MTM2.com

Was working in a track the other day and I had an idea. Any of us who have done tracks before know about the frustration of placing hit boxes on objects. I was wondering if it would be possible to rework the code to allow objects to react like normal ground, instead of spawning an invisible box around the object by default. I have a feeling this would require tampering with the engine itself but I thought I'd ask.

I doubt it. Not any time soon. The square "hitbox" is simply the way games work (or used to work until recent game engines). I know Unreal 4 has a system in place to fix this but they spent a whole segment of coding on this feature alone. Whenever you import objects in their editor the hitbox will be square as well and you need to specifically set the engine to do some calculations to fix this.

Per-polygonal collision examples do exist, however it would be pretty hard to adapt the existing engine to use them (full disclosure: I haven't seen the source, but I do program). This is made harder by the fact that in addition to creating and storing collision data, all other collision systems in the game (e.g. bounding boxes, tires, scrape-point-based truck bodies, and even other complex meshes) would have to be modified to be able to interact properly with a mesh-based collision hull. This actually requires some pretty advanced knowledge of physics-based mathematics to figure out.

Now, that being said. There are two things that may in fact be worth looking into, although don't quote me on this as I cannot speak for O Great Leader Fila. The .sit files contain what appears to be unfinished support for cylindrical collision primitives, which are at least not boxes or wedges ("ramps"). The other thing: Has anybody ever played with the "Collide (Facing)" object type before? It's really weird. Maybe I'm mistaken, but it almost feels like its collision boundary is either cylindrical or some kind of concave hull. I never tried using it for trees (one set of polys for the leaves and one set for the trunk, I assume, is what it would take) but it might be interesting to look at the code for that.

I have started taking a very extensive C++ course that also dabbles a lot with UE4 (it's basically a mix of UE4 and C++). I am hoping to use this to extend my knowledge of programming because let's face it, when I started doing this I had no idea what I was doing. So it's going to take a while but hopefully soon I'll be able to progress the game even more (and add requested features and more importantly port it to Dx9/OpenGL. (and preferably do away with the bitmap menus and have an in-game 3D menu instead).