Bogus Error Messages Related to NewtonPhysicsTick

[GeorgeH]

I thought I would post my findings when I encountered when I got an error for the line containing "FlipperStroke()" in the FizX code listed below. I find this often occurs when the script has FizX coding. When it happens, the error codes are meaningless. When I encountered it on a table I was working on, I got an error on "BallsRemaining" and the line number referenced was the one for "FlipperStroke()". I tried remarking out all the lines in the script that contained "BallsRemaining". Of course the game wouldn't play correctly but it did start posting real messages that I could use. It still listed line number for the line containing "FlipperStroke()" but the message was correct. When I got no more error messages, I unremarked the "BallsRemaining" code. I did get a different error at that point that I was able to interpret and correct. Then the table played without errors!

If this happens in the future, I may remark out FlipperStroke() in the line of code below which I think might help. I just thought of it now. If you do this, FizX won't play correctly but it may help with error messages, as long as, you unremark it when done.

Let me know if this helps anyone else. The only alternative is to go through all the code looking for errors which takes a long time.

Sub NewtonPhysicsTick()
FlipperStroke()
End Sub

 

[TerryRed]

This will happen with any table (that has an error in the table script) that uses any code in Sub NewtonPhysicsTick or Sub DrawFrameTick. (it's not a FizX issue)

FP didn't originally allow the use of code within Sub NewtonPhysicsTick or Sub DrawFrameTick, until BAM came along. So when your table has a legit error code (FP commands or BAM commands), then FP won't understand how to report it correctly, so it stops at the first thing it won't understand, which is usually Sub NewtonPhysicsTick or Sub DrawFrameTick.

In the case of a table using FizX code, it will stop at Sub NewtonPhysicsTick.

I had similar issues when I made mistakes in my table code on tables like Sonic Pinball Mania, or Star Wars DSA GE, etc before adding FizX code, as I used many things in Sub NewtonPhysicsTick or Sub DrawFrameTick.

Not much we can do to avoid it. As you showed, the only thing you can do is to comment out anything you added to Sub NewtonPhysicsTick or Sub DrawFrameTick, and then try to find the actual mistake made in the rest of the table's code.

Needless to say, this has me in the (good) habit of saving to different table files everytime I make major changes / additions to a table. If I get an error, I can go back and compare the older table file and newer table file to see what the differences are. (use something like WinMerge)

 

[GeorgeH]

I am aware of what happens. I have had it happen many times. My experience is that when I remarked out all the "BallsRemaining" code which was generating the invalid error messages, I started getting valid messages even though it was still referencing the line number of "FlipperStroke()". It helped me resolve the errors. When I removed the remarks for the "BallsRemaining" code, I no longer got the error message.

I have made periodic backup copies of tables for many years, long before the many times you have told me to do this. I also have the automatic backup option turned on in FP. Unfortunately when working with large chunks of code, you have to add all the code at one time or it doesn't work because all the different subroutines interact with each other. In other words, there are times when this problem is impossible to avoid unless you write perfect code all the time.

 

[GeorgeH]

I have had another success with resolving a bogus error message. If you want to know what I have been doing, I am creating a demo table with a generic version of the tweakers from Avatar. It involves copying several subroutines all at the same time from Avatar to the demo table. That is why I have been encountering these errors so frequently. After copying the Game tweaker to demo table, I once again got a bogus error message for "BallsRemaining", so I once again remarked out all the lines of code that referenced it. There are a couple of if/then statements that reference BallsRemaining so you have to remark out the entire statement.

I remarked out all the lines that referenced "BallsRemaining". Last time I decided I would try remarking out "FlipperStroke()" in the sub below. I found it didn't do anything so I remarked out all 3 lines of the sub. This made it so the line numbers referenced in future messages were correct! The last time I did tried this, I had to use the text portion of the message because the line numbers kept referencing the line containing "FlipperStroke()" in the sub below. Now I can use the line numbers!

Sub NewtonPhysicsTick()
FlipperStroke()
End Sub

If you try this, I suggest that you save a copy of the table before you start. It will help you if have trouble restoring everything you remarked out. You can use it as a reference in case you forget what you did. Once you resolve all the errors and restore all the remark outs back, the bogus message goes away.

Next time, I will remark out the sub "NewtonPhysicsTick()" before remarking out the "BallsRemaining" code (or whatever code that is generating the error message). Then I will see if I can get away with just remarking out the line of code that is referenced. Once you get past the bogus error message, FP starts generating correct error messages. I suppose it could generate another bogus message but it hasn't happened yet. I have gotten bogus error messages in the past before I started using FizX and I think this method might help.

I haven't tested it but I think this same approach will probably work with tables that have the sub "DrawFrameTick" also. Please post your own experiences using this method. I think this method will also work with error messages other than "BallsRemaining". You will just have to remark out whatever term is listed in the error message.

 

[Anthias]

I've downloaded several tables recently which threw weird errors. I just deleted them, I don't have time to bug fix a broken table. If I see those tables updated, I'll try again.

 

[GeorgeH]

I've downloaded several tables recently which threw weird errors. I just deleted them, I don't have time to bug fix a broken table. If I see those tables updated, I'll try again.

The errors I am talking about occur after you add code to a table and test it. There is something legitimately wrong in the code you added but but FP doesn't generate the correct error message for it. So you either have to go back to a previous version and start over or go through the code line by line to find the error. The errors don't just spontaneously appear on a newly downloaded table. Most of the time the error message references a line number for "FlipperStroke()" in the code below (used in FizX) or in the "Sub DrawFrameTick":

Sub NewtonPhysicsTick()
FlipperStroke()
End Sub

You must be lucky to have never encountered it. The cause is what TerryRed says in his message above.

 

[Anthias]

Yes lucky indeed. I think I did once, a few years ago. I certainly can't claim to be the best coder, but now I know where I've been using up all my luck! I'd have preferred lots of errors and a Powerball win, to be honest.

 

[Paolo]

Every now and then it happens to me too, if you have some typing errors or missing (then, if,=,"...etc etc) in the Fp script, and you have code that uses Bam, like fizx or other, Fp gives you an error on a line that doesn't make sense.It happened to me that he gave it to me on the smoke ball roller code.
Recently, integrating Fizx for the first time, I hadn't renamed one of the two lower flipper, and I was getting an error in FlipperStroke(), then I solved it, but not before going crazy.....

As regards Sub NewtonPhysicsTick(),also here recently in "Goldrake" I had received a strange error that I don't remember, as soon as I inserted the "spotlight" I went crazy here too, after a long time I understood that the "spotlight" code that operates under Sub NewtonPhysicsTick(), it conflicted with the one used by fizx, then I realized that I had to move my "spotlight" code to Sub NewtonPhysicsTick() of fizx..... in short, normal things

You simply need to be careful about what you insert into a version of your work that has no errors, always have a backup version in case of some irreversible error, and may the strength of Fp be with all of you..... also if Fp, it does not recognize errors involving Bam

 

[GeorgeH]

Every now and then it happens to me too, if you have some typing errors or missing (then, if,=,"...etc etc) in the Fp script, and you have code that uses Bam, like fizx or other, Fp gives you an error on a line that doesn't make sense.It happened to me that he gave it to me on the smoke ball roller code.
Recently, integrating Fizx for the first time, I hadn't renamed one of the two lower flipper, and I was getting an error in FlipperStroke(), then I solved it, but not before going crazy.....

As regards Sub NewtonPhysicsTick(),also here recently in "Goldrake" I had received a strange error that I don't remember, as soon as I inserted the "spotlight" I went crazy here too, after a long time I understood that the "spotlight" code that operates under Sub NewtonPhysicsTick(), it conflicted with the one used by fizx, then I realized that I had to move my "spotlight" code to Sub NewtonPhysicsTick() of fizx..... in short, normal things

You simply need to be careful about what you insert into a version of your work that has no errors, always have a backup version in case of some irreversible error, and may the strength of Fp be with all of you..... also if Fp, it does not recognize errors involving Bam

If you get an error you can't resolve, you should try this. It helped me.

 

[GeorgeH]

Next time, I will remark out the sub "NewtonPhysicsTick()" before remarking out the "BallsRemaining" code (or whatever code that is generating the error message). Then I will see if I can get away with just remarking out the line of code that is referenced. Once you get past the bogus error message, FP starts generating correct error messages. I suppose it could generate another bogus message but it hasn't happened yet. I have gotten bogus error messages in the past before I started using FizX and I think this method might help.

I tried remarking out the sub "NewtonPhysicsTick()" before remarking out the code that is generating the bogus text message. It starts posting the correct lines numbers right away even though the text message will still be bogus. On my table, it took remarking out lines of code twice before I got to real error messages. You just have to keep remarking out the lines numbers of code that the error messages reference until you get to the real text messages.

To my thinking, this method works better than the alternatives at least when you have to add a lot of code to a table. One alternative is to manually go through the code to find the error which might work if you haven't added much code. The only other alternative is to add everything a second time to a backup copy of the table and hope you don't make any errors. I think my method is easier than doing that. You just have to make sure that you restore the remarks to the way they were before your started; hence, the reason you should save a copy of the table before you start so you can use it to look to see what the original code was. I had one case where there was only one actual error so I just closed the table without saving changes and remembered the change I needed to make and added it back later.

 

[GeorgeH]

I used a lot of words previously but the process is simple, now that I have it figured out:

1) Save a backup copy of your table that gets a bogus error message. Play the table and note the text message and line number.
2) Close the table and open the script. The line number in the bogus error message will normally point to a line in either "Sub NewtonPhysicsTick()" or "Sub DrawFrameTick" of the script. Just remark out the entire subroutine.
3) Play the table again and note the line number referenced in the message. It will display the same text in the error message but the line number will be correct.
4) Close the table and open the script. Verify that the line number has the code referenced in the text of the error message. Remark out the line for the code.
5) Repeat steps 3 and 4 until you start getting valid error messages.
6) Resolve the valid errors.
7) Restore the code that was remarked out to its original state. Use the backup copy as a reference to make sure you change it back correctly.

 

