kabill

Aye, these are the two most likely problems.

For those who didn't hate the first one (and maybe some of those that did, too!): http://www.rockpapershotgun.com/2015/06/01/xcom-2-announced/#more-292343

Easiest method with this file is to use MODMERGE="replace" on the top element such that the whole contents of the file is replaced with whatever you are changing it to. It's inelegant and I'm fairly certain there's a more precise solution if you need it but I suspect that this method will be sufficient for whatever you're doing.

Hey guys. Sorry for the extended absence. As might be obvious, I've been busy with various things over the last couple of months while also suffering from some modding exhaustion, hence I've not been around. I'm not sure this is likely to change in the near future, both the busyness and the exhaustion. And as I'm sure you all appreciate, time and keen are both integral for this kind of work. Accordingly, I'm calling a moratorium on my modding activity. It's not impossible that this will reverse in the future - I've been through similar lulls this in the past - but I think it's only fair to make this clear now such that people aren't waiting for work that I've (implicitly or otherwise) promised to produce. That said, there's a few things that I'll probably potter around with to tidy up existing projects and if I have the time and willingness I might finish off and release an almost-completed mod I was making at the beginning of the year. And I'll be sticking around the forums, not least in eager anticipation of GH's upcoming games!

I think the game possibly uses the string for the ranks as a way of identifying the correct rank icons, therefore you need to name the new rank icons after the new rank names you've created. Might be wrong, but I seem to remember seeing this before and this being the problem.

Heh, strange. Well, at least you found the issue. I was going to suggest that it might be because they're animated, but there's animated props used in the vanilla UFOs as well (e.g. anti-grav generator, alien hyperdrive etc.) which I'm fairly certain are on the first level, so I'm not sure why it would be that.

Honestly, I can't remember. But actually you're probably right - ECS wasn't about making gameplay changes so it's unlikely I added that. Never mind, then. (To add: I really can't think why those mods would be making a difference. Certainly ECS - if I didn't change the roof tiles then the only things I did were to add the fire and smoke props, to add the power core explosion points, to add ground damage and to swap some of the props out for damaged ones. Not sure why any of those things would be causing issues with the camera. The only other thing I can think of is that there's been an update to the UFO submaps in XCE but I'm not sure there has been anything maybe other than a few minor LoS bugfixes which should already have been fixed in FitH to the best of my knowledge.)

Hypothesis: it's related to the 'roof' tiles I used to replace the vanilla UFO roof tile spaces so as to allow units to land on top of UFOs? Haven't tested this but it seems like the most likely candidate.

A number of features and bugfixes were taken from XCE and included in the 1.5 release of Xenonauts.

Instructions are here: http://www.goldhawkinteractive.com/forums/showthread.php/12716-Xenonauts-Steam-Branches If you've followed those instructions and you're still not getting anywhere, I don't know.

I think "shift-Q" reveals the map and "Q" hides it. Or the other way around.

Not sure but I can have a look (I thought this was already supposed to be the case as I remember it coming up a long time ago, possibly before release last year. But I've seen it happen myself a few times too.)

Not sure that it would be possible to extract the current attack probability in a useful manner. IIRC, it's based on the relative time each base has been in game, e.g. if one base has been in game for 60 days and another for 40 days then there's a 60% chance of going for the first and a 40% chance of going for the second. There's not really any way you can mod that without changing the actual calculation as well. If this issue is primarily about new bases being attacked, perhaps the best solution would simply be to block base attacks against bases which have been in existence less than X amount of time (e.g. 1 month) so that you always have the chance to defend them with soldiers/turrets before they can be attacked. That would at least stop instances where there's literally nothing you could have done to prevent losing the base.

Think I'm torn on this. On the one hand, it makes more sense to me that the aliens would simply wreck the base rather than hold on to it with a chance that it might be recaptured. On the other hand, I'm not entirely unsympathetic to the problem - in my last game I'd literally just gotten a new base up and running with a radar and a couple of hangers and it was attacked and destroyed without me really being able to do anything. One thing that might make it work conceptually is that when the aliens occupy a base they convert it to an alien base. I.e. When a base is captured by aliens they occupy it and the player can counter-attack if they want to recapture the base. However, after a length of time (say, a month) the base is converted to a proper alien base and can no longer be recaptured (but can be assaulted as normal). Hence, you have a grace period after which the base is lost to retake it but if you leave it too long you lose the opportunity. All this said, I'm not sure it would be within my competence to implement something like that. But I think it would be my preferred system.

Yeah, a save or pic would be useful, especially as I don't remember this being the case in my own games (but I might not have encountered precisely the set of circumstances you've mentioned).

