Ashley's Forum Posts

  • It was kind of an experimental feature, I'm not sure it works 100% with all the different ways events pick objects. Try it; if it works it works, if it doesn't it doesn't. I doubt it'll be fixed before Construct 2, it's deep in the engine stuff.

  • Crash=bug, so make sure that's reported.

    As for the spawning problem, this is an extremely interesting .cap. I have investigated it and at first there seems to be a problem with the timer behavior. If you replace the timer behavior with a simple "Every 500 ms" condition, the interesting stuff starts happening.

    It looks like the initial object moving to the right incorrectly keeps resetting its fade behavior, while the objects it's spawning also don't get a fade in. But it is actually working correctly!

    Let's go back to what Spawn Object does in terms of picking. Say you have an object called A, and in an event which picks A1, it spawns A2. Should you get A1 and A2 picked, or just A2? The code is supposed to pick A2 only since it's the only new created object (the system create object action works this way). This way you can control A1 by actions before the spawn action, and control A2 with actions after the spawn action.

    In this particular case though, you end up with just A1 picked - spawning an object does not pick it and the actions affect the original object! This means the 'Set angle to .angle+90' and 'set type to 2' apply to the object moving horizontally. So it ends up redirecting itself downwards, and spawning another object to continue its current path. It's kind of backwards and crazy, but it's actually necessary. If you spawn an object of the same type as the object spawning, the new object cannot be picked because of limitations in the engine. The reason is very complicated, but the code behind running a general action is:

    For each currently picked instance 'Obj':

    -> Run action for instance 'Obj'

    So for example 'Set X to 0' runs the 'set X' action for every picked instance. However, in the 'spawn object' action, it would modify the list of currently picked instances, which it is currently processing in a for-each. This can cause a crash, so the fix was to prevent spawning an object of the same type from picking the spawned object. This results in the counterintuitive behavior in your example .cap.

    The fix? I don't know what the best thing to do is; this picking behavior probably can't be changed in the 0.x engine because it's so integral to the running of actions. I think the best thing to do is to always spawn a different object type (even if it looks the same). So you could have RedBulletA spawning RedBulletB which in turn spawns RedBulletA again. You can then use families to save repeating events. Hopefully that will do you for now.

  • You do not have permission to view this post

  • posting other peoples photos is wrong

    After you posted a picture of me omfg! You're so banned!

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Sounds like a bug.

  • You do not have permission to view this post

  • Can we skip the "omg-it's-a-girl-on-the-internet" fuss this time around? I hope Mary Jane is OK with you posting a picture of her. Did you ask first? (I don't think I'd be happy if David went posting images of me on the web, for example )

  • Can you make a .cap? Can you explain what you expect it to do so we don't misinterpret your intention from the picture of your events? Can you explain what it actually does?

    Have you tried making a basic application that just sets a string to len("Hello") or len(SomeTextBox.Text)? Are you sure len is the problem there?

  • It seems the platform behavior doesn't work like this but rather moves the sprite in a triangular shape (with a smooth top).

    Are you using jump sustain? Does it still do that with no jump sustain?

    [quote:2ip2r4yn]I also noticed something a bit unnerving which might be a bug. i tried several times jumping in the exact same position and each time reached different heights, though with very small variations. is there a simple way to fix this like setting the Y velocity to 0 when landing?

    The platform behavior is framerate independent (lookup TimeDelta on the wiki), which is important to make your game run at the same speed no matter what someone's refresh rate is. This means there are small random variations in the movement, but it shouldn't be significant. How big is your sprite? It should only be noticable with small sprites.

    If it's really that important to you (although I feel a game should not be designed so specifically as to have a tiny variation crucial to the gameplay) then you can go framerate-dependent and have a fixed timedelta. That comes with all the pitfalls of framerate-dependent games though, basically for it to be fair you're going to have to turn off V-sync and have a tearing display.

  • There is actually some maths going on inside the distance() and angle() expressions, but they hide that, they're just the intuitive distance-between and angle-to calculators. So really you're using some math, but its given a nice name so it doesnt scare anyone

    For the record, distance(x1, y1, x2, y2) is sqrt((x2-x1)^2+(y2-y1)^2) and angle(x1, y1, x2, y2) is atan2(y2-y1, x2-x1) (atan2 does inside itself some more stuff than just atan too).

  • Put the hotspot to the middle left of the arm object (hit 4 on the num pad with the hot spot tool).

    Have an image point on the player where you want the arm attached (let's call it "ArmPoint").

    Always position the arm object at ArmPoint, and set its width to distance(player.x, player.y, hand.x, hand.y), and set its angle to angle(player.x, player.y, hand.x, hand.y). That should be roughly what you want, might need some tweaking of hotspots and imagepoints.

  • There's expressions in platform to get the player's vector of motion right? .VectorX and .VectorY, or .dx and .dy, or something like that. In that case angle(0, 0, dx, dy) gives you the angle of motion.

  • I did, like, write the runtime

  • I think most people who are using 3D in Construct are using some combination of 3D boxes and 3D mesh distortion. There are a few open bugs on the tracker about both though, which might be preventing more people using them. Daiz raised a good point that generally 3D stuff is harder, more mathematical, and more difficult to reason with in your head, which is why 2D is quicker and easier to use.

  • Moved to Feature Requests.