keyvalue / property improvement

[D3CEPTION]

ive looked into sp recently and both keyvalues and properties have struggle properly interpreting data for the enduser, like scripters.

in kevalues there are two problems atm : some datamaps are wrong, byte to string fails or even unsupported datatypes, so that some values cant even be accessed.

in properties, on the other hand, everything can be accessed, but some properties that are better described by strings or objects, appear as int objects etc. in fact a lot of properties are displayed as ints, that in nature are / or for efficiency could be, of a different datatype.

my question first of all is, why is it still not that easy to get this all under a clear structure. ( for devs its okay, but what about starters, like i am still? )

i think it wouldnt be hard/inefficient to create member access for all objects with custom api by source python.

like entity.x = var/object


sp creates a list api with all the "x", and scripters can try to access them, if the entries dont exist / arent possible, sp does standard error handling/fixing..
just an idea, as i struggled setting some stuff along my way today..

[satoon101]

Could you give specific examples for what you are talking about? And, as far as the entity.x part, we have that capability for items we have stored in our data. If there is something specific you would like us to add to our data, either ask or post a pull request.

viewtopic.php?f=8&t=972


*Edit: also, as far as the properties being the wrong type, we fixed that earlier this week:

https://github.com/Source-Python-Dev-Te ... 76809c5f81

https://github.com/Source-Python-Dev-Te ... f6346d9868

[D3CEPTION]

i havent saved my results, but some keyvalues have entries, that are neither of the get_key_value_x type i think. also "angles" is represented as "angle" in datamap and all the "datamap.x" values dont have stringsplit checks/ dont work at all, i think? cant remember in detail, i just couldnt get access to keyvalues easily and since properties was working on everyhting it didnt matter. on properties though there are also inhandles, pointers etc where i wondered if it was usefull to let users try input anything (sometimes things can be routed across) , and sp interpretes if the object is valid for the entry. sometimes a True is on propertylevel a 1, but gets revoked. if sp would add ent.isMoving as item member, sp could interprete ent.isMoving = True to ent.set_property_int(1) with the right handling etc... right now i only have small scale use and ideas for these,for now i just wanted to share my point as i came across this. i might even lack some general info about sp's past and progress, but that will evolve i guess

[satoon101]

i havent saved my results, but some keyvalues have entries, that are neither of the get_key_value_x type i think.

A quick test of of all the currently supported servers shows that TIME and POSITION_VECTOR are the only types we don't support currently for keyvalues we can add as attributes. That's easy enough to add in, though. And, if you want to retrieve/set values that are TIME or POSITION_VECTOR keyvalues without them being attributes of the Entity object, you can use float and vector respectively.

also "angles" is represented as "angle" in datamap

No, angles is the correct keyvalue. Through testing this today, I found out that "angle" is not a valid keyvalue for any entity, so I will remove it from the entity data. We also already have a "rotation" property that uses m_angRotation.

and all the "datamap.x" values dont have stringsplit checks/ dont work at all, i think?

I'm not sure what you mean here, could you explain? And again, a real example instead of a theoretical one would help out tremendously.

on properties though there are also inhandles, pointers etc where i wondered if it was usefull to let users try input anything (sometimes things can be routed across) , and sp interpretes if the object is valid for the entry.

There are plans to possibly interpret inthandles as indexes, but we haven't gotten around to that, yet. And, when we do, it will require an index to set as it will return an index. We absolutely do not want to always return an index but then allow either an index or an inthandle to be used to set the value. Also, this will only likely work with Entity attributes, not with get/set_property_<type>, as using the get/set_property_<type> should always get/set the property using its native type.

sometimes a True is on propertylevel a 1, but gets revoked. if sp would add ent.isMoving as item member, sp could interprete ent.isMoving = True to ent.set_property_int(1) with the right handling etc...

The changes I linked to above already handle True/False values properly, just like in this example:
viewtopic.php?p=7603#p7603