I can have a look at these if no one else wants to. I don't understand your point about the fire-from-centre issue though. Is it obvious in any of the videos you've posted or is there a good test-case to illustrate what you mean?

Sadly wasn't able to check this for certain this morning (I'll do it later) but when I was playing around with anti-missile defences a few months ago I managed to get them working without getting any crashes, including IIRC multiple shots at the same time. As I say, though, I need to check as I might be misremembering or might not have tested some specific conditions where it would come up.

Column 14: "ProjName". Types include 'Bullet', 'Alien Bullet', 'Missile', 'Alien Missile' and 'Alien Torpedo'. Note that it's possible that anti-missile defences will only work against 'Missile' type and not also the 'Alien Missile' type I wrote above as I can't remember exactly. So if you're testing missile defences for player aircraft and 'Alien Missile' attacks keep getting through it might be that you'll need to change them simply to 'Missile' instead (I don't know if changing type makes any difference other than for anti-missile defences.)

Anti-Missile defences only work against Missile/Alien Missile type projectiles (as defined in aircraftweapons.xml). Don't think the hardpoint type matters at all.

Are there any research projects you've not completed yet? The easiest way I can think of would involve adding the Marauder tech as an unlock after finishing another research project. Other than that, I don't know - not sure there's a way to manually unlock techs in game.

It changes the Marauder to require the Corsair be researched as well as the default requirements (armour plating and alien reactor) but I assume you have researched those already? In any case, it doesn't seem to be a typo so maybe another mod is causing the issue?

Noted. Yes, I've already done it. Should hopefully be in 0.33.

Saw and responded to your post on Steam before seeing this. Basically, I don't have any idea what might be causing the problem other than maybe a bad interaction with another mod. Only thing I can suggest if you haven't tried it already is deactivating other mods but leaving Armoured Assault on and see if there's another mod that's related to it too.

2a) is a vanilla bug. 2b) I think is too, although I thought it had been fixed in XCE (maybe it's not in the current release version though). I've just had a look in the files and I think I know what's causing 1). If you want to fix the issue: 1) Open the mod's aircrafts.xml files; 2) Find the OnWinAgainst column; 3) Add "1x" just before the Items.AlienAssaultLanderDatacore and Items.AlienDreadnoughtDatacore strings so they read 1xItems.AlienAssaultLanderDatacore and 1xItems.AlienDreadnoughtDatacore There might be another issue and I've not checked to see if this works but there's a good chance this is the problem.

I've not seen any odd behaviour recently, but I've also been playing with a lot of changes to GC so have no idea if this is a quality of XCE or something that I did. Ah, sorry, you may be right. I was thinking of the pathing variables when I replied above, forgetting that this was about something else. Adding them together seems like a fairly simple but effective solution to me. Yeah, it definitely made them shoot more but they were also pretty static. Not necessary a problem for command room aliens but definitely not recommended for general use. Relatedly, something to consider: when the scatter system was changed the short-range to hit bonus was toned down to account for the fact that missed shots could in fact still hit their target. I presume, however, that the AI wasn't adjusted to factor that in when comparing against its minimum to-hit threshold. So, leaving aside for a moment any significant AI changes, would it be worth reducing the values across the board just a little to account for that?