Alcemon's Forum Posts

  • Keeping it short and simple because C2 is already quite cool (and I am sure that there must be a lot of these kind of lists around in the forums):

    -Reverse animation flow action

    -Sprite frame optimization (if two or more frames of the sprite are the same they don't get included twice)

    -Tiled Backgrounds

  • You are absolutely right, a sort of "myproject.capx.autosave" that doesn't overwrite your main file but to which you can return when everything goes wrong.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sorry for asking I know you guys are probably super busy as always but I think the program could really use a timed auto save feature.

    While the program is quite stable there are still a couple of crashing bugs that will eventually rear their ugly head. Unfortunately I cannot reproduce or find a pattern to them otherwise I would totally report them. It's just happens after one or two hours of use.

    Now I know that the "just save frequently noob" phrase applies perfectly to my problems but when things get exciting and you are lost "in the zone" it is hard to remember.

    Thanks for the cool and useful stuff you keep adding (replace object ftw) and hopefully, what I am asking for would not be too hard to implement as it would really help the ease-of-use of the application.

    Edit: Something like save every 5 previews would also be a workaround solution if the timed one has some sort of complication.

  • Thanks Everyone, I thought that it would kill all events where the constants were referenced (as the warning said) but it seems like good guy C2 spared all my events <img src="smileys/smiley36.gif" border="0" align="middle" />

    Edit: To be precise, C2 actually DOES delete all the events that reference your cut globals when you cut their definitions but they are all re-added as soon as you paste them back.

    So yes, it's safe to ignore the warning if you paste what was cut right away

  • Hello all, I have quite a big number of global variables (mostly constants) that I want to move to another event sheet.

    Of course these cannot be cut and pasted normally, and I also would like to avoid the following procedure:

    (1) duplicate all the globals with a slightly different name in the destination event sheet

    (2) going through the whole project renaming every use of all the moved variables

    (3) delete the now unused original globals

    (4) rename the remaining globals to their old names

    Any tips for making this process less painful?

    Thanks in advance

  • Have you tried using Groups and Subgroups?

    I used to get lost easily in my project's code but once I started using groups and subgroups more liberally it became very manageable.

  • I've noticed that previously they allowed webhosting for "anyone with the link" kind of sharing but this is no longer the case.

    Now they only allow webhosting for the "public" kind of sharing, which also indexes your game into Google's search results (which is good for a final version but bad for development versions that you probably don't want to share with everyone).

    Well, it's time to go back to Dropbox I guess

  • After looking into lerp and playing with its parameters for a while I believe that you can get all the results that you need just from it.

    For example for ease-out you use:

    lerp(start, finish, time_counter ^ 2)

    For ease-in you use:

    lerp(start, finish, time_counter ^ 0.5)

    You just need to make sure that:

    1) your time_counter starts in 0

    2) you increment it by some amount depending on how fast you want the movement to be (0.1 each tick its a fairly fast movement, so I normally use 0.05)

    3) your end condition is always time_counter = 1 (or greater).

    Finally, if you you you are looking for a higher-level solution you could always use the tween plugin as already suggested.

    I really like the art style of your game. Hope this was helpful :)

  • Grr, and I thought I searched well enough before posting. My bad.

    Well, no harm in repeating good things more that once ;)

    Yep. We've already got a thread about it, though. :)

    http://www.scirra.com/forum/topic62698.html

  • develop-online.net/news/43135/Wii-U-expanding-third-party-dev-range-with-HTML5

    If well done, this would be huge for HTML5 devs and Construct2.

  • 'System: Create Sprite' picks the newly created Sprite.

    'Sprite: Spawn Sprite' doesn't pick the new Sprite - the original one remains picked.

    ramones Wow! Thank you ramones, this is exactly it.

    In the end it was not a bug or a limitation. I think it's an undocumented behavior (as the manual entry for 'Create Sprite' and 'Spawn Sprite' do not mention this difference) that comes to light *ONLY* when the same sprite is spawning instances of itself.

    To explain it even better, we all thought that 'Spawn' ALSO picked the spawned object because code like the following would run without problems (again sorry for not embedding I can't seem to tame Google Drive for that):

    It seems like spawn it's picking but its not

    But the reality is, as ramones said, that Spawn *DOES NOT* pick the created instance (it just happened to get picked when we were spawning different instances because it was the most recent instance for the 2nd sprite in that scope).

    Thanks everyone, I am adding "SOLVED" to the topic.

  • R0J0hound thanks for your answer. I initially thought it answered everything but I did find an inconsistency that I wanted to address.

    Please look at the following snippet(sorry, I could not direct embed from a google drive image)

    docs.google.com/file/d/0B20uobjbjbtgS2tjX25TTTZPOG8/view

    The scoping rules that you mention in your two links are not breached. And yet it does not work as it should, as running that code would spawn infinite instances of Sprite1 as opposed to only 2.

    wretchedshark currently the thread is not so much about "getting something done in any way" (which in hindsight, WOULD be the objective of the "how do I do..." subforum). Many of the proposed solutions in the thread already answer the original question.

    It is more about finding an explanation for a C2 behavior I did not not anticipate or understand (as maybe it is known limitation, bug?).

  • vee41 Thanks for the tip. Basically this is using a global variables; (loopIndex and LastBodyUID) to help up picking and putting information into each of the instances.

    This also could work as an even better work-around to the one I linked but the truth is that it is still not possible to pick the created sprite when the spawning/creating command is done from another instance of the same sprite.

    Hmm...maybe both instances are picked (creator and created) and it's necessary to use 'Pick nth instance' before using it. I will try that right now and report the results.

    **UPDATE** Sorry, no luck, pick nth instance doesn't seem to help in this case.

  • wretchedshark, thanks again for the reply. We are getting close to the issue :)

    Now, try to make each sprite to spawn exactly to the right of the previous sprite (spawning in the predefined image point 2).

    To top everything make sure to alternate the use of the animation "clone" in such way that:

    -the first spawned is using the Default animation

    -the second spawned is using the clone animation

    -the third spawned is again using the Default animation, and so on

    This should not be possible without setting up information of the sprites immediately after the spawn (which is apparently not possible in Construct2 if the spawning sprite is the same as the sprite being spawned).

  • Thanks for the detailed reply Wretchedshark. As I told you in my first reply, this is exactly how it is solved in the forum post I linked (and how I actually do it in my project as a work-around).

    The problem I am running against is basically related to picking and sprite spawn recursion (my deepest apologies as it seems that I am utterly failing at explaining myself).

    Imagine that you have the following two lines running on a Sprite instance of "Sprite":

    Sprite | Spawn Sprite on layer 0 (image point 0)

    Sprite | Set spriteID to Sprite.UID

    Instead of having spriteID correctly loaded with the created sprite's UID, you would get the creator's UID loaded into spriteID (as Construct2 confuses the parent and child instance because they are called the same).