Arima's Forum Posts

  • Try something like: always set angle to anglediff*0.9

    The bigger the angle difference, the faster it will turn (there are various ways to cap the speed), and it won't overshoot when it gets to the right angle.

    Also, what I typed won't work exactly because it doesn't have timedelta. It should look like: always set angle to anglediff*(somenumber*timedelta) but I can't remember what somenumber's supposed to be for that. Try experimenting with what number should be there.

  • A global variable is helpful to use because it will be unaffected by the picking process. It doesn't need to be a global variable - you could have a 'valuesprite' if the values are needed for only that layout. As it is, you're picking an object, then creating another instance of that object which forgets the previously selected instances of the created object, which makes it confusing. By setting the place to create from somewhere else, it makes it all work smoother.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • There are two ways. I think the right command is lerp, but the easier way in construct would be this:

    • Move at angle: angle(square.x, square.y, targetx, targety), pixels: speed*timedelta

    Hmm, using lerp for that does seem to be a bit trickier than I thought.

  • What I think is happening is you're selecting a cloud via the conditions, but when you create a cloud in the actions, it forgets the selected cloud from the conditions, and the new cloud that was created becomes the only selected cloud, meaning that the new cloud spawns from it's own pivot point.

    Also, since the objects with the bullet behavior are set to destroy themselves automatically when leaving a layout (in the properties), you don't need the sprite to clean them up when they go offscreen. A much easier computationally method, if the bullet behavior wasn't cleaning up after itself already, would be to check their x position. Much faster than checking for collisions.

    I modified your .cap. I set a global variable for each cloud picked in the conditions so the x/y you wanted to spawn from wouldn't be forgotten when you created a new cloud and used those instead. Take a look at it and tell me if there's anything you don't understand.

  • For thread:

  • I believe the issue is construct changed how it picks objects after creating them. So if you had:

    Create sprite

    Create sprite

    • Set angle of sprite

    in 98.9 it would change the angle of both. In newer versions, the same event would result in the second sprite being rotated. This is because on creating an instance of an object, construct picks the object that has been created and forgets all other instances of the object. The new version of the event:

    Create sprite

    • Set angle of sprite

    Create sprite

    • Set angle of sprite

    I haven't checked the .cap tho, so it might be something else.

  • I have a situation where I want the player to go back and forth between layouts very often. With the way construct is, I have two options - either load all the textures at start (not an option for this game, too many textures) or dump everything out of VRAM when switching layouts. This means I have to reload everything every time, resulting in a rather noticeable pause.

    Is there any chance of a third method that loads all the textures as they're needed when going to a new layout, but doesn't dump the old ones?

    Also, a 'unload all textures except those in use' command would be nice.

  • I prefer else forgetting the selected objects - if it didn't work that way, there's some stuff that I don't know how it would be possible to do. Else events run if the event preceding it does not run - so if you want it to run only once, a trigger once condition after the else should work. (I haven't checked the .cap)

    Example:

    value = 1

    • action 1

    else

    • action 2

    So if value does not equal 1, else will repeatedly fire until it does. IIRC, else events don't work properly if there's a subevent between them, like this:

    value = 1

    • action 1

    subevent conditions

    subevent actions

    else

    • action 2

    I don't know if that's been fixed or not, but it sounds like it hasn't.

  • Why do everyone cares so much about "the best way"?! There is not a best way to do a thing!

    Perhaps, but some ways are clearly better than others. And isn't your entire rant about doing something a better way?

    I wonder why everyone is so against this kind of feature. Polygons with textures and collision checking. Is that so difficult? So difficult for you that MADE the entire CONSTRUCT?

    The devs don't even have much time to work on bugfixes, which are of much, much higher priority. Maybe they could consider it for C2, but there's more important stuff to be done on C1.

    This is not even the first time a user asks for this kind of feature. And noone helps those users. We are not all expert coders!!

    They can't implement everything people want immediately. Construct is a free piece of software written in the dev's spare time. I think we all can agree that there are more important things to work on first, like bugfixes, and perhaps even online capabilities (not sure what the status is on that. Seems to be a lot of different info), etc.

    I'm not against the feature - I just think that most of what could be achieved with it can already be done, and other stuff is more important.

  • Phah! You both with your wimpy amount of variables. I've got 45 pvs on one object and about 85 globals.

    Of course, I am making an RPG, so uh... there's a lot of stuff to track.

    I'm also curious as to how many events people have in one layout. My battle engine has about 2000.

  • Thanks. It's been entered in the IGF and IGC. I'm still trying to decide when to start showing it.

  • Ah, thanks for the responses - it turned out the idea I had for it wouldn't work, though. Thanks anyway!

  • I thought of that after posting. It could still potentially work if you used a function to call another event (call event loopindex), but IIRC there's some overhead calling a function, which might make it less efficient.

  • You could also run a loop.

    For 1-30

    if state=loopindex

    • do events
    • end loop

    That way it will stop when the event runs.

  • I want to read a file and get it in raw 1s and 0s. Is there any way to do that?