Difference between revisions of "User talk:Aveneger"
(Created page with "Hi Avenger, this page will be dedicated as communication channel for you about your contributions.") |
|||
Line 2: | Line 2: | ||
this page will be dedicated as communication channel for you about your contributions. | 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 <code>traffic_spawn_condition</code> type (shall I call it a "type"?) can take <code>type</code> as an <code>enum</code> and <code>num_param[]</code> as an <code>integer</code> and <code>str_param[]</code> as <code>string</code>. | ||
+ | |||
+ | Then by parsing all files, the script should be able to see other uses, like <code>type: area</code> and <code>type: weather</code> and "fill in" the enum for that case. It could also tell that <code>type</code> is mandatory and the <code>*_param</code> 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 <code>details</code> and <code>summary</code> HTML, [https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details The Details disclosure element - MDN docs] to have all searchable in a single page, and not (initially) an endless scroll (hopefully). | ||
+ | |||
+ | <details> | ||
+ | <summary><code>traffic_spawn_condition</code></summary> | ||
+ | <code>'''type''' => enum ('''area''', '''city'''', '''time''', '''weather''')</code> | ||
+ | </details> | ||
+ | |||
+ | Well, that may be a little big one, but that'd be something I like doing! |
Revision as of 22:06, 16 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!