Hi.
I tried to compile this project:
https://github.com/armory3d/armory_templates/tree/master/vehicle
and got these errors:
I also used VehicleBody trait in a new simple "car project" and got the same error.
Here is the export settings:
System
Blender: 2.82
Armory: 2020.6
OS: Windows 10
Graphics card: 1070ti
edit: simple car project files:
SimpleCar.zip
Hi @nicoosokhan, can you try to export the vehicle example from Armory examples? If the export works probably you do something wrong with the trait.
Edit: Just to make sure, did you enabled rigid body for the vehicle object?
What happens if you build to the Krom target? There are some problems related to Bullet in C, it might be one of them: https://github.com/armory3d/armory/issues?q=is%3Aissue+is%3Aopen+physics+C
@MoritzBrueckner Krom export works successfully.
Should I look for an equivalent code that is supported by bullet API in C?
I have also uploaded "simple car project" files.
@knowledgenude
No, I didn't enable/apply RigidBody manually.
I thought it is handled by the VehicleBody (bundled) automatically (createRigidBody method in trait script).
@MoritzBrueckner Krom export works successfully.
Should I look for an equivalent code that is supported by bullet API in C?I have also uploaded "simple car project" files.
It looks like a bug, maybe it is just Haxebullet that needs to be updated. Unfortunately my knowledge in that area is very limited, so I can't really help here, sorry
@Sanva @luboslenco. Your merged code solved all errors above.
but this one still exists:
C:\Users\nicoo\Desktop\ArmorySDKarmory\Sources/armory/trait/VehicleBody.hx:82: characters 59-79 : bullet.CollisionObject has no field DISABLE_DEACTIVATION
How can I help this one to be solved?
For Krom/js it's defined here:
https://github.com/armory3d/haxebullet/blob/master/Sources/bullet/Bt.hx#L105
For HL it needs to be added into bullet.idl:
https://github.com/armory3d/haxebullet/blob/master/Sources/bullet/bullet.idl
@luboslenco the problem is, how to add that? It looks like static vars are not supported in Hashlink WebIDL — and, for worst, that aren't really class constants in Bullet, just defines → https://pybullet.org/Bullet/BulletFull/btCollisionObject_8h_source.html (l. 22~26).
In Krom/js, with Ammo, they work because Haxe itself allows to define static inline vars in extern classes that will the replaced at compile time.
But I don't know how to do the same with the Hashlink version.
One possible solution would be to create a CollisionObjectActivationState enum with the right values, for example — that would work across all possible targets, it's just an int. What do you think? We could even keep the Ammo static vars for backwards compatibility without conflicts.
With the last compilation error solved, this now fails at runtime with
Starting KoreHL
Uniform shirr not found.
Uncaught exception: armory.trait.SimpleRotateObject does not have field speed(Float)
Process returned 0 (0x0) execution time : 0.206 s
Press ENTER to continue.
exporting for Linux (C).
@luboslenco do you know how could I enable Hashlink stack traces?
@Sanva The runtime error does not happen on windows C target when using a simple vehicle test scene. Not the example /template file. I think it is not a Bullet related issue.
@QuantumCoderQC but, in any case, if I try to do something not trivial with Armory or Kha, I'll definitely need a way to turn on Hashlink stack traces... any idea where to look for?
@Sanva No. I don't known how unfortunately.
No. I don't known how unfortunately.
It looks like it isn't even possible...
The runtime error does not happen on windows C target when using a simple vehicle test scene. Not the example /template file. I think it is not a Bullet related issue.
The problem seems to be with this specific Blender file, for some reason, maybe related to #1805.
The message armory.trait.SimpleRotateObject does not have field speed(Float) is indeed telling that armory.trait.SimpleRotateObject has no property named speed(Float), literally — I was interpreting it as has no property named speed of type Float... So, the problem refers to this:

With #1805 fixed, just pressing the refresh button fixed this problem, also showing the right UI:

With this and the fix about bullet.Bt.CollisionObjectActivationState, the vehicle example template now works in Linux and Android, although with a bunch of differences.
The message _armory.trait.SimpleRotateObject does not have field speed(Float)_ is indeed telling that
armory.trait.SimpleRotateObjecthas no property namedspeed(Float), literally — I was interpreting it as _has no property named speed of type Float_... So, the problem refers to this
This sounds like the file is older than the feature that supports different property data types in the UI,. Before that. all properties were set as a string and had their type in the name. Is this file the vehicle example file linked above? If yes, we should update it (or should we automatically refresh all properties after loading a file? This might destroy some values that do not longer exist so it's probably a bad idea)
@MoritzBrueckner I've added a pull request updating that file → https://github.com/armory3d/armory_templates/pull/7
By the way, in this specific case the property value was lost, I didn't have a chance to see it — but I updated it anyway since it's only the speed value to manually rotate the Sun light, so I suppose in this specific case it is not important.
Most helpful comment
@luboslenco the problem is, how to add that? It looks like static vars are not supported in Hashlink WebIDL — and, for worst, that aren't really class constants in Bullet, just defines → https://pybullet.org/Bullet/BulletFull/btCollisionObject_8h_source.html (l. 22~26).
In Krom/js, with Ammo, they work because Haxe itself allows to define static inline vars in extern classes that will the replaced at compile time.
But I don't know how to do the same with the Hashlink version.
One possible solution would be to create a
CollisionObjectActivationStateenum with the right values, for example — that would work across all possible targets, it's just anint. What do you think? We could even keep the Ammo static vars for backwards compatibility without conflicts.