Stern WIP FizX BAM FP Avatar (Stern, 2010) WIP

[freebird1963]

Just d/l and played. Nice table. Plays and runs smooth. Nice work.

 

[GeorgeH]

Just d/l and played. Nice table. Plays and runs smooth. Nice work.

Thanks Freebird! I am actually changing the physics but not too drastically.

 

[GeorgeH]

I decided to try the same XML that the other guys are using with FizX. To be honest, it wasn't bad. Yea it has a ball mass of 8000 where mine is set to 80. I thought I used a heavy ball at 80 but this new one carries the weight to an extreme. It does seem too heavy when I play it but not extremely heavy. Mine plays faster that I think my customers might prefer. The new high poly ball seems heavier than the default but I think I can reduce the ball parameters to compensate. Ultimately, I am not sure what my customers would want. I could provide 2 versions and the end user can select one. Since the table will require an external ZIP file for the hi poly ball and the color DMD, I could add the XML file there and let the end user select one of the two versions of the file that has each version of XML.

I do have a question for the FizX guys. Is it OK to shroud the drop targets with a surface and have that surface drive the hits like was done on "Jupiter Ascending Final". Or should I replace the targets totally like was done on "Cosmic Princess v1.2"? I would prefer the former because it retains the appearance of the original drop target.

 

[AnonTet]

I did not touch the targets after table creation many moons ago because wip. I'll leave this one to @JLou5641
I'm also not familiar with Jupiter ascending table creation to comment on that properly.

 

[TerryRed]

