mekonbekon's Forum Posts

  • dop2000

    Sorry, I should have clarified - using the wait 0 seconds returns a count of 0 even if other sprites still exist, hence me using a function after the wait to escape the picking

  • I've just recently been using object.count in a project; I noticed that the count doesn't update within the same event, so if you have:

    on sprite touched: destroy sprite; set text to sprite.count

    ...it still includes the touched sprite within the count, because the sprite still exists until the next top level event (I think?).

    Changing this to:

    on sprite touched: destroy sprite; wait 0 seconds; set text to sprite.count

    ...returns a count value as 0, I'm guessing because in this case it only picks the sprite that's been touched and destroying it means there's no sprites left in the pick. I'm not sure why the same picking logic doesn't return a count value of 1 in the first example.

    One way I managed to get around this was:

    On sprite touched: destroy sprite; wait 0 seconds; call function "count"

    On function "count": set text to sprite.count

    I'm sure there are other ways though.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You're welcome!

  • Hi Flipop

    I'm guessing from your capx that you've added events 7-10 to keep the player ship facing up?

    If you want the player ship to face in the direction of movement, rotate the image 90 degrees clockwise in the image editor; 0 degrees starts at 3 o'clock, so if your ship is facing up in the image editor then it's pointing at 270. Be aware that when a bullet is created you will have to set its angle to the ship angle.

    If you want to make your ship always face up the screen, keep the image facing up in the image editor (as it already is) and in the player object's 8-direction change the "Set angle" setting to "No".

    Couple of other issues:

    1) In event 6, you don't need to set the bullet and enemy direction every tick, just when they're created.

    2) In event 11, you only want this to trigger once. To be honest I wouldn't use a wait action here at all. Instead I would add a condition to your keyboard input to only fire a bullet if the bullet value is greater than 0.

    I've created a revised project for you that simplifies the code:

    https://www.dropbox.com/s/n6x6kdtqc0hzs ... .capx?dl=0

    Here are some of the main changes:

    1) Instead of having a trigger for each keyboard input, I have one trigger that checks for any keyboard input, then a check to see which input was made. This reduces the requirement for multiple trigger checks.

    2) I added a condition to this event so that it only fires if the number of bullets is greater than 0.

    3) I used the following expression to determine which image point to fire the bullet from:

    int(Keyboard.StringFromKeyCode(Keyboard.LastKeyCode))

    This checks the last keyboard input (Keyboard.LastKeyCode), then converts it into a string (Keyboard.StringFromKeyCode), and then converts that string into an integer (int).

    4) I set the bullet direction when it's created, based upon the player direction.

    5) I set the enemy direction when it's created.

    6) I've set the parallax of the text layer to 0,0. This keeps the layer fixed and the text object in the top left corner.

    Hope that helps! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">

  • Hi KitaWolf,

    This is the method I use:

    Add the AJAX object to your project.

    Add the following two events:

    1. On start of layout| AJAX: Request array.json (tag "yourArray")

    2. AJAX|On "yourArray" completed |Array Object: Load from JSON string AJAX.LastData

    You can leave the size of the array object at 0,0,0 - it will automatically resize to fit the array.json data.

    If you run the game in debug mode you can check that the json data is correctly being grabbed by the AJAX request and loaded into the Array object.

  • Uglypenguin

    You're welcome

    There may be an issue with pathfinding breaking if the pathfinder is off-screen - I'm investigating further. For now, I'm switching off the pathfinding in that circumstance using an "Is not on screen" condition .

  • imothep85

    System|Compare two values| first value: find(text.text,"sardines") is not equal to second value: -1, do your action

    From the manual:

    find(src, text)

    findCase(src, text)

    Find the first index within src that text occurs, else returns -1. find is case-insensitive, and findCase is case-sensitive.

  • Hi Uglypenguin,

    Would something like this work for you?:

    https://www.dropbox.com/s/y3le8v60o0kps ... .capx?dl=0

    You can control the hunter with cursor keys, press left mouse to try and hit a prey.

    I've placed a trigger box object (for reacting to the hunter) and a target object (for pathfinding) in a container with each prey to make it easier to see what's going on with the pathfinding behaviour, but you could substitute these for instance variables on the prey if you needed to reduce the object count.

    Toggle prey trigger box and target visibility with the space bar.

    In general it works ok but very occasionally a prey will lock up - haven't figured out why yet.

  • dop2000

    This kinda works - you move the camera position towards the focus point as a fraction of the current scale

    https://www.dropbox.com/s/csqvsgs3jrn4z ... .capx?dl=0

    It goes a bit squiffy if you release and click again before the scale has returned to 1 (I think because the offset values are recalculated whilst its still scaling?) so umm... don't do that <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":-)" title="Smile">

  • —

    The "condition X" was to illustrate that usually you wouldn't have a trigger once in a group by itself, it relates to the other code in the group.

    One example of how I use this is having a number of game states that may be on or off at any time during play, each containing an independent loop. I put the code for each state in a group. When I want to turn off a particular game state I disable its group, switching off that loop. When I switch on the game state again the "trigger once" refires allowing me to reset any variables etc pertaining to that state.

    No doubt there are other ways to code this; I find this method to be straightforward to implement, easy to read and with some benefits towards optimisation as you can be sure that none of the code in that group is going to be checked or triggered whilst it's disabled. But hey, to each his own!

  • Obviously if your only condition is an overlapping check, sure disabling the group could improve performance if the number of objects are huge.

    That was kind of my point - there are situations where it is useful to be able to simply turn off chunks of code, which would be a better optimisation than the ordering of conditions, where the checks would still be made even if the actions aren't triggered.

    But i think starting to see groups as a completely valid solution to solve a large amount of issues is simply not a good way to start thinking about programming in C2, because the moment you run into problems like performance, instead of thinking about how to optimize your code, you start relying on a "lazy" approach or what to say.

    I wouldn't consider it a lazy approach, rather learning the options that C2 affords you and then using them appropriately. Certainly you need to know what you're doing and I wouldn't advise beginners to dive in without an understanding of them, but that goes for pretty much all the features of C2. I'm certainly not advocating for using them as a catch-all for optimisation.

    Im not sure what you mean with resetting top level for trigger once conditions and how disable and enable groups is good here, compared to for instance making correct conditions? I won't argue to much against this, because im not sure what you mean.

    As I understand it, if you have something like:

    GroupA
Trigger once | do action
Condition X | do another action
[/code:sqmlm5sj]

Each time the group is reactivated the "Trigger once" action would fire.  This saves you having to set up a bunch of variables or other conditions to reset the Trigger.

  • nimos100

    Whilst in rafaelsorgato 's particular case you're right that groups are the cause of the problem (if the group is disabled then necessarily you can't trigger any events within that group), it's misleading to say that you shouldn't be using groups in any circumstance. There are many valid reasons for doing so, most importantly because no checks are made against events in deactivated groups, which can lead to significant performance boosts, especially if those checks are on large numbers of objects/instances. Also deactivating and reactivating groups is a convenient way to reset top level "trigger once" conditions.

  • Portvayne

    No, this has been an ongoing issue. Not sure if it was fixed for a bit, it'd be a shame if this problem has come back.

  • I guess you could add a second boolean and do:

    If sprite.boolean1 and !sprite.boolean2 | do action; set sprite.boolean2 true;[/code:3ge5743s]

...but if I'm going to do that I might as well use the number variable technique I mentioned above.

  • dop2000 That's a pity. Ah well, at least I'm not being a complete idiot about it!