linkman2004's Forum Posts

  • I love you.

  • Alright, so this method seemed like exactly what I needed in terms of having my plugin check if the layout has changed, although it's either not working or not working as I would assume. When the game first starts the value is equal to true, but afterwards if you change layouts, restart the current layout, etc. it remains false. Am I missing something here? I'm assuming it should equal true for the first tick of each layout.

    For the record, I'm checking the value in my plugin's "tick" method.

  • I haven't found anything in the SDK manual about it, but I may just be missing it - is there any way to check the 'global' property of an object type through the SDK? If so, do references to instances of global object types remain the same across layouts?

    EDIT: I have found the answers to both questions. 'global' is a property of the plugin type and instances do persist across layouts.

  • Loop through the objects you want to sort using For Each(ordered) in descending order with the Y position of the sprite as the expression to evaluate, then send the object to the back of the layer. The objects will be iterated through from bottom to top and sent to the bottom in that order, so object's with a lower Y value - and higher on the screen - will end up in back.

    CAPX example

  • If you make money off your game - through ad revenue, direct sales, what have you - then you need to purchase the personal edition. If you make over $5000 in revenue, then you will need the business edition. The free edition cannot be used for commercial use in any capacity, as far as I'm aware. I'm sure Tom can provide a full clarification on the matter.

  • Thanks for the comments, guys - sorry I didn't reply to any of them sooner.

    Unfortunately, I don't have any plans to fix remaining bugs in this plugin - my familiarity with the code has dwindled over time, reducing my ability to identify problems. This, combined with my full-time work and school schedules - which leave me little time for my current projects - means I'll be dropping support indefinitely.

    However, I would like to say that I've just finished tinkering around with the C2 plugin SDK a little bit and I'm starting to get a grasp of what's going on in that regard. With any luck, you'll see something on that front in a few weeks time, although I make no promises.

    In the event that I do release a C2 version of this plugin, updates will likely be sporadic and I might start accepting donations as a way to offset the time invested. Life is a demanding mistress and I am submissive to its will.

    Be sure to keep an eye out for any updates - I'll let you guys know as soon as I have more to report.

    Once again, thanks for all of the downloads and comments for this plugin - I see it as my crowning achievement in this community and the support is much appreciated. <img src="smileys/smiley1.gif" border="0" align="middle" />

  • Yeah, x is simply a stand in for a variable of your choosing. For example, you could use:

    (sin((time * 1000) + 270) + 1) * 49.5 + 1

    Where "time" is the actual system expression for elapsed time in seconds - multiplying this value by 1000 gets you milliseconds. Multiplying "time" by a higher number will increase the speed of oscillation while multiplying by a lower number will decrease the speed.

  • Alternatively, if you want the silky smoothness of sine, you could just set your variable to:

    (sin(x + 270) + 1) * 49.5 + 1

    This will oscillate between 1 and 100. x can be any value you want, such as a variable you iterate by yourself, or you can take the game time and have a nifty one line solution.

    EDIT: Here's a Google Graph for the Hell of it

  • This is intended - you may have cases where you want to interact with an invisible object. Just check if your object is visible in the click event if you want to avoid interacting with it when it's not.

  • No problem, man - let me know if you run into anymore problems.

  • I had some suspicions that your problems were caused by incorrectly placed hot spots and that is indeed the case.

    Your 'PainBox' object has a hot spot that is far right of center, resting in a position such that - given that the X and Y coordinates represent this point - your player's position will always be left of X relative to that object. Centering the hot spot on the 'PainBox' will fix your knock back problems.

    For the health bar, your hot spot is once again out of alignment based on the effect you want. Placing the health bar's hot spot on the left edge of the image will result in the image extending towards the right relative to the hot spot, just as you want.

    As a nifty little trick - which you may already know - while editing hot spots in the image editor, you can use the number pad on your keyboard to quickly position it to the edges/center/corners of your image. So, for example, 4 sets it to the left edge, vertically centered; 5 to the center; etc.

    I hope all of this helps you out. <img src="smileys/smiley4.gif" border="0" align="middle" />

  • Well, I can tell you how to fix number 3. For each frame the player's health is equal to zero it will keep resetting the "Death" animation over and over again which means it never finishes - adding a "Trigger once while true" condition after the health check condition in event 6 should fix that by making the event run once.

    I can't be sure what's wrong in the first two cases - I have no context for what the objects are or how they're set up. If you provide your CAP file I'll be glad to look at it and help you out.

    I'll just mention that setting the X position of HealthBar won't do anything as HealthBar.X and your 'Location' variable are equal without changing.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I waited two solid minutes for it load on my Playbook but it never left the white screen - I'm running OS2.1.

  • This all comes down to an issue of reflexes - it's difficult to hold down a key for a single frame, thus the key may remain held for an additional one or two frames unintentionally causing unwanted movement.

    My solution

    I introduced a three frame timer into the equation to solve the problem. By moving once upon a key first being pressed, then utilizing a timer to delay movement a few frames before resuming movement, you can now move one pixel at a time and yet still move with a largely imperceptible input delay.

    I hope this helps. :)

  • If you post a CAP file, I can check it out and see what's going on.