Document reserved EC type IDs

[Stinkfist0]

EC type IDs (and type names) are unique and they cannot be changed after the EC is adopted widely (if wanting to have backwards compatibility). So, it would be nice to have a page that would document all of the used IDs. The page could also be place where different entities/companies could "reserve" ID spaces/ranges for their use.

[peterclemenko]

Should this be a doxygen page or a wiki page?

[Stinkfist0]

I would say wiki, as it's more robust to commits changes (no need for pull requests) and wiki is on-line and accessible virtually always.

[jonnenauha]

I guess the main problem is that realXtend as a project does not have a wiki atm or a place to host the doxygen docs. Put if they are put into doxygen it will be hosted by us at least.

I think there is not a huge margin for real errors. If you pick a taken component ID this https://github.com/realXtend/naali/blob/tundra2/src/Core/TundraCore/Scene/SceneAPI.cpp#L122 will notify you about it when you start the client and load your plugin.

I can say that we at Meshmoon have started our EC ID range from 500 to not conflict with any core EC IDs now or in the future.

[peterclemenko]

A starting point is useful knowledge, but the end point of the allocated range is needed as well. Extra blocks can be allocated as needed, but there needs to be an end point of the allocated block so other people know where a safe start point is.

Jonne Nauha notifications@github.com wrote:

I guess the main problem is that realXtend as a project does not have a wiki atm or a place to host the doxygen docs. Put if they are put into doxygen it will be hosted by us at least.

I think there is not a huge margin for real errors. If you pick a taken component ID this https://github.com/realXtend/naali/blob/tundra2/src/Core/TundraCore/Scene/SceneAPI.cpp#L122 will notify you about it when you start the client and load your plugin.

I can say that we at Meshmoon have started our EC ID range from 500 to not conflict with any core EC IDs now or in the future.

---

Reply to this email directly or view it on GitHub: https://github.com/realXtend/naali/issues/654#issuecomment-17569775

Sent from Kaiten Mail. Please excuse my brevity.

[jonnenauha]

Yeah sure. I'd say the core can say eg. 500 to be a safe starting point. It does not really matter if Meshmoon is using 500 and up and other people wont have our plugins. Then again if you wish your plugins to be a part of Meshmoon we can provide you with another range so nothing will conflict, we are open to these kind of things too if someone makes nice feature plugins/components. As long as we can read the sources and verify the code is good :)

But you are right. Documenting somewhere the safe start ID if you wish to create your own components would be good. And there we could list cores used IDs as well.

[peterclemenko]

Personally I think that the whole EC ID problem is caused by bad design. I think the ID should be based on an entry in an SQlite database server side of all the known components. I really dislike having fixed Ids like this, it reminds me of a problem the ArmA community has because all scripts are in the same namespace.

Jonne Nauha notifications@github.com wrote:

Yeah sure. I'd say the core can say eg. 500 to be a safe starting point. It does not really matter if Meshmoon is using 500 and up and other people wont have our plugins. Then again if you wish your plugins to be a part of Meshmoon we can provide you with another range so nothing will conflict.

But you are right. Documenting somewhere the safe start ID if you wish to create your own components would be good. And there we could list cores used IDs as well.

---

Reply to this email directly or view it on GitHub: https://github.com/realXtend/naali/issues/654#issuecomment-17570316

Sent from Kaiten Mail. Please excuse my brevity.

[jonnenauha]

Heh, I don't see any big design flaw here. No one is having problems with the IDs, this was only a note that we should document them. Any persistent state like a sqlite DB on the disk is what we are trying to avoid in a Tundra server and its one reason why the core design is so great. If you want huge DB on disk of object positions and assets you might want to look at alternatives that provide that eg. OpenSim. The DB approach is very doable Tundra too, you'd just need to write that plugin as for now its not provided by core. A proof of concept sqlite plugin was actually implemented at some point but it was removed as no one really used it and it was not fully finished. But Tundra provides excellent Qt signals to implement this kind of thing easily. Still I guess this would not solve the issue you have with component IDs, but it would make servers persistent without storing/loading .txml:s on startup/shutdown.

I don't see how having the ID:s in a database would solve anything. The client and server would need to do some messaging to check what component is what before any scene sync is done. I mean if your suggestion was that the IDs can vary from server to server. I think that would just complicate the protocol without any benefit. Clients that don't have all the components of the server can still connect correctly and will only miss the functionality provided by those components its missing.

What is the situation in where the ranges being locked down in code would cause problems? I'm sure you can find examples from ArmA etc. but I doubt they will match one to one on what we are talking about here.

[Stinkfist0]

@jonnenauha By wiki I (and probably @th3flyboy) meant this https://github.com/realXtend/naali/wiki

I think the current design is ok, and allows the component type identification very efficiently (transferred over wire as VLE'd uint). Another viable option would be to use hash of the component name as the unique ID (component names must also be unique) like Urho3D does.

[jonnenauha]

Right the github wiki would be great to fill with some generic info but not the amount of data we have in doxygen.

@Stinkfist0 I think he has more issue about the range of free IDs that people can use when they implement ECs without conflicting with core IDs. So we could just document "hey use 500 and up if you create your own components." as a guideline, dunno :)

We are going in around ~50 in core ECs and there are lots of caps in there. 500 would be quite safe for a long long time. But I guess it could be something like 10000 too to be on the safe side :P The IDs are not set in stone afaik as txml do not ref them. You can in fact change the ID later as long as you update your server and clients at the same time. Or clients can join to the server but wont just get the components untill they update.

Only things that will break loading txml:s is changing component name and existing attribute names/id:s. But I dont think there is anything we could do about that even if we wanted.

[peterclemenko]

I think it should be a hash of the author and the EC name. The reason for the database would be to dynamically load the list in to the database and reference it through that as an expandable, dynamic list. The point is not to store the data in the database, only the list of component types.

As for the SQLite plugin, I'm going to have to look for that, as that sounds interesting. Also, the main reason I bring up ArmA, while it doesn't exactly match, is that scripting commands and config names have in the past collided because all scripts were in the same namespace. The point is to make them more unique to reduce the probability of collisions, while allowing for runtime loading of new modules.

[cadaver]

Hashing to eg. 32 bits would increase the network payload. The initial idea to use small integer ID's was exactly to allow efficient VLE encoding over the wire, just like Stinkfist0 said.

[peterclemenko]

I've documented most if not all of the EC IDs here: https://github.com/realXtend/naali/wiki/Reserved-EC-IDs

[Stinkfist0]

Great! I did some mods to the page. When this wiki page is refered from the core developer documentation (Entity-Component Reference page maybe?) I think this issue can be closed.

[jonnenauha]

I added Meshmoon reserved IDs there and made a cleaner looking <table> of it all. If someone has the time could update the other ones to use the <table> too to make it a bit more readable :)

Good job @th3flyboy

[peterclemenko]

I just documented the ChiruAddons repository's entity component IDs and converted the existing data over to tables.