1394 replies to this topic

[Aaron James]

Forgive me if this has been addressed already, but when I try to play JP's taxi with the latest rev updated yesterday,
I get this error:
When I go back to 628, the error disappears.
Just wanted to let you guys know.
There seems to be some problem with the plunger script.
I changed taxis plunger over to koadics plunger and the problem was resolved.

Attached Files

•  image.jpg   144.12KB   16 downloads

[jpsalas]

Forgive me if this has been addressed already, but when I try to play JP's taxi with the latest rev updated yesterday,
I get this error:
When I go back to 628, the error disappears.
Just wanted to let you guys know.
There seems to be some problem with the plunger script.
I changed taxis plunger over to koadics plunger and the problem was resolved.

I haven't updated the table, but the last version I have, version 2.1.2, works fine.

[toxie]

Toxie / Fuzzel, will the move to DX9 allow us to do other things like potentially add ball spin physics?  Or is any physics element totally separate from the DX9 work / rendering engine build?  Even if it's totally separate, does going to DX9 at least open the door for physics changes that may one day include some detection / calculation for ball spin? 

 

Alternatively, do you think there would ever be a way of assessing / facilitating some type of ball spin in VP's current realm / state considering that it seems it actually happens to some degree graphically at least regarding the ball decals.   You can occasionally see the ball travelling normally / straight along a vector, but the decal will be spinning around an apparent other axis than the ball is travelling.  I was wondering if we could capture that data somehow that's spinning the graphic for the decal and utilize it to actually affect the physics of the ball from the rotational elements being applied to the decal rendering. 

 

Physics are completely decoupled from the rendering, so adding this would work, but apart from the basic physics and the rough simulation structure i also don't know -that- much about this code.

[Aaron James]

Forgive me if this has been addressed already, but when I try to play JP's taxi with the latest rev updated yesterday,
I get this error:
When I go back to 628, the error disappears.
Just wanted to let you guys know.
There seems to be some problem with the plunger script.
I changed taxis plunger over to koadics plunger and the problem was resolved.

I haven't updated the table, but the last version I have, version 2.1.2, works fine.

I forgot to say that it only happens when trying to launch the table In Hyperpin.
In the normal editor it works fine with the latest revision. Strange I know.

[tttttwii]

As there are for VP9.15 two versions one with and one without virtual plunger support, I would like to know if this beta is supporting virtual punger or not.

My virtual plunger has just arrived and I want to install it this weekend.

[Slydog43]

Latest nightly's support the virtual plunger just fine.

[kenrunio]

While I'm not getting any script error with Taxi, the plunger itself is not animating properly on that particular table - it moves down very slightly part of the way and then just stops. 

 

Just double checked - its actually not an error specific to the new versions of VP- its related to the fact that I am using an accelerometer for nudge but a regular switch for the launching the ball. 

Edited by kenrunio, 25 September 2013 - 08:17 AM.

[jimmyfingers]

A couple bugs discovered with the "Enable Lighting" option on wall objects:

 

1) Disabling the "Enable Lighting" option on one of two identical / copied wall objects leads to what one would expect, with the one having the option on being darker and similar to the other table objects with it on, and the one with it off having no lighting applied and being a lighter colour.  However, doing the same on a wall object with a texture applied leads to actually a darker object instead of a lighter / original lighting object for the texture.  It seems that the behaviour should be the same as the non-textured walls without the option selection and some textures would be very nice to have shown "as is" without the table attempting to do lighting which affects the wall texture / graphic in different rotations / positions. See below:

 

 Capture of Lighting Enabled Bug.PNG   212.99KB   21 downloads

 

2) On the most recent revision and seemingly all versions after somewhere around rev588, if you run the simple test table attached below, exit, then click on the right basic wall object with "Enable Lighting" not selected, then change it to being selected / on, a subsequent running of the table will produce this result and / or crash.  It may also wait to crash until attempting to exit the table.  See below

 

 Capture of Lighting Toggle Bug.PNG   215.19KB   12 downloads

 

I've attached a simple test table, used for the captures above, so hopefully you guys (Toxie / fuzzel) can verify and reproduce both the crash / graphical glitch and the wrong - darker instead of lighter / original - lighting being applied to the texture mapped example wall(s).  Thanks and hopefully this is something easy to fix. 

Attached Files

•  Lighting Bug Test Table.vpt   112KB   5 downloads

Edited by jimmyfingers, 28 September 2013 - 02:07 AM.

[fuzzel]

Thanks Jimmy, I'll have a look into this

[jpsalas]

The first revision that gives me an error and VP quits is rev599

[jimmyfingers]

Hey Toxie / fuzzel, one other thing "lighting" related that was discussed way back but never implemented was allowing for the option to also disable the lighting on the "off image" of a light object due to the way that most tables have fading lights implemented.  This was discussed at some length back around pages 8-9 of this topic culminating in post #169 / #170 where it was just agreed that adding the same disable lighting option for the off image, as already exists / implemented on light objects for the on image, be also included. 

 

