Menu
▾
▴
1 Attachments
#93 Addition of console-like features
Recently, I've been testing Doom Legacy in my Raspberry Pi 2, a small single-board computer that has an ARM processor and runs Linux, with a distro called Retropie that can basically turn it into a gaming console, operating only through gamepads. Some guys on RetroPie forum were able to compile Doom Legacy in Raspberry Pi computers, thus being able to use it for playing Doom in split-screen with two controllers.
However, although DL runs fine in RPi, this sourceport isn't fully optimized for a console-like experience. Unlike all other frontends and emulators inside RetroPie whose menus and interfaces are fully navigable with USB controllers, Doom Legacy won't allow you to navigate through menus without a keyboard or a mouse.
I'm sending, as an attachment, a patch that implements a console-like experience in Doom Legacy, and aims to address those issues. The patch was created by a "svn diff" command, based in the commit 1453, the latest one from now.
Here's a description of the changes contained in the patch:
- Allow menu navigation with a gamepad: By using SDL_JOYHATMOTION event, now the D-Pad of the first controller works as arrow keys in menus, thus allowing player one to navigate in the menus with your gamepad;
- Translation of joystick hats to button mappings: By using SDL_JOYHATMOTION event, now it's possible to bind D-Pad directions to actions, just like moving or changing weapons / inventory;
- Translation of Xbox360 triggers to button mappings: By using SDL_JOYAXISMOTION event and a local routine that uses SDL_JoystickName function in order to try to detect Xbox360 controllers, now it's possible to bind those buttons to actions, such as RT to shoot, or LT to look up;
- Joystick axis deadzone support: Applies axes movements only if the values are between 4000 and 32768, or -4000 and -32768. This way, axes won't be super-sensitive to smallest movements ocurred when the analog sticks aren't fully centered, or somehow loosen. Useful to avoid a bug where players keep moving like crazy on controllers sometimes;
- Axes movements sensible to "Run" command: Doubles axes values when "Run" is pressed / activated. Works only when player is moving or strafing;
- Ability to read autoexec file in home folder: Useful for having "autoexec.cfg" in the same folder as "config.cfg";
- New automatic bindings for the first plugged controller:
- "Y" key to "Enter" Key / Button 1: To confirm the operation in confirmation popups, such as ending a game or exiting DL without a keyboard. The "Y" key still works;
- "N" key to "ESC" Key / Button 2: To cancel the operation in confirmation popups. The "N" key still works;
- "S" key to "Enter" Key / Button 1: In order to start a multiplayer game when "Wait players" is greater than 1 and other players haven't connected to you yet. The "S" key still works;
- New control bindings:
- Automap: To show the map from a controller button (ex: R1 or RB). TAB key still works;
- Main Menu: To open main menu from a controller button (ex: START). ESC key still works;
- Pause: To pause the game from a controller button (ex: SELECT or BACK). Pause key still works;
- New multiplayer / splitscreen game options:
- Bots: Allows you to add bots in a game, without having to recurr to "addbot" console command (already added in recent commits);
- Randomize Bots: If true, bots will be added with random names, colors and skins (if there's any). If false, bots will be added in the original sequence of names (Frag-God, Thresh, Reptile, etc), colors (green, indigo, brown, red, etc) and will always use the default "Marine" skin.
I tried creating this ticket in the "Patches" section, but it seems I have no permission to do that, so I'm posting it here. Sorry if it's in the wrong place, and sorry if some of my code changes aren't as good as it should, since I'm not as versed in C++ as I wanted to be. But at least for me, all those changes worked fine, both on my desktop with Ubuntu and my RPi2 with a Debian-based distro.
Doom Legacy is a great source port and I wanted to help its development somehow. I hope my contribution helps, and that you guys include them in DL in the future.
I forgot to add a few screenshots showing the changes above. Firstly I tried editing my post in order to include them, but it seems I can't do that on sourceforge. So I'm posting them in this comment. Sorry for the double-post.
I've sent them as attachments. See below.
Last edit: Leonardo Montenegro 2019-08-20
I don't see any problems with most of this. I suppose with a Pi you don't have a keyboard, so the one source of input has to be used for everything.
Do consoles usually activate a menu for every question and then just give you joystick means to select choices off the menu ?
You are going to run out of independent buttons trying to assign each to a function, and memorizing those assignments is going to be a problem for users.
Please respond as to the maximum number of button->action assignments that will be needed to cover all uses, and how many buttons do you typically have. Please realize that there are more actions planned such as crouch, crawl, etc. etc., and they will have keybord assignments, so you may run out of buttons.
I assume you can navigate the option menus using the joystick, and can select menu values.
I don't need screenshots.
The Patches section seems to be for offical patches to the code base. Not used very often.
I will implement the deadzone with a menu setting to control the deadzone size.
Every joystick behaves differently.
The bots are already randomized. The problem is that the B_Random repeats the same values every time the game is started. This is good for recreating a demo, but at times it is undesireable.
I have added a new Random number generator, and I should see about making it non-repeatable. Then it could be used in B_Init_Bots to initialize the tables.
There probably should be a random number initialization control in the menus so the user can choose repeatability or more randomness.
I don't know if I understood this question correctly, but if you're referring to the ability of accessing menus / selecting choices from a controller, then the answer is: you can select choices in menus by pressing the first button of your controller, and go back to the previous option by pressing the second button of your controller. That works only for the first controller, and basically translates Button 1 to Enter Key, and Button 2 to ESC key.
However, you can't access menus after starting a game (since there's no way to access ESC key from a gamepad), neither navigate in the menu options (since menus are navigable only through keyboard arrow keys or mouse movements).
Both issues were implemented in the patch I sent.
I don't think that'll be a problem. I have two different kinds of controllers here: one is a Playstation 2 wired controller, and other is a Xbox360 controller. Their controller layout are basically the same of most controllers out there: PS4 controllers, Xbox One controllers, even Switch gamepads, etc.
On all those cases, I have 12 buttons: four buttons at the right, four shoulder buttons at the top, Start / Select buttons and two analog stick buttons. Besides, there's four more options for mapping: the D-Pad directions, that now we can use for mapping them to actions such as change weapons (and/or inventory in Heretic / Hexen). Counting buttons and D-pad directions, there is 16 buttons total, which is already the maximum DL handles if I'm not mistaken.
Anyway, here's how I've configured DL for my PS2 controller:
In my case, those mappings allow me to do almost all actions in a game. And there's even two available buttons that I haven't used: Circle and Triangle. You can easily use Circle to crouch, and Triangle to crawl.
And there's even an axis available: Right analog stick, Y axis. Initially I thought at using it for looking up / down, but with the auto-centering mentioned in feature request #80, aiming with the axis isn't a good idea. That's why it's unused in my case. But if you use it, then you'll have two more available buttons (L1 and L2).
Good idea. This way it'll be more flexible.
BTW, that suggestion would complement with the feature request #91 that I sent last month. This way, users will be able to fully customize axes from the menus, instead of having to use "bindjoyaxis" commands for that task.
Yes, as the code says, it's already randomized. And indeed as you said, it's a "fake random", since the values are always the same. And even if we take into account the demo recreation, maybe it'd be more correct to implement it directly in the demo playback routines, in order to record bot information inside the demos, instead of relying on the "bot randomize" routine.
And even if you implement a new random number generator that indeed works, there's another problem: if the "bot randomize" routine is situated in "B_Init_Bots" function, then it'll be executed only once. So if you create a dozen multiplayer games in a same DL process, then all bots' informations will be the same for all multiplayer games you've created.
That's why I've decided to move the "bot randomize" routine to "Got_NetXCmd_AddBot" function, inside "d_clisrv.c" file: this function is called everytime a bot is added, and when applying the randomness here, it results in fully random bots for each multiplayer game created.
It was on this function that I've implemented the following behaviours:
Last but not least, I don't think it's necessary to add option for users to choose more repeatability or more randomness. For me, only a boolean "Random bots" should be enough.
Last edit: Leonardo Montenegro 2019-08-21
Do consoles (on the PS2, Playstation, XBox, etc.) usually activate a menu for every question and then just give you joystick means to select choices off the menu ?
Your answer seems to be about your patch. I was asking what is the usual user interface that those other consoles use.
I don't think that 4 unused buttons is going to be enough.
The new keypress functions that are being considered include: crouch, kneel, crawl, prone, climb, drop weapons, drop objects, give item, place object, activate object, choose category, enter combination (keypad 0-9).
Current keyboard uses: weapon select (0-9), fwd, rev, left, right, look up, look down, strafe right, strafe right, drop bomb, jump, fly, activate, inventory left, inventory right, activate item.
The weapon select and keypad are the most troublesome.
The rest total up to 27 key functions, so maybe 32 distinct keys will be needed.
What do the other( PS2, XBox, etc) do for games with such needs, use drop-down menus, or dedicte one key to function-shift?
All games have this random number repeatablitiy vrs randomness issue. There is often a place to enter your random number seed, with an explanation that using the same seed will give you the same game setup. Entering a seed of 0 is interpreted as automatic mode. You may not see it on console games simply because they do not offer the choice.
There are many other things selected by the random number generators than just the bot names.
I have never owned a PS2, XBox, or other game console.
The PC joystick I have has a 2-axis joystick, two buttons on the joystick, and two on the base.
Last edit: Wesley Johnson 2019-08-21
Well, that's kinda specific for each console. Every console has its own user interface. Every game ported to a console has an own user interface. It varies a lot, so it's hard to know that.
However, all of the interfaces has one thing in common: they're already optimized for controllers. You can do everything from a gamepad, since menu navigation, control settings and the gameplay itself. There's two simple examples I remember: one is Doom 64 (a port of Doom for Nintendo 64, with sprites made from pre-rendered CGI graphics), and the other is the recent ports of Doom for Xbox360 and Nintendo Switch. On both cases, the game assumes the following controller mappings by default:
I'd say most of those functions are redundant to me, and can be resumed in one only key.
Take crouch / kneel / crawl / prone, per example. The first FPS game I've ever played that has those functions is Call of Duty 2. On PC, all those actions can be done with a single key: Ctrl. If you press it once, the player crouches. If you hold it for half second, player prones. When proned, you can crawl simply by walking at this stance. And I don't see a difference between crouch and kneel, for gameplay purposes. There's COD2 for consoles too (PS2 and Xbox), and the controllers works basically the same way.
Climb action can be done simply by jumping, and COD2 even uses a same key (Spacebar) for jumping and climbing. The same applies for the console versions.
Fly action can be done with jump key too, and for me it's better than having two different keys for that action.
About the possibility for dropping weapons and objects, I know that ZDoom has this feature, and there's even some mods that uses it (Real Guns Advanced 2 is a example, since it basically replaces Doom weapons for the ones in Call of Duty Modern Warfare series). You can have only two weapons in that mod, so you gotta drop the one you have, in order to change it. And you can drop weapons / items for other players to pick. However, it's not a feature that modders uses frequently. In fact, there's few mods that has this implemented.
Choose category can be simply done by extra menus that user can navigate with arrow keys, just like player skin selection screen. There's no need to add extra buttons in that case. ZDoom has this feature too, and it works fine on controllers without having to map extra buttons.
And about the "enter combination" / "weapon select" (keypad 0-9), if you're referring to the ability of changing weapons by pressing those numbers, that can be easily done with "Next weapon" and "Previous weapon" mappings (that in my case, I mapped them for D-Pad left and D-Pad right). The same applies for "inventory left" and "inventory right" (in my case, D-Pad up and D-Pad down).
And if you don't like changing weapons with "Next / previous weapon" mappings (because it's slow to go from a shotgun to a bfg9000), there's another way of changing weapons, that can be faster:
It works this way: that disc in the center of the screen, showing all weapons, is shown when player holds a specific key / button. In order to fast change weapons, you hold the key that shows the weapons' disc, and while it's pressed, you press a direction with D-Pad or any axis, and the weapon is changed with the one from the pressed direction in the disc.
There's two FPS games that uses that feature for changing weapons, items or skills. One is Serious Sam 3, other is Crysis. Both on PC and console versions.
There's another thing to mention here: Most controllers nowadays won't have more than 12 buttons, so even if you increase the max button limit from 16 to 32, it'll be rare to find joysticks with more than 16 buttons (counting with D-Pad directions) to test that feature.
Well, on that case, you'll indeed have trouble trying to map the needed buttons for fully playing Doom without a keyboard. You won't have enough buttons for actions such as change inventory, jumping or crouching. But at least you'll be able to move your character, toggle strafing, shoot, open doors and run / change weapons. But in that case, Doom isn't optimized for controllers with less than 6 buttons. Even Doom ports for Super NES makes use of all six buttons for most basic actions.
Last edit: Leonardo Montenegro 2019-08-21
I have been working on your submitted code, to include it in the next release.
There were several problems in the existing code, which took some time to solve.
I added some features, and modified some of your code to prevent it from changing the existing keyboard behavior.
I think it is incomplete, but probably adequate. If someone does not have enough buttons to use this, they should have a keyboard attached too.
Please test this patch. Let me know if something got broken.
It will get cleaned up before it gets submitted. I will take out all the debug stmts.
Just tested your patch. It's working, but with a few things to mention:
Deadzone slider did not work any better, but an option for it is in the code. The slider tends to overdraw the name, and takes the same number of button pushes to change
Changed default to 800. Made the step increment to be 20. So now it is 10 clicks to reach 1000, and I assume each person only has to set this up once. If you can get a console or edit the file directly, you can still set any value.
Wait players: I do not have those controllers and cannot comment on button appropriateness.
Pause button: I just used the next one after the menu button. Let me know if there is some better default joy button for pause.
Mapping a button to 's': I went wilh using the pause button because it is used for pausing (stopping and starting) the game already, and it is does not have any conflicting usage during the WAITPLAYER message.
Using the KEY_ENTER for 's' was also affecting the keyboard. I do not want any kludges put in to make joysticks work to be affecting the keyboard usage.
A user can avoid having to press the 's' button by:
1. set a waitplayer timeout, like 5 seconds. The game will start after 5 seconds.
2. set the number of wait players to 0, the game starts immediately.
I verified that the game skill is correct using the debugger and looking directly at the gameskill variable. If there is some problem then it should be a separate bug report. Also, I need better info on what menu operations are used to start the game, and what behavior is observed that makes it appear to be a lower skill level.
I noticed that the gameskill is not set until the game is actually started.
The bot code has some options, one of which makes bot skill to be one less than the game skill.
The updated code patch is attached.
The menus have changed some also.
That should work for now. And it's easier than setting a slider.
However, it'd be interesting to make it customizable for each controller in the future. Maybe some users want to play DL with two different controllers, and different axis sensibilities. Having the option to set, let's say, deadzone 1000 for the first controller, and deadzone 500 for the second, would be interesting.
But I understand that it's not the time yet, so I'll keep this noted for future support requests and/or patches.
The default button for PAUSE is "Joy 0 But 5", the fifth or sixth button in the controller, right? And it's exactly this button used for 's' on Wait Players?
If true on both questions, then there's a problem: what if user has a controller with less than six buttons? You have a controller with only four, so it won't work on your case. It's still better to use the first button on the controller for 's' action, and the second one for 'q' action, since it's exactly these buttons that works on the menus for selecting options and going back.
Yes. At least it's a workaround. However, if user has a controller with less than six buttons (such as the one I mentioned before), he'll probably be stucked on that menu, since he won't be able to go back to menus without a keyboard.
I'll see if I can open another bug report for the skill bug I'm getting. However, there's a simple way to demonstrate this issue:
That suggests that, despite I've chosen skill 4, it seems to be using skill 3 (Hurt Me Plenty), since that skill shows the three zombies, but not the imps on the corridors.
It's worth to mention that DL 1.47.2 works just fine when I choose Ultra-Violence.
Last edit: Leonardo Montenegro 2019-09-21
I was seriously looking at making separate settings for each controller, but the controller system is not setup for defining the settings or providing the separation. That ability only got added to the mouse in the last release.
A default for the PAUSE button was not provided in your code so I invented one arbitrarily.
I don't know what button 2 was doing, but I assumed you skipped over it for some reason.
I think that a 4 button controller will require a keyboard too. Almost everyone will have a keyboard.
Please let me know what button is best for the PAUSE. I have no idea what the button labels on the controllers are, or where those buttons are.
It is JOY0BUT0 and JOY0BUT1 that are intercepted and are thus are problematic.
I could also detect JOY0BUT2 to perform 's'. That would not conflict, has no translation problems, and is cheap to implement. I could easily detect JOY0BUT3, JOY0BUT4, JOY0BUT5 too, thus giving 3, 4 or 5 buttons that would substitute for 's'. Because that detection happens only during WAITPLAYER it has no effect on any other use of those buttons.
The button for gc_menuesc (what you had as gc_mainmenu) is also intercepted, but that is defaulted as JOY0BUT7. If the user redefined gc_menuesc as JOY0BUT2, it would be intercepted too, so it is necessary to have a second button also perform the 's'.
While it is possible to work some kludge for using JOY0BUT0 button to substitute for 's', it will be expensive in the code. I have not found a cheap way to detect that due to the translation being done in a different response handler which is being used indirectly. The source information is lost already.
I am most determined to block the KEYBOARD ENTER key from having any response in that message, because I have learned from other projects that the key that leads to the last menu needs to have no response in the last menu, because it can trigger a non-reversible operation.
I have made that mistake before, and have had to remove code after only a week of user experience with that.
The user should be able to back out of the WAITPLAYER message using the ESCAPE button.
They can then define the PAUSE button, or set wait players to 0, or set a timeout.
I had been planning to release in the next week, but I have not even got to the other issues at hand. More things are going to have to be left for later.
Well, one of the most popular types of controllers are the ones from Xbox 360 or Xbox One. We could use them as reference.
On those controllers, by default, "Back" is the seventh button and "Start" is the eighth. You could use Start for "Main Menu", and Back for "Pause". Or to simplify:
Main Menu -> Joy0 B 7
Pause -> Joy0 B 6
Then must move gc_automap to Joy0But8.
I think this will have to be the final test.
I also changed the 's' test to recognize more buttons, just not but0.
Have too many separate items in one request....I cannot just cleanly close this thing.
1. Have the BOT issues been addressed by the existing bot patch ?
2. Does the proposed joystick patch deal with all the joystick issues ?
3. I think joystick deadzone has been covered.
4. The autoexec file in a different directory. The Windows DoomLegacy launchers use the autoexec file and we have been having a problem with DoomLegacy reading the wrong autoexec file and thus ignoring the Launcher settings. Allowing it to default to another autoexec file from a different directory is not going to help that situation at all. What usage problem does this fix ??
Is it just some settings due to the platform and you are storing them in autoexec, and want to hide the file better ? Would another file with a separate name work as well ?
Just got the latest patch, together with the latest commits you've made.
Before answering the questions, just reporting that the game skill bug was fixed in the commit 1459. Tested with doom2 iwad and a few other pwads, and now they're working as it should.
Anyway, let's go to your questions
If you're referring only on the patches you provided here, then I don't know. When opening the patch on a text editor and reading the changes you've made, I haven't seen nothing that should change the bots' behaviour.
However, I've noticed in the recent commits that you've implemented some nice options for customizing bot skill without having to rely entirely on game skill. This way, now I can start a deathmatch on skill 4, and then reduce the bot skill on the console with the command "botskill 2". Another thing I saw is that the bots' behaviour seems to be different in some situations (improved maybe), and there's more bot names than before.
Another thing to mention is: the randomizing bot routine is still the same as the previous one. I've started three consecutive multiplayer games with three bots, and it always chooses the same bots on my case: Fodder, Ralphat and Reaper. Besides, their colors were always the same: Green, Brown and Brown. It'd be interesting to have at least the option to customize, through console commands, informations such as:
Yes, all joystick issues seems to be solved to me. Everything it working as it should be.
I confirm the step increment in 20 worked, and for now it'll do the job. It's covered.
Maybe it's some kinda specific use case. Lemme explain.
On RetroPie, all games installed go by default to /opt/retropie/ports. The doom legacy binary goes to /opt/retropie/ports/doomlegacy. It's a folder that only root users can create, edit or delete files.
By analysing DL's source code, I noticed that, on Linux OSs, autoexec files are loaded only if they're on the same folder as DL binary. And that means having to recurr to root user everytime I need to edit something on that file.
That's why I added a routine that, before searching for autoexec.cfg in the same folder as the binary, it firstly searches in the home folder for a file with that name. In my case, in /home/user/.doomlegacy/autoexec.cfg. This way, editing "autoexec.cfg" is as easy as editing "config.cfg".
I'm using autoexec.cfg files solely for storing my "bindjoyaxis" commands, since it's a safer place to put them. Previously, I was putting them on "config.cfg" inside my home folder, but if I accidentally open DL without having plugged my controller, the lines containing "bindjoyaxis" disappear, thus making me lose all controller axis settings. That doesn't happen on autoexec files.
Anyway, if it's causing more problems than solving anything, feel free to ignore this feature for now. There's better ways for solving issues related to "bindjoyaxis", such as separate file names.
Last edit: Leonardo Montenegro 2019-09-24
There is a bot menu under Game options.
Changing the random number seed changes the bot names and colors. This is SAVED so that if you get a setup you like it will stay. Using the seed of 0 makes it use the ERandom number, which I am considering initializing from the OS random number generator. I am only worried about debugging when ERandom is initialized random, so maybe it should be that bot is initialized from system random when that seed is 0.
This menu item for seed has the same problem of having a wide range, and no way to type in arbitrary numbers. To use a seed of 1004, you have to press right 1004 times, or edit the config file with an editor. Any solution for this is not going to be Xbox controller friendly.
Last edit: Wesley Johnson 2019-09-24
Didn't know there was a new bot menu, although I could see most options from the command-line.
Anyway, just tested "botrandom 0", and I confirm it's returning random bot names and colors whenever a multiplayer game is created. However, I'm getting repeated bot names sometimes, and I remember having implemented a routine for checking duplicate bot names, in order to choose another one when detecting that a bot with the same name was previously added.
For other random seed values in "botrandom", I don't think it's necessary to add option for customizing it through the GUI, since as a controller user, it would be much simpler to have only the option to change between random and non-random bots (simply a boolean). If users need to test other specific options in "botrandom", maybe it'd be better to make it exclusively through command-line.
Suport for autoexec file in home directory and executable added svn 1461.
The launcher uses a different file, using a switch.
There is protection against duplicate bot names in B_Init_Names. The bot code always had this.
There is no protection against duplicate bot colors.
Are you sure you are getting bots with the same name in an individual game?
Your patch took the random out of B_Init_Names, and added a randomize bot command for the console. It also added skins to bots. However, this console command is only good for a local player, not network play, not saveable, not reproducable for demos.
The system random has not been implemented yet. It is going to get really complicated because of network play and playing demos, it is inherently non-reproducible. Still thinking about it.
So for now to get different bot assignments, poke the bot random.
If something is only a console command, and not in the menus, then most users are not going to use it, and probably would not even know it existed. Example: Mozilla Firefox has a massive number of tunable values that most people do not know exist.
Last edit: Wesley Johnson 2019-09-25
Yes, I noticed some code for protection against duplicate bot names. And yes, there's no protection against duplicate bot colors and indeed it shouldn't be. However, even though there's some attempt of protection against duplicate bot names, I'm still getting repeated bot names in one specific case.
I've done the following steps:
After 4 or 5 attempts of the following steps, I got two cases of "Carmack" being repeated, one twice and other three times. It's worth to mention that it happened only with "Carmack" for now. I'm sending a screenshot as attachment, to demonstrate the repetition.
BTW, have you included bot skin support in those patches, or it'll be done later? I haven't seen any options to customize that feature.
I'm asking this because I've done a few improvements in the "Randomize Bots" implementation, in order to add a third option called "On Map Change", which randomizes bots colors and skins everytime a map is changed. I haven't sent a patch containing those changes yet, because I'm waiting for the version 1.47.4 to be released these days, but as soon as it's released, I intent to create a patch containing these and other changes, and it can be related to that patch somehow.
That's not the point. What I meant is: currently, the option values for "Bot Random" aren't intuitive for common users. They won't understand why it accepts numbers between 1 and 999999999, and why not make it simpler by simply having "Yes" for random and "No" for non-random. That's why I suggested having it only as a console command.
Anyway, maybe there's other ways of improving it without relying at making it console-only. Why not separate it in two options such as those below?
Bot gen options, including several random sources, svn 1462.
Fixed the duplicate names problem. The duplicate check was neatly thwarted by a spurious semicolon on the FOR stmt, which split it into two legal stmts.
Added bot color duplicates check, so colors are not reused until all colors are used.
Added bot skins.
Any Bot randomize should call B_Init_Bot().
I prefer that bot code be in the bot code files, and the clisrv contain network code.
I have been moving some code blocks around to achieve that, as some of the previous authors were somewhat lazy about where they dropped in code.
Last edit: Wesley Johnson 2019-09-27
Just updated my DL copy via SVN, recompiled the binary and tested the new features.
I saw you separated bot random in two options, one for bot generation method and other for bot seed. After selecting "seed random" in the bot generation method, now all bots added are random for each multiplayer game. Haven't tested the other options besides "plain", "seed" and "seed random" to see what each option does, but at least for now it should do the trick. It's better than before.
I confirm that the duplicate names problem isn't happening anymore, after a few multiplayer games created.
I confirm that bot color duplicates check is working. After creating a dozen multiplayer games with 3~7 bots, I noticed no color repetition.
I confirm that bot skins are working. Loaded those Skulltag skins ported for DL support, and all bots are using a random skin from those.
That being said, I guess this ticket can be finally closed.
Gamepad: svn 1466
Note: svn 1465 simplified the control names for mouse and joystick. This will affect the config file.
Until 1.48 release, you may want to have a separate config file for testing.
see WDJlog.txt
Release of 1.48 will be this week, so I need to bug anyone who will TEST for me.
Any updates on this? Looking forward to version 1.48 so I can try it on the Raspberry Pi
DL 1.48 is still at testing phases before release. You'll have to wait a bit longer, until this version is finally released.
However, there's another way to try those changes on a Raspberry Pi, while still on version 1.46: By applying this diff patch I've created some months ago, on RetroPie forums, and then recompiling it from source. By following the instructions I provided on the link above, you can compile a custom DL version, based on 1.46, that contains most (if not all) changes mentioned on this feature request.