gwerneck's Recent Forum Activity

  • Totally on board, man. I think it was a bad move to introduce Construct 3 with such controversial stuff instead of features, but still it's sad to see everyone reacting so poorly and being so angry instead of giving it a chance.

    That being said, I'm fearful that C3 will be tied to chrome even when offline. Hoping the offline version will be standalone.

  • I don't think it's the save/load state that's causing it... I switched mine so that, instead of saving and loading, it restarts the layout when you start recording and when you start playing, and it's still wildly inconsistent.

    Your example does play back perfectly every time. I was under the impression it was due to less room for error, but then I made the character and moving blocks faster, then artificially lowered framerate, and still got identical results. I am not sure why mine doesn't work, but I'll try and adapt your code into my game and see if it does. Thanks for your help!

  • The "trigger once" condition prevents an event from activating multiple times once its other conditions are met.

    For instance: If you have an event with the conditions "ObjectA is overlapping ObjectB" and "Trigger Once", it would trigger once when starts ObjectA overlapping with ObjectB, and then wait for them to stop overlapping to check again.

    I'm afraid there's no event to have something happen once and then never again in the game, but it should be simple to achieve by various other means.

    In your case, you could simply move the "Add 1 to mainbar_speed" to the events that set the object's level and charge the player money. This way, it'll add to the global variable at the moment you upgrade, and only then.

  • All you need to do is verify whether an object is overlapping another, and if so, set that object to a random position again. It'll change its position until it's no longer overlapping.

  • The thing is, time scale works precisely by changing the value returned by dt, so once I lock the framerate using minimumframerate, dt stays the same and timescale changes have no effect. This is the reason why I'll have to figure out another way to get a constant timestep.

  • Weird, I've never heard of that. I tend to run into trouble with nw-js failing to kill its own process when the game is closed. Perhaps you have too many instances of it running in the background, and that's preventing it from opening. Try and end all instances before running it again.

    If that's not the problem, I'd take a look at https://www.scirra.com/nwjs - perhaps there's a more recent version in which this won't occur.

  • A simple way to make a character "squish" when landing is the following:

    On Landed:

    Player - set height to self.height*0.8

    Player - set width to self.width*1.2

    System - wait 0.1 seconds

    Player - set height to self.height/0.8

    Player - set width to self.width/1.2

    Basically, this will "compress" the sprite, making it look wider and shorter for a moment, then quickly go back to normal.

    I'm not sure what sort of visual effect to expect from a squishy character jumping or walking around, though - if you have something in mind, let me know and I'll see if I can help. Good luck!

  • Yes, it does. Using Minimumframerate is a temporary measure - once I get this to work, I'm planning on using some clever maths to set the timescale dynamically in a way that stabilizes fps without messing with speed much. For now, the game running slower isn't a much of a concern.

    I have made a small project which makes it very very easy to reproduce the issue - all you need to do is follow the instructions on-screen. I'll post a link to it since I can't for the life of me figure out how to attach files:

    http://doorsandlevers.com/SuperTestDemo.capx

  • Wow, that was fast. You guys are awesome, thanks!

    newt

    When I say 'per tick' I mean that every frame I append numbers - which identify current input - to a text file. Later I can read that file and have the game simulate the input that was down in each frame, in order, as if I was playing the game and doing the exact same thing.

    When I say 'Minimumframerate', I'm referring to a system expression which caps deltatime - so I can use it to make my game framerate dependent and do more precise stuff like this.

    I hadn't considered timestamping it, that is an excellent idea, yes. I'll let you know how that turns out. Thanks for the quick response!

    R0J0hound

    I've set it to 99999 because, when set to 60, displaying "dt" every tick shows a value which changes slightly per frame, which I thought could be the cause of the problem. I've tried again with 60 just to be sure, and still get the same results.

    The changes are quite slight, so it can be hard to notice if you only have a sprite moving around on its own. My game has moving platforms and hazards, which can make a tiny difference mean a lot more.

    Would you mind sending your capx so I can compare the way you did it with mine and see if I've done something silly? Thanks for helping out so quickly!

  • TL;DR - Trying to control sprites with the platform behavior using a list of per-tick instructions has different results every time, even with a fixed time step. Why?

    Hello. I've been trying for a while to make some cinematics wherein sprites with the platforming behavior move as if controlled by a player. Instead of recording gameplay and displaying video, I would like to use a text file with instructions for how objects should move. This is the method I came up with:

    • When I press a certain key, the game saves to a special slot and starts writing all keyboard input to a file, on a per-tick basis.
    • When it's time to play the cinematic, the game loads from that slot and proceeds to simulate the per-tick inputs on the file, every tick.

    I understand that, in order for the movement to remain consistent, I need a fixed timestep throughout the cinematics - so I set the minimum deltatime framerate to 99999 when recording and playing input. I expected this to be the only precaution I'd need to take - but it seems like I was wrong.

    Sprites following the exact same instructions behave slightly differently each time, and these inconsistencies add up to make them end up in completely wrong places. I have no idea what could be going on, and I unfortunately cannot provide a capx file since it's a commercial project quite deep into development.

    I have tested and am fairly sure that:

    • The time step is perfecty consistent between frames.
    • The events involving recording and playing input are set up correctly.
    • All elements involved take deltatime into account when moving.

    I know I shouldn't expect perfect precision from a computer when positioning sprites and such, but what I am attempting seems feasible, and a similar logic is used in many games for showing replays, so it shouldn't be impossible.

    Am I missing something obvious? Can anyone who has used a similar method before shed some light? Does anyone know a better way to achieve a similar effect without playing video? Thanks a bunch

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Thanks, fisholith! The mathematics behind your formula are somewhat beyond me, but it works flawlessly.

    Inspired by your well-written, color-coded explanation, I made a simple commented project that uses your method, in case anyone stumbles here in search of the same thing I was looking for. Not very clean and surely not the best way to apply it, as I'm not very familiar with this stuff yet, but it should be enough for anyone who wishes to achieve this effect.

    Thanks again!

  • Hi there! I'm trying to have an action trigger whenever an object rotates 360 degrees in 2 seconds.

    Simple enough, I imagined, just store the current angle for 2 seconds and check whether it has increased or decreased by 360 compared to the oldest stored value every tick. However, the Sprite.Angle function resets the value back to 0 after reaching 360, instead of continuing as the Angle value does in the Debug Mode.

    I failed to find a way to get the object's 'absolute' angle, as in, if they had started at zero and rotated 360 degrees clockwise twice, it would return '720'. Is there one? If not, has anyone succeeded at detecting when an object rotates 360 degrees - regardless of the initial position - in another fashion?

    Thanks in advance!

gwerneck's avatar

gwerneck

Member since 3 Feb, 2015

None one is following gwerneck yet!

Trophy Case

  • 9-Year Club
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

12/44
How to earn trophies