quote:
Now, GBC is technically in a fresh install but is disabled (anyone can use it, they just need to enable it).
Similarly, by default phantoms fire at radar dots, but if you go into unit states you can make it so by default they don't, substantially improving their usefulness (they basically never hit radar dots). (I think     GoogleFrog is the only person I've seen who places this sort of thing in a different category to GBC) |
dyth68 I wasn't aware that you still don't see the differences. Here are how I see the levels of customisation.
Level 0
Everything you can do without exploring the UI that much or reading any tooltips. This excludes everything found at the top left of the screen, most commands that cannot be issued with a right click, and state toggles. The game should be fun, playable and look bug-free at this level. Phantoms fire at radar dots by default because having a unit fail to fire, even if explicitly told to, looks like a bug at Level 0.
Level 1
Everything you can do with a basic unmodified UI. This excludes everything in the Settings or Hotkeys Menu (F10), the widget list (Alft+F11) and tweak mode (Ctrl+F11). At this level you can change states such as a Phantom's Fire At Radar state. You can also place retreat zones and set retreat levels. Various tooltips may be read to learn about the game, such as the tooltips for terraform placement
Level 2
Everything you can do with Simple Settings ticked in the Menu. This includes toggling particularly common or useful options such as camera scroll speeds, the size and left/right position of the minimap, unit outlines and whether the cursor is locked to the window.
A lot of configuration is available at this level because the entirety of the Hotkeys and Settings/Unit Behaviour menus are available. Players can modify just about any hotkey here and set units to default any behaviour that can be set via state toggles. I expect most people to play Zero-K somewhere between Levels 1 and 2.
Level 3
Everything available when Simple Settings is unticked. This is the first level at which a player might void their warranty, but the options here should be designed to make that difficult. Tweak mode exists at this level, allowing players to reposition the UI panels. Many overlays, such as healthbars and command visibility, are able to be toggled and adjusted. The advanced graphics options are here, with the simple ones being in the non-game menu.
Level 4
Everything available when Show Advanced Settings is toggled in Settings/Misc. There are very few advanced settings, and most are debug options, so the big change at this level is access to the widget list. At this point the player has definitely void their warranty as the widget list offers many ways to break your game.
Widgets can be moved between Levels 3 and 4 with the addition or removal of a settings menu button that toggles the widget. Some widgets, such as GBC, were relegated from Level 3 to Level 4 for being too buggy or failing to teach the user how to use them to such an extent that they look buggy. Many could probably be moved to Level 3 if anyone wants to put the work in. A few of the widgets here are holdovers that have not yet revealed themselves to be too broken to exist.
Level 5
You are at customisation Level 5 if you know how to find and install publicly available widgets. There is no central widget repository so it is hard to know what is at this level, and "publicly available" exists on a wide spectrum. Popular or useful Level 5 widgets can be included and moved anywhere from Level 0 to Level 4.
Particularly useful widgets that languish at Level 5 tend to do so due to bugs, idiosyncrasies or jank. If someone writes a widget for themselves then it is not necessarily going to be usable by others. In recent times this tends to be because targeting widgets include a level of jank (force-overriding unit states and player orders) that the creator knows about and is happy to work around during play, but which would look buggy and frustrating to most others. They also have troubling performance implications that are unsolvable without starting over and implementing the same behaviour with different tools.
Other widgets languish at Level 5 simply because they would make the game worse. The LLT Disco widget would be terrible if widely used, and not just for the performance implications. No good solution has been devised. I don't want to start making 'arbitrary' rules about what can and cannot force fire at the ground, but I will if action is required and no better solution is found.
Level 6
At Level 6 you are writing and tweaking your own widgets. Keeping useful widgets to yourself is frowned upon.
Level 7
At Level 7 you are hacking around restrictions placed on widgets or compiling your own version of the Spring engine for some benefit. This level is not allowed.
quote:
Do you get my confusion about what you mean by "mod"? Could you elaborate on where the boundary lies? |
The boundary is at Level 5. Anything below Level 5 is not a mod.
To answer the question. Don't Fire at Radar is discoverable at Level 1 and can be permanently configured at Level 2. GBC is Level 4. Artemis overkill AI is Level 5. I have not seen the Artemis AI widget but, judging from the other targeting AI widgets I have seen, my guess is that it works as follows:
-
Sets Artemis to Hold Fire, essentially overriding that state for the end user without explaining how it works.
-
Either periodically asks Spring to get all enemy units in a cylinder around the Artemis (a very slow operation) and check their unitDefID against a target filter, or keep track of every enemy unit that has entered radar or LOS and periodically filter them based on unitDefID and whether they are in range (a relatively slow operation).
-
Issues Attack commands, potentially overriding attack commands given by the user.
It could be written to not override attack commands and to require the user to set it to hold fire in order to function. This would still be bad default UI as the firestate would have hidden meaning, invisible to the user, and the whole behaviour would be undiscoverable. Furthermore the effectiveness of the widget would depend on latency.
"Just make and advertise a public widget repository" is not a solution!
