Twilight Zone

do you want me to do it with the kicker-ramp?
yes I mean the kicker ramp
Here is your ramp model rotated 5 degrees counter clockwise

Now insert it instead of previous Kickerramp and in FP set the rotation to 5

I believe it is the FP kicker rotation setting that determines the direction of the pulse.

so in theory this should now give our kicker model at 5 degree directional pulse up the ramp
 

Attachments

  • rampa-kicker-5.zip
    3 KB · Views: 60
ok....done, it works the same ..... but I was expecting it .... I still do not understand why this test?
Exactly !
It's hard to tell if it changed anything....anyways it was just an idea :trippy:

It was to see if it would change the direction of the pulse by 5 degrees
 
My Billiards table uses this technology to push just the cue ball
ok .... but I was saying on a ramp, on a ramp how would it work?

It was to see if it would change the direction of the pulse by 5 degrees
but 5 degrees, it is very little, hardly noticeable .... I can change degrees, but the result does not change ... because in my opinion, if I put at 45, in milk .... and then I put at 90 in the editor , the result is the same, I kick the ball at 45 ..... in practice you will only see the kicker off axis, but the "SolenoidPulse" that is the direction of the kicked ball, you always adjust it in the editor
 
ok .... but I was saying on a ramp, on a ramp how would it work?
It doesn't look like it works I agree
but 5 degrees, it is very little, hardly noticeable .... I can change degrees, but the result does not change ... because in my opinion, if I put at 45, in milk .... and then I put at 90 in the editor , the result is the same, I kick the ball at 45 .....
45 left (counterclockwise) in MilkShape
45 right (clockwise) in table editor
in practice you will only see the kicker off axis, but the "SolenoidPulse" that is the direction of the kicked ball, you always adjust it in the editor
Yes that is why I was thinking the direction of the kicker pulse will be 5 then or 45 or whatever.

FP should be unaware that we rotated the model in milkshape it will "see" it as new model that just looks that way and then when we rotate it in table editor it should just fire the ball in the direction we set....

At least that was my goofy idea

I also tested it and it doesn't work....so there must be something in the model itself that determines the kicker mechanism.

I was conceiving the kicker-model as a "block" that will have a default kicker direction of 0 degrees when imported into FP regardless
of how the model is constructed or rotated in milkshape
 
Last edited:
45 left (counterclockwise) in MilkShape
45 right (cloc
will always have the same result, ball kicked in the direction set in the editor, and off-axis kicker
FP should be unaware that we rotated the model in milkshape it will "see" it as new model that just looks that way and then when we rotate it in table editor it should just fire the ball in the direction we set....
unfortunately it is not so, in fp, he does not care, of how rotate the kicker, fp will see the kicker as set, in the FPM program ..... but it always has priority of how you set the rotate in editor,the "pulse, of kicker",with the simple fact that you will see an off-axis kicker
I also tested it and it doesn't work....so there must be something in the model itself that determines the kicker mechanism.
the mechanism as you interpret it, is the "Solenoid Pulse" is this is default of fp, which is based on the rotate in editor, and cannot be changed, IMO ...... you can modify the model (the kicker) as it is better believed, but the mechanism cannot be modified ..... maybe Bam .... could it?
 
will always have the same result, ball kicked in the direction set in the editor, and off-axis kicker

unfortunately it is not so, in fp, he does not care, of how rotate the kicker, fp will see the kicker as set, in the FPM program ..... but it always has priority of how you set the rotate in editor,the "pulse, of kicker",with the simple fact that you will see an off-axis kicker

the mechanism as you interpret it, is the "Solenoid Pulse" is this is default of fp, which is based on the rotate in editor, and cannot be changed, IMO ...... you can modify the model (the kicker) as it is better believed, but the mechanism cannot be modified ..... maybe Bam .... could it?
No worries
We dont need to go further with this.

Thats ok. It was just a test to try

Thanks Paolo
 
No worries
no problem.
We dont need to go further with this.
yes ... I believe so too.
Thats ok. It was just a test to try
unfortunately it is not even applicable on the ramp-kicker......the kicker, also in other forms, is a complicated object, which fp uses in a particular way, which in turn is difficult to modify .. yet Rav, did a magic with Nes, managed to turn gravity even on a kicker.
Thanks Paolo
also to you,Bob.
 
@wild
@Gimli
@shiva

I am not sure how to say this so I am just going to say it. I got Shiva's flipper code working so it does not need a ramp assist. When I added Shiva's flippers, the trajectory of the ball was different from what I expected. I wasn't able to hit any targets because the aiming was off. It may be due to Jungle Girl having flippers of a different shape than those on Twilight Zone. I finally made some changes to the code for contact points so the trajectory of the ball is correct after being hit. When I did that, the ramps started working. You have to hit the ball near the center of the flipper in order to hit the ramps on this table. Shiva's flippers have the highest omega near the center of the flippers so there is enough power to hit the ball up and over the ramps.

I am thinking I will make the flippers switchable by the end user so they can either select your ramp assist version with standard dynamic flippers or select Shiva's dynamic flippers.

Shiva added some new flipper angle and swing code to the latest version of Jungle Girl and am trying to figure out how to add it to this table. I got some new ideas about adding additional switchable physics options on the menu for the end user. Shiva figured out a way to make the bounce control switchable. I know that Bob likes lots of bounce. I am also thinking I may provide an option to change the table slope in the menu for the guys that want the ball to play faster than my typical physics.
 
@wild
@Gimli
@shiva

I am not sure how to say this so I am just going to say it. I got Shiva's flipper code working so it does not need a ramp assist. When I added Shiva's flippers, the trajectory of the ball was different from what I expected. I wasn't able to hit any targets because the aiming was off. It may be due to Jungle Girl having flippers of a different shape than those on Twilight Zone. I finally made some changes to the code for contact points so the trajectory of the ball is correct after being hit. When I did that, the ramps started working. You have to hit the ball near the center of the flipper in order to hit the ramps on this table. Shiva's flippers have the highest omega near the center of the flippers so there is enough power to hit the ball up and over the ramps.

I am thinking I will make the flippers switchable by the end user so they can either select your ramp assist version with standard dynamic flippers or select Shiva's dynamic flippers.

Shiva added some new flipper angle and swing code to the latest version of Jungle Girl and am trying to figure out how to add it to this table. I got some new ideas about adding additional switchable physics options on the menu for the end user. Shiva figured out a way to make the bounce control switchable. I know that Bob likes lots of bounce. I am also thinking I may provide an option to change the table slope in the menu for the guys that want the ball to play faster than my typical physics.
If Shivas work George and you are happy go with that.

The ramp assist is only to offer something to try if all else fails.

I found that increasing the flipper strength in table editor also made a big difference even with the dynamic flipper code already added
 
Part of the issue as well is the nature of "FP" generated ramps and their geometry which isn't completely gradual at the peak.

The one thing that you see with well done VPX tables are custom made ramps in Blender, etc. This arose from having fewer tools compared to FP for wire ramps,etc... so if you are good at making ramp models (different than a "FP generated ramp") then you would get smooth ramps without this issue.
 
I found that increasing the flipper strength in table editor also made a big difference even with the dynamic flipper code already added

Wow!!! You are absolutely right! Today, I successfully added Shiva's new flipper angle/swing code and the flippers became weak again. So I was disappointed. Just now, I increased the flipper strength in the table editor without making any other changes and the power returned. Then I went back to the version of the table with the standard dynamic flippers (that you and I developed) and increased the flipper strength in the editor. Once again, the flippers had enough power to send the ball up and over the ramps!

Everyone thinks I am some sort of physics expert but I have never noticed this. I always thought that the omega settings in the script overrode the strength setting in the FP editor. Obviously, that is not true.

Of course, I have never claimed to be a physics expert. If you want to know the truth, I just experimented with the settings because I didn't like the physics on any of the tables I played, Basically, I just spent loads of time fiddling with the parameters in the XML and got a sense of what they do. Then, Malifica created an XML with a heavy ball that I became taken with and he gave me permission to use it. I have been modifying it ever since.
 
Part of the issue as well is the nature of "FP" generated ramps and their geometry which isn't completely gradual at the peak.

The one thing that you see with well done VPX tables are custom made ramps in Blender, etc. This arose from having fewer tools compared to FP for wire ramps,etc... so if you are good at making ramp models (different than a "FP generated ramp") then you would get smooth ramps without this issue.
Aye, FP ramps do end rather abruptly.

Another problem is that ramps start rather abruptly as well. When I have a problem with a ramp, I use a ball roller and navigate the ramps slowly, noticing any bumps the ball makes. I nearly always add an approach ramp that helps smooth out the abrupt start of the ramp.

I also learned to test ramps with a solid color so I can see any imperfections. I remember when I was working on "Independence Day" with Francisco, I found a peg that was sticking up through a ramp that the ball would occasionally hit. You couldn't see it without the solid color on the ramp.

There is frequently a problem with the interface of a solid ramp with a wire ramp. It is times like these that I wish there were finer height adjustments. On this table, the wire ramps start after the peak so all you have to do is set the wire ramp a little lower than the solid ramps and the ball just drops down a little which doesn't hurt anything.
 
I've always made adjustments to both the dynamic flipper code and the flipper strength in the editor. I'm pretty sure I mentioned in my guide you needed to have both set correctly to compliment each other.
 
I don't remember where, in another thread I had mentioned this, in fact I have always adjusted, both the omega, and in the editor, in my tables, and I have never had problems with ramps ... (apart from two) obviously for others tables, (without bam) this problem can be encountered.

in vpx, i don't know if the table can be adjusted, as in fp, i mean both in length and in width, so if you can't then it is normal to do ramps in model, so in a more gentle way, so that the ball goes well.

having said that, the fp ramps work better if they are well adjusted according to the length of the table, if you take a longer ramp then the climb is more less l steep, if you do it the ramp shorter then it is normal that it is steeper ,it must also be said that many ramps are necessarily made in models, if they have diverters, double lanes, etc etc .... but if you have a single ramp, that of fp if done in a way that respects certain criteria, then it works very well .... you don't have to do it in a model ... it's all a matter of practice.

a "ramp assist" does not have to be a method used necessarily, (but sometimes it is useful) but in my opinion increasing the strength of the fins too much just to be able to complete a steep ramp, created for that type of table, would affect everything the game of the table ..... let me explain better

this is also conditioned by the speed that one uses of the ball,xBAM.BallSpeedLimit = 2000......and it is a moderate inclination (table slope) I use between 1500/2000, and 6.5/7.5....... because in my opinion if you have a higher speed of the ball, between 3000/5000,and a high incline(table slope 8/10) and in addition you increase the strength of the fins (in a drastic way) you will see the ball hit by the fins at lightning speed, and while playing, perhaps in a hectic moment, you will not understand where the ball is, and when you should hit it.....with the result that you will have a very confusing game, and you will need "slow motion" on the table, to understand what happens .........sorry it's just an ironic joke.

there are many things to consider, in order to have optimal physics, but it is always conditioned by the type of table you are dealing with, and to use the best construction techniques

it's not enough just to adjust the fins, or adjust the table slope, or put an "assist ramp" ... or something else .... in a table, but you have to understand how the table was built before, since we are talking table of which a "re-mod" is being made,it is not a criticism, but only an opinion.

in conclusion, sometimes a table is built based on the playfield (texture), and not on the measures that a table requires, for a better development of the game, and this affects the ramps .... negatively
 
Last edited:
I don't remember where, in another thread I had mentioned this, in fact I have always adjusted, both the omega, and in the editor, in my tables, and I have never had problems with ramps ... (apart from two) obviously for others tables, (without bam) this problem can be encountered.

in vpx, i don't know if the table can be adjusted, as in fp, i mean both in length and in width, so if you can't then it is normal to do ramps in patterns, so in a more gentle way, so that the ball goes well.

having said that, the fp ramps work better if they are well adjusted according to the length of the table, if you take a longer ramp then the climb is more less l steep, if you do it the ramp shorter then it is normal that it is steeper ,it must also be said that many ramps are necessarily made in models, if they have diverters, double lanes, etc etc .... but if you have a single ramp, that of fp if done in a way that respects certain criteria, then it works very well .... you don't have to do it in a model ... it's all a matter of practice.

a "ramp assist" does not have to be a method used necessarily, (but sometimes it is useful) but in my opinion increasing the strength of the fins too much just to be able to complete a steep ramp, created for that type of table, would affect everything the game of the table ..... let me explain better

this is also conditioned by the speed that one uses of the ball,xBAM.BallSpeedLimit = 2000......and it is a moderate inclination (table slope) I use between 1500/2000, and 6.5/7.5....... because in my opinion if you have a higher speed of the ball, between 3000/5000,and a high incline(table slope 8/10) and in addition you increase the strength of the fins (in a drastic way) you will see the ball hit by the fins at lightning speed, and while playing, perhaps in a hectic moment, you will not understand where the ball is, and when you should hit it.....with the result that you will have a very confusing game, and you will need "slow motion" on the table, to understand what happens .........sorry it's just an ironic joke.

there are many things to consider, in order to have optimal physics, but it is always conditioned by the type of table you are dealing with, and to use the best construction techniques

it's not enough just to adjust the fins, or adjust the table slope, or put an "assist ramp" ... or something else .... in a table, but you have to understand how the table was built before, since we are talking table of which a "re-mod" is being made,it is not a criticism, but only an opinion.

in conclusion, sometimes a table is built based on the playfield (texture), and not on the measures that a table requires, for a better development of the game, and this affects the ramps .... negatively
I agree with everything you said. Unfortunately, the length of ramps on recreations of tables can't really be adjusted all that much. It is true that a longer ramp is not as steep and is easier to navigate.

I personally don't like using xBAM.BallSpeedLimit. It is hard to describe but using it makes the table not "feel" right to me. Excess speed is usually caused by a table object that doesn't have the strength set correctly. Bumpers are often the culprit. Rafal gave me some debug code that identifies the fastest ball speed. I use it with the ball roller by resetting the speed code to 0 and hitting an object. I stop the ball with the roller after hitting the object and the code gives me the max ball speed. I have used BallSpeedLimit but set it to be higher than the max speed I recorded just to catch unforeseen circumstances.

It seems I am the only one that hasn't adjusted flipper strength in the editor on dynamic flippers. Maybe I am getting old. I have noticed I don't think as clearly as I once did and takes me longer to solve problems I find on tables.
 
Don't worry George.... we're all getting old. :)
 
