POSSIBLE BUG: Physics engine appears to NOT allow 0 velocity - creates "quiver"

synthesis

Here is a link to a bug recreation demo.
http://gamesalad.com/game/play/42356

The issue is...
I have built a set of rules in the shooter ball. Upon launch...velocity is added. However...when the ball has stopped...the velocity will not allow a force to 0...consistently.

At times...the forced velocity works...other times...it takes a long while...and other times...it will not force to zero. Therefore...the X and Y velocities seem to continue to "dance" around fractional values...which appears to happen so fast...the rules can't keep up with the changing values...and therefore...the physics engine (I assume) continues to process the velocity.

For turn based games that require pauses between user moves (such as puzzles...ie a billiards game) and that pause requires the physics engine to "quiet"...this is a BUG...and is quite noticeable in game play.

Please review the sample above. If there is an error in my logic...I would love to know where...as the rule structure is quite simple and straightforward. Otherwise...if this is a "KNOWN ISSUE"...I would like to know that too...and when might it be resolved.

To use the demo, adjust slider for strength and tap the ball to shoot.

The RED T/F text is the switch tracking the rule check for < 5 total XY linear velocity (times 100) to reset the "ball is shot" T/F value. When the T/F switch is thrown back to False (tracking the fact the shot is complete)...it is not until after the X and Y velocity has been forced to 0.

So the fact that the T/F boolean is executed and the velocity remains to quiver (usually quivers that is...) suggests a bug to me. I've tried forcing it with both linear.X and Y overrides and a change velocity...but nothing is consistent...and without both overrides in place (Ch. Vel. + Ch. Attr.)...the reliability of the override effect reduces a lot.

Thanks,
Synthesis

synthesis

Here I am using 0 gravity. It is a horizontal plane (similar to billiards). If you view the demo, you will see sometimes the 0 override works but usually not. View the readouts to track what is happening to the velocity values during a launch.

