If new logic blocks were to be developed, what would you like to see in there?
For example, think of a common task that you’ve had to hack around ( or use Python to enable ) that could possibly be implemented as a visual logic block. Remember that they need to be generic enough to be re-used in multiple situations.
NEW:
Copy transform from other object ( with optional additional position and rotation offset, and option to ignore object rotation ). This could be used to emulate Vertex Parenting, eg for a camera setup.
Physics related
Set mass
Add to / Remove from collision detection
MODIFIED:
Camera
add a value to control the time taken to tween between min/max distances
add an option to ignore the rotation of the parent
A follow path actuator where the object will move on a path represented by a spline with vertex number order used as guide or something like that and have the option XYZ to be able to set up the pointing(rotation) of the object independently.
Depending on what type of interpolation the vertex path has the object will move acordingly.
This actuator will have a startpath and an endpath something that will tell the object what to do when starts going on the path and what to do after the path has been completed.
NEW ONE :eek:
I really need a “limit objects maximum velocity” brick…
thats one i could in practically EVERY game i can think of…:spin:
Also i would like the rigid bodie joints to be implemented as a logic brock, not a constraint.
I’d like to see a LOD logic brick with the following features
a) user can set switch in and switch out details for each LOD
b) option of fade LOD when switching
c) option of force LOD when frame rate drops too low
Oh and LOD 0 is the highest level of detail
People are always moaning about the slow framerate in Blender and this should help speed things up.
Follow path would be something that would be a little more flexible then an IPO, here’s my ideas.
-Add to the follow path actuator, make an option to make the path relative to the object position, not absolute
IPO
-An object to make the IPO positions relative to the object position, not absolute
EDIT OBJECT (ADD OBJECT)
-X,Y,Z controls where the object will be placed, it may be absolute or it may be relative to the object
NEW ACTUATORS
-Save/load
-Destroy constraint (have an option for destroying it under a specified amount of force)
I cant remember who, but some one suggested, a while back, modifying the joystick actuator to mimic analog behavior, rather than having to set several actuators at increasing sensitivities.
yeah a path follow actuator would be excellent!! oh and a LOD logic brick!!
and most importantly a dynamic parenting logic brick or some other means of changing the parenting from one object to another… this is a another thread that is a really good idea!
A Parenting actuator would be handy, with setParent: and clearParent options.
An actuator that can affect a hit object’s properties in someway might be helpful:
Collision Prop:enemy------>AND----->HitObject: Prop:HP Add -10
Add a Nearest option to the trackTo actuator, that lets you track to the nearest object with a particular property.
Some General Game Engine wishes…
As long as we’re making wishes, there’s a function called endSelf() in the PyDocs. It says it ends the current object, but doesn’t actually do anything. It would be great to not have to have endObject actuators on everything, and just be able to get rid of them with python.
I vote for save/load…this is more-so for the newbs out there than it is for me. I would probably use python regardless, but im sure non-python users would find this very useful.
Maybe global (gamelogic.property) properties could somehow be integrated for the non-python users as well? Maybe just have a little tab when you add a property to an object(local, global) and allow the property sensor/actuator to always function on global properties.
I’d like to see a LOD logic brick with the following features
a) user can set switch in and switch out details for each LOD
b) option of fade LOD when switching
c) option of force LOD when frame rate drops too low
I think that would be better suited as an option under the object panal or something like that. Though, an internal LOD system would be extremely cool.
An actuator that can affect a hit object’s properties in someway might be helpful:
Collision Prop:enemy------>AND----->HitObject: Prop:HP Add -10
Couldnt you just use Collision(property:enemy) –> AND –> Property(property:HP Add-10)?
A Parenting actuator would be handy, with setParent: and clearParent options.
Add a Nearest option to the trackTo actuator, that lets you track to the nearest object with a particular property.
Perhaps this can be done with constraints, which I havent studied at all. But it would be nice to have a 3D area constraint an object can travel through/on.
However, I dont know how it would be implemented, other than using an expandable matrix for the coordinates.
So instead of setting up invisibles to stop the objects travel you have an area of possible travel.
Load/save would be nice, however I think it should also involve a simple start/end menu too. And include slots, or just free naming for the load/save functions and usuable from any time in the play.
Couldnt you just use Collision(property:enemy) –> AND –> Property(property:HP Add-10)?
For my example, I meant for it to be logic bricks on a projectile object. When the bullet hits an object with prop:Enemy, it would check for prop:HP on the enemy, and then add/subtract whatever amount.
Also, add an option to affect only the other object on a ray or collision sensor with logic bricks.
Like
-Object A shoots a ray and it hits object B
-Objects, C, D, and E have the same properties as B
-Set an option called other in the ray so every brick connected to that only affects object B
I think just a save/load actuator would be more then enough. How can you otherwise make an unique menu?
And for the name of the saved stat, the actuator could just take a string property for that…
And a “parent to” actuator would be indeed very useful.
A “grip/attach” actuator!
One of the basic ( and oldest) properties of video games, so, everyone wants to emulate this.
Something like Collision -> AND -> Grip ( anchor - parent - whatever) or Near - Expression - property:true -> grip
Modify the Ray sensor so it can pass through objects it’s not looking for. The # of objects to pass through without giving up could be set (1 would be stop at first face seen, 0 would be pass through all).
Add a Ghost actuator: object only registers collisions with objects that have the specified property. Useful for walking through walls without falling through the floor.
Oh yeah, and fix all the bugs! You can’t make a proper game with bugs in the system.
A simple menu: Load, Save, Start, Exit and of course, Esc to the menu.
I am busy with other things, and dont have time to think on this and explain more options regarding its use. But I wanted to add it in anyway. Smile.
Hes, asking, Im wishing.
The sensor could be setup with the esc button, then the actuator could initiate the menu system, allowing variables for use and hooks for python scripting for coders to elaborate if they so choose.
At some time later, more items could be added to the actuator, ie: display options/user preference, easy, hard, normal, (would load a different scene series?), Inventory Control (with its own variables and hooks) perhaps that would be on a separate sensor?.
Anyway, it could lead the way for a more advanced UI and help with the repetitive coding of some tasks.
