Jump to content



Photo
* * * * - 7 votes

The VP 10.3 beta thread


  • Please log in to reply
616 replies to this topic

#241 BorgDog

BorgDog

    We come in peace.. shoot to kill.. shoot to kill.

  • Members
  • PipPipPipPip
  • 1,427 posts
  • Location:Leavenworth, WA

  • Flag: United States of America

  • Favorite Pinball: Alien Star, TNA



Posted 24 April 2017 - 12:59 PM

 

Feature requests:

 

Can you make the Dimensions Manager more useful by having an Apply button, so that you can click on a machine, hit Apply and it sizes the currently open table to those dimensions.  

 

On File, New can it be made to run through a series of dialogs to setup a table, first being the Dimensions Manager that would set the size of your new table, then maybe a table type, em, original ss, or rom controlled that would then load basic templates for each of those types with a bunch of generic parts and appropriate/approximate default physics applied.  And yes a set of template tables would need to be developed or sourced from existing shared ones, because frankly there is not much right about the current default other than having a selection of parts, size is not a standard anything, physics are messed up, etc.

 

Just trying to make it easier for new table builders to get started down the right path.  Nothing more frustrating then seeing someone put in a bunch of work and making something look really nice and it's sized incorrectly so it will never play right.

 

Thanks for all the work guys, some fun stuff going on.

 

If some of you guys would want to help out with that, then this could be a fantastic idea.

The most simple variant to do this (for us) would be that this scheme basically just selects one out of X existing new table templates, so we would need to have these first to do this (e.g. one empty table per proposed template, with the appropriate flipper and playfield settings and a basic script (including all the newskool stuff like DOF/Controller.vbs) in place).

 

Anybody up for this??

 

I know there are a few templates that have been uploaded here (I did at least one of them), and I have an updated version of the Gottlieb EM template that I've developed for my own use that I can contribute to the cause.  I'll spend a day or two and clean it up some and add comments and such to it then update and link it back here.  It does have the basic dof configs as well as some example objects like pops, drops, kicker that are all scripted and working etc.



#242 toxie

toxie

    VPF Veteran

  • VP Dev Team
  • PipPipPipPipPipPip
  • 5,734 posts
  • Location:berlin, germany

  • Flag: Germany

  • Favorite Pinball: AFM

Posted 24 April 2017 - 01:39 PM

 


Hmmm.. Thanks for reporting.. So if i get this right, the autosave being disabled will still trigger a save after ten minutes, but the autosave enabled will trigger a save after the expected/setup time?

Or both variants after 10 minutes??

 

In both cases, automatic save enabled-disable, the table is saved after the expected time.

 
It may be that playing with the backdrop parameters does not activated the autosave,

that is why the previous time I waited an hour and a half before the problem was present,

in the end I went into the editor and the autosave was self- Activated.

 

 

Okay, but this means that the checkbox checked itself basically? Or is it still shown as disabled?



#243 kiwi

kiwi

    Pinball Fan

  • VIP
  • 2,665 posts

  • Flag: Italy

  • Favorite Pinball: Star Trek 25th Anniversary



Posted 24 April 2017 - 02:23 PM

 

 

 


Hmmm.. Thanks for reporting.. So if i get this right, the autosave being disabled will still trigger a save after ten minutes, but the autosave enabled will trigger a save after the expected/setup time?

Or both variants after 10 minutes??

 

In both cases, automatic save enabled-disable, the table is saved after the expected time.

 
It may be that playing with the backdrop parameters does not activated the autosave,

that is why the previous time I waited an hour and a half before the problem was present,

in the end I went into the editor and the autosave was self- Activated.

 

 

Okay, but this means that the checkbox checked itself basically? Or is it still shown as disabled?

 

Is shown as disabled,
when I move an object there is something that activates the autosave countdown.



#244 toxie

toxie

    VPF Veteran

  • VP Dev Team
  • PipPipPipPipPipPip
  • 5,734 posts
  • Location:berlin, germany

  • Flag: Germany

  • Favorite Pinball: AFM

Posted 24 April 2017 - 02:59 PM

Okay, thanks, will look into it!



#245 toxie

toxie

    VPF Veteran

  • VP Dev Team
  • PipPipPipPipPipPip
  • 5,734 posts
  • Location:berlin, germany

  • Flag: Germany

  • Favorite Pinball: AFM

Posted 24 April 2017 - 03:21 PM

I think i found it. Could it be that you entered the editor options dialog before doing the test(s)?

Cause if you enter the dialog to change something (or not) and leave it by pressing OK, then no matter what the autosave option says, it will always enable it.  :/

If you do not enter the dialog before, then everything should be fine (i guess thats why nobody noticed).

Will fix this.



#246 BorgDog

BorgDog

    We come in peace.. shoot to kill.. shoot to kill.

  • Members
  • PipPipPipPip
  • 1,427 posts
  • Location:Leavenworth, WA

  • Flag: United States of America

  • Favorite Pinball: Alien Star, TNA



Posted 24 April 2017 - 08:24 PM

I'm getting an error when I try to set a uservalue for a timer.  Don't know that I've tried using them on timers before, I assume it should work.

 

Error reads:  Type mismatch: 'HStimer'

 

the line in the script is HStimer.uservalue=1



#247 toxie

toxie

    VPF Veteran

  • VP Dev Team
  • PipPipPipPipPipPip
  • 5,734 posts
  • Location:berlin, germany

  • Flag: Germany

  • Favorite Pinball: AFM

Posted 24 April 2017 - 08:56 PM

it's simply called 'user', not 'uservalue', like for all elements..  ;)

 

EDIT: actually not true, only the help for it (e.g. why???).. so i'll check..

 

EDIT2: i just checked, if i for example set a uservalue=1 for the rollingtimer of the default table, it works..


Edited by toxie, 24 April 2017 - 09:13 PM.


#248 fuzzel

fuzzel

    spaghetti code

  • VP Dev Team
  • PipPipPipPipPip
  • 2,818 posts

  • Flag: Germany

  • Favorite Pinball: yes I have

Posted 29 April 2017 - 12:08 PM

rev3056 is up:

 

- document some missing UserValue's and the timer element itself
- fix autosave option if entering/OKing the editor options dialog
- add HasHitEvent and Threshold to the ramp element and the UI
- remove display grid/backdrop from properties (differently exposed in UI nowadays)
 



#249 BorgDog

BorgDog

    We come in peace.. shoot to kill.. shoot to kill.

  • Members
  • PipPipPipPip
  • 1,427 posts
  • Location:Leavenworth, WA

  • Flag: United States of America

  • Favorite Pinball: Alien Star, TNA



Posted 29 April 2017 - 04:39 PM

I'm getting an error when I try to set a uservalue for a timer.  Don't know that I've tried using them on timers before, I assume it should work.

 

Error reads:  Type mismatch: 'HStimer'

 

the line in the script is HStimer.uservalue=1

 

I still get this error setting the uservalue for the timer with rev3056



#250 Slydog43

Slydog43

    Pinball Wizard

  • Platinum Supporter
  • 3,008 posts
  • Location:Hackettstown, NJ

  • Flag: United States of America

  • Favorite Pinball: Addams Family, All Williams 90's Games

Posted 29 April 2017 - 07:08 PM

I tried without error

 

timer1.uservalue = 2
msgbox("Timer1 uservalue = " & timer1.uservalue)


#251 BorgDog

BorgDog

    We come in peace.. shoot to kill.. shoot to kill.

  • Members
  • PipPipPipPip
  • 1,427 posts
  • Location:Leavenworth, WA

  • Flag: United States of America

  • Favorite Pinball: Alien Star, TNA



Posted 29 April 2017 - 07:30 PM

hmmmmm

 

edit: opps, my error, I had forgot to put the _timer in the Sub HStimer_timer line.  Carry-on, as you were, nothing to see here.


Edited by BorgDog, 29 April 2017 - 07:39 PM.


#252 BorgDog

BorgDog

    We come in peace.. shoot to kill.. shoot to kill.

  • Members
  • PipPipPipPip
  • 1,427 posts
  • Location:Leavenworth, WA

  • Flag: United States of America

  • Favorite Pinball: Alien Star, TNA



Posted 29 April 2017 - 09:56 PM

Small feature request.  Can we get an option in Preferences\Editor Options on whether to group elements in collections be default or not?  99.9% of the time I turn that off, and it would be nice if I could just set that preferences.

 

Thanks.


Edited by BorgDog, 29 April 2017 - 09:57 PM.


#253 dark

dark

    3D model-man

  • VIP
  • 1,936 posts
  • Location:Toronto

  • Flag: Canada

  • Favorite Pinball: Star Wars, AbraCadaBra,MB, LAH,JPark...too many to choose!

Contributor

Posted 30 April 2017 - 04:21 PM

I'm wondering if material options could be improved?  Any specular/shine on a material for complex mesh's like toys usually looks like ass and there isn't really much control over it other than just removing glossy and shine all together. (I've played with the material debugger quite extensively.)

 

I know the VP engine isn't on par with 3D software but generally (as seen in 3dsmax) specular level controls how shinny something is, and glossiness controls how focused or spread out that shine is.

 

In this example you can see my Trex update, I have a shininess value of .1 and a clearcoat layer of 1/1/1 color value (almost the lowest value possible) and even with the lowest values the specular highlights look bad on the Trex and the only solution is to remove them altogether:

trexexample.jpg

