Jump to content

wulf 21

Members
  • Posts

    248
  • Joined

  • Last visited

  • Days Won

    8

Everything posted by wulf 21

  1. I guess you don't see resolutions that are bigger than your actual screen size but what you might see is 1600x900 which has the same ratio as my screen (16:9). Maybe you can try that. That said, ofc. it is a bug that needs to be fixed by the devs. I mainly intended this reply as an additional info, so they can find the issue more quickly, not as a permanent solution.
  2. Yet another occurence where human soldier is affected. It was same pattern again ie. soldier was hit and I got the message that this soldier is bleeding right after hit very shortly (but not on new turn). During mission actually only 2 Xenonauts survived, yet, 3 were displayed as alive after mission. This time I noticed the affected soldier was actually loosing only a little more than 20 HP on alien hit, so not nearly enough to kill her. I am pretty sure the health bar of Michelle Davis actually depicts how much max HP she had left after "killed". (I know that Samantha Ross and Zhao Mengjie were really not killed as one is visible in screenshot after it happened and I know my sniper survived). After it happened I loaded the savefile from before the mission and saw she was one of the soldiers that actually started the battle wounded already (last 2 screenshots). Reported that instance with F11 additionally. So I think what's happening is that some calculation that decides if a soldier will be dead after the hit is wrong in some cases where the "current max hp" (or whatever it's called, I mean the HP value to which a soldier can be healed back up during mission) is significantly lower than the absolute max hp. It may be that the same thing might happen on sebillian. Now that I think about it, it could be that it was only happening after a sebillian already did regenerate for one turn (so it already had its "current max hp" lowered before the "kill"). It might be the reason why it does not happen for psyons - as they arent regenerating and do not heal each other, such value is probably not implemented for them in the first place (or it is there, but never lowered). During mission (soldier with blood is "killed") After Mission: Screenshots from savefile before mission:
  3. There is a bug report subforum already, which makes it more easily to see what already was reported. The Lock-up-issue you mentioned is there since version 1 (but since they didn't find the reason and fix it, yet, I guess the more info the better. It just makes it easier to find if all the info regarding a specific bug is in one thread.) Regarding the suggestions 1: Yes, Id definitely like more camera angles, too during the action, too. 2: Was like that in first closed beta builds, but the devs are still playing around with game mechanics a bit. They removed the main base location from the geoscape in V3.0, so now the location stays hidden and the skyranger can just teleport to the mission location. Maybe they'll put it back in if people like it more. I personally had this paranoid feeling about troop transports only very shortly in X1, until I found out that UFOs spawn in waves and fighters would always actively move in to attack my aircraft. So I just launched my fighters first and if during a day of air combat no alien fighters appeared anymore, I could be 99% sure nothing would attempt to shoot down the troop transports, problem solved... 3: Sounds good.
  4. I dont get this issue on 1920*1080 (16:9) pixel resolution. Issue seems to be related to 1680 * 1050 (16:10) screen resolution.
  5. On the first crashsite mission in new hotfix I got a large UFO in the mission after shooting down a proble UFO in arctic region (Screenshot 1). However, despite loading the big UFO, it was still just crewed like the probe (just 6 sebillians on the map). And post mission I got the message the I recovered a probe ufo data core. (Screenshot 2). I'll attach the savefile, however for testing, I loaded the savefile again (see crashsite info in screenshot 3) and sprinted right to the UFO and saw that the correct one was loaded this time (Screenshot 4). So either it is completely RNG (where it "decides" on mission load wether bug happens), or otherwise it always loads correct UFO from savefiles but it can be wrong directly after shooting it down (I think on first try, I shot down UFO, prepared equipment, made the savefile and started the mission without loading the save). Savefile: first crashsite.json Screenshot 1: Screenshot 2: Screenshot 3: Screenshot 4:
  6. Not sure if I understand this correctly. You can switch between primary and secondary weapon without TU cost at the end of turn and whatever weapon was selected will be used for overwatch (if enough TU left to shoot). Granted it is a little awkward to use as clicking secondary weapon will automatically put you in force fire mode where you need to ESC out from if you just wanted to select it for overwatch. Or do you actually mean that the soldier should do this automatically? For example sniper that has not enough TU for sniper shot but enough for SMG snapshot should automatically switch to the SMG and shoot that if an alien appears, or maybe some soldier being left with medpack selected at end of round automatically pulling out primary gun if needed. Not sure if I'd like such feature - it kind removes the task to think about what could happen on alien turn and plan ahead accordingly from the player, if the soldier just auto-decides the best action in overwatch.
  7. That civilan somehow has wrong idle animaion. It looks like he is continuously starting to fall over and jumping at the same time, then lands back to ground (not sure what this animation was actually intended for but surely not for idle). It seems only the idle animation though, he looked just fine while moving.
  8. Have one more occurence with a sebillian here. The one with the green blood below in the screenshot was killed by grenade explosion but then regenerated at the same time. However it was still dead (possible to go on same tile, not possible to target). Again mission completed properly right on last alien kill, but one alien was counted as not killed post mission. So again, it seems the not couning as dead part only affects game ending trigger just during round. (i.e. it is not triggered that the game should immediately recheck winning conditions because an alien just died, but when the next check is done anyway, either on new round or last kill, it counts the sebillian as dead and completes the mission)
  9. Tested what happened if a stratop is completed before having the necessary living space. Turns our there is no limit check at all and you just get the scientists/engineers anyway. Of course it would not be good to successfully finish a strat op and not get the reward later - so either the living space for the scientists/engineers needs to be reserved before starting the strat op already (and not allow to start it if there is not enough space) or possibly queue up personnel that is due to arrive at base but will arrive only after the necessary space was built.
  10. As requested in linked thread, I open a new one to discuss the behaviour where a soldier or sebillian would be counted as dead in mission (so other soldier can move onto same tile) but is displayed upright and still can regenerate (sebillian)/bleed(human) and will not be counted as dead after mission. I have startet seeing this behaviour just recently (most likely starting with 3.0) and it seems to happen more frequently than the pure graphical bug (This was maybe one or 2 times per whole closed beta game time playthrough). I did not see it happen on psyon, yet. I had actually one more occurence in Build V3.1 with a sebillian, this time he was out of UFO (did not take any screenshots). It was regenerating after being killed. However the sebillian stayed dead still and the mission ended properly when killing last alien (so not through capture and hold of UFO) but was not counted as dead post-mission. I have one new occurence in Build V3.2 with a human soldier: one of my soldiers was hit on alien turn on being hit, there was displayed message that soldier is not bleeding now from 1 wound (which only makes sense if the game thinks the soldier survived the hit) on my turn however, I no longer had control over the soldier and it was possible to move other soldier onto same tile (First screenshot) I did not receive any further "The soldier is bleeding and looses 5 HP per turn" messages for this soldier after mission however (which was pretty much desaster, only one soldier really survived the mission) the dead but still standing soldier (Jane wilson as it turned out) was counted as alive in the end (Second screenshot) So there seems to be some issue in the code for removing HP per turn (human bleeding) or adding (sebillian regenerating) where some part of game counts the human/sebillian as dead, another part as alive. The alive part only seems to affect GC mission ending triggers during one turn but then carry over to overall mission result seen in Geoscape.
  11. Hmm, what did you do when you ended the game you wanted to return to? Just to make sure you know how the save system works: The continue button will always load the latest savefile. But the quit to main menu or quit to desktop will NOT automatically save the game state to continue. You always need to save manually (either through save menu or through F5-Button) before quitting the game or progress since last save will be lost. There are some points when the game will indeed create an Autosave (like after receiving funding you mentioned), but again, using the quit function does not autosave. Regarding the lockup issue. There is already this thread: There is indeed some issue that the game can lock up during alien turn under some circumstances if an alien drops unconscious in stun gas while doing its move. (and maybe on death through reaction fire, too, but have not seen this yet)
  12. Build V3.1 Can still reproduce. Here is are updated savefiles before_laser_research.json (can be loaded to reproduce as above) Quicksave.json (file with only one laser battery in it) Screens look now a little different (there is actually number 1 displayed next to the laser battery now and it gets zero after dragging it out) - strange thing is I can still reproduce it only one time after loading from desktop - will not reproduce if I try to do it a second time without quit to desktop in between. Maybe you are not attempting to fix it because according to the research dummies the plan is laser weapons should auto-recharge slowly instead of reloading like a normal gun. But it may still point to some deeper issue in the way saving and loading works and pop up again if there is a new ammo type unlocked by research put into the game...
  13. It is somehow happening in V3.1 again. The appearance is the same (civilian and aliens appear to "teleport" to the final location after stepping on first grey tile). Here are some screenshots: I think sometimes is is working as it should - so maybe it was just fixd for the case where NPC is not visible because it is outside of the viewing cone and noth where it is behind obstacle. Or Maybe the reason is actually the same as why sometimes I can see the alien head indicator when I shouldn't (the other thread).
  14. Can be seen in Screenshot. It does not make any sense to have a cancel Button in these messages as they inform that something happened (rather than asking do you really was to do that?). Maybe the second button was supposed to be "go to atlas base"?
  15. Build V3.1 Had this happen a few times n Build V3.1 now and always sent an F11 bug report after that (as you told to do in some thread) - hope that there may at some point be something in Data that. The reason I am posting this here again is that there appearantly was some change in code that added something to this behaviour. Now it is not longer just a graphical glitch but it affects the game logic, too. Basically the upright body is no longer seen as dead now. At one instance, I had 2 of my Xenonauts killed during mission, one had the upright glitch. On debrief Screen, only one was dead, but still the items were stripped in armory. (Mentioned in other thread about Strat Ops, but it turns out that it is the standing upright and not Strat op that caused it). Then during an UFO mission by chance the last sebillian got the issue (Screenshot 1). I did count the bodies to be sure, it was indeed sebillian Nr 6 of 6. Note: The body on the floor is actually a second sebillian that was killed the turn before, it is no duplicate body. However the Ground Mission would not end after the last kill. What I did next is move in all Xenonauts, one of them to same position as the upright sebillian. (Screenshot 2). Then I ended my turn, what then happened in quick succession (was not prepared to take a screenshot) was that 1. sebillian regenerated all the HP 2. Ground mission was completed. On debrief Screen the sebillian was not dead or captured (Screenshot 3). So it is strange it ended the ground mission - maybe there is actually some glitch in the capture and hold winning condition that allows to win immediately if I have 6 Xenonauts vs. 1 alien in the UFO for one turn, rather than at least one Xenonaut in UFO and no alien for 5 turns? Either way, I think this change in behaviour points in the direction that it was probably something in the game logic all the time rather than in the animator and some code change brought that to the surface just now. Screenshot 1: Screenshot 2: Screenshot 3:
  16. It is in Documents\My Games\Xenonauts 2. The real path to documents depends on the operating system (its C:\Users\<your windows user>\Documents in windows 10), but there should be a shortcut in start menu or desktop. There you find your savefiles and logs. And yes, the part with the not opening door was fixed. The crash appearantly not - or it is an entirely different crash that only had the chance to appear after the devs fixed the first one...
  17. This is just confusing in GOG. I already asked GOG support about it and then wrote them they should put a clear hint about it on the website. Appearantly they didn't. What you need to do is: Install GOG Galaxy, log in with GOG credentials and then install the game from the library Tab. There is no manual installer available during closed beta phase appearantly.
  18. Happened to me, too. I opened up a door to an alien in my turn and destroyed its shield. The specific alien then fired some shots at me on alien turn and the game crashed probably when the next alien should do its move. Attached: output.zip
  19. Good News! Managed to reproduce it perfectly. The key idea was: If Im convinced that movement is not interrupted by alien sight, why not leave aliens out of it completely? No frame perfect inputs involved either, can do the click as slowly as I want. I only do not know where the randomness comes from if Shift+Click alien rather than Shift+Ctrl+click is used. One prerequisite is probably that the soldier needs to be able to fire at the target before moving, which is not always the case, maybe there are some others I am not aware of. These are the reproduction steps that make the game crash every time: Start a new game, place initial base fast forward until there appears a ground mission and start it - there will typically be no aliens in sight (if there are, you can start over, but it will still work most of the time) select any soldier prepare a movement command (just one step out of heli is enough) with one left click (screenshot 1) hold Ctrl+Shift on a forward tile that is already in sight (Screenshot 2) click left - soldier does the move (screenshot 3) let go Ctrl+Shift hold Ctrl left click Attached: output.zip The other crash error message with grenades can be reproduced the same way, slightly modified steps: Start a new game, place initial base fast forward until there appears a ground mission and start it - there will typically be no aliens in sight (if there are, you can start over, but it will still work most of the time) select any soldier left click grenade slot press and let go Ctrl, so you still have the grenade selected but are out of the forced throw mode prepare a movement command (just one step out of heli is enough) with one left click hold Ctrl+Shift on a forward tile that is already in sight click left - soldier does the move let go Ctrl+Shift hold Ctrl left Click Attached: output_nade.zip Screenshot 1: Screenshot 2: Screenshot 3:
  20. Have a new occurence here, this time normal shot with shotgun. Made sure I really just single clicked and that I pressed shift before clicking and let go the Shift button after clicking, while the soldier was moving already. The click itself was completely on the alien and fast (mouse up before the soldier started moving). This time, no turning away or towards the target was involved at all, just straight movement one tile forward to be able to shoot over a desk and then straight ahead shooting. And no TU reserve was activated. So we can pretty much exclude the possibiities that the movement gets interrupted by spotting another alien or the TU reserve. I should also note that when it happens, I see no visual interruption of the actions of the soldier at all. The Shift+click will issue the movement order that the soldier does finish without interruption and then the click on the alien starts the aiming anomation then crash on firing. One thing I noticed however is that when crash is about to happen the camera centers on the soldier right at the start of the movement, which normally does not happen. I think that the camera center on soldier normally happens on interrupt. Therefore I think what happens is that I can somehow issue the movement and shoot command at the same time (maybe even on the same frame), then both try to play back at the same time and the movement would then interrupt the shooting, so only the movement gets really done. Attached: output.zip Edit: well actually the center of camera on Xenonaut does not always happen, I think it only happens if the game determines the Xenonaut is not in view (It does go to xenonaut and track the shot if its far away). So rather the queued-up shot at the start of the movment seems to be the cause of the camera centering, and not the interrupt. In this occurence again, no visual interruption of the soldiers actions. He just moved to the end of the path on shift + Click. What is interesting here is that this time I manually needed to turn towards the alien with right-click before the soldier could shoot (was facing away at the end of the movement) - seems the queued-up shot does "survive" even that. I left fraps running in background this time, just to check the framerate and I had drops to 20 fps. So maybe low framerate somehow increases the probability of it happening (will try to play on lower resolution to test that). Maybe what is actually happening in my case is that I finish the complete mouse click (button down and up) before the soldier does even start the movement animation, which leaves room to interprete the click a second time as firing command. Another remark: Seems the for the crash to happen, the soldier must have a "firing solution" to the alien already at the start of the movement (hit probability any value > 0%) or it wont queue up the shot. Attached: output_2.zip Edit2: No, actually, FPS seems not to be related to it. Just tried it with lower resolution + fastest graphics settings. Game was smoother (no drop below 30 fps) but crash did still happen (this time machine gun again). But even in this case: Just one click during the shift+click. output_3.zip
  21. Will try, but I am pretty sure I am just single clicking. One thing I noticed however when I do the click really slow is it that it is enough for the soldier to start moving with the Shift down + left mouse button down, and that I hear an in-game click sound later on left mouse button up - hence my assumption that the game can somehow generate 2 input events depending on the precise timing of mouse down, mouse up, shift down, shift up and where the cursor is currently pointed on all of these.
  22. It happened yet again with normal rifle shot. Took another look in the log and what I can see there is that there is MoveToEvent and AbilityEvent for the shot just 30 ms apart. Since I don't do 30 inputs per second it appears to me that it basically must be the same input that triggers both events (like the shift+click). 2019-03-21 21:47:11,798 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.40.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:651) Queued global::Xenonauts.GroundCombat.Events.CommandLifecycleReport: Status: Started, Command: MoveToEvent([F:0, I:97, J:49] / [X:48, Y:0, Z:24], ID:6418 Type:Centre), Details: , Comment: 2019-03-21 21:47:11,800 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.40.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:651) Queued global::Xenonauts.GroundCombat.Events.MovementStartedReport: MovementStartedEvent: [F:0, I:91, J:59] / [X:45, Y:0, Z:29], ID:7702 Type:Centre, 6064 2019-03-21 21:47:11,801 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.40.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:651) Queued global::Xenonauts.GroundCombat.Events.CommandLifecycleReport: Status: Activated, Command: MoveToEvent([F:0, I:97, J:49] / [X:48, Y:0, Z:24], ID:6418 Type:Centre), Details: , Comment: 2019-03-21 21:47:11,836 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.40.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:651) Queued global::Common.RPG.AbilityEvent: AbilityID: normal, Source: GlobalEntity 6080 Item - Name:Ballistic Rifle, Target: GlobalEntity 6216 - Combatant - Species:psyon, RoleGroup:default, Ethnicity:default, Gender:default :: LifeStatus:Conscious Attached: output.zip
  23. Well, I have 2 more times where it happened here. At one time I almost thought I found out how to reproduce it, but no, I don't seem to be able to do it willingly, it just happens. But what I can definitely say is that it was NOT like click alien to shoot --> some interrupt --> click again, but rather just Shift+Click to issue the movement command, then click again after movement was finished. Interestingly, the second time happened on throwing a stun grenade and the Exception which crashes is something else (ArgumentOutOfRangeException instead of NullPointer), however I can see that it basically is the same in log - ie. the throwing action of the same stun grenade was queued 2 times. I can only assume that there is some specific way to do the Shift+Click input (order at which buttons are pressed and released for example) that will somehow queue up a shot already but it just should issue the movement command. Then probably it is the movement itself that interrupts the shot (I can see in log that there was first queued the first shot and then the Interrupt is logged just milliseconds before first MakeStepSound) First one: output.zip The one with grenade: output_stun_grenade.zip
  24. I think it shouldn't interrupt the action because of spotting the alien in these cases, because I could see the alien during the same turn already (at least that how I think this should work - movements interrupted only if a soldier spots an alien that was not seen in same round at all until that). And I did not spot a new alien because of the rotation. And actually I do not remember having clicked a third time after the first fire attempt was interrupted (will pay more attention though if it happens again.) If there were 2 shots queued, maybe it would actually queue the first one after the shift+click movement already and cancel it when I let go off the Shift button? Intuitively it would make sense for the soldier to first move and fire on shift+click because it shows the summed up TU cost for both actions before the click. But that is just speculation at that point because I don't know if I Shift+Clicked everytime it happened. However, it is not unlikely that the soldier was always facing in another direction when it happened (so it needed to rotate+shoot always).
×
×
  • Create New...