View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0021013 | AI War 2 | Bug - Gameplay | Mar 20, 2019 10:26 am | Mar 21, 2019 10:25 am | |
| Reporter | DEMOCRACY_DEMOCRACY | Assigned To | Chris_McElligottPark | ||
| Status | resolved | Resolution | fixed | ||
| Product Version | 0.816 Aggressive Busting and Stacking | ||||
| Fixed in Version | BETA 0.850 The Arrival of Fleets | ||||
| Summary | 0021013: Marauders bypassing stack limits. again. | ||||
| Description | It appears that marauders are not obeying the laws of C# and are bypassing the 15 raider limit again. ok then save is before things get interesting interesting save is when it's possible for marauders to produce more raid ships than cap allows 17 of 15 is when marauder outpost left most middle states it has a 17 of 15 cap. weird cap thing is just a jpg showing the marauder outpost interestingly, if you reload saves, the cap resets to 0. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
Hey Chris, so each Marauder raider tracks the PrimaryKeyID of the outpost that spawned it. However, primary keys seem to be handed out very differently after save/reload. The code for serializing this is now Buffer.AddItem(OutpostId, true ); <=== the "true" here is from your commit that "compacts" down the Int64 variables that are used for GameEntityIDs We no longer use 64 bit numbers for game entity IDs. When I load a game I and print the outpost IDs I see things like Found raider Marauder_Drone_Raider 5536 on Appel and was spawned by outpost 2 <=== this is a unit loaded from the save; this outpost id is clearly incorrect Found raider Marauder_Drone_Raider 5548 on Appel and was spawned by outpost 3 Found raider Marauder_Raider 5571 on Appel and was spawned by outpost 1 Found raider Marauder_Raider 5595 on Appel and was spawned by outpost 4 Found raider Marauder_Raider 119701 on Nemet and was spawned by outpost 4779 <==== these are newly spawned units with the correct values Found raider Marauder_Drone_Raider 119664 on Appel and was spawned by outpost 5476 I'm not sure what to do here, since I'm not sure if the compacting code you talked about is meaningful anymore (or if this whole thing is being changed in .900) |
|
|
The compacting code is still meaningful, and is probably needed but not definitely. Also actually it makes savegames smaller in their text format, though that's less relevant now that I think maybe we switched away from that? I will have to investigate. Anything that references a primary key, or that is direct storage of a primary key, should be passing it as true as above. In that way it winds up mapping properly, because it builds up a central index remapping as it goes. The problem comes in when the mapping isn't applied somewhere, and then we get a fun invisible bug. The external data mappings themselves might be prone to this, I'm not sure. I think I'm going to just take this code out, and then make the savegames completely binary as part of 0.900. |
|
|
Thanks! * The default serialization style for things the game saves is now Byte arrays rather than the char arrays. This will make savegames vastly smaller than before, although not as legible (as if they were before) to edit by hand. ** This is great for a variety of practical reasons, but among them it causes fewer transient garbage collector allocations. And it also makes it so that large integer numbers are no longer something that make the savegame larger. Rather than one char's worth of bytes per digit in the number (1-6 bits, per UTF-8 specs), it now just has a fixed 4 bytes for the number regardless of how many digits it has. ** This breaks all the previous savegames, but they were already broken anyway. ** Player profiles and settings are still using char arrays so that they can be edited by hand as desired. * There was previously a "too smart for our own good" method for "compacting" integers down that were used as primary keys. This could cause all sorts of bugs when used incorrectly, and aside from known bugs that this fixes, we happened to see a few other bugs in passing as we were removing it. ** Note that this was needed almost exclusively because of the char arrays serialization that we were using. Now that we're using byte arrays, this compacting is not just bug-prone it's actually not any more efficient in the first place. So it's really good to have that out of there in general. |
|
|
Also given that people were still having to compress late-game saves in order to upload them to mantis, I think this is definitely a good call |
|
|
Yeah, I wanted to do this for a while, but it was going to be a real pain not breaking existing savegames. So this works out ideally here. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Mar 20, 2019 10:26 am | DEMOCRACY_DEMOCRACY | New Issue | |
| Mar 20, 2019 10:26 am | DEMOCRACY_DEMOCRACY | File Added: weird cap thing.jpg | |
| Mar 20, 2019 10:26 am | DEMOCRACY_DEMOCRACY | File Added: 17 of 15.save | |
| Mar 20, 2019 10:26 am | DEMOCRACY_DEMOCRACY | File Added: 17 of 15.savemet | |
| Mar 20, 2019 10:26 am | DEMOCRACY_DEMOCRACY | File Added: interesting.save | |
| Mar 20, 2019 10:26 am | DEMOCRACY_DEMOCRACY | File Added: interesting.savemet | |
| Mar 20, 2019 10:26 am | DEMOCRACY_DEMOCRACY | File Added: ok then.save | |
| Mar 20, 2019 10:26 am | DEMOCRACY_DEMOCRACY | File Added: ok then.savemet | |
| Mar 20, 2019 11:12 am | BadgerBadger | Note Added: 0050999 | |
| Mar 20, 2019 11:12 am | BadgerBadger | Assigned To | => Chris_McElligottPark |
| Mar 20, 2019 11:12 am | BadgerBadger | Status | new => assigned |
| Mar 20, 2019 3:25 pm | Chris_McElligottPark | Note Added: 0051001 | |
| Mar 21, 2019 10:18 am | Chris_McElligottPark | Status | assigned => resolved |
| Mar 21, 2019 10:18 am | Chris_McElligottPark | Resolution | open => fixed |
| Mar 21, 2019 10:18 am | Chris_McElligottPark | Fixed in Version | => BETA 0.850 The Arrival of Fleets |
| Mar 21, 2019 10:18 am | Chris_McElligottPark | Note Added: 0051027 | |
| Mar 21, 2019 10:22 am | BadgerBadger | Note Added: 0051028 | |
| Mar 21, 2019 10:25 am | Chris_McElligottPark | Note Added: 0051029 |
