Docs validator

[Mr-Auto]

list as of right now: 'SpawnInfo', 'set', 'HttpRequest', 'UdpServer', 'customtheme', 'size_t'

• SpawnInfo - no idea, little documentation, no examples
• set - we have maps, sets, vectors, tables, arrays - would be great to decide on like one name, or because of the standard objects come with some extra functions, maybe would be good to not rename them and just write a documentation?
• HttpRequest and UdpServer - no idea
• customtheme - should just ignore? it's in the force_custom_subtheme and force_custom_theme, as they are written in a "non standard" way compared to other stuff
• size_t - if i remember correctly, sol2 doesn't handle unsigned 64bit well, also this is only used for get_address and get_rva which i don't think should be in the API doc, as almost no one except people who work on this project/reverse engineer the game use this

[Dregu]

We can stop renaming the stl containers and link to https://sol2.readthedocs.io/en/latest/containers.html in the first section for reference.

I think the idea of returning the socket types was to transfer ownership or something, but I don't really know how it all works out.

customtheme is not claiming to be a type, just a parameter that can be many different types that are well documented.

Why keep the debug functions a secret though?

[Mr-Auto]

We can stop renaming the stl containers and link to https://sol2.readthedocs.io/en/latest/containers.html in the first section for reference.

Don't think this has any value to someone that just wants to write a mod and have no knowledge about C++, standard library etc.

Why keep the debug functions a secret though?

Hard to keep something secret in open source project 😄 . It's just that normal people don't have use for those. And for example: if i ever needed to get address for pattern, i would never think to look in the API doc for something like this

[Dregu]

Don't think this has any value to someone that just wants to write a mod and have no knowledge about C++, standard library etc.

Just write a doc section about the container types yourself then if you think that's not good enough. It's would probably be enough for most people if we just say that all of these containers can be used like lua tables, but maybe add a matrix of available operators/methods too.

Hard to keep something secret in open source project 😄 . It's just that normal people don't have use for those. And for example: if i ever needed to get address for pattern, i would never think to look in the API doc for something like this

I don't know where else you would look for something like this, but I'd rather remove the deprecated functions before this, and I don't want to do that either. If it's in the api, it should be in the api doc. It's just more confusing if people find these functions and we intentionally left them undocumented.

[estebanfer]

• set - we have maps, sets, vectors, tables, arrays - would be great to decide on like one name, or because of the standard objects come with some extra functions, maybe would be good to not rename them and just write a documentation?

arrays and tables can be different tho, luals has some advanced types related to that https://luals.github.io/wiki/annotations/#documenting-types

[Dregu]

I am using the address functions through string.format("%x") always though, so returning hex strings automatically would just make it easier.

[Mr-Auto]

We can use * in the comments again, instead of this funny snowflake ✱

[Mr-Auto]

['HttpRequest', 'UdpServer'] left

[Mr-Auto]

I think the idea of returning the socket types was to transfer ownership or something, but I don't really know how it all works out.

So should i make them return nil or do actual ownership transfer and ignore the type in the validator?

[Mr-Auto]

right now there is no ownership, so the pointer is just dangling, if i do ownership transfer it will mean that using just udp_listen("url", foo) without saving the return will prompt sol to just delete the object

so it's kind of breaking change, but probably the right solution

[Dregu]

The idea was to transfer the UdpServer to lua so it could have methods like close()... I just didn't add the type cause there were no methods yet and lua usertypes are only required by this validator. You can add an empty type or even implement :close() for it, definitely not return nil.

HttpRequest is a similar story, although it has a pretty short lifespan and doesn't really matter what it returns, as the callback handles success and error. As long as it doesn't turn to garbage before the request even finishes.

[Dregu]

And it's fine if garbage collection closes the udpserver when the lua handle is gone, that's how it's already documented but it just doesn't work like that.