newt's Forum Posts

  • [quote:1fwdqh3u]I mean, should we be using sprites in this case?

    Same thing happens when you use multiple bgtiles, that are actually tilled.

    Example: Lets say you want to make a border with one tileable image on top, one on bottom, one on the left, and one one the right. Your still going to get the one pixel difference where the corners meet.

  • Well you said your using animation playing... how long's the animation?

  • Um what version, and what about extra modules?

  • +private.variable = 0

    +On control "p1_catch" pressed

    ->Catch ball

    ->set private.variable to 1

    +private.variable caught =1

    +On control "p1_pass" pressed

    ->Pass ball

    ->set private.variable to 0

  • Awesome, one event too!

  • I think the rts behavior can do all this, but it would take a lot of wrangling on the events.

    Probably more than you should mess with pre beta imho.

    If you want to play with stuff to see how it would work out, I would suggest for your melee characters you set the range to 1, then on the on shoot event you could have it change animation. Then for the hit you could work out some probability of a hit. To prevent the melee's from attacking over one another, use the rts condition object to avoid.

    Your ranged should be pretty straight forward, but you might want to add some event that makes them move away from targets then fire.

    Same goes for support, and commanders.

    One thing to consider is the type of view your dealing with, if this is top down, then no problem.

    If you want something like side view or isometric, things will get a little tricky with z order.

  • You could possibly use the sine movement, I think it still works in tandem with other behaviors.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • newt, can you post an example of what's wrong?

    Ok but don't laugh at my crappy event sheet...it's a mess

    http://www.mediafire.com/?dymmdx2yzvt

    Whats happening is I'm creating a bunch of random objects using the random pick on families.

    Somehow in the process they keep being placed above other objects... z order wise.

  • One step closer!

    Sorry to say families still are messing up for me tho...

  • Ok well I guess for realism's sake this: http://www.mediafire.com/?znqtwnuywnz

    Should be pretty close.

    I still say since its relatively easy to do, there's no point in changing an existing plugin.

    But I don't see why there can't be an additional plugin that does this.

    Goodness knows what the future will bring, especially if someone should ever make a easier way to make plugins.

    Perhaps something like a sub-plugin, that works in tandem with another plugin.

  • Or you could just add support for midi controls. I'm sure some smarty pants could come up with some music generation algorithms.

  • Couldn't you do something like:

    character is moving

    character angle is 30 degrees

    set max speed to max speed / 2

  • Isn't that what the timeline object was made for?

  • Well first off the on shoot trigger would have to be directly related to ammunition, so every turret that used it would be subtracting something every time its triggered.

    Ok thats great we got that part... blah, blah, blah, but what exactly are they shooting?

    That kind of limits the trigger to the object being created.

    Suppose I wanted to have an additional condition like:

    On tank shoot

    helicoptersprite is in range

    create object misslesprite

    Then if your going to have a rate of fire, wont that variable have be tied to the amount of ammunition?

    So now I would be stuck firing x amount of bullets, as well as missles etc.

    Would it not be just as simple to create a private variable, for something that would be somewhat obscure?

  • I could understand a setting for burst of fire, or what ever you want to call it, but I dont think an ammunition setting would be all that great.

    Sure it might be cool for some situations, but what about if the user wants to get more ammunition?

    Besides wouldn't that be better under the bullet behavior?

    Ok not really, as it stands there's a setting under the bullet behavior for speed of the bullet, and personally I think it would be better under the turrets behavior, unless you want to add a different bullet for each turret. Then again you can change just about all of the individual behavior settings during runtime.