wulf 21

So, there happens nothing, when you click on a fighter? There should appear transparent fighter sillouettes that indicate where you can move it + buttons to fire the guns. Exiting the minigame before winning or loosing (or UFO escape, but the way it's balanced that never happened to me) is only possible by moving the fighters out of range (to the bottom). Maybe it is one of these UI issues that appear only on certain screen resulutions, so the information which resolution you run the game might help.

I don't know russian (like I expect most others here), so I let it translate by deepl.com. The translation sounds like it makes sense (though only Kompa3ot could point out where it is not accurate). It is a little off topic in this thread, though:

I shot down an UFO in the north. If I remember correctly, it should was a "destroyer advanced" UFO. Edit: Looks like I did not remember correctly. There was a transport UFO on selected map and I think it may be that I shot down a transport. I marked the location in the first screenshot and additionally did a close-up screenshot if the exact location is relevant. Now the crash site will always randomly either select temperate, arid or desert terrain, new terrain being selected if the "crash site mission" window is closed and crash sight clicked again. Judging from the location, the real terrain should probably either be arctic or boreal. Here is the save file: Quicksave.zip I suspect that there might be a connection to the other issue I reported in previous build, where there was loaded a map with "destroyer advanced" instead of probe. This map might be somehow incorrectly set up for probe UFO type instead of the correct one, so the game will randomly choose another "destroyer advanced" map (it seems the map is selected when clicking the crashsite icon). Edit: Probably the 2 are not that directly connected as I thought. Will take a look if it loads correct map if I shoot down "destroyer advanced" somewhere in polar region. Screenshots: Location of crashsite: Close-Up: Some random map selections:

The crash just happened to me, too. I was outside ship, but I attempted to kill a gun drone with a frag grenade. It was already damaged by a sniper shot before throwing the grenade. Clicked "End Turn", then saw and heared the frag grenade exploding, then the game crashed. I suspect it will always happen if the cause of gun drone death is an explosion. (frag grenade or breaching charge). Attached: output.zip

After playing the current closed beta for longer, I can say that this part is actually wrong. I fired a few sniper shots on enemies bebind cover with 100% final hit chance after sufficiently increasing the accuracy stat of the soldier with the sniper rifle. I am wondering how some_hit_chance - 30% * some_hit_chance can be still 100%. The only logical explanation I can think of is that the hit chance calculated from weapon fire mode + distance can internally actually be >100%, so the calculation result is still >100% and in the end the final hit chance just gets capped to a maximum of 100%? However this means that the block chance of the obstacle is really 0% in this case despite still being displayed as 30%....

Since the playtime got extended I noticed that the performance was going down in Geoscape when there is more going on. At first I noticed it in the highest time warp setting. But it was getting worse and worse up to a point when even with lowest game speed I could count the frames. It becomes worst when there are like 5 UFOs and 3 or 4 Interceptor squadrons in the air simultanously. But the interesting thing is that performance would stay very bad, even after I shot down all UFOs (or they escaped). If I then save the game, quit to desktop, start the game and load it again. performance gets better. example of such save: performance___.json The point in the game where it gets that bad is about mid March 2018. If I don't pause the game and Alt+Tab, so it keeps running in background, I see that the game fully utilizes a CPU core (it displays 25% in Task manager, which means 100% of a core). Additionally I notice that the RAM used by the game will constantly increase over time. So, it looks like the Geoscape calculations aren't really optimized and maybe there even is some memory leak issue where no longer needed objects are not properly deleted and only saving, quitting and loading would start up only with what's really necessary. My Spec: OS: Windows 10 RAM: 6 GB @800 MHz CPU: Intel Core 2 Quad @2.66 GHz GPU: NVidia GForce GTX 570 I should probably at some point buy a faster computer anyway, but I never imagined it would be Xenonauts 2 Geoscape that would require a faster CPU ;).

found another one: The game does somehow not know what to display, if the Xenonaut is already standing at the foot of the ladder before the move:

The game was just stuck on the loading screen at 0% directly after starting it. I needed to end the game with task manager to get out. (it reacted properly to the quit signal from OS though, did not need to force kill the process). It was the first time I had this issue and directly after quitting and grabbing the log I started it again and the issue was gone. Here is the log from the failed startup: output.zip

From what I've seen, not really. If it was like that, for example blocking propabilites would not be independend (for example if there are 2 chest high boxes directly behind each other, in a realistic simulation, if the projectlile passed the first box, it would be more unlikely to hit the second, because it is mostly covered by the first). There is a basic hit probability calcuated based on weapon, fire mode and distance to enemy. This can modified by a fixed per-enemy modifier (the half high psyon engineers are manually set up to be harder to hit for example). Finally, the game checks for obstacles in the path between attacker and enemy. Each obstacle has a fixed blocking chance value (aforementioned chest high boxes have 30%, complete walls have 100%, the forklift has 50% etc). The game displays these probabilities beforehand and for each projectile is made a dice-roll based on the probabilities what is going to happen to it. It is fun in the game because you see all hit chances before firing and can plan accordingly, but has some completely unrealistic consequences. For example the games does not differentiate if the projectile missed because of spread or bad aim. So better aim stat kind of means magic reduction of shotgun projectile spread. Another example is that lower spread should mean less blocking chance in reality and more body parts behind cover (ducking) should mean more blocking chance. But it's not working like this. I imagine it would theoretically be possible to calculate all the probabilites based on a cone in the 3D game world. But I think this would basically be a completely new feature and I don't know if the developers at any point thought about implementing such thing.

Just had a strange crash, I open a new thread because for me the point when it crashed was differently than in other thread and the logfile shows another location in code where crashed. What I did before the crash launched a pair of interceptors Scout UFO was intercepted over the sea chose tail "until over land" I think crash happened exactly when reaching land (probably when the UFO intercepted dialog should pop up again) Not sure what caused this. I did these steps probably 5 to 10 times in this build and a lot more often in all builds summed up and it never crashed at this point. Interceptors just had standard starting equipment still, but maybe there was something special about the UFO I intercepted (not sure what this could be though) Attached: output.zip

Once I had an idea what to do it was not so difficult to reproduce. prerequisite: Soldier was not moved yet (Sreenshot 1) Right click directly behind the soldier, so it turns around 180 degree (Screenshot 2) End Turn The result is random. Sometimes the fog of war looks like soldier was turned only 90 degree (Screenshot 3), Sometimes like he was turned 45 degree and therefore offset 135 degree (Screenshot 4). So it seems the issue is just not reported more, because playing situations where the soldiers last action is a 180 degree turn are rare. 90 degree like in original post is more common, but in this case it will work correctly >50% of times and the issue is not that obvious to see because of the angled body in the animation. Screenshots: Screenshot 1: Screenshot 2: Screenshot 3: Screenshot 4:

I have 2 more things. First, the game randomly loaded the map from the original post, and the fix of the movement texture seems to have fixed the corner texture, too. Even one more special situation with missiong texture. It is on ladders that where to path to and from the ladder allows 135 degree turns. Purple texture in corner again appeared after seeing the one on movement path. Im not quite sure, but it could be that the corner texture only will appear if ESC is pressed after preparing the movement (not on clicking some other path). I noticed the short appearance of red text does not heppen, if ESC button is used, so maybe it will not delete the texture then and move it to 0,0. But either way, I've got the impression that the corner texture issue will just disappear if all the missing movement path textures are added.

I already reported that some time ago. Guess the UI rework in Build 5 will do something about that (at least I hope so)

This is a misunderstanding of the mechanic because it is defferent than it was at X1. (It is explained in the in-game changes since X1 tutorial) Left Clicking on the panel on the left no longer activates TU reserve but selects fire mode (same as when right-clicking enemy). Right clicking a fire mode activates the TU reserve.

Just shot alien behind the commander chair a few times. Upon hitting the chair, it turned more and more white (I guess it should be overlaid with a damaged looking texture that is missing):

I do not have a further example where soldier randomly overwatch fired during the situation, however I have 2 more times where it is happening where it is even more obvious. On first screenshot, soldier the difference between the direction soldier is looking and the fog of war is 90 degrees. In second one it is 135 degrees. I am still not completely sure under which circumstances it happens, but what I am sure about is that I always first issued a move command and then a right-click turn. It seems the fog of war calculation will stay turned where it was at the end of the move if it happens. Both screenshots then taken directly after alien turn.

Further info: Actually my initial assumption that it is related to rank was wrong. Just had a perfect raid mission where everyone was at full HP at the start and noone took damage. All (even higher ranked) stayed in slot after mission. Furthermore I observered some soldier being removed from slot without mission in between. It seemed to happen after status switched from "Not Available" to "available". I think now that with the fix for the HP display in soldiers tab, there was introduced the first version of the status change (ie. wounded soldier not being available for missions) and that this is not working correctly somehow: trigger for "not available" status seems not correct - starting mission with already wounded soldier (even light wounds) seems to trigger it rather than a bad wound "not available" soldiers can be added to Skyranger slot despite the status. Status change to "available" will remove them again

Next mission I took 2 new guys (rank PVT) on the mission. Turns out that exactly these 2 then were not removed from slot after mission. Additionally one of the 2 (Julie Eklund) was promoted to corporal on mission debried, but did not get promotion in armoury/soldiers Tab/no promotion message. And the portraits were our of sync with inventory (there is armour in debrief, but not in armoury overview). Heres the save from before the mission: 4th crashsite.json

I did not see this behaviour in previous builds, so I guess some change related to the fix that inventory got removed from soldier slots after death in V4.2 (which works). I checked that it is reproducable with the savefile. load the 3rd crashsite.json there was removed just one soldier the 2nd crashsite mission before, add assign her back to the slot start the crashsite mission abort it confirm the debrief Result: All 8 soldiers were removed from there slots and are displayed in soldiers Tab as "not available" (which is not true, actually they can be added to slot and used for next mission just fine). I guess, it got something to do with the soldier rank (it worked just fine after fist mission when all were private at start of mission, now all are corporal from the start). Edit: Found out that assumption was wrong... Screenshots:

Found another movement path texture that is missing. It is for after jump over obstacle turn 90 degree and jump over next obstacle. On the same map I found in a corner a bright purple texture later. Because both issues happened the same map again, I don't think this is a conincidence. The error texture in the corner was not there at the beginning of the map - it appeared some time during the round. Of course I cannot know what action exactly caused it to spawn, but I am sure I saw the movement path error texture first, and the corner texture later. Furthermore I noticed this time a red error text popping up shortly when I it started to display the movement path (after preparing the movement command) and popping up again when stopping to display it (when ESCing out of the movement or executing it). Maybe something got logged. So it might be that the error texture from the movement path somehow does not get deleted correctly (like if there is no error texture) and instead just gets moved to 0,0. Logs (added last 2, I think it should contain the start of ground combat to the end): output.log.zip Screenshots:

Hmm, Such Modifier was in X1, not sure what the idea was behind it, but if you read the "changes since X1" ingame help, it tells that it was removed on purpose. But according to this help it actually reduces the hit chance of aliens by 25%. So there is an objective use of the crouch, but it is difficult to see in game, because the game doesn't tell you "alien missed because soldier was crouched", it just tells you "missed". And a 25% chance is not that large to definitely observe the effect. (ie. feel nearly save from hits). But I always try to use it at end of turn when TUs allow it and use cover, because I am sure that my soldiers will take less total hits in the long term than if I would not do it.

Hmm, for me the healing rate felt just about right in last few builds. If missions appear shortly after each other, I need some additional soldiers to rotate, but when there was a long gap between 2 waves, soldiers practically always healed back to 100% in the meantime.

The .json files are savegames. You find them in the "Saves" folder next to the Logs folder. If he has a Mission_18_Ufo.json, that means he did save the game before the mission and named it "Mission_18_Ufo" in the save menu.

I guess if it has any gameplay effect, it still needs to be implemented - however it indeed is a little strange to see the announcement still, since for some reason, Operations Director and chief scientist can not longer be seen in a fixed main base personell slot (like in previous builds). To explain - these 2 are special "story" characters that are around the whole time from the beginning - they are the fictional authors of the reports you read in the game.

Don't know if this still helps at this point, but here is another occurence. Game locked up again after alien walked the path marked with arrow and then dropped unconscious. Of course, I don't know if I'm right with drop unconscious on same tile as shooting theory. But what can be seen in the logs again is that one animator started the dropunconscious animation. Then the same animator gets set into shooting state after that: 2019-04-23 21:27:57,924 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.43.1\Assets\Code\Screens\GroundCombat\Systems\Rendering\AnimatorSystem.cs:223) Setting DropUnconscious on Animator for 4709 to True ...... 2019-04-23 21:27:58,089 [INFO] (D:\Jenkins\workspace\X2 (Build)\hotfix-0.43.1\Assets\Code\Libraries\Artitas\Artitas.Core\Code\World.cs:681) Handled global::Xenonauts.GroundCombat.Events.AnimatorTriggerCommand: Actor: 4709, Trigger: ShootingState, Active: True, Sticky: True Attached: output.zip Screenshot: