868 replies to this topic

[BorgDog]

Edit: Nevermind. I guess it makes sense to read it if you want to check if the entire target bank is dropped whenever a target is hit...

 

Yes, that's the usual scenario.

 

The isdropped setting is set to 0/1 after the animation. The problem here is that the collision detection is decoupled from the graphics animation. That means if you get a hit event the collision detection has detected a hit and triggers the callback but the animation isn't finished yet and isdropped shows still the old status.

 

Interesting, and kind of makes sense, does this potentially allow for double hits as the target is being dropped since the target is not technically dropped or is the collision detection off at that point?

 

I guess since I'm aware of it I can work around it, but I think it would be easier if the callback wasn't triggered until the animation is done.  Of course I think this all ties into why the raised delay was added as well.

[gtxjoe]

One workaround is to use the Target.UserValue field in the script.  I think this would work

 

Anytime a target is hit in the Sub target1_Hit() , set the UserValue to 1 (indicating it is dropped)

Antyime a target is reset, set the UserValue to 0 (indicating it is not dropped)

And then to determine if a target back is all dropped, you check the target UserValues, so regardless of animation speed, you don't need to run a timer to continuously check the IsDropped status of the target bank,

[BorgDog]

that's kind of cool, I had seen UserValue there, but had no idea what it was for.  thanks.

[allknowing2012]

On 10.0 final (havent tried 10.1) when you click Backdrop->Options then Click Enable Decals it clears the check in enable EMReels but does nothing for Enable Decals.

Bug? (not that it likely matters since I dont know why you click it :-) )

[fuzzel]

rev2524 is up:

 

- hit/drop target: fire hit event after animation is over
- gate animation reworked
 

[BorgDog]

Thanks for the change on the drop target event firing timing, that will make some coding easier.

 

It appears to have introduced another little bug however, if your target is not visible now it will not register the hit.  I went back one version to check and it works in that one, but not in this one.  Easy enough fix as I really didn't need to have an invisible target object, I just made it an invisible wall with a hit event instead.  Just wanted everyone to be aware in case someone had some invisible target objects.

[fuzzel]

Thanks for the change on the drop target event firing timing, that will make some coding easier.

 

It appears to have introduced another little bug however, if your target is not visible now it will not register the hit.  I went back one version to check and it works in that one, but not in this one.  Easy enough fix as I really didn't need to have an invisible target object, I just made it an invisible wall with a hit event instead.  Just wanted everyone to be aware in case someone had some invisible target objects.

Yes that the problem with this change. I think I mentioned it in your bug tracker report but because you can use a invisible wall as trigger it's ok the way it is now.

[allknowing2012]

I see some work on gates - would it makes sense to add another "width" for width of the spinner itself as opposed to the length of the bracket? Is it worth the effort? What about the the wire that goes up and down, is that possible to add?

[fuzzel]

Another spinner mesh shouldn't be a problem but adding a "width" doesn't make sense because it would only scale one dimension without the others and then you would have a very flat but wide spinner plate. Btw the length also scales the spinner plate it's not bound to the bracket alone.

[fuzzel]

rev2528 is up:

 

- fix fire collection event for hit targets (workaround)
- add hit/drop traget to seach/select list
- change verbiage of "Rotate for cabinet usage" to "Use always FS backdrop settings (Cabinet usage)"
- fix display EM reels/decal check box in the backdrop settings
 

[fuzzel]

rev2529 is up:

 

- set default gate type in case of a broken file (reported by wrd1972)
 

[allknowing2012]

Another spinner mesh shouldn't be a problem but adding a "width" doesn't make sense because it would only scale one dimension without the others and then you would have a very flat but wide spinner plate. Btw the length also scales the spinner plate it's not bound to the bracket alone.

Aware of the length - but sometimes I wanted the bracket to be wider to sit on the posts without making the spinner so wide. Just a nice to have .. nothing critical.

[allknowing2012]

