Better warning system

[smoth]

Leave the highschool labels in highschool please.

We are concerned first with providing the existing behavior so that it is available for those who have come to rely on it then replace it with a better one.

So the worry is user experience.

[knorke]

http://pastebin.com/sefpiDGq
not really tested
cba to do the extra commander warning/sounds. (dont feel like listening to beep beep dooot)

My experience is that people just press F5 when this happens in spring

F5=hide UI. You mean F6=no sound?

[Jools]

Yes, I mean F6. I usually press both in panic when I'm attacked.

[Jools]

http://pastebin.com/sefpiDGq
not really tested
cba to do the extra commander warning/sounds. (dont feel like listening to beep beep dooot)

So it's a widget. In other words you mean every user do this himself? I'm cool with that, but I believe newbies aren't. Maybe make a spring option that shuts down warnings and lets you override them with widget then.

[smoth]

OR complain to the game dev....

[knorke]

So it's a widget. In other words you mean every game adds it and the user does nothing.

fixed.

[Jools]

Allright, so I think we found consensus. Just make it possible to disable unit warnings and we'll override the system with own lua.

[Beherith]

I see that cant reach destination was removed as well.
Is there a callout for it?

Code: Select all

-  logOutput.Print(owner->unitDef->humanName + ": Can't reach destination!");

[knorke]

UnitMoveFailed() --> "unitID, unitDefID, unitTeam"
did not test.

Btw, vbs finished remaking the warning system in Lua but I don't know if it is uploaded somewhere already.

[Beherith]

Talking to him how about the warnings. He'll check out unitmovefailed.

[very_bad_soldier]

I see that cant reach destination was removed as well.
Is there a callout for it?

Code: Select all

-  logOutput.Print(owner->unitDef->humanName + ": Can't reach destination!");

I tested that UnitMoveFailed but could not get it to get triggered. The constructor I tested just moved in circles to eternity withouth that callin getting called? Engine issue or is that callin only used under certain conditions?

[very_bad_soldier]

Well, the whole engine crashes at some point when UnitMoveFailed is defined
http://springrts.com/mantis/view.php?id=2847

Also here is a first version:
http://dl.dropbox.com/u/24641738/unit_a ... cation.lua

-Prints notification.
-Plays alarm sounds
-Jump to location using F3 (doesnt work currently due to engine issue)
-Move failed notification (also doesnt work)

Please test before I commit it to BA, so we dont have another game breaking Lua error.

Its all based on knorke's widget, so thanks for it!

[Jools]

Going back to this thread, is the above mentioned issue still true. I can't get UnitMoveFailed to trigger. Is it not yet implemented in engine?

[quote="wikI"]UnitMoveFailed() --> "unitID, unitDefID, unitTeam"
Only called for unitDefIDs registered via Script.SetWatchUnit since 85.0[/quote]

[MajBoredom]

Re: the original idea with the warning sound: it's a good idea but the fix needs to be carefully thought out.

For example, in BA it is a very common strategy to set up a "flea spam" lab which repeats fleas and sends them into an enemy base with a FIGHT or MOVE order. When the fleas start to arrive, you get non-stop warning klaxon noises. Here you'd prefer not to get all the warnings.

However, it is also common practice to place a flea near a choke point as a "sentry". It acts as an early warning of troop movements when towers and radar are too expensive or risky. Here you'd prefer that the warnings not be completely muted for fleas.

So, it is not as easy as disabling the nth warning message for a given unit type as this may obviate strategies that involve the warning system -- and leading to player frustration.

Ideally, you don't want to receive messages from the same spatial location more than at some critical frequency, or you want that frequency to lessen as the number of warnings in that region increases. But then the solution becomes much more complex.

[Jools]

Re: the original idea with the warning sound: it's a good idea but the fix needs to be carefully thought out.

For example, in BA it is a very common strategy to set up a "flea spam" lab which repeats fleas and sends them into an enemy base with a FIGHT or MOVE order. When the fleas start to arrive, you get non-stop warning klaxon noises. Here you'd prefer not to get all the warnings.

However, it is also common practice to place a flea near a choke point as a "sentry". It acts as an early warning of troop movements when towers and radar are too expensive or risky. Here you'd prefer that the warnings not be completely muted for fleas.

So, it is not as easy as disabling the nth warning message for a given unit type as this may obviate strategies that involve the warning system -- and leading to player frustration.

Ideally, you don't want to receive messages from the same spatial location more than at some critical frequency, or you want that frequency to lessen as the number of warnings in that region increases. But then the solution becomes much more complex.

Yes, this can become very complex. But even a in a complex system, the individual pieces can be quite simple. As long as we can improve the status quo, there is no harm in trying to do more.

The thing about spatial thing is a good addition. But, what if you have a plane flying over a location and is shot at. It has no relationship with the units below it really. I think what you actually want is a warning per logical group. These are usually in same location, but not always as the plane example showed. Furthermore, there are different priorities. If your commander is under attack that should be #1.

I have improved this logic a bit in the newest xta version: https://code.google.com/p/xta-springrts ... sounds.lua
(there are other sound events also in that widget).

The xta version defines different warning intervals for sound alarm and text alarm, with corresponding spam filters, and different ones also for commanders. It is already quite complex but can of course always be improved.