Chris

Gorzahg, I can't believe you're given Mr Tibbles angry eyebrows.

OK, some useful suggestions. First thing to say is I don't want to disrupt the existing combat model too much. Therefore I don't want to change weapon ranges based on shot mode, nor do I want to add two burst fire modes (semi and full auto). To be honest, I would rather have a single shot mode and a full auto mode than a single shot mode and a burst fire mode. The reason is that burst fire is much like a single shot, whereas full auto has an entirely different role. Therefore when I refer to "burst fire" I actually mean "full auto". A template based system like suggested in my original post would be a pain in the ass to implement. Requires lots of extra graphics and the like, so I'd prefer to do something else if we can come up with a plausible alternative. I quite like the idea that burst fire has the same AP cost for the first bullet as an unaimed single shot, and then additional bullets have a fixed AP cost (which can vary per weapon) to fire. Burst fire would just consume APs until either the weapon runs out of bullets or the soldier runs out of APs. You don't have a lot of control over the length of the burst then, but implementing a control system for that would be a nightmare and would lean towards overcomplication. For accuracy, you could then use the JA2 system where the first shot is at normal (unaimed) accuracy and the following ones rapidly decline in accuracy (eventually reaching a minimum percentage). Again, I guess the accuracy drop off per shot and minimum percentage for accuracy could be set individually per weapon. For suppression, you can then have bullet-based suppression for burst fire. You'd just use the basic single-shot suppression value, but then each bullet fired might add a fixed number to that. I think that could work. In graphics terms, I think we'd have to get rid of the individual bullets and just show the impact points. Although quite how that would translate into lasers and plasmas, I don't really know.. Naturally, we may have to increase reload costs if they're not enough of a barrier to repeated auto fire - although there's also the danger of running out of ammo too. But the beauty of the system is that later in the game when you have to manufacture your own ammo, auto fire would hurt you in the bank balance too

Wow, GJ has certainly proved popular. At the moment I've just got him working on the ground combat AI but it's not beyond the realms of possibility that he'll do something on the air combat AI too. The problem with the entire air combat is that the system isn't fully locked down yet so we're still a bit unsure how it'll turn out.

The basic AI model should be in place by 9th October (ie. beta). There'll be a small AI update in V14 this weekend but don't expect anything too impressive yet. It's a big task and it takes a bit of time to pull it all together.

So, one of the last things to consider before beta (or in the early stages of beta perhaps) is a revamp to how burst fire works. This is seperate from, but linked to, the addition of suppression mechanics to the game. The problem is that there's not sufficient differentiation between single shots and burst fire. This makes the tactical game a bit more dull (less tools at your disposal) but also makes my life as a game designer harder. We've got machineguns in the game, but they're basically just sniper rifles that fire several bullets at once at the moment. In game terms, burst fire should (and does) consume more ammo and suppress more than single fire mode per AP spent. It should also cause less damage to single targets per AP spent at range, but it should have the possibility of causing minor damage to multiple enemies instead of hitting just one. It should also damage the surrounding terrain - after all, lots of shots are being fired! Finally, at close range it should be potentially devastating, as all those otherwise wayward shots are much more likely to hit the target, which might end in something like five to ten seperate shots hitting the target. Basically, I want burst fire to feel like the soldier is blazing away with their weapon and have it actually appear to have a tangible effect on the battlefield. At the moment, burst fire just doesn't feel "strong" enough. I'm open to suggestions on how it could be handled, as I've not got anything definite planned yet. I'm currently musing some form of circular template system where a certain number of hits are randomly assigned to any tile or object within that circle, and suppression is applied to all targets in the circle. The circle would be tighter the closer the target is to the shooting unit, simulating the effect of range on accuracy. Some weapons would be entitled to more hits and bigger circles, to represent weight of fire - ie. the machinegun or the Ferret 50cal. In graphical terms, the game would just play the bullet impact animation for each hit on a tile. The disadvantage of this is that it's a bit predictable, and it doesn't take soldier accuracy into account - but then, burst fire isn't meant to be accurate anyway. As long as it's balanced so that it does on average less damage than single fire then it could work...

