Rhindon's Forum Posts

  • And please don't feel bad for the long post. The way my mind works is odd. At times I need long, detailed info. Other times, short-n-sweet is what's needed. God only knows when I'll need which one. LOL Honestly, I have a hard time knowing, myself. I just keep asking questions until I figure out the right question that gets me the right answer. With all your info, if I'm still confused, at least I'll be able to sort things out a bit to know where I'm still unsure. Again, I'm SO grateful for your effort and your willingness to give such a thorough answer. THIS is the kind of detailed approach I've needed since I started using C2 several years ago.

  • I'm definitely going to read all of this and play around with your .capx. THANK YOU! I'm very, VERY grateful for this info and all the time you took to put it together. God bless you!! TRULY!

  • Despite there being a sample .capx file that illustrates how each blend mode words, I am sometimes still at a loss when it comes to understanding what it is I'm seeing. Namely, the "behind the scenes" and the terminology sometimes escapes even as I think I finally get it...

    For those with a better grasp on such things, could you explain what each blend mode is, what exactly is going on between the objects as the blend effect is active, and what "additive", "destination out/in", "source out/in", "XOR", etc, etc, etc all mean, please?

    Basically, I need a "...For Dummies" explanation.

    Thank you, kindly!

  • Thank you, rexrainbow! As always, you have my deepest gratitude. I will check those out and see what I can learn from them. GOD BLESS!

  • — and R0J0hound - thank you both for everything. It always means a lot to me to have such kind and supportive people like yourselves. GOD BLESS you for that.

    And I had a feeling rexrainbow would be THE go-to guy.

    (Rex, if you have anything specific that could assist me, would you point me in the right direction, please? Otherwise, I will try to find the list of everything you've done so far... God bless you, too, sir!)

    I'll check out the videos you suggested, GameCorp, and see if those give me a proper direction for what I'm trying to do.

    Although, in my initial search, I did find several potentially good options in the tutorials section: https://www.scirra.com/tutorials/search?q=AI

    THIS one stood out to me: https://www.scirra.com/tutorials/1051/b ... cing-games

    I'm still just starting to go through them, so I don't know which, if any, would suit our needs for a racing game as we picture, but maybe that'll help.

  • I'm working on a simple top-down racing game.

    Initially, the idea is to simply set the best lap times along with some other challenges I would add.

    But I feel that it would be important to add traditional racing elements, which means the option to race against other cars, typically controlled by the computer. My problem is creating A.I. that's natural enough to feel like it's actually trying to RACE you.

    Basically, what are some resources or ways I can do that within C2?

    I know Pathfinding behavior would be my initial go-to, but I have this sense that it won't be completely suitable (I could try to articulate why, but I'm trying to keep this a short and to-the-point post). Alternatively, I might be able to devise something using the Bullet behavior and a constantly updating direction based on any other obstacles or cars on its way to its immediate goal on the track... (Easier to SHOW than to explain what I'm thinking...)

    Anyway, while I test out some ideas and do some searching, myself, I would be grateful if anyone could point me to some proven racing A.I. tips and tricks, please. Thank you so much!

  • Thank you both.

    In this case, Ashley, the angle is updated based on the angle because the character and the mouse object - no lerping (but I do believe I understand what you're saying). It's strictly that one condition that goes from testing between -112.5 & -157.5 to -180 & -157.5. It's that crossing the -157.5 line that the system doesn't get.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Ashley, if you have a spare moment, could I get your input, too, please?

    Namely, some deeper understanding of why the return value for the angle( ) is giving negative numbers. I'm afraid I'm at a loss for why that is. Thank you, sir!

  • I spoke too soon. I still couldn't get it to work and I tried a few different implementations of your advice.

    Could you send me a copy of your edit so I can see how you did it, please?

  • Oh okay. Thought that was it. Thanks again! God bless you, sir!!!

  • Thank you, — For clarification, where would I place that, exactly?

  • .CAPX: https://dl.dropboxusercontent.com/u/36080515/Export%20(1)/Foxtrot-89%20v%201-1.capx

    With the use of the mouse object, I'm using angle(F89.X, F89.Y-30, Reticule.X, Reticule.Y) and it's always-updating angle in order to set the proper animation for the gun-toting Foxtrot-89 character.

    There are 8 facing directions (360* / 8 directions = 45*).

    I discovered that when testing for angle ranges (ie: 22.5* to 67.5*), that any angle above F89 is counted as a negative value. So it ranges from 0 to 180 or 0 to -180.

    Every angle test works (animations are updated correctly) EXCEPT for the transition from the top-left (-112.5* to -157.5*) to neutral-left (-157.5* to -180*).

    In my capx file, at event lines 19 and 20, you'll see I had to use the two lines to test for the full 45* because of the horizontal divide from the negative to positive value angles. Once I move the angle to 157.5* to 180* (positive values, or down-left facing), the proper animation (neutral-left) goes into effect, but it's not taking into account the full 45* range. When transitioning from an up or down right-facing angle to facing neutral-right, there's no problem. ONLY when moving from up-left to neutral-left.

    Can someone help me see what I am missing, please? Thanks!

  • I tested this out for several minutes and my MAIN concern - not being able to go through junctions when the path is open, and vise-versa - appears to be resolved. That is ABSOLUTELY a God-send! Thank you again! You're a life-saver! I'm trying to get this ready for a March 31 release and you nailed it!

  • blackhornet - Thank you so much! I'll have a look now that I can actually get back into Scirra.com.

    While waiting for the servers to get fixed, I've doing my own tinkering and almost had a solution...ultimately, same problem. If this doesn't work, I'm going to try something different than the sliding walls altogether.

    Also, I corrected the fact that you could slide through walls while they were moving - that's not supposed to be able to happen and I just hadn't gotten to a fix yet.

    That two ghosts can be on the same junction shouldn't be an issue. ... But then (as you know) I'm in a constant discovery state, where things come up that I didn't know about or didn't account for. So, if it's an issue, it's PRESENTLY outside my scope.

    Thanks for your help, as always! You're awesome!

  • As you suggested, blackhornet, I tested things on a smaller scale, and as far as I could make out, everything worked. I only changed the layout, using fewer sliding wall pieces.

    When I copied my current layout and deleted about 2/3 of the maze, I didn't realize at first that that would re-do the UIDs for each object. So I updated the Wall_UID variable values for each of the JunctionCheck object instances. ... That seemed to work.

    But then I went back to my original layout and found that all the WallSlide UID values and the Wall_UID variable values had not changed. There was no problem there. It was all exactly as I set it up and should be.

    So now I have tried...

    1. Removing the Pick All condition (lines 103 and 118), and putting them back.

    2. Adding a For Each JunctionCheck as a 3rd condition on the same event lines.

    3. Replacing the Toggle Boolean with If This/Else conditions for the same variables (sub-events for lines 103 and 118).

    What I have found is that some of the Boolean values will change while others will not when addressing each set of JunctionCheck Boolean variables as related to their respective WallSlide object. When the WallSlide is done sliding positions, it seems that...

    1. Two of the four JunctionCheck Boolean values will update properly.

    2. All four Boolean values will be completely opposite of what they should be (making it possible to pass through the wall when you shouldn't, and the other way around).

    3. Some JunctionCheck sets will update fine without any trouble whatsoever.

    So I'm totally confused as to what's going on. I cannot figure out WHAT is causing this problem.