Dudeman Jones

That is roughly where I put my first base, even back in X-Com. Fun fact: It's also roughly where the main headquarters for Rainbow Six are located in the books, for about the exact same reason. ~Dudeman Jones

If we are just giving an order to Civilians, then why do we need direct control over them? Rather, how about Xenonauts within a certain radius (3 to 5 squares was mentioned, but 5 is a large area so lets say 3), the player can select a civilian like a unit, but cannot equip anything and is almost out of AP, just enough to spin the Civie in a new direction, or crouch and stay put. Then during the next civilian turn, they will automatically run roughly in the direction that you pointed them in. To prevent abuse of the tactic, you could increase the score loss of ordered civilians for a set amount of turns. Additionally, there can be a chance of failure baked into the mechanic as well. The higher rank the soldier who gives the order is (biasing to the highest rank in the civilians command radius), the greater the chance the civilian will obey the command. The more aliens there are in the same radius, the greater the chance the civilian will panic and do whatever the hell it wants to. Based on these, you're likely to see new playstyles emerge, specifically players setting up safe routes of passage in order to evacuate civilians from a hostile area to areas that they have cleared. With the command bonus associated with rank, higher ranks are now needed on the battlefield to help maintain order not just of your soldiers but of the civilians you are tasked with protecting as well.

Some thoughts on your list. 1.) While I do agree that someone carrying a Precision Rifle should get some sort of accuracy bonus if their target is being spotted, you have to be careful not to overpower this bonus. Precision Rifles are already pretty damn powerful with their high armor penetration ability. Perhaps a minor rework of the accuracy/damage formula could be done for the Precision Rifle where having a target "spotted" mitigates the damage and accuracy penalties from range. The risk of course is creating a touch of death unit, but again this can be prevented by having the spotting bonus only bring the shot back up to baseline, not exceeding it. For balance, you could have the spotter need to have binoculars equipped, limiting them to one hand weapons. 2.) X-Com has always worked well with the Ballistic/Laser/Plasma progression, so adding a human super tech tier seems out of place , largely on the level that humanity is kinda supposed to be completely screwed if left to it's own abilities. It's only by adapting the xeno tech that humanity gains a snowballs chance of survival, and even if the bio force gun or whatever would be converted xeno tech, it smacks a bit to strongly of the blaster launcher, which is being dropped entirely. Just get into the heavy laser/plasma weapons, then reach out an touch somebody (at 7000 degrees F). That being said, it's been brought up a number of times that it would be cool to have technology trees that keep the Ballistic tier viable. The best suggestion I saw was rail guns or gyro jet weaponry, the idea being that Ballistic weapons are the armor piercers. 3.) EMP grenades maybe, but even then I question it. Effectively they'd be anti-andron weapons, who are currently balanced against being suppressed and having a ton of armor. It's an idea, but I'm not sure about it. 4.) Someone correct me if I'm mistaken, but didn't X-Com have proximity grenades? I remember them existing, but I don't think I ever used them. The issue is that mines are a defensive weapon, and most combats are assaults. Even in the case of base defense, you are inside the base itself, so I wouldn't think that mines inside my secret underground fortress would be a good idea. 5.) Again, deployables are typically defensive weapons, so they would encounter the same issues as the mines. The extra firepower would be useful true, but having to break and redeploy every other round would probably make it not worth it. 6.) In battlescape I'm pretty sure it's already been said that artillery support wouldn't be feasible. Not to mention hinging an entire nations funding support on one mission is pretty game breaking for a game like X-Com/Xenonauts, where a mission can go straight to hell in one turn. On the base defense side, if Xenonauts keeps with the form then we will probably see base shielding that helps to protect the base initially, reducing strength of the assault force.

