Spawn actor into drag, picking up other actors

R3BORNUK

I would love for someone to tell me where i am going wrong in the attached pic.

I have a button that spawns the actor, which appears under the mouse. This triggers the inside rule, and as the wire.spawning variable is set to 1 at spawn, the actor follows the touch until you release. All great so far.

Now when you release it should set the wire.spawning variable to 0, stopping, in my mind anyway, that actor from ever being able to be picked up again.

Obviously I have something wrong with how GS is treating this logic. Any pointers?

R3BORNUK

.

The_Gamesalad_Guru

change to touch is pressed as you're constraining to the mouse and there is no way to unconstrain unless you're away from the actor which is impossible becuase you're locked to it. Else in this setup won't ever fire the change to zero.

R3BORNUK

It has to be to be picked up when it spawns under the mouseclick. The dragging works fine, the issue is that when i release and then try and click on it again, it should NOT follow the touch as the spawning variable should be 0

R3BORNUK

I don't think i have explained my issue properly.

When i touch the button (and hold it) the wire actor spawns above the button - the touch has now moved from the button to the wire. - good

I can move the wire actor around the screen - good

I can release the actor and move the mouse away from it -good

I can click anywhere on the screen and the actor stays where i left it -good

All good.

BUT, if i click on the wire actor again I can pick it back up and move it to another place. I want it to stay where it is after the first drop. This is what the .spawning variable is for.

AlchimiaStudios

Did touch is pressed not work?

Also what is changing the .spawning variable is the first place to the value 1?

The_Gamesalad_Guru

Put in a display text and be sure it is resetting to zero. If that's all the code it looks right.

AlchimiaStudios

Oh nevermind, i see it's the default value.

The_Gamesalad_Guru

@AlchimiaStudios said:
Oh nevermind, i see it's the default value.

Yeah I check that.

AlchimiaStudios

I see the issue now.

You cant change it in the otherwise because of the rule structure.

It has to meet 2 conditions to change to 0 and one of the conditions is that the variable needs to be set to 0 already.

AlchimiaStudios

@R3BORNUK A work around would be

---

create variable self.DragStatus with default value of 0

when touch is pressed and self.spawning is 1

change self.DragStatus 1

do drag logic

---

Seperate rule: When touch is released and self.DragStatus is 1
Change self.spawning to 0

R3BORNUK

@AlchimiaStudios said:
@R3BORNUK A work around would be

---

create variable self.DragStatus with default value of 0

when touch is pressed and self.spawning is 1

change self.DragStatus 1

do drag logic

---

Seperate rule: When touch is released and self.DragStatus is 1
Change self.spawning to 0

Thank you this worked.

However, and i say this as a professional web developer and arduino programmer, my original logic was correct in regards to standard if/else format. It really should have worked.

It will be interesting to see what other surprises GS has.

Again, thank you

The_Gamesalad_Guru

Did you see if the attribute was changing with the way you originally had it by using a display text to show the self attribute?

The_Gamesalad_Guru

@AlchimiaStudios said:
@R3BORNUK A work around would be

---

create variable self.DragStatus with default value of 0

when touch is pressed and self.spawning is 1

change self.DragStatus 1

do drag logic

---

Seperate rule: When touch is released and self.DragStatus is 1
Change self.spawning to 0

I told him to use touch is pressed. In that rule he showed he was using touch is inside. I said that was the issue..lol if he had just changed touch is inside to touch is pressed his original would have worked. As I say, just because it works doesn't mean it's right.

AlchimiaStudios

@R3BORNUK said:

@AlchimiaStudios said:
@R3BORNUK A work around would be

---

create variable self.DragStatus with default value of 0

when touch is pressed and self.spawning is 1

change self.DragStatus 1

do drag logic

---

Seperate rule: When touch is released and self.DragStatus is 1
Change self.spawning to 0

Thank you this worked.

However, and i say this as a professional web developer and arduino programmer, my original logic was correct in regards to standard if/else format. It really should have worked.

It will be interesting to see what other surprises GS has.

Again, thank you

You're using an ALL rule that means for the otherwise section both conditions had to be met as complete inverse.

That means that touch had to be outside and self.spawning had to be 0, so therefore you cannot have it change to 0 because it has to be 0 to change to zero...

R3BORNUK

I would have assumed the ALL rule equal to logical AND / &&.

Obviously not> @Lost_Oasis_Games said:

@AlchimiaStudios said:
@R3BORNUK A work around would be

---

create variable self.DragStatus with default value of 0

when touch is pressed and self.spawning is 1

change self.DragStatus 1

do drag logic

---

Seperate rule: When touch is released and self.DragStatus is 1
Change self.spawning to 0

I told him to use touch is pressed. In that rule he showed he was using touch is inside. I said that was the issue..lol if he had just changed touch is inside to touch is pressed his original would have worked. As I say, just because it works doesn't mean it's right.

I did exactly that, and no it did not work. As I explained, the touch needed to transfer from the original click on the spawner, to the spawned item - requiring inside. "lol"

Alchimia: Aye, it was an incorrect assumption on my part as to how the ALL rule works. I assumed it was equivalent to:

if(condition1 && condition2){
workings
}else{
fallback
}

Which is how you would achieve the all effect in normal programming, In GS it seems the logic is thus:

if(condition1 && condition2){
workings
}elseif(!condition1 && !condition2){
fallback
}

I find this really strange, and to me makes it much harder to achieve simple if/else statements with multiple conditions. Are you able to explain the GS centric benefit of this format?

The_Gamesalad_Guru

So you want the wire to constrain to the mouse when it first spawns and then be able to release it?Then be able to pick it up again and move it?

That's because rules are not if statments but when/else

