New release: v2.2.0 BETA2

[freezy]

2 hours ago, lucky1 said:

In my opinion it makes support much easier than having to support all possible combinations of freezy versions combined with plugin versions. 

If Freezy releases the new version 2.2.0 there will be a plugin version 2.2.0 which is tested to be working with that version.

If he releases a version 2.3.0 there will be a plugin version 2.3.0

etc.

As easy as that.

 

That's just a whole load of bullshit.

 

"You" don't need to test anything, because the API will never change, by definition. So, testing really is up to me now, when I do changes in dmdext. Only that I cannot do it anymore, since your binary won't work with any changes, unless you specifically build for it.

 

The support nightmare is not whether there is a bug when I make changes. The support nightmare is that that every time thousands of users update dmdext, it will break the plugin. Every. Single. Time. For. Every. User. Want to quickly downgrade to test something? PAC breaks. You didn't meticulously keep track of which PAC corresponds to which dmdext binary? PAC breaks. For every, single, user. Every time.

 

To add insult to injury, it doesn't say why. It just breaks. It doesn't say which version it needs. Because it can't, really, since it's actually not linked to a version, but to the actual binary.

 

This is unacceptable. I'm kinda baffled you thought I would let this pass.

[slippifishi]

That sounds like a Lucky problem, not a Freezy problem. Did Lucky say you are not allowed to change the API or contracts? I must have missed that post. I definitely saw the one where he said he would rebuild for every new version (implying he will account for any change in contracts, if it occurs)

[Wylte]

So, if I'm understanding this right, the process going forward will be:

0)  There's a plugin for DMDext that graciously allows virtual users access to .pac colorizations.

1)  Freezy makes updates to the main program, but can't test how it affects .pac because the plugin is now behind.

2)  Freezy has to release an untested numbered update so Lucky1 will make a plugin.  Anyone who updates to this numbered update loses functionality because there's no plugin.

3)a)  Lucky1 releases a plugin and we go back to (0), or b) doesn't because there are bugs (that Freezy had no way of finding).

4)  A game of telephone ensues with Lucky1's testers telling Lucky1 what broke and Lucky1 telling Freezy so he can try to reproduce (if he's been given the beta plugin at this point) and fix.  Meanwhile, users are updating and losing functionality.

5)  Freezy possibly fixes the bug, but can't test it because the plugin now doesn't work on the fixed binary.  Back to (1).

 

That sounds awful.

Edited August 12, 2023 by Wylte
Step 0

[slippifishi]

This is the nature of a plugin, and it's what the community asked for when it insisted that Lucky's approach was not acceptable.

 

Why is Freezy testing PAC? It's not his plugin, so not his concern. Yes, he can certainly do some pre-emptive testing (if he wants to) to get an idea if PAC support has broken, and perhaps give lucky/the community a heads up if it is, but I would say he is under no obligation to do so.

 

Why are you all trying to create drama where there is none for you? If there is any drama/pressure, it is on lucky to keep his PAC plugin up to date. You asked for PAC to be separate from DMDExt and here you are, so what's the problem?

 

Edited August 12, 2023 by slippifishi
typo

[freezy]

1 hour ago, slippifishi said:

Did Lucky say you are not allowed to change the API or contracts?

By design, a public API (which in this case, it is), is not to change. It's one of the basic principles of software development. If you do change, it will break all existing clients.

 

31 minutes ago, slippifishi said:

Yes, he can certainly do some pre-emptive testing

No, I can't. The plugin breaks completely.

 

31 minutes ago, slippifishi said:

Why are you all trying to create drama where there is none for you?

Because dmdext is maintained by me, and the error will be displayed in dmdext, users will come to me when there are problems. But that's not even the main issue.

 

The main issue is that every dmdext update will break the plugin. This sucks for the entire community.

 

Oh, and what if Lucky1 gets hit by a bus, or leaves the community? Then all your 100s of hours of colorization work will die a slow death as people upgrade to new dmdext versions that aren't compatible with the plugin anymore, and never will be.

 

It's just a tremendously stupid and selfish move at the cost of the community.

 

 

[freezy]

1 hour ago, slippifishi said:

That sounds like a Lucky problem, not a Freezy problem.

 

Let's be honest. What you're really saying is that the problem created by Lucky1 which impacts 100% of the user base at each update, should be fixed by Lucky1 rather than me. Like, your concern is not the community, but Lucky1 and me.

 

