Game Engine Issues

[z3r0_d]

I just read a few posts, but I have a question: Where did the "Actor" option go? Without it, physics are undoable for people without Python experience (and I'm stubborn with that--I'm not going to start using Python until I really need to, i.e. savegames and complex crap), Force & Torque are utterly useless, and you're wasting people's valuable time & computer space (by computer space, I mean for multiple Blenders & the aforementioned Force & Torque).

in 2.33 and 2.34 the actor buttons do not show up until you choose sumo as the physics engine in the world buttons [or you can delete the world, that works too]

[jesterKing]

By the way,

are there more than 2 people working on the game engine part of blender?

Nope. At the moment it's even only Kester working hard on the gameengine, and doing amazing things with it. We've tried to attract more developers, but as of present there have only been few who have expressed interest, and none who actually do something (to my best of knowledge).

/jesterKing

[xhyldazhk]

There is an issue with the edit object actuator in python. An add object actuator cannot change it's add object because [addObjectActuator].setObject needs as parameter an object from a non-active layer, but non-active layer objects are not accesible from the scope of gamePython, so I suggest, by compatibility with [addObjectActuator].getObject, that the parameter passed should be a string (the name of the object in the non-active layer), not an object.

[z3r0_d]

okay, I have a few things perhaps which should make it on this fourm

1: armature deformed meshes can't be replaced with another [armature deformed] mesh at runtime

the replace mesh actuator replaces the mesh, but it doesn't deform

