288 replies to this topic

[DDH69]

you grabbed the latest ini?

 

In short - no.  Now fixed - thanks.

 

My schedule for running ledcontrol_pull had broken .... now fixed 

[Dozer316]

By the way - what I always wanted to ask: On the original table GI and some inserts pulse. Just watch the PAPA video over at youtube. Can this be simulated?

 

The flashers can be done with a timer sub which fades the lights if the solenoid is on for a certain amount of time.  I would guess that there is a part of the WPC 95 system which is not emulated in the current versions we have. (Some kind of PWM for the lamp matrix).   I did this on some personal SAM tables as they also use this feature extensively.  At some stage I might get around to putting it in this game but I've got a few other things to work on first.

[ClarkKent]

Dozer:
Because of some strange behavior of the ball I revised the table and removed all walls under rubbers as because of the new VPX rubber elements the collideable walls are not needed anymore (except slings). The walls were from height 0 to 50 which caused some friction problems. I made all rubbers collideable as intended and moved them to the right height. Note: the height of the rubbers should be the middle of the ball, so if the ball is 52 the rubbers should be 26 (one unit more or less is not that problematic) - otherwise it could be possible that the ball sticks to the rubber. I also corrected some rubber shapes as they were not exact enough, corrected some rubbers on posts (the ones on the outlanes with two rubbers on them and some others) and some other small things. At the posts on the skill shot there is one bigger rubber ring between the lower two posts not two separate ones (as far as I walked through some teardown galleries). And corrected some heights of the metal posts to have a better visual effect with the rubbers on them.

 
I made some rubber primitives with invisible walls built-in, inspired by this table. I made them from scratch so they may or may not swap out easily with the existing ones.
 
https://www.dropbox....itives.vpx?dl=0

I do not fully understand how this would help if there is a rubber element already available which looks good and is working perfectly if activated. Can you explain?

Edited by ClarkKent, 03 April 2016 - 07:37 AM.

[boiydiego]

for some reason after running this version all my dmds are gone in vpx and vp9 on all other tables , installed last 2.7non pindmd vpinmame (i have lcd dmd ) from other site are there more people with this problem ?

it tryed to put my registry settings back put also that doesnt bring the dmds back ..

 

somebody knows problem ?

[nFozzy]

Oh, I didn't realize this table uses the built-in rubber objects now. Before it had custom primitives for rubber bands.

 

The advantage is the rubber bands will look correct on the pegs since they'll be sitting at the right height.

[ClarkKent]

Oh, I didn't realize this table uses the built-in rubber objects now. Before it had custom primitives for rubber bands.

 

The advantage is the rubber bands will look correct on the pegs since they'll be sitting at the right height.

The height of the rubbers in VPX can be changed, too. It is highly appreciated that you did that work! I personally always prefer the rubbers VPX provides...

[bassgeige]

you can run another backglass but you won't have animation or lightning, pinmame doesn't communicate with vpinmame events that are used for other backglasses

 

I was able to try it before a few minutes myself and my first assumption to try to just disable the integrated DMD did not help to fix it. Unfortunately it seems your answer does not lead to an easy solution. Do you think there is a future possibility to unite both communication types. My problem is clear I can not foreseen how much from the vpinmame events are ready to use for the dB2S and I am also not sure how exact those events represent the original ROM state. I always tried to use vpinmame as to my understanding it should include the most game ROM information.

 

Congratulations! @Dozer and everyone involved for a new higher CV standard with the integrated DMD!!

[arngrim]

that was my first question when we talked about this dmd flasher object, if pinmame can act like vpinmame or something, nobody replied so it seems not easy or even feasible i don't know

[bassgeige]

I did a quick test to see if there are any events at all present from the old ROM method. My live visible tool designed for the Spectrum solution indicates to my big surprise lamp return signals from the ROM. This means that there could be hope but I can not answer this question myself.

 

http://www.vpforums....&showfile=10969

[arngrim]

we might just need an adaptation to b2s.server, which is a dead end since herweh left the boat with the source code of b2s, 2 years since we requested it and he didn't share it

[Dozer316]

You can mirror anything the original rom did including lights / solenoids / flashers so all that is required for any original backglass is to change the settings for the backglass to b2s communiction and assign the flashers / GI / cannon animation to a scripted b2s call.  

 

That's all I did for the packaged backglass - rather than assign S(olenoid)27 to a light or snippet on the backglass you just assign a discrete b2s ID (i.e 27) and then send the data from the sub routine in the the script which controls that flasher (Controller.B2SSetData 27,1) to turn it on or (Controller.B2SSetData 27,0) to turn it off.   You can even trigger animations by string name (check the help for the designer).

 

You're basically just building an EM backglass for a rom controlled title.  Everything the rom does can be mirrored but you have to code the directb2s command manually rather than the backglass picking it up with native solenoid / lamp and flasher assignments.)

 

You just need to open my backglass in the designer and see which id's I've assigned to certain entities.  If you want other rom commands assigned to them the original table script will need to be altered to send them.

 

I don't know what the enhanced backglasses contained in relation to my original versions, I've never been able to open them.

 

I don't know of any other way around using manual b2s calls to the backglass (and by extension DOF) with the current tech we have unless directb2s (or an equivalent) and DOF were natively included in the vpinmame code.

 

Dozer.

[bassgeige]

Thank you for the deeper insight. There are pros and cons. The pro is a new method which allows to include the new DMD and also the ROM signal and this together with all the benefit from triggering string names. This was for this table the perfect and only solution! :-)

 

