868 replies to this topic

[BorgDog]

I think allknowing and I are on the same page here.. I think .  From a pinball standpoint it makes more sense to have the hit register when the target is dropped (and it makes a lot of programming things easier)

 

Not sure how that relates to ActiveBall, isn't there always an ActiveBall?  Shouldn't anytime you check ActiveBall it will return something?  (note I have never used this myself so actually have no idea)

[gtxjoe]

Another possible option might be have a:

 

- target_hit event which starts the animation and author can script in the playsound ()

- target_unhit event when the animation is done and the isdropped is changed to TRUE, so author can script the pinmame switch call and/or perform the target bank check/reset

 

 

target_hit () would satisfy majority of authors and works with existing tables

target_unhit()  could be used where timing is more critical like the EM target bank check

Edited by gtxjoe, 06 March 2016 - 02:48 AM.

[jimmyfingers]

We need to have ActiveBall processing allowed on all hit events (all objects, which was true for anything that had a hit event up until now).  Too many things depend on this from sound processing to custom physics routines (dampening, speed detection, etc.).  Making the targets act different then every other item being hit, as far as not allowing this function, is not a good idea at all in my opinion.  Whatever way the re-coding or reversion is to be changed, the ActiveBall needs to be determinable at the time of the hit event, as quite simply it can't afterward plus the speed at the time of the collision is going to change after any moment of time afterward.   What happens animation wise and processing for scoring could still depend on other things like when IsDropped is true / completed and that could be the item that is delayed.  

 

Not sure of the best way but I definitely would not stray in how the ball detection works at the time of the initial Hit / collision.

[allknowing2012]

Another possible option might be have a:

 

- target_hit event which starts the animation and author can script in the playsound ()

- target_unhit event when the animation is done and the isdropped is changed to TRUE, so author can script the pinmame switch call and/or perform the target bank check/reset

 

 

target_hit () would satisfy majority of authors and works with existing tables

target_unhit()  could be used where timing is more critical like the EM target bank check

The sound you are programming is the clunk of the target hitting the bottom..and you shouldnt call the pinmame switch hit on the hit but the full drop. That is what the real machine would do.

Activeball hitting the target for volume - should there really be a volume for a target drop? hmm...

 

 

-- if the code is reverted back, then I stick with a timer to simulate the wait for the target to drop .. no harm in doing that either.

Edited by allknowing2012, 06 March 2016 - 03:03 AM.

[Neo]

back to square one .. the hit triggers the target reset and the animation is still going so the target stays down :-( If we are trying to replicate real pinball the hit event shouldnt happen till the target drops completely. If folks want to do non "real" pinball things with the hit event then coded workarounds should be needed - no offence to the requester .. just my opinion.

 

None taken...there is a real-pinball precedent with what I'm trying to do though: The powerball in Twlight Zone...the machine acts differently when the powerball is on the playfield as opposed to the regular ball (IIRC, the powerball's made of a different material and a different weight which enabled the machine to distinguish it from the normal steel ball). What I'm doing is not exactly the same, but the TZ powerball did inspire me to at least give different-colored balls a go.

 

In all honesty, if there is a way to somehow retain ActiveBall from the start of the animation through the hit event firing then that'd be all I'd really need, regardless of when the hit event actually fires.

 

Take Care

[gtxjoe]

The "sound" is the ball colliding with the target, the target sliding/rubbing as it travels through the target assembly and then yes hitting the bottom/switch     

 

We could deal with this by just using the original vpx implementation and throwing in some timer delays to take care of the script issues, but I am also interested to see if toxie/fuzzel can make the implementation more realistic without any major design changes

Edited by gtxjoe, 06 March 2016 - 04:00 AM.

[BorgDog]

Another possible option might be have a:

 

- target_hit event which starts the animation and author can script in the playsound ()

- target_unhit event when the animation is done and the isdropped is changed to TRUE, so author can script the pinmame switch call and/or perform the target bank check/reset

 

 

target_hit () would satisfy majority of authors and works with existing tables

target_unhit()  could be used where timing is more critical like the EM target bank check

 

I like this idea, although maybe a target_collide (like the flipper collide) that occurs when ball hits the target, and a target_hit that would be when the drop hits the bottom and triggers the isdropped state.  Whatever you call them, it would give us the flexibility to do with them as desired (play ball hitting target sound on collide and target hitting the bottom on "hit").  yes, we can all code ways around the issue no matter which way things are, but again in an ideal world we shouldn't have to    

[fuzzel]

Ok I reverted the changes back to the old behavior as this is the more aligned way for every hit object. Maybe I add an extra event to the drop targets...

 

rev2530 is up!

Edited by fuzzel, 06 March 2016 - 01:34 PM.

[jpsalas]

Ok I reverted the changes back to the old behavior as this is the more aligned way for every hit object. Maybe I add an extra event to the drop targets...

 

rev2530 is up!

Yes, I think that the best to do, so all the objects react the same way during a hit. To create a later reaction to a hit event an author can always use the vpmTimer.AddTimer.

[BorgDog]

 

Ok I reverted the changes back to the old behavior as this is the more aligned way for every hit object. Maybe I add an extra event to the drop targets...

 

rev2530 is up!

Yes, I think that the best to do, so all the objects react the same way during a hit. To create a later reaction to a hit event an author can always use the vpmTimer.AddTimer.

 

 

That's the problem, they don't act the same way.  

 

if I hit a wall it immediately fires a hit event and if the first line of that is wall.isdropped=true then in the next line I check if wall.isdropped it will be true.

 

if I hit a drop target it also immediately fires a hit event and if the first line of that is target.isdropped=true then in the next line i check if target.isdropped, it will be false.  There is a forced delay in the isdropped. 

 

