I’m trying to do something insanely simple but am suffering the BGE Newbie Blues.
The screenshot below shows a logic brick setup that I’m having trouble with. Basically, the cube has two properties: Value and MaxValue. The first time the keyUp is pressed, the cube plays it’s little movement IPO and the Value property is incremented by one. The second time the keyUp is pressed, the Property sensor should evaluate as False, thus preventing the IPO from playing, since it shouldn’t make it past the AND controller. I’m confounded why I can keep hitting keyUp any number of times and the IPO plays every time and the Value property is incremented each time.
Playing the game I have the two properties shown on the screen. Value increments every time the keyUp is pressed, ad infinitum. I can’t figure out why it should ever go beyond the value of 2.
I think you have to set the False logic pulse on the Property sensor (the button that looks like: [’’’]) on. That will send a False pulse when the sensor evaluates as false (I think), which should turn off the ability to press Up and increment the value.
No, false pulse just triggers the controller if the sensor’s state is false. It does not change the result of the controllers execution result (no activation).
The problem is, the property sensor does not compare with a property this way. What you wrote is: does Value contain the string “MaxValue”?
You could use an expression controller or
you can count MaxValues down: property actutator MaxValue-1
and check for not beeing zero: property sensor “not equal” 0
or if you want to keep the MaxValue set Value to MaxValue and decrement Value:
A) Always (no pulse) -> AND -> Property actuator “Assign”, “Value”, “MaxValue”
and
B) keyboard + Property Value not equal 0 -> AND -> IPO + Property actuator “Add”, “Value”, “-1”
Whenever you want to reset the value you activate the actuator of A)
Just done a few tests and it seems that the “Not Equal” Property sensor cannot use game properties as a value. If you hard-code it to the number 2 then you should get the behaviour that you want. It’s confusing since this is inconsistent with the Property actuator which you have shown can use game properties (in this instance at least).
(Edit: Confirmed. I changed the property actuator to set <Value = MaxValue+1> and the debugging info shows “Value = 3” as expected and the cube moves as expected since <Value != 2>)
I’m guessing this is because properties can be strings so the comparison will be with whatever you type in the Value box. What the sensor is probably doing is comparing the integer <Value> to the string “MaxValue” which will always evaluate as false since an integer can never be equal to a string.
Strange behaviour for sure, but kinda logical when looked at from the correct perspective.
Perhaps a more appropriate way of dealing with this would be to assess the type of property in the Property box and compare it to the value given in the Value box and if there is a mismatch then an error should be thrown. It would also be nice to use object properties as the Value as you have tried to do, but this currently seems to not be possible.
…On further consideration, surely the Property sensor should accept game properties or hard-coded values as default and require that strings be placed in quotation marks.
You could use expressions to do this very simply- plug your keyboard sensor into a controller, and set the controller type to expression. Then in the field on the controller, type
I tried it this way and yes, the logic does work! The keyboard events only produce movement appropriately, i.e. the propPosition doesn’t go less than 0 or more than the propMax property value.
However, for some mysterious reason, each keyboard click of right or left arrow increments the current propPosition property by a value of 2, instead of 1 as is coded into the Actuators.
If someone could figure out this new glitch, I should have the problem solved!
As I said, the logic works just fine with regards to limiting the movement to only run between 0 and propMax. What I don’t get is why the propPosition property increments by two (2) with each activation. That makes no sense, as the increment Actuators should only fire once per keystroke. (Right?)
I apologize, but I’ll need more explanation than most other people. While I’ve written thousands of lines of Python code for Blender, I have practically no experience with the BGE.
Monster: If you are actually answering my question about the +2 increment (which I believe you might be) I’ll need a little more info on how to do what you suggest.
I think it’s sending two because the keyboard sensor’s sending two pulses to the property actuator, one for pushing, and one for letting go - Monster’s method of checking to make sure the keyboard sensor is true and that propPosition is not = 0 (for the left key arrow) should work.
Your theory was interesting, but didn’t pan out. I tried running the above .blend and holding down the keyRight and keyLeft keys rather than tapping them in order to test if the second pulse was being sent on the release of the keys. My test indicated that the propPosition increments/decrements by two (and exactly two) with each keypress, regardless of whether the key is tapped or held.
Here I have a scene with two empties, each with identical Sensor and Actuator bricks attached. The only difference is that one of them has a simple AND controller and the other has an expression controller. When you press the space bar (activating the Keyboard sensor) the property in the object with the AND sensor increments by one as expected. The other empty’s property increments by two.
I’m sure someone will be able to explain why this is happening. I can’t be the first person to run into this!
Here’s a new scene with that setup: