Difference between revisions of "User talk:Aveneger"
Line 42: | Line 42: | ||
Well, that may be a little big one, but that'd be something I like doing! | Well, that may be a little big one, but that'd be something I like doing! | ||
+ | |||
+ | --- | ||
+ | |||
+ | Hmm, how would this work when any unit gets an update/delete? Who would be maintaining the database of the units? You would regenerate all the used units for each update and upload it? | ||
+ | The point is not everything that is used in our data might still be valid, some attributes might be obsolete or just there and never even loaded by the game. Simply said, if sth like this should be present on official modding wiki, it should be created from the code itself, where units are declared as only code knows what is valid and what shall be there. | ||
+ | --[[User:50keda|50keda]] ([[User talk:50keda|talk]]) 16:24, 19 April 2024 (UTC) |
Revision as of 16:24, 19 April 2024
Hi Avenger,
this page will be dedicated as communication channel for you about your contributions.
2024-04-16 - suggestion/idea: I was thinking about writing a script to generate kind of an "API Reference", as complete as both games combined (ATS/ETS2) uses in their def.scs files. That means, say:
def/vehicle/ai/bus_opalin.sii traffic_spawn_condition: .traffic.bus_s.condition.time { # spawn only in following game time intervals type: time # 06:00 - 9:00 num_param[]: 360 num_param[]: 540 # 16:00 - 18:00 num_param[]: 960 num_param[]: 1080 } traffic_spawn_condition: .traffic.bus_s.condition.city { # spawn only inside cities type: city str_param[]: "?*" }
Given the use above, I can infer that the traffic_spawn_condition
type (shall I call it a "type"?) can take type
as an enum
and num_param[]
as an integer
and str_param[]
as string
.
Then by parsing all files, the script should be able to see other uses, like type: area
and type: weather
and "fill in" the enum for that case. It could also tell that type
is mandatory and the *_param
optional.
Then descriptions would be another problem. Either sync descriptions with the script to re-generate API Reference every release. It'd also be possible to get added/updated descriptions straight from the wiki and feed the script too.
And then for ease of maintenability, we could post it all in a single page and enable, for instance, expandable sections with the details
and summary
HTML, The Details disclosure element - MDN docs to have all searchable in a single page, and not (initially) an endless scroll (hopefully).
<details> <summary>traffic_spawn_condition
</summary>type => enum (area, city', time, weather)
</details>
Well, that may be a little big one, but that'd be something I like doing!
---
Hmm, how would this work when any unit gets an update/delete? Who would be maintaining the database of the units? You would regenerate all the used units for each update and upload it? The point is not everything that is used in our data might still be valid, some attributes might be obsolete or just there and never even loaded by the game. Simply said, if sth like this should be present on official modding wiki, it should be created from the code itself, where units are declared as only code knows what is valid and what shall be there. --50keda (talk) 16:24, 19 April 2024 (UTC)