tulamide's Forum Posts

  • Don't use greater than/less than tests on angles - it never works properly. They always have problems with the crossover between 0/360 degrees. That's what the angle-specific expressions, like anglediff, are for.

    Ashley, I'm afraid I need an explanation here. I think I'm not understanding this right. How can I validate a range of possible angles if greater/lesser than shouldn't be used? Or do you mean that only my direct approach with abs(angle - 180) is the wrong way?

    abs(Sprite.Angle - 180) greater or equal 175 ->not advised, as it does not use angle expressions?

    anglediff(sprite.angle,0) Less or equal to 5 ->not advised, as it does use a "lesser than" test?

    If so, what is the correct way to see if an angle is in between a range of possible angles?

  • The example won't work, because both conditions need to evaluate to true for the action to be triggered. And the angle can't be at the same time greater than 355 and lower than 5 (e.g. 3 is lower than 5 but also lower than 355)

    Instead do a system compare:

    abs(Sprite.Angle - 180) greater or equal 175

  • Rich, you're still working on it?

    Would like to know, too <img src="{SMILIES_PATH}/icon_smile.gif" alt=":)" title="Smile" />

    Last thing about it was:

    I'll do it this summer. <img src="{SMILIES_PATH}/icon_cool.gif" alt="8)" title="Cool" />

    http://www.scirra.com/phpBB3/viewtopic.php?f=2&t=4023&p=32085

    *knock on wood* *cross fingers* *say a prayer*

    <img src="{SMILIES_PATH}/icon_mrgreen.gif" alt=":mrgreen:" title="Mr. Green" />

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Thank you very much, linkman, for taking the time to check it.

    Of course, this won't help when the framerate drops, but it will at least make the speed consistent for all people as long as the game is reaching V-sync rate.

    That's why I tested the framerate constantly. But after your post I tried things a little different. Let me mention that the warp effects speed is framerate dependent. If I have a v-synced rate of 60Hz and another gamer has 120Hz, he will see the effect moving twice as fast. If I want every gamer to see the effect the way I intended it, I have to change the speed value at least once during gameplay.

    The compromise between having a constant movement of the warp effect throughout every computer, and the little glitches is that the code counts the frames four times a second. An always event tests if the framerate changes by more than 10% and only then sets a new speed value. This way, the speed will be left untouched on a fairly stable system once the value is set, but the code ist still fast enough to react within 250 ms on a drastic change on the framerate. The 10% are acceptable, because one would barely notice an increase or decrease of this amount the way I use the warp effect. (btw: with this procedure the warp effects speed reacts to timescale changes also)

    Thanks again

  • Hmm, noone who can help?

    The warp effect can help with quite nice rain or water effects, but if the speed is so different on a 60Hz-Monitor compared to a 120Hz one, it ist not reliable enough and the impression you intended may even be broken. And compensation of framerate dropping isn't possible, too.

    (Edited first post to set the link. The old one was outdated.)

  • You're both welcome

    And in case of any questions left, don't hesitate to ask or pm. You shouldn't suffer from me being too lazy to document it

  • I had a look at your cap. I'm afraid I can only confirm that the text manipulator is buggy.

    Try changing the order of the sub-events 3 and 4 and you'll get the two lines that were missing before - but the other are then missing. By changing the order of the subevents you can even get the preview to crash.

    Basically I would say, that it has something to do with the mixture of accessing the lines with getstring and getsubstring, espacially using the |For each substring|-condition. Somehow Construct gets confused by this.

    For example, I have set up a new textfile with six lines in the format "Line 1: One" and so on through "Line 6: Six". If I only use |For each substring delimited by ":"| in the |on line read| event, and set the action to append...

    TextManipulator.GetSubstring(":", 1) & ":" & TextManipulator.GetSubstring(":", 2) & NewLine[/code:1rsz3y9h]
or

[code:1rsz3y9h]TextManipulator.Getstring & NewLine[/code:1rsz3y9h]

...I get exactly the lines 1, 3 and 5 of the textfile, missing every second line. But when I copy the event and let Construct do the same thing twice, I get all lines from 1 to 6 and in the right order!

