Jorlem

And maybe a free automatic reaction attack if they try to move away from melee range?

Personally, I'd just like it if my scientists wouldn't destroy their notes if I tell them to switch to a different research project midway. I think that progress should not be lost if I decide something is a higher priority at the moment than what I'm currently doing. (Admittedly, I haven't played the most recent builds for the last few weeks, so if this was added, then ignore this.)

For a globe, to see both sides of the planet at once, you could have two circular shaped maps side by side, locked so that when you “rotate” one, the other turns as well by the same amount. That way it can bypass any potential issues with the engine not being able to display a 3d sphere for an actual globe.

I’ll second (third?) what was said about having the Cleaners get involved in other missions. Once they start showing up elsewhere, we could get Cleaner progress by recovering Cleaner corpses or capturing them, to replace the automatic uptick? Also, if they are meant to be the official response, while we are the rogue element actually getting things done, they should be showing up to fight the aliens occasionally to maintain their cover. Sometimes they might show up undercover at a crash site, replacing some civilian spawns, while other times they might show in force with a squad equivalent to the player’s, armed and armored like their reinforcements on the base missions. In those situations, the mission could turn into a three way battle. They should also show up in terror missions, as their cover as the official anti-alien response force should completely collapse if they don’t respond to that. Maybe we could research and build a radio interceptor (that later upgrades into the quantum decoder), that would allow us to detect Cleaner ops and try to intercept them. That could in turn allow for more defensive style missions, in addition to the current “rout the enemy” and “raid” style missions. For example, a VIP might be taking cover in a building, with its AI set to not leave, and the player needs to prevent the Cleaners from entering the building to kill the VIP. Or substitute the vip with a radar station they want to destroy, Heck, you could even get the chance to arrive early, and set up traps with remotely detonated explosives. That could be fun, and would be a very different play style than most missions.

I'd like to suggest the addition of a dedicated spy plane, and a camera/recon attachment that can be put on an existing airplane. What I envision this doing would, if you were to fly the plane over a crashed UFO site or some other aboveground mission site, you would start with the terrain revealed. Not the enemy locations, just the terrain. To work, the plane would have to go out and return before sending out the attack squad, and would need to overfly the mission site during the day. (The in-universe explanation would be that the recon photos would be used in the pre-mission briefing, so the soldiers would know what the terrain is. Out of universe, this would be to prevent you from having the recon flight go over the mission site right before the transport arrives.) For UFO crash sites, this could also tell the player what some of the aliens present at that crash site are, before the player gets the Quantum Array. To balance this, if the plane attachment is used, then the hostiles would know you are coming. This would result in a UFO crash site expiring sooner, potentially preventing you from waiting for daybreak, meaning that you would have to decide to go in blind during the day, or go in with more info, but risk needing to do a night mission (this is why needing to go back to base with the pictures before sending the transport out is important), and maybe adding the risk of Cleaner presence at the crash site. For Cleaner bases, them knowing you are coming could mean additional Cleaner troops present at mission start, or fewer turns before reinforcements start coming. If the player instead builds a dedicated spy plane, I'd say that would give a far lower chance of the plane being noticed, resulting in a lowered chance of the negative effects. In turn though, the player would be instead paying for this with money, resources, and a hanger slot being used for a non-combat aircraft.

I think this is the big thing. Once the rest of the game has been finalized, that's when it is time to update/correct the xenopedia. After all, what if they adjust some stats later on in the beta, that means they'd need to update the xenopedia again? And again? And again? It would just be making unnecessary work for themselves.

Lack of need? People overload soldiers and drop the stuff in the dropship because they feel they need the additional supplies. Provide an inventory in the dropship, and that need vanishes because it has been filled. You don't usually need that much extra stuff, after all. Edit: Can't figure out how to delete the double post, sorry.

Lack of need? People overload soldiers and drop the stuff in the dropship because they feel they need the additional supplies. Provide an inventory in the dropship, and that need vanishes because it has been filled. You don't usually need that much extra stuff, after all.

