View Issue Details
ID | Project | Category | Date Submitted | Last Update | |
---|---|---|---|---|---|
0024252 | AI War 2 | Bug - Gameplay | Dec 20, 2020 7:27 am | Dec 21, 2020 2:16 pm | |
Reporter | NRSirLimbo | Assigned To | Chris_McElligottPark | ||
Status | resolved | Resolution | fixed | ||
Product Version | 2.707 Thread Tracking And Lost Planets | ||||
Fixed in Version | 2.708 Mapgen For Multiplayer | ||||
Summary | 0024252: CPA Speed group with 25479 speed raiders | ||||
Description | That's a very, very fast raider... Save included. Has a few mods, but nothing code-style. | ||||
Tags | No tags attached. | ||||
|
|
|
It's not just raiders in CPA. It's all units in CPAs and Warden Fleets. Nothing like seeing super-fast pulsar tanks, v-wings, and assault frigates right at your door. |
|
Chris, the things discussed here use Speed Groups; I seem to remember you making some speed group changes recently? |
|
I did make some changes, mainly in how they were going to be applied across to multiplayer, etc. I can take a look at this and see what is going on. When I was making my changes, I noted there were some points where speed groups were being created but never stored anywhere permanent (on the faction, for instance), so that was causing some oddities when you reload a game in single player, or when it transmitted the data in multiplayer. I think I explicitly chose not to fix that and marked that code, instead, though, since I didn't want to change anything that would cause issues. Other than that, it's mostly been a matter of fixing potential errors that can happen. I'll be curious to see what this turns out to be when I dig into it. |
|
I wasn't aware that speed groups needed to be stored someplace in particular. Has it always been thusly? |
|
Yep, it's always been that way. Speed groups don't get serialized unless they are stored at the faction object. Serialization is in general a top-down process, where the world has references to things, which have references to sub-things, and those have sub-things, and in some cases we have cross-links to other things. Speed groups are one of those items that are tricky, because all of their "things" are ships that are actually already serialized elsewhere. So mainly a speed group is just an ID, a speed limit, and then a list of ships. We need to store that somewhere, because it's a unique set of data -- putting it as a sub-object of ships, for instance, would lead to 100 copies of it for 100 ships in a single speed group, or other oddities. From an object reference standpoint while running the game, a speed group can just be linked to ships, though, which is what was happening. So it would never get serialized, because nothing central had a link to it, but all of the ships could do their work just fine and so as long as you didn't save and reload you'd never see the problem. |
|
Thanks! This is probably a big part of it: * Fixed up the CalculateSpeed() method on the CPA logic to handle a couple of thins: ** Firstly, we no longer base it on the CalculatedSpeed of each ship, because that can include a lot of temporary things like paralysis, or it can include things that are temporary boosts (like existing speed groups), or it can even be 0 if nothing has been calculated yet. *** It was possible in the prior code that if multiple speed groups were created in succession that included some ships that were all of one type, that the average speed would rise each time, eventually leading to truly absurdly high speeds. ** Secondly, we are now using 64bit math to calculate the average speed just in an abundance of caution, since if the speed group is large enough it could otherwise overflow and theoretically cause very strange results. We doubt this was happening, but it's nice to have in place. ** Lastly, when the "average speed plus a little" is fully calculated for a speed group with a CPA, it now makes sure that it is not higher than the maximum speed of any ships in the group. Previously, it was possible for a mono-type group to always get a boost of 1/9th their speed, plus 200 if the game was far enough in, plus up to 50 just for the sake of randomness. Now that will cap out at the actual speed of the ship type in question. ** We're guessing that this was the cause of the hyper-fast speed groups that a few people were seeing from CPAs, but it's hard to be sure. If this fixes it, then this simply means that the code for setting the overriding speed of speed groups was not working properly in the past, which is something we may have fixed recently. |
|
Thanks! * In order to avoid having existing savegames with excessive speed group speeds running around, during the load off of disk it now checks the overriding speed limit against the max speed of all the ships in the group, and if the max speed is lower it sets that as the new speed group for that speed group. |
Date Modified | Username | Field | Change |
---|---|---|---|
Dec 20, 2020 7:27 am | NRSirLimbo | New Issue | |
Dec 20, 2020 7:27 am | NRSirLimbo | File Added: 25479 speed group.save | |
Dec 20, 2020 7:27 am | NRSirLimbo | File Added: 25479 speed group.savemet | |
Dec 20, 2020 7:27 am | NRSirLimbo | File Added: 20201220132642_1.jpg | |
Dec 20, 2020 1:28 pm | Crabby | Note Added: 0060097 | |
Dec 20, 2020 2:36 pm | BadgerBadger | Assigned To | => Chris_McElligottPark |
Dec 20, 2020 2:36 pm | BadgerBadger | Status | new => assigned |
Dec 20, 2020 2:37 pm | BadgerBadger | Note Added: 0060098 | |
Dec 21, 2020 11:28 am | Chris_McElligottPark | Note Added: 0060107 | |
Dec 21, 2020 11:29 am | BadgerBadger | Note Added: 0060108 | |
Dec 21, 2020 11:34 am | Chris_McElligottPark | Note Added: 0060109 | |
Dec 21, 2020 2:05 pm | Chris_McElligottPark | Note Added: 0060120 | |
Dec 21, 2020 2:16 pm | Chris_McElligottPark | Status | assigned => resolved |
Dec 21, 2020 2:16 pm | Chris_McElligottPark | Resolution | open => fixed |
Dec 21, 2020 2:16 pm | Chris_McElligottPark | Fixed in Version | => 2.708 Mapgen For Multiplayer |
Dec 21, 2020 2:16 pm | Chris_McElligottPark | Note Added: 0060121 |