Talk:Wish List (EU)

Concerning Base Building Stacking:

At the moment you are only allowed to build next to a finished module, and you aren't allowed to plan ahead in your base construction. It would be nice to at least be able to plan more than one phase of construction in advance. This would be pretty easy to implement. There is no need to code any new "queuing system". Just place the new module next to an existing under-construction module, but increment the build time to the normal build time + the time remaining on the under-construction module (the lowest time remaining that would make the square you are building in, a legal square to build in). As a premium for build stacking, you have to pay the costs up-front. As with normal construction, all costs are non-refundable if you change your mind. (There would probably need to be some on-screen feedback for how long the module would take to build, before you were committed to building it.) Spike 12:06, 3 September 2008 (PDT)

There may or may not be an issue with this as you could technically construct the whole base in one sitting and thus overflow the 255 days to build variable. It's a single byte in FACIL.DAT so it would stand to reason that it is the same size in the executable. --Zombie 07:32, 14 September 2008 (PDT)

What *might* be possible:

• if you try to place an unconnected module, update BASE.DAT for the module part, but keep the time of constuction to 0xFF
• when a module is done, check if there is an adjacent square whose module type is different from 0xFF, but whose construction time is 0xFF, and start construction if it's the case
• modify the executable to do that

Seb76 10:00, 14 September 2008 (PDT)

What about something like that?

You can build anywhere, but it is "queued" if not adjacent to an already built square. Build starts when an adjacent square is complete. Seb76 15:45, 14 September 2008 (PDT)

Good point Zombie. The solution is a good one and I like the example from Seb76. The good thing about this mod is that is doesn't unbalance the game at all, it just makes the game easier to use. Spike 19:06, 14 September 2008 (PDT)

Off we go... Seb76 00:50, 15 September 2008 (PDT)

Decrease Accuracy for targets out of sight

How come you can easily shoot on something you do not see? I find the over-used scout-sniper tactic is a cheap exploit of the X-COM. The tactical game should describe a combat, not a cowardly shooting practice. It would turn into a nice feature, if there would be a penalty of (let us say) -20% to the accuracy of anybody who is firing on a target out of his current sight. This can greatly enhance the tactical depth of the game. (Seb around? ;-) --Kyrub 14:20, 30 August 2008 (PDT)

There is a penalty. Bullet drift. The further away you are, the more this will impact the bullet, potentially making even a 100% accurate shot miss. Also X-Com maps are pretty small, and the aliens already cheat enough as it is to make things difficult even with the sniper/scout strategy. In Apocalypse they addressed this with adding weapon ranges. But then, even some weapons were capable of shooting beyond the unit's ability to see an enemy target. - NKF 23:07, 13 September 2008 (PDT)

