Robot Arena - More Than Four Robots

[shedRift]

From a message I sent to Trovaner:

"   Sorry I kept you waiting.  The computer I have the game currently installed on, running Windows 7, has crummy wireless adapter drivers for the the card I use with it.  The flakey performance of the wireless adapter under Windows, which is more frustrating      than it  may seem, essentially  prevented me from accessing the Internet on that computer, which in turn slipped this forum from my mind.  I mean to transfer all the game and tool files to my laptop, which has better wireless performance.

   In order to have more than 4 robots, all individually controllable, I simply created multiple independent structures in each robot file.  By default, components in the game are either attached to the base frame or other components.  I instead set the attachment of the separate, independent of the base frame, parts of the robot file to -1, if I remember right.  I think 0 was the base frame, and any positive integer referred to the ID of a component other than the base frame.  Once a component is attached to ID -1, other components can be attached to that component.  For example, if Component A is attached to the ID -1 and Component B is attached to the ID of Component A, Components A and B will be together and separate from the rest of the robot.  Taking this a step further, motors and wheels can be added to parts independent of the base frame to make other robots.  All independent robots get power from the battery placed inside the base frame.

   Unfortunately there are only 9 spaces in the menu for controls.  I bet it is perfectly possible to add on more controls through the robot file though.

   Giving artificial intelligence to the robots seems difficult, perhaps limited, but possible.  Given that all livelihood of the multiple robots in one file comes from the base frame, this setup is probably not well suited for traditional robot fighting.  I imagine I could attach "smart zones" to components of independent robots within a file and attempt to work out something from there.  If there is some sort of non binary but rather analog smart zone it would help a lot.  That would be preferable over attaching 50+ smart zones, to an independent robot within a file of others, to get some idea of the surrounding robots from other files during a match.

   One key limitation, or possibly a benefit, of multiple robots in one file is that they do not collide.  I can see this being beneficial for a game with 4 teams of 3, as teammates would not get in each other's ways.

   It may be a good idea for me to pin a post of this in the Modifications section and add on things if I have forgot them.  I now realize this is likely important to a lot of people here.  I failed to notice when I promised a video and failed to make one.

   I will aim to transfer everything to my laptop this weekend and get back into this. "


I will reword the explanation to make it more clear soon.

Expect more, I did not mean to disappear.

[Badnik96]

Certainly an interesting development. So clusterbots can be a thing now, just with some cool side effects.

Thanks for expanding on this, you deserve tech advisor or something

[Virus Bomb]

reminds me of that bfe multibot that click made

[Thyrus]

you need to sty... seriously

[System32]

Actually adding more than 4 via source code editing wouldn't be all that hard.

After all, it merely requires a few small edits to the Match select GUI, And the location and addition of the bot spawning array (assuming the coders did so).

edit: Forgot to say the final edits would be to the arenas themselves, as they only have bot[0] to bot[4].

Serge has a tutorial for Source code editing.

[Trovaner]

