740 replies to this topic

[Umpa]

Why wait let's jump to dx11! Now! Lol

Sent from my SAMSUNG-SM-G935A using Tapatalk

[vogliadicane]

I have some feature proposal, not sure, if others also think it would be helpful.

 

the problem now: if you want to cut out some sector in a light (for a schadow cast from a post or so) you have to:

 

add 4 points each after the other and have to transform each of them to "slingshot" -> 8 steps

not a big deal, if you just want to make one, but usually you have lots of lights and lots of posts and it sums up to a pita

 

my proposal: add option "add 4 slingshot points" this one would be perfect, it would save 7 additional steps

 

as an alternative, maybe easier to implement: add an option "add point (slingshot)" and rename the old one to "add point (smooth)" This would at least save 4 of 8 steps necessary.

 

What do others think?

Edited by vogliadicane, 12 August 2017 - 11:08 AM.

[BorgDog]

I have some feature proposal, not sure, if others also think it would be helpful.

 

the problem now: if you want to cut out some sector in a light (for a schadow cast from a post or so) you have to:

 

add 4 points each after the other and have to transform each of them to "slingshot" -> 8 steps

not a big deal, if you just want to make one, but usually you have lots of lights and lots of posts and it sums up to a pita

 

my proposal: add option "add 4 slingshot points" this one would be perfect, it would save 7 additional steps

 

as an alternative, maybe easier to implement: add an option "add point (slingshot)" and rename the old one to "add point (smooth)" This would at least save 4 of 8 steps necessary.

 

What do others think?

Use F10 to add a "slingshot" point (what does this even mean on a light?) or F11 to add a smooth point when the light is selected and mouse is near where you want the point, very quick and easy to add 4 points, F10, F10, F10, F10

[BorgDog]

feature requests:

 

can you add an Apply button to the Dimensions Manager so when you select something in the manager and hit Apply it applies those dimensions to the current open table? 

can we also get the old scaling method back as an option? maybe list both in the right click menu as say Scale local and Scale Global or something like that, they each have their uses

[vogliadicane]

 

I have some feature proposal, not sure, if others also think it would be helpful.

 

the problem now: if you want to cut out some sector in a light (for a schadow cast from a post or so) you have to:

 

add 4 points each after the other and have to transform each of them to "slingshot" -> 8 steps

not a big deal, if you just want to make one, but usually you have lots of lights and lots of posts and it sums up to a pita

 

my proposal: add option "add 4 slingshot points" this one would be perfect, it would save 7 additional steps

 

as an alternative, maybe easier to implement: add an option "add point (slingshot)" and rename the old one to "add point (smooth)" This would at least save 4 of 8 steps necessary.

 

What do others think?

Use F10 to add a "slingshot" point (what does this even mean on a light?) or F11 to add a smooth point when the light is selected and mouse is near where you want the point, very quick and easy to add 4 points, F10, F10, F10, F10

 

oh didn't know that, cool. A slingshot point delivers hard corners whereas a smooth one, well. But you surely mean, why it is called "slingshot"...

Edited by vogliadicane, 12 August 2017 - 04:49 PM.

[Shockman]

It sounds like you think the points are one or the other, but each is a state that can be either or.

 

You can have sharp corners that are not slings.

 

It's called slingshot because it simulates a solenoid between that and the next point.

[BorgDog]

It sounds like you think the points are one or the other, but each is a state that can be either or.

 

You can have sharp corners that are not slings.

 

It's called slingshot because it simulates a solenoid between that and the next point.

 

we're talking about points on a light object, which you have a choice of slingshot or smooth, which slingshot makes not much sense on a light.

[Shockman]

I see. That is strange they would have that. I wonder if they are actually in line for pre-rendering for the purpose of sling animation.

 

I wonder if this has anything to do with the reflections set causing them to vanish. 

Edited by Shockman, 12 August 2017 - 09:03 PM.

[nFozzy]

The dimensions manager could use another drive for more / better data (wtf is WPC-through-1987? And I suspect most early WPCs are still 20.25" wide, not 100% sure on that though). It's also been mentioned that the unit conversion calculator isn't as accurate as it should be.

[hauntfreaks]

oh holy hell not the reflections again....LOL   

[BorgDog]

The dimensions manager could use another drive for more / better data (wtf is WPC-through-1987? And I suspect most early WPCs are still 20.25" wide, not 100% sure on that though). It's also been mentioned that the unit conversion calculator isn't as accurate as it should be.

 

Have you checked out the 10.4 dimensions manager?  the WPC through 1987 has been eliminated and a few other similar changes as well.  

[Shockman]

oh holy hell not the reflections again....LOL   

 

again is one way of looking at it. not yet is another.

[nFozzy]

I want to talk a bit about Flipper Physics. I've been collecting data on this for awhile and I've come to a couple of conclusions. There are two main issues:

 

1. Flippers are a little slow. But only a little. Flipper rotation should be in the ballpark of 10ms (talking about the reported 'keypress to eos' with the f11 debug stuff open), which is very achievable, especially with a little script to keep the ball speed under control. Seems to track pretty closely to some high framerate video I've collected. EDIT: This is way too quick actually sorry for the bad info

 

2. The flipper trajectory itself. I think this is best explained with pictures. These are from Rothbauer's flipper trajectory table, and I have it set up to shoot balls at an even pace across the flipper's surface.

These are based on tests with a 51 degree rotation Sega/Stern flipper.

First, with some pretty standard VPX flipper settings.

I don't like how clustered together the shots are, and the "center" of these clustered shots is canted too far left. The flipper settings aren't too much help. Abusing friction and/or strength can move the center up a bit. EOStorque/EOSangle abuse can increase polarity, but only by a few degrees at most, and only for the early shots. Could be better.

 

Okay next, this is more or less a mock-up for now, but this is what I'm aiming for

The biggest difference is the general larger angle of shots, a whole 15 degrees of extra shot angle across the same flipper area. Based on the data I've collected, this is pretty close to correct for this era of flipper. The backhands are very sharp, there's a lot of backhand angles that aren't shown because the table can't pick them up. The angles at the end of the flipper are also quite sharp - In the slow motion, you can clearly see the ball get forced off the end of the flipper while it's rotating, and maybe that effect isn't being abstracted in VP10... I think the ball needs to be past the tip where the flipper starts to round out to get those late angles normally. Anyways, the smooth, wide arc of flipper trajectories is the good stuff.

 

So hopefully this demonstrates the limitations of the flipper code, and where it could be improved. Next I'm going to take a look at system 11 flippers and see how the shallow flipper angle affects the shots - already finding the same basic issues though. Probably going to keep developing my script into something more playable.

Edited by nFozzy, 16 August 2017 - 08:40 AM.

[fripounet]

for tv 4k and resolution 3840x2160 possibility interface vp 10.4 , icon 48 and font upper because ==>

[Wizball]

I would like to repeat the request I made in the 10.3 thread - Please add support for adding compressed sound formats to the sound manager, rather than having to use PlayMusic.

[fuzzel]

for tv 4k and resolution 3840x2160 possibility interface vp 10.4 , icon 48 and font upper because ==>

sorry that isn't possible without a complete rework of the UI (AFAIK). The core UI structure wasn't designed with that kind of flexibility.

I would like to repeat the request I made in the 10.3 thread - Please add support for adding compressed sound formats to the sound manager, rather than having to use PlayMusic.

Toxie has this on his to-do list but I don't know if that will be part of the next 10.4

I want to talk a bit about Flipper Physics. I've been collecting data on this for awhile and I've come to a couple of conclusions. There are two main issues:

 

1. Flippers are a little slow. But only a little. Flipper rotation should be in the ballpark of 10ms (talking about the reported 'keypress to eos' with the f11 debug stuff open), which is very achievable, especially with a little script to keep the ball speed under control. Seems to track pretty closely to some high framerate video I've collected.

 

2. The flipper trajectory itself. I think this is best explained with pictures. These are from Rothbauer's flipper trajectory table, and I have it set up to shoot balls at an even pace across the flipper's surface.

These are based on tests with a 51 degree rotation Sega/Stern flipper.

First, with some pretty standard VPX flipper settings.

I don't like how clustered together the shots are, and the "center" of these clustered shots is canted too far left. The flipper settings aren't too much help. Abusing friction and/or strength can move the center up a bit. EOStorque/EOSangle abuse can increase polarity, but only by a few degrees at most, and only for the early shots. Could be better.

 

Okay next, this is more or less a mock-up for now, but this is what I'm aiming for

The biggest difference is the general larger angle of shots, a whole 15 degrees of extra shot angle across the same flipper area. Based on the data I've collected, this is pretty close to correct for this era of flipper. The backhands are very sharp, there's a lot of backhand angles that aren't shown because the table can't pick them up. The angles at the end of the flipper are also quite sharp - In the slow motion, you can clearly see the ball get forced off the end of the flipper while it's rotating, and maybe that effect isn't being abstracted in VP10... I think the ball needs to be past the tip where the flipper starts to round out to get those late angles normally. Anyways, the smooth, wide arc of flipper trajectories is the good stuff.

 

So hopefully this demonstrates the limitations of the flipper code, and where it could be improved. Next I'm going to take a look at system 11 flippers and see how the shallow flipper angle affects the shots - already finding the same basic issues though. Probably going to keep developing my script into something more playable.

I'm not sure if I understood all of that. What kind of improvement to you wish for the flippers? A slight speed-up of the flipper movement? A complete set of different flipper settings to choose from?

[ganjafarmer]

I want to talk a bit about Flipper Physics.

 

What about live catch possibility, it's not easy on real pin but it's possible to learn, practice and make perfect live catch like very fast ball suddenly stops on flipper.

 

I don't understand how it's possible in real life, you hit the flipper to meet the ball at the same time and ball freezies like wtf world physics. Ball should bounce like crazy thinking logic but no, sometimes you got that miraculously live catch.

 

In VPX it's very hard to make perfect live catch, seems like you need more luck then skill.

 

Can't find any video right now but i'm sure you know what is perfect live catch. If i find some good examples i'll post video.

 

What you think about live catch and drop catch in VPX overall?

[jpsalas]

I would like to repeat the request I made in the 10.3 thread - Please add support for adding compressed sound formats to the sound manager, rather than having to use PlayMusic.

 

Yes, that will be really nice, like the ogg format

 

And another thing it will be nice to fix is the crashes in the editor. I get a lot of crashes each time I right click to select something, or left click to select several objects. Those crashes started a few builds before the final 10.3. I guess they are memory leaks, since sometimes I can predict a crash, mostly if a change a ramp type, or a trigger type, and the editor still shows the old type, this is the type of object doesn't change. Then I know it is better to quit the editor and start it again, but this can be another thing and not related to the crashes when clicking or dragging with the mouse

[fuzzel]

 

I would like to repeat the request I made in the 10.3 thread - Please add support for adding compressed sound formats to the sound manager, rather than having to use PlayMusic.

 

Yes, that will be really nice, like the ogg format

 

And another thing it will be nice to fix is the crashes in the editor. I get a lot of crashes each time I right click to select something, or left click to select several objects. Those crashes started a few builds before the final 10.3. I guess they are memory leaks, since sometimes I can predict a crash, mostly if a change a ramp type, or a trigger type, and the editor still shows the old type, this is the type of object doesn't change. Then I know it is better to quit the editor and start it again, but this can be another thing and not related to the crashes when clicking or dragging with the mouse

 

crash dump?

[nFozzy]

So hopefully this demonstrates the limitations of the flipper code, and where it could be improved. Next I'm going to take a look at system 11 flippers and see how the shallow flipper angle affects the shots - already finding the same basic issues though. Probably going to keep developing my script into something more playable.

I'm not sure if I understood all of that. What kind of improvement to you wish for the flippers? A slight speed-up of the flipper movement? A complete set of different flipper settings to choose from?

 

A faster flipper sure, but also the flipper needs to be throwing the ball on a wider strata of trajectories.

 

Currently, increasing flipper speed exacerbates issue #2 though, it trends more ball angles towards this ambiguous center point. This why I've taken to calling it a 'polarity' issue: the rest of the shots are pushed to the polar ends of the flipper bat. So the flipper could be faster, but the ball angles also need to be more evenly spaced across the flipper,