It's especially evident on the backside of the Trex on the left.  You can imagine how unnatural and bad this would look if it were actually using higher values, meaning there isn't much I can do to have decent looking specular highlights.  In this case I would like the light to hit the surfaces/bumps or the trex so when it rotates back and forth it conveys some level of realistic reaction to lighting, currently this isn't really possible with a complex mesh like this.  Yes using different environment maps can have a dramatic impact on this but then we are catering the env map to specific objects too much.

 

Below is a screen grab of 3 basic materials in max, they are all the same except they have different specular/glossy values:

materials.jpg

Left is a matte finish, low specular, no glossy.  Middle is high gloss (note the smaller circular/focused specular highlight).  The right is high specular with no gloss (note how the specular highlight spreads over the surface of the mesh more).

 

I just find that there isn't a lot of versatility with "glossy layer and clearcoat layers" and they seem kind of counter intuitive when coming from a 3D software.  I think it would be better if it simply had 'specular level' and "glossy level" with value inputs rather than determining glossiness through color values.

 

Basically all the more complicated toys I've made for vpx have had either very little glossy layer (near black value) or none at all, and no clearcoat layer (0,0,0, black) and it kind of sucks for lack of a better term, especially for toys you'd like to see just a bit of light while moving.


Edited by dark, 30 April 2017 - 04:21 PM.


#254 toxie

toxie

    VPF Veteran

  • VP Dev Team
  • PipPipPipPipPipPip
  • 5,734 posts
  • Location:berlin, germany

  • Flag: Germany

  • Favorite Pinball: AFM

Posted 30 April 2017 - 04:57 PM

could you post a sample table with the trex rotating like you want? then i could fool around with the material.



#255 dark

dark

    3D model-man

  • VIP
  • 1,936 posts
  • Location:Toronto

  • Flag: Canada

  • Favorite Pinball: Star Wars, AbraCadaBra,MB, LAH,JPark...too many to choose!

Contributor

Posted 30 April 2017 - 05:06 PM

@Toxie, PM sent.



#256 toxie

toxie

    VPF Veteran

  • VP Dev Team
  • PipPipPipPipPipPip
  • 5,734 posts
  • Location:berlin, germany

  • Flag: Germany

  • Favorite Pinball: AFM

Posted 01 May 2017 - 11:19 AM

as talked about via PM, the next beta will feature an additional material setting that should help this case (e.g. if the scene element's image should be used for glossy or not, or something inbetween, which is especially useful if the image has a lot of dark areas).



#257 flupper1

flupper1

    Enthusiast

  • Members
  • PipPipPip
  • 464 posts
  • Location:Netherlands

  • Flag: Netherlands

  • Favorite Pinball: Visual Pinball

Contributor

Posted 01 May 2017 - 11:49 AM

should be pretty simple, we just need an additional shift of the geometry/cam matrix at the very end of the pipeline (after layback), right?

  

That's exactly the stuff we need to test/experiment with


Any news on this? Or did I overlook that in this thread? Would be great to have!

#258 fuzzel

fuzzel

    spaghetti code

  • VP Dev Team
  • PipPipPipPipPip
  • 2,818 posts

  • Flag: Germany

  • Favorite Pinball: yes I have

Posted 01 May 2017 - 02:23 PM

no not yet.I'm pretty busy with real life stuff so I think you have to wait a bit longer

#259 flupper1

flupper1

    Enthusiast

  • Members
  • PipPipPip
  • 464 posts
  • Location:Netherlands

  • Flag: Netherlands

  • Favorite Pinball: Visual Pinball

Contributor

Posted 01 May 2017 - 05:08 PM

No problem of course, just curious.

#260 fuzzel

fuzzel

    spaghetti code

  • VP Dev Team
  • PipPipPipPipPip
  • 2,818 posts

  • Flag: Germany

  • Favorite Pinball: yes I have

Posted 03 May 2017 - 10:00 PM

rev3067 is up:

 

- update default table to show how to use one-wire ramps as wire guides
- fix one-wire ramp to create proper mesh if control points have a height offset
- add switch to the editor preferences if on new collections 'group elements together' is checked or not.
- add extra setting in material editor to steer how the (optional) image is used for the glossy part of the material (0=no tinting from the image, up to 1=same behavior as with old VPX/10.2)
 

Regarding the one-wire ramp change:

After playing around with a new wire-guide element I found a bug in the wire-ramp mesh creation algorithm. After fixing it you can now use the height offset of the control points to create a wire-guide by using a one-wire ramp. So no need to add another element especially if the code of that new element would be a 100% copy of  the one-wire ramp code ;) I updated the default table and replaced the wire guide primitives with ramps. The way how to create guides that way is not that comfortable but a solution. It needs some time until you find the right height offset and position of the control points to build the rounded start/end part of the guide.