megatronx's Forum Posts

  • megatronx

    Probably the same way as with the physics behavior. All physics objects will push out of each other. I haven't tried it so I don't know if there is any fighting between the behaviors that might make the objects jitter.

    I tired setting it up myself, but I can't get it to work. :< Units either fall or overlap each other.

  • R0J0hound

    Hi! Do you know how to integrate chipmunks and rts, for units not to walk on top of each other? Thx! xxx

  • Hey,

    A while back i reed that you can pair chipmunks physics with rts, for units not to walk on top of each other. Can someone tell me how to make it work that way?Thx!

  • You mean in the editor? Yes, that would be helpful, and in fact lack of that option becomes very frustrating at times.

  • I agree that there shoud be z-index option by default, and I hope c3 will include that feature, however you still can do it efficiently with events, sorted by Y axis. You can narrow it down to specyfic objects. You can make it a function that you call every time you need to z-order everything.

  • I have my own way of doing so too - about prefixes. Still, icons would be neat.

  • Or just small icon before the name.

  • It is problematic in did, and definitely happens when game is upscale, but not sure if the problem exists if displayed in original window.

  • Thanks for the reply! That's a valid way to do it, but I want to keep all turret initialization logic in the turret's on created event even if it adds one additional condition per faction (color). I'll have various things using these faction families and hate to spread the initialization logic for them around at that level. But your suggestion should definitely work and in the short term I'll probably do something like that so I can move forward.

    Still, my first approach should work - do you have any idea why it wouldn't? I'm using a similar picking system in other cases to treat families more like components, and it seems to be working just dandy. But this makes me think I'm misunderstanding something fundamental (and apparently pretty important) about the way families work, picking works, and/or the way the turret behavior works.

    Then the events that are the same for both, make for the family that includes both types. But when you need turret to aim at the other group, it's best to have it separated. Will save you time, and frustration, and performance is the same!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • megatronx it's almost possible, but families in their current form + containers just doesn't cover all the situations well enough to reduce my code, so it's pretty much one sheet per enemy graphic and even then I'm having glitches with multiple enemies using the same code, just not quite 100%.

    Yes, it can get problematic when a lot of units are using same events. However, make sure it is not a problem with your code. I say that because I had 100 of minions walking back and forth, all using same events, and for first few days I was battling with code, as on occasions they'd stop at the node, and not turn back and move. But, after several changes it all started working almost perfectly; almost because timer would not be precise, so some would move after longer time period then they were suppose to ( ease to check, seeing distances between minions becoming tighter ), which is a shame. But it worked in the end. I was only using platform and timer behaviors.

  • Objects are being created on the next tick, if I'm correct. So you got to use On created instead.

  • If it was easier to write events as "custom behaviors" that you can apply/stack on multiple objects (and object types) as has been requested/suggested/begged for over the past few years then I would never need to duplicate event sheets

    It would be good, but it would require to change workflow. And currently, really, you can do it, buy having dedicated event sheets, include them, with some conditions and it's almost the same.

  • Just simplify it:

    On green created : target red

    On red created : target green

    Or you can create txt variable and set them on their creation to either green or red, and then pick by that variable.

  • Generally 9path is putting quite a strain on performance. I suggest you just create several 9path objects, each with different animation frame, and animate them trough events. Best way to do it is to create a family for it, and create family numerical variable, then set object's value of that variable representing a frame that is suppose to be displayed, and then trough simple events, create static local variable with total number of frames and another one that will hold the number of current frame, and then every x ms add 1 to current frame local var, and trough events hide 9path family objects but display the one with variable that local static variable is currently set to. when current frame local var is equal total number of frames, reset current local var to 0.

    Hope that makes sense in writing

  • No "power of 2" "magic" involved here ; it's just pixel rounding, which does exactly what it says.

    As for n^2, it works "better" since content designed to work in n^2 can easily be accessed with data encoded on 8/16/32/64 bits, which are native data types, without waste, memory alignment or performance issues

    Setting values to n2 did improve smoothness for me significantly.