When using the xml from FizX examples, its important to change the slope to between 5 to 6 (if it wasn't already). Until I did that, the ball was too heavy (tables were originally set to around 7). Now I'm using 5.5 for slope and adjusted the kickers / autoplunger, etc as needed (in the editor / xml). I set the flippers / slings / bumpers the same in the editor as Cosmic Princess, and then adjusted the bumpers as needed in the xml (and also use the new bumper model and peg skirt model, and remove any em kickers, etc used for the bumper.)

Once you get one table all worked out correctly for how FizX is intended to work (DFv2 Flippers and DPv1 and changes to the table and xml to match), its easier to apply to another similar table.

 

[TerryRed]

As for drop targets.... I use invisible guide walls (set to plastic and you need to use invisible textures on the top and sides) that cover the existing drop target, and change the table code so that the wall being hit is what controls the movement of the drop targets. The drop target is just there to look like a drop target (and doesn't get hit). Make sure to use the names DT1, DT2, DT3, etc. This also allows you to fine tune the wall angles if needed as some times one target can be a pain. I did this for one drop target on Sonic and it plays much better, whereas if I matched it up perfect with the position of the drop target, the ball would drain everytime. Since the wall is invisible, you can do whatever you want to make it "play" better without needing to change the drop target.

I agree its better to leave the real drop target in place and use an invisible wall, as using a wall (for the "visible" drop target) means it can't be visible inside / below ornament holes for the targets.

 

[JLou5641]

@TerryRed , for the wall of drop target, instead of using the transparent texture, just untick the "rendering" box of the wall

 

[TerryRed]

@TerryRed , for the wall of drop target, instead of using the transparent texture, just untick the "rendering" box of the wall

That works initially... but when you change dropped = true / false.... then FP forcefully renders it again, depending on the code you use. I find it easier to use an invisible texture to force it to always be invisible no matter what without needing to use .render = true / false, etc.

 

[GeorgeH]

Thanks guys!

 

[GeorgeH]

I have made adjustments to my XML to work with the high polygon ball.

The original table was coded to switch between the users choice of a silver ball or a blue one. The original coder went to a lot of trouble to code it. I think I will change the blue ball code to a custom ball that matches the table, possibly the blue plasma. I don't think custom balls were available when it was coded.

 

[TerryRed]

One thing that is handy.... don't set your drop target walls to use an invisible texture right away. Make sure everything is working correctly first. By seeing the wall drop and pop up during gameplay it helps a lot for trouble shooting.

 

[GeorgeH]

I have been switching back and forth between FizX and doing other things. I created a blue plasma custom ball and added it to the textures and script. Unfortunately, I can't change the two captive balls to use it. The table is set up so the end user can switch between the default silver ball and the custom ball. The problem is that the captive balls are created when the table loads before the end user would be able to change them. The only approach that I thought of to make it work is to drain the two captive balls and load new ones. I am pretty sure that quickly changing the setting on the end user's keyboard would mess this up because it would take some time for the balls to drain. So I don't think this can be fixed.

I decided to try an fps (frames per second) of 592 in the XML. I think I would potentially like it better but many of the settings for the flippers would have to change, possibly even some parameters in the XML. So for the time being, I think I will stick to 296. Some end users will get stuttering if they use 592 so I think some sort of profile change like TerryRed is suggesting is needed to be able to switch between the two.

 

[GeorgeH]

I have tried various FizX flipper settings and don't know how to adjust these:

EOSTorque
EOSAngle - If you set it extremely high, it looks like it completely takes over the flipper omega and barely hits the ball. Other than that I don't know how to adjust it.

I am starting to figure these out: BouncingFallOffThreshold, FlipperBouncingFallOff, FlipperBouncingCoeff. They remind me of the 3 parameters for the ball in the XML. They are all interactive and you have to adjust them all in increments simultaneously. In other words, adjust one a little, play the table and then try adjusting the others in small increments (starting out with larger increments and going to narrower). Of course, FlipperBouncingCoeff is about the same as Ravarcade's Bounce Control code only there is one parameter instead of 4. It is nice to not have to figure out a curve that everyone uses. But that is where the similarity ends. I determined that the fastest the ball hit the flippers on Avatar is when the plunger is pulled back all the way and the ball circles around the outer loop to hit the left flipper. I compared that bounce to what happens in normal play. It might help if I could remember what the max ball speed is on must tables (seems like maybe 3000 depending one the physics). I might be able to figure out some debug code that tells me what the ball speed is which might help.

I don't like as much bounce as many people seem to so this was a struggle. ...But I think I hit on what works best for me (or at least pretty close):

BouncingFallOffThreshold = 1500
This is defined as the speed where the falloff is fully applied but that didn't seem to help much to make adjustments -- a higher number seems to mean less bounce at high speed. The range is pretty broad. I presume the max is your maximum ball speed, maybe 3000?

FlipperBouncingCoeff = 0.45
This is basically a global adjustment of bounce at any speed. The higher the number, the higher the bounce - very similar to Ravarcade's bounce control code.

FlipperBouncingFallOff = 0.6
This is defined as how much reduction in bounce is applied after you reach the Threshold. A higher number seems to mean less bounce at high speed. The range is 0.0 to 1.0.

I will try these later:

FlipperStaticFriction
FlipperKineticFriction

 

[JLou5641]

@GeorgeH,

FlipperBouncingCoeff is the bouncing coeff like you set before in XML.. it the same things.. But now you have a falloff and threshold that simulate the deflect of the rubber depend the ball speed.
Ex:
Bouncing = 0.8
FallOff = 0.5
Threshold = 1000

That mean the bouncing coeff is reduced to 50% when ball reach 1000mm/s and over... so here, it will give 0.4
And it also mean that the bouncing coeff start at 0.8 when ball is at 0mm/s and then gradualy reduce to 0.4 when ball is more and more near the threshold... so here, 1000mm/s.

So by a simple calculation, you can determine that at 500mm/s you will have a bouncing at 0.6, at 250mm/s you will have a bouncing at 0.7..

I made an Excel file if you want to find your value depend the ball speed.

This can give you a very bouncy ball at very low speed, but a low bouncy ball at hight speed.. Very usefull to have ball dribling between two post, but not a super sonic ball after a kick on a post.

10.3 KB file on MEGA

mega.nz

 

[JLou5641]

using ballspeed in debug mode is very usefull to set your best value for threshold and falloff

 

[GeorgeH]

using ballspeed in debug mode is very usefull to set your best value for threshold and falloff

Thanks! How do I adjust EOSTorque and EOSAngle? I don't have clue what they are or how to adjust them.

 

[AnonTet]

From the manual I've posted:
Percentage from max omega for EOS Angle
EOSTorque = 0.25 ' Defaut : 0.25 (25% of defined Omega)
' End Of Stroke angle ( Angle range where the Omega is reduced )
EOSAngle = 5 ' Default: 5

 

[GeorgeH]

From the manual I've posted:
Percentage from max omega for EOS Angle
EOSTorque = 0.25 ' Defaut : 0.25 (25% of defined Omega)
' End Of Stroke angle ( Angle range where the Omega is reduced )
EOSAngle = 5 ' Default: 5

Why do all the profiles on the Sonic table by @TerryRed have the EOSTorque set to 0.35. Also 2 of the 4 profiles have the EOSAngle set to 2 that say the profile has stronger flippers?

 

[AnonTet]

Those settings in the manual are from a VERY early testing phase. The current defaults are actually 0.35 wiht 5º Angle. But one of the testers from Sonic actually had EOSAngle=1 for example... these are just preferences, that's all. The stronger you have the torque the stronger the "light flicker" when the flipper is fully up will be and more precise you'll have to be too if use less angle in which it is in effect.

So early tables didn't even have EOS. current tables where everything is electronic it is my understanding it doesn't interfere with game play and then there's everything in between. But I just read :)

Rule of thumb the angle at which EOS works should be (very?) narrow and the amount of force, in reality, is just enough to keep the flipper up, so, low. If I remember correctly the current defaults were also based on default nfozzy settings (but I never actually looked at nfozzy code)

 

[AnonTet]

Sorry for double post but I'll take the opportunity to remind everyone of a very important thing: your input method changes for better or worse, how you perceive things, just like Hz in monitors (the most common topic) affect how you play.

For the longest time it was problem and even ignored but nowadays it is a thing too. I posted about it here.

TLDR:
Follow the link in my .sig and if you have a cheap keyboard (or worse, RF wireless) vs an old ps/2 keyboard or a nice pinball HW circuit board you should be able to feel the difference. It really is a make or break thing

 

[GeorgeH]

I added the FizX drop targets and added the script for them. I named the walls around them DT1 through DT4 as instructed. I presume they must be named that way due to the coding in the FizX script.

After adding the rubber script, I encountered a meditation error when I added the existing rubber behind the drop targets to the script. The rubber was named RubberNavi so I added it like the following:

RubberNaviType = 5 ' Description : Rubber Long Band

I resolved it by changing the name of the rubber of the table object and occurrences in the script as Rubber23 and the error went away:

Rubber23Type = 5 ' Description : Rubber Long Band

I don't know why that fixed it.

I guess I will proceed with adding the rest of the FizX rubbers tomorrow.

 

[AnonTet]

I added the FizX drop targets and added the script for them. I named the walls around them DT1 through DT4 as instructed. I presume they must be named that way due to the coding in the FizX script.

You are correct.

After adding the rubber script, I encountered a meditation error when I added the existing rubber behind the drop targets to the script. The rubber was named RubberNavi so I added it like the following:

RubberNaviType = 5 ' Description : Rubber Long Band

I resolved it by changing the name of the rubber of the table object and occurrences in the script as Rubber23 and the error went away:

Rubber23Type = 5 ' Description : Rubber Long Band

I don't know why that fixed it.

It fixed it because of the same reason above. Unfortunately there is no way to find rubber type objects on a table and avoid the renames. so you have to rename those.

But there's another issue. post rubbers. These are not named so you have to import the models and substitute the rubbers. Then you can assign the types for those too and all will react with the new FizX. Otherwise, you're only using FizX to the shapeable rubbers and posts should have the same "treatment" :)

Note on the tiny post rubber. JLou hadn't done that yet at the time he sent you the pack. So I scaled down one existing model which might not be perfect but it works. Export it from Cosmic Princess.
Then you can rename and select a type to those too.

I guess I will proceed with adding the rest of the FizX rubbers tomorrow.

Nice

 

[JLou5641]

Note on the tiny post rubber. JLou hadn't done that yet at the time he sent you the pack. So I scaled down one existing model which might not be perfect but it works. Export it from Cosmic Princess.
Then you can rename and select a type to those too.

What you talked about here is the model to make a hit sub for sound.. The tiny model for FizX is made

 

[JLou5641]

@GeorgeH , check the readmefirst file on each folder of resource i sent you.. It's explained. ( fastly i admit lol )

 

[GeorgeH]

Are fleep sounds part of FizX? It looks like there is a huge amount of coding for it on Cosmic Princess but Terry's Sonic doesn't appear to use it.