LUA UI: stupid questions
Moderator: Moderators
LUA UI: stupid questions
Um... I'm not really ready to ask a lot of dumb questions about coding a custom UI for my latest project yet, but I thought I'd at least start looking at some things:
1. I'd like to have different units have different buttons. Like, for example... vehicles might have one style, infantry another. That sort've thing. Possible? Among other things, I'll want to have different variants of "ON" that cover more... creative... uses of Activate()...
2. I've taken a look at the Widgets, but not the code-side yet. Based on what I've seen from it, though, I see very little reason why we couldn't have squads that were automatically created and managed through the UI, without user intervention. Possible? Can I allow users control, but then revert them back to a central movepoint after a time interval or events? I'm not talking huge formational stuff like Warhammer here, just simple "if you build infantry out've this factory, they get automatically grouped into units of 5 guys, who all stay roughly in the same geographical location".
3. I want Side A and Side B to have UIs that look entirely different, to reflect their fluff. Possible?
4. I want to automate certain types of orders. For example, I'd like to be able to give a "lay mines" order to a unit, and have the UI randomly pick some spots on the map within a selection radius/square to lay mines in. Possible?
5. I want to lock out certain Spring UI features, so that players may not use them, because they would screw up gameplay. Possible?
This is all just random musing, of course- I am too ignorant to actually know what technical questions to ask at this point. I'm just trying to get a feel for what's really possible at this point.
1. I'd like to have different units have different buttons. Like, for example... vehicles might have one style, infantry another. That sort've thing. Possible? Among other things, I'll want to have different variants of "ON" that cover more... creative... uses of Activate()...
2. I've taken a look at the Widgets, but not the code-side yet. Based on what I've seen from it, though, I see very little reason why we couldn't have squads that were automatically created and managed through the UI, without user intervention. Possible? Can I allow users control, but then revert them back to a central movepoint after a time interval or events? I'm not talking huge formational stuff like Warhammer here, just simple "if you build infantry out've this factory, they get automatically grouped into units of 5 guys, who all stay roughly in the same geographical location".
3. I want Side A and Side B to have UIs that look entirely different, to reflect their fluff. Possible?
4. I want to automate certain types of orders. For example, I'd like to be able to give a "lay mines" order to a unit, and have the UI randomly pick some spots on the map within a selection radius/square to lay mines in. Possible?
5. I want to lock out certain Spring UI features, so that players may not use them, because they would screw up gameplay. Possible?
This is all just random musing, of course- I am too ignorant to actually know what technical questions to ask at this point. I'm just trying to get a feel for what's really possible at this point.
1. yes
2. possible, but see point 4.
3. yes (the team side information is available)
4. yes (but computationally expensive routines should probably use groupAIs)
5. yes, but no (LuaUI can block most UI features, but it's optional)
The key point to be made is that LuaUI is optional (and there are no plans
to change that). It is not the right layer of code for game rules (it is not sync'ed,
and therefore it's easy to bypass any rules that it may try to enforce).
2. possible, but see point 4.
3. yes (the team side information is available)
4. yes (but computationally expensive routines should probably use groupAIs)
5. yes, but no (LuaUI can block most UI features, but it's optional)
The key point to be made is that LuaUI is optional (and there are no plans
to change that). It is not the right layer of code for game rules (it is not sync'ed,
and therefore it's easy to bypass any rules that it may try to enforce).
Ok, how's about another stupid question:
Can I make much more informative tooltips? I really hate how all I can tell players is limited to the Unit Description, which I cannot format or do other cool things with. It'd be really nice, for example, to have a Widget that was "tooltips ON", and then be able to show a paragraph describing a unit's function, i.e.:
"This is a Roman Legionnaire, heavy infantry armed with two throwing javelins and a stabbing sword. 200HP, 50/75/35 DMG rating, speed 1.0, charge speed 1.5" etc., etc.
It'd be really, really nice, for mods that aren't OTA, to be able to give players a lot more information about their units, and what they're used for, in a format that's pretty and does not require studying a manual.
Can I make much more informative tooltips? I really hate how all I can tell players is limited to the Unit Description, which I cannot format or do other cool things with. It'd be really nice, for example, to have a Widget that was "tooltips ON", and then be able to show a paragraph describing a unit's function, i.e.:
"This is a Roman Legionnaire, heavy infantry armed with two throwing javelins and a stabbing sword. 200HP, 50/75/35 DMG rating, speed 1.0, charge speed 1.5" etc., etc.
It'd be really, really nice, for mods that aren't OTA, to be able to give players a lot more information about their units, and what they're used for, in a format that's pretty and does not require studying a manual.
I have no plans to add TDF parser access to LuaUI. If someone really
feels they need it, they can write a lua TDF parser. I think the better approach
would be to add a LongDescription field to the unit .fbi's, and add an associated
field to the UnitDefs[] tables (if such a feature is desired).
For a more flexible system, you could add a "CustomData" sub-section to
fbi's, and store whatever you want in there as "name=string" pairs. I'd be
willing to shove that into the UnitDefs[] as well.
feels they need it, they can write a lua TDF parser. I think the better approach
would be to add a LongDescription field to the unit .fbi's, and add an associated
field to the UnitDefs[] tables (if such a feature is desired).
For a more flexible system, you could add a "CustomData" sub-section to
fbi's, and store whatever you want in there as "name=string" pairs. I'd be
willing to shove that into the UnitDefs[] as well.
TDF format doesnt support multiline messages,[]// {} or ;.
Thus the ideal solution imo would be to write a class that loads them from a file the modder writes seperatley. This would get around all the issues of the TDF format, allow whatever formatting you chose, and wouldnt require you to wait for spring 0.75 for the new LUA API modifications.
It would also mean that less cluttering of spring is happening, and the problem posed by further requests of "I'd like a full description small description a version with coloured text and formatting and a french version", and so on.
Thus the ideal solution imo would be to write a class that loads them from a file the modder writes seperatley. This would get around all the issues of the TDF format, allow whatever formatting you chose, and wouldnt require you to wait for spring 0.75 for the new LUA API modifications.
It would also mean that less cluttering of spring is happening, and the problem posed by further requests of "I'd like a full description small description a version with coloured text and formatting and a french version", and so on.
I didn't realize TDF format is so limiting (haven't worked with it much).
The lua format might not be a bad choice. Lua was actually designed
with configuration data in mind. It's generally a lot easier to read and
write then XML (imo), and you can use variables and expressions to
manipulate the data.
P.S. The ['more data'] assignment syntax has to be used for table keys
that use non-alphanumeric characters, such as space. It's best to simply
avoid using such key names...
The lua format might not be a bad choice. Lua was actually designed
with configuration data in mind. It's generally a lot easier to read and
write then XML (imo), and you can use variables and expressions to
manipulate the data.
Code: Select all
ScaleFactor = 2.1
ExtraSoundDir = 'Sounds/extra/"
ExtraData = {
armspy = {
longdesc = 'Lua strings support all characters',
extraSound = ExtraSoundDir .. 'armspy.wav',
['more data'] = ScaleFactor * 123.4
},
corcom = {
longdesc = 'You can use referenced data in tables to avoid duplication',
extraSound = ExtraSoundDir .. 'corcom.wav',
['more data'] = ScaleFactor * math.cos(math.pi / 3) * 8
}
}
that use non-alphanumeric characters, such as space. It's best to simply
avoid using such key names...