Boolean rule, rotation setting and integer function help needed
STRIKENSUN41
Member, PRO Posts: 22
I’ve been on the search for how to do some of these things, and I feel I am close to getting them but haven’t gotten them to work.
First is a Boolean rule that I want an actor to move left when it’s set to true. So I have an actor with several rules for it to do this.
This seems to cause a problem, as I have text appear saying true when it does appear to be true (mostly for me to visually see it being true) and whenever I touch the actor, the true appears, but it goes bizarre. Like it literally flashes on and off. But it shouldn’t be turning itself off without me pressing the actor. And the actor doesn’t deactivate once pressed again.
I thought maybe I should set a counter for it to cycle through. So it’d be if 0, set to false, but if 1 set to true. And the actor would cycle through 0 and 1 each time it’s pressed. But I’m not sure how the rule looks for that.
The next thing is how I get an actor to spin around in a circle? I do know how to get an actor to spin around another actor, but what I’m looking to have is the actor rotate around. As what I have is it’ll go down and around, but doesn’t rotate. So an example of what I’m looking for is a circle, and a radius line. But if the circle begins to spin, the radius line will rotate with it.
Lastly is a set of integer ruling for how long I want a button to be held for.
I held down the button to see if it’ll ever stop and turn the Boolean rule false, but it never did. What I’m looking for here is to have a Boolean set to true when I hold a button, and have the integer set from 100 count down as I hold the button. Once the integer reaches 0, the rule should be set to false even with holding the button. And we’ll begin to recharge gradually for you to be able to hold the button again to set it back to true and count down again.
Comments
When attribute = 1
--Move left
Instead of a boolean, use an integer attribute.
When touch is pressed
--Change attribute to 1-attribute
Or if you want to use a boolean . . .
When touch is pressed
--Change attribute to (not)attribute
Just use the Rotate behaviour.
Alright, @Socks I have tested the one integer function for the moving left and right thing. I have gotten it to work, but it doesn't run smooth. I have a text showing when the integer true (1) or false (0)
I also tried the rotate function, but that seems to rotate the actor from the center when I want it to rotate from a certain point. It'd work if I constrained the actor to another actor that's rotating, but I feel there's an easier method. Like from the gif I showed with the circle spinning around, what I'm wanting is just the radius line not the circle at all. Though, I included an example of what I'm working on so it should be seen better to what I'd be wanting. The thing I'm wanting to rotate is the attack. And it should be rotating like the one radius line in the gif.
I think I got the integer function to work for the attack at least. I have text showing when it depletes.
As far as technical feedback goes, I'm not sure what I can do with 'it doesn't run smooth'
Constrain it to . . .
x position = (width/2) * cos (angle) + absolute x
y position = (width/2) * sin (angle) + absolute y
rotation = angle
@Socks Ah, I meant for not running smooth to be that it wasn't working perfectly. Like it would work, but sometimes doesn't. But I have decided to change how I'm going about moving the actor around, so don't need to worry too much on the reverse button.
I used the constrain attributes for the actor I'm wanting to spin, and it does spin but not from the location I want it to. I can see the x position and y position being where the actor is always at, but I'm trying to figure out how to change where it rotates from, as the rotation is always at the center of the actor. How would I change that location to the edge of the actor?
Could you post a screenshot of the rule you are using ?
self.angle is an angle attribute set to 0. game.ballx and game.bally is set for the positions of another actor.
Whoops, sorry, I presumed you knew your way around the basic trig used to move an object in a circle (you'd said: "I do know how to get an actor to spin around another actor") . . . so my answer was just shorthand for what you needed to do with the rules you already had.
You've also not provided any actual values (and words like 'edge' are less than useful in these kinds of conversations as it could mean a few things), so necessarily we need to use placeholders for the values too. If you were to say I have a 400 px wide / 80 px high actor that needs to rotate from the centre of the righthand edge in a counterclockwise direction I could give you the actual code, with the actual numbers, but saying that you have an actor - and not specifying the size - that you want to rotate - without specifying in which direction - and it needs to rotate from the 'edge' - without saying which edge - then you'll necessarily get placeholders like 'half the width' or 'width/2', but I didn't actually want you to type in 'width/2' I wanted you to use the correct value (i.e. in the above 400 px example, you would use '200') !!
So, I am going to assume your actor is - for example 600 x 100 px and needs to rotate from the lefthand edge in a counterclockwise direction, that it is using self.time for its angle, is moving at 90°/sec, and is placed in the centre of a landscape iPad project . . . .
Constrain position X to . . . . 300 *cos (self.time *90) + 512
Constrain position Y to . . . . 300 *sin (self.time *90) + 384
Constrain Rotation to . . . . . . (self.time *90)
Hope that makes sense !!
@Socks
Yes, that does make sense. I should have specified a little bit more into the details. So what I have is an actor with 50 x 10 px that I want to rotate clockwise. And the point I want it to spin from is at 0x5 px which would be from the left edge of the actor.
(^ quick example of the actor, assume width is 50 pixels and height is 10 pixels)
The x represents where I want the rotation to be constrained to. Lets call this actor "attack" for now.
I'm also wanting to make actor attack constrained to the locations of another actor which we'll call "ball." So actor attack should have it's left edge pixel 0 be at the center of actor ball, who's pixel size is 32 x 32. I believe Gamesalad has things spawn at the center point as a default, but to specify it, that would mean 16 x 16.
Actor attack should be continuously spinning clockwise while moving with actor ball on the center location of actor ball.
So that's why you probably saw a game.ballx attribute on one of the previous posts. As I have the game.ballx attribute constrained to the x position of actor ball. There is also a game.bally, which is also constrained to the position of actor ball.
I tried the one formula you posted with using half of actor attack which would be 25 and assumed +512 and 384 was the main location so I used game.ballx and game.bally instead. But it did constrain the location of actor attack to actor ball, but did not succeed in rotating actor attack.
Constrain the X position to 25 *cos ( negatively progressing angle ) + game.ballx
Constrain the Y position to 25 *sin ( negatively progressing angle ) + game.bally
Constrain the Rotation to ( negatively progressing angle )
You are probably not constraining the rotation to the correct value ?
This is most likely the case. I'm a little uncertain about how "progressing" works in the formula, like how it appears. Since if I constrain rotation to numbers being added, subtracted, multiplied, divided, that formula would lead it to having a single number result being the actors rotation. For instance, (self.rotation -10)*90. But what would make the formula be negatively progressing?
The usual trick would be to use game.time or self.time for the angle, but any changing value would do, for example you could interpolate an attribute, you could use change attribute within a timer or constrain a value to itself + an increment . . . etc etc
This is what using self.time would look like:
Constrain the X position to 25 *cos ( -self.time ) + game.ballx
Constrain the Y position to 25 *sin ( -self.time ) + game.bally
Constrain the Rotation to ( -self.time )
You'd also probably want to multiply self.time by some other value, as if 1 second = 1 deg it wil be rotating very slowly, so throw in something like *100.
@Socks
Alright, I got it to work with that. I tested interpolating, timer and constraining itself to see which worked better, and I find the constraining worked best. So I constrained self.time to (self.time+10). This made it rotate around at the speed I want it at. Though changing that number will change the speed.
Using timer, I don't even know how to describe how it worked. I want to say it appeared glitched, but I know that's not the correct term. Lets just say it didn't work exactly as needed.
But thanks for helping me learn how to get these functions to work.
I'm not sure how !!?
You can't constrain self.time (or game.time) to anything !! For example constraining self.time to self.time+10,000,000 will have no effect.
Ultimately if it works for you then that's all that's important, but could I see the rules you used, I'm curious to see how you made it work.
Some other rules I'm using that use actor attack are in actor ball.
Besides constraining game.ballx/y to actor ball position x/y, I have a space bar key input for spawning actor attack behind. This also changes the attribute attack to true. When attribute attack turns false (when space bar releases, or integer attack power reaches 0) actor attack becomes destroyed. This probably doesn't have much of an affect on this, but more as a mention on the side.
I figured the problem with timer, it's because I didn't use it fast enough that it had this odd movement pattern almost like a game and watch game. It should be set to something faster than 0.1 seconds. And has the change attribute with (self.Time+10)
Could you post a screenshot of the rules that constrain self.time to (self.time+10) ?
Have to change a little on the timer rule. I find 0.001 seconds is about as fast as it will work with. So changing the 10 to 15 makes it about the same speed as the constrain self.time to (self.time+10)
If it was the constrain attribute your looking for, I believe I had it in the previous message screen shot. It's the bottom constrain attribute. It's pretty simple though as all it is, is just constrain attribute self.time to (self.time+10). No other constrain function for self.time than that.
Thanks for the screenshot . . .
Like I say above, once it works, it works, and that's generally all that's important, but I just can't quell my curiosity as to what is actually happening here !!
Also, letting people investigate your rules can sometimes yield improvements in efficiency (so smoother running games).
Am I right in thinking that self.time is an attribute that you made, rather than the built in /default self.time that each actor comes with ?
What is confusing me is that Constrain is basically a timer that runs on every frame, so effectively it's an Every 0.01666.. seconds Timer (assuming your game is running smoothly at 60fps), so you have this Constrain changing self.time (assuming self.time is an attribute you made - otherwise you cannot change it) as well as a Timer changing "self.time" every 0.001 seconds !? (which the timer cannot do as 0.001 is faster than the game's frame rate, so will be changing the value every . . . . you guessed it . . . 0.01666.. seconds) meaning you have two 'timers' doing the same thing (albeit with different incrementing values), in theory you could replace both those behaviours with a single behaviour that increments the value by 25 (the sum of the two incrementing values).
?
@Socks
Yeah, it really does raise my curiosity as well. I'm not sure how it works either.
But you are correct to think that the attribute is one I made. I just realized that there is an actual self.Time. But the difference between my custom attribute and that one is that mine is an angle attribute while the default is a real.
Though the timer variation works, I find it more simple to just stick with the constrain attribute and set the timer one off (or delete it). This makes me curious now to what happens if both are running together.
After testing, it just makes it appear what you said by making a single behavior and setting it to an increment of 25. Meaning it rotates faster.
Yes, this is what I was referring to when I suggested using self.time to increment the angle, it's a lot easier than making a new attribute, constraining that attribute to a increasing value and using that as the angle . . . . I would get rid of all that stuff and simply use self.time (the built in clock that every actor has) -
So . . .
Constrain the X position to 25 *cos ( -self.time ) + game.ballx
Constrain the Y position to 25 *sin ( -self.time ) + game.bally
Constrain the Rotation to ( -self.time )
. . . and like I say you'd also probably want to multiply self.time by some other value.
Like this . . .
Constrain the X position to 25 *cos ( -self.time *180 ) + game.ballx
Constrain the Y position to 25 *sin ( -self.time *180 ) + game.bally
Constrain the Rotation to ( -self.time *180 )
Bear in mind that self.time is measured in seconds, it counts up in seconds, one at a time, and we are using this value as the angle that cos and sin operate on, so after 20 seconds your rotating actor would have only rotated by 20° !!! Much too slow for most things, so multiplying it by 180 means that after 1 second it would have rotated by 180°.
The only difference between an Angle attribute and a Real attribute is that an Angle attribute 'loops' at 360 (360°).
So if you have a Real attribute with a value of 350, and you add 20 to it, you will get 370.
Whereas if you have an Angle attribute with a value of 350 and you add 20 to it, you get 10.
Ah ! I see, they are variations, I thought you had them both running at the same time !
That's where I got confused.
If you have one behaviour incrementing a value by 10 every X seconds, and another incrementing the same value by 15 every X seconds, then switching them both on with see that value increment by 25 every X seconds.
Like I say, I'd not bother with all that, I'd just use the built in clock, no point duplicating something that already exists.
Your Constrain behaviour that says "constrain time to time+10" is running at 60fps, so every frame (1/60th of a second) 10 is added to the attribute 'time', so your actor is rotating at 600° a second, or around 1.75 rotations a second.
That worked as well, and would be simpler than making the attribute. Though either method works just as fine.
But other than that, it seems we've got this figured out now. And now I've got all the rules and functions to start making the app. Thanks again!
Agreed, there are probably dozens of ways of doing this, whichever one works is the right one !