Crazy idea: How about not introducing the problem in the first place?

[Dazz]

3 hours ago, lucky1 said:

 

Why ? In my opinion it makes support much easier than having to support all possible combinations of freezy versions combined with plugin versions. 

If Freezy releases the new version 2.2.0 there will be a plugin version 2.2.0 which is tested to be working with that version.

If he releases a version 2.3.0 there will be a plugin version 2.3.0

etc.

As easy as that.

 

P.S: With the serum.dll freezy makes sure that it has the matching version of the serum.dll by embedding it into his dll. That is not possible with the plugin because of his license restrictions.

I think you guys forgot that this hobby started and is a community project. This hobby is open source for the most part as all of the software that we use is open source. @lucky1 project started off as an Open Source project, but quickly turned more closed.  The changing from vni/pal to pac was reactive to me receiving legal contact regarding colorizations.  Pac closed off the project to encode the frames.

 

I really don't care, but this feud/battle has been going on long enough... and not really much has changed since the beginning.

Yes, this is a support nightmare... There is already enough questions and issues regarding trying to get both dmd colorizations to live in harmony on a single machine.  The community doesn't give a flying F*** about who's dll does what... the community needs solutions that work together without hinderance. A solution, with the communities interest in mind, needs to be found.

 

[lucky1]

3 hours ago, freezy said:

Only that I cannot do it anymore, since your binary won't work with any changes, unless you specifically build for it.

That is why YOU have a special build of my plugin  which is not bound to any binary for testing.

You used that to develop the plugin interface which seemed to work quite well.

The only limitation is that you are not able to test pac and fsq with that special version of the plugin

but that is irrelevant for the testing since the colorization code is the same for all three formats .

So if it works with your testing version it will work with the other file formats.

 

2 hours ago, slippifishi said:

Why are you all trying to create drama where there is none for you? If there is any drama/pressure, it is on lucky to keep his PAC plugin up to date. You asked for PAC to be separate from DMDExt and here you are, so what's the problem?

 

Thanks !

[lucky1]

2 hours ago, freezy said:

Oh, and what if Lucky1 gets hit by a bus, or leaves the community? Then all your 100s of hours of colorization work will die a slow death as people upgrade to new dmdext versions that aren't compatible with the plugin anymore, and never will be.

 

Steve45 has 100% access to ALL pin2dmd sources and is involved in all decisions.

If you want I can tell him to make pin2dmd opensource if that happens, because I obviosly don´t care anymore then.

[slippifishi]

Suggestion: "DISCLAIMER: DMDExt does not support PIN2DMD projects" put this in your release notes and/or readme and you can now outright ignore 100% of any support requests that relate to PIN2DMD/PAC/VNI/FSQ/whatever!

  

2 hours ago, freezy said:

Oh, and what if Lucky1 gets hit by a bus, or leaves the community? Then all your 100s of hours of colorization work will die a slow death as people upgrade to new dmdext versions that aren't compatible with the plugin anymore, and never will be.

 

You claim my hundreds of hours of work could be lost if lucky get's hit by a bus, but that loss actually extends to the entire PIN2DMD project, not just your DMDExt plugin, so we will have bigger problems if lucky gets hit by a bus (lucky, please don't walk on any roads!). But actually that loss already happened for me 18 months ago when this debacle started and my VNI projects were removed from the site, I tend to stay away since then. I learned a new word at that time, in fact you taught me it Freezy - FUD - and it seems we have come full circle because all I am hearing from this thread now seems to be the same fear, uncertainty and doubt.

 

 

[lucky1]

3 hours ago, Wylte said:

So, if I'm understanding this right, the process going forward will be:

0)  There's a plugin for DMDext that graciously allows virtual users access to .pac colorizations.

1)  Freezy makes updates to the main program, but can't test how it affects .pac because the plugin is now behind.

2)  Freezy has to release an untested numbered update so Lucky1 will make a plugin.  Anyone who updates to this numbered update loses functionality because there's no plugin.

3)a)  Lucky1 releases a plugin and we go back to (0), or b) doesn't because there are bugs (that Freezy had no way of finding).

4)  A game of telephone ensues with Lucky1's testers telling Lucky1 what broke and Lucky1 telling Freezy so he can try to reproduce (if he's been given the beta plugin at this point) and fix.  Meanwhile, users are updating and losing functionality.

5)  Freezy possibly fixes the bug, but can't test it because the plugin now doesn't work on the fixed binary.  Back to (1).

 

