Solver

I don't actually remember how it was supposed to work. I think you're supposed to lose the airplanes and personnel but keep the buildings. And yes, it would be cool to fight in the Xenonaut base layout, but that was more challenging to implement, this is easy.

I liked it. The maps are still somewhat repetitive, but this is a major improvement over the last build. I think I'm seeing the potential of the map randomisation system there. Should turn out quite well. I also want those multiple simultaneous orders. My guys are inaccurate even by the infamous standards of X-Com soldiers. My feeling is that it's not so much them sucking as it is due to the tiniest of cover dropping accuracy too much. Good job with the animations. I enjoy the distinctly alien manner in which aliens move. I liked the ragdolls too, such as my dead soldier falling into a ditch. I don't see this as an obstacle to gameplay - yes, it can mean items move a tile or two, but this should not be a problem as long as the items are in the tile in which they visually appear to be. Performance is outstanding, the map loads nearly instantly.

I might first suggest disabling the ambient sounds mod and see if the problem persists. For fairly mysterious reasons, it seems that having too many ambient sounds worsens the game's stability.

No talking, I'll just upload the minipatch to Steam

I don't have access to that now. Check gameconfig.xml, there should be a section with a variable for it. xenonautBaseRetakeInterval, or xenonautBaseRetakeWindow, something like that. Possible that I missed adding it to the modding guide and so it's only as some note somewhere I of course do not remember the finer details but the idea is that a lost Xenonaut base turns into an alien base, and then if you attack that base successfully within X hours (defined in the xml), you get the base back. Personnel are killed and airplanes destroyed though. This is a good idea. I suppose it's also a good idea for one more small release that is only bugfixes perhaps.

Works in the miniupdate I posted somewhere though, right? Works as far as I know. In a future version if there is one

Well, last I checked you still have a lot of work to do with X:CE 0.34.2, so keep fighting

Maybe I am taking a well-deserved winter vacation?

It's honestly hard to say. There was a startup crash for WinXP a while ago, which I fixed. I have never tried Xenonauts on XP so I have no personal experience - perhaps someone else is running XP and can confirm one way or another. Windows XP has been essentially unsupported since 2009, and entirely unsupported for the last 2.5 years. Regardless of Xenonauts, I'd strongly suggesting upgrading to a current Linux or Windows version.

Well, to be more clear - actual ground combat autoresolve would also mean handling soldier experience (and injuries / deaths), in addition of course to items, and implementing such an autoresolve needs code changes. And I don't see myself implementing that.

You can ask in the modding forum... it wouldn't be difficult to put a mod like that together by yourself, especially if you describe what you want in a bit more detail. For instance you could easily make all research and manufacture take half the time. I don't see how having less UFOs would make the game significantly faster, you don't have to assault all of them anyway.

I can't see this being implemented. Ground combat is the central part of the game. Without it, you're left with a base-building game that's quite easy to figure out and a mediocre air combat minigame. The airstrike feature is in the game so you can have some gains when you choose not to go on combat missions.

I'l take that up privately.

Solver's not working on much of anything right now.

I don't care. It's cosmetic graphical stuff that is at the absolute bottom of my priority list, and probably the skill list as well. Just about every other known issue is more important.

I don't care about the animation bug really. It affects nothing important, may be a vanilla bug as well, and isn't worth the effort for sure.

In ufocontents, your aliens look like Scuttler_Warrior_Aggressive, right?

From my perspective, this would be good to fix not specifically because of these burst aliens but rather undesirable effects such as in X-Div with drones/androns, etc.

I'm not touching anything though without some good saves. I can't be bothered setting up a test mod and scenarios.

I also have no idea about that, but the bug is probably somewhere in that AI logic then, because there are no other hardcoded race rules.

Again, there are no "standard race conditions" in the code that I can find, except for one Reaper rule. Everything else is controlled via aiprops only. A race with the same aiprops as Caesans is supposed to work 100% the same as actual Caesans. Since MeleeVehicles is only for a melee alien and BurstFire is ranged, I don't see any point in investigating this.

What, this again? I've lost track of how many times teleport reaction fire has been broken and fixed.

Something else is broken there, the MeleeVehicles ability only does one thing, which is modify the pathfinding algorithm of melee units so they don't get stuck in front of vehicles. That's it. It also triggers the same condition as Reapers in the code, and forces the script to Aggressive, regardless of what's set in the aiprops. There aren't more Reaper settings than that.

Yes, the AI tries to use collective decision making. It's a good system overall. What the AI units then prefer to do depends on their aiprops. For example, whether they will target the same enemy or not, and whether the group will prefer to stick together or run searching for enemies. What I am not seeing how that grouping or behaviour could be different based on whether the race is custom or not. Stuff's complex Specific GC saves might help understand this though.

I'm sure you are correct, I'm just saying it's not a direct race check. The AI decision making as a whole is complicated and it's of course not a simple table or something like that, it's a complex interplay of the AI variables. But then in my understanding it should only depend on the aiprops variables, not on the races themselves. Which seems not to be the case.