Topic: Lua, immovable attributes

I am trying to add the internal names of immovables to the editor help. I ran into difficulties for the trees: In the editor there is the old tree of each type shown. If i want to show the internal names of all related trees from sapling to mature i need to add some other functionality to the script. I have a working solution, but it makes heavy use of string manipulation (splitting, joining). That is split e.g. aspen_summer_old to aspen_summer and find all immovable which starts with this string. I think make use of attributes makes this a lot easier: If i add the attribute aspen_summer to all register.lua files of this tree, i can just use immovable:has_attribute("aspen_summer") to get all trees of this specific type (without doing heavy string things).

Now i want to add this information (internal names) to the rocks. Because rocks are all over the same (except the images) the idea is to have only 6 rocks, sorted by size, on the left side of editor help and put other information to the right side. If i add the attribute "help_rocks" to the register.lua files of rocks/blackland/[1to6]/register.lua i can just use immovable:has_attribute("help_rocks") to get only those rocks for the left side of the editor help. Then i can add additional attributes help_rocks[1-6] to some of the other rocks to get the entries for the right side of the editor help.

Is this a way to go, or are the attributes reserved for other things? I fear using those attributes for all kind of stuff may makes using them errorprone.

---

Attachment: image/jpeg

Top

Quote

Feels like those internal names are somewhat a secret which must be hidden to the user I think it's tedious to always use a file explorer and go through all folders (if one knows where they are) and then open an init.lua in an editor to the find the internal names.

I would insert the internal names just below all other information.

---

Attachment: image/jpeg

Top

Quote

Here is someone looking for a tool to add/change fish resources. And here a tool for exchange one terrain with another is asked for.

All in all it does not harm to have the internal names in the editor help. And i don't think it will bother a map editor. Moreover having those internal names in the editor help can awake interest to try out lua scripting. Maybe renaming "Internal names" to "Names used in lua scripting". So if one wan't's to try out lua scripting we should provide the needed information. Think e.g. on the scenario "Trident of fire" which exchanges terrains. Together with a possibility to add windows there can be editor addons with additional editor tools.

We have those internal names also in our encyclopedia and i never heard that this information is useless or bothering. On the contrary i think they are important for scenario authors.

Personally i have my own editor_functions.lua which grows in time, containing functions that i find useful, e.g. change_terrain() or set_fish(). Without knowing the internal names they are useless.

Did you noticed that in my pictures there are 2 new tabs in the editor help (immovables and rocks)? Despite the question of adding internal names, the immovables should be part of the help because some can be removed during game play, and others not. This is an importand information for a maps author, imho. Same for the rocks: "How many stones/granite can be mined from rocks4?".

Regarding the attributes in the register.lua's:
There should be a clear definition for what purpose they are for, imho.

Top

Quote

hessenfarmer wrote:

kaputtnik wrote:

We have those internal names also in our encyclopedia and i never heard that this information is useless or bothering. On the contrary i think they are important for scenario authors.

I agree, that the names of buildings are importnat for sceanrio authors, Therefore it is good to have them in our homepage Encyclopedia. However I think we should limit the in game help to information needed for gameplay and map making. Or formulated the other way round we should only provide help information that can be used inside the game / editor.

I am only talking about the editor, not a game.

Did you noticed that in my pictures there are 2 new tabs in the editor help (immovables and rocks)? Despite the question of adding internal names, the immovables should be part of the help because some can be removed during game play, and others not. This is an importand information for a maps author, imho. Same for the rocks: "How many stones/granite can be mined from rocks4?".

fully agreed, would love to see a PR that.

Such information can be better shown as a tooltip for an immovable inside the editors place immovable tool, imho, just like the tooltips for trees. Having an extra tab just to show "Size is big" or "Quarrying turns this into rocks3" is a bit overkill. See also: https://github.com/widelands/widelands/issues/2099

Ok then, my approach was anyway a dirty hack. But at least i have learned some things.

What about having the internal names inside the Info-tool window?

Top

Quote

hessenfarmer wrote:

kaputtnik wrote:

What about having the internal names inside the Info-tool window?

Nice try ;-). Honestly I think this does not change any of my arguments.

Sorry, but your argument's aren't very strong in my opinion. The example of the scenario trident of fire was only one. Imagine one want's to script a rock which never shrinks, or a tree which renews itself after some seconds after felling, or whatever. Or if one wants to use the function modify_unit. Another example: in my scenario (really don' know if i can complete it sometime ) there is a person who is able to pray for land if he will be provided with donkeys to keep his magic. A scenario can be much more than placing buildings, forbid buildings, checking if a user has reached a field of a map, or set workers and so on. There can be much more scripted. If we want to get some new developers, also a new scenario authors, we should provide the relevant information somewhere.

But i admit that it is currently only me who wants the internal names somewhere shown, because for me it's tedious to always walk through the folder structure of the data directory with a texteditor or file manager. For beginners it is even harder to find the correct file and additional the learning curve for lua scripting with the widelands lua api is steep. If we can make it a little bit easier we should do that. Moreover i think on the long run we should move the information of internal names of buildings, wares and workers from the websites encyclopedia into the editor. So they are available where they are needed. And this could also be a step forward to a scenario editor inside the map editor.

Top

Quote