666 replies to this topic

[toxie]

also other tables show weird script errors.. (f.e. apollo 13)

[koadic]

ok just loaded monster bash into the lateset revision with the flasher object and all my meshes are gone from the table?
 
anyone else with this issue

Yes, it happens the same here.

Can also confirm...

In addition, also discovered that any meshes added to the table and saved with 819 don't appear in earlier revisions

also other tables show weird script errors.. (f.e. apollo 13)

That's because the primitives are gone

Edited by koadic, 26 December 2013 - 08:33 AM.

[fuzzel]

oh sorry! it was late yesterday and I didn't test enough. Will fix it later,

[toxie]

For the lights the new lightmap is better now, I really like the DMD made ​​with lights.
For the bumper I prefer the old lightmap, is much more visible when the bumper is on.
The left bumper is on and the other two are off, there is not much difference in brightness.

 

 

Thanks

 

Max

 

rev 822 introduces separate textures for bumpers and lights, so that the bumpers are much brighter now. let me know if its too bright now.  

[ringorian]

Just have an idea about disabling redundant sounds for DOF, by default i want to have a lot of sounds disabled and currently i remove the sounds from all the tables, or with koadic we hardcoded the sounds to be disabled on the script itself.

The idea is to have a list of sound names in an exclusion list, as not all tables have the same names for the sounds, so we could just add all names matching an effect that i don't want to hear anymore.

Example, i don't want to hear ballrelease, i put the sound name ballrelease on the exclusion list, another tables had ballrel? No problem, we add ballrel in the exclusion list

Maybe in the beginning it will take some time to go to some tables but after a certain time we won't need to take care of it anymore

What do you think?

Would this be possible to add ?

[fuzzel]

rev 824 should fix the issue with the broken primitive and flashers. Please test the flashers carefully until you use this in your upcoming releases. One known problem is the the IsVisible flag doesn't work at the moment. I didn't find the reason for this but it will be fixed for sure

 

Edit: take a look into CommandReference.txt, what kind of flasher variables are usable.

Edited by fuzzel, 26 December 2013 - 12:15 PM.

[melon]

Hello.

Now I'm doing the illumination for BK2K and I'm having serious problems with the ordering that didn't happen before.

I select all the ramps for the GI:

 

 

Now I reorder them

 

 

I run the table, and it's not correct!

 

 

I see the order again, to see what's wrong and I see this:

 

 

Everytime I change anything Vp reorders all the ramps involved wrong.

I'm doing it now with draw in back/draw in front, but it's not the way to do it.

 

It happens with the official release and with the new builds (using right now 810)

It didn't happen before (when I was using rev783, I didn't update so often)

[fuzzel]

rev 824 should fix the issue with the broken primitive and flashers. Please test the flashers carefully until you use this in your upcoming releases. One known problem is the the IsVisible flag doesn't work at the moment. I didn't find the reason for this but it will be fixed for sure

 

Edit: take a look into CommandReference.txt, what kind of flasher variables are usable.

The IsVisible variable works in rev824 the only thing you shouldn't do is something like that:

 

if flasher1.IsVisible=1 then flasher1.IsVisible=0 end if

 

So you can't read a variable and set it after that. I don't know if this behaviour is already known to you.

[kiwi]

 

For the lights the new lightmap is better now, I really like the DMD made ​​with lights.
For the bumper I prefer the old lightmap, is much more visible when the bumper is on.
The left bumper is on and the other two are off, there is not much difference in brightness.

 

 

Thanks

 

Max

 

rev 822 introduces separate textures for bumpers and lights, so that the bumpers are much brighter now. let me know if its too bright now.  

 

For me now it's okay.
 

One thing that certainly you have already thought , mapping image of the playfield .
 

Thank you very much.

 

Max

[arngrim]

I was thinking of that kind of screen to manage the sounds:

 

 

 

