Jump to content

wulf 21

Members
  • Content count

    64
  • Joined

  • Last visited

  • Days Won

    2

wulf 21 last won the day on February 12

wulf 21 had the most liked content!

Community Reputation

17 Good

1 Follower

About wulf 21

  • Rank
    Squaddie
  1. This thing I metioned in other threads when I was playing around with savefiles nearly drove me mad for some time . Because I kept being reset to earlier game states while testing and wondered if I really did press that F5 button or forgot it? But now I did do it in a way that makes it clear for me this is actually happening and made a screenshot each step. And I intentionally did not use the quicksave for it, so I wouldn't have to ask myself what I really pressed after that. made sure I had no preexisting savefile named test (deleted them) started the game from desktop, started a new game and placed my base in Latin Americe (Screenshot 1) saved the new game as "test" (Screenshot 2) quit to desktop started game from desktop again, started a new game and placed my base in Asia Pacific (Screenshot 3) saved the game as "test" again and confirmed the question if it should overwrite the savefile (Screenshot 4) loaded the "test" I did just create (Screenshot 5) ... aaaand magic! the base was suddenly back in Latin America (Screenshot 6) quit to main menu, then loaded the savefile again (Screenshot 7) ... and the base STILL is in Latin Americe (Screenshot 8) - so if you stop here you could think that game failed to actually save, but it gets better quit to desktop load "test" again and here comes the real magic: The base is suddenly in Asia Pacific, right where it was before saving the test a second time! (Screenshot 9) So I think what really happens here is that for loading savefiles there was used some part of code that is intended for files that stay unchanged during the whole runtime of the game (like sprites, sounds, models). So upon accessing the save directories on game start, the engine just thinks "let's load these small files into cache right now, might save time if I need them later". And upon loading the file it would then just load what was already in RAM and never access the file system again to load the actual file, so it appears like the savefile was not saved again until quitting the game to desktop again. Screenshot 1: Screenshot 2: Screenshot 3: Screenshot 4: Screenshot 5: Screenshot 6: Screenshot 7: Screenshot 8: Screenshot 9:
  2. wulf 21

    [V 2.0 - General] Bug Load Game

    Could it be that this and the other thread actually have a common root cause? Because, 1 time after exchanging interceptor equipment on the aircraft screen and then shooting down a UFO, I got both bugs: I first saved while the drophip was on the way to crash site then after completing the ground mission, game crashed when I tried to load the save, I found it was broken At this time I thought of it an coincidence and did not report it again (and no longer have the savefile). But after trying around a bit, it seems that going to the aircraft screen and back seems to be a reliable way to cause not-loadable savefiles. Here are 2 of them test.json does load perfectly well. test2.json will be stuck on loading. The only action between saving those files was going to the aircraft equipment and back. Interestingly the second file is much smaller despite that. This got me interested and I took a look at the actual content of the savefiles and saw that it misses the whole "ComponentMatrix" part. So maybe the same part of wrong data that makes the game crash on loading back from ground combat actually makes creation of this part of the savefile impossible?
  3. One of the planes got stuck and I finally figured out how it happened. It requires some precise timing and hopefully can be reproduced with my savefiles: load the dropship_launched.json it contains a dropship en route to the crashsight and an interceptor on way back to base fast forward time (speed 2 or 3) If it happens you will see the dropship reaching the crashsight slightly before the interceptor reaches his home-base. Then the dropship bounces back-and-fouth around the crashsight a bit. While this is happening, the interceptor symbol disappears from screen (like it landed). Then the ground mission starts to load. Finish the ground mission (Just abort it for testing) After return to geoscape and confirmation of mission result, the plane will be stuck The plane is than on the same location as its base but it will not move. It is unclickable (nothing happens if plane, not base is clicked). On Plane Tab it will display the stats from before ground mission loaded (fuel is not empty). So it looks like there actually happen some frames while Geoscape data is prepared for loading it back after ground mission. If one during these frames contains a transition from airborne to landed state, plane will be stuck in some in-between state. It will only happen on the fast forward speeds 2 or 3 - it did not happen if I tried maximum speed. Since it may actually be nearly frame-perfect, I checked with fraps that the Geoscape was running with around 99 fps while it happened. While it is stuck, it was trunning at 150 fps (so it was calculating faster, probably no calculations for the stuck plane done). Furthermore here are my specs should they be needed for this: CPU: Intel Core 2Quad Q9400 @2.66 GHz, GC: NVidia GeForce GTX 570, 6 GB RAM - Game installed on a HDD, but windows on an SSD (so the Xenonauts savefiles are there). Savefile after that: plane_stuck.json Screenshot with the stuck plane (the squadron 2 on the North America Base):
  4. Found yet another way to crash the game: launch an interceptor click the base it was launched from click the hangar of the interceptor click disband click yes Looks lie some part of the code then destroys the entity while another part that does the flying still tries to update it. 2019-02-03 22:12:46,137 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\Strategy\Systems\Geoscape\WaypointSystem.cs:31) Delete Waypoint 277:Waypoint 2019-02-03 22:12:46,146 [FATAL] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\XenonautsMain.cs:441) A fatal error occurred during Update() - System.Exception: Entity 261 was deleted and cannot be modified after destruction. Please use IsAlive() when modifying. Mutation: null into Common.RPG.RangeModifierStorageComponent at Artitas.World.MutateComponentOnEntity (Int32 entityID, Int32 componentID, IComponent previousC, IComponent nextC, Boolean added) [0x0003d] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:297 at Artitas.Entity.Add (IComponent newComponent, Int32 componentId) [0x00017] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Entity.cs:57 at Common.RPG.ModifierSystem.HandleRangeModifier (Artitas.Entity target, Common.RPG.Modifier`1 modifier, Boolean added, Int32 storageComponentIdx, System.Collections.Generic.Dictionary`2 modificationStrategies, Common.RPG.ModificationStrategy`1 defaultModificationStrategy, Common.RPG.ApplicationStrategy`1 applicationStrategy) [0x00020] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Gameplay\RPG\ModifierSystem.cs:209 at Common.RPG.ModifierSystem.Handle (Common.RPG.ModifierEvent event) [0x0005c] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Gameplay\RPG\ModifierSystem.cs:105 at (wrapper delegate-invoke) System.Action`2<Common.RPG.ModifierSystem, Common.RPG.ModifierEvent>:invoke_void__this___ModifierSystem_ModifierEvent (Common.RPG.ModifierSystem,Common.RPG.ModifierEvent) at Artitas.Core.Utils.ExpressionUtil+<ActionFromMethodInfoFactory>c__AnonStorey1`4[Artitas.Systems.EventSystem,Common.RPG.ModifierEvent,Common.RPG.ModifierSystem,Artitas.IEvent].<>m__0 (Artitas.Systems.EventSystem target, IEvent param) [0x0001c] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Utils\ExpressionUtil.cs:151 at Artitas.Systems.EventSystem.HandleSubscribers (IEvent event) [0x00050] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Systems\EventSystem.cs:49 at Artitas.Systems.EventSystem.Handle (IEvent event) [0x00003] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\Systems\EventSystem.cs:26 at Artitas.DefaultProcessStrategy.Process (IEvent event) [0x001c6] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:830 at Artitas.DefaultProcessStrategy.Process () [0x00024] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:773 at Artitas.World.Process () [0x00007] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:643 at Common.Screens.DataStructures.WorldManagedScreen`2[Xenonauts.GameScreens,Common.Screens.DataStructures.IScreenParameters].Update (Single deltaTime) [0x00032] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Lifecycles\ScreenLifecycle\DataStructures\WorldManagedScreen.cs:49 at Common.Screens.ScreenManager`1[Xenonauts.GameScreens].Update (Single deltaTime) [0x000f3] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Lifecycles\ScreenLifecycle\ScreenManager.cs:149 at Xenonauts.XenonautsMain.Update () [0x00066] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\XenonautsMain.cs:438 Attached: output.zip
  5. Reproducable with following save-file (after researching comba armor): combat_armor_researched.json go to engineering screen add one combat armor to queue. Result: 160$ left. Quantity-up-button not greyed out and quantity-down-button greyed out - OK (Screenshot 1) click quantity-up 1 time. Result: Quantity is 2. Only 60$ left. Quantity-down button not greyed out but quantity up-button not greyed out either - NOK, expected: quantity up should be greyed out because not enough money (Screenshot 2) click quantity-up again. Result: nothing happens - OK click quantity-down. Result: Quantity is 1. Again 160$ left. Quantity-down and up are both greyed out - NOK, expected: quantity-up should not be greyed out because there is enough money to increase it (Screenshot 3) click quantity-up - Result: nothing happens - NOK, expected: it should be possible to increase quantity as we have the met prerequisites So it looks like the piece of code that determines if we met the prerequisites to increase quantity (and greys out the button if not) actually uses the prerequisite state from before the quantity change, not the state after. As a workaround, it is possible to remove the item completely from queue and add it again, then quantity can be changed up again. Another note: If the add combat armor is clicked 2 times with queue empty, it would add 2 lines: 1xcombat armor, 1x combat armor instead of 2x combat armor. I suppose this is not a bug since the player could have the intention to produce for example item A, item B, item A instead of 2x item A, item B. However it would make kind of sense if the add project button would increase quantity instead if it is the same project that is already at the end of the list. Screenshot 1: Screenshot 2: Screenshot 3:
  6. Had this happen in V2.0 today. However it happened after getting shot by alien for me instead of a self-kill, so it looks like it will appear randomly on Xenonaut death. Might actaully be the same glitch as dead alien standing upright after death - So I additionally did send an F11-report that was asked for in these threads. Edit: the character to the right the alien is looking at with the blood is the one that is actually dead.
  7. It is still in V2.0. And it affects civilians as well as aliens. I don't know if I just did not notice that earlier or something was changed in this version but: As soon as the civilian did move out of line-of-sight, the game actually fast-forwarded (like it does for all the hidden movement). So it looked like the civilian was teleported to its final position. For better understanding, I marked the movement path on screenshot. The green path was about the way the civilian moved inside my line-of-sight. The red path was the way he was "teleported" - which is wrong, because I should have no way to know where he is without looking there. (Small OT: Game Design wise it would make kind of sense to leave a transparant ghost to mark a position where NPCs was last seen - but giving the player an information he should not have is clearly a bug). Reported that instance of the bug with F11 aditionally. (Maybe there is some useful information in that auto-collected data)
  8. Seems this specific crash was not fixed, yet in Build V2.0. It happened to me a second again, this time I was firing with machine gun. Crash did happen right before impact of first projectile again, 3 Projectiles were already in the air, so maybe it happened when the fourth projectlie should be fired. It is the same part of the code where it happened again: 2019-02-03 12:05:16,529 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:631) Handled AnimatorStateEvent<global::Xenonauts.GroundCombat.Animations.CombatantStateTransitionListener.Tags>: AnimatorStateEvent<CombatantStateTransitionListener.Tags> ( Trigger: OnEnter, Payload: Idle, Actor: (Clone) (Xenonauts.GroundCombat.Animations.CombatantStateTransitionListener), StateName: StandingIdle, Payload: Idle, Behaviour: 6100 ), Info: 1305036771 2019-02-03 12:05:16,561 [WARN] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\GroundCombat\Factories\Abilities\Shoot\Projectile.cs:372) Ignoring because target impact entity was destroyed. 2019-02-03 12:05:16,562 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:616) Queued global::Xenonauts.GroundCombat.Events.ProjectileMissEvent: Projectile Event (ProjectileMissEvent - Projectile TrajectoryMissOffBoard (rolled 89% (<= is success) against 14.84%) on -1 from (19.3, 0.8, 33.0) to (16.4, 0.0, 25.7) ([F:0, I:33, J:51] / [X:16, Y:0, Z:25], ID:6612 Type:Centre), impacted at: [F:0, I:33, J:51] / [X:16, Y:0, Z:25], ID:6612 Type:Centre) 2019-02-03 12:05:16,596 [INFO] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:616) Queued global::Xenonauts.GroundCombat.Events.ShakeCameraCommand: Camera: GlobalEntity 881 2019-02-03 12:05:16,603 [FATAL] (D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\XenonautsMain.cs:441) A fatal error occurred during Update() - System.NullReferenceException: Object reference not set to an instance of an object at Xenonauts.GroundCombat.Abilities.FirearmAbility.FireProjectile (Common.RPG.AbilityState state) [0x00055] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\GroundCombat\Factories\Abilities\FirearmAbility.cs:721 at Xenonauts.GroundCombat.Abilities.FirearmAbility+<AnimateShotsTimeline>c__Iterator0.<>m__1 (Common.RPG.AbilityState state, IEventEffect`1 effect, Artitas.Events.DeltaTimeEvent arg3) [0x00001] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Screens\GroundCombat\Factories\Abilities\FirearmAbility.cs:668 at Common.RPG.DelegateSingleEventEffect`2[Common.RPG.AbilityState,Artitas.Events.DeltaTimeEvent].Apply (Common.RPG.AbilityState state, IEvent event) [0x0000f] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Gameplay\RPG\Ability\Effects\EventEffects.cs:119 at Common.RPG.SequenceEffect`1[Common.RPG.AbilityState].Apply (Common.RPG.AbilityState state, IEvent event) [0x0004e] in D:\Jenkins\workspace\X2 (Build)\release-0.37.0\Assets\Code\Libraries\Common\Code\Gameplay\RPG\Ability\Effects\CompositeEffect.cs:154 Attached output.zip
  9. Hi, found this small visual bug. I think it did not appear before because we did not have the MIMIC UFOs before: It will appear if you win an air combat on Geoscape (not autoresolve), and then directly go into next air combat without ground missions etc in between. Then there will be displayed a ghost fighter at the position where you ended the air combat before:
  10. Thanks for the update. I Like the new Music. Nice seeing some things that were suggested already being put into the game
  11. To rule out that there is any interference with previous savefiles here, I actually renamed my safe folder before. So we starte emty. What I did: Start game without having a Save-folder Start new game Accept initial report dummy place initial base Press F5 - quick_save.json (was only save in saves dir after whole process) Quit the game to Desktop Start the game again Click "Continue" Go to Armory Result: there are no items in Armory except the ones you are carrying - all the infinite items are gone away the loadout selection is broken Edit: if you go on a ground combart mission with the already equipped items and finish it, armory goes back to normal when loading to geoscape, so maybe that's why it was unnoticed... Edit2: happens with normal savefiles, too. dragging one of the items to the right does not let them appear again. They are then lost, until next ground mission. This essentially means that every time I continue a saved game from before, I will be stuck with current squad equpment until after next ground mission after ground combat, actually only the infinite items are back - loadout selection will stay broken
  12. wulf 21

    [V 2.0 - General] Bug Load Game

    Had this, too. Not sure how to reproce. Here is the broken save file: quick_save_broken.json (I did rename the quick save after realizing it was broken) Screenshot where game is stuck:
  13. Still happens in V2.0. Turns out you don't even need an empty hangar to trigger this, just: start new game place initial base click the base click the squadron click "relocate" - it will offer you only the 1 hangar in existence click authorize relocation Screenshot of broken interface (note how the base is completely missing in the radar circle):
  14. I can still reproduce this in V2.0 The only modification to reproduction steps is in Step 12, it is now "Total of 3 in there now - 3 slots from the left used" - because 1 engineer now starts in radar. The slot that gets broken is now the 3rd from the left because of that. Another quick note: On first try after starting up V2.0 without having any V2.0 saves created before, only old saves, the game did not load the new quicksave with F9 in step 14. Looking into the ESC-menu, the Qicksave was was displayed as Version "0.0.0" despite being new. I had to use the save menu and save a test.sav, after loading it the issue was in the test.sav. Strangely enough, after loading the test.sav the quicksave now was displayed as Version "0.37.0" and it was possible to load it. It seems there is some strage thing that lets the game mix up partial information from saves that were loaded into RAM before saving again with information from the actual save files... Quicksave from V2.0 with broken slot inside: quick_save.json Screenshot with broken slot marked as it looks in V2.0. Living capacity still 15/16 despite having 16 personell before saving in step 13:
×