I'm not a fan of there being a hard cap on the carry capacity, I very much prefer the current soft cap. If there must be a hard cap, I think it should be set somewhat higher than the carry capacity soft cap. That way you aren't blocked if a grenade or ammo pack puts you just one or two over the weight capacity. Honestly though, I think the idea of a limited storage locker on the dropship that you can fill with what resupplies you think you'll need is much better than hard capping soldiers' weight/carry capacity.

If you need more saves for this bug, I provided a couple in this report (from 1.29d) I hope that is helpful.

Ammo, I agree with, but being able to have spare shields for when it comes time to breach the UFO? That would be really nice.

On the subject of the Reapers, I’d like to bring up the issue of their coloring. The reaper color palette is far too similar to the color palette used by the robot drones that the aliens have. When I first saw a reaper, I thought I was up against this game’s version of an andron, not a reaper thanks to that.

One of shield users panicked and fled, dropping their shield in the process. However, their character model on the map still shows them with a shield. As can be seen in the screenshot, Genta appears to be holding a shield, but does not actually have one equipped. I have attached a save I made when I noticed this, before I picked his shield back up. For the output log, it is the same one as is attached to this bug report. (Both bugs occurred in the same play session, and the file is so large it takes ages to upload. I hope you don't mind my not wanting to upload it again.) user_shield_drop_shield_model_didnt_update-15.json

I've noticed that when some objects on the tactical map, like walls or objects that provide cover are destroyed, the graphic is not removed from the map. This allows me to shoot through what appears to be a wall: Or stand in what appears to be a cover object (not sure what the proper name is): I've attached a save for both, as well as the output log. (As an aside, the output log is nearly 3/4 of a gigabyte, I can't help but wonder if the log might be a source of lag for extended play sessions on the experimental build.)output_log.txt user_destroyed_object_not_removed_from_map-16.json user_shoot_through_walls-14.json output_log.txt

I knew most of that (not that it could be done in flight, or that you could rotate the soldiers, though, thanks!), the intent of my suggestion was to make it obvious to players that the functionality exists by putting a button next to the Launch Dropship button that would take players directly to the screen where they can do it.

Came across this oddity. I didn't think to preserve a save until well after finishing the mission, sorry. Note the Wraith in the upper left portion of the picture. It looks like the black unrevealed terrain is cutting off the upper portion of the Wraith. Layering issue, perhaps?

Currently (as of V1.29d), when you go to send out a combat team, you are presented with the armory screen, where you can select who will be going on the mission, and what they are carrying. At the top of the screen there is a button to launch the dropship, and a button to abort the launch. I would like to suggest a third button be added, that would say something along the lines of "Prepare dropship". Clicking this button would bring you to the aircraft screen (or a slight variant, like how the screen where you launch the dropship from is a variant of the armory), with the chosen dropship selected. This is the screen that normally allows you to position where each of your soldiers is standing in the dropship at the start of the mission. The purpose of this suggestion is to give easy access to this screen when you are about to launch a mission, so if you change who is assigned to the dropship from the Launch Dropship armory screen, you don't need to back out of the mission prep to make sure everyone is in the desired starting positions.

The game crashes to desktop sometime during day 37 or 38. If I get far enough into day 37 for the research to complete, I select the Laser weaponry research. I am usually on speed 3. I've attached a save from day 36 and one from day 37. I've also attached a log file, the only one that was in the "...\Documents\My Games\Xenonauts 2\Logs" folder. I had the autosave interval set to 5 days (which didn't seem to create an autosave), but setting it to 90 days didn't stop the crash. (I've also attached the general settings file, in case that might help.) Please let me know if there is any other info I can provide. Edit: If it is relevant, I am playing the game via Steam. Edit 2: Found the Output.log file, it was in "J:\SteamLibrary\steamapps\common\Xenonauts2\Xenonauts2_Data". Probably because I don't have the game installed on my C drive. Anyway, I just attached the Output.log file, after re-crashing the game. Edit 3: Removed the output.log file, as the bug was patched according to the changelog, and the file had personal information in the header/file paths. user_day_36_manual_save-9.json resolve_layers.log user_day_37_manual_save-10.json general.json