Difference between revisions of "User talk:Aveneger"

From SCS Modding Wiki
Jump to navigation Jump to search
(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!