That sounds awful.

 

That is not true because he can´t test every call of the plugin with the special version he received from me to create the plugin interface.

[lucky1]

9 minutes ago, slippifishi said:

- FUD -

 

wiki says about the word he learned from freezy  ...

 

is a manipulative propaganda tactic used in sales, marketing, public relations, politics, polling and cults. FUD is generally a strategy to influence perception by disseminating negative and dubious or false information, and is a manifestation of the appeal to fear.

 

Seems to be very suitable here.

 

 

[freezy]

14 minutes ago, slippifishi said:

but that loss actually extends to the entire PIN2DMD project

PIN2DMD isn't locked to any dmdext version, so future versions will work.

 

15 minutes ago, slippifishi said:

all I am hearing from this thread now seems to be the same fear, uncertainty and doubt.

There is no doubt, neither uncertainty, that every dmdext release will break the plugin.

 

21 minutes ago, lucky1 said:

That is why YOU have a special build of my plugin 

I have naively overwritten that version by your latest, locked, version, and you've removed that Dropbox link since then.

 

I think we can all agree that the bus issue and me not being able to test are the minor issues here (and mostly resolvable). But no one is addressing the elephant in the room, which is that every release of dmdext will break the plugin for everyone. And no, the issue is not who needs to fix it (I know it's not me, thanks), the issue is that the actual users will have a broken setup by updating dmdext, every single time. That's just a fact, and has nothing to do with FUD.

[lucky1]

On 8/12/2023 at 3:13 PM, freezy said:

I have naively overwritten that version by your latest, locked, version, and you've removed that Dropbox link since then.

 

Here you go ... Since it enabled you to develop and debug the plugin in the current version of dmdext, I´m pretty confident it will be enough to test any future changes to your code.

 

Edited August 27, 2023 by lucky1

[slippifishi]

13 minutes ago, freezy said:

the issue is that the actual users will have a broken setup by updating dmdext, every single time. That's just a fact, and has nothing to do with FUD.

 

Again, this is the nature of plugins. The same extends to mods for games, another form of "plugin". I (still) play GTA V and I mod it, but every time Rockstar releases a new version, all my mods break and I have to wait for update(s) to be made by the mod creators. Rockstar don't announce in advance what's changing and the first I find out about it is when the update downloads and I can't play the game anymore. Sometimes the breaking changes can be fixed quickly, and sometimes they get fixed slowly - either way I have to wait, it's the nature of a plugin.

 

Also, with the greatest respect, how much work are you foreseeing happening to DMDExt in the future? We are obviously at a point in time where lots of changes are being made, but one imagines that once things are stabilised from the current roadmap, DMDExt 2.2.5 or whatever the final version number is will likely remain the main stable version for some time? Or are you anticipating more regular updates going forward? Again with the greatest respect it has taken some time for DMDExt to get to this point as your focus has understandably been on the excellent looking VPE. I appreciate that you may be thinking long term along the lines of "what if i make a small update in 18 months time" but don't forget there were 18 months of stability before that. I know we can't predict the future, but we can look at the history of the DMDExt, and from what I can gather it has been relatively stable for much of its life, with short bursts of innovation occurring at a few points. For as long as I can remember when I was playing VPX, people were using Freezy 1.7.1 or 1.7.2 - for literal YEARS that was the goto version - so will it require more frequent updates from now?

[lucky1]

14 minutes ago, freezy said:

But no one is addressing the elephant in the room, which is that every release of dmdext will break the plugin for everyone.

 

Didn´t every update to the pin2dmd code break the compatibility to dmdext in the past ? Remember the time when 16 color modes weren´t working properly until DJRobX and I fixed them and that 64 colors weren´t working until I cooperated with mista-funky to add that to your code ?

 

This IS - FUD -

[freezy]

1 minute ago, slippifishi said:

Again, this is the nature of plugins

No, it's not. That's why we have an API. What you're talking about are mods, which manipulate an existing program, and depend on the program. An API is supposed to be a stable interface.

 

3 minutes ago, slippifishi said:

so will it require more frequent updates from now

I don't know, but after big releases like this, there's going to be follow-up fixes. And there is Scorbit on the horizon.

[freezy]

1 minute ago, lucky1 said:

Remember the time when 16 color modes weren´t working properly until DJRobX and I fixed them and that 64 colors weren´t working until I cooperated with mista-funky to add that to your code ?

 

Of course, there will always be updates with bugs that might break something for some setups. Now, an update always breaks every setup that uses the plugin.

 

That's a pretty big difference in my book.

[LynnInDenver]

Having the plug-in check to see what specific version of Freezy's engine, rather than the version of the API (which should be stable now), is another piece of evidence I can use to continue not using any PAC colorizations on my cabinet. I disabled all colorizations when PAC came out, because many of the changes that came about with it I recognized that - even if it was brought with good legal reason - the way it was done invoked a support nightmare from day one, invalidating all the old guides for using colorizations, and violating open code licenses, and as a Twitch streamer specializing in virtual pinball I couldn't risk putting people in the middle of that, and still can't given what's been revealed here. The only colorizations I use are SERUM.

 

I do rate this the specific fault of @lucky1, who appears to be at this point stonewalling in the face of @freezy offering noble attempts at an amicable solution, that goes well above what he needed to do in the face of what was always a hostile fork of his project. One person is making efforts in favor of the community as a whole, while the other is making efforts to keep that community divided for his own selfish reasons.

[slippifishi]

Ahhh, I did wonder if you would show up to tell us you have abandoned PIN2DMD, yet again.

 

The way I see it, Freezy you have a choice - either support the plugin, or don't. If you want to block PIN2DMD from DMDExt to alleviate your perceived support nightmare, go for it. If you are concerned this will alienate users or DMDExt 2 uptake because it will limit the number of colour projects available, then you must go to the Serum forum and convince the users there to create projects and increase the available library, and then either hold off with releasing until the SERUM library meets your needs, or perhaps you allow interim support of PIN2DMD until such time as you are happy with the SERUM offering, and drop the plugin then - that would be to your discretion.

 

As usual the other PIN2DMD artists are silent, but if they aren't going to speak for themselves then I will and I will say we don't care either way, the ones who do it for money will still get the same money from the real pin users, and while we lose a great tester base from the vpin users, we also lose the fear of alphaDMD or anyone else stealing our hard work for their own gains. It will certainly reduce the number of new PIN2DMD artists we see, but that's definitely not your problem. Many of the (vocal) vpin users made their feelings well known 18 months ago (eg. see the previous post) so some of us already feel that the vpin community abandoned our work, so there is no love lost from our side; you will notice that the PIN2DMD forums are much quieter these days than they used to be.

 

Ultimately, in 18 months you have not been able to change lucky's mind. I will go out on a limb and predict you won't change his mind within the next 18 months, so you should consider making your decision and moving on.

[Cliffy]

Sweet Lord. I was just happy as a lark testing for you both and it was going so well. We were *this close* to nailing it all down. Lucky fixed this on the fly, freezy fixed that on the fly, it was coming together so nicely and then BAM! What the hell happened? Lucky and Freezy, both genius, both invaluable and now we add zedrummer- 3 genius minds! All the authors and artists, I bow in your general direction although I don't envy the position you've been put in. 

I have no idea if this is all falling apart due to ego clash or technical difficulties but I can tell you I myself feel like I don't know what to do. I don't want us all getting to a point where we have to "pick sides"!

[freezy]

3 hours ago, slippifishi said:

Freezy you have a choice - either support the plugin, or don't.

 

I have a lot more choices. I will pick the one that is most beneficial to the community and as little as possible hurtful to lucky1 and the monetizing coloring authors.

[Dazz]

@lucky1 This has seriously gone long enough... and it's getting NOWHERE.

 

How about this...

Encrypted formats, including PAC, will no longer be tolerated at VPUniverse.  PERIOD. 

 

PAC *IS* a commercial format that was simply added to allow colorization authors to monetize their colorizations for REAL Pinball machines.... at the cost of digital/virtual pinball. This has NOTHING to do with the digital pinball community interests.

 

If you want to continue the commercialization of Pin2DMD and specific colorizations for real pinball use please move to your own platform. VPUniverse will no longer support these efforts.

[LynnInDenver]

Well said @Dazz, @freezy has bent over backwards trying to accommodate the desires of the community for a single solution, only to have the goalposts be moved time and again. I think it's clear @lucky1 doesn't want a solution that isn't under his 100% control.

[zedrummer]

On 8/11/2023 at 7:31 PM, lucky1 said:

To prevent my colorization code or any colorization to be misused again

 

Could we have a comprehensive explanation on that @lucky1, please? What is the real source of the problem? If there was such a misuse, perhaps there's something that can be done against that.