Don't worry George.... we're all getting old. :)
Gimli's beard is definitely getting grey :smile:

The experiment was still fun. Develop a kicker assist ramp triggered dynamically based on BAM ball monitoring
 
What do you guys think about deleting the video that plays when the game is over? I like in-game video but at the end of a game I just want to start another game and not watch a video. ...But then that is just me, plus I have played this game many times and have seen the video many times.
 
It seems I am the only one that hasn't adjusted flipper strength in the editor on dynamic flippers.
honestly, I always thought that "the omega" took precedence over the editor .... in fact it was this topic that I wanted to discuss, in that thread that I don't remember where I put it......

instead then I discovered that it was possible to modify both ...., and with further improvements, but I wonder if this is right? Couldn't editing the editor negatively affect the "dynamic flippers" system?shouldn't omega be in total control? I wonder if Sheva's new system also includes the ability to use adjustment in the editor ...

Maybe I am getting old
Don't worry George.... we're all getting old.
Gimli's beard is definitely getting grey
time passes for everyone, guys, the important thing is not to go crazy:shockedalien:?I already have a white beard, for my age?
 
instead then I discovered that it was possible to modify both ...., and with further improvements, but I wonder if this is right? Couldn't editing the editor negatively affect the "dynamic flippers" system?shouldn't omega be in total control? I wonder if Sheva's new system also includes the ability to use adjustment in the editor ...

