2023-04-01 10:08 CEST
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003406Spring engineGeneralpublic2013-01-19 17:552013-01-21 01:19
ReporterJools 
Assigned TojK 
PrioritynormalSeverityminorReproducibilityalways
StatusresolvedResolutionfixed 
Product Version91.0 
Target VersionFixed in Version 
Summary0003406: User interface not showing correct action
DescriptionUser interface doesn't update correctly. When you order a turret to shoot outside its range, the mouse cursor will show attack available, although that unit can never attack at that point. Furthermore, the attack command will still succeed, although the unit never will be able to actually attack that point. Therefore, it blocks further actions of the unit.

Steps To ReproduceMake a turret, order it to attack outside of its range, watch mouse cursor.
Additional InformationThis should preferably be solved engine-side. If not possible to do that, then add a callin that gives information that attack is not possible, so that mods can add their own cursor according to the behaviour.

Also when a hill blocks the turret, it will not fire. Also in this case, the cursor should change to not available.

Basically, the mouse cursor should be in accordance to the action that actually will take place.
TagsNo tags attached.
Checked infolog.txt for Errors
Attached Files

-Relationships
+Relationships

-Notes

~0009618

Google_Frog (reporter)

2013-01-20 03:36

 I don't like this idea because it is bad when the engine attempts to implement UI features which can be invalidated by gadgets. You say the unit 'can never attack that point' but gadgets can change weapon range, move units around and modify the terrain.

It is a lot harder to re-implement the old behaviour than it is to implement the new behaviour with lua. It is easy to change the cursor if it is an attack command and certain conditions are meant. It is easy for a gadget to prevent an attack command from being placed while quite hard to detect when one should have been placed but was removed by this feature request.

The redeployment time for lua is a lot shorter than engine changes. There is a reasonable chance that the initial engine implementation will break something or there will be unforeseen design problems. There are a lot of things that would need figuring out, for example what if two turrets are selected?

So in short I think this would be a very bad idea to solve engine side. Instead a callin would be preferable:
" a callin that gives information that attack is not possible"
But we already have such behaviour. There is a widget called Attack AoE which uses weapon attributes to draw dots on the terrain for the expected impact spread. This widget already takes terrain blocking and weapon range into account. Lua is already capable of doing what you require.

~0009623

Jools (reporter)

2013-01-20 15:51

 If it is preferable to solve in Lua than in Engine, then sure, but solving it in an gadget requires the appropriate callin to be added.

To solve the issue in a widget is problematic; widgets can be turned off and this is not a extra feature that we ask for, we ask to fix a bug in the user interface. I don't think widgets should be the arena where we fix engine bugs.

Most other games have an UI that doesn't lie to the user.

~0009624

Google_Frog (reporter)

2013-01-20 16:15

 The UI is not lying. The cursor says that if you click there the unit will receive an attack command. The engine can't know if that is a reasonable location for an attack command.

It is trivial to block the sending of an attack command on certain conditions via lua.

Widgets and gadgets are the UI in almost all Spring games at the moment so the most important thing for the engine to do here is to implement simple and consistent behaviour. When the engine tweaks the command interface on the whims of a few games it is much harder for other games to continue to have a functioning UI.

It is entirely possible to make widgets that cannot be disabled. They exist in ZK. Sure you can disable them by disabling luaui but at that point almost all Spring games are unplayable.

I don't see a situation where being able to disable this widget would be a problem.

~0009625

Jools (reporter)

2013-01-20 16:23

 From the point of the user, the interface is lying. It doesn't matter if the fault is widgets, gadgets or the engine, if the action does not correspond to what is suggested by the cursor, then it is a lie to the user.

Maybe best option to make it a gadget still. We don't want to have extra clutter in widget selection list either.

~0009626

Google_Frog (reporter)

2013-01-20 16:25

Last edited: 2013-01-20 16:25

View 2 revisions

 Hide if from your widget selection list if it is a problem.

~0009627

Jools (reporter)

2013-01-20 16:45

Last edited: 2013-01-20 18:41

View 2 revisions

 Well, the engine sets all other cursors, attack, move, guard, load, unload. Why should it not set out of range cursor too?

~0009628

Jools (reporter)

2013-01-20 17:11

 Anyway, the ability to know when a shot is blocked by terrain etc requires a callin from the engine.
+Notes

-Issue History
Date Modified Username Field Change
2013-01-19 17:55 Jools New Issue
2013-01-19 17:55 Jools File Added: screen00147.png
2013-01-20 03:36 Google_Frog Note Added: 0009618
2013-01-20 15:51 Jools Note Added: 0009623
2013-01-20 16:15 Google_Frog Note Added: 0009624
2013-01-20 16:23 Jools Note Added: 0009625
2013-01-20 16:25 Google_Frog Note Added: 0009626
2013-01-20 16:25 Google_Frog Note Edited: 0009626 View Revisions
2013-01-20 16:45 Jools Note Added: 0009627
2013-01-20 17:11 Jools Note Added: 0009628
2013-01-20 18:41 Jools Note Edited: 0009627 View Revisions
2013-01-21 01:19 jK Changeset attached => spring develop 7d8695d3
2013-01-21 01:19 jK Assigned To => jK
2013-01-21 01:19 jK Status new => resolved
2013-01-21 01:19 jK Resolution open => fixed
+Issue History