I've seen some pretty cool results with the new light source options on a couple test tables but can't really use / release any of it until we get this one detail resolved so that it doesn't throw off the fading lights routine.  Figured that we should get some of these bugs and aspects out there / revisited as you may be getting close to an official release.  Thanks again for all your work and willingness to get these features and bugs sorted. 

Edited by jimmyfingers, 28 September 2013 - 07:11 PM.

[ICPjuggla]

fuzzel, I was wondering if you had time to look at this as well? I downloaded the latest rev and noticed the drawing order box is still in the way.. No rush was just wondering if it will be fixed/moved some time in the near future.?


fuzzel, is it possible to move the Drawing order box to a different location?

It was much nicer to be able to see colors & formatting and position at the same time wile building, it saves some clicking and time during the building process.. :-)

[fuzzel]

I will change the drawing order in one of the next revisions. I think I will make a new drawing order dialog and remove the old one to save some space in the options.

[ICPjuggla]

I will change the drawing order in one of the next revisions. I think I will make a new drawing order dialog and remove the old one to save some space in the options.

 

Thank you kind sir :-)

[fuzzel]

Rev 674 fixes the enable/disable lighting crash bug. For the rest I need a bit more time...

[fuzzel]

A couple bugs discovered with the "Enable Lighting" option on wall objects:

 

1) Disabling the "Enable Lighting" option on one of two identical / copied wall objects leads to what one would expect, with the one having the option on being darker and similar to the other table objects with it on, and the one with it off having no lighting applied and being a lighter colour.  However, doing the same on a wall object with a texture applied leads to actually a darker object instead of a lighter / original lighting object for the texture.  It seems that the behaviour should be the same as the non-textured walls without the option selection and some textures would be very nice to have shown "as is" without the table attempting to do lighting which affects the wall texture / graphic in different rotations / positions. See below:

 

Capture of Lighting Enabled Bug.PNG

 

Ok I checked the code and it's not a bug it's a feature

Keep in mind that even for a textured wall without lighting the top and sidecolor is used to color the texture. This feature isn't used if you enable lighting because a static light map is used and the result would be a really dark textured wall.

If you set the the top/side color to white and disable the lighting you will get the original texture.

[fuzzel]

Please try rev 675! I moved the drawing order option to a separate dialog.
You can access the dialog by right clicking an element and select "Drawing Order" or by hotkey Ctrl+Shift+D.

Maybe you didn't notice it: you can select an element and press the context menu key on the keyboard( the key between the left windows and control key).
Doing that the normal context menu will show up no matter if the mouse is over the element or not. The context menu that pops up belongs to the selected element. This is helpful if you selected multiple elements and you want to e.g. scale those elements.
You don't have to select the menu items with the mouse, instead you can press the desired key:
X = Flip X
Y = Flip Y
R = Rotate
S = Scale
T = Transform
P = Add Point (Walls, Ramps)
D = Drawing Order
F = Draw in Front
B = Draw In Back
A = opens the Assign to sub menu (1-8 stands for layer 1-8)
L = Lock toggling

Hope that helps

[jimmyfingers]

Ok I checked the code and it's not a bug it's a feature

Keep in mind that even for a textured wall without lighting the top and sidecolor is used to color the texture. This feature isn't used if you enable lighting because a static light map is used and the result would be a really dark textured wall.

If you set the the top/side color to white and disable the lighting you will get the original texture.

 

Thanks for the explanation and instruction / clarification on getting the equivalent of no lighting / texture tinting for wall objects - I gave your suggestions a spin (setting the side colour to pure white) and it worked great!  That's good to know and is kinda a feature I suppose as one can use the knowledge that with lighting off and side and top colours intentionally set, that options become available to manipulate the textures somewhat internal to VP.  This could be nice so that further graphical program editing may not be required or additional textures for some things may not be needed as a drop wall could simply manipulate and colour the texture.  I see that at least possibly useful for GI on / off events for some drop wall objects where the same texture could be used but with just the colour being a little darker on the wall's visible side and / or top.  Using the same texture and just the wall colour options to tint might even save video memory - maybe you could confirm if that would be the case as you know obviously the nuts and bolts of a lot of VP's inner workings.

 

Thanks again and the only thing left regarding the enable lighting aspects is now getting that option to disable it for the off image on the light objects.

Edited by jimmyfingers, 30 September 2013 - 05:04 PM.

[fuzzel]

Please check out rev 677. I added another checkbox to the lights settings where you can disable the lighting for the off image too.

[unclewilly]

Sorry for all the primitive questions.

If you have a primitive but it is sitting below the Playfield. Is it still rendered and does it still have a hit on the fps