I, actually, don't think it would be that easy to extend the EXE's bot limit unless they intended to have more than 4 bots. If you take a look at the code used for the status meters, you'll notice that the EXE is responsible for placing them into the four corners. This implies that the coordinates have been predefined inside of the EXE. If they are storing these coordinates inside of a 2D array than we would get some sort of index out of range exception when it fails to find the coordinates after index 3. Likewise, if they hard coded conditionals with values than the EXE wouldn't be able to have a place to send the information and most likely crash due to its absence (since it doesn't make much sense to check for something that should always be there).

I thought I made a post about the EXE's four bot limit somewhere but I couldn't find it. Instead I found this post:

It is not currently possible to add more than 4 fully-working bots. It is a limitation caused by a lack of coding in the EXE to handle more than 4. Serge was looking into it but he nor anyone else has had any success.

As a workaround, housebots have been created in the GMF files of some arenas but they don't support everything that normal bots do. There are some good topics on this subject: here, here, and here

There is also another workaround involving trying to pack more than one bot into a .bot file. This works because the chassis is treated as a component. IIRC, the issue with this is that if one of the chassis are destroyed then both bots are destroyed and one of the bots can't use wheels to move. As far as discussion topics go, I could only find this one but many modders have done it before so we can explain it further if necessary.

I'm certainly not trying to belittle shedRift's rediscovery of this; I just thought I'd point out some of the other side effects. Another thing to note is that I don't think you can have more than one chassis inside the same bot file. Most of my attempts to merge bot files were made in 2011 so the above quote may not be completely accurate (although, I'm assuming that it is).

[shedRift]

Thanks, helpful links. 

[System32]

I, actually, don't think it would be that easy to extend the EXE's bot limit unless they intended to have more than 4 bots. If you take a look at the code used for the status meters, you'll notice that the EXE is responsible for placing them into the four corners. This implies that the coordinates have been predefined inside of the EXE. If they are storing these coordinates inside of a 2D array than we would get some sort of index out of range exception when it fails to find the coordinates after index 3. Likewise, if they hard coded conditionals with values than the EXE wouldn't be able to have a place to send the information and most likely crash due to its absence (since it doesn't make much sense to check for something that should always be there).

I thought I made a post about the EXE's four bot limit somewhere but I couldn't find it. Instead I found this post:

It is not currently possible to add more than 4 fully-working bots. It is a limitation caused by a lack of coding in the EXE to handle more than 4. Serge was looking into it but he nor anyone else has had any success.

As a workaround, housebots have been created in the GMF files of some arenas but they don't support everything that normal bots do. There are some good topics on this subject: here, here, and here

There is also another workaround involving trying to pack more than one bot into a .bot file. This works because the chassis is treated as a component. IIRC, the issue with this is that if one of the chassis are destroyed then both bots are destroyed and one of the bots can't use wheels to move. As far as discussion topics go, I could only find this one but many modders have done it before so we can explain it further if necessary.

I'm certainly not trying to belittle shedRift's rediscovery of this; I just thought I'd point out some of the other side effects. Another thing to note is that I don't think you can have more than one chassis inside the same bot file. Most of my attempts to merge bot files were made in 2011 so the above quote may not be completely accurate (although, I'm assuming that it is).

There wouldn't be a need to add co-ords along a 2d array, and every screen in the game is in fact a .GUI file. However, that means I'll have to look into where the exe calls the gui files, especially on the options menu.

Lastly, The array would have to be altered along with other possible arrays, such as the one that finds bot spawning positions in the arenas, the one that calls on the AI, the one that updates CO2, points and damage etc etc.

[Trovaner]

There wouldn't be a need to add co-ords along a 2d array, and every screen in the game is in fact a .GUI file. However, that means I'll have to look into where the exe calls the gui files, especially on the options menu.

I'll give you the benefit of the doubt by assuming that you mean .GIB files and IDA's C-style pseudocode rather than .GUI files and source code...

The .GIB files are just layouts that get parsed at runtime by the EXE. You are right that the .GIB files are responsible for most of the GUI but all the functionality such as button events and bot slots are the result of the EXE having hard-coded calls and references that are only accessible from specific screens. Also screens like the actual combat screen do not have a dedicated .GIB file (in most other places, they used a placeholder widget inside of the GIB to represent 3D content that is generated by the EXE but not in this circumstance).

As I attempted to explain in my previous post, the EXE reads statusmeters.gib and creates a new HUD for every bot. In order for each HUD to be placed into its own corner, we know that the relative x and y positions must be predefined within the EXE. For this reason, I gave the two most likely implementations that Gabriel Interactive used. Both implementations, however, would result in the game crashing if the programmers assumed that it would always be limited to 4 bots. Which considering the predefined placement of the HUDs in the corners, this is a pretty good guess. If they were lined up across the top than it would have been easier to code something that dynamically positioned the HUDs based on the number of bots but they clearly didn't do this (unless of course they have some unused handling that switches the layout when there are more than 4 bots (extremely unlikely)).

I am fully aware that you can turn off the HUDs or try adding more code to the EXE. My point is that if Gabriel Interactive wasn't planning on having more than 4 bots than it is going to be a very difficult task to add it without the source code. It isn't going to be as simple as changing a 4 into an 8. In fact, it is very possible that you'll need to change more than one 4 into an 8 and make multiple injections of your own code for handling stuff that they hard coded into the other slots. I'm not saying that you shouldn't try to do it; I'm just making sure you realize how big of a task it would be.

Lastly, The array would have to be altered along with other possible arrays, such as the one that finds bot spawning positions in the arenas, the one that calls on the AI, the one that updates CO2, points and damage etc etc.

Considering that they probably created a bot class and kept an array of active bots, I doubt that you'll need to worry about associating bots to start points, bots to AI, or bots to HUD data. Since those sorts of things would have been handled recursively on each element in the bot array. As very indirect evidence of this, the python code has quite a bit of object-oriented programming and I would assume that they weren't complete idiots when they coded the C++ code (since it would have required the exact same handling for each bot and they clearly understood object-oriented programming).

[System32]

Yeah I meant the .GIB files.

Also screens like the actual combat screen do not have a dedicated .GIB file (in most other places, they used a placeholder widget inside of the GIB to represent 3D content that is generated by the EXE but not in this circumstance).

However the UI/common/gamewindow.GIB actually has values for the placement of the statusmeters.GIB.

Code: [Select]


[Group]
ReportedPos 6 0 406 0
Alignment 33
Notes load 'statusmeters.gib' here
Name player3 status
Position 0.01 1 0.98 1
ChildOrder 3


[Group]
ReportedPos 549 0 406 0
Alignment 36
Notes load 'statusmeters.gib' here
Name player4 status
Position 0.99 1 0.98 1
ChildOrder 4



[Group]
ReportedPos 6 0 9 0
Alignment 0
Notes load 'statusmeters.gib' here
Name player1 status
Position 0.01 1 0.02 1
ChildOrder -1


[Group]
ReportedPos 549 0 9 0
Alignment 12
Notes load 'statusmeters.gib' here
Name player2 status
Position 0.99 1 0.02 1
ChildOrder -1

And with the relevant bits:

Code: [Select]

[Group]
ReportedPos 6 0 9 0
Position 0.01 1 0.02 1

[Group]
ReportedPos 549 0 9 0
Position 0.99 1 0.02 1

[Group]
ReportedPos 6 0 406 0
Position 0.01 1 0.98 1

[Group]
ReportedPos 549 0 406 0
Position 0.99 1 0.98 1
I've edited the GIB for the main menu before. Here is the gamewindow screen with Player1's pos file altered.

Code: [Select]

[Group]
ReportedPos 6 0 9 0
Alignment 0
AspectSetting 0
AspectRatio 0
PassMouse true
Notes load 'statusmeters.gib' here
Name player1 status
ID -1
Position 0.51 1 0.32 1 //EDITED CODE HERE
Size 84 0 64 0
Visible true
ChildOrder -1
ClipMode 1
NumChildren 0
And here is the result:



And this was in notepad.

[Trovaner]

Huh, my mistake... I guess its been longer than I thought since the last time I worked with the GIBs...

I took another look at gamewindow.gib and it looks like the EXE is replacing the Group widgets rather than using the builtin Proxy widget. With this in mind, it is possible that the EXE is using the game type's bot size limit for determining which widgets get replaced by a visible HUD (sounds obvious but it implies that the implementation may be more intuitive than I originally thought). You may still need to increase the array size and tell the EXE to load more than 4 bots but it may be just those two values that need to be changed.

[System32]

I'd do it myself If I could be able to find the damn things.