That's not really a good reason for me. 1) Bullet drift has a very small effect in the game, because the actual percents are set quite high. Example: if you spray an unseen alien from the other corner of the map with autofire of 35%, you'll get a 73,6% chance to hit with at least one bullet. Physics and game balance, adieu. 2) Moreover, bullet drift has nothing to do with not seeing the target. It should be the contrary, you ACCIDENTALLY hit something you don't see, no? 3) You get a penalty for handling two weapons in the same time. Why couldn't we take the same penalty (80%*Acc) for the hit-out-of-sight? (Well, I can't do this actually, maybe others can)--Kyrub 18:25, 14 September 2008 (PDT)

I don't agree that bullet drift is already there as a penalty, since this doesn't distinguish between seen and unseen targets at all (ok it does indirectly, only in so far as unseen targets tend to be further away). I think we should look at 3 cases: 1. person firing did not happen to be the one who spotted the target. 2. person firing could not see/spot the target under any circumstances. In the first case, we can assume the firer has visual contact with the target, after someone else pointed it out. No accuracy penalty should be applied (maybe a TU penalty?). In the second case, there should be an accuracy penalty. 80% would be generous, I would go for 50%. Or maybe something non-linear, so that autofire percentages would not fall by as much as aimed fire and snap fire percentages. One problem you have is how to present these two different cases to the player before they take the shot. It's a bit obscure if you just show them a lower hit probability without explaining why. Spike 19:02, 14 September 2008 (PDT)

Bullet drift is an effect on range (actually it has quite a major effect on the blaster bomb), but yes it's not because of whether or not the unit can see the alien. But then again, the maps are small. If you ever took lots of screen shots of the map and made a large composite from them, you'd find that the area of operations is very tiny and that the 20 tile visual range means that our avatars are quite short sighted. That's not realistic either, but imposed for game balance. Other tactical games appear to handle the accuracy vs. range dropoff issue by combining the shooter's skill and the weapon's maximum range. Basically you can operate the weapon to the best of the shooter's ability within the maximum range, but the further away you try to aim, accuracy is decreased. In some games, you even get to see the effect on the accuracy before you pull the trigger as the accuracy is attached to the cursor. - NKF 22:46, 14 September 2008 (PDT)

Actually the blaster bomb "drift" issue is not mainly caused by drift, but by accuracy adjustment between each waypoint (60% for xcom players, 55% for aliens). Maybe we can cook a kind of "max effective range" for a weapon base on firing mode (auto<snap<aimed) and gun type (pistol/rifle). Firing above this range would decrease the accuracy. Seb76 01:03, 15 September 2008 (PDT)

(to NKF) The main flaw of the whole "shoot the unseen" thing is the aliens cannot shoot back at somebody shooting at them (no reaction fire). If they could (or if they'd shoot at least the soldier they see), I wouldn't complain. This destroys the battle tactics side of the game, you just sent a man to "spot them". Nota bene, they cannot use the same scout-sniper tactic, the way we do, either. (This would be most annoying, by the way).

(to Seb76) Effective range would restore some balance and add some use to the aimed shots. I thought about a simpler solution with substracting some accuracy (which would make auto useless, snap into a poor and aimed into a solid chance-to-hit). Your suggestion is much more elegant, Seb, if you can cook it ;-) --Kyrub 08:00, 18 September 2008 (PDT)

Fair enough, but do note that even your units cannot react against an alien that they cannot see within their visual range. Attacks of opportunity and actively taking your turn are two different tasks after all. I'm not sure the aliens would be such sportsmen though. It might be worth looking into whether there is cooperation amongst the aliens while they are taking their turn - and I think I just have the scenario savegame to test this. If I could find it. BBs probably break the rules of basic firearms and range, and mind control has its own set of rules, so probably wouldn't count. -NKF 00:37, 19 September 2008 (PDT)

Hmm, maybe we could have accuracy impacted like this:

• aimed shot: no range penalty
• snap shot: penalty if shooting beyond visual range (reaction fire is not impacted since it uses snap shots)
• auto shot: no penalty if shooting under night visual range, small penalty if between day and night range, big penalty if above visual range.

Maybe we can use a function of the distance for the penalty instead of hard values. What do you think? Seb76 16:53, 19 September 2008 (PDT)

How about you reduce accuracy by (Effective Range / Actual Range), whenever Actual Range > Effective Range. This could be applied for all attacks, and applied again (or another factor applied) for out-of-sight targets. I would suggest that the effective ranges, in relative terms, are something like this order (highest to lowest):

• HWP / Terrorist weapons
• Heavy Laser
• Rocket Launcher
• Heavy Cannon
• Laser Rifle (or higher up for this one?)
• Rifle
• Plasma Rifle
• Auto Cannon
• Heavy Plasma
• Pistols (Laser Pistol, Pistol, Plasma Pistol)

(Yes I'm prejudiced against plasma weapons but I'd like to rebalance the game a bit. All that plasma just expands too quickly and interacts with our atmosphere too much for the bolt to stay coherent over longer ranges.)

Now, apart from the problem of coming up with the values for Effective Range for each weapon - where would they be stored? Spike 10:45, 20 September 2008 (PDT)

The point of using visibility range only is not to have to specify effective range per weapon; tuning good balanced values can be quite difficult. As for their storage, they can be hard-coded in the loader, or defined in the ini file. Seb76 05:23, 21 September 2008 (PDT)

Good point, tuning it correctly is very tricky, it would be easier just to use visibility range rather than creating new "max effective range" for various weapons and making sure it's balanced. A couple of other options when the sniper is outside visual range: 1. disallow the attack with an "Out of Range" message. 2. allow the attack but only for Aimed Fire, otherwise give an "Out of Range for [Snap Fire|Auto Fire]" message. As was mentioned, this restores some use to Aimed Fire which otherwise is under-used. For this to make sense, we would have to take the interpretation that "visibility range" means "spotting range". Clearly it does not make sense to be able to do Aimed fire at something you cannot possibly see at all, even if you know where to look for it. So if, on the other hand, we assume that an out-of-range sniper can't see his target at all, the accuracy should be reduced to something lower than the lowest accuracy of the weapon - say half of auto or snap accuracy. Spike 05:49, 21 September 2008 (PDT)

(Off Topic: this all should be now moved to the 'talk' page, no? Can anybody do it?)

Let us keep the change simple! When the game mechanics are too complicated (for the realism purpose or other), you lose control over the way the game is played. While I understand your points, Spike, I'd personnally go with what Seb76 has suggested: Aimed - no penalty, Snap - penalty at vision range (20), Auto, Full auto - penalty on night (9) range. Plus the customization in the ini file. We need to rethink all the launchers, I could let them with no penalty (they seem to be guided).--Kyrub 13:00, 23 September 2008 (PDT)

Some prototyping...

Here is the algorithm. Note that I use a "GetDistance" function freely provided in the executable. It's the original one used for visibility range check. Spotting range is 40 units with this function (divide by two to have tile equivalent).

int efficiency=100;
switch(mi->actionType)
{
	case 1://autoshot: penalty starts at 14 (7 tiles)
		if(distance>14)
		{
			efficiency-=(distance-14);
		}
		break;
	case 2://snapshot: penatly starts at 30 (15 tiles)
		if(distance>30)
		{
			efficiency-=(distance-30);
		}
		break;
	case 3://aimedshot: no distance penalty
		break;
	default:
		return;
}

if(efficiency<50)
	efficiency=50;

I did not hook up the efficiency factor yet so it is pure decoration for now... Waddya think? Seb76 04:58, 26 September 2008 (PDT)

Edit: I updated my loader with a first implementation. Seb76 15:17, 26 September 2008 (PDT)

Looks good! Spike 11:19, 26 September 2008 (PDT)

Throwing over stuff

(Moved to Talk, as this is not a bug and so does not need fixing.)

I want to throw stuff over other stuff. I don't find grenades useful. I much rather shoot a rocket launcher from outside reaction shot range because even when you miss, odds are it's close enough. The throw itself has an arc trajectory and can hit the ceiling (a feature I like) but to pick the target it has to have straight line of sight (like a bullet) which is stupid. I want to throw onto the top of buildings where I can't see, or bounce a grenade off the ceiling and over the head of a squadie because I don't have line of sight with a gun. If I had line of sight, I would just shoot since that costs less TU even if I already had an armed grenade.

The easiest way to accomplish this is to keep "out of range" but remove "you can't throw there" and just let a solider throw to any square they want. A better way is to keep the warning but give the player the option to try the throw anyway. If you can't really throw there, then oops... that's your badly positioned live grenade to deal with.--Brunpal 22:59, 11 September 2008 (PDT)

I did some tests disabling the "you can't throw there" check and it does not work. The grenade ends up in the vicinity of the throwing unit. Actually the line of sight is not used when throwing objects. I'm 98% sure it simulates the throwing of the object and if it intercepts anything, the throw is refused. Seb76 04:47, 13 September 2008 (PDT)

The explicit emulation of the trajectory has been verified as part of the throwing range testing by Zombie and myself. The range bands are not consistent with a continuous model; they look like a table lookup from the same source 3rd ed. GURPS (Steve Jackson Games) uses. -- Zaimoni 8:21 13 September 2008 (CDT)

Units don't need LOS to an area to throw a grenade, as evidenced by my favored tactic of chucking an Alien Grenade or HE Pack into any Medium or Large Scout which has had the roof blown away in the crash from outside to 'pacify' any remaining crew. Arrow Quivershaft 09:22, 13 September 2008 (PDT)

Really? It never seems to work for me. Always requires me to have line of sight. For example tossing in a grenade into the roof hole doesn't work for me if the solider is on level 0 and I target a square inside at level 0. The walls and door obviously block the LoS. However I can target an area on level 1 or 2 in mid air and throw to that location where it naturally drops down to level 0. However I have line of sight to those higher levels in that case. That's an acceptable compromise in many cases but in others it fails completely. For example having an alien on the top of a 2 story building (level 2) in the middle and a solider standing next to the building and not being able to toss a grenade onto the center of the roof. I could toss a ball there in real life. I wouldn't have thought the trajectory would have been high/steep enough to hit the "sky roof".--Brunpal 22:04, 13 September 2008 (PDT)

Just how strong are your soldiers? The stronger they are, the higher their toss. There are various occasions where you don't need to see where you're throwing to throw. For example, try tossing grenades over a tall fence or hedge. A High Explosive pack into the apple orchard that is surrounded by a hedge on farm maps is often an easy way to smoke out any hidden aliens - and the orchard. One likely cause why you can't throw inside the UFO is that there's something in the way inside that's preventing the throw, such as a wall. Try adjusting your throwing destination, or reposition your soldier for a better throwing angle.

I've often found grenades to be much more reliable than a directional attack early in the game where firing accuracy is much lower. You ought to try playing a few of the simpler missions like supply ship or large scout assaults with an all-grenadier cast. Takes a bit of planning to not destroy much of the loot, but otherwise literally a blast. -NKF 22:52, 13 September 2008 (PDT)

Invasion Mod

amitakartok

• • If any UFO passes within a certain distance to a base without a Mind Shield, the base is immediately discovered. It doesn't matter what mission it is on, not having a Mind Shield means instant detection. Accordingly, later retaliation missions do NOT send scouts but go for the battleship immediately. The outcome depends on what kind of defenses the base has:
    • No Grav Shield - Battleship gets through defensive fire: Base Defense mission. If the attack is repulsed, the aliens send another battleship next month.
    • No Grav Shield - Battleship shot down by defensive fire: the aliens send another battleship next month.
    • Grav Shield - Battleship gets through defensive fire: the battleship finds itself unable to land so it simply blasts the base into ashes. Entire base and all its contents are lost, no Base Defense mission possible.
    • Grav Shield - Battleship shot down by defensive fire: aliens decide the base is too heavily fortified and back down. Retaliation mission ends (until X-Com provokes another one, that is).
  • Countries with an alien base sitting on their soil for more than a month are automatically infiltrated.
  • Aliens deliberately targeting the country with the lowest X-Com activity with infiltration instead of choosing randomly.
  • More severe consequences for alien infiltration: if a country signs a pact, X-Com is banned from that country.
    • All X-Com assets (bases, craft, personnel, items in storage) within the country's borders are automatically and permanently confiscated at the turn of the month the pact is made.
    • X-Com operations inside that country suffer a massive score penalty as they're technically violating the country's borders and airspace, causing international tension between the country (who feel the Council does not respect the charter that allows countries to withdraw from the project) and the Council (who never agreed to withdrawing X-Com's services from quitter countries in the first place).
  • No matter how well the player actually performs, funding WILL keep dropping in the long-term as the sponsors become dissatisfied with X-Com. In fact, funding from all nations will eventually drop into the negative as the sponsors try to pressure X-Com into disbanding (well, that and ongoing rumors of X-Com self-financing through arms dealing causing them to try and get their share of the profits).