Wtf happened with subclasses?

In your subclass it doesn't show that you are exporting the class.

You need to export the class and

runtime.objects.plr.setInstanceClass(plr.plr);

You need to export the class and

> runtime.objects.plr.setInstanceClass(plr.plr);

the first plr is the module, the second plr is the class.

Hello, ok thank you.

So basically, i noticed why it was working for me before.

If i set instance class of a instance in main, you both are right i have to export the subclass and then use plr.plr

However, i noticed, if i add the runOnStartUp in my subclass file, i dont have to export the class at all, and it works aswell.

Look at the Player class here:

class PlayerInstance extends globalThis.InstanceType.Player
{

constructor()
{
super();
console.log("Created!");
}

}

runOnStartup(async runtime =>
{
	// Code to run on the loading screen.
	// Note layouts, objects etc. are not yet available.
	
	runtime.objects.Player.setInstanceClass(PlayerInstance);
	runtime.addEventListener("beforeprojectstart", () => OnBeforeProjectStart(runtime));
});

async function OnBeforeProjectStart(runtime)
{
	// Code to run just before 'On start of layout' on
	// the first layout. Loading has finished and initial
	// instances are created and available to use here.
	
	runtime.addEventListener("tick", () => Tick(runtime));
}

function Tick(runtime)
{
	// Code to run every tick
}

Well yeah, like that you have direct access to the class without having to import, but I'd say it's kind of dirty to program it like that hehe. At least to me it makes sense to have it organized that way. Just as an example:

> import * as Player from "./player.js";

Now I have the Player Module, which can include more than just the player itself. It could also contain, say, the camera and the player weapon, which kind of make sense to be part of the player Module. Like so:

> runtime.objects.player.setInstanceClass(Player.Player);
runtime.objects.camera.setInstanceClass(Player.Camera);
runtime.objects.sword.setInstanceClass(Player.Sword);

So everything regarding the player will be inside one separate file. And the setInstanceClass can happen only in one file in one place. So if something goes wrong or I have to add another instance class, I know exactly where to look.

I write plenty of dirty code btw. but I still try to keep it minimal and do regular cleanups. There's nothing wrong with dirty code to a degree. Be more like Balatro-dev and less like Yandere-dev. Both have "dirty" code but Balatro is printing infinite money and yandere simulator still isn't finished (it's been 11 years)

Yeah now that you said it, i feel like your approach is better in the long run for sure. I to like organized code :p im just unfamiliar with how JS organized code looks like, since i am coming from c# and backends like php where i am used to strict types and not loose types like in js.

Thanks !

i am coming from c# and backends like php where i am used to strict types and not loose types like in js.

You might like to try using TypeScript which gives you strict type checking.