time passes for everyone, guys, the important thing is not to go crazy:shockedalien:?I already have a white beard, for my age?
It seems that the omega in the script should be in total control but it is not the case. Maybe I will ask Rafal and see what he thinks.

My beard is white and what little hair I have left on my head is white also.
 
honestly, I always thought that "the omega" took precedence over the editor .... in fact it was this topic that I wanted to discuss, in that thread that I don't remember where I put it......

instead then I discovered that it was possible to modify both ...., and with further improvements, but I wonder if this is right? Couldn't editing the editor negatively affect the "dynamic flippers" system?shouldn't omega be in total control? I wonder if Sheva's new system also includes the ability to use adjustment in the editor ...

Rafal sent me this reply about how the omega in the script works with the flipper strength slider in the editor:

"All works same way as in FP without BAM.
In XML you have set flipper omega = 10
In FP you can change flipper strength, but slider is in percent, so it is like 100% of omega in XML or 50% of omega in XML.
In BAM when you set omega, you change omega from XML, not value set in FP editor in percents."
 
After finally resolving the problems with flipper omega, I have started making progress. I decided to not change the height of the left ramp. I couldn't lower it very much and had to move the orbit lane that goes around the back of the table so the ball doesn't hit the ramp. With the new settings for flipper strength, the left ramp performs nicely.

