Mipey's Forum Posts

  • Ah yes, forgot to mention that Construct processes events and conditions from top to bottom, if it changes the value in a way that it meets the next condition within the same tick, it will process that as well.

  • If I remember it correctly... if you have paired Sprites B with Sprites A correctly, then this should work:

    +Sprite B clicked
+Pick paired (Sprite B)
+For each paired (Sprite A)
Change value to Sprite A[/code:1bana30c]

But I'm not sure, I haven't worked with object pairer in a while. David should know better, there is a pairer example by him with rocks and veggies.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • You could add debugging code to your project, for example a text object that shows contents of the array. I debug manually, because the debugger is kinda iffy. I rarely use it, mostly to check on the overhead and get more detailed error messages when my project goes belly up.

  • No, I meant this: "Do not pair objects and families. Always pair objects with other objects, families with other families, but never mix objects and families." This will save you from big trouble.

  • Smoothness is dependent on FPS. The higher FPS you have, the smoother mouse cursor is. At lower FPS, mouse moves large distances between frames, so it appears to jump. If you move your mouse quickly across the screen, you'll notice that it gets drawn a few times, skipping across gaps.

  • That's a bit messy way you've got there... I'd suggest to only have one trigger, but two subevents with separate conditions. Also, there is no point giving 99999-55555 as a value, that is a simple arithmetic operation, just give 44444.

    Like this (+ is an event condition, ++ is a subevent condition, > is action):

    +On left clicked on Sprite3
++ 'Amount of water' greater than 44444
   > set 'Amount of water' to 99999
++ 'Amount of water' less or equal than 44444
   > set 'Amount of water' to 55555  [/code:1x8m8mfm]

  • At least now you know the lower limit of your engine! However, I'm sure that it'd run smoothly if several effects were disabled (moblur, etc.). Most production games have graphical options where one can opt to reduce or raise graphics quality. Just toggle those effects on and down.

  • Pairer object is a bit difficult to work with. As a tip from someone who's battled that eccentric object: don't mix families and objects. This alone will save a ton of time spent on the pairer object.

  • Runs slowly on my system, the mouse lags and everything is kinda choppy. 'bout 20 FPS, I'd say.

    Celeron 2.4 GHz

    ATI Radeon 9550 256 MB (PS2.0)

    1.5 GB RAM

    Windows XP

    Crrrrrrrrrrrrrrrrrraaaaaaaaap mobo

  • I have a feeling that the Else statement is screwing you up. Let's see what happens:

    • checks if walking, plays the walking animation
    • then if the above fails, it plays standing animation
    • now check for key pressed, in this case it starts another animation

    After one tick, it checks those events again, but the "key pressed" already triggered in previous trick, so it won't trigger in this one. Meanwhile, the above two events had triggered already, resetting the animation to either one. So, your X animation only plays for one tick.

    I suggest replacing the Else event with this (right click the condition to invert it):

    + is NOT walking

    + X-animation is NOT playing

    play idle animation

    Also, you might want to add the "X-animation is NOT playing" condition in walking animation event, too.

  • In unlimited mode, it runs at just below 600 FPS, which is impressive for my machine. Neat effect!

  • As far as I know, the object always exists even if there are no instances of it. By adding them to the layout - even non-layout objects - you DECLARE them, so the runtime can use it. C++ and other programming languages are full of such declarations, so object type exists within runtime. You can create and destroy them within runtime as you see fit; if you remove them within edit time, they're gone for good.

  • I don't know, it feels like Frankenstein of RPGs. The story is interesting and the concept of companion conversations etc., but otherwise it all feels too familiar. Still, it is quite a nice game!

  • Only when they contract the bird flu.

    Har, har! Geddit! Bird flu! Flying pigs!

    ...

    Screw you. My dog still loves me.

  • Yeah, the flu is mostly dangerous to juniors and seniors. Juniors, because they haven't developed the immunity system fully yet... seniors, because their immunity system is having an Alzheimers or something.

    But if your kids are healthy, you've got nothing to fear. I'd worry about kids whose moms kept them waaaaay too sterile. Don't say no when kids want to play in the dirt - it makes 'em into excellent candidates for Fallout-esque survival!

    As long as they don't dig a landmine up, like it happened to one of kids I read about... eek. Luckily it didn't go off even as the toddler was hitting it with a toy truck. Imagine the father's face.

    Err. Yeah, get well soon!