The current way of setting the data properties manually as INI files is generally fine. However, they are prone to errors when it comes to Valve updating the properties themselves. Can't we read the properties internally on the C++ side and translate them to the Python layer automatically, updating the INI files as well when needed (for scripter reference)? The properties have to be in the code somewhere, so it's definitely possible. This would remove the need for keeping track of the properties for all games and updating the INI files manually.
Since Valve still updates CS:GO, for example, for the competetive side of things as the game is still relevant in that regard despite being about 7 and a half years old, we can almost guarantee Valve will continue to tweak the properties and may as well continue to do that with other Source (2) games. That also guarantees our data/ directory to be out of sync with the game at any given Source (2) game update, at least in my eyes.
Please list the problems we might encounter with the automatic approach, so we can discuss this further.
Data properties and Valve updates
- L'In20Cible
- Project Leader
- Posts: 1533
- Joined: Sat Jul 14, 2012 9:29 pm
- Location: Québec
Re: Data properties and Valve updates
The properties themselves are retrieved dynamically through the server classes/datamaps. What is declared into the INI files are aliases that are dynamically bound to the Entity class and dynamically resolved to the property they are pointing to.
That system is not only to provide unification so that aliases such as Entity.view_offset properly resolves to localdata.m_vecViewOffset[0] on some games, and m_vecViewOffset[0] on others, etc. but also to make it easy to update in the scenario you mentioned where they change anything into a game.
Take for example how EventScripts, or even SourceMod were/are working; for the most past, every scripts/plugins were/is responsible to retrieve the properties themselves which not only pollute the plugins with ton of redundant if/else for every games/engines but also means each individual plugin will have to be updated in the eventuality a property changes.
With the system in place for Source.Python, if any property that was aliased change, it only requires a simple update to a single INI file and just like that every plugins are updated.
That system is not only to provide unification so that aliases such as Entity.view_offset properly resolves to localdata.m_vecViewOffset[0] on some games, and m_vecViewOffset[0] on others, etc. but also to make it easy to update in the scenario you mentioned where they change anything into a game.
Take for example how EventScripts, or even SourceMod were/are working; for the most past, every scripts/plugins were/is responsible to retrieve the properties themselves which not only pollute the plugins with ton of redundant if/else for every games/engines but also means each individual plugin will have to be updated in the eventuality a property changes.
With the system in place for Source.Python, if any property that was aliased change, it only requires a simple update to a single INI file and just like that every plugins are updated.
Re: Data properties and Valve updates
Well, why do we hardcode for example the clip and maxammo values for weapons then?
- L'In20Cible
- Project Leader
- Posts: 1533
- Joined: Sat Jul 14, 2012 9:29 pm
- Location: Québec
Re: Data properties and Valve updates
BackRaw wrote:Well, why do we hardcode for example the clip and maxammo values for weapons then?
At some point the idea was to use the weapons.scripts module to get dynamic access to such data, for example the result of sp dump weapon_scripts weapon_scripts on CS:S:
But on CS:GO, the signatures to access the weapon database change all the time and if it doesn't, they change the structure of the CCSWeaponInfo it contains which still requires an offsets update to accurately read the data. The data provided in the weapon manager files barely change in comparison.
Perhaps parsing the ctx files ourselves could be an idea, but I'm fairly sure I compared the results at some points and they were doing a lot of stuff at run-time to translate the raw data they contains. Another idea I had at some point was to hook the KeyValues accessors method and compare the structure to dynamically restructure the CCSWeaponInfo but turned out to be more work than it was worth imo. If you want to explore something and find a reliable and maintainable solution feel free to make a PR.
![Smile :smile:](./images/smilies/smile.png)
Re: Data properties and Valve updates
Thanks for the info!! I'll keep an eye on it!
Re: Data properties and Valve updates
What are the ctx files you mentioned?
- L'In20Cible
- Project Leader
- Posts: 1533
- Joined: Sat Jul 14, 2012 9:29 pm
- Location: Québec
Re: Data properties and Valve updates
BackRaw wrote:What are the ctx files you mentioned?
They are the scripts for the weapons that are listed into the weapon_manifest.txt and stored into the ..scripts/* directory (usually packed in the pak files). Those files are parsed by weapon_parse.cpp which build the weapon info and store them in the weapon database.
Re: Data properties and Valve updates
L'In20Cible wrote:BackRaw wrote:What are the ctx files you mentioned?
They are the scripts for the weapons that are listed into the weapon_manifest.txt and stored into the ..scripts/* directory (usually packed in the pak files). Those files are parsed by weapon_parse.cpp which build the weapon info and store them in the weapon database.
Ahhh, now I get it. Thanks.
Who is online
Users browsing this forum: No registered users and 92 guests