Max_Caine

I like most of this, there's a good framework here for future possibilities, however, just one question regarding Weapon/Armour level. Is it absolute or relative? By that, I mean armour/weapon level currently looks like any bonus is defined at the point of interaction, so a "level 2" weapon that interacts with a "level 4" armour would grant the armour the +2 armour bonuses, whereas a "level 8" weapon interacting with the same "level 4" armour would grant the weapon the +3 weapon bonuses (+3 being the maximum bonus permitted). This means any bonus granted is always relative to the difference between the armour/weapon levels, with a cap regardless of the difference between armour and weapon. Or, are weapons/armour assigned a specific bonus level (0/+1/+2 etc) at creation, and only get that bonus if the level of the weapon/armour beats the opposing level of the armour/weapon? In that case the level is absolute.

Orbital Bombardment from a Narrative perspective Anyone who's completed the Alien Fleet research topic knows that a space station doesn't make sense in the context of the research topic. However, there are 20,000+ Near Earth Objects in varying distances away from the planet. Instead of alien space rays or alien space bombs, the first the world is aware that they're being shot from space is when a Chelyabinsk-esque meteor rams into a mid-sized town or small city. At first there's wild panic and disarray, but then the panic subsides when it's pointed out this is "just an asteroid". Only when it happens again, and again, and again and the closest (hence the easiest to see) NEOs start disappearing from the skies that the horrible realisation that these are being used as weapons sets in. I feel that this would fit better within the narrative construct presented in Alien Space Fleet research.

This is a reasonably easy question to answer. How much time (and therefore money) can I, as the lead developer, spend on any individual part of the game? Typically, the answer is "not a lot", especially if the part of the game in question only applies to a subset of the game's mechanics. You want to try and keep systems as simple as possible so debugging them is relatively straightforward. In other words, you cheat. Take XCOM's grenades, for instance. There's no scatter (removing the need for a scatter system). You can't throw a grenade on anything except a flat surface (removing the need to work out how thrown objects interact with non-flat surfaces). An arc is drawn between the thrower and the landing zone, but I suspect that this is simply for UI purposes - the arc doesn't play any part in working out where the grenade can go. To prevent grenades from being the only weapon players use, you then artificially restrict the number of grenades a squaddie can carry to ludicrous levels. Hey presto, you have grenades which work and a reasonably fun to use.

Regarding throwing arcs At the moment, all discussion has been centered around the assumption that an object when thrown in an arc can reach the landing zone unimpeded. This is possibly true when there is no variance in the landing zone, but what happens when there is variance? There is the possibility of mid-air collisions, where an object on a higher level which had not been previously accounted for in the initial throwing action can impede the movement of the thrown object once the variance of the landing zone has been calculated. PP handles parabolic arcs and scatter variance so there are lessons to be taken away from PP. To begin with, PP gives you no clue as to how far the thrown object will scatter. You choose a point and cross your fingers. You also have no idea if a thrown object will intersect an another object. If it does, the thrown object either explodes if it can, or interacts badly with the object it collided with. It's common in PP for the worms which Chirons launch to end up underneath or inside props, because the engine can't handle it. I think if a proper arc was to be drawn between target and launcher, then all thrown objects would have to detonate on impact regardless of what it impacts with or you end up with the problems with object interaction that PP has. PP also ONLY models parabolic arcs. This is frustrating when inside bases, because the arc of a thrown object is often high enough to intersect with the upper part of doorways. Arcs hopefully could be either parabolic or elliptic, to simulate objects thrown in as close to a straight line as possible.

Report that as a bug then.

I think MARs shouldn't be healable mid-fight, especially NOT with medkits (I suspect that's a bug).

