Data properties and Valve updates

Discuss API design here.
User avatar
BackRaw
Senior Member
Posts: 537
Joined: Sun Jul 15, 2012 1:46 am
Location: Germany
Contact:

Data properties and Valve updates

Postby BackRaw » Fri Apr 17, 2020 11:15 am

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.
User avatar
L'In20Cible
Project Leader
Posts: 1331
Joined: Sat Jul 14, 2012 9:29 pm
Location: Québec

Re: Data properties and Valve updates

Postby L'In20Cible » Fri Apr 17, 2020 11:25 am

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.
User avatar
BackRaw
Senior Member
Posts: 537
Joined: Sun Jul 15, 2012 1:46 am
Location: Germany
Contact:

Re: Data properties and Valve updates

Postby BackRaw » Sat Apr 18, 2020 1:53 pm

Well, why do we hardcode for example the clip and maxammo values for weapons then?
User avatar
L'In20Cible
Project Leader
Posts: 1331
Joined: Sat Jul 14, 2012 9:29 pm
Location: Québec

Re: Data properties and Valve updates

Postby L'In20Cible » Sat Apr 18, 2020 2:24 pm

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:
User avatar
BackRaw
Senior Member
Posts: 537
Joined: Sun Jul 15, 2012 1:46 am
Location: Germany
Contact:

Re: Data properties and Valve updates

Postby BackRaw » Sun Apr 19, 2020 12:24 am

Thanks for the info!! I'll keep an eye on it!
User avatar
BackRaw
Senior Member
Posts: 537
Joined: Sun Jul 15, 2012 1:46 am
Location: Germany
Contact:

Re: Data properties and Valve updates

Postby BackRaw » Sun Apr 19, 2020 12:36 am

What are the ctx files you mentioned?
User avatar
L'In20Cible
Project Leader
Posts: 1331
Joined: Sat Jul 14, 2012 9:29 pm
Location: Québec

Re: Data properties and Valve updates

Postby L'In20Cible » Sun Apr 19, 2020 3:32 am

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.
User avatar
BackRaw
Senior Member
Posts: 537
Joined: Sun Jul 15, 2012 1:46 am
Location: Germany
Contact:

Re: Data properties and Valve updates

Postby BackRaw » Sun Apr 19, 2020 3:44 pm

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.

Return to “API Design”

Who is online

Users browsing this forum: No registered users and 2 guests