4027 replies to this topic

[danomyte]

thanks gxtjoe!

[toxie]

@toxie I built x64 VPinball yesterday. Whilst trying to get something working this what I needed, it does turn out that I won't be using this x64 method now though.

 

I was just wondering about how long it takes to load the "VP Player Render". It's significantly slower loading on the x64 build, just wondered if this is normal or missing something?

This shouldn't occur (i think). Is this specific to one table or did you try others, too? If its specific, can you point me to it?

[chepas]

This is just doing a "New Blank Table" and running it. At the time the "Rendering table" comes up there's a noticeable hang between the builds fuzzel uploads.

 

I got from git, grabbed the DxSdk, build from VS19, used the x64 3rd party dlls.

[The Loafer]

First and foremost I didn't mean to offend.  I really do appreciate everyone's blood sweat and tears that goes into all this.  

 

A little background on why I posted my previous request.  I believe in Beta testing and realize its importance.  I actually jumped on 10.6 as soon as it was available for my desktop version but because its a little trickier for me to always update my virtual pin cabinet I decided to wait for final release to jump to 10.6 on the cabinet.  Plus test on one (desktop) and compare to the other official release (cabinet).  Also as previous mentioned I realize you have to hit enter twice because of the pop up but on my virtual cabinets some of my guests may not realize this.

 

