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)