4027 replies to this topic

[wiesshund]

 

rev213 is up (Release Candidate):

 

- retweak table save default filenames for Blueprint-images, .obj, .pov and .vpp: copy from table filename

- change 1s plunger retract default value

- bugfixes

 

                   

[wiesshund]

So is it time?
Release the Kraken

 

[Aubrel]

hi, thanks for the plunger retract default value: it works better for me like that

 

I just found a compatibility issue (not a new one, an old VPX7 one).

Demolition Man 1.3 by Knorr/Kiwi : the backwall looks broken with VPX7.

In fact it's because the texture image "grau" was doubled, there are 2 images with the same name in the image manager.

VPX7 is keeping only 1 image and removes the second one and it's not something bad but in that case the one removed was the good one used in VPX6...

Edited by Aubrel, 20 June 2021 - 12:58 AM.

[wiesshund]

 the backwall looks broken with VPX7.

In fact it's because the texture image "grau" was doubled, there are 2 images with the same name in the image manager.

 

I am thinking that is perhaps more a bug with 10.6 than 10.7?

Would it not stand to reason, that no two items should exist in any of the asset managers of the table, bearing the same exact dis[played names?

 

Seems that 10.6 should have never allowed that to happen in the 1st place?

[Aubrel]

I am thinking that is perhaps more a bug with 10.6 than 10.7?

Would it not stand to reason, that no two items should exist in any of the asset managers of the table, bearing the same exact dis[played names?

 

Seems that 10.6 should have never allowed that to happen in the 1st place?

 

 

Yes of course

but now it would be better to catch the one used by VPX6 and to keep only this one in VPX7 to get a good compatibility

[wiesshund]

 

I am thinking that is perhaps more a bug with 10.6 than 10.7?

Would it not stand to reason, that no two items should exist in any of the asset managers of the table, bearing the same exact dis[played names?

 

Seems that 10.6 should have never allowed that to happen in the 1st place?

 

 

Yes of course

but now it would be better to catch the one used by VPX6 and to keep only this one in VPX7 to get a good compatibility

 

 

Silly question, but which one,  in list order, is VPX .6 using, as opposed to VPX .7?
1st entry or 2nd entry?

Looks to me as if it displays the 1st one, but so does 10.6

 

I took a new table, tossed 3 images in

then renamed all 3 to spin inside vpx

 

both 10.6 and 10.7 showed same behavior

1st image was used, the other 2 were disregarded

 

Images had different external names

 

So then i went and took 3 different images

all with identical external names

 

i started in 10.6

i imported all 3 images, which had identical internal and external names

then made 3 flashers, and set each one to a different same named image

Table editor displayed all as the Last timage

Table running displayed all as the 1st image

 

saved and opened with 10.7 and observed same exact behavior

 

So it seems that what ever is going on in demo man, should not be happening to begin with, not even in 10.6?

Obviously it is somehow, not sure how, but seems it actually should not be.

 

10.7 though, at no time, deleted any duplicated images from the table, it simply disregarded them, but 10.6 showed same exact behavior

 

Unless

 

I am doing it wrong?
Which is possible

But seems that the table in question is doing something that it should not do in 10.6 even?

Edited by wiesshund, 20 June 2021 - 01:30 AM.

[Aubrel]

I took a blanc table, added a ramp using an image imported "image1" full black then I imported again a new "image1" red. So I have 2 "image1" in my image manager (a black and a red)

VPX6 is now always using the red one (the latest) even when I change the image in the image list of the ramp.

I save the table in VPX6, I open the table again in VPX7 and only the black one remains in the image manager.

So yes I don't know how it can works in VPX6 but VPX7 doesn't keep the good one.

[wiesshund]

I took a blanc table, added a ramp using an image imported "image1" full black then I imported again a new "image1" red. So I have 2 "image1" in my image manager (a black and a red)

VPX6 is now always using the red one (the latest) even when I change the image in the image list of the ramp.

I save the table in VPX6, I open the table again in VPX7 and only the black one remains in the image manager.

So yes I don't know how it can works in VPX6 but VPX7 doesn't keep the good one.

 

I can not replicate that, 10.7 is not deleting any images
it is showing me same as i see in 10.6

Here is 10.6

 

3 ramps
3 textures with same names
different one of the textures picked for each ramp

 

 

All ramps display only 1 1st image (in alpha/numeric order)

which was the 1st added, not the last added

 

 

And i save that and open it in vpx 10.7

And no textures have been deleted, at all

 

 

And as you can see, it has same behavior in and out of table

 

 

As you can see, no difference.

 

So i went to get that version of demo man, which i had to download from archive, because knorr deleted all his tables from all sites
(and he is probably going to yell at me for downloading it from archive too)
And i can not replicate the behavior you have on that specific table either

Both images exist in 10.7, it uses the 1st one, both exist in image manager, and i can rename or delete either one at will.

 

 

But that table does seem to have most likely saved originally with some kind of data anomalies when it was made, which they have recently revisited and fixed in VPX.

It does not exactly seem to load well, until you have gotten it open, and then resaved it, and then it opens much better and faster, though i  have not obviously had time to run it

and see that it plays fully as it is supposed to.

[Aubrel]

Your capture with both images in the image manager of VPX7 is strange (at least for me because here I don't have both in vpx7)

 

if it can help : here is the blanc table I talked about above:

https://www.mediafir...table2.vpx/file

 

With VPX6 the ramp is red because it uses the last imported "image1" and it was the red one.

With VPX7 the ramp is black because the red "image1" was deleted (no more in the image manager)

 

at least it's what I get here

Edited by Aubrel, 20 June 2021 - 05:08 AM.

[LunatechFringe]

 

 

 

 

 

Thanks for the detailed reply.

The issue is that the plunger speed and smoothness on 10.6 is absolutely perfect. On 10.7 the speed is soooooooo unbearably slow that you could make a cup of coffee and come back just in time to launch the ball - Little bit of an exaggeration there, and on creature it's just very underpowered on 10.7, but perfect on 10.6.

 

White water is my all time favorite table so I know all the bits and pieces backwards. Many years ago there was a place around the corner from my house that had the real pin, and I use to play for hours every day.

Interesting what you say about the L-4 and later ROMSs.

 

 

Just do what wiesshund said: Disable the 1s auto retract in dof nudge settings.

This is a new plunger that was activated by default in early betas. Just disable it.

 

Based on quite a few posts that I read, the first thing I did was check that this was disabled, but just in case I went to my settings to double check, and I can see that there is no tick in that check box.

As I mentioned, when I go back to 10.6 it's perfect, but when I go to the latest 10.7 the issue is there. Weak plunger in creature, and super slow and weak plunger in white water - Not to sure what other tables might be effected, but those are 2 tables I play all the time, so very noticeable to me.

 

Try toggling that setting on, and then off, to see if the UI is just misreporting the state of it.

 

 

Toggling the setting on and off worked for me.

[toxie]

I guess the demo man issue shouldn't block the release. Hopefully Knorr will just do an update at some point.

[Aubrel]

yep probably but now the fact we don't have all the same result and the same behaviour with the same table and the same software is worrying

[wiesshund]

I guess the demo man issue shouldn't block the release. Hopefully Knorr will just do an update at some point.

 

Not sure, considering i think he pulled all his downloads?

I had to go pull this table out of archives to look at it

 

Granted the fix should be simple, if one keeps a copy of the 10.6 exe handy and runs into that issue

go rename the offending grey texture in the 10.6 exe and save

But i dont know how many would do that, and i think knorr doesnt want anyone uploading any of his stuff, even if it is to fix an issue

he kind of had a fit over bigus updating a mod that he already had prior permission to make

[bigus1]

He was actually pretty relaxed about it and other folks went on a rampage. Knorr is a really nice guy, from my experience, and we just didn't see eye to eye about long-standing permissions.

[Thalamus]

I don't think this is a unique case. I've worked a lot with sound files and I've seen more than one table where samples have had duplicate names. I wonder, is it hard to make a small loader program/exe that can be run via cmd line to audit the table resources. And if it sees issues like these, report it ? That way one could quickly get a list of tables where potential issues like these and get those fixed ?

[wiesshund]

Your capture with both images in the image manager of VPX7 is strange (at least for me because here I don't have both in vpx7)

 

if it can help : here is the blanc table I talked about above:

https://www.mediafir...table2.vpx/file

 

With VPX6 the ramp is red because it uses the last imported "image1" and it was the red one.

With VPX7 the ramp is black because the red "image1" was deleted (no more in the image manager)

 

at least it's what I get here

 

I know what you have done

You have both duplicated the internal name, and the external source

10.6.x should have never let that fly.

I dont think you can realistically try to have 10.7 accommodate an error that should never have been there in the 1st place

 

https://drive.google...iew?usp=sharing

 

check that file, i replicated what you are doing

check exact file paths in 10.6 and vpx names

then load in 10.7 and look, and it will make sense

 

10.7 wont even let you do that, it will cancel out the old one with the new one

try and do exactly what you did to a new table in 10.7 and save it, now go reopen it

you will see that it did not keep the visually identical named/pathed textures (Or sounds for that matter)

 

You will bloat your table file if you do that enough, because it does not delete the previous ones
it simply replaces which one it is going to refer to, you could stick 8 gigs of image1 from c:\images\image1.png into the table, and it would only show you one of them

but you'd bloat the table file, and to get them out, you have to delete one, save, reload, delete the next visible one, save, reload, repeat till you vomit.

 

@Toxie

Probably, some user feedback would be good though
"ATTENTION USER, YOU NO CAN NAME SHITS THE SAME NAMES AND SOURCE PATH, I NOT DOIN DIS!!!  MKAY THX BAI!!!!"

and then refuse to at least do the internal name identical

Because as long as one of the 2 differ, then no issue as far as the image manager goes, you can see them all and fix the issue, clean it up etc.

 

I could see this being an issue when multiple persons work together on same table and one imports instead of reimporting by mistake and next thing you know
you have 3 4k playfields all named playfield, from the folder c:\pinteam\design\table_name\images

 

You can stick 10 textures all named image1 to VPX, from 10 different paths
you still will only be able to see one in game, but you will see all 10 in the editor, because you did not 100% duplicate the data

where as in doing the same internal name from same external path/name like he did, it cancels the others out because all data points are same.

I don't think this is a unique case. I've worked a lot with sound files and I've seen more than one table where samples have had duplicate names. I wonder, is it hard to make a small loader program/exe that can be run via cmd line to audit the table resources. And if it sees issues like these, report it ? That way one could quickly get a list of tables where potential issues like these and get those fixed ?

since i can do it by hand, i would imagine one could write some kind of tool for it that could give you a report

i do not know how hard it would be.

 

I do not know how easy it would be to make the tool run a cleanup for you though, as i can not even do that manually.
I can see and read, but can not write.

 

At least if they have exact duplication only in one spot, you can see and fix them in the managers
It's when they have exact duplication of both the internal vpx name AND the real literal path/name that you can no longer see the offending others without

yanking them out one by one, saving and reloading each time to reload the data structure.

 

One idea might be to have 10.7 force a renaming just like it does table objects where it appends 00# to them
on load, if any item in each manager area has a duplicate internal name, force a renaming of it appending 001 to the 1st 002 to the second etc.
And then YELL and SCREAM at a person if they attempt to stick them in like that to begin with

 

Still may mean you would have to fix an existing table, but you would at least see the offending parties to be able to address it.

And no, it isnt exactly unique

I have seen tables with multiple left_flipper or popper_ball etc
where someone probably made a new sound and then not thinking imported it rather than clicked reimport from

yep probably but now the fact we don't have all the same result and the same behaviour with the same table and the same software is worrying

easy fix

 

delete the offending grau image or give it a new vpx internal name like grau2
save and reload the table, and the right one will magically re-appear

 

and i can not promise that my table is 100% the same, your download is no longer available, and i went and found the closest i could in archive

I have a different version of demo man that i normally run, think it's a bigus mod or something

Edited by wiesshund, 20 June 2021 - 07:28 AM.

[Aubrel]

yep probably but now the fact we don't have all the same result and the same behaviour with the same table and the same software is worrying

easy fix

 

delete the offending grau image or give it a new vpx internal name like grau2
save and reload the table, and the right one will magically re-appear

 

I was talking about the fact you still have the 2 images on the knorr table in your image manager in VPX7 and not me.

That's crazy : same table, same software and not the same behaviour => not good

 

And in any case even if it was an issue to allow multiple files with the same name, if VPX6 uses the most recently imported one, VPX7 should be able to keep that one.

Of course this is something we will get with many other tables and a good retrocompatibility would be more than welcomed.

Edited by Aubrel, 20 June 2021 - 07:39 AM.

[wiesshund]

 

yep probably but now the fact we don't have all the same result and the same behaviour with the same table and the same software is worrying

easy fix

 

delete the offending grau image or give it a new vpx internal name like grau2
save and reload the table, and the right one will magically re-appear

 

I was talking about the fact you still have the 2 images on the knorr table in your image manager in VPX7 and not me.

That's crazy : same table, same software and not the same behaviour => not good

 

Technically, it should not work at all to begin with, not even in 10.6

If you did that to another program's data file, it would implode.

Imagine if you did that to a FAT table.

it is something that should never have been allowed to happen, and not a thing you want to accommodate as is in a newer version
But being that it has happened, and probably multiple times across many tables, some kind of handling routine for it is probably warranted

like a forced renaming of the duplicate internal names, which will not magically fix a table per se, but at least when you go to see what is wrong

you will see image image001 image002 image003 etc

[Aubrel]

I didn't check the VPX6 code but in software nothing is done by luck.

So if VPX6 is always taking the new one it's for a reason and it's not randomized.

So no need to do anything else than simply keep the same file in VPX7

Edited by Aubrel, 20 June 2021 - 07:51 AM.

[jpsalas]

In my opinion newer versions of VPX (or any program in general) should fix bugs in older versions, as VPX does. But it should not try to simulate bugs found in older versions just to keep a "compatibilty mode" with those bugs. The tables showing those errors should be fixed if you want to play them in newer versions.

 

And the demolition table has also another double texture, "rampbolts", in case someone wants to fix the table