GeometriX's Forum Posts

  • CrudeMik, wow, thanks for pointing that out. I hadn't noticed that roll-off factor before.

    I'd suggest setting the individual volumes for audio that you want to travel further, and setting the roll-off to be low enough to compensate. It'd need some playing with but I think it'd work quite well.

    KaMiZoTo, I've updated my demo to show you the roll-off in action.

  • Do you mean that I can delete all my mouse events and just replace them with touch events and it will work perfectly?

    Yup. You won't have access to mouse wheel or right-click, but if you don't need them, then it'll work perfectly.

    How about if I need to test the project on the laptop? I will need the mouse events, right..?

    Nope.

  • That "every 2.5 seconds" at event 15 is weird, and seems to be causing the issue. Disable that and replace it with system->trigger once while true. Also set event 14 to trigger once.

  • You should update then :)

  • Mouse events are not automatically converted, unless the tablet has mouse emulation enabled (but don't bank on that).

    Otherwise, if you don't need right-clicks, you can set your touch object to simulate mouse clicks. It's on by default, I believe, but can be set in the properties pane under "Use mouse input".

  • Thought it'd be a fun challenge to play around with this, so have a look at what I've come up with:

    Example capx. Drag and drop the green circle.

    It's in two parts: setting up positional audio to get the left/right channel stuff working, and I used the distance between the sprite and the audio generators to determine their volume.

    I tested this at quite low volume. Obviously it'll need tweaking according to your setup, so please start with the volume down low.

    I do agree though, an attenuation percentage setting would be brilliant.

  • You mean other than using the drag-and-drop behaviour?

    You'd have to manually create the behaviour then, but instead of updating the object's position to mouse.x,mouse.y every tick (or as the mouse button is held down, specifically), use lerp to get a smooth movement: lerp(self.x,mouse.x,0.5);lerp(self.y,mouse.y,0.5).

    The object will appear to lag behind the mouse, but adjusting the lerp interpolation to whatever is suitable will help minimise that while still smoothing out the movement.

    Example capx.

  • Image points do mirror properly, but the pin behaviour doesn't update upon mirroring. So when you mirror the character, you need to update the hair's position and pin (and probably mirror it, too).

  • Dash jump works perfectly for me. Your code is right, checking to see if "jumping" is playing and if it is, setting platform speed to 600.

    I'd just suggest that you check to see if the player is in air before allowing the dash, otherwise he can "jump dash" (not the same as dash jumping) while in the air, which just looks weird.

  • Limiting ammunition is done with variables. For example, you could create a local variable attached to the player called Ammo. Every time the player presses the button to fire their gun, first you check if Ammo > 0, then if it is, create an instance of the bullet along with the firing animations (or whatever else is needed) and subtract 1 from Ammo.

    If your code is right with your health bar, then it's probably something silly like a layer or object set to invisible. If you can't come right on your own then you should post a link to your capx so we can take a look for you.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Select the project name in the project pane on the bottom right of the screen, then click on "First layout" on the properties pane on the top left of the screen to change the default layout.

  • No sweat. I've done this a few times myself so I knew the first obvious place to look :P

  • Yup, you'll have to edit the images to smaller size.

    Read about image optimisation here.

    You can see that file size is determined by a variety of factors. In your case, decreasing the dimensions of the images will greatly help in reducing file size. You seem to be using massive images but actually resizing them down greatly in-game. This still uses the original image, however (and additionally has to calculate resizing it, which also looks pretty ugly in C2), so you're effectively wasting space.

    Example, your iodine bottle:

    Original, actual image [703x1770px; 47KB]:

    <img src="https://dl.dropbox.com/u/14522925/C2%20examples/bottle-actual-size.png" border="0">

    How the image appears in-game [61x153px; still 47KB]:

    <img src="https://dl.dropbox.com/u/14522925/C2%20examples/bottle-in-game.png" border="0">

    Resized image to fit in-game [61x153px; 5KB]:

    <img src="https://dl.dropbox.com/u/14522925/C2%20examples/bottle-resized.png" border="0">

  • In the properties pane on the left side of the screen, under behaviours, check that destroy isn't set to after fade out (it should be set to no, in this case).

  • Don't forget that objects off-screen or invisible can still be interacted with. You should use another condition like "is visible" or "is on screen" to check if the dialogue box should be interactive or not.