A new fork of the engine


(wkk.py) #1181

Which is a non-issue, it is caused by people misunderstanding the values returned by the API.

See https://github.com/UPBGE/blender/issues/865#issuecomment-427577311.

Basically, the mouse position is relative to height - 1 and width - 1, because the mouse is mapped to a pixel index (starts at 0, ends at size - 1).

If anything, the doc should be updated.


(Daedalus_MDW) #1182

which is absolutely unacceptable today. ignoring something this basic is just plain lazy.

plus, the logic.mouse.position is normalized, which makes it alot more messy. the fact that its normalized makes the statement that this value is ready to use, and 0.5 is dead center.


(BluePrintRandom) #1183

I just only accept moment greater than 1 pixel /shrug


(wkk.py) #1184

0.5 is dead center

0.5 is dead center. But on an even sized resolution (say 4 pixels wide, big screen), the perfect middle is between 2 pixels. The mouse cannot land between two pixels. So it “drifts” to the nearest pixel, which is not really 0.5 now. The comment I sent has the code to use in order to not experience drifting.

And I think it makes sense that the mouse position is given in pixel index (0 to size - 1), and not 1 to size. It works like any other array/list/tuple, that you parcour from 0 to len(list) - 1.

It is just a matter of documenting that fact.


The issue happens when people do x = 0.5 - mouse.position[0], they expect the mouse to be in 0.5 when in the center, but 0.5 is sometimes inachievable. That is just how it is, because of things previously mentioned.


#1185

As pointed by @WKnight02 we are in the process to include this information in UPBGE docs. We will also supply a little example script to make clear which is the way to get a working mouse look script.


(Daedalus_MDW) #1186

then why not make the mouse.position just use pixels? then its like the sensor and also get fine control over where the mouse is.

are other engines this big of a PITA?


(wkk.py) #1187

mouse.pixelPosition why not.

But this would just do mouse.position[0] * (width - 1).


(Cotaks) #1188

Indeed, works like a charm, i didn’t understand the topic i guess, thought it was for upbge team to implement into code, haha implemented myself in my script, mouse drifting gone, GD works great now.

But still troubles with activeInputs, i will make a new topic for it on the github, because what they say does not work correctly, anyway if i set how it should be nothing works and blender crashes instantly lol.


(duendecat) #1189

There seems to be an issue with using addObject. When comparing versions, in 0.2.3 the code below adds the player to the same location as p (the spawn point empty) and the player falls gradually (approx) one unit to the ground plane below at the rate of gravity, wheres in 0.2.4 the player object’s xyz values are correct on the first frame (as before) but then the position on the z axis immediately begins to rapidly decrease, pushing the player through the ground plane.

def place_player():

	scene = logic.getCurrentScene()
	spawn_points = [ob for ob in scene.objects if "player_spawn" in ob]

	p = self.select_spawn_point_empty(spawn_points)

	spawnObj = scene.objectsInactive["Player"]
	player = scene.addObject(spawnObj, p)

        print(player.worldPosition)

Result of the print in 0.2.4 (ground plane wp is at 0,0,0):

<Vector (0.3561, 4.1373, 0.6576)>
<Vector (0.3561, 4.1373, -18.7040)>
<Vector (0.3561, 4.1373, -57.0336)>
<Vector (0.3561, 4.1373, -101.2110)>
<Vector (0.3561, 4.1373, -145.3884)>
<Vector (0.3561, 4.1373, -189.5658)>
<Vector (0.3561, 4.1373, -190.4825)>
<Vector (0.3561, 4.1373, -191.3991)>
<Vector (0.3561, 4.1373, -192.3158)>
<Vector (0.3561, 4.1373, -193.2325)>
<Vector (0.3561, 4.1373, -194.1492)>

etc

The world position of the spawn point empty (when printed out in-game) is the same in both versions. If I raise its position a few units higher there is no change, the spawned object still shoots downwards through the floor.

If I add player.worldPosition = (0,0,0) to the bottom of the above code then the player is set to the center of the game world (with no initial downward motion other than gravity) and can be controlled as normal. I’ve disabled all other code that would affect the placement of the player, so it looks like this might be an issue with addObject.