R3BORNUK

@R3BORNUK said:
I don't think i have explained my issue properly.

When i touch the button (and hold it) the wire actor spawns above the button - the touch has now moved from the button to the wire. - good

I can move the wire actor around the screen - good

I can release the actor and move the mouse away from it -good

I can click anywhere on the screen and the actor stays where i left it -good

All good.

BUT, if i click on the wire actor again I can pick it back up and move it to another place. I want it to stay where it is after the first drop. This is what the .spawning variable is for.

Gave a walk-through of my intentions above.

I don't mean to sound uppity regarding this issue. GS is madly popular and the devs obviously know what they are doing.

Regardless, Alchimia's solution was a good workaround

AlchimiaStudios

@R3BORNUK said:

@R3BORNUK said:
I don't think i have explained my issue properly.

When i touch the button (and hold it) the wire actor spawns above the button - the touch has now moved from the button to the wire. - good

I can move the wire actor around the screen - good

I can release the actor and move the mouse away from it -good

I can click anywhere on the screen and the actor stays where i left it -good

All good.

BUT, if i click on the wire actor again I can pick it back up and move it to another place. I want it to stay where it is after the first drop. This is what the .spawning variable is for.

Gave a walk-through of my intentions above.

I don't mean to sound uppity regarding this issue. GS is madly popular and the devs obviously know what they are doing.

Regardless, Alchimia's solution was a good workaround

@R3BORNUK said:
I would have assumed the ALL rule equal to logical AND / &&.

Obviously not> @Lost_Oasis_Games said:

@AlchimiaStudios said:
@R3BORNUK A work around would be

---

create variable self.DragStatus with default value of 0

when touch is pressed and self.spawning is 1

change self.DragStatus 1

do drag logic

---

Seperate rule: When touch is released and self.DragStatus is 1
Change self.spawning to 0

I told him to use touch is pressed. In that rule he showed he was using touch is inside. I said that was the issue..lol if he had just changed touch is inside to touch is pressed his original would have worked. As I say, just because it works doesn't mean it's right.

I did exactly that, and no it did not work. As I explained, the touch needed to transfer from the original click on the spawner, to the spawned item - requiring inside. "lol"

Alchimia: Aye, it was an incorrect assumption on my part as to how the ALL rule works. I assumed it was equivalent to:

if(condition1 && condition2){
workings
}else{
fallback
}

Which is how you would achieve the all effect in normal programming, In GS it seems the logic is thus:

if(condition1 && condition2){
workings
}elseif(!condition1 && !condition2){
fallback
}

I find this really strange, and to me makes it much harder to achieve simple if/else statements with multiple conditions. Are you able to explain the GS centric benefit of this format?

I'm not sure why it doesn't evaluate the else condition like most languages would. The only things I can think of are they wanted to make it easier for people to create rules without the complexity that can come from using a ton of else if/else when they initially created the engine. So they just kind of combined them into a "otherwise" or else that functions as an else if.

I'm sure you've seen the little logic "puzzles" that can come from coding with and/or + else/else if statements in real languages, might be daunting for a new user.

I guess the downside is the results you see from something that should be easy becoming harder.

It could also be the way the game engine reads/iterates on the logic.

Maybe @CodeWizard or @BlackCloakGS has more insight.

tatiang

Based on this definition, "The logical AND operator (&&) returns the boolean value true if both operands are true and returns false otherwise," GameSalad functions exactly this way.

When you have a rule with two conditions set to "All", it means "If A && B."

So your example rule that says:

If [all] touch is inside
If self.wire.spawning=1

Is going to trigger when both conditions are true. The "Else" section is going to trigger when both conditions are false or when one condition is true and one is false.

Is that how than you would expect it to function in other programming languages?

tatiang

@Lost_Oasis_Games said:
Did you see if the attribute was changing with the way you originally had it by using a display text to show the self attribute?

As @Lost_Oasis_Games said, I think the question is whether or not self.wire.spawning is 1 or 0 when the actor is first spawned and for the first few moments the actor is active on the scene. To test this, use a Timer set to Every 0 seconds with a Log Debugging Statement inside with the expression self.wire.spawning. Let the actor spawn and then stop the program and check the Debugger Window. Do you see all 1s or is there a 0 somewhere in the log (obviously, 0 should show up once you release the mouse button but what about before that)?

AlchimiaStudios

@tatiang said:
Based on this definition, "The logical AND operator (&&) returns the boolean value true if both operands are true and returns false otherwise," GameSalad functions exactly this way.

When you have a rule with two conditions set to "All", it means "If A && B."

So your example rule that says:

If [all] touch is inside
If self.wire.spawning=1

Is going to trigger when both conditions are true. The "Else" section is going to trigger when both conditions are false or when one condition is true and one is false.

Is that how than you would expect it to function in other programming languages?

If that was the case and his logic started with self.spawning being either 0 or 1 he should see that it is either unmovable right away or as soon as the touch was outside it would not be able to be picked up again (intended).

His original problem was that it continues to be able to be picked up, hence the otherwise is not triggering with just the condition of touch is outside not being met, which in the link you provided would be the correct functionality of "else".

tatiang

Hmm, I see that I wasn't quiet clear on the intended behavior. If the mouse is released, you shouldn't be able to then click and affect the actor again. If that's happening, there's some other cause.

Any chance you can post the project file (.zip it first), @R3BORNUK?

R3BORNUK

Spoken to Alexandria @ GS. Seems my issue has brought a bug to their attention. Glad it's not just me going mad

R3BORNUK

You still want the file tatiang? GS are already looking into it.

tatiang

Only because I'm curious but nah, if they're looking into it I'm sure they'll find a cause.