Movement System Explaination (9/???)

Oh, yeah! I condensed my mouse-look script from way back:

from math import pi

from bge import logic, render
from mathutils import Vector

c = logic.getCurrentController()
m = c.sensors['Mouse']

if m.positive:
    w = int(render.getWindowWidth() * .5)
    h = int(render.getWindowHeight() * .5)
    
    x = (w - m.position[0]) * 0.001
    y = (h - m.position[1]) * 0.001
    
    cam = c.owner['pov'].worldOrientation
    spr = c.owner.worldOrientation
    v1 = Vector((cam[0][2], cam[1][2], cam[2][2]))
    v2 = Vector((spr[0][2], spr[1][2], spr[2][2]))
    a = v1.angle(v2)
    if a + y < 0 or a + y > pi: y = 0
    
    hori = c.actuators['hori']
    vert = c.actuators['vert']
    hori.useLocalDRot = False
    vert.useLocalDRot = True
    hori.dRot = [0.0, 0.0, x]
    vert.dRot = [y, 0.0, 0.0]
    
    c.activate(hori)
    c.activate(vert)
    
    render.setMousePosition(w, h)

Movement System Explaination (8/???)

The way I handled adherence to a surface was pretty simple:

  • If the player is moving along a level plane or up a slope, the player simply follows the slope.
  • If the player is moving down a slope, the Z-displacement is replaced with a maximum incline.

There is a flag which determines if the Z-displacement is overwritten: this is to prevent “hopping,” when the slope-sensing ray detects a shallow incline before the player is actually touching it. The flag is unset when going up a slope and when the player is seen to be touching a level slope: the latter case is determined by the angle and distance of the slope-sensing ray. The length of the ray must be half the height of the player object, and the surface must be level.

Running over something like the top of a steep roof isn’t likely to go as expected. Player’s do a small hop, when going uphill to a level or downward slope. Since the system requires physical touching to work, the “ramp”-effect will most likely cause a player to fall alongside a ramp rather than travel down it (at higher speeds, anyway).

By the way, the maximum incline was determined by the following steps:

  1. Make a vector of (1, 0, -1), which is a 45-degree slope.
  2. Normalize it.
  3. Take the Z-value, and multiply it by whatever speed being applied.

Movement System Explaination (3/???)

It should probably be stated that lateral and vertical movement are entirely separate from each other. The most they intersect is when the horizontal displacement is shifted to align with a plain.

Oh! On that note: it’s best to use a capsule instead of a cone because the dull bottom allows a slope to be detected before moving off a precipice. If a cone was used, there’d have to be a safeguard put in place to make sure the player didn’t go flying off the top of hills on account of registering as airborne.

Just thought you ought to know all that.

Movement System Explaination (1/???)

Okay, see this?

image

Don’t lie. I know you do. It’s the player’s primary body, in this game. Take a Capsule metaball, rotate it sideways in Edit Mode, and make it into a mesh. Easy as pie. The body finds what it’s standing on via the Touch sensor, which is actually a terrible idea because it would mean that even touching walls and ceilings would count as grounded: to alleviate this, a capsule is parented to a cylinder set to the Sensor physics-type for double-checking.

image

Isn’t that cute? And it works.

There’s a small script that executes within the capsule that triggers with the cylinder’s own Touch sensor as well as the capsule’s own:

from bge import logic, events
from mathutils import Vector

c = logic.getCurrentController()
o = c.owner

touch = c.sensors['Touch']
slope = c.sensors['Slope']
grounded = touch and slope

if touch.positive:
    o['grounded'] = False
    for obj in slope.hitObjectList:
        if obj in touch.hitObjectList:
            o['grounded'] = True
            break
else:
    o['grounded'] = False

o['touch'] = touch.positive
o['slope'] = slope.positive

Pretty simple, right? If the cylinder and capsule are touching the same object, then the player is standing on something. In theory, this allows for players to potentially jump off of each other in mid-air, but that’s badass so we won’t consider it a bug.

I’ve got work in an hour, so we’ll call it a wrap for now. See ya around…

image

… you sexy fuckers. ♥

BREAK IT DOWN, THAT BLENDER CODE.

I… I didn’t want to test my stupid mod anyway!

I can’t find the reaction-image I want.

Importation

from ast import literal_eval
from bge import logic

We’re not really pulling magic here, so we only need the logic module. We’d import BGE straight up if we were handling events and stuff, but we’re not.

In a bit, I’ll explain literal_eval, which is pretty slick: it’ll let us stuff a lot of data into an INI file.

Basic Setup

c = logic.getCurrentController()
o = c.owner

o['frame'] = o.getActionFrame()

Just the simple stuff we’ll use often, and this is how we get the frame-number without an actuator. Heads up; we’re running a “one animation at a time”-kind of system, so don’t worry about this being wonky at any point with animations on different layers causing problems.

With Every New Frame

if o['frame'] != o['previous frame']:
    anim = o['animation'] + str(o['frame'])
    
    if anim + 'i' in o['anim data']:
        o['input overrides'] = o['anim data'][anim + 'i']