[SpacePirateScott]

Here is something to try. Create a fast repeating timer. If you are getting the bad error messages, move the contents of Sub NewtonPhysicsTick and Sub DrawFrameTick to the timer sub. Your timing will be screwed up but everything should still work, and the error messages should be correct.|

Just speculating here. I haven't tried this since I'm at work and shouldn't be reading forums much less writing scripts for pinball tables. :) Has anyone tried this?

I will give this a try tonight and post the results here.

 

[GeorgeH]

Here is something to try. Create a fast repeating timer. If you are getting the bad error messages, move the contents of Sub NewtonPhysicsTick and Sub DrawFrameTick to the timer sub. Your timing will be screwed up but everything should still work, and the error messages should be correct.|

Just speculating here. I haven't tried this since I'm at work and shouldn't be reading forums much less writing scripts for pinball tables. :) Has anyone tried this?

I will give this a try tonight and post the results here.

The 2 subs have links to BAM. I don't know much about either sub but I think moving the contents to a timer may make it so the code so it won't work as intended. Be aware that the first few error messages may be valid and then the bogus message starts.

 

[SpacePirateScott]

Ok, I tested this out and it works, at least well enough to get the line number reporting correctly

I "mistyped" the name of an object in my Update() subroutine. This is normally called from the NewtonPhysicsTick(). As expected the error message referred to the first line in the NewtonPhysicsTick function.

