This is a relative big issue for high level defenses with setup time. They will go to idle status as soon they have no direct line of sight to any enemy, even if this enemy is in weapon range. I understand that this defenses can't shoot because there is a friendly unit in way (i appreciate that), but when they need 10 seconds setup time and the enemy i nearly in sight range, it's really NO good idea to go in idle status for that defenses.
As best example take Doomsday Machine and Annihilator.
Behaviour of defenses according to free line of fire
Moderator: Moderators
Regarding overwatch .. if this is built in, idle status should provide a considerable armour bonus (i.e. against aerial or nuclear strikes), otherwise idle would be useless.Dwarden wrote:maybe manual mode "overwatch" where unit stays in "ready" position ...
and also mode "scan defined angle" where turret will check defined angle (0-360 degrees) and so on ?
To you second proposal can you explain what you mean with that?
Normally in TA the time before which a pop-up cannon, an annihilator, or anything else with opening animation, folds up back after having fired and not having seen other enemy is regulated by the script.
However, I noticed that the spring engine has a tendency to skip "sleep" command in the scripts.
And yes, well scripted units go into ARMORED state when folded, which makes them take less damage when folded. The original cavedog solar is not well scripted.
However, I noticed that the spring engine has a tendency to skip "sleep" command in the scripts.
And yes, well scripted units go into ARMORED state when folded, which makes them take less damage when folded. The original cavedog solar is not well scripted.
-
PauloMorfeo
- Posts: 2004
- Joined: 15 Dec 2004, 20:53
Re: Behaviour of defenses according to free line of fire
Well, actually, the pop-up cannons (small guardians) have fired at my missile towers destroying themRayden wrote:... defenses can't shoot because there is a friendly unit in way (i appreciate that), ...
.And actually, in the original TA, the Guardians ocasionally shoot Missile Towers that happen to be close.
Such a bad temper on those Guardian towers...
Indeed, they do. Pop-up cannons and heavy lasers take much less damage. Something like 10%/20% of normal dmg, i think...Rayden wrote:... idle status should provide a considerable armour bonus ...
Okok i believe you, but i don't want discuss line of fire or how strong they are armored.
There is still the problem that they shouldn't fold if there are enemies within possible firerange.
Unit should only be allowed to fold back if there is no enemy around in a 360° radius within fire radius, regardless of los to this enemy.
There is still the problem that they shouldn't fold if there are enemies within possible firerange.
Unit should only be allowed to fold back if there is no enemy around in a 360° radius within fire radius, regardless of los to this enemy.
it's mean as forced "stay in aware mode and scan "choosed" angle area ...Rayden wrote:Regarding overwatch .. if this is built in, idle status should provide a considerable armour bonus (i.e. against aerial or nuclear strikes), otherwise idle would be useless.Dwarden wrote:maybe manual mode "overwatch" where unit stays in "ready" position ...
and also mode "scan defined angle" where turret will check defined angle (0-360 degrees) and so on ?
To you second proposal can you explain what you mean with that?
this way you can have e.g. one or two turrets always within "IMMEDIATE" fire status ...
of course it should eat more power and they can be more vulnerable as You already said ...
Here is a misbehaving unit (version with spring texturing) and here is how it behaves in TA (second post). Ok, too many scripts lines, and too many issues, with that unit, you probably have better things to do than looking at it. The thing that annoyed me most is that in AimPrimary(heading, pitch), at line 2402 I have a while ((!turret_presence)+(menu_mode)) {sleep 1000;}, and that spring ignored it, my turret kept on firing and refused to enter in jam-mode. Also, apparently the TransportPickup(unit_id) {unit_tracking_on=1; other_unit_id=unit_id;} wasn't exectued when clicking load on another unit. Hmm, you'd probably better wait for simpler exemples.