Yup, this is the right place. Thanks for contributing them, hopefully someone will find them useful!

It's not possible to suppress drones or other robotic troops. Or fearless enemies. But the reason we use the icon is that the aliens will be using cover by the time beta comes around and if a unit is already crouching in cover you won't know when it's suppressed unless you have the icon.

We couldn't put that in the combat UI because there's no space. The mission end screen though, yeah - I'd like to have a KIA stamp to go over the portrait.

Yes, we should be on for another release this weekend.

As no doubt many of you have observed, there's been spambots everywhere over the past week or so. I am deleting the offending posts when they are reported, but new spam users keep appearing. It appears that they've managed to get around the security question I set a while ago, so I've changed that and it seems there are no more spambots registering. However there's quite a few accounts that were created before the question change over the past month or so that are being activated now and being used to post spam. There's not a lot I can do about that except ban them as they pop up and wait for them to run out of accounts. Please keep reporting the spam as it appears. Also, please stop responding to it if it's in another thread. Amusing as it may seem at the time, once the spam messages are deleted it just derails the thread. Keep calm, report the spam, and carry on.

You can already do that, and that'll continue on the new screen too.

Ubiqitous - I wouldn't bother reporting bugs in out of date versions. At best they'll be ignored, at worst it'll actively confuse our testers. The standalone ZIP files are being updated tonight as there was some confusion between us and Desura over who was responsible for uploading them. They just need to approve it now and then the ZIP files will be V13.2 as well.

The other way to simplify the Wounded issue would be to make HPs a XX/YY value, like 30/55. That'd convey more information at a glance than using mouseovers.

There's difficulties having "blocks" that aren't all in one place. It's mostly to do with the event system and assigning faction damage from alien activity correctly. But yes, we probably will retouch the map so the Soviet boundaries in Europe are more accurate during beta (that's the most glaring error, alongside the missing islands). For bigger regions - I just think it works better when a radar base can protect the majority of a funding block. Otherwise you can have a lot of operations in an area and still end up with negative funding from them because you're not giving them good coverage. In game terms it seems better to have two regions instead, one where you'd have great relations and another that'd be swarming with alien bases.

Updated the first post with the correct link to the second image and some details of the colour coding. I think adding gentle shading to every other stat column would help too, actually. I'll do that. Finally - the Armour for a soldier can be changed by clicking on it on the screen. Does anyone use that functionality? Removing it would help keep the clipboard a bit less wide, especially given the soldier and dropship names can potentially be quite long strings.

The idea with the final system is that any soldier used in properly battle (ie. rather than sitting in the Chinook or avoiding all combat) will automatically level up most of his stats a couple of times, but is is capped at 2 points in each attribute per stat per battle. It may be slow at the moment, but that's what balancing is for. One of your main objections seems to be "special forces soldiers would not gain a skill-up for doing mundane things". This is fair enough, until you realise that this is a game. Of course special forces soldiers wouldn't get noticably fitter or stronger running around the battlefield, or become more accurate just shooting at enemies (assuming they already have combat experience), but frankly very few special forces soldiers will increase their abilities very much once they've already gained special forces experience. And it wouldn't be a very fun game with no advancement whatsoever. And adding soldier advancement that isn't linked with combat is breaking the risk / reward mechanic of risking your troops dying in order to make them better at fighting, which would be extremely bad game design.

Naturally anyone equipped with notepad is able to adjust this to their liking

Khall, where's your avatar from? Looks cool. The hashes are caused by missing data in strings.xml. This may be intentional as a result of me removing late game stuff, or it may just be incomplete files. Either way, it's nothing to worry about - it'll be fixed in the next build or certainly by beta.