I added a normal playfield timer set to 10ms.
I moved the contents of The NewtonPhysicsTick() to my timer's update sub and it started correctly pointing out the linenumber where the error was. I did have to completly comment out the NewtonPhysicsTick() function even though it was empty for this to work. So like this:

'Completely comment out the entire function including the Sub NewtonPhysicsTick() and End Sub lines
'Sub NewtonPhysicsTick()
' lightHelper.Update
' gridLightsHelper.Update
' arrowsLightsHelper.Update
' FlipperStroke() 'FizX
'End Sub

Ran this instead.

Sub DebugTimer_Expired()
lightHelper.Update
gridLightsHelper.Update
arrowsLightsHelper.Update
FlipperStroke() 'FizX
End Sub

After I 'fixed' the problem, I ran the game for a while and I still worked well enough for testing. So you if have an error that needs to be triggered by playing through for a while, this might help.

I hope this helps. Please post here if this works for you or not.

Also, after you fix your bug, you should restore the code to the NewtonPhysicsTick() function.

 

[GeorgeH]

Ok, I tested this out and it works, at least well enough to get the line number reporting correctly

I "mistyped" the name of an object in my Update() subroutine. This is normally called from the NewtonPhysicsTick(). As expected the error message referred to the first line in the NewtonPhysicsTick function.

I added a normal playfield timer set to 10ms.
I moved the contents of The NewtonPhysicsTick() to my timer's update sub and it started correctly pointing out the linenumber where the error was. I did have to completly comment out the NewtonPhysicsTick() function even though it was empty for this to work. So like this:

'Completely comment out the entire function including the Sub NewtonPhysicsTick() and End Sub lines
'Sub NewtonPhysicsTick()
' lightHelper.Update
' gridLightsHelper.Update
' arrowsLightsHelper.Update
' FlipperStroke() 'FizX
'End Sub

Ran this instead.

