616 replies to this topic

[toxie]

Here an example what the new material option does (only useful if an object has an image attached). The old behavior (option = 1) will use the image also for the glossy part of the materials, using the new behavior (option = 0, but can be set anywhere 0..1) will not use the image and can look more natural, depending on the usecase.

Attached Files

•  NoImage.jpg   92.85KB   38 downloads
•  UseImage.jpg   93.47KB   37 downloads

[toxie]

i just saw that my backwards compatible loading of materials is actually not working like intended.  :/

so i have to unfortunately increase the file version, so that old/new tables can be detected on loading, otherwise the new parameter can be garbage when old tables are loaded (e.g. tables will look different than in 10.2 then).

sorry for the inconvenience!!

[kiwi]

Normally, the autosave works, depending on how it is set in the editor options,
If I enable the autosave and return to the editor, and then return to options to disable the autosave,

the table, however, once is self-saved.

[TerryRed]

i just saw that my backwards compatible loading of materials is actually not working like intended.  :/

so i have to unfortunately increase the file version, so that old/new tables can be detected on loading, otherwise the new parameter can be garbage when old tables are loaded (e.g. tables will look different than in 10.2 then).

sorry for the inconvenience!!

 

I don't know if this relates to what you are talking about....

 

...but I noticed that 10.3 has issues with some tables. Attack From Mars for example has some VERY bright lighting issues, and other tables seem to have parts of it that are washed out looking. If I go back to 10.21, these tables all look fine.

[hanzoverfist]

I don't know if this relates to what you are talking about....

 

...but I noticed that 10.3 has issues with some tables. Attack From Mars for example has some VERY bright lighting issues, and other tables seem to have parts of it that are washed out looking. If I go back to 10.21, these tables all look fine.

 

 

That is an issue with SolMod lighting vs. normal Sol. SolMod is supposed to give a range of values 0-255 but in some combinations of vpinball and vpinmame you only get 0 and 1's as vanilla Sol does and that is the core of the problem. I don't know the full historic behind it's development, but some versions of vpinmame.dll as well as vpinballx.exe are affected when combined, in other words you need the right version of vpinmame and vpinball for it to work correctly. This problem affected all my FSS tables as I was using an older version of vpinmame and a new version of vpinball, the best and only solution is to upgrade everything (vpinmame and vpinballx), and get corrected version of those tables. But if that is not feasible, then you will need to stick with the working versions you currently have.

Edited by hanzoverfist, 08 May 2017 - 01:15 PM.

[TerryRed]

 

I don't know if this relates to what you are talking about....

 

...but I noticed that 10.3 has issues with some tables. Attack From Mars for example has some VERY bright lighting issues, and other tables seem to have parts of it that are washed out looking. If I go back to 10.21, these tables all look fine.

 

 

That is an issue with SolMod lighting vs. normal Sol. SolMod is supposed to give a range of values 0-255 but in some combinations of vpinball and vpinmame you only get 0 and 1's as vanilla Sol does and that is the core of the problem. I don't know the full historic behind it's development, but some versions of vpinmame.dll as well as vpinballx.exe are affected when combined, in other words you need the right version of vpinmame and vpinball for it to work correctly. This problem affected all my FSS tables as I was using an older version of vpinmame and a new version of vpinball, the best and only solution is to upgrade everything (vpinmame and vpinballx), and get corrected version of those tables. But if that is not feasible, then you will need to stick with the working versions you currently have.

 

 

I just want to confirm.... are you talking about "real" lighting in a pinball cabinet, or in the VPX table itself?   

 

I was talking about the lighting (and other things) on the vpx table itself looking way too bright or washed out... not real pinball cabinet lighting.

 

I had the newest VPX 10.3, newest pinmame, newest B2S server, etc....

 

Just wondering if anyone else was seeing this? Hopefully this won't require alot of tables to be updated?

[hanzoverfist]

 

 

I don't know if this relates to what you are talking about....

 

...but I noticed that 10.3 has issues with some tables. Attack From Mars for example has some VERY bright lighting issues, and other tables seem to have parts of it that are washed out looking. If I go back to 10.21, these tables all look fine.

 

 

That is an issue with SolMod lighting vs. normal Sol. SolMod is supposed to give a range of values 0-255 but in some combinations of vpinball and vpinmame you only get 0 and 1's as vanilla Sol does and that is the core of the problem. I don't know the full historic behind it's development, but some versions of vpinmame.dll as well as vpinballx.exe are affected when combined, in other words you need the right version of vpinmame and vpinball for it to work correctly. This problem affected all my FSS tables as I was using an older version of vpinmame and a new version of vpinball, the best and only solution is to upgrade everything (vpinmame and vpinballx), and get corrected version of those tables. But if that is not feasible, then you will need to stick with the working versions you currently have.

 

 

I just want to confirm.... are you talking about "real" lighting in a pinball cabinet, or in the VPX table itself?   

 

