1488 replies to this topic

[Pin-Pete]

Do you really run two anti virus systems in parallel? no wonder you have input lag.

That did the trick. Got rid of AVG, which was the culprit. Now everything Works nice and smooth.

[sniiki]

About analog nudging and simulated bob.

 

There's this long discussion mostly between me and Thalamus about an extra nudge I was experiencing every time the sim bob triggers.

https://www.vpforums...ic=33287&page=3

 

Several times I thought I've found a fix but then soon noticed it's still there. I had no issues with real bob or sending tilt with Mechanical Tilt key [T] so it was really frustrating as I found no other discussion about the topic except for something similar mentioned in VR thread and therefore obviously thought it was something in my setup.

I then finally took a look in source and found that in pininput.cpp (line 827 in r3746) it was sending 'eCenterTiltKey' when the bob triggers which seemed strange. I replaced it with 'eMechanicalTilt' and it seemes to have fixed the issue.

 

Here's a video showing what I mean. First a test with r3746. ~0:20 you can see this extra nudge bouncing the ball all over. Later in the video another few tries with the mentioned mod and the ball stays cool.

https://youtu.be/_RujVX3-N_I

 

P.S.

Thanks Rob for helping me out. Had some trouble getting the source to build and started messing with cmake which Rob told was deprecated and told it should build fine directly in VS.
I was trying to build latest r3750 but it crashed everytime during table launch. Then thought to try with r3746 which worked without issues.
I used DX SDK 2009 (Aug). Not sure if it makes any different whether I use that or 2010 (Jul)?

Edited by sniiki, 16 July 2019 - 06:47 PM.

[kiwi]

 and position surface for targets possible ?

I normally have the targets positioned not on the table field, but always a little lower,

in my opinion it is better to set the Z position, instead of selecting a surface, or/and add a wall where to place the targets.

[wrd1972]

Toxie, Fuzzel,

Can a "selectable" feature be added to the "backdrop" propoerties/options, that would link x-scale and y-scale together? So that when one scale is adjusted, the other scale adjusts in the same amount? I am wanting this to more quickly and accurately be able to set table backdrop, and maintain as close to 1:1 scale as possible.

 

Again this would be selectable by way of a "button" or similar.

 

Thanks

[fuzzel]

Hm very special option. So when you have pressed that button the value for one scale axis is automatically set to the other one?

Gesendet von meinem SM-T320 mit Tapatalk

[wrd1972]

Precisely. The X-scale and y-scale would increase/simultaneously. My idea is to use this feature to rough in the size of the table to the screen and maintain 1:1 as much as possible. Then turn the option off and adjust y-scale as needed to fill more of the screen.

 

Come to think of it. If the X/Y (together) scale adjustment were simply added as another adjustment aid to the menu when in camera mode, that would be the most useful solution.

 

Make sense?

[fuzzel]

Ah now it make sense you want that option in the camera mode ok. I think that's not a big issue. I would simply add another adjustment option.

Gesendet von meinem SM-T320 mit Tapatalk

[vogliadicane]

I had the problem with the new Time Warp (Bord) that the playfield looked much too dark. Because I was on an older beta rev I updated to 3746.

Ok the problem for Time Warp was solved, but e.g. for TAF (g5k) I had the opposit, playfield much too bright (see image)

I guess I could solve it for TAF by disable lighting for the playfield mesh. What would you suggest? Change it for all tables affected? Or consider it a bug and wait until VPX in this point is again backwards compatible? (yes, suggestive question)

 

[fuzzel]

rev3751 is up:

 

- add x/y scale support to the camera mode to scale x/y axis at the same time
- use real upper border for temp vertex alloc, as some .obj feature a combination of different v/vt/vn combinations for the face indices
- fix loading error for extremely old (Tech Beta 3, etc) tables and fix (most likely completely unused nowadays) font import/tableload issue
 

Edited by fuzzel, 18 July 2019 - 09:47 AM.

[wrd1972]

Fuzzel,

The new feature to adjust x-scale and Y-scale simultaneously is utterly fantastic! It is much faster to dial in backdrops and maintain as much of a 1:1 scale as possible. I simply go to the backdrop settings of a table, and manually set X-scale and y-scale to 1 and 1, then use the X/Y scaling to expand the table to fit the display on the y-scale. Then add just a touch more x-scale to fill the display...but not too much. Now I have to go through all 250+ of my tables and tweak backdrops again. LOL

 

I hope others try this out and find it as useful as I do. My tables are now much more uniform in scale, than before. You guys absolutely freaking rock!

 

Many thanks.

B

 

 

[Dexjee]

I had the problem with the new Time Warp (Bord) that the playfield looked much too dark. Because I was on an older beta rev I updated to 3746.

Ok the problem for Time Warp was solved, but e.g. for TAF (g5k) I had the opposit, playfield much too bright (see image)

I guess I could solve it for TAF by disable lighting for the playfield mesh. What would you suggest? Change it for all tables affected? Or consider it a bug and wait until VPX in this point is again backwards compatible? (yes, suggestive question)

i have noticed this too. setting the lighting to 0 indeed fixes it. do we loose anything by disabling the playfield mesh lighting?

Edited by Dexjee, 20 July 2019 - 09:49 AM.

[racer7c]

What lighting setting did you change?  I'm having the same really bright problem.

Edited by racer7c, 20 July 2019 - 07:42 PM.

[Dexjee]

What lighting setting did you change?  I'm having the same really bright problem.

switch to layer 8 of the table and edit the playfield mesh - there is a lighting option which i set to 0.

[Schlabber34]

Setting the "disable lighting" to 1 disables the VPX lighting on the mesh. TAF was made before that feature was available for the playfield_mesh. So zero should be correct! The higher value must have been there because the prim import standard was set to 1 for the DL feature and the guys didn't care because it had no effect at that time.

Gesendet von meinem SM-G955F mit Tapatalk

[Dexjee]

Setting the "disable lighting" to 1 disables the VPX lighting on the mesh. TAF was made before that feature was available for the playfield_mesh. So zero should be correct! The higher value must have been there because the prim import standard was set to 1 for the DL feature and the guys didn't care because it had no effect at that time.

Gesendet von meinem SM-G955F mit Tapatalk

thanks for the explanation.

 

does anyone know if any table actually uses that setting atm? if not i would go ahead and change it in all my 10.6 tables..

Edited by Dexjee, 24 July 2019 - 02:22 PM.

[rothbauerw]

I'm seeing a bug with ramps.  I first saw this on Indy 500 and thought it was weird, couldn't explain it and didn't see it anywhere else.  Well, I'm seeing another example of it. 
 
For long ramp sections, the right hand wall becomes noncollidable.  The ball can pass right through it.  See red arrow on the right.  Easiest to test this with manual ball control, sliding the ball up the right hand side of the ramp.
 
In addition, the ball won't pass under the ramp from left to right.  See red arrow on the left.  
 

 
Test table in the dropbox link attached.
 
https://www.dropbox....mptest.zip?dl=0

Edited by rothbauerw, 25 July 2019 - 01:36 AM.

[LynnInDenver]

I played with it myself. Confirmed, plus left to right movement at the very bottom of the ramp, you can cross the "wall" of the ramp quite easily, yet right to left movement you can't "enter" the ramp or "leave" the ramp except via the expected route.. Reducing the end height to 100 appears to deaden the effect considerably, although it then manifests some odd "ball jump" behavior trying to slide the ball under, causing the ball to rocket over to the point it can actually pass under. Adding additional ramps as walls doesn't change what happens. Reversing the ramp direction (top at 0, bottom at 185) keeps the ramp from corralling the ball at all.

Edited by LynnInDenver, 25 July 2019 - 01:59 AM.

[rothbauerw]

Good finds Lynn.  Interestingly, adding more points to the ramp make all of these issues go away 

[LynnInDenver]

Good finds Lynn.  Interestingly, adding more points to the ramp make all of these issues go away 

 

I suspect it's in part because the ramp object is rarely used, if at all, for long straight stretches like that, and it's usually hemmed in by objects that are not ramps, and nowhere for the ball to pass under it, when it is. Or there's additional points to help massage the ramp slope. It's basically an extreme edge case you set up there, not that it's a bad idea for testing purposes to try the edge cases.

[STV]

This "through wall" phenomenon mirrors somewhat other "odd" in-play things I've seen recently.   Actually thought it might be balls bouncing over things they never used to in the vpx world and mappers didn't in the past have to accommodate for that...  Curious indeed...