Oops, I didn't mean harshly! It's just that if the number of rocket launchers were artifically limited then that would likely raise objections (why can't I give everyone a rocket launcher!)

With the MARS I can see the reason for having Xenonauts and aliens in bright, distinctive colours. The MARS's olive drab shell, while a natural colour for a remote weapons platform, is awfully murky, especially on farm maps. It has no pop like Xenonauts do.

The Reaper is very closely modeled on the Chrysallid of X-Com fame. The Chrysallid was infamous for having a combination of high AP and low cost for their zombification attack so even if there were only 1 or 2 Chrysallids on a Terror map they would quickly infect and create a horde of Chrysallids. I suspect the same is happening here - the starting Reapers go out and infect some civvies, who become Reapers, who infect MORE civvies and it snowballs until you end up with a slavering pack of monsters.The question is, is this desirable behavior? I feel there should be the threat of civvies being turned into living larvae, but not the certainty. That, however will likely come down to map design.

If you want to impose a limit to the number of HEVY's carried, a more natural (and henceforth less objectionable) way of doing it would be to make the HEVY manufacturable, imposing a steep initial cost in terms of time and money to deploy, and make its ammunition manufacturable, imposing an on-going cost that eats into manufacturing other items.

I strongly urge anyone who feels one way or another about grenades and scatter to post their thoughts on this thread. It's your chance to weigh in on a fundamental mechanic of the game.

Textboxes from popup text occasionally become "sticky". That is to say when you move the mouse ponter off the box they appear from, they stick to the mouse pointer and follow it around the screen. The only solution to fixing it is to return the mouse pointer to the item they popped-up on and let it rest for a few seconds before moving the mouse off.I've noticed this from version to version but never cared to find out why. I think I have found out. If you move a mouse onto a popup box area (such as the geoscape box in strategy, or the end turn box in ground combat), let it rest breifly then move the mouse away before popup text appears, the popup text will still appear and become stuck to the mouse. This is by no means a foolproof method - it takes a little practice to get a sense of the timing (not too much to have he box popup on the area it pops up on, but not enough to have no box appear) however it is reproducable and does not need to be frame-perfect to reproduce. It is in fact most likely to happen when you don't realise it as the pointer moves briefly over a box (such as the last turn box) or transitions from one screen to another (such as moving from the soldiers screen to the geoscape). The stickyness is a special kind of annoying. It's very much like gluing your fingers to a dowel instead of the furniture you have unpacked around you. You want to shake the pointer free of the text, especially when it's a large textbox and covers up parts of the game area.

Left-Click on the medical center from the base screen. The number of scientists should drop by 1, that scientist is then assigned to the medical center.

I had a look at other contemporary games and saw how they dealt with grenades. XCOM 2 like its predcessor deals with grenades and indirect fire weapons by perfectly calulating an arc. Whatever the end tile of the arc is, the grenade is desposited there. There are no mid-air collisions - if the arc can't be traced through to a flat tile, then you can't throw it. I suspect the developers for XCOM and XCOM 2 found it easier to do this and artifically restrict the number of grenades a squaddie can have than try and model it more authentically. PP models grenades more authentically. Grenades and indirect fire weapons always scatter. The degree to which they scatter is dependant on the distance they travel, and a true parabolic arc is modelled after the final landing point is determined. You can have mid-air collisions - a grenade or an indirect fire weapon can be stopped by an intervening piece of terrain that is NOT a flat tile. However, grenades and indirect fire weapons are always modelled as perfect arcs, which is frustrating in certain situations, especially inside a building. OpenXcom was a facinating read. Looking at this thread: https://openxcom.org/forum/index.php/topic,1532.0.html it would seem the OpenXcom prefers an eliptic arc rather than a parabolic curve. And in fact in this thread: https://openxcom.org/forum/index.php/topic,4726.0.html states baldly that the arc is formed from a series of points and a straight line is drawn between each those points, so not a true arc at all. For all these games, grenades and othe arcing weapons ignore the usual rules for shooting in that game. It seems necessary to work out an arc and see if that arc collides with props. EDIT: Having thought about Solver's comments, it occurs to me that players are more likely to want something even with cases such as Solver's scenario, that to have nothing at all because of said cases. People have an infinite capacity to explain away implausible situations or make amusing youtube videos out of it.