My attention turned to the right ramp. I have lowered the right ramp on my working copy because it doesn't perform very well otherwise. This involved lowering the miniplayfield and all its objects. If you are concerned about this, you won't notice any changes when you play it other than the ramp performs better.

I am really tired of how long this table takes to load. I am in the process of changing all the textures for the video to use the power of 2 following the tutorial I created. I have been extracting the frames piece meal when I don't feel like exercising my mind too much. This will be a good test to see how much faster the table loads.

I revised my objectives on the first posting. I decided I like Shiva's flippers although they are similar to Gimli's and my version. Gimli's and my version have a linear progression of omega from the base of the flipper to the tip from the max to the min omega. Shiva has a progression where the omega is low at the tip then gets higher in the center of the flipper. Then the omega is low at the base of the flipper. This really does appear to help with hitting center shots which has always been a weakness of FP. The coding is not for the faint of heart as it requires about 1000 lines of code. I am not sold on Shiva's bounce control so I will probably do it the way I have done in the past. Shiva did figure out a way to make the bounce switchable so I will try that.

I have been thinking about the lighting. I am toying with the idea of illuminating the areas that match the game mode. For example, illuminate the miniplayfield when the ball is up there. I think it might be a way to make the table look less busy.

What do you guys think about illuminating the instruction cards like I did on Space Shuttle?
 
Halloween does this when you go on the upper playfield and switches the pf lighting and GI off and only have the upper pf lit up. Controlled lighting is something I personally love instead of just having the entire table always on or off.

Some people love instruction cards. I myself add options for the instructions cards to show the pupdmd on my PinEvent mods and people love that.

If you hate long loading tables... you'll despise RetroFlair 2 by the time I'm done, as it will use a lot of texture animations. 245 MB so far for the table file. :)
 
If you hate long loading tables... you'll despise RetroFlair 2 by the time I'm done, as it will use a lot of texture animations. 245 MB so far for the table file. :)
I will probably like RetroFlair. I just hate long load times when there is a way to improve the wait. As you recall, I like MOTU which is slow to load and I have modified it several times. We will see how Twilight loads when I am done.
 
Forum activity
Help Users
You can interact with the ChatGPT Bot in any Chat Room and there is a dedicated room. The command is /ai followed by a space and then your ? or inquiry.
ie: /ai What is a EM Pinball Machine?
  • No one is chatting at the moment.
      Chat Bot Mibs Chat Bot Mibs: simon.bethke is our newest member. Welcome!
      Back
      Top