Just did an initial quick battle to see what I could find. I have only tried the .deb version (Debain/Ubuntu) Game installed ok, though it took a while for the .deb file to load in fully. The wrapper pulled in settings from my local winecfg configuration (i've been using a virtual desktop to prevent having to hard reset my computer should it hard lock), but not sure if it's supposed to do that (assuming that it is in fact utilizing a wrapper) In game performed identical to my manual installation i run through wine anyway, but I did notice a few things. I didn't get any screenshots as this was just a blind run to see if I encountered any horrific crashes. 1.) Upon loading into a quick battle, after starting the game and selecting europe, I received an error stating that "precursors could not be saved". I clicked the provided OK button, and the battle loaded apparently as normal. 2.) Some previously documented clipping issues with characters and walls, as well as the half erased wall bug when a wild shotgun blast hit a house wall next to a window. 3.) Late in the battle, I had a unit jump a hedge and run to another hedge beyond it, while carrying a medi-kit. The game did not remove the pathing tiles as the unit ran, instead keeping the whole path lit, and progressively turning red from the end of the path towards the start of the path. Also, the AP left counter kept counting down as the unit moved, eventually ending up at -44 AP when the unit arrived at the second hedge. At this point the path tiles were completely red briefly, then disappeared along with the counter when the move order was fully completed. The unit's AP was where it should have been after the move, as opposed to the -44 AP listed. I'll try to see if I can duplicate the first and third issue before filing a proper bug report. Ideally with either video or screenshots. ~Dudeman Jones

I fear what happens when you fire a 2 billion AP rocket o_o...

I sent an email as well, but I'd be happy to help test. I'm running Linux Mint (Ubuntu/Debain effectively, which accounts for some ungodly percentage of actual Linux users) at the moment, but I can easily set up some alternate live OSs to test other flavors if need be.

Hunter was destroyed on enemy turn, but commands were maintained on my next turn. AP for launching an attack from the now dead hunter is ridiculous, and I also am shown the move cursor for the vehicle as well if I press escape. I can still select a new soldier, and cannot regain control of the dead hunter after doing so. http://imgur.com/DTkNb

System: Laptop running x64 Linux and Wine Processor: 2GHz Intel Core 2 Duo Video Card: GeForce 9300m GS with 512MB video memory RAM: 4GB Not sure how useful this is, but given that from what I've read thus far the Linux release will be a Wine wrapped version of the game, I figured that it may be helpful to the devs. Hard crash during Industrial tileset Crash occured during attack at long range with machine gun, past other friendly units, upon enemy unit that was already supressed. Friendly Hunter vehicle was located behind the target, and fire and smoke effects were present on screen of attacking unit. Terminal dump fixme:system:SetProcessDPIAware stub! fixme:system:SystemParametersInfoW Unimplemented action: 59 (SPI_SETSTICKYKEYS) fixme:system:SystemParametersInfoW Unimplemented action: 53 (SPI_SETTOGGLEKEYS) fixme:system:SystemParametersInfoW Unimplemented action: 51 (SPI_SETFILTERKEYS) fixme:win:EnumDisplayDevicesW ((null),0,0x33f48c,0x00000000), stub! err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 1 on device context 0x3c8. err:d3d:context_choose_pixel_format Can't find a suitable iPixelFormat err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 1 on device context 0x3f8. fixme:d3d:wined3d_get_format Can't find format WINED3DFMT_R24_UNORM_X8_TYPELESS (0x49) in the format lookup table fixme:d3d:getDepthStencilBits Unsupported depth/stencil format WINED3DFMT_UNKNOWN. err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 25 on device context 0x400. err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 13 on device context 0x408. err:d3d:context_choose_pixel_format Can't find a suitable iPixelFormat err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 1 on device context 0x410. err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 1 on device context 0x418. err:d3d:context_choose_pixel_format Can't find a suitable iPixelFormat err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 1 on device context 0x420. fixme:d3d:wined3d_get_format Can't find format WINED3DFMT_R24_UNORM_X8_TYPELESS (0x49) in the format lookup table fixme:d3d:getDepthStencilBits Unsupported depth/stencil format WINED3DFMT_UNKNOWN. err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 25 on device context 0x428. err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 13 on device context 0x430. err:d3d:context_choose_pixel_format Can't find a suitable iPixelFormat err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:context_create Failed to set pixel format 1 on device context 0x438. wine: Unhandled exception 0xc0000417 at address 0x743ce4 (thread 0009), starting debugger... Process of pid=0008 has terminated No process loaded, cannot execute 'echo Modules:' Cannot get info on module while no process is loaded No process loaded, cannot execute 'echo Threads:' process tid prio (all id:s are in hex) 0000000e services.exe 0000001f 0 0000001e 0 00000015 0 00000010 0 0000000f 0 00000012 winedevice.exe 0000001c 0 00000019 0 00000014 0 00000013 0 0000001a plugplay.exe 00000020 0 0000001d 0 0000001b 0 00000021 explorer.exe 00000022 0 winedbg: Internal crash at 0x7ed4e29a

This so hard. I just did a battle this morning where a civilian ran directly in front of an alien, who then promptly shot him in the face. Some chaos is a good thing, but the civilian AI needs worked a bit. What if civilians generally run away from aliens towards either other civilians and/or armed friendly units, so long as they don't feel surrounded (define surrounded as being within such a radius of an alien). If a civilian is surrounded, then let them panic and run in a random direction, or just hide in a corner. Also, I don't know how feasible this is, but it would be nice to be able to yell orders or rudimentary directions to NPCs, i.e. get behind us, run N/S/E/W. Been a number of times where I just wanted to yell at a civie to get hell out of the way.

I've been getting roughly 10-15 fps here. I'm running on a dual core 2GHz CPU with 4 gigs of ram under x64 Linux/Wine. One thing I did notice though is that the program is only using one core. Not sure if that is a limitation of Wine or the game itself. TBH, I have no idea how feasible multi-threading is through Wine. One thing I have noticed though is that it seems to take forever to launch. Don't know if that's my own setup or what though. Update: The launch time seems to be random for some reason. I'm inclined to blame it on my old laptop though.

Abyss expansion pack anyone?

This would add a huge level of danger to missions. For every dead/mia soldier in a bailout mission, the alien ticker goes up by so much. It could create totally screwed scenarios though, so perhaps leave it as an Ironman Mod.

I vote for my old X-Com motto. "X-COM! COLLATERAL DAMAGE HAPPENS TO OTHER PEOPLE!"

Vehicle degradation isn't a half bad idea, but making it permanent is unnecessary. I'd say a better idea would be to go ahead and implement it, but also give players the ability to overhaul the vehicle and restore lost performance. Doing so would take that craft out of service for a time, say 1-2 days given that the work would be performed by the best mechanics humanity has to offer, likely with plenty of spare parts to acquire. Perhaps even scale the overhaul time with how much work needs to be done. In addition, overhauling a vehicle would incur a monetary cost, in order to acquire the new parts necessary to rebuild the craft, but this cost would be, up to a certain point, dramatically less than purchasing a new aircraft, again scaled to how much actually needs done. This could be further developed by having the overhaul cost and the replacement cost cross at some point, the idea being that after a certain threshold it's actually more expensive to overhaul an existing vehicle than to replace it. So why do it after that point? Perhaps adding a morale type of stat would be a good idea, measuring the operators level of attachment/confidence with that machine. It's a well known fact that operators develop a level of attachment to their equipment that can and often does affect their performance with said equipment; Hell X-Com itself is a good example of it. So by keeping a craft maintained, the operator maintains a higher level of performance with that craft as opposed to replacing it, reflecting the operator being more familiar with the quirks and nuances unique to that machine. In game mechanics, this could be reflected as a small bonus to performance, say 10% skill bonus. Combine that with the engagement history idea that Safe-Keeper had and that could be very cool.