I was talking about the lighting (and other things) on the vpx table itself looking way too bright or washed out... not real pinball cabinet lighting.

 

I had the newest VPX 10.3, newest pinmame, newest B2S server, etc....

 

Just wondering if anyone else was seeing this? Hopefully this won't require alot of tables to be updated?

 

 

yes this is about lighting issues in visual pinball and vpinmame. in a cab, desktop etc.. does not matter. unfortunately if the table was made using those conflicting versions of vpinmame or vpinball, the table will also be affected by the problem.  so as I said you need the latest exe/dll and also the affected table needs modification.

 

BTW: can you PM me a pic ... just curious too see what you are experiencing,I know what you are seeing but I don't know if its different for different setups.

Edited by hanzoverfist, 08 May 2017 - 11:20 PM.

[GreenKnight]

Interestingly, the latest beta (3067) has fixed a display problem I was having with beta 3031 on the recent update to Funhouse (V1.3) in that the table would not "size" correctly on the DT screen no matter what I did with the table display settings (Inclination etc.).

 

Now it displays perfectly.

 

Thanks guys!

[toxie]

Normally, the autosave works, depending on how it is set in the editor options,
If I enable the autosave and return to the editor, and then return to options to disable the autosave,

the table, however, once is self-saved.

 

is this still the case with rev 3056 and up? cause i think i fixed exactly that..

Edited by toxie, 13 May 2017 - 03:40 PM.

[toxie]

 

i just saw that my backwards compatible loading of materials is actually not working like intended.  :/

so i have to unfortunately increase the file version, so that old/new tables can be detected on loading, otherwise the new parameter can be garbage when old tables are loaded (e.g. tables will look different than in 10.2 then).

sorry for the inconvenience!!

 

I don't know if this relates to what you are talking about....

 

...but I noticed that 10.3 has issues with some tables. Attack From Mars for example has some VERY bright lighting issues, and other tables seem to have parts of it that are washed out looking. If I go back to 10.21, these tables all look fine.

 

 

if you use a very recent build (e.g. rev 3067) then this could be the case due to the new material setting.. rev 3068 will then fix this in this case..

[kiwi]

 

Normally, the autosave works, depending on how it is set in the editor options,
If I enable the autosave and return to the editor, and then return to options to disable the autosave,

the table, however, once is self-saved.

 

is this still the case with rev 3056 and up? cause i think i fixed exactly that..

 

This behavior is related to revision 3067.

[toxie]

Hmmm.. Damn.. That whole autosave stuff is very weird.. :/

Thanks for the bug report!

[flupper1]

Concerning replace (or enable not using) layback, I have some new info:

I think I have tricked 10.2 into doing this, maybe this will help implement this more easily (as my trick is a workaround). The results:

 

With these settings:

 

What I did was doubling the table height. For that to work the playfield image and all images which rely on full table scaling, need to be doubled in height as well (this is the tradeoff, for White water the playfield was 1864x4096, now it is 1864x8192 pixels, with a lot of nothing for half the image, so it does not increase the size much).

This still positions the camera still directly above the middle of the playfield, but with my workaround, only the upper half of the "playfield" has stuff on it. This makes it possible to set layback to "0" for FS. I tested a lot with different values for the other settings and the ones above seem satisfactory to me. 

 

The settings for DT need to be tweaked as well, but it can be made to work (see the settings above):

 

Benefits of this:

- no layback for FS. See my earlier posts where it is explained some more what layback is. It is not perspectively correct, so no layback is better I think.

- side effect seems to be that I can put X scale and Y scale to the same value, did not expect that to happen but is sure nice.

- for me especially: this enables easy rendering of textures in Blender for transparent ramps, since the ramps do not have to be adjusted for layback.

[fuzzel]

Yes layback is evil add it screws the complete scene. I've finally found out what the shift values are for in blender. As blender doesn't use a camera with a classic look-at or camera target vector the shift values are used to a shift this target in the x and y direction. So basically the whole camera calculation is already in VP but disabled at the moment. The biggest work for using the new calculation is to add a switch into VP and to change all areas where you can manipulate the classic camera settings so it will work with the new one. I don't have much time at the moment so that must wait a bit longer I guess...

[Ben Logan]

Side note: Amazing screenshots of Whitewater WIP. Go, Flupper!

[kiwi]

The Reference Command file does not say anything about the kicker variable "Hit Height",
I was interested in knowing whether this parameter can be modified by script.

 

Thanks

[toxie]

Unfortunately not, as its part of all the static physics elements that feature a pre-calculated acceleration hierarchy.

[kiwi]

Thank you for the information.

[fuzzel]

rev3069 is up:

- add hitheight for kicker to the CommandReference.txt
- increase file version to be able to detect version 10.2 (and below) tables/materials for full backwards compatible material loading
 

[toxie]

Thanks! This should now be all 'safe' to use again and fully compatible to load/play 10.X tables, etc. The only caveat is that tables saved with that new 10.3 revision will not be loadable with 10.2 then, due to the new material parameter.  :/