asaz989

If it had the right sense of humor, I would totally play that game.

I got confused by this too, until I realized xenonauts.exe was conspicuously small. Try "cat xenonauts.exe"

Thanks a lot! So what's interesting in my case is that this is an integrated graphics card, and I'm fuzzy on how the video RAM works with those. IIUC they share main memory with the CPU, but I don't know if they get a fixed allocation, or if they can ask for as much memory as they like. Maybe I just need to find the knob to allocate more and things will be good.

Yup, getting these crashes again. (On v1.07 through Steam.)

Ah hah. Apparently NeoTiger has characterized this behavior. Hospitalized soldier seem to lock down their equipment until healed. Annoying -__-

The scientists tried to convert him to their newfangled e-cigs and tablet apps, but he's too set in his ways

Hmmm. Did you stop and check for the equipment after the dropship got back to base, but before the soldiers recovered? If it's not showing up at that point, it's definitely a bug, and goes against the developers' description of the functionality.

Are they disappearing from only the equipment screen, or also from the soldier list screen? Soldiers injured below 50% will not be usable, and will show up in the list screen as "Wounded N Days"; they'll be usable again once they've healed up above 50%. (A Medbay will speed up this process.) WRT equipment, I remember hearing about an issue where equipment of dead or wounded soldiers would "disappear" temporarily until their dropship returned to base; I don't remember if they'd decided to change the UI to better indicate this.

The replacement industrial tileset seems to also fix my invisible props issue - that's how the performance issue manifested with me, apparently

Ooooh, Steam! A few days late to the party, but I'll try this out.

Here's /0/"]the screenshot on the Xenonauts home page (With some aspect ratio issues, unfortunately.)

Here's a screenshot of my mission, and a save - the soldier is behind an invisible car (you can see the pathing that avoids it), and quitting to the main menu has exactly the same car stay invisible. However, quitting to the desktop and reloading completely, some other random prop type won't appear, for example those NW-to-SE walls just above the UI elements at the bottom. Here's a save, though I don't know if this will reproduce easily across systems: [ATTACH]4391[/ATTACH] Whenever this happens, there are multiple repeats of the following two lines at the console (same line number and everything, though that is in Wine source code (I'm on Linux), not Xenonauts ) err:d3d:wined3d_debug_callback 0x17aaa8: "GL_OUT_OF_MEMORY in glTexSubImage".err:d3d_surface:surface_upload_data >>>>>>>>>>>>>>>>> GL_OUT_OF_MEMORY (0x505) from glTexSubImage2D @ surface.c / 2353 A couple more observations: The console output doesn't get repeated more if I exit to the main menu (not desktop) and reload the save, despite the error re-occuring, indicating that the game attempts to load a texture into OpenGL/D3D memory only once across multiple GC loads in the same xenonauts invocation. The issue seems more likely to pop up the longer I run the game; in one or two GCs things are pretty stable, but the third GC in a load is very likely to exhibit this issue at least once. Are textures not getting a glDeleteTextures call through the wined3d layer? Before this, the bug was annoying, but could usually be fixed by exiting and re-loading; this is my first big (grounded Landing Ship) night mission, and the game can't seem to load all the prop textures even from a fresh start. test.sav test.sav

If you exit the game completely (quit to desktop) and then re-open, do you see the same issue? I'm seeing something similar that seems to be related to graphics issues when loading textures; the images for props fail to load, so the prop never shows up, but restarting the game gives that prop a chance to be re-loaded properly.

What's interesting is that the parts of the screen that consistently show up correctly are those with moving images (the scrolling screens). Gives me the impression this has something to do with invalidation/redrawing.

There's an annoying bug in the packaging (not sure if it's better fixed on your end or on GH's). Your tiles/farm/ directory is named with lowercase, while the Linux package uses uppercase for that directory only (assets/tiles/Farm). Since Linux filesystems are case-sensitive and Wine emulates a Windows system (which isn't), installing this map pack makes the game unable to find any of the stock farm tile images, causing all black tiles on farm missions. I fixed this on my machine by moving the contents of farm/ (the map pack) into Farm/ and deleting the empty farm/; the right solution is for either you or GH to change the case to match the other. I'm not sure how changing the case to capital in the map pack archive would play on Windows, though; have fun checking that out