Hello, all.

I'm looking for a C2 algorithm for 1 condition on key press that could check 4 things.

I have 4 elements/sprites.

"story so far"

"continue"

"start a new game"

"controls"

They blink on auto in sequence as selections.

Currently I have this setup:

if button is pressed (say XPAD D-pad up):

if anim "blink" in "story so far" is playing:

<-- set anim "default" in "story so far"

<--set anim "blink" in controls

2 other conditions for the other elements

if anim "blink" in "controls" is playing:

<-- set anim "default" in "controls"

<--set anim "blink" in "story so far"

**This ends up executing 2 conditions because of the resets as opposed to 1**, (1 exclusive condition check is what I need), so the list never goes to the last element.

I'm guessing this is a pretty common problem in programming, so the solution is just having 1 condition check on key press which checks 4 things?

No idea how to program this.

I'm guessing something with pushback array, etc.?

Doh! Ugly jump it is then.

I suppose I could do exclusive control systems at start, but that takes all the fun out of it (can't switch to keyboard in middle of game if you want to).

Thanks.

Ashley

lucid

I mean this.

Lucid seems to have done it. I just need the capx.

Basically I need to position the mouse/touch cursor once on key press at specific coordinates in game, say sprite.x, sprite.y.

After that, business as usual, player input controls the mouse cursor.

I need this because I have an ugly jump when switching between control systems, from keyboard/touch to XPAD.

Because in XPAD 360 Controller mode (as opposed to keyboard/touch modes, which are mouse based), the analog stick steers the cursor, so when player switches the control modes, cursor position is different and I need the mouse cursor to jump to that position.

How would I set the position of the mouse cursor/touch position to a sprite in C2?

Found an old post by the Spriter Dev on it, but expired link.

If the two aren't separated by events, can I safely assume that mouse cursor position = touch position by default?

I figured it out.

You can add an "or" condition Player_Ship1 is within 0 degrees of 270 degrees, but again that's a weird patch.

And none of you so called programming types could even suggest it.

Hah.

Well, that's that, but again it's super weird.

Ok, I have one last thing to say.

Changing 270 to 271 does work and the ship won't technically go off screen even though it does drift down slightly, but why would you even need to do that?

I completely don't understand this style of programming and yes the manual is very confusing. We shouldn't have to test every little thing.

Basically the way the in between function is coded is ridiculous because it forces you to use an extra number and behavior I didn't want (it should work at just 270 without having to go into 270.353535 or whatever).

And when one states in the manual something is in a 45 degree quadrant, that should mean 0 to 45 degrees.

So I think this is sloppy software design.

And this is the only bug I found in my game, which seems to be unfixable because of C2 design.

—

Try creating "System->Is between values" event in C2.

You'll see that it's inclusive of lower an upper bounds:

lowbound <= num <=highbound

I'm a bit late to the party, but I agree with Bruno and others.

OP's attitude is terrible and the project is a complete mess. You can tell by simply looking at the file he posted - project is buried inside multiple sub-folders (\VARIABE_CLEANING\_NEWONE_USETHIS\windows splice in - Copy (10)) and includes a 4.5Mb backup file!

And instead of creating a small capx to demonstrate the problem, he demanded Ashley to look for a potential bug in that pile of garbage?!

Again, no need to be an asshole and you didn't help at all.

I frequently make backup copies cause C2 files go corrupt often, so a couple extra folders is no big deal.

The angle is checked whenever you touch R_Control. From looking at the code, the ship is meant to move in a certain way when beyond the Y bottom boundary as seen in event 140. This works for when he uses L_Control, as seen in event 149. If you set up triggers in the events you can see it gets all the way down to 140 but then he can't move right. He mentions this in OP :

"But to make this even simpler, because our founder appears to be really overburdened, what appears not to be working is in Line 140.

Basically make ship go down to lower boundary and once at lower screen boundary it won't go right at the default angle of 270, even though it should."

As I mentioned earlier the condition for 140 is never satisfied, but everything up until that point is working fine. Y < Player Y Bottom Boundary is a separate check to Y > Player Y Bottom Boundary. I agree that the controls are ridiculous though and the investigation took a while, Ashley would've been wasting time.

"I agree that the controls are ridiculous"

No need to be an asshole and you didn't offer any solution.

Keep that sort of **** to yourself.

Hi AmpedRobot!

The problem has nothing to do with angles. Actually, they're not even being checked at that moment. It's just that, when you go backward you can actually go beyond your PlayerYBottomBoundary variable. Because of that, the condition before the angles (Y < PlayerYBottomBoundary) prevents the movement.

That happens because when you move forward or backward you check for the boundary BEFORE moving the ship but without taking in consideration that the movement itself may take the ship over that boundary. In order to correct this you should create a cap that makes Y equal to the boundary whenever it goes beyond it or consider the distance moved when checking the boundary. Both solutions would work fine.

That said, I would strongly recommend that you do 3 things:

1. Review your code, because it's very dirty and very confusing and this will probably bring you more trouble in the future. Also, a lot of the stuff you're trying to do could be done in better, simpler ways.

2. Reconsider the controls for your game. From a game design standpoint they are terrible.

3. Be a little more friendly in these forums. People are here to help because they want to. They don't receive anything to do that, so, a little more politeness might make people more inclined to help.

Here's a screenshot showing my position and the boundaries. Ignore the position of the buttons. I just moved them to make it easier for me to control the ship.

Hope this helps. Cheers!

This is not helpful at all.

Very rude and totally useless.

You wanna fight, I'd suggest another forum.

This is from the manual.

"Is between angles

True if the object's current angle is between the two given angles in degrees. The first and second angles must be in clockwise order. That is, Is between 0 and 45 degrees is true if the object is in a 45 degree area, but Is between 45 and 0 degrees is true if the object is in the 315 degree area from 45 degrees through 0 degrees."

I don't know how to read that other than it includes bookend angles.

Wrong.

Check the manual.

Per the manual, the in between condition is supposed to include the bookend angles.

I can quote the manual in a sec.

What you replied makes no sense man. At 271, the ship can veer off screen.

That's the whole point of the limitation.

And it does seem to be some kind of bug unless someone can point out a mistake in my coding scheme or suggest one that actually works.

My ship orientation in this instance is 90 degrees counterclockwise versus default, so 270 as default.

Here's the official C2 degree chart for you spatially challenged gents.

http://www.darksunpictures.com/public/degree_chart.png

Just kidding! I'm spatially challenged. Well, when getting back to this I was, so I had to map it out and test in game. (It made perfect sense to me the first time I did this.)

And the conditions seem to be right as far as the degree limitations.

Remember, the whole point of this is custom boundaries and not letting the ship go off screen with touch controls depending on angle.