Havok: `enum`'s not exposed in `HavokPhysicsWithBindings`

[regna]

For example, when trying to set the Motion Type of a Havok Body, we need to pass the MotionType:

HP_Body_SetMotionType(bodyId : HP_BodyId, motionType : MotionType)

According to Havok’s .d.ts types, MotionType is an enum, however, HP_Body_SetMotionType() actually requires an object of form { value: number } for MotionType. It’s a bit challenging to use Havok functions like these with strict Typescript typing.

I found this smart workaround by Namide that works for me. He intersected the enum’s with HavokPhysicsWithBindings:

let havok: HavokPhysicsWithBindings & {
	...

	MotionType: {
		STATIC: MotionType.STATIC;
		DYNAMIC: MotionType.DYNAMIC;
		KINEMATIC: MotionType.KINEMATIC;
	};

	...
}

With this workaround, we can now simply write:

HP_Body_SetMotionType(bodyId, havok.MotionType.DYNAMIC);

where havok is of the intersection type above.

Is there a change on Babylon’s side we could make to make Havok more convenient to use out of the box when using strict TypeScript, i.e. not having to write and maintain this large intersection object ourselves?

Thank you all for your help

[Deltakosh]

cc @Cedric

[Cedric]

I’m not a TS expert. I would refer to @RaananW for this kind of question

[RaananW]

Would you be able to reproduce ths issue in a simple typescript project? I am trying to udnerstand the actual problem here. i.e. - is it a types issue, or a js issue? The function can expect something, which is fine, but if the types are aligned, it shouldn’t fail on typescript.
A reproduction would be great, to allow me to check what can be done. We will be happy to fix it on our side.

[regna]

Thank you, all! Let me create a simple repro of this

[regna]

My mistake, all. I was using an older version of @babylonjs/havok. Since version 1.3.4, these enum’s were added to HavokPhysicsWithBindings, so I believe this is resolved

See Line 212 of HavokPhysics.d.ts in 1.3.4 Code viewer

[regna]

I created a Simple Havok TypeScript script to test the newest @babylonjs/havok@1.3.5 types:

GitHub Source

The enum issue seems resolved!

Though, I have one tiny complaint with the new types

1.3.3: export enum Result { ... }

1.3.4: declare enum Result { ... }

Because Result is no longer exported since 1.3.4, I had to do a workaround in my script linked above:

// Is there a better way to get the `Result` type?
type Result = ReturnType<typeof HK.HP_GetStatistics>[0];

@RaananW, would you have a suggestion here? Thank you!

[RaananW]

well, we can always add anything that is missing! This is why I asked for reproduction, because I thought the issue was already resolved

Do I understand correctly you want to make sure the declared enums are also exported so you can use them?

[regna]

Yes, please Is it okay to export the declared enums?

[RaananW]

to be honest, I don’t see why not

I’ll make the change later

[RaananW]

@babylonjs/havok 1.3.6 now exports the types so you don’t have to use ReturnType

[regna]

Thank you so much, @RaananW

[regna]

@RaananW , after upgrading to 1.3.6, I’m seeing more errors in my script that I’m not sure how to resolve

Script: havok-ts-vite/src/index.ts at main · regnaio/havok-ts-vite · GitHub

This comparison appears to be unintentional because the types 'typeof ResultEnum' and 'ResultEnum' have no overlap.ts(2367)

Type 'MaterialCombineEnum' is not assignable to type 'typeof MaterialCombineEnum'.ts(2322)

[RaananW]

let me check

[RaananW]

oh, i know what happened. fixing

[regna]

I’m excited Thank you!

[RaananW]

Could you try the new version? tested locally.

[regna]

Works great now!

It’s really interesting how you used:

type ResultType = Result;
export { ResultType as Result };

and

export interface HavokPhysicsWithBindings extends EmscriptenModule {
    Result: typeof Result;
    // ...
}

I have to learn this more advanced TypeScript