If we didn’t do this check (“we” being you and I, dear reader), we’d end up doing frame checks a whole bunch of times between frames. I averaged five.

That’s bad.

After we’re sure we want to even do anything, we throw together an index-value! “<Animation Name><Frame Number>” is the formula! It’s like how most people’s names on the internet go, so it’s familiar and intuitive!

The input-overrides things is a bit tricky, by design. See, if we only update that dictionary when explicitly told to do so, we don’t have to specify the same set of executable commands every frame: we can put it off to about once per animation; more, if you want to have cancels and whatnot.

Nothing fancy. ;)

Changing Animations

    if anim in o['anim data']:
        anim = o['anim data'][anim]
        
        if 'next' in anim:
            next = literal_eval(anim['next'].strip())
            
            o.playAction(next['name'], next['start'], next['end'])
            o['animation'] = next['name']
            
            feet = next['name'] + '-f'
            if feet in o['anim data']:
                o['feet'] = o['anim data'][feet]
            else:
                o['feet'] = {}

Now we get to another fun trick! Since we’re not relying on Actuators, we have to react to changes in the object’s state ourselves; in this case, falling and landing. This here is the first part of how that’s handled. At the beginning of every animation, this checked for. Unlike the input-thing, we blank this if it’s not specified. I’ll explain how this information is used, later on.

For now, I’ll explain the magic that is literal_eval! The script assumes you wrote out a Python-like dictionary, like so:

[base]
falling: {'name':'Z Spin', 'start':30, 'end':60}
standing: {'name':'X Spin', 'start':30, 'end':60}

In that way, we can store all the meat and potatoes of an animation on one line, in a single entry. We run strip() just to make sure unusual spacing doesn’t cause an error. Nothing is executed, so don’t be afraid of hacks: literal_eval just looks for variables, and nothing more.

For Continuing Animations

        else:
            for prop in anim.keys():
                changes = literal_eval(anim[prop].strip())
                
                if 'child' not in changes: continue
                c = changes['child']
                if c < 0 or c >= len(o.children): continue
                
                c = o.children[c]
                changes.pop('child')
                for k in changes.keys(): c[k] = changes[k]

This triggers if the animation isn’t segueing into another one. I really haven’t tested this as much as I’d like, since I’m still unfamiliar with rigging in Blender. Ignore it.

It runs on a slightly more complex version of the animation-changer, if you’re curious: it demands that the dictionary has a key ‘child’, to look through the object’s list of children.

Progression Logistics

o['previous frame'] = o['frame']

This is how we check to make sure we’re not doing the same action repeatedly within on logical step. In the editor, ‘previous frame’ is set to -1, while ‘frame’ is set to 0.

The Feet Sensor

o['grounded'] = c.sensors['Grounded'].positive

shift = ''
if o['grounded']:
    if 'land' in o['feet']: shift = 'land'
elif 'fall' in o['feet']: shift = 'fall'

if shift:
    anim = literal_eval(o['feet'][shift])
    o.playAction(anim['name'], anim['start'], anim['end'])
    o['animation'] = anim['name']
    
    feet = anim['name'] + '-f'
    if feet in o['anim data']:
        o['feet'] = o['anim data'][feet]
    else:
        o['feet'] = {}

This is the second part of the faux Actuator! Here’s the logic at play:

  • If an animation is supposed to be airborne, it will eventually land.
  • If an animation is supposed to be grounded, it will eventually fall.

With that, we’ll only need one at a time: hence the initial check before use. It should also be apparent why we blank the animation-dictionary, now: without that blanking process, an animation would loop the initial frame of falling/landing if a blank dictionary wasn’t provided; and that’s just an annoying bit of additional work.

The animation-changing process is copied from before, so hey.

In Conclusion

In conclusion, fuck TF2 Lobby.

Read More

Selecting Objects in Blender, from Python

I’ve been working on how to clear a body-origin of its child hitboxes, and encountered a weird error: the clearing-method would remove the hitboxes, but then the destructor wouldn’t delete the origin! What I discovered was that the one hitbox I was making took away the focus from the origin, and I never returned it. Luckily, there’s a boolean property in the body-object, select, that makes such work child’s play.

After some tweaking, here’s what the clearer looks like:

def clear(self):
	for hitbox in self.origin.children:
		hitbox.select = True
	bpy.ops.object.delete(use_global=True)
	bpy.ops.object.select_all(action='DESELECT')

The constructor has a fancy new line, too!

self.origin.select = False

And, lastly, the destructor has a little more bulk:

def __del__(self):
	self.clear()
	self.origin.select = True
	bpy.ops.object.delete(use_global=True)
	self.origin.select = False

The lesson here is to always be mindful of Blender’s selection-mechanic. I personally am going to make sure that every dynamic object I create is deselected from the get-go, and to use bpy.ops.object.select_all(action='DESELECT') to clean up massive operations.

I advise that you do the same.