Sub DebugTimer_Expired()
lightHelper.Update
gridLightsHelper.Update
arrowsLightsHelper.Update
FlipperStroke() 'FizX
End Sub

After I 'fixed' the problem, I ran the game for a while and I still worked well enough for testing. So you if have an error that needs to be triggered by playing through for a while, this might help.

I hope this helps. Please post here if this works for you or not.

Also, after you fix your bug, you should restore the code to the NewtonPhysicsTick() function.

Cool. I will try it the next time I have a problem. Thanks.

Normally, the only thing in that sub is FlipperStroke() by itself.

 

[Anthias]

Cool. I will try it the next time I have a problem. Thanks.

Normally, the only thing in that sub is FlipperStroke() by itself.

Off topic but flipper stroke sounds like something from a nsfw dolphin web site

Either that or what caused the untimely demise of a certain TV dolphin.

 

[SpacePirateScott]

Well the dolphins that played Flipper would be over 60 yrs old now, which is really old for a dolphin, which is really stupid thing to be looking up late on a Friday night. :)

 

[GeorgeH]

Ok, I tested this out and it works, at least well enough to get the line number reporting correctly

I "mistyped" the name of an object in my Update() subroutine. This is normally called from the NewtonPhysicsTick(). As expected the error message referred to the first line in the NewtonPhysicsTick function.

I added a normal playfield timer set to 10ms.
I moved the contents of The NewtonPhysicsTick() to my timer's update sub and it started correctly pointing out the linenumber where the error was. I did have to completly comment out the NewtonPhysicsTick() function even though it was empty for this to work. So like this:

'Completely comment out the entire function including the Sub NewtonPhysicsTick() and End Sub lines
'Sub NewtonPhysicsTick()
' lightHelper.Update
' gridLightsHelper.Update
' arrowsLightsHelper.Update
' FlipperStroke() 'FizX
'End Sub

Ran this instead.

Sub DebugTimer_Expired()
lightHelper.Update
gridLightsHelper.Update
arrowsLightsHelper.Update
FlipperStroke() 'FizX
End Sub

After I 'fixed' the problem, I ran the game for a while and I still worked well enough for testing. So you if have an error that needs to be triggered by playing through for a while, this might help.

I hope this helps. Please post here if this works for you or not.

Also, after you fix your bug, you should restore the code to the NewtonPhysicsTick() function.

I tried your trick with the timer on the demo table I am developing. I got a bogus error that referenced the line number in the sub for the Newton Physics Tick. Unfortunately, the timer trick didn't work. I tried several configurations of the timer and even added a light to turn on in the timer code. The light turned on but the text of the error message was still wrong.

Maybe someone else can try it.

 

[SpacePirateScott]

Did you completely comment out the Newton Physics Tick function, not just contents? If so, then I have no idea. I know that it at least works some of the time. Better than nothing?

 

[GeorgeH]

Did you completely comment out the Newton Physics Tick function, not just contents? If so, then I have no idea. I know that it at least works some of the time. Better than nothing?

I remarked out the entire Newton Physics Tick subroutine. If I get another error, I will try it again. I only have one the one line in the Newton Physics Tick subroutine for FlipperStroke().

 

[SpacePirateScott]

Ok, did some more testing.. it seems to be working for me
I added a reference to fake object on line 3571

with the normal NewtonPhysicsTick()

I ran the table and pressed the plunger key which generated this error with the incorrect line number


I commented out the NewtonPhysicsTick() completely and moved it's contents to the DebugTimer_Expired() function



I ran the program and the error message now had the correct line number


Maybe this hack only works for specific errors, or maybe something else is going on. If this doesn't work, you can send me your table and I can take a peek at this.

BTW, here are my timer object settings

 

[madmrmax]

Ok, did some more testing.. it seems to be working for me
I added a reference to fake object on line 3571
View attachment 42145
with the normal NewtonPhysicsTick()
View attachment 42146
I ran the table and pressed the plunger key which generated this error with the incorrect line number
View attachment 42147

I commented out the NewtonPhysicsTick() completely and moved it's contents to the DebugTimer_Expired() function

View attachment 42148

I ran the program and the error message now had the correct line number
View attachment 42149

Maybe this hack only works for specific errors, or maybe something else is going on. If this doesn't work, you can send me your table and I can take a peek at this.

BTW, here are my timer object settings
View attachment 42150

Maybe we need to bake this into FizX table, something like a "#ifndef DEBUG" or something that is like "in debug mode use timer, else use Newton tick"