Mechanic – Proof Of Concept

Ever hear of the term “Nerd Sniping”? I hadn’t until a bit ago, but this totally happened to me. No, it isn’t a bad thing. It refers to a situation where someone says “…that of course, is impossible” (or merely — “how can I do this”) and someone with an engineering/programming mindset thinks, “wait a minute, I could solve that”.

So one day I’m hanging out talking with some fellow modders about this and that, and the topic comes up about a certain game mechanic, (differentiating here between game vs real-life auto mechanics, lol) and how to approach a given problem.

The more we chatted, I realized my brain was already working toward the solution. The code was writing itself in my head. I have a pile of projects that I’m going to get to – and this game mechanic of being a virtual mechanic fixing/repairing things is on that list.

I dove in, thinking it would be super-easy. (Turned out to be a bit more involved, of course.)

Here’s an early alpha where I was figuring out some basics, like highlighting the proper part and deciding how to make it function.

Testing that my raycast registers the proper part and the highlight works for valid parts.

A hundred plus lines of lua later I had the basic idea done for removing a part and “storing” it somewhere. The idea was to have things you’d disassemble or repair, with visual prompts to help the player along.

The “ghost” placeholder was the same vox model, just set to not collide and a bit of glow.

All well and good, but it wasn’t complete. The part in the players hands had to end up where the visual indicator was, just to make it work right. This took a bit more work, where I was storing different states in arrays (though now I think of it, structs would be better — I’ll fix it later) while the player manipulated and placed things.

Its funny, when I work on things sometimes I hit some problem and either a) work around it at the time, or b) get annoyed and drill down to the real reason its behaving that way.

Well, this time it involved coordinate systems. If you recall cartesian coordinates from high school, you have your x and y axis, that can define a point with two coordinates, like (5, 3).

I’m working in three dimensions, so I have X, Y, Z.

In Teardown, the Y axis always points upward. Its just how its built. My problem is when I do the sleight-of-hand needed to ‘snap’ the part into place (I delete the ghost shape and spawn the original part where it should be.) The shape doesn’t end up where it should.

Its CLOSE, but offset enough that it is causing problems.

So I debugged by printing all these variables to the console to see what the hell was going on, but I wasn’t sure exactly what it was yet. I needed the model to spawn at say: -3.4, 0.4, 0.2 (X, Y, Z) and it wasn’t doing that exactly. Its like trying to add 2 + 2 but getting 5.165 instead of 4.

My solution was to construct a careful test so I could drill down on why its doing this. There are some possibilities where errors would creep in — world vs local coordinates, the shapes and bodies encapsulating them.

I had to find the offset that was creeping in somehow and stomp that bug flat.

Well, wouldn’t you know — I found out why. Here’s the final proof-of-concept-demo:

Part can be selected, placed and then reinstalled if need be. Note the extra states in the upper-left.

It was the vox model itself. (I thought it was in the code possibly, which was driving me nuts.)

Each model has what is called a ‘pivot’, which is just a axis that can be adjusted for various reasons. The model I was using came from elsewhere (and critically I didn’t check beforehand, my mistake), and turns out the pivots were slightly off — about 0.5 on every axis. The physical location of the model in world coordinates was a bit offset too.

Bit of a hair-puller, but it taught me a lesson — check your assets! I really should’ve looked at it more closely before working with it, since it was part of a compound model and those offsets were there from that particular type of assembly.

Another lesson was attempting to map states for an object.

Usually you can get away with setting some boolean (true/false) flags and call it a day, but this particular mechanic required no less than NINE different states when I broke it down. No wonder I was having trouble earlier! I can only keep so many things in my head at once, lol.

Diagramming and pseudo-code breakdowns were a big help. Sometimes you get so lost in the weeds of a problem that you need to make a map of the destination to keep you on track.

I’m always learning something — and this dovetails nicely into a future post how I found out a quirk of the engine… but more on that later.

(Cheers to Nathan who inspired me to figure this out – here’s a link to his project site.)