With the above said I found almost 99% of the tables made with 10.6 worked fine on 10.5.  Exceptions I found were Flintstones and Ice Fever (I'm sure there was more).  So tons of tables created fine with 10.6 work on 10.5 so why not play them until 10.6 became official?  What wasn't working fine during the beta process was 10.6 itself (which is fine as that is part of the beta process i guess).  So obviously there was a lot of 10.6 beta releases.  At times several a week.  There was no way I was going to move half my pinball machines (I have over 20) to get at the back of my virtual pin to keep upgrading.  Plus the 10.6 beta went on for an extremely long time.  That's fine but why should I wait in playing a new table I know works fine on either version when the problem is only the beta itself?  All I simply asked is there a way to suppress the warning  that your not on the beta to work around the issue especially because there was so many versions of the beta and the beta went a long time.  That would make a whole problem go away.  Besides isn't that part of the beta process finding out things and offering suggestions to make the product better?  Is not asking for the ability to disable the error pop up a legit request?  It doesn't have to be implemented but isn't any question a valid question during beta period?  Just offering some advice for 10.7 beta so we can evolve and solve problems.  Besides other areas in VPX has options to "ignore errors".

 

As I write this I am already regretting it because it will probably spew a bunch of backlash and hurt feelings.  Something I am not trying to do.  If you look at my previous comments in the past I have actually tried to help others (with little knowledge I have lol).  I love this group.  I'm also regretting this post because its gonna spark a ton of responses going off topic in how I manage both machines, remote connection tools, backups, running multiple versions, etc.

 

I guess I will live with the error pop up and go underground.  Don't worry I learned no more comments from me.  If you take one thing from this email I am very sorry to offend and keep up the great work all.

 

For the record, I was never offended and I don't think Toxie was.  This in actuality is not bad advice to say "if you don't want to update to VP10.7 then don't play VP10.7 tables". This isn't saying anything negative it's the same as saying "if you want to play VP10.7 tables, then ensure you update the latest 10,7beta handy.  I do think Toxie exposed something a little here because having reasons to not update the pincab because of access to machine or lack or internet or whatever is fine, BUT then how that doesn't stop you from putting the new tables on the same machine? It's the SAME PROCESS!

 

Anyway, you seem like a nice chap, don't take these comments too seriously.  Personally, if you can put the new table on the pincab, then it's worth upgrading with the required exe. Right now, it may not be so apparent but some tables will be built with very specific VP10.7 features and that can make it worth it in the end.  I felt that way specifically when they added much better physics to the saucers to the point where not putting on VP10.6 was to me foolish.

 

GTXJoe/Danomyte: I think that was accurate as long as the table didn't use a new feature (like the saucer physics thing).  Maybe it still works that way for VP10.7 as long as no new "playing" features are incorporated in the new beta

[toxie]

Sorry, I should have been more clear. When I was doing reimport from. I could load one or two sound but then the program would crash.

Can repro, will fix later-on. Thanks for the report!

This is just doing a "New Blank Table" and running it. At the time the "Rendering table" comes up there's a noticeable hang between the builds fuzzel uploads.

 

I got from git, grabbed the DxSdk, build from VS19, used the x64 3rd party dlls.

And also building 'Release'? Cause 'Debug' will be slower to load, etc.

[chepas]

 

Sorry, I should have been more clear. When I was doing reimport from. I could load one or two sound but then the program would crash.

Can repro, will fix later-on. Thanks for the report!

This is just doing a "New Blank Table" and running it. At the time the "Rendering table" comes up there's a noticeable hang between the builds fuzzel uploads.

 

I got from git, grabbed the DxSdk, build from VS19, used the x64 3rd party dlls.

And also building 'Release'? Cause 'Debug' will be slower to load, etc.

 

 

Ah good point! Only built once, so it will be that. Cheers.
 

[onemanproject]

Thank you to all involved and many thanks for the further development

 

omp

[toxie]

 

Sorry, I should have been more clear. When I was doing reimport from. I could load one or two sound but then the program would crash.

Can repro, will fix later-on. Thanks for the report!

Fix will be in next version.

[fuzzel]

rev4060 is up:

 

- update event handling and fix drag'n drop issue
- fix closing table handling on exiting VPX
- Patch by mfuegemann: Add directional (pan/fade) sound to DropTargets, Kickers, Trough, BallStacks, Locks, Diverters (core.vbs)
- fix reimport(from) in sound manager crashing
- change GetTable to ActiveTable to match existing ActiveBall (see CommandReference.txt)
- add GetTable to the script globals (see CommandReference.txt)
- add Inder/Playmatic trigger mesh
- reduce speed up a bit again (plunger)
- fix some more problems with the new retract plunger and increase pull speed x2
- fix missing custom colors in the colors dialog

 

[danomyte]

Awesome.  Thanks for your efforts

[mfuegemann]

Hi,

 

Thalamus asked me some days ago, if something could be done about the soundeffects of the standard Drop Targets Banks, as they are not using the new parameters for AudioPan und AudioFade of the Playsound command.

This was something that has bothered me for quite a while too. Now I had a reason to investigate it further.

 

Looking at the core.vbs, I realized, that the implementation could be done without changing the main VPinball.exe code and so I started. At first I tackled Drop Targets but the code for the other table elements such as Trough, BallStack, Saucer, Kicker, Diverter, VisibleLock was similiar. So I implemented it there too. 

Elements, that are covered by JP's sound code, as Gates, Flippers or the Plunger, I left as they are.

 

Thalamus did extensive tests and soon we realized, that we needed to add error detection, as there are lots of tables, that use only part of the standard functionality, leaving us with no object to decide the element position. Furthermore there are some tables, that use walls as Drop Targets and here we cannot use the correct initialized object to get the position.

If any error cause is detected, the "old" sound code will be used.

 

At the beginning I used constant values for table width and height to calculate AudioPan and AudioFade (standard size 950x2100), as I had no direct acces to the actual table values from the core.vbs script. Then Toxie added new methods to the current VPin 10.7 release (rev4060), that allow a table specific handling also for Widebody tables.

For VPin versions prior to 10.7 the constant values are used, so the new functionality is working for older VPin versions too.

And the best of all - this will work for all tables and improve most of them. 

 

I do hope You like the improvements as much as we do.

 

Regards

Michael

[Thalamus]

I've been playing all day long hearing sounds that has up until now been "misplaced" to default location. Fantastic job Michael !

[batch]

Nice to see Michael has joined the team (almost German !)

 

You guys are really doing a good job on this software, and I don't know what I would have done in my life if there was not been VPinball (sorry for the bad English)

 

I don't know where we're going with it, but, sure, it's very exciting !

[kiwi]

If I go back and forth between the backglass and the editor, the property panel does not update, if it is on the properties of the table,

if I select an object and then click on nothing, the panel refreshes.

 

Thanks!

[blindpeser]

You guys can't get enough cheers for your hard work! Thank you very much

[flstclasic]

Thanks to everyone!

[DJRobX]

Excellent.  This has been sorely needed for a long time. 

[RustyCardores]

Awesome work. Huge thanks to all involved.

[Brew]

Thank you! SSF is really awesome

[Ciceronic]

Great work, looking forward to this upgrade!
Very cool that it will also upgrade older tables.