Can you do a gate with a rectangle wire of height 70 -- the wire is like dragging thru the playfield. Its not scaled correctly. I like to use 50 height to get the mounts at the right height, but then the wire is buried in the playfield :-(

[Neo]

I noticed on target objects the UserValue doesn't appear to be defined for the object even though it appears in the editor. I tried using DropTarget.UserValue = 1 and got a script error "object doesn't support this property or method"

 

Also, when you try to put a value in the User Value in the editor it doesn't stick. It clears out when you click back on the target

 

Just something I noticed while trying to build my first table in 4 years in VPX.
 

Take Care

[Neo]

Something else I noticed...changing the drop targets to fire the hit events after the animation is done may have broken something I was trying to do. In my table I have two different-colored balls (the normal silver ball and a gold ball), and I want the targets to score double points when hit by the gold ball. I set a ball object to ActiveBall in the hit event sub depending on the target(s) to check the ball color (ball.Image). Used to be that ActiveBall was set on the hit event itself, and on the hit event it checks the color, and if it's gold, score double the points.

 

in code it looks like this:

' There are three drop targets in the bank, the hit event subs are the same for each one. 
Sub DTHexH_Hit()

    If not Tilt then
        Set HexBall = ActiveBall           
        DTHexCount = DTHexCount + 1
        DTHexSeq = DTHexSeq & "H"
        If DTHexSeq <> "H" Then
            HexSeq.State = 0
            HexInSeq = False
        End If
        CheckHex()
        PlaySound "TargetDrop1"
    End If

End Sub
 
Sub CheckHex()

    If not Tilt Then
        If DTHexCount = 3 or (DTHexH.IsDropped=True and DTHexE.IsDropped=True and DTHexX.IsDropped=True) then
            If HexBall.Image = "dvogold" Then          
                AddScore 20000
            Else
                AddScore 10000
            End If
            If DTHexSeq = "HEX" Then
                AddActiveBonus():AddActiveBonus():AddActiveBonus():AddActiveBonus():AddActiveBonus()
                If not XBallThisBIP Then ActivateExtraBall()    
            End If
            DTHexH.TimerEnabled = True
        Else
            If HexBall.Image = "dvogold" Then         
                AddScore 4000
            Else
                AddScore 2000
            End If
            AddActiveBonus()
        End If
    End If

End Sub 

What I'm finding in this new build is that when the hit event fires, it's now taking a script error saying the ActiveBall is null (it was working fine in previous beta builds of VP 10.1. I was using 2474 and 2522, and I'm now running 2529, and it doesn't work with 2529), and I'm not sure how to fix it. Even if I set the drop speed to some ridiculously high number (I've tried as high as 1000) it's still taking this error intermittently.

 

Any ideas how I can make this work with the way the drop targets work now or should I just abandon the idea of having different-colored balls altogether?

 

Take Care

[fuzzel]

ah I feared that I opened pandora's box with this change The reason for the active ball is null is that normaly when a hit event is detected you have an active ball (which triggered the hit event) in that context. But now the event is fired without any active ball anymore because the ball is already somewhere else (depending on the animation speed). I see two options here: 1. I revert the changes back to rev 2522 (hit event is fired when the hit is detected) or 2. you work with a second invisible set of drop walls and handle the event with the wall's hit event instead.

[gtxjoe]

Is there a third option, maybe to revert and set isdropped = true and make inv wall non-collidable when the target is hit and the animation starts?

[Neo]

Well strictly from my perspective (me being a scrub original-table builder), falling back seems easier and makes more sense to me (since every other hit event fires on hit. I'm confused as to why drop targets had to be treated differently unless it's due to the animation). That said, I'm not fully sure what else was implemented between 2522 and 2529 (I'm sure I could look it up) nor do I know how critical those intermediate changes between 2522 and 2529 are. Personally, I've fallen back to 2522 so I can continue playtesting my first VPX table.

 

I'd have to give some thought to the invisible drop walls idea...my VP building skills are somewhat limited, and I'm having trouble visualizing at the moment how I can make that work. In the meantime I think I have managed to work around the issue that apparently caused the change to make the hit event fire after completing the animation.

 

If firing the DT hit event after the animation is here to stay and I have to adapt, then I'll have to adapt somehow.

 

Take Care

[BorgDog]

Would it just make sense to just de-couple the animation from the rest of the hit entirely? Ball hits target, hit event triggered, isdropped set true, and animation started.  No dependency on the animation for anything.  Would be just like before we had this object and used a wall to trigger all the stuff.

 

It makes no sense to even have the target object if we still have to do everything as a work around just like we did before, all we seem to gain is an animation.

[allknowing2012]

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.