Difference between revisions of "User talk:Aveneger"

From SCS Modding Wiki
Jump to navigation Jump to search
Line 47: Line 47:
 
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?
 
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.
 
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)
 
--[[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)