The exclusions would be on the right side, but when a sound is excluded from the left, it needs to stay on the left (or we wouldn't know which sound was there originally), but the cell with the name of the sound can be surrounded by some color to show that it is excluded.

 

I know that is not the priority, but i would love to see that feature,there would be no need to totally remove the sounds or hardcode the sounds on the scripts

 

Just have an idea about disabling redundant sounds for DOF, by default i want to have a lot of sounds disabled and currently i remove the sounds from all the tables, or with koadic we hardcoded the sounds to be disabled on the script itself.

The idea is to have a list of sound names in an exclusion list, as not all tables have the same names for the sounds, so we could just add all names matching an effect that i don't want to hear anymore.

Example, i don't want to hear ballrelease, i put the sound name ballrelease on the exclusion list, another tables had ballrel? No problem, we add ballrel in the exclusion list

Maybe in the beginning it will take some time to go to some tables but after a certain time we won't need to take care of it anymore

What do you think?

 

[toxie]

i personally would rather go for some standardized form, so that basically authors could flag sounds in certain categories..

and then these categories could be dis/enabled by the user..

 

excluding sounds by name simply sounds weird somehow..

[arngrim]

the only table that excludes all the redundant sounds is CV, because I told to Koadic the sounds that are redundant.

 

It's more between the DOF configs, the ones that are using them and on the toys they have.

 

the sound names are not so different than their purpose, because i do most of the dof configs, i can point out on a topicthe sounds that are emulated by which toy, and it is far more than just flippers, slingshots and bumpers.

 

that is the only way i found to have a global option, without considering the author has a ledwiz or not and thinks of it or not, it is a easier way to manage sounds, imo, once it is implemented of course

[arngrim]

if there is a way to copy paste the sound names from the sound manager, then koadic solution, to hardcode the sounds to be excluded in the script (i had to manually type all the sounds names after having read them), would be much easier to implement and would be a great help already

[unclewilly]

Anyone tried out the new flasher object yet
Any issues

[jimmyfingers]

Tested a little bit with the new flasher objects today using rev 828 and a basic test table.  They are exhibiting the same type of previous bug as the ramps had with the "paint ball" look when RU is not enabled on the objects or, as originally with that bug, not having RU or RO enabled in the general video preferences.  Unlike the previous ramp issue, they also have issues even when Additive Alpha is not enabled.  Here are a couple screen shots with both the Additive Alpha enabled and disabled respectively:

 

 

 Capture of Flasher Object Issue with No RU enabled - Additive Alpha enabled .png   469.11KB   9 downloads  Capture of Flasher Object Issue with No RU enabled - Additive Alpha disabled .png   511.68KB   9 downloads

 

As you can see the flashers are solid and the ball has the square around it while underneath. It's almost like all the recent aspects regarding the alpha ramps with the ordering and RU aspects that predicated a lot of conversation have still been left in these new flasher objects.  They don't require any height ordering which seems to fit the aspect that they are almost benefiting from the same "bug" as previously discussed with the stereo 3D option choices on ramps and RU / RO needing to be enabled in some form.

 

I hope this can be fixed so that the RU option on the object itslef is not mandatory to use them or RU / RO mangdatory to be forced in the video settings for graphic glitch avoidance as I did witness a small FPS improvement when using the flahser objects in my test table. I believe that they would also yield less stutter during swapping activities during gameplay possibly even more beneficial when forced AA is used (nvidia control panel) - FPS not being the end all of performance / stutter assessment.

 

Thanks again for adding this beta feature and continuing so quickly to keep adding new options / components to VP (9.2.1).

 

[toxie]

As far as i understand, this is really just an early beta of the flashers, mostly copy-pasted from ramp code and wiring it up to the UI, so i guess fuzzel will need to put some work in it first..

[unclewilly]

I'm the same as jf. Is prefer it worked like the alpha ramps without the ru checked.
It's nice that they can overlap without graphics glitches at the same height.

It does save a few fps. Although my system always stays around 60fps no matter what table I play. How are people getting 100+ fps, do I need to change something in the video settings.

The one thing is like is to be able to have the object be either horizontal or verticle.

How it is now works great for gi lighting and flashers. There are some cases like flashers on a back wall or flashers underneathe toys, like the bride flasher in mb. Where a verticle flasher is necessary. Hope that makes sense.

Or even if you wanted to show light on a side wall using this object a vertical option would be nice.

Appreciate your work on this.

I may redo the lighting in mb using this for performance reasons.

Haven't checked the ball under the flasher object yet but I hope it changes the ball brightness/color as well like the alpha ramps do as this is nice when the ball rolls through an area where gi light is present and becomes brighter or tinted.

I ser my gi lights at around 52 height for this reason
Anyway back to testing and thanks again.

If you guys want a performance testing table of be happy to send you a copy of monster bash, it will probably max out primitive use as well as alpha ramps. Maybe would be helpful for vp optimization

[fuzzel]

As far as i understand, this is really just an early beta of the flashers, mostly copy-pasted from ramp code and wiring it up to the UI, so i guess fuzzel will need to put some work in it first..

To be honest it should work as it is now the code isn't just a copy and paste of the ramp object. For rendering I used some stuff of the decal object and to add the blending I used the code from the ramps. So it's more of a mixture of decals and ramps. The problem with the height is a basic render engine problem but I will look into this maybe I can find something to improve it.
What I meant with "beta" is that options can change if someone has a good idea and implementing it could break the current behavior.

[fuzzel]

just some additional information about the drawing behavior:
VP has one big list of all objects you add to the table, the drawing order changes the position of objects in this list. The engine goes through this list and updates only those objects which have changed if you use RU. If you don't use RU all objects will be drawn every frame. The normal object is pre-rendered and this image is copied to the video buffer. Primitives, Ramps and Flashes are dynamic objects means they will be rendered every frame but after the static ones are already copied to the video buffer. If you use transparent images/objects you have to make sure that everything under that object is already drawn otherwise it looks odd. VP doesn't order the objects for you so you have to do it by your own with the drawing order AND with the height. Ramps are tricky here because a long ramp has different heights so sorting them with just a avg height doesn't work. The same goes for primitives/meshes. Changing the drawing order in a way that VP does the sorting will break tables.

[unclewilly]

Ok I've run into some graphics issues with mb that will force me to switch all the gi and flashers over to the new flasher object.

Just a few questions.

Will the ru checkbox be fixed or will it always need to be checked.

Also will a vertical flasher object be possible.

I haven't had a chance to look at the commands yet. Does this object also use the triggersingleupdate command

I appreciate this object as it should make mb look awesome