666 replies to this topic

[koadic]

I think RotY might be a little redundant for an object that is essentially a plane... you only really need angle (rotx) and rotation (rotz), also, changing terminology to RotZ messes up all previous rotation adjustments saved in earlier versions. I'm reluctant to resave my table with this version until we finalize the terminology so I don't have to go and readjust them again.

At least the triggersingleupdate method actually works now and provides a fps boost... almost to (if not at) the level of ramps

Edited by koadic, 30 December 2013 - 09:44 PM.

[fuzzel]

Hmm good point, so what you suggest for those two rotation values?

[koadic]

angle - the rotx value, and rotation - the rotz value, that way it uses similar terminology as the gate object... as opposed to the primitive object which is more 3d based

[fuzzel]

Ok on my way

[jimmyfingers]

Hey guys, maybe I'm missing something here but I wouldn't remove the 3rd rotation as with ramps I would previously rotate them by 90 or 180 along the same axis as the plane so that using two of the same images right next to each other provided some slight variation in the peaks of of the lens flare effect / spires and made it seem a bit more natrual.  It could be done rotating the images themself but the less imported / loaded images we need the better.  Quickly testing the latest 836, I could see uses for all 3 rotation elements with this in mind.

 

Also, quickly testing it looks like FPS is indeed back up around the ramp value and working without RU in a similar fashion to ramps.  I think the real test will be a load test of quickly swapping the images and both observing the differences while using the new object vs. ramps in the FPS but also qualitatively by assessing the ball flow and looking for stutter or hick-ups of some sort.

[fuzzel]

rev 837

Hey guys, maybe I'm missing something here but I wouldn't remove the 3rd rotation as with ramps I would previously rotate them by 90 or 180 along the same axis as the plane so that using two of the same images right next to each other provided some slight variation in the peaks of of the lens flare effect / spires and made it seem a bit more natrual.  It could be done rotating the images themself but the less imported / loaded images we need the better.  Quickly testing the latest 836, I could see uses for all 3 rotation elements with this in mind.

 

Also, quickly testing it looks like FPS is indeed back up around the ramp value and working without RU in a similar fashion to ramps.  I think the real test will be a load test of quickly swapping the images and both observing the differences while using the new object vs. ramps in the FPS but also qualitatively by assessing the ball flow and looking for stutter or hick-ups of some sort.

I think this makes sense...I've changed the rotation values in 837 (only Angle/Rotation) but I think it's a bit limited because you can't topple the flasher to the left/right anymore...let me know what you think with this and if the older version is better I can add the three axis option again...

[koadic]

Maybe a 3rd rotation option might not be a bad idea then... I would leave the base angle/rotation as is, maybe add it as tilt (or back to X/Y/Z?)? and make sure the rotation acts as ObjRotZ, so it always rotates on the tables z axis

Edited by koadic, 30 December 2013 - 11:08 PM.

[fuzzel]

I think that RotX/Y/Z is basicly the naming of that behavior because you rotate the plane around these axis. What about RotX/Y or RotUp/Down(as RotX) and RotLeft/Right(as RotY)  and Rotation(RotZ)?

[fuzzel]

rev838 adds the RotX/Y/Z again. I can't find other names for the rotation

[koadic]

I had written something out replying to your post before you updated to 838, but I guess I switched windows or something before I actually hit post, and didn't have time last night to retype it out before I had to get ready for work...

I was gonna suggest the 3 options be, in primitive terminology, RotX/RotZ/ObjRotZ... RotX to set the angle, ObjRotZ to set the rotation on the table, and RotZ to swivel the flasher around on the angle set by RotX without adversely effecting ObjRotZ rotation. And I am still a fan of naming RotX/ObjRotZ as angle/rotation (just thinking of UW and any others who have started trying to implement flashers into their tables already) so every flasher that is already rotated doesn't have to be set again. Still trying to think of a good name for the RotZ implementation though... maybe swivel/twist/orientation/image rotation? or...

Anyway, I am sure you are tired of changing this back and forth, and I will let it drop after this I just wanted to post this because I had it all typed up yesterday to post before you committing rev838, but obviously did something where I lost it, and just wanted to express my thoughts on the matter. And if you don't want to change it, it might be helpful to recognize the short lived legacy setting of rotation so tables modified with earlier betas wont need to be readjusted to work with the new system, although that is completely up to you (as there are probably very few).

[koadic]

i personally would rather go for some standardized form, so that basically authors could flag sounds in certain categories..
and then these categories could be dis/enabled by the user..
 
excluding sounds by name simply sounds weird somehow..

I had a thought on this...

How about adding an additional playsound method, like maybe... PlaySound2 (or PlayFeedback) where it could be controlled from something like Table1.PlaySound2=True/False. I also had another thought along a similar line for tables that use samples in place of rom sounds, and use PlaySample "Sample1" utilizing a separate volume slider for samples, like how the sound and music volumes are separated currently. PlaySound will always still work for current tables, but they can be split up into more categories for greater control.

[arngrim]

Like the idea, considering the sounds that need to be put on playsound2 should cover ALL the toys that someone can have

[sleepy]

I've wondered about a stereo WavOut access feature (Ch 1, Ch2, and Pan) that would allow for synth waveforms generated from script using a Timer, an Array Dim and equations. I've always found it frustrating to have to use large .wav files for beeps and growls and pitchbends that could be generated on the fly at a much smaller filesize. Something like sounds in the BASIC programming language, or late 70's pinball synths. Currently it is impossible to generate even a simple console beep for the sound card. 

Edited by sleepy, 01 January 2014 - 01:58 AM.

[fuzzel]

that's correct and I think it shouldn't be hard to implement this. I would go even further and implement a basic synth sound engine which is accessible from the script. I don't have much experience with sound programming so I don't know when we start this...

[sleepy]

One of the uses of synth would be to generate sounds that, by their periodic propagational values, could also trigger events at any specified point during the sound. A programmed "Siren" sound might also control a Flasher, a rise/fall sound could control the Bonus Lights in countdown, or control the Light Sequencer Object as a sound controlled Color Organ, etc.

So a dedicated synth module might need to provide return values throughout the sound generation to accomplish this control, else I would be interested in both a synth module and a simple WavOut port to allow this interaction.

 

Looking around, it appears the Windows Core Audio API is the means to access the WavOut function. Of course, this API is more tedious than standard C++ audio libraries.

[arngrim]

for information, here are all the sounds that i directly remove from the sound manager after downloading any table release:

 

flippers

slings

bumpers

targets

droptargets

targetreset

autoplunger

drain

ballrelease

ejectholes

knocker

motor

 

when you play vp at higher volume, it's quite annoying to hear these mechanical sounds at the same level, or hear them at all, when you have force feedback,we have more than 300 users using dof configs now, i suggest them to do the same than me until we have a more decent solution

[DJRobX]

Agree with the above - It would be great to be able to classify sounds in the sound manager. 

 

I've modded my own VP sources to be able to send sound to two different output sources.   Someone suggested changing VP to send sound output to the TV to make the mechanical sounds emanate from the playfield area.    I tried this and immediately loved how much more realistic it was. 

 

But, this left some problems.   Music tables like ACDC were sending their music to the TV.    Some tables like Elvis or LOTR that work around Pinmame performance issues also direct all their sound out of the TV.     It wasn't too hard to modify the sound routines to support a second device.  The problem now is being able to tell VP where each sound in the sound manager should go.   For now I have a dirty hack of adding a button to the sound manager that replaces the sound pathname with a special token ("Backglass output*)", since as an end user i'll probably never need that pathname.   It would be great to have a more official solution. 

 

If we had a way to classify the "mechanical" sounds in the sound manager, it would help both DOF users (who want to turn it off) and others (who want to send sound to the TV).

 

This could also pave the way to eliminate custom DOF configs - if the table directly contains the information needed to trigger the right hardware, PlaySound "FlipperLeft" could trigger LEDWiz hardware in one config, and play the sound on the TV in another. 

[fuzzel]

New feature alert! With rev 839 you can throw balls inside the player with your mouse. I liked that feature when I saw it the first time in U3D Pinball. To use this feature you have to check under Preferences -> Editor Options -> "Throw Balls in Player".

When activated a left click will create a ball at the mouse cursor. If you hold the left mouse button and move the mouse the ball will be thrown in that direction when you release the left mouse button. A left click on a non moving ball will reuse the ball instead of creating a new one. A right click on a ball will remove it from the table.

 

Here is a short video showing that feature in action: http://youtu.be/nTqfxRLoT44

 

Edit: Using that feature on already released tables can give you script errors. The reason for this is that most scripts keep track of the created/destroyed balls on the table and if you create/destroy additionally balls you can screw up the script logic. So just keep that in mind

Edited by fuzzel, 03 January 2014 - 10:05 AM.

[arngrim]

holy cow, that will help me a lot to ledwiz tables, thank you

[koadic]

Is there any way to possibly move the setting for this to the debug window? and only have it active while that window is open? I can see it as a handy tool to use, but accidentally leaving it on and clicking on the screen might get frustrating... that way too, it can be enabled without exiting the already running table.