Wrectified Reboot - Alpha Systems


Here is the game is it currently is,
~ = pick up weapon
CTRL = mouse mode 2
Tab = first person
shift = run
1 = drop weapon or component
Ctrl -> aim at items with property “Control” = “order” part where to go
Mouse wheel up/down = Move z depth plane in and out
2 = grab component
[ and ] = switch actor
e = grab ladder / release ladder
space = jump

Left click while holding weapon = fire
~ while holding weapon = reload
Left click while holding a component = attempt assembly

This is Pre - Pre alpha - Just systems tests at the moment,
Let me know what you think.

Why are you starting over?

The actors action rig was terrible,
The actions themselves were not well made,

The assembly system was overeally complicated,

I tried getting it perfected, but it still occasionally would fall right through things…

Compound physics appears just slightly too buggy to,go forward with my previous attempt.
I plan on doing the same things, but more limited.

You will be able to build robots, trade arms, remove then etc,
But this will be done with replace mesh, and sometimes even swapping whole models.

The minecraft esc assembly I had planned works, but if things randomly pop through a wall it’s not good.

I am prepared to make a kick ass game anyway, with vehicles, combat, assembly, and destruction… Just not as much construction :slight_smile:

The game will still be following the same direction, Everything was coded crappily before.
Logic spaghetti and poorly written code…

If I write it from scratch I can probably get it going in about a week.

Good luck!!

Thanks! I have almost all the functionality I learned to make with the old rig, added jump tonight,

need to get the weapon systems back into the new blend, and a elevators etc,

Assembly is the only one I kinda want to start over from scratch, but I am hesitant, as the old one is “this close” to working…

And please let me know what you think about the new systems,

I reckon you should blend your character animations a bit more, as it makes him seem a little rigid. Also with the ladder, you want to make ladders, doors and any other hard to trigger events, as easy to trigger as possible. The battlefield series does this by snapping the player to the ladder if they are facing the right side.
Looking good so far.

Actually it’s changing animations on a single actuator,
It blends into idle, however not switching actions,

I think I am going to fix it via a actuator sensor, and use that to prevent changing the animation or direction of forces until the end of that walk cycle, (20 frames max)

Have not tried my hand at python for actions rather than a actuator.

The code I use is there to check out,


Python actions actually work pretty well. I used them for the BGMC and the result was more than satisfactory. There’s a special trick for blending layered actions (if you want a different action for the arms and legs for example) but there are examples of that around if you need it.

I think it’s a good idea to reboot your progress. After a long time on one project it’s easy to lose enthusiasm and to get bogged down in fixing details. It’s better to rewrite code though rather than reuse it. You’ll find some problems fix themselves the second time round.

Current Logic and python setup


new file

added sprint, jump up, jump forward, and sprint jump.

and mountains again (factory reset my comp)

Mit 3.0 cc - name project Wrectified in credits. except other intellectual property, where specified.

it is good good luck i like it


BUMP - Added new file, controls and video

Hi,i had some trouble with 2.69 with the camera (i guess is something with mouselook, in 2.69 not exist yet)
movement work well , but i not understand how make to grab something
the spaghetti bricks do all more hard.(is necessary?)
why the box controller is so simple , while the other objects so intricated?
why -X for forward movement rather than standard +Y ?
if not there are not good reason better follow the standard (also, in case of stuff more complex with rotation/rays/etc help a lot have some reference )

there clearly some mistakes in the logic of armature (idle + ilde ? :D)(and also seem the “source of spaghetti”):
double names , double actuators, double action, double layer , double code ,
this is ever a bad thing (unless the game is completely ended and it work as should)
a simplest solution for this is use a function that read the actuator , but use playAction to play it:
block the old action is implicit as you play a new action on the same layer , not conflict, not double stuff.

imagine, rather than this:

something like this:

in my opinion is necessary otherwise become ever more complex

I use only two actuators to play all animations
the two sets of actuators, is for a seperate ik armsture for the right arm,
so there is no dependancy cycle, and you can aim, and animate with 1 ik target.

the ik target parents to the arm action ik armature, and when you aim, it unparents and is moved to aim target, or mouse cursor.

each unit can be calibrated to do whatever,
that is why the player faces X-

You can setup a unit using logic, or python or both, with the controller brodcasting to the unit.

its not included but the system will soon look for a property , Vehicle if its in the host body, it will move the previous actor, ane parent him to the vehicle, ghost.

I use two animation actutors, so I can blend to idle.

dont like the way the actor is rigged? its a open project, redo it the way you like, if it is more simple or works better I will use it. ( try and make it easy for newbs)

I used logic spagetti because I had multiple systems to mix, and wanted the scripts seperated so I can replace 1,

2 key = pick up component

left mouse = attempt assembly

I will post the most recent file tonight.

Check the resource thread master control mouse, its the core of the system.

nice work man, looks to be an interesting game in the works…

I will update this with the current file tonight,

the new actor uses action armatures, because python based action blending did not seem to work the way I was doing it,

works and is fast now,

vehicles are go, they use a empty for the seat and others for the exits

a ray check is performed to exit,

the new actor on layer 2 uses only controlls piped through the controller,
using 2 lists, move and act, and 2 properties, x and y(mouse)



feel free to Ask any questions

Actor on Layers 2/3 = current actor

All should in theory work for both actors, but have not added/ tried swap yet in new actor ,

when I do it will be in the ActFilter.

Actor on layer 1 has more complete movement filter then Actor on Layer 2,

WASD -move
Shift - Run on actor 1
Tab - FPS mode on Actor 1

` - pick up weapon
1 - drop weapon or part
2 - pick up part

R = swap actors / exit vehicle in Actor 1

Left click = Fire gun or attempt assembly of part

Right click = switch between Aiming and animating right arm

CTRL = in actor 1 = mouse aim v2 “Mouse over aim”

ctrl+E = activate PIES = if in object = Physical interactive Environment System

Be aware 2.73a still does not fix broken rigid body joints code as far as I know.

so shooting once (deleting any item from the scene) removes all rigid body joints.

“Car” on track on layer 1 is a prototype for vehicle system, all controls are routed through controller as well.

Actor 1 is Gen 2

Actor 2/3 is Gen3 and so is car.

any critisim or questions or ?