All other objects that are libloaded in and then added via addObject (enemies, items) also have the same behavior (i.e. are forced through the floor).

Does anyone else experience this?

Edit: If I adjust the “Fall Speed Max” property to something very low (such as 0.9) then the character floats down to the ground (very) slowly without clipping through the ground, which would suggest that the maximum fall speed is being reached on the first frame.


(BluePrintRandom) #1190

use the X y z and location locs on the actor and turn on physics debug view

also is the actor a character or dynamic or rigid body?


(duendecat) #1191

I’ve turned on the location transform locks (in the object panel), but this hasn’t had any effect. Aren’t these normally used in the editor view?

The physics debug view is already on.

All moving entitles (player, enemy and npc) are character physics type.


(BluePrintRandom) #1192

ok I thought maybe you had a static parented to the actor or something

character physics uses a vector for gravity now,

maybe that is the issue?

(also I typically use a dynamic and ghost mode and use rays for actors physics)

I really don’t like the character wrapper.


(duendecat) #1193

I use a similar set up, however I’ve been using the character physics type + rays instead. I’ve just tried switching everything over to the dynamic type, but no luck.

Is there a way to manually set the current fall speed value in python? This might solve the issue (for me at least) if each entities fall speed is reset on init. Hacky, but that’s sort of where I am right now with this.


(wkk.py) #1194

https://pythonapi.upbge.org/bge.types.KX_GameObject.html#KX_GameObject.setLinearVelocity ?


#1195

@duendecat are you using the build i passed or the last one that posted @tristan73 ?
The one that posted tristan had fixes for character…


(duendecat) #1196

I’m using @tristan73’s build, yes (this one). Checked and double checked. :slight_smile:

Thing’s that I’ve tried in the past couple of days (re: the player object):

  1. Set linear velocity to (0,0,0), at init and also on every frame after the rapid shift downwards / falling begins (no effect).
  2. Set worldPosition to (0,0,0) a few frames after falling begins (this works if there is another object directly underneath, otherwise no effect)
  3. Set worldPosition to equal the spawn point empty position, a few frames after falling begins (no effect, it starts falling rapidly through the floor again)
  4. Changed physics type to dynamic (no effect)
  5. Changed physics type to static / no collision (solves problem, but… no more player physics)
  6. Swapped-out the player object for a cube placeholder with the same settings (no effect)
  7. Searched my code / logic bricks, trying to find anything that could be the cause, disabled anything non-essential or movement-related (no effect)
  8. Set object’s initial “Fall Speed Max” to zero in Blender, then reset it with the Python character wrapper a few frames after init to be 55 (this solves the problem, the player drops down to the ground normally afterwards. There is also no downward movement between init and the reset).

So I’ve managed to temporarily find a way around the problem, but I’m really at a loss to what is causing it in the first place. As I said, it only seems to be doing this in 0.2.4…

Edit: Turning off collision bounds also seems to solve the problem, however this also prevents the character object from falling to the ground normally at the rate of gravity (in this instance, the Fall Speed Max was set back to its original setting).


#1197

Have you test walkDirection? Character works with walkDirection instead of setLinearVelocity. Also using fallSpeed


(duendecat) #1198

walkDirection is displaying (0,0,0) on every frame, so I don’t think it’s related to that.

Setting the fallSpeed to zero (in the physics tab) and then setting to a higher value using the Python character wrapper a few frames after init (in game) does prevent the sharp downwards drop on the z axis from happening, so this hack will work for me for the time being. The drop would normally have occurred within the first few frames.

It looks like there might be another issue with the character physics if it is used with applyMovement, where the player object judders (jumps back repeatedly) if it collides with a static object. In 0.2.3 I adjusted the Collision Bounds Margin to 0.1 which prevented this from happening, but adjusting this value doesn’t seem to make much of a difference in 0.2.4. Example: test.blend (523.4 KB)


#1199

For character physics you have to use walkDirection instead of applyMovement


(wkk.py) #1200

.applyMovement(vector) is equivalent to position += vector, which teleports the object without setting the velocity. Makes you teleport a bit inside the wall, then the physics try to push you out of it.