[at least, this is what I hear, I haven't been using blender much to try it]

2: changing the object an add object actuator adds is weird

so, it appears that the new method of getting that object is through GameLogic.getCurrentScene().getObjects() , but the issue is that objects in an invisible layer do not end up there.

also, strings do not always work as expected [as they did in 2.25]. goldenjaii [elysiun and #gameblender] has a file where some objects work in 2.34 [but not others], where all of them work in 2.25.

[xhyldazhk]

That's the code (in source/gameengine/KX_SCA_AddObjectActuator.cpp):

Code: Select all

PyObject* KX_SCA_AddObjectActuator::PySetObject(PyObject* self,
                                                                                                PyObject* args,
                                                                                                PyObject* kwds)
{
        PyObject* gameobj;
        if (PyArg_ParseTuple(args, "O!", &KX_GameObject::Type, &gameobj))
        {
                m_OriginalObject = (CValue*)gameobj;
                Py_Return;
        }
                                                                                                                                               
        char* objectname;
        if (PyArg_ParseTuple(args, "s", &objectname))
        {
                m_OriginalObject= (CValue*)SCA_ILogicBrick::m_sCurrentLogicManager->GetGameObjectByName(STR_String(objectname));;
                                                                                                                                               
                Py_Return;
        }
                                                                                                                                               
        return NULL;
}

that seems to be meant to first check if the argument given is a Ketsji object and then check if it's a string with an object name, but if fails the first check then seems to throw a Python exception and never goes to second test. So I commented out the first test, compiled and now I was able to give object names as arguments, but as in the BlenderObject -> GameObject conversion only objects in active layers are converted, even with this hack I could not access hidden layer objects. I tried to work around that hacking in source/gameengine/Converter/BL_BlenderDataConversion.cpp, specifically in
BL_ConvertBlenderObjects, executing the same code block for objects in active layer that for those in other layers, but it didn't work, still the objects placed on non active layers are not accesible from the Add Object actuator... maybe I need more documentation or diving into the code... any suggestions?

[an-toni]

xhyldazhk,

have you had success with that?

i tried to start porting this old system to 2.34 (it currently only works with versions 2.25-2.33), but encountered similar problems. was looking forward to using the new Scene module/object to access the blender objects that need to deal with, but couldn't get info about the ones on hidden layers.

am demoing the system at the conference next week, so obviously hope that could use the current version of Blender, but that might not happen :/ (am talking about http://studio.kyperjokki.fi/engine/KyperMover ). unless there's a hyperactive coding sprint there or someting

regarding the problems of initializing added objects in 2.34 (that are not there with 2.33), i made a simple test case some time ago -- it includes usage instrucions and some info, http://www.kyperjokki.fi/tools/inittest.blend (dunno if Kester or anyone who knows about the internals has had time to check that out, probably not - i did mention it in a reply to Kester on bf-committers back then)

i think the way is to drop that kind of kludges we needed before had access to Scene, but that still requires more work on accessing the hidden layers etc. (and perhaps other scenes too?), so i hope you have figured out something about that..

~Toni

[theserpentlord]

I see the falling through floors bug constantly - on different machines with different worlds. I have noticed some things:

It is more common when I use dLoc than linV
It happens you walk, land, or spin in place
It also happens in the middle of flat planes

My guess is blender applies an opposing force or velocity when you try to move through a surface. This SHOULD put you above the surface, but once in a while it isn't quite enough. You can sometimes push through walls and corners as well as floors.

This would affect velocity (linV) more than displacement (dLoc and dRot). linV moves ALONG the surface after the first collision, but with dLoc moves INTO the surface, penetrating deeper more often.

Maybe the force of velocity of the floor against your pushing needs to be increased by a very small margin? How could this be debugged or tested? (Some people don't notice it. Maybe different performance, time spent playing or even CPU type affects small margins of math error?)

The best test I have so far for this bug is just moving a cube with keys linked to dLoc actuators around on a big, flat plane. I can upload a .blend file if you need one

where is this bug in the Bug Tracker?

[z3r0_d]

well don't use dloc then

there are other reasons to not use it:
it doesn't change velocity [it just moves the object, right into the wall if you tell it to]
and it isn't framerate independent, at different framerates you go different speeds

[alien-xmp]

An-toni: You are setting (from Python) the add object actuator to copy the last object added to the active layer! This means that gameobject.must_init is already 0 so the sensor never activates and the script doesn't get called.

Also, init.py is called on both edges of the sensor pulse, so "why was init called even though must_init is 0?" gets printed.

xhyldazhk: You're on the right track: if PySetObject is called with a string, it will try to set it as an object and fail, then try to set it as a string and succeed. However, the error is still raised and causes an exception at a later date. The solution is to add a PyErr_Clear() between them. It should be fixed in a testing build.

The logic & physics now happen at a fixed rate (30 & 60 Hz respectively, settable with python) IPO and action actuators still run at framerate, so they are still smooth. The physics will eventually interpolate on framerate to maintain animation speed.

[an-toni]

thanks alien-xmp -- i had the misconception that the init would be called in the beginning even for objects in non-active layers, but that doesn't seem to be so even in earlier versions.

will compile from CVS (to get such a testing build) to see if adding using names works there.

other option would be to be able to get references to the objects-to-be-added in the hidden layer(s), not having to use names anymore at all. might see the source about Scene regarding that.

~Toni

[theserpentlord]

z3ro_d: Yes, dLoc is pretty useless for moving characters

But, I still fall through the floor, and can sometimes push through walls with linV. Walls do stop dLoc - most of the time - just like they stop linV - most of the time.

Even though linV keeps you from falling through the floor AS MUCH as dLoc, the problem is still much too frequent to make a nice game with Blender

[gargola]

Nope. At the moment it's even only Kester working hard on the gameengine, and doing amazing things with it. We've tried to attract more developers, but as of present there have only been few who have expressed interest, and none who actually do something (to my best of knowledge).

/jesterKing

that's sad man! very sad...if i only had the knowledge....

[malCanDo]

> The logic & physics now happen at a fixed rate (30 & 60 Hz respectively, settable with python) IPO and action actuators still run at framerate, so they are still smooth. The physics will eventually interpolate on framerate to maintain animation speed.

Is it possible to have this as an option to set in Blender as well, rather than just in Python? Maybe a slider bar, allowing you to select any number between 1 and 120?

Mal

[gargola]

I'm thinking it might have to do with loading these old blends into the new blender.

i can't even load my old blends on the new blender.an error comes up and won't let me load the old blends.i just deleted them.

[z3r0_d]

I'm thinking it might have to do with loading these old blends into the new blender.

i can't even load my old blends on the new blender.an error comes up and won't let me load the old blends.i just deleted them.

compressed, signed, or locked files will have to be unsigned/compressed/unlocked in 2.25 before they can be opened in any open source release

other than that all blender files should be able to be opened