Jump to content

asaz989

Members
  • Posts

    34
  • Joined

  • Last visited

Everything posted by asaz989

  1. If it had the right sense of humor, I would totally play that game.
  2. I got confused by this too, until I realized xenonauts.exe was conspicuously small. Try "cat xenonauts.exe"
  3. 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.
  4. Ah hah. Apparently NeoTiger has characterized this behavior. Hospitalized soldier seem to lock down their equipment until healed. Annoying -__-
  5. The scientists tried to convert him to their newfangled e-cigs and tablet apps, but he's too set in his ways
  6. 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.
  7. 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.
  8. The replacement industrial tileset seems to also fix my invisible props issue - that's how the performance issue manifested with me, apparently
  9. Ooooh, Steam! A few days late to the party, but I'll try this out.
  10. Here's /0/"]the screenshot on the Xenonauts home page (With some aspect ratio issues, unfortunately.)
  11. 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
  12. 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.
  13. 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.
  14. 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
  15. On 1.05HF (no modifications), I'm starting to get this issue even earlier in the game (GL_OUT_OF_MEMORY warnings, stuff failing to be drawn), on light scout and scout missions. So far it tends to be props rather than UI elements (e.g. walls or railcars that aren't visible to me but that no one can see or shoot through). No crashes yet, but I'll keep an eye out as I progress to bigger missions. My system is running Intel HD3000 integrated graphics, and lspci indicates that it has 256MB of memory allocated to the video card.
  16. When I try downloading the Steam package on Linux, Steam says everythings fine, but: The download completes immediately When I try to launch the game through Steam, I get an error "Failed to start game (missing executable)." When I go poking around in the Steam install directory (~/.local/share/Steam/SteamApps), a Xenonauts directory has been created, but is completely empty. IIRC from other games that have had the same issues, the indicates that a SteamApp was created for the Linux version, but no files were added to it.
  17. Port! Port! Port! Port! </frat boy> Seriously though, really looking forward to a shiny Linux port with all the 1.0-1.05 fixes. Thanks for a great game!
  18. Does that include the Linux/Mac ports? As a side note, I'm using Humble Store, because right now there's *nothing* available on Steam for Linux - just a steamapp description that says there's a Linux version, and a 0-byte download.
  19. You'd get better results shooting at a different type of alien. Androns are just very difficult to damage with ballistic weapons (unless you count rocket launchers ).
  20. You know, I find it funny how people call a product that's actually being released vaporware. It's delayed, but vaporware is specifically for stuff that doesn't actually exist outside of press releases.
  21. Yeah, getting high up (especially with jump-jets) is very useful, even without an accuracy bonus. On v21, before any added alien AI for using elevation, I found Harridan suits to be very worth it just for reconnaisance purposes. They both kept me from running straight into an aliens around unscouted corners, and on Terror Missions provide very useful spotting in my main kill zones
  22. I haven't played any v21 builds yet, so no comment about the current balance. Just my two cents about Caesans - when I take casualties against Caesans, it's because of good long-range shooting, and because they're so cautious about leaving cover that it's harder to snipe them from out of range. To make them "scarier" to go up against, but still have a distinct character, maybe buff their (already quite good) accuracy at range? Like a more defensive or cover-aware version of the Harridan snipers. That would also go well with their Xenopedia lore, which is all about them being cautious ranged fighters.
×
×
  • Create New...