I would say, if this isn't reported as a bug yet, you should do so and then wait with the documentation until it is fixed

  • I don't have a system icon, lol.

    Au contraire It just was described in short. Here is the long part:

    When on the parameter page, you see fields for all the parameters and in the lower part of the window is a list of icons. They represent the expressions related the repective objects. When entering one of the fields, you may either type by hand (and then use, what lucid wrote) or you select the system icon via doubleclick, then in the new window with the system expressions select the system tab and afterwards "Get global variable". Click on Finish, and you will see a "global('Variable name')" inserted into the parameters field. Now just replace 'Variable name' with 'FASTMODE'.

    In this case, it doesn't make much sense, because it's faster to type it, but you do not always know exactly the syntax of an expression, and there it comes in handy.

  • Can anyone solve this ? I'm pretty sure there is a way. Maybe with a loop or something.

    I have a solution. But I'm afraid it's very complicated compared to just activate grid movement behavior. On the other hand, my solution doesn't make use of that behavior at all, so you're much more flexible in changing every little bit of it. But be warned, I make use of functions, alias calling, loops and such. I'm nearly sure, there might be an easier way. But hey, it works

    http://www.mediafire.com/file/znonwyxim3y/Grid%20Movement%20Alternative.cap

    Hope it helps! (I know it's not well documented)

  • I don't mind you editing my file at all, though I was under the impression that the expressions I used already applied timedelta. Your lerp solution is probably better anyway since you'll get closer to the mouse position.

    Yes, that's strange. I thought the same, but when I tested your solution with framerate mode unlimited the movement was much quicker than in v-synced mode. But somewhere I read about built-in features being timebased instead of framebased, but maybe that only applies to behaviors?

  • Tulamide I think your link is not working though, would be interested to see what you came up with.

    I'm sorry. I don't know what happened to the file upload. I try another hoster now and share a slightly different version (deceleration added). Hope the link works this time *cross fingers*

    http://www.mediafire.com/file/ojmtyiiwgtd/MovingConstantly.cap

  • I think you pointed to the right direction, uberlou. Even if not, at least I learned something again

    And if you don't mind, I added TimeDelta to the move at angle action, as well as adding the set angle towards position action, also with TimeDelta, to make it really behave constant

    http://www.filedropper.com/movingconstantly

    4ror, I hope you finally found what you were looking for?

  • I'm really new to all this, so I did not actually work with everything, but isn't SpriteFont an alternative? As a workaround of course, because you have to use bitmapped fonts.

    If this thought is totally nonsense, just forget about it.

  • Why not just use math instead of mouse behavior?

    Have a look at

    http://www.scirra.com/phpBB3/viewtopic.php?f=16&t=1865

    and

    http://www.scirra.com/phpBB3/viewtopic.php?f=3&t=2055&p=15393

    Or do I misunderstand what you are trying to achieve?

  • Hi all,

    I'm afraid I need another helping hand. The project I'm working on will be independent of the framerate, so I heavily make use of TimeDelta.

    The warp effect doesn't seem to be safe in this matter. Using a value for the speed leads to nice results as long as the framerate doesn't change drastically. So I tried to use a formula with TimeDelta to compensate and put it in an Always-event. But then the warp effect changes its behavior randomly and drastically in very short periods of time.

    The .fx file uses framecounter and multiplies it with the speed, so basically changing speed in relation to timedelta should lead to the result I need, meaning that the warp moves with exactly the same speed no matter how high or low the framerate actually is. At least I think it should

    I have set up a cap to show what I mean. Play around with v-synced or unlimited on. There is also a checkbox to switch between the default values and the TimeDelta formula. I only set the speed values as long as the checkbox is checked. When you uncheck, the last set value will be used - and the strange behavior disappears. But then of course it's frame dependent again instead of time dependent.

    Warp.cap

    Does anyone have a solution?

    p.s. I couldn't figure out how to switch between v-synced and unlimited mode via events/actions. I try to implement an options menu to let the player decide. I might have missed something, so if anyone can point me in the right direction...