ok the UpDown function only works properly when its connected to the camera actuator if i try to put the UpDown actuator to the empty the mouselook simply screws up and get messy,i want the cap stuff work for the empty s orientation ,know wat i mean ?
Kinda, but why use an empty at all? why not just cap the camera
Ill vote when the option ‘all of the above’ is added. 
All of those areas need some work, a few more than others.
WOW how could i miss that,i completely lost that part tho and yes it is my fault,the mouselook fits perfectly for what im looking for,thx a lot HG1 and sorry for missing that 
Agoose thx for ur assistance too but i think my problem is already solver thx
Romy
I hope the formats BGE imports is increased too- FBX import would be great (and 3DS max scene files too- in my dreams!)
Well I think a node based visual scripting would be really good because right now… logic bricks…
Hopefully with the Blender summer code this will be something possible soon.
As for me, this is my wish list:
-
Better physics handling: The objects can be scaled down and up and can be placed at very large distances. However, when used at such extremes, the object’s positions is not correctly calculated, resulting in it shaking like a lee! I know there’s a limit for the 32bit float calculation, but what puzzles me, is that if I print the object’s position, I get a more that 8 digits after the comma… but the object object is at 1 million units away from the center.
If the limit is 1 million or 10 million, let it be like in 2.49, where you can’t place your object or scale it beyond the stable limit. Well, this is also up to the designer… So is there a way to go beyound the 32bit float calculus? -
A mouse movement sensor with X, Y and sensitivity. That will allow a logic bricks only mouse look and other things related to mouse.
3. A faster scenegraph allowing more objects into a scene.
Thank you for your attention!
in my opinion the blender game engine’s node logic is a great advantage it has compared to many other game engines, so i think they should be upgraded with new functions.
they should be freely movable like the compositing nodes, copyable and the controllers should be able to be on more than one state.
also realtime text objects would be nice, because having to use bitmap-texture fonts is really not the state of the art! this realtime text should be changeable with logic bricks, both with an actuator and with a property, which should not have to be named ‘Text’.
furthermore, the game engine should just be overhauled in performance and speed along with rendering quality and features.
and not to forget anti-aliasing!
i fully agree, but what do you mean with the mouse Z-axis?^^ don’t you think X and Y would be enough?
talking about axes: a joystick sensor recognizing a gamepads z-axis (the triggers of the xbox360 controller are countet as an axis, not as buttons) is missing. as far as i know, the game engine does’nt recognize the gamepad-triggers yet.
I love the logic bricks. After some time, when the logic got bigger, with the current style, it will get messy… and my only wish right now that the logic bricks looks like nodes.
@fr3sh - Wow, you’re right, the Joystick sensor only has support for two axes. That should be very simple to fix - we should both message Kupoman about fixing that, since I believe it’s a single value to change (from a maximum of 2 to 4 for axes).
Ok, i got a reply from Ton, essentially saying that the issues are still under discussion, and that he wouldn’t support an indivudial develoment fund.
@SolarLune - I do not think it is so easy, because the added axis would have to be implemented to interpret the signal the joystick/gamepad sends. otherwise how should be detemined whether the 2 axes that are already there represent the gamepad’s sticks or the triggers?
Keep the comments up!
This is not an issue, as in Kupoman’s ‘What Would You Like to See Fixed’ thread, I posted a question about this and got an answer of how to do it, though I don’t recall the solution right now.
If one were to try to fix and implement this in Blender’s source code, I believe that it would be easy as the triggers register as other joypad axes, right? So, axes 0 and 1 = left analog stick, 2 and 3 = right analog stick, 4 = left trigger, and 5 = right trigger. However, I don’t own a PC XBOX 360 pad, so I can’t test this or know exactly how it works.
mhh … this seems like a good idea:yes:, so probably will not be taken into account!
better to add a brick multilaser, brick multicolor, brick vibrator brick Jungle ecc:(
what also is missing, in my opinion, is an integrated navigation mesh system, with basic pathfinding functions like goTo, follow, flee/shun and similar things.
@fr3sh - That is present in the Recast and Detour system, which has already been made and finished, if I recall. It will most likely be added after the 2.6 feature freeze.
Reading the commit logs, I thought I read that Moguri already fixed this issue and that the maximum axis limit for joysticks has been restored to what it was in 2.49.
I think that has a lot of things to improve in BGE. Sun shadows is very important, but point light’s shadows is not so important. Point light’s shadows is important, but there other things more important than this. A faster rasterizer is really the most important thing of the whole BGE. People say that OpenGL version doesn’t matters, but it do. With OpenGL 4 we could have tesselation at the gpu’s tesselation unit, and that could help to have some “Lod” fast and more precise. But a faster rasterizer is still the most important. Other important thing is Anti-Aliasing control inside Blender, without having to go to blenderplayer and put “-m” there. That patch was a great improvement, but it can improve still more. After the faster rasterizer, we should have multi-threading OF COURSE and a better Scenegraph. After all this super-important things we should care with other functions like shadows, anti-aliasing, tesselation and filters. And about these filters, they’re deprecated. Our HDR is bad and slow but bloom, DOF and SSAO is good for now (thx martinsh and other glsl artists). But there some other things like object motion blur, that is not a 2DFilter, and we need them. Other VERY important thing that I forgot to say is about the modifiers that don’t work in real time in BGE. So, faster rasterizer, scenegraph and phyton handling with multi-threading should be priority. After this should come real-time modifiers, sun and point shadows, node system, and all this that you talked about.