GraphNode vs Entity - ESM migration issue

Good afternoon,

We’ve been working on migrating a large project to the new ESM scripting format, but we are coming across some issues with the conversion.

A lot of our legacy code used Entity.findByName to access specific object scripts throughout the project. However, every findByName reference in the converted .mjs files now seems to return a GraphNode, which does not allow script access.

I have been going through the docs for a couple of days now trying to find an alternative, but so far, there seems to be no simple way to get around this. Any recommendations?

image

the Entity extends the GraphNode, so you can test if your returned GraphNode is entity, and if it is, use it as an Entity.

Majority of GraphNodes you get will be Entities.

Could you please give me an example of how that should be done? It doesn’t seem like I can get the returned GraphNode to work as an Entity.

Well the code should work as you have it.
the only problem is that you get the type warning. But that should not change the functionality. Is your script functioning correctly, and you’re worried about this warning in the Eitor?

If so, try something like this

/** @type {Entity} */
const gameHUDObj = ... (your current code)

Not right now. My team tried to do a mass migration and there is a lot broken at the moment. I was assigned with fixing all the errors.

This is what happens when I do what you said:

I will continue working on the clean up and will let you know if things work out.

You could also try

if (gameHUDObj  instanceof Entity) {
... you code using it as entity
}

That isn’t working either unfortunately. It is almost like it returns a graphNode by default and converts it to Entity, because the script property doesn’t get properly recognized. Before the ESM conversion those lines worked automatically.
image
image

image

I am wading through a lot of other conversion errors right now though, so I will let you know if this gets fixes once I clean most of them up. Thanks for the suggestions.

These are not errors that will stop the code from running … only the type errors. The reason is that the new scripts do a lot better type checking than old, and these things get surfaces, where before they would not.

2 Likes