5
edits
Changes
Jump to navigation
Jump to search
no edit summary
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!
---
'' > Hmm, how would this work when any unit gets an update/delete?''
'''A: A full rerun, indeed, to regenerate the full "mega page". And, I suppose wiki would just be able to tell what exactly changed in a nice diff as much as any CVS probably does.'''
'' > Who would be maintaining the database of the units?''
'''A: A volunteer, I'm afraid. Me at first.'''
'' > You would regenerate all the used units for each update and upload it?''
'''A: That's one point I raised. It would be much easier if the page was a single one, right? Then topics "contracted" via a <code><details></code> HTML entity of sorts, something to enable units to be collapsed and expanded. At least for the first iterations of the doc. If it works well, then some kind of automation could be made to send to individual pages, not sure how much the wiki is "automatable", but form submission, etc. I think it's pretty possible, just not really viable for the first iterations of the generator.'''
'' > 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.''
'''A: Agreed with the whole point. But what I have access to is the data; and better something close and concise than nothing, I thought when coming up with this idea. The right thing to do would be , yes, to extract from sources. But I don't think anyone in SCS has had the opportunity to work on something like that so far, right?'''
So, the proposal really is full of caveats, there will be lots of assumptions and guesses, like the accepted input (float/int/str), acceptable ranges, mostly would come from "educated guesses" over values used throughout the data, or manual documentation input (descriptions, as the community finds out what does what). So, a <code>spawn_ratio</code> could report as accepted values an interval from 0.0 up to 1.0 while seems they could go at least as high as 6.0 with some meaning in the game.
It would at least be a central reference for the game for modders and maybe even for the developer team, and could also be used to find mistakes in the data (single use popping up, range exceedingly high, unexpected change from previous version, etc).
(excuse my lack of experience to use this talk channel :})
--[[User:50keda|50keda]] ([[User talk:50keda|talk]]) 16:24, 19 April 2024 (UTC)
