Since CScriptBuilder maps metadata from TypeId to Metadata, I figured I could just store the metadata next to the compiled bytecode and use it when loading. But I ran into an issue—TypeId isn’t stored with the bytecode and is always generated dynamically. Even with a simple script that has two classes and a function, the TypeId ends up slightly different when loading from a script file versus loading the compiled bytecode. That makes it impossible to map entities to their metadata properly. I'm wondering what potential solutions could address this issue.

Don't use the type id, use the name of the type together with namespace.

As you already identified, the typeid is not static and will depend on the order things are compiled/loaded.

If you compile the same script in two different modules, the same class will have two different type ids (except if it is declared as shared).

Hmm, I've been planning to do similar thing that OP described - as I'll want to have meta data stored after compilation with the bytecode. But I've also been using typeId for network replication between client and server - does this mean I was just lucky that the ids matched?

Doing something like this right now before serializing given type and sending it to client:

  auto transformTypeInfo = engine_->GetTypeInfoByDecl("Transform@");
  if (transformTypeInfo)
  {
     ScriptTypes::asTYPEID_TRANSFORM = transformTypeInfo->GetTypeId();
  }

And then using asTYPEID_TRANSFORM to serialize/deserialize from network message. Does it mean I should not trust the typeId being uniquely created for specific typename and I should either use strings (not too great for networking) or map them to some unique hashes that are shared between client and server? All of those are of course defined as shared btw.

I guess I will have to rethink my approach, somehow it worked so far but that may be because I'm registering them in the same way between client and server (and btw, Transform is C++ side registered type).

The typeId is basically a sequential number, if the types you use are guaranteed to be defined in the same order on both server and client then it should work.

For registered types this is even more likely to be true since you usually configure the engine once and it doesn't change. However the day you decide to add a type that should exist only on the server or the client and register this before the Transform type your code will break.

You can easily test this. Just register a dummy type as the first thing on the server engine, and you'll see that the type id for the Transform type on the server will no longer be the same.