The cons are that a first quick test to simple change the communication method in the dB2S was rejected. I will test it later on again. It would mean that a dB2S needs to be setup piece by piece again. The benefit to use triggering string names allowed you to use better timing settings. The con is that it will work but the understanding of each string is first needed to use it in the right way. It is very good that events from the ROM can be routed over the system to work with the corresponding result which the native ROM version offers. The con is that you need to include every new wish that is not already included in a separate table release. It can slowdown the whole process or can lead to a standstill. I do not know new unknown limits yet in the system like I saw it for example in the extended CV dB2S versions more times. There is also a risk that it could be to much for the new method in a kind of way too.

 

The extended versions you mean are usable and I can give you every detail about it. My problem is before this step can happen to first modify the normal day version and its logic. This can lead to a different graphic for the wheel. The versions I did are all different designed in that point. Something similar I did for Twister and that was also a lot of work. The amount of work can be exremely huge and can also mean a complete redesign of the 2.0 versions as they are already very close to the edge of the current dB2S designer created. I do not know if a better PC which I maybe will buy this year can solve problems which I have with the dB2S designer.

 

I am still thinking about what to do better but it all means all in all as it seems now, no easy solution for me.

[Dozer316]

Dude, here is your Day mod version converted to work with this table -

 

https://www.dropbox....re_DMD.rar?dl=0

 

I was able to open it on my cabinet machine in the designer and the conversion took about 5 minutes.   Have a look at the id's I have assigned to the 4 flasher snippets and the cannon and wheel animations.  Also note that the main project settings have been set to b2scommunication mode. That's all there is to it.  Depending on what you've used in the other versions you can use the same process to convert the rest.

 

If you have used non standard assignments (things that the original backbox did not have) then yes, the table script would need to be updated with new calls but if all they have is the 4 flashers, the cannon and the wheel animations then the table will not need to be updated.

 

The back  glass looks very nice running however I would recommend reducing the resolution of the main image.  It's way too large and no one is going to be running a 4k back box monitor.  By doing so you'll also negate the need to patch the exe to support more memory and reduce support requests for users whose machines bomb when they try to run it.

 

Hope this helps.

[bassgeige]

Thank you very much Dozer! Back on the main PC the first rejected communication change worked without a single problem now. Then I was a bit stuck with the correct corresponding allocation and saw you submitted your settings for the correct ROM values here. This settings I included now and loaded the version up.

 

Your help did save me the testing and it ensures everything runs. I will submit you the other values from the 2.0 versions. I know how much work it can be to include them in a new setup like you did it now. Please take your time and only do a change to your table if you are happy with it!

[ClarkKent]

I noticed that Walls129 and 130 (between inlane and the post above) are also not necessary anymore. You can delete those two. For analogue plungers Park Position 0,01 is better.

 

Love this table. Great light show, great gameplay, great VPX port. If the pulsing of the GI and some inserts can be simulated one time I consider this a perfect port!

[robertms]

Dozer, this table is such a masterpiece I grin silly every time I fire it up. It truly advances VP into new territory and proves everything else (FP, TPA, FX2) is just a video game at best. I have to admit Clark's recent tweaks and suggestions have been really good ones, who knew he was so good with rubbers  And the latest version of that sick-resolution backglass that bassgeige and haunfreaks cooked up is just icing on the cake. Superb job everyone involved!

[Dozer316]

I noticed that Walls129 and 130 (between inlane and the post above) are also not necessary anymore. You can delete those two. For analogue plungers Park Position 0,01 is better.

 

Love this table. Great light show, great gameplay, great VPX port. If the pulsing of the GI and some inserts can be simulated one time I consider this a perfect port!

 

If you dropbox the current state of the table with the changes you have made, I will use it as as starting point for any additional changes as time goes on.

[bassgeige]

There is another way for dB2S handling possible. A modified ROM input splitt into two command outputs and one of them could be set to an own time delayed value. This would mean what I did not see in the actual dB2S designer yet, to delay the wheel from the cannon shot without the need for various single pictures. Another way to have even further feedback from the table could be to use the actual user neon tube colour setting from the table transferred for example into your described triggering string names and this could be used as actual value for the dB2S and on this way a direct feedback for more interesting backglass and live user interaction is possible. I know that you are in groundbreaking new land and I will wait very interested which solutions you are going to include next. Maybe a few ideas described from me could be a next interesting step.

[Dozer316]

There is another way for dB2S handling possible. A modified ROM input splitt into two command outputs and one of them could be set to an own time delayed value. This would mean what I did not see in the actual dB2S designer yet, to delay the wheel from the cannon shot without the need for various single pictures. Another way to have even further feedback from the table could be to use the actual user neon tube colour setting from the table transferred for example into your described triggering string names and this could be used as actual value for the dB2S and on this way a direct feedback for more interesting backglass and live user interaction is possible. I know that you are in groundbreaking new land and I will wait very interested which solutions you are going to include next. Maybe a few ideas described from me could be a next interesting step.

 

This is all very possible - the code for colors is already in the table script and used by DOF (Directb2s) for flipper and under cabinet RGB when the extra ball button is pressed so this can be included in the designer easily.  You'd just need 8 different snippets for each of the colors assigned to the appropriate directb2s id.   You will notice that the backglass I included with the table has a delay set for the wheel so it runs after the ball has made it to the top of the arc.  The table script waits about 800ms or so before it triggers the wheel after the cannon has fired.

 

You can be very granular with commands when you do it manually like this so there is an advantage in some ways over using the rom.

[freneticamnesic]

I've been away from this for too long. This is legit the best looking table available anywhere, FP, VP, TPA, it's not even close.