I'll apply. It's reasonably unlikely we'll get it again this year though - I think the idea is to expose unknown and up-and-coming games rather than relatively well-known projects such as ours.

I wrote a long explanation for this screen but the forums ate it so this post will be brief. Basically this screen replaces the existing Personnel screen, and is geared towards managing the soldiers. The hiring of personnel will now be conducted on the relevant page (labs, workshop, barracks) rather than all together on a single page as I think it makes more sense that way. The training functionality is more than likely to be canned. I've thought about it and I don't really see it being particularly useful, it's really just adding an extra layer of complexity for no real gain. People get confused by the fact it only works on Privates (so none of the starting troops) and the fact it has very limited functionality. Levelling troops up in battle shouldn't be difficult enough to make it that useful either. Anyway, onto the screen itself. The first screen is the soldier management screen (clipboard "paper" obvious still WIP): http://www.xenonauts.com/devimages/barracks1.jpg There will be functionality to "look down" which would let you see more troops on the clipboard but that'll hide the navigation menu on the wall and the speech bubble menu. Quite how it'll be triggered, I'm not fully sure yet. I quite like the colour coding of the numbers too - it's just a question of not making the screen look like a kaleidoscope. EDIT - the colour coding is basically done at random in that image but essentially numbers will start backed in yellow at 50 and then will move up to the darker greens as the soldier gets closer to 100. For the chinook, the lighter green indicates a soldier not on full health who has still been assigned to a Chinook (details on his injury would be shown on mouseover). The second screen is the soldier hiring screen: http://www.xenonauts.com/devimages/Barracks2.jpg This basically incorporates the current soldier pool hiring system direct into the UI. We'll probably colour-code the stats there too.

Quick note from me to say we've released a hotfix on Desura. This disables the editor functions in the game and hopefully fixes the air combat retreat crash, but I also did it in the hope a fresh update would sort out the Desura MCF problems some people are having. Note - I forgot to update the launcher background "V13" text.

The lack of a buy screen would be fairly terminal to that. The best you could do would be add starting Workshop projects with whatever cost and 0 build time for the items you wanted to be "buyable".

Hehe. I'm not going to read this thread mostly because everyone knows my views. But in short - I can't stop people pirating Xenonauts (or other games) and I won't do anything to stop it, or even lecture people on morality beyond what I have in the article, but please don't tell me it's right! There are good points to piracy as well as the bad points, but the act itself is still wrong.

It's something we'll look at in beta.

OK, so I'm sitting down and trying to get the major screen for our new UI revised and ready to be implemented (once the rest of the code is done at least). The easiest of these is the Stores screen. What I've aimed to do with the updated UI is to: 1) Make it clear why it doesn't do anything until you capture / manufacture some items. 2) Stop it being quite so overwhelming. As such, there are three "sub-screens" in the design. http://www.xenonauts.com/devimages/stores1.jpg Screen 1 is what is show if there are no items in the base stores. Pretty self explanatory really. http://www.xenonauts.com/devimages/stores2.jpg Screen 2 is the "Sell" screen, which is shown by default when you load up the screen and there is something in the stores. This has all the functionality of the current stores screen, but minus the awkward columns for Transfer also shoehorned in there too. The base is selected by the dropdown in the top left corner. http://www.xenonauts.com/devimages/stores3.jpg''>http://www.xenonauts.com/devimages/stores3.jpg' rel="external nofollow"> http://www.xenonauts.com/devimages/stores3.jpg Screen 3 is the "Transfer" screen, which is shown when you click the Transfer tab in the "speech bubble" menu in the bottom left. Again, this has all the info you need to transfer items from one base to another without the extra columns from the Sell functionality mixed in. The bases in question can be chosen from the two drop-downs. Overall, I think the changes are pretty simple but they should make the screen both prettier and more intuitive. Hopefully I'll have the updated Personnel screen later today too.