I don’t think I have ever seen this requested and with BlurPrintRandom’s recent request for a feature I figured I might as well throw one out as well.
I have for a long time thought it was strange that logic bricks like ‘movement’ take floats as parameters but I can’t just type a property name into the field and have it use whatever value is there. So for X, Y, and Z, instead of defining them once and only being able to move by that value they can each get their values from assigned properties which can be changed by the ‘property’ bricks, making the ‘movement’ brick (and others) much more dynamic.
‘Message’ has an option to use a string property as the body, why can’t nearly everything be set to get a value from a property? (Including the message brick’s To field and subject should in my view be able to take the name of an object from a string prop.)
Perhaps it will lead to more ‘spaghetti’ logic by further reducing the need to go to python, but the current design limitations have always felt inconsistent.
The Python controller allows you to control any actuator value with a property if you need to. Though I do agree it might be nice to allow properties be the input providing that the search list only shows properties of compatible types.
[QUOTE=Ace Dragon;2905483]The Python controller allows you to control any actuator value with a property if you need to. Though I do agree it might be nice to allow properties be the input providing that the search list only shows properties of compatible types.[/QUOT
I like to have options and flexibility and it seems like this is an obvious extension to the exisiting functionality of the logic brick system. Is it functionally the equivalent of:
movement = [obj[‘some_x’], obj[‘some_y’], obj[‘some_z’]]
obj.applyMovement(movement, true)
Absolutely it is functionally the same. However by that logic ALL of the actuators, sensors, and controllers are functionally equivalent to some block of python so why have any of them at all? Why not just have a ‘Use python’ setting per object and have it point to a script where you do all your programming and ditch the logic bricks all together? Because not everybody is a great programmer or dreams of becoming one so having flexible and approachable tools is important.
I do see the good in this, but… Some thing just seems incorrect about also… I just can’t put my finger on it though… For those how are not so good at programing I can see the benefit… It might also confuse some one even more with it… Maybe there could be 2 states of the GUI. One of a basic view the other more dynamic… Just food for thought
As soon as you can enter properties the wish will arose to add a value conversion (e.g. property value divided by 2 or negative property value). No big deal, the property should have the correct value beforehand.
Other is, the GUI provides number fields. So it is pretty hard to enter property names with numbers :D. So you could add a switch to toggle between value and property field as quickmind suggests. This might clutter the GUI. If it is worth? - I think it depends on the situation.
Lets think about the motion actuator. It is the one with the most numeric values. If we could switch the field type, we could even get rid of the “0.0 = not set” issue. Just toggle between Not set/Value/Property.
Alternative: mini language -> always use a string.
Empty = not set
Number = constant
String = property (assuming properties start with non-numeric)
I do not know what is a good solution.
How about creating a mock-up image how a GUI could look like?
Been a long weekend at work and I appreciate the comments from everyone.
I may try to spend some time this week making a few mockups illustrating what I see in my head as you suggest Monster. For now, I don’t know that I would expect somebody to want to enter value conversions. What I see would be this somthing like this:
(Picture this in the Logic Editor… I am at work and don’t have time to make a proper mockup…)
KEYBOARD UP – AND – PROPERTY ‘SPEED’ ADD 10.0
KEYBOARD DOWN – AND – PROPERTY ‘SPEED’ ADD -10.0
ALWAYS PULSE MODE TRUE-- AND – MOVEMENT FORCE: X [ SPEED ] Y [0.0] Z[0.0]
The editor does already allow you to enter any characters into the field for numbers. All that is needed is for blender to switch to property mode on that field and show a drop down list of all the properties you have added to that object the moment you start typing a character that is not a number. Alternatively it could as you say take a string with ’ or " and then the property name. No need to really change the UI or add any more buttons with either of these. (though there is so much I wish was changed about the layout to make text labels on settings fully readable, but that is another discussion all together.) If you type a property name that doesn’t exist the field can change color just like it does when you remove/rename a property that is in use.
I just checked and blender does allow you to enter 0.0 as a property name… this seems like a poor thing to allow. At least the admittedly not-so-great programmer part of me kinda recoils at the ability to name what is essentially a variable to 0, 1, or whatever number I want. Anyhow I guess using properties by ‘my property’ in the value field is what I would want. So it becomes:
ALWAYS PULSE MODE TRUE-- AND – MOVEMENT FORCE: X [ ‘SPEED’ ] Y [0.0] Z[0.0]
try using seperate states summoned by properties on a main set state, that way you can toggle what logic to use and it will help clean things up a bit, hope that helps a lil bit, if you have any questions just ask.
I have never found a need for the confusing state system in the logic editor. The fact that it is hidden by default (meaning it goes undiscovered), cannot have different states named (like the default layer management in the viewport), and lack of really descriptive help means I never bothered to try to incorporate it into any of my logic. I also can’t think of an example video or .blend that made use of it without it being the topic of the tutorial that I have watched in the last 4 years, which doesn’t speak much for its usefulness to me. It just isn’t clear to me what the value would be.
Anyhow it doesn’t really achieve what I want which is being able to reduce the number of actuators needed to achieve a goal by being able to adjust what/how much influence they have dynamically rather than choosing between a large number of fixed amounts via an equally complex amount of logic. (This is probably better in another topic but I guess part of this is now asking what are the best practices, if there is such a thing, for the structure of our game logic; logic bricks as much as possible with sparse python, logic bricks and python mixed more or less evenly, or pure python as much as possible? Should we try rely as much a possible on large functionally diverse scripts with a lot of features, lots of logic bricks with sparing use of python scripts, or a mix of both?)