My question is...
How do you FORCE a 0 velocity to X and Y after the physics/rendering engine has grabbed the actor? Is there a way to force the physics engine to RELEASE the actor (ie control the actor's Physics boolean value while in game)? Seems like if there was...it would go along way towards optimization improvement.

My understanding was that this boolean (along with the graphics boolean value) cannot be changed once the scene is executed.

adado

Yeah, I originally thought I had this issue licked for you Syn as it was working for me several times in a row...thusly I posted that 'corrected' demo project for you a while back. However, ran it the next day, and it was inconsistent again...go figure.

I suspect with TSB's falling due to gravity and then landing on things, there is more there to say "hey, I've landed on something and cannot move...zero."

firemaplegames

One solution, and it is not ideal of course, is to destroy/spawn a new copy of the Actor when its velocity gets <= 0.

I am running into similar issues with the Platformer demos I am trying to make.
Sometimes, but not always, the Player's velocity never stops. My readouts toggle between 0/-20 incessantly and never come to a rest. Very irritating indeed. And because of that, the Player won't be able to jump, or will get stuck, etc. This happens maybe 4 out of 100 times, drives me crazy.

The physics system in GS is based on Box2D. Box2D has been ported to many languages. I use it for Flash. There are a million Flash physics games that use it.

Box2D has a lot of features that have not been implemented yet in GS. Here is a link to the box2D website: http://www.box2d.org/index.html

I do not know if GS uses this or not, but one of them is the concept of a "sleep" state, which greatly reduces CPU cycles.

Check out this flash game using Box2D: http://www.kongregate.com/games/Uchiha/erase-box

The thing to notice in that game is that when an object turns red, it has entered the sleep state, and will not be acted upon by by processor. It can wake up instantly, but what is great is that is a state that you can check for.

synthesis

@FMG
Oh brother...I figured that this was a REAL bug...not me just missing something.
Snafu'd again.

This is the 3rd physics game I've attempted now with GS...only to be sidelined because of BUGS! I'm getting very frustrated coming up with ideas...only to find out 2 weeks into each one...I have a roadblock that won't move...and I don't have any way to move it (and maintain optimization).

I'm officially 0 for 3. I guess I will be forced to release a "pick-a-number" between 1 and 10 app. That sounds fun...eh?

I guess I will move on to prepare for Flash CS5 and wait for v 1.0 gs...hopefully before my membership expires.

Man this is frustrating. UGH!!!!!!!!!!!

Well AT LEAST WE HAVE IPAD SUPPORT NOW. screw the real issues...we'll leave those for later.

synthesis

BTW:
I knew about the spawn replacement workaround...
Problem with that is...if you have 20 balls on the table...its a bit like using a sledgehammer to drive a tack into place.

Spawning and tracking all those variables...just to workaround something like this is just plain horse patookey (IMO).

firemaplegames

Don't worry, Flash has its own issues. I've been battling that software for 10 years now!

Actually, that is probably what saves me when using GS. I'm so used to hacks and workarounds from Flash just to get something working, that I just expect it. I am used to using sledgehammers everywhere.

With web design, the client ALWAYS seems to be using IE6, so even more sledgehammers are needed...

Clean, well organized code? Please. That only works in Fantasyland. I always start out with good intentions, then it just turns into a monster when you try to make something work in something like IE6, Flash MX, Windows ME Home Edition, or some other nightmare.

This seems to happens every few years. The old technology (thankfully) gets replaced with newer, better, faster technology - but now it has new issues to contend with.

If we waited until everything worked properly, nothing would ever get made.

Plus, there's only a small window of time when the software will actually work! The first software I worked on was called After Dark, the screensaver software. Remember the Flying Toasters? We had to make sure that ran on all the operating systems of the time. Windows 3.1, Mac OS 7, Windows 95 had just come out. You had to be a good programmer - but you also had to be really good with a sledgehammer! You definitely needed both skills.

And you still do.

And now, after all that, After Dark doesn't work on ANY system anymore. That window of time has passed. Kids today don't even know what it is.

You cannot sit around and wait for the Commodore 64 to fix all their bugs before you release your software. You would still be waiting! What's a Commodore 64?

Anyway, I hope you are able to release your games. Don't get too frustrated. And bring out your bats and sledgehammers, nothing is ever perfect.

synthesis

Okay then FMG...
I stuck with the project...and am looking to spawn to workaround.
Now the issue is,
Upon respawning itself (which works)...I cannot get a value to accept its default.
In the actor...I have a rule

When game.shotExecuted = true
then changeVelocity and self.ballShot = true
otherwise
self.ballShot = false

The rule seems to execute correctly one time...and from there on...its always TRUE instead of its default of FALSE! Can't seem to find the root of this issue...as the default boolean value is being ignored (or not reported correctly).

The game attribute is being driven by the user via the SHOOT button. Then the self attribute is used to "switch" the game ball interior rules. The functionality seems to function correctly...but why is the value not reporting correctly? My concern is if the reporting is wrong...then there is something going on in the functionality that may also be wrong...even though it may not be directly impacting the sequence.

Any thoughts? Anyone?

Download Link:
http://gamesalad.com/game/play/49309

The boolean having the issue is being reported to the red text (on the ball). note how after the first shot...it works...but from then on...It doesn't. I've been scratching my head on this one.
Is this ANOTHER bug? Or am I a complete idiot?

(BTW...I had a Commodore VIC20...but that was after a TRS-80 and before a Tandy

scitunes

This might be totally different, but your problem seems similar to the problem I ran into when trying to have a timer speed up or slow down as time went on. The idea was that within one actor the real attribute that I was using in the timer started as one value but then needed to change. Eventually someone figured it out for me. In the shared projects look for a variable timer demo. I think you could use this with rules other than timers to possibly get the outcome you are looking for. I could be totally misunderstanding the issue you are having, but maybe it will get you on the right path.

Good luck!

(I hope you stick around as your ideas have been helpful)

synthesis

@scitunes
I am not using ANY timers.
My actor has 2 rules...that's it.

its an if/otherwise....
if game is true...
then self is true...
otherwise self is false.

My problem is...
it operates perfectly in the first loop sequence. After that...the boolean is broken (even though it functions on screen correctly...its just the fact that the reported value to the text field is incorrect). Its like if you spawn yourself more than once...you break any and all default values preset in the actor.

BTW:
The second rule on the actor is the respawn rule check (if self is true and self X+Y velocity is very small....then...gameBoolean = false, respawn a clone of myself at my X and Y position and destroy myself...which should cause a default reset of my self boolean).

firemaplegames

hmmmm. If you set the power meter to 20, it works pretty consistently.

I remember a problem that I was having that a text field wasn't updating unless I constrained it. I forget what that issue was though...

EIDT: Nevermind, now it doesn't work..

I'll try and take a look at this later.

synthesis

Thanks FMG...
But remember...in the 2nd demo...
The functionality works perfectly. It is the boolean value that is not reporting correctly.
Either there is a bug in my logic...or a bug in a boolean report to a text display behavior.

firemaplegames

When I initially set the meter to 20, it consistently reset the boolean (in the text display). Now it isn't working.

I'll try to take a look later on...

synthesis

OK...
I was just clarifying that you knew that there are 2 separate demos linked above.
The boolean value being reported in the 2 demos is different. In the first demo...the game boolean is being reported on the red ball text.
In the 2nd demo sample, the self boolean is being reported to the ball text.

The first demo reports correctly...the 2nd demo (the one with spawning integrated) doesn't.
Thanks for looking into this for me.

I think it might be a bug in GS. I'm just looking for independent confirmation on that...or someone to point out my ignorance if it isn't a bug.

synthesis

It appears that the 2nd bug in this (after working with the actor a while) does not impact the actors performance. It appears the boolean is firing off correctly. The bug appears to be isolated to the value not reporting correctly to a display text field. If the boolean attributes are game attributes...they appear to report correctly. But self boolean's do not. The rule structure is fairly simple inside the actor in the 2nd sample above...so I don't think its a rule order sequence issue...especially since the rule includes an otherwise attribute assignment.

firemaplegames

Yeah, I took a brief look at it the other day. In the one Rule set, you have a Change Attribute, a Spawn Actor, and a Destroy Actor behavior "loose" inside that Rule.

I did a quick test and wrapped the Destroy in a 0.1 second Timer. That made the boolean display correctly twice, instead of just once...but it was broken again after that.

I'll try to dig into it later.

I did have that problem in one of my projects where the Display text wasn't updating properly. I'll try to remember how I sledgehammered it!

synthesis

You would think the otherwise behavior in the first rule (separate from the spawn/destroy rule) would force to false. I can't see anything in the entire script window that would cause an override. And since the actor performs correctly...seems like the boolean is firing correctly...just not displaying correctly.

The sledgehammer would be a game boolean attribute substitution for the self. So if you want to report the value...gotta use game booleans until the self boolean bug is fixed.

The boolean issue is a minor issue (IMO)...but the 1st issue...the quivering velocity is not.

CatOnAKeyboard

This is a common and known bug.

It is a problem that I had in early development of the game I was making. Whenever a display text is used to display a actor instance variable, the value displayed will not be consistent with the actual value in the field. Proof of this was that I had a math formula that incremented a global variable a certain amount based on the value in the actor instance (a score counter incrementer, basically). Although the total score would always be updated to the correct amount, the display on the actor of how much the player just earned was inconsistent.

ORBZ

synth. i ran into this same "jiggling" bug in the physics engine back in 0.7.x My work around was thus:

create a variable called Speed on your actor type INTEGER.

Constrain the Speed to the magnitude(linear velocity x, linear velocity y)
(note: I can't remember if magnitude can return a neg value, if it can wrap mag inside an abs function, if not, omit the abs. I think it can't return a neg number so this example is good. i'm sleepy)

now speed will be an integer approximation of the speed this hacks off rounding bits.

create a rule when speed< 10
call behavior change velocity, set value to 0

synthesis

@Orbz
That workaround seems to be defunct.
I checked your expression of:
constrain speed = magnitude(velX,velY).....when < 10.....then speed = 0
which seems to report 1.66-1.67 as a speed check value once the ball has "virtually" stopped.

The expression I was using prior to check for a virtual stop was:
constrain speed = abs(velX-velY).....when < 5.....then speed = 0
this usually settles to a reported value of about .45 and saves a little on the processor by avoiding the magnitude function call...since its a simple arithmetic sign.

Still quivering on the linear velocity value reporting.

The bug appears to lie in the actual forcing value of 0...not in the expression or attribute allocations. I am trying to both change velocity speed to 0/direction 0 and force X and Y linear velocities to 0...but the reporting linear values still quiver...even though the rule has proven to have been executed.

The sample project is linked at the top of the thread if you want to look at the rule set.
I would love to find an elegant cure/workaround to this if possible...to save the constant spawning/destroying...but not at the cost of 2 or 3 constrains. As if you have 20+ balls on the table...it will be A LOT of constrains to manage and process.