3889 replies to this topic

[KieferSkunk]

One more note on your script there. You specified switches 10, 13, 12, 11 in that order. I suspect that you translated that from a cvpmBallstack, where you specify the entry switch and then the trough switches. In cvpmTrough, .entrySw takes care of the entry switch and .initSwitches specifically only handles the trough switches, starting at the exit and going backward. I suspect that in that script snippet, you want:

.entrySw = 10
.initSwitches Array(13, 12, 11)

[hmueck]

Hmueck: both .size and .entrysw are properties. You call them as

Thank you! Me and my cold didn't think of that.

[BananaBoat]

Guys been away for a while and without reading all 119 pages, can someone kindly summarise the current status of this project and what remains outstanding after 5 months?

Thanks!

Sent from my HTC_0P6B using Tapatalk

[freneticamnesic]

current status: beta

woot

but, potentially less beta than before?

[fuzzel]

Yes I would say we're moving towards the gamma phase if at all. I don't know if we really need another pre release phase. Again I can tell you when we will release the official 10.0 but it's going to happen this year for sure

[Trinity]

Just say December 31st, 2015.   That way any sooner is a pleasant surprise   < cept happier.

[toxie]

The 'problem' is that there is always stuff left to do, so the classical feature creep..

 

Talking about that, upcoming are some nice improvements and fixes for the ramps.. 

[fuzzel]

rev2087 is up:

 

- ramps can now in addition use the height parameter of their control points (its used as an offset in addition to the normal ramp behavior)

  For instance: you define a ramp with botton/top height 100 for additional control points the height offset is 0 so it's on the same height. If you set it to -20 the control point is then on height 80, if you set it to 40 the actual height is 140 and so on.

- kicker is in legacy mode as default setting. The new physics seems to have an issue if the ball comes straight from the top or from the left side towards the kicker. If that's the case the velocity of the ball becomes zero very fast. The reason for this is unclear at the moment so you have to test this if it works on your table.

- smooth normals for rubbers
- finally fix whacky ramp normals
- code cleanups
- ball spin issue solved
 

[toxie]

this changes the look of classical/transparent ramps dramatically, but it had to be finally done right, as the old ramps just did 'something' for the lighting.

 

and also rubbers won't show facets anymore (i hope).

[hmueck]

I panicked for a second when i tried my wonky test table and the balls kept sliding into each other.

Quick version check: rev.2044??

Then i noticed: the archive contained vpinballX.exe and vpinball.exe. vpinball.exe is the new rev.2087

P.S. i'm not sure what you mean with "ball spin issue solved", but on my wonky test table there seems to be no change since last beta.

[fuzzel]

Ups thanks hmueck for the hint. First post is updated and contains only vpinballx.exe (rev2087).

 

the spin killing is a hack to compensate the heavy spinning when the ball doesn't move. It's an improved version so maybe not completely solved

[unclewilly]

Haven't had much time for testing.
1 question, do the ramps expirt as obj when you do a full table export?

[hmueck]

I think everything is one big obj when you export the table.

[fuzzel]

No every element is a single obj or consist of multiple objs like bumpers for example.

[hmueck]

i think i mix up "obj file" and "objects in blender".

[nFozzy]

- ramps can now in addition use the height parameter of their control points (its used as an offset in addition to the normal ramp behavior)

  For instance: you define a ramp with botton/top height 100 for additional control points the height offset is 0 so it's on the same height. If you set it to -20 the control point is then on height 80, if you set it to 40 the actual height is 140 and so on.

Was this not working before?

[fuzzel]

No

[unclewilly]

One other question on the ramps.
so the end points can't be off set

So for example a ramp similar to the slopy ramp in white water. You would have say 0 as the start and say 60 as the end and just off set all the slopes?

Also, in between each point would be a flat section so essentially you could make a curved ramp like the one in fire by using a lot of affset points.

I guess what I'm really asking is.
say you have the base ramp set at 0 and 60
is the off set from whatever the heught is of that ramp at the place you add the point or do you need to always start with a flat ramp say 60 and 60 and offset from there?

And will the ramps export with the table as a mesh?

[fuzzel]

I guess what I'm really asking is.
say you have the base ramp set at 0 and 60
is the off set from whatever the heught is of that ramp at the place you add the point or do you need to always start with a flat ramp say 60 and 60 and offset from there?

And will the ramps export with the table as a mesh?

Yes the offset is relative to the current height. So if you have a sloped ramp and add multiple control points on it you have to tweak each height, it's not limited to flat ramps. You can even apply that on wire ramps too.

And yes the ramp will be exported as a mesh but it needs fine tuning before you reimport it into VP again.

Edited by fuzzel, 25 June 2015 - 10:55 AM.

[fuzzel]

I've just made some quick tests with the new height offsets of the ramp control points but I think it should be possible to create wire guides with this feature. You have to use a one-wire ramp and at least 2 additional control points at the beginning and end of the ramp. It's a bit tricky because if the control points are too close to each other and the height offset is different the ramp will look weird in the editor. This might need a bit more optimization but it's a start.