View Issue Details
| ID | Project | Category | Date Submitted | Last Update | |
|---|---|---|---|---|---|
| 0022353 | AI War 2 | Crash/Exception | Dec 11, 2019 10:29 am | Dec 11, 2019 7:37 pm | |
| Reporter | razgrizh | Assigned To | Chris_McElligottPark | ||
| Severity | crash | ||||
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.014 High AIP Playstyle Viability | ||||
| Fixed in Version | BETA 1.015 Testing The Outguard Waters | ||||
| Summary | 0022353: Game breaking bug - Friendly Marauder | ||||
| Description | Game mode: 1-Basic (Helping Hands The state of the campaign is with at least 75% of the galaxy in friendly marauder's hand. The performance is going slow probably for the number of ships in the map from the marauders. The actual game breaking though can be recreated in the save i've uploaded in exactly 24 seconds after running the simulator. The save has 2 hours and 46 minutes. After it arribes at 2h:46m:24s a marauder fleet error starts appearing and the game simulator stops working. Making imposible to finish the game. The arcen debug log file shows the error that appears continuosly. | ||||
| Tags | No tags attached. | ||||
| related to | 0022336 | resolved | BadgerBadger | Every-Second-Slowdowns |
| related to | 0022262 | resolved | BadgerBadger | Simulation performance degrade way too much |
|
|
|
|
|
12/11/2019 4:11:45 PM Error during CreateNew on squad, FleetMembership was never set for type MarauderVWing, GetIsFleetLeader(): False, skipNormalFleetMembershipAdditions: False at System.Environment.get_StackTrace () [0x00000] in <1f0c1ef1ad524c38bbc5536809c46b48>:0 at Arcen.Universal.ArcenDebugging.ArcenDebugLog (System.String Message, Arcen.Universal.DebugLogDestination Destination, System.Boolean IncludeStackTrace, Arcen.Universal.Verbosity Verbosity) [0x00000] in <6dcef55f41164a6bae53c252ffa99015>:0 at Arcen.Universal.ArcenDebugging.ArcenDebugLog (System.String Message, Arcen.Universal.DebugLogDestination Destination, Arcen.Universal.Verbosity Verbosity) [0x00000] in <6dcef55f41164a6bae53c252ffa99015>:0 at Arcen.Universal.ArcenDebugging.ArcenDebugLog (System.String Message, Arcen.Universal.Verbosity Verbosity) [0x00000] in <6dcef55f41164a6bae53c252ffa99015>:0 at Arcen.AIW2.Core.GameEntity_Squad.CreateNew (Arcen.AIW2.Core.PlanetFaction PFaction, Arcen.AIW2.Core.GameEntityTypeData TypeData, System.Int32 CurrentMarkLevel, Arcen.AIW2.Core.Fleet FleetOrNullIfNotShip, System.Int32 UniqueTypeDataDifferentiatorForDuplicatesOrZero, Arcen.Universal.ArcenPoint StartingLocation, Arcen.AIW2.Core.ArcenSimContext Context) [0x00000] in <ecd6d0ef6f9c48889c941b70e34d0290>:0 at Arcen.AIW2.Core.Faction.SpawnNewUnit (Arcen.AIW2.Core.ArcenSimContext Context, Arcen.AIW2.Core.Planet Planet, Arcen.Universal.ArcenPoint Location, Arcen.AIW2.Core.GameEntityTypeData TypeToSpawn, System.Int32 MarkLevelToSpawnOrNegativeOne, Arcen.AIW2.Core.Fleet FleetIAmIn, System.Int32 UniqueTypeDataDifferentiatorForDuplicatesOrZero, Arcen.AIW2.Core.EntityBehaviorType Behavior, System.Int32 BehaviorRelatedFactionIndex, Arcen.AIW2.Core.GameEntity_Squad GuardedObject) [0x00000] in <ecd6d0ef6f9c48889c941b70e34d0290>:0 at Arcen.AIW2.Core.Fleet.DeployDroneContents (Arcen.AIW2.Core.ArcenSimContext Context) [0x00000] in <ecd6d0ef6f9c48889c941b70e34d0290>:0 at Arcen.AIW2.Core.GameEntity_Squad.DeployDroneContents (Arcen.AIW2.Core.ArcenSimContext Context) [0x00000] in <ecd6d0ef6f9c48889c941b70e34d0290>:0 However the XML says <entity skip_export="true" copy_from="VWing" name="MarauderVWing" special_entity_type="DroneGeneral" self_attritions_X_percent_per_second_if_parent_ship_not_on_planet="1" description="Inexpensive and short ranged, adept at shielding allies and chasing down fleeing hostiles. These V-Wings are spawned by Marauder Outposts and will only defen\ d those Outposts." starting_mark_level="Mark1" tech_upgrades_that_benefit_me="Unused" exp_to_grant_on_death="-1" > <fleet_membership name="MarauderDrones" ship_cap_group="Strike" weight="100" min="20" max="20"/> </entity> |
|
|
Chris, the save game definitely reproduces the problem, just give it a minute or two. I also see errors for Error during CreateNew on squad, FleetMembership was never set for type MarauderFusionBomber, GetIsFleetLeader(): False, skipNormalFleetMembershipAdditions: False when I tested it. |
|
|
In this case, the bug is that it's trying to add the drone to be a part of the fleet of the thing that spawned it. But the thing that spawned it probably died in the interim. I've put in some more debugging, and am making it use the fleet of the drone counter if the centerpiece of that fleet has a null fleet. I was able to duplicate the bug, so I'm waiting to see if this fixes it. This savegame is kind of shockingly slow with whatever is going on with the marauders, it's troubling. |
|
|
Got it: * Fixed a concerning and nonsensical bug where the same ship was attempting to be added to a fleet more than once on creation, but then not winding up in the fleet at all from its own point of view, thus spewing errors. ** This may ultimately be part of some much larger issue with pooling of units -- potentially one that happens specifically when the simulation is running agonizingly slowly for whatever reason. |
|
|
Yeah, it's quite slow but I'm not sure why. I made the Marauder Stage 3 sim code (where most of the Sim stuff happens) and the marauder long range planning code into noops by adding a return statement right after the function started and it doesn't impact the performance numbers. There are a total of 1330 distinct marauder raiders (a lot more if you count the stacks), which doesn't seem excessive. |
|
|
Part 2: * It is possible to get ships trying to set a pursuit target for a higher weapon system index than they actually have, mainly if the ship somehow changes type while maintaining its ID between the autotargeting and the finalized logic. This again shouldn't be possible, but seems to happen now in the same savegame where the other concerning bug just was. Now it won't complain about these, but will just ignore the bad data. |
|
|
Yeah, the unit count is not impressive. I am thinking that perhaps we have a situation where drones are being deployed a lot and then packed back in or something. But also it seems to be getting absolutely confused about what units are what and where, which is very confusing. |
|
|
So there are 300 or so Outposts. If I blow them all up then the game goes up to full speed (I just added an entity.Die() call to the sim code for marauders). But the slowdown is not in the Marauder Sim code, since disabling the Marauder Sim code doesn't have any performance change. |
|
|
Working on this: * Put in some new counts in the escape menu's performance section that show the number of drones deployed and recalled, and the number of ships added into fleets and taken back out of them, as well as the number of failures of each. ** As it turns out, in the strange savegame with bad performance of marauders, there are TONs of ships that are failing to be re-added properly, and drones popping in and out constantly. So this gives us something to work with on why it's so slow. |
|
|
Badger, your fix to making marauders not deploy when not enemies are on the same planet worked! |
|
|
Closing this out fully: * Removed the always_deploy_drones tag, since there is logic that causes drones to auto-recall if there are no enemies nearby. This was causing drones of marauder outposts to go in and out of the outposts constantly and rapidly, tanking performance previously. Anyone else who used the same logic was going to run into the same thing. ** The savegame that previously ran SUPER slowly, aka about 2% of normal, now runs at 70-80% of normal instead. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| Dec 11, 2019 10:29 am | razgrizh | New Issue | |
| Dec 11, 2019 10:29 am | razgrizh | File Added: ArcenDebugLog.txt | |
| Dec 11, 2019 10:29 am | razgrizh | File Added: Campaign 1 broken.save | |
| Dec 11, 2019 11:05 am | BadgerBadger | Note Added: 0054932 | |
| Dec 11, 2019 11:07 am | BadgerBadger | Note Edited: 0054932 | |
| Dec 11, 2019 11:07 am | BadgerBadger | Assigned To | => Chris_McElligottPark |
| Dec 11, 2019 11:07 am | BadgerBadger | Status | new => assigned |
| Dec 11, 2019 1:33 pm | BadgerBadger | Note Added: 0054938 | |
| Dec 11, 2019 4:48 pm | Chris_McElligottPark | Note Added: 0054940 | |
| Dec 11, 2019 5:06 pm | Chris_McElligottPark | Note Added: 0054941 | |
| Dec 11, 2019 5:07 pm | BadgerBadger | Note Added: 0054942 | |
| Dec 11, 2019 5:11 pm | Chris_McElligottPark | Status | assigned => resolved |
| Dec 11, 2019 5:11 pm | Chris_McElligottPark | Resolution | open => fixed |
| Dec 11, 2019 5:11 pm | Chris_McElligottPark | Fixed in Version | => BETA 1.015 Testing The Outguard Waters |
| Dec 11, 2019 5:11 pm | Chris_McElligottPark | Note Added: 0054943 | |
| Dec 11, 2019 5:13 pm | Chris_McElligottPark | Note Added: 0054944 | |
| Dec 11, 2019 5:21 pm | BadgerBadger | Note Added: 0054946 | |
| Dec 11, 2019 5:32 pm | Chris_McElligottPark | Note Added: 0054948 | |
| Dec 11, 2019 5:42 pm | Chris_McElligottPark | Note Added: 0054950 | |
| Dec 11, 2019 5:57 pm | Chris_McElligottPark | Note Added: 0054951 | |
| Dec 11, 2019 7:35 pm | BadgerBadger | Relationship added | related to 0022336 |
| Dec 11, 2019 7:37 pm | BadgerBadger | Relationship added | related to 0022262 |
