ckelloug

X-Division is one of the most amazing games I've ever played. I'm on XCE 34.3 and X-Division .4 There are two bugs that drive me nuts though. The first is the endless alien turn bug which happens infrequently and probably can't be fixed: It seems to be a deadlock between the thread that runs the aliens and the rest of the game. Watchdog timer on alien turn time might be a reasonable solution? The second bug however and the one that bugs me the most is one I've mentioned before on this thread: dropping an item on the ground and switching items in the soldier's hand tends to cause a null pointer exception about 5% of the time I change the equipped item for a soldier. Something that the code reads after the callback to the X to close the backpack window is dereferencing a null pointer. I can't reproduce the bug just moving items around the backpack but in the thick of the battle, dropping a weapon and grabbing another or a first aid kit from the backpack causes it. Wish there was something I could do to help the community figure out what it is. My theory is that the code for inventory is based on a pair of linked lists, one for the ground and one for the items carried by the soldier. I'm guessing that one of the special cases in the list handling forgets to check if a pointer is null before derefrencing it and perhaps some other special case forgets to update a pointer when an item is moved between lists.

What weapons should one ideally have by the time phase 2 rolls around? I've got Division mk1 ballistics and lasers and I seem to get my posterior kicked way too often. Perhaps my tactics are just lousy. . . Do I need to exchange weapons with every alien I kill? Also, what skills does the X-Division team need? I'm a computer engineer and nanomaterials researcher between consulting projects and might be able to help out.

I'm running wine 2.0 on linux with X:CE 34.2 and X-Division 0.99. The strict enforcement of memory addressing in linux tends to expose memory bugs that would otherwise be latent. I am getting an intermittent freeze when I pick up items from the ground and then hit the X in the top right corner to close the inventory window. I first noticed it on an alien outpost mission where I got injured almost immediately and needed to use a medkit. Due to the TU's required in X-Division for the operation, the fastest way to do this is to drop your weapon, get a medkit out of backpack, heal yourself, drop the empty medkit and then pick up your weapon. I lost the save where I could reliably get the problem to happen however I do have the console log message from wine which is the same each time I have seen the problem: Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00483cb5). It appears to me that the inventory is handled as a linked list and that there is a problem with not checking whether the pointer to either the next or previous element is valid before dereferencing it. If I find a save where I can reliably duplicate the problem, I'll post it.

Thanks for the comment on aliencontrolsystem. It would make more sense to me if aliencontrolsystem was named primativealiencontrolsystem or something similar that made the progression more obvious. What an amazing mod!

I can't build the corsair. Should Corsair require a "basic alien control system" or an "alien control system"?

Is the Laser Rifle MK1 really supposed to have a reload time that means its the only thing you do in a given turn?

I'm not an expert on the microsoft stack either but I've played through the game once using the hacking tool under wine on linux and had only a few hangs rather than every mission with larger than a scout UFO causing the out of memory problem. The Large address aware flag should be fine on 64 bit windows. What it does is tell the linker that it's okay for the 32 bit code to use memory addresses between 2gb and 4gb. From extensive googlation many many games from this era had the exact same problem.

It appears that the X:CE executable is not being built with the large address aware flag and as a result, the program runs out of address space with the texture maps. I was able to download the following tool that hacks the binary to change that flag and all of my problems with running out of memory on wine went away. I think there may be a compiler option in the build but this tool fixed the problems for me. http://www.moddb.com/downloads/large-address-aware1

Based on sleuthing in my games under wine using valgrind and other debug tools, there appears to be a race condition/deadlock with sound in the game where multiple threads try to either open the audio device or play sounds.

I have run this save game under wine in X:CE 32.4HF. It has two problems. It allocates a whole bunch of texture maps and starts getting out of memory errors allocating textures. Before it can crash for that reason which it usually does in my games, it encounters a deadlock condition between the first thread started by the game and a thread started much much later. A race condition with occasional deadlock would explain the slow alien turn bug. Here's some of the errors coughed up by wine: err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:d3d:wined3d_debug_callback 0x1b1af8: "GL_OUT_OF_MEMORY error generated. Failed to allocate memory for texture.". err:ntdll:RtlpWaitForCriticalSection section 0x44b36854 "?" wait timed out in thread 0045, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x44b36854 "?" wait timed out in thread 0045, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x44b36854 "?" wait timed out in thread 0045, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x44b36854 "?" wait timed out in thread 0045, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x44b36854 "?" wait timed out in thread 0045, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x44b36854 "?" wait timed out in thread 0045, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x44b36854 "?" wait timed out in thread 0045, blocked by 0000, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x44b36854 "?" wait timed out in thread 0045, blocked by 0000, retrying (60 sec)

I've been playing X:CE under wine in linux. It crashes all the time, moreso with newer wine versions. I started running it under valgrind and various debugging tools. It appears that there is a race condition where two threads are both trying to write to or open the sound device at the same time. valgrind slows down Xenonauts by a factor of 10 so the race occurs every time just starting the program. It makes sense that playing as few sounds as possible minimizes the occurence of this bug. Heres some of the messages I get just starting xenonauts 34.2HF under valgrind with wine 2.0 ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ==2783== Conditional jump or move depends on uninitialised value(s) ==2783== at 0x6C5786: ??? ==2783== by 0x71D735: ??? ==2783== by 0x6953CC: ??? ==2783== ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred err:ntdll:RtlpWaitForCriticalSection section 0x4bdef2c "mmdevdrv.c: ACImpl.lock" wait timed out in thread 003b, blocked by 003a, retrying (60 sec) err:ntdll:RtlpWaitForCriticalSection section 0x4bdef2c "mmdevdrv.c: ACImpl.lock" wait timed out in thread 003b, blocked by 003a, retrying (60 sec) ALSA lib pcm.c:7897:(snd_pcm_recover) underrun occurred ACImpl.lock is an internal lock in wine related to initializing its simulation of the windows IMMDevice.