3889 replies to this topic

[Jafjas]

Hmmmm I just did a clean instal and now everything is working again.
I think I'm happy again after spending to much time trying to find the solution and solving this the hard way in the end.

Thanx freneticamnesic for responding so fast, ps. love the amazing AMH table you and Shoopity made!

Jasper

[Sindbad]

Here's a new version (version 20150722) of Victory: https://drive.google...V091alNJNndKcWM

 

- fixed ball stuck at upper ramp by removing all mistakenly set height offsets on all ramps

- some small fixes

 

Table was built and tested under rev. 2112.

 

 

Presently, I don't find much time, so it'll take some time to correct or fix any of my test tables. I'm sorry for that, but real life comes always first... Nevertheless the FS version of JP and LW's Legend of Zelda table is more or less ready for testing. I only want to wait until UltraDMD is stable before posting the link to the table here. If you can't wait any longer, send me a PM and I'll send you the link.

 

Edit:

Arghhh, wrong thread, Sorry!

Edited by Sindbad, 12 July 2015 - 08:41 PM.

[freneticamnesic]

I just had an idea...I hope it makes sense:

In the same way that walls "Can Drop" it would be great to have a similar toggle for primitives that are marked "Is Toy"

The idea is, most moving primitives have 1 rotation point, ie. open or closed, left or right, make sense? There's a lot of ways to script this, and it can take some time fine tuning, but it's such a simple idea, I believe it could be handled in the editor.When you click "Is Toy" it brings up rotation options, which are the objrotx/transx/rotx options we already have, but there's 2 boxes. The left would be "Open" or something, what you'd call it probably makes more sense.. Off? It's usually tied to a solenoid, so off/on would make some sense? and you'd enter the values. If it was like a box that opens and closes, you could have ObjRotZ 0 for Off, and ObjRotZ 90 for On, and then in the script, rather than scripting all this movement, you could just say "Primitive.State = Off" and at the same time you'd probably need to add a timer to primitives so you could have a way to adjust speed.

 

Obviously there will be a lot of instances where this just doesn't make sense, like a varitarget or something with multiple positions, but for a majority of things it would be very useful. Think of drop targets, currently there's at least 3 pretty solid ways to script their movement. This could reduce it to 1 universal way. And you could still script the old way if needed...

[freneticamnesic]

when did BMP image format stop working?

[toxie]

what happens? crash? or what?

[hmueck]

when did BMP image format stop working?

What's BMP? Something like .iff for my Amiga or .pcx for my Win3.0 PC?


Kidding aside, bmp works fine for me as a playfield in rev.2112:


Maybe the name contains stuff VP doesn't like? ([,],-, ,......)?

[freneticamnesic]

Just trying it on primitives

The primitive on the left has a bmp

the primitive on the right has a jpg, which is just the bmp re-saved

Identical primitive proprties:

 

In the game:

[toxie]

does the bmp have an alpha channel set?

[fuzzel]

Just a small teaser for a new upcoming feature in VPX. In the near future it is possible that elements will reflect on the playfield. At the moment only static elements are mirrored and the look isn't too natural yet (it's more like a 100% mirror) but I'm working on that Here are some screenshots how it's looking at the moment. More informations later...

Attached Files

•  reflection1.jpg   219.59KB   25 downloads
•  reflection2.jpg   186.78KB   19 downloads
•  reflection3.jpg   227.33KB   17 downloads

[toxie]

We could just blur it maybe to make it a bit less dominant?

[fuzzel]

why not

[freneticamnesic]

Just a small teaser for a new upcoming feature in VPX. In the near future it is possible that elements will reflect on the playfield. At the moment only static elements are mirrored and the look isn't too natural yet (it's more like a 100% mirror) but I'm working on that Here are some screenshots how it's looking at the moment. More informations later...

 

ah this will royally bone AMH ...I spent so much time!

does the bmp have an alpha channel set?

whatever is default I guess, I never messed with it...

[toxie]

why not

 

i'll commit something later-on.. then you can decide if you like it better..

 

 

@Fren: I meant rather if the actual bmp file has an alpha channel that might be set.

Edited by toxie, 16 July 2015 - 04:14 PM.

[lodger]

a feature that might be helpful with the editor is coming up with a way to manage control points when there are multiple objects that overlap...for example, trying to select multiple control points with left shift can often be difficult or time consuming if the program registers as you clicking on another object (you lose selected points.) This gets tricky when you are trying to do something like adjust a wall "plastic" over lower objects. Anyone else hit snags with this?

[jpsalas]

a feature that might be helpful with the editor is coming up with a way to manage control points when there are multiple objects that overlap...for example, trying to select multiple control points with left shift can often be difficult or time consuming if the program registers as you clicking on another object (you lose selected points.) This gets tricky when you are trying to do something like adjust a wall "plastic" over lower objects. Anyone else hit snags with this?

I think the best way to work on those objects is to make better use of the layers. Just assign the object to an empty layer and then turn off all the other layers and you will be able to work on that object much easily. The layers are a very good help when working on a table, not only for keeping the same kind of objects together, but also for isolating some objects to work on them. I always keep at least one empty layer for that purpose.

Edited by jpsalas, 16 July 2015 - 05:28 PM.

[hmueck]

a feature that might be helpful with the editor is coming up with a way to manage control points when there are multiple objects that overlap...for example, trying to select multiple control points with left shift can often be difficult or time consuming if the program registers as you clicking on another object (you lose selected points.) This gets tricky when you are trying to do something like adjust a wall "plastic" over lower objects. Anyone else hit snags with this?

