Spring RTS Engine

Why is it units in BA such as snipers and penetrators dont attack the unit i click on? They just make up their own mind and shoot the nearest unit

Sucky_Lord wrote:Why is it units in BA such as snipers and penetrators dont attack the unit i click on? They just make up their own mind and shoot the nearest unit

They units they are firing at are probably slightly out of range.

In BA, if you target an enemy that is out of range, your attacking unit continues to fire at other units that are in range.

In the case of units like stumpies or flash, this is a good thing.

For units like Snipers, Penetrators, and Banishers (units with long range and equally long reload) it really sucks. You may be only 1 second out of range of the unit you want to fire at, but the sniper picks a random flea, kills it, and then you have to wait 10 seconds for the next shot.

The only way to fix this is to put your units on "hold fire" but that has disadvantages too. Don't forget to turn it back to "fire at will" when you're done microing!

Moreover, what's up with the control command? Sometimes it doesn't do anything and sometimes it says it's on patrol but it's not...

control panel is affected by lag i think (which is gay┬▓)
like if you have bad ping, toggling fire states is akward.

knorke wrote:control panel is affected by lag i think (which is gay┬▓)
like if you have bad ping, toggling fire states is akward.

State change is a command like any other, so it is affected by lag. The display itself is not lagging, it shows state the unit is in at the moment.

+1 to this thread.

I'm sure we never used to have this problem, it's darn annoying!

omg noobs. PUT YOUR SNIPERS ON HOLD FIRE

An auto-hold-fire-when-given-attack-to-low-ROF-unit-widget might be nice.

Pxtl wrote:An auto-hold-fire-when-given-attack-to-low-ROF-unit-widget might be nice.

Ive been thinking the same, anyone want to make this?

Regret wrote:

knorke wrote:control panel is affected by lag i think (which is gay┬▓)
like if you have bad ping, toggling fire states is akward.

State change is a command like any other, so it is affected by lag. The display itself is not lagging, it shows state the unit is in at the moment.

Things like that should show their state client-side with no lag. There will obviously have to be lag somewhere along the line but it shouldn't be in the controls. That's like saying it's better if you don't move in an fps until the server receives the information because it's more accurate. It's obviously better to move client-side because it's easier to control.

I think placing buildings and giving orders should be the same way in spring. Let the commands be given with no latency, put the delay in the action, not the order. But I'm not a developer so I don't know how much work that would take, and I'm sure it's a lot more work than it's worth.

Well, client-side command displaying might be too hard to implement, but at the very least the actions need to be queued properly - if I click the state toggle twice, it should get toggled twice instead of the current abominable click-wait-click-wait behavior.

Pxtl wrote:Well, client-side command displaying might be too hard to implement, but at the very least the actions need to be queued properly - if I click the state toggle twice, it should get toggled twice instead of the current abominable click-wait-click-wait behavior.

There is a widget which removes roam/return fire, so that both the buttons are nice single-click toggles. Called 'state remover' or something.

still you need to wait a short moment after clicking to see if your click got registered

Pxtl wrote:An auto-hold-fire-when-given-attack-to-low-ROF-unit-widget might be nice.

+1

It is easy to forget to set it back to fire at will afterwards, and the units become cannon fodder.

Try this widget:

http://trac.caspring.org/browser/trunk/ ... tstate.lua