Any programmer looking at two lines of code the first saying target.isdropped=true and the second asking if the target.isdropped would expect a true.

 

Since the drop targets seem to be unique in this delayed isdropped (does anything else even automatically set it's own isdropped?) having the second event associated with it sounds like a good idea, say a target_dropped event that occurs when it actually isdropped.

[jimmyfingers]

@BorgDog - that's all looking at it from the IsDropped context / processing but there is other processing needing to be considered and at the onset of the ball making contact for the _Hit event, there has to be enough code functioning to still handle the ActiveBall / initial collision as one would normally for other objects and was why these recent "null" issues came up.  The IsDropped or handling of the animations / delays will need to be dealt with differently either with new coding / extensions in the source or through scripting work-arounds (can't really work around a missing ActiveBall function from a _hit in the script) as simply delaying the hit is going to break too much for ball collision / speed assessment using things like ActiveBall.VelX / ActiveBall.VelY or positional assessment of the ball such as ActiveBall.X / ActiveBall.Y.  A lot of additional and beneficial routines rely on this such as sound processing as well as newer positional sound processing and it can only be assessed correctly at the moment of impact / _Hit with a collidable object to use the ActiveBall class / object.

[arngrim]

small thing but it makes the authors and myself confuse to use wrong switch sometimes, the template table has left slingshot sound for right slingshot and vice et versa, please fix that small typo

 

Sub RightSlingShot_Slingshot

    PlaySound "left_slingshot", 0, 1, 0.05, 0.05

    RSling.Visible = 0

    RSling1.Visible = 1

    sling1.TransZ = -20

    RStep = 0

    RightSlingShot.TimerEnabled = 1

gi1.State = 0:Gi2.State = 0

End Sub

 

Sub RightSlingShot_Timer

    Select Case RStep

        Case 3:RSLing1.Visible = 0:RSLing2.Visible = 1:sling1.TransZ = -10

        Case 4:RSLing2.Visible = 0:RSLing.Visible = 1:sling1.TransZ = 0:RightSlingShot.TimerEnabled = 0:gi1.State = 1:Gi2.State = 1

    End Select

    RStep = RStep + 1

End Sub

 

Sub LeftSlingShot_Slingshot

    PlaySound "right_slingshot",0,1,-0.05,0.05

    LSling.Visible = 0

    LSling1.Visible = 1

    sling2.TransZ = -20

    LStep = 0

    LeftSlingShot.TimerEnabled = 1

gi3.State = 0:Gi4.State = 0

End Sub

 

Sub LeftSlingShot_Timer

    Select Case LStep

        Case 3:LSLing1.Visible = 0:LSLing2.Visible = 1:sling2.TransZ = -10

        Case 4:LSLing2.Visible = 0:LSLing.Visible = 1:sling2.TransZ = 0:LeftSlingShot.TimerEnabled = 0:gi3.State = 1:Gi4.State = 1

    End Select

    LStep = LStep + 1

End Sub

[fuzzel]

rev2532 is up:

 

- default table: slingshot sound for left/right slingshot fixed
- add dropped/raised event for drop targets only (it is save to check the isdropped setting from these callbacks)
 

[BorgDog]

Thanks fuzzel, droptarget_dropped works great!

[BorgDog]

Can we get an addition/clarification to the Dimensions Manager?  I'm looking for early, 60s, 70s Williams dimensions, and none of the annotations in there apply.  From what I've been able to dig up in several posts the dimensions would be the same as the WPC (through 1987) designation of 20.5"x42" or 964x1974 vp units.  This post supports that idea if you read far enough stating Standard Williams through 1987: 964 x 1974 and Standard Williams after 1987: 964 x 2162  .  I guess my confusion is that WPC certainly does not apply to Williams in the 60s and 70s, and in fact WPC did even come about until 1990 with Funhouse, so maybe that WPC (through 1987) should really state Williams (through 1987) since System 1-11s (prior to WPC) have their own listings, and a different dimension.

 

Does that make sense?

[sliderpoint]

Can we get an addition/clarification to the Dimensions Manager?  I'm looking for early, 60s, 70s Williams dimensions, and none of the annotations in there apply.  From what I've been able to dig up in several posts the dimensions would be the same as the WPC (through 1987) designation of 20.5"x42" or 964x1974 vp units.  This post supports that idea if you read far enough stating Standard Williams through 1987: 964 x 1974 and Standard Williams after 1987: 964 x 2162  .  I guess my confusion is that WPC certainly does not apply to Williams in the 60s and 70s, and in fact WPC did even come about until 1990 with Funhouse, so maybe that WPC (through 1987) should really state Williams (through 1987) since System 1-11s (prior to WPC) have their own listings, and a different dimension.

 

Does that make sense?

 

nerd! 

[ninuzzu]

I know I've done this before, because I have a file with 5 materials in it when I import, but how do I export several or all of the materials from one table into a single file so I can import them into another table?  Old age is setting in.. or the Jack is taking it's toll.. yeah that's it Jack is clouding my brain...

 

thanks.

 

 

I guess we have a bug, because I also can't export all the materials, I have also a .mat file with severals materials inside.

Another bug i found is when you delete the last material, the other materials will be messed up. I think it's better to report this in the VP10.1 thread

I'm lazy so I quote myself

[fuzzel]

I'll take a look but we have a bug tracker for such things.

[fuzzel]

rev2533 is up:

 

- fix multi selection in the material manager (allowing deleting/exporting multiple materials)

[ClarkKent]

I also noticed a little bug: When zooming in, the points are not adjustable anymore in the last two zooming stages. To be able to work EXACT this would be necessary to be working!