sometimes bringing the plastic in front helps. or putting it on a seperate layer. and selecting control points with a mosue rectangle.

In the near future it is possible that elements will reflect on the playfield.

i'm thinking about my robot table and wonder how VP will reflect the large plastic ramp, when it doesnt know how the ramp looks like from underneath...

[jimmyfingers]

We could just blur it maybe to make it a bit less dominant?

The reflection feature is great news guys!  The screen captures look great fuzzel!  I personally think they look nice as is / without the blur so could the blur effect / level be an option instead of forced?  Also, vs. blurring wouldn't something like the amount visible (almost like an opacity level) be used instead of blurring to make it more subtle - or both  Options I think are always desirable where not too difficult to implement / code as personal taste still is quite varied between authors and players of VP as we have consistently seen form everything from physics to lighting levels. 

 

Thanks again for continued work on this latest wicked feature - it's right up there with bulb reflections on the pinball

[jimmyfingers]

 

Just a small teaser for a new upcoming feature in VPX. In the near future it is possible that elements will reflect on the playfield. At the moment only static elements are mirrored and the look isn't too natural yet (it's more like a 100% mirror) but I'm working on that Here are some screenshots how it's looking at the moment. More informations later...

 

ah this will royally bone AMH ...I spent so much time!

Fren, I can empathize a bit with your initial feeling as I created a ball reflection routine (never got released) that got essentially superseded by the built-in and easy to use native reflection that the dev. team added, however, overall it's way better for VP and the community to have these things available natively and / or more easily implemented.  Plus, I imagine the effect overall will be something that can be enabled / disabled so you could always do things the way you used to but you got to admit it will be way less work in the future to not have to code all the special elements that the previous mirroring effect required like extra drop targets, extra flippers, etc.  

 

Also, one reason your FPS is fairly low in your two recent reflection based tables is because of doing the mirroring manually and specifically the large primitives with dynamic / active materials used for the (I was able to essentially double the FPS with only a few relatively quick changes on Fast Draw most of it being related to simply the manual method for simulating the reflective playfield).  When you first released Fast Draw you described being somewhat puzzled by the low FPS but I imagine by now you've seen the difference of making the table non-reflective / altering the materials used to facilitate that effect.  If you are interested I could describe more in a PM or alternate topic the few key areas I saw that gave me the near double FPS in Fast Draw at least at the cost of effectively disabling the effect / changing the active / dynamic nature of the key primitives and their corresponding materials.

[lodger]

for the rubber object, I was having some issues using the timer event in it...i.e. not being able to enter in a timer value to misc and getting an error with rubber.timerenabled=true, etc. the enabled check box was turned off prior to the script enabling. any thoughts on this? thanks!

 

-lodger

[freneticamnesic]

 

 

Just a small teaser for a new upcoming feature in VPX. In the near future it is possible that elements will reflect on the playfield. At the moment only static elements are mirrored and the look isn't too natural yet (it's more like a 100% mirror) but I'm working on that Here are some screenshots how it's looking at the moment. More informations later...

 

ah this will royally bone AMH ...I spent so much time!

Fren, I can empathize a bit with your initial feeling as I created a ball reflection routine (never got released) that got essentially superseded by the built-in and easy to use native reflection that the dev. team added, however, overall it's way better for VP and the community to have these things available natively and / or more easily implemented.  Plus, I imagine the effect overall will be something that can be enabled / disabled so you could always do things the way you used to but you got to admit it will be way less work in the future to not have to code all the special elements that the previous mirroring effect required like extra drop targets, extra flippers, etc.  

 

Also, one reason your FPS is fairly low in your two recent reflection based tables is because of doing the mirroring manually and specifically the large primitives with dynamic / active materials used for the (I was able to essentially double the FPS with only a few relatively quick changes on Fast Draw most of it being related to simply the manual method for simulating the reflective playfield).  When you first released Fast Draw you described being somewhat puzzled by the low FPS but I imagine by now you've seen the difference of making the table non-reflective / altering the materials used to facilitate that effect.  If you are interested I could describe more in a PM or alternate topic the few key areas I saw that gave me the near double FPS in Fast Draw at least at the cost of effectively disabling the effect / changing the active / dynamic nature of the key primitives and their corresponding materials.

 

 

It's for the greater good!

I mean it wasn't too bad, I had a decent method for importing, the hard part was setting depth bias for certain objects, other than that it was fairly easy. Not easy enough that I wanted to do it for every table, though, so this is great. Fast draw was baffling because it had, even with the reflections, less primitives than most other tables I have made. I haven't gone back to look at it, I'm sure there's a lot of optimizations that can be made to improve the FPS, but my understanding was I made all the primitives static (that I could) and non-collidable so they had as little of a performance impact as possible. I'm sure going back with a fresh mind I'd see something I stupidly overlooked. Maybe I'll do that this weekend. But thinking about it compared to AMH, I seem to recall FD having even terrible performance (for me at least) compared to AMH, and obviously the AMH reflection routine is more complex. Obviously this is all pointing to me screwing something up on fast draw.

 

I'm excited for the real time lighting adjustment and this reflection update in the works... both very awesome. Perhaps more so for the lighting. Currently my tables are just "hey that looks ok enough and I want to stop messing with numbers" so I think they can look a lot better.