Pcsx2: [Windows] CDVDNull Plugin Missing from recent GIT builds since August 2016

[jcdenton2k]

Using latest PCSX2 git build on Win7 x64

Only related (old) pull request I could find related to this:
https://github.com/PCSX2/pcsx2/pull/1290

So why was the CDVDNull plugin removed? Does the cdvdGigaherz plugin work better than the CDVDNull plugin?

I know the 'null' plugins are just there in order to give PCSX2 something to use instead of complaining about a missing plugin. But I'd like some info on this and perhaps some already-posted info that I may have missed after trying to search for it.

I load from ISO just fine since my DVD drive isn't fast enough to keep up with the demands of the emulator and I rarely use it anyways because I don't want to scratch/damage my original discs. Ripping them to ISO using ImgBurn is a lot more convenient for me. :)

[willkuer]

Pcsx2 has an in-built iso reader. Thus independent on the plugin choice you can always read iso's. The null plugin thus didn't provide any functionality and should be replaced by the gigaherz plugin.

As mentioned in your linked pr the null plugin was making some trouble with antivirus software. And it wasn't properly interfacing with pcsx2 anymore.

Do you see any need for the null plugin?

[jcdenton2k]

In the latest git build from the pcsx2.net main website (PCSX2 v1.5.0-dev-1319-gb00ae97 compiled Sept-20-2016) I've noticed the dev9gigaherz plugin isn't even detected in PCSX2.

My request is to leave the null plugins in place as an 'automatic fallback' if bugs or glitches prevent PCSX2 from using the normal plugins. Whether through corrupt plugin files or whatever happens then at least there's a fallback instead of having users freak out about 'broken' plugins.

Overall this was a question that I was asking as I would like to see a bit of consistency:
CDVDnull, DEV9null, FWnull, USBnull are all 'null' plugins but their presence doesn't disrupt the PS2 emulation. I have both the CDVDnull and cdvdGigaherz plugins so that I know I have something to fall back on if the plugin 'breaks' for whatever reason.

Like the 'dev9' situation, if the dev9 null plugin had been removed we'd be hearing many users of the new git commit upset at the changes.

Now if cdvdGigaherz plugin is mandatory-required for crucial functionality then please do educate me or direct me to the relevant code if possible and I'll do my best to understand it. (I don't have good results with GitHub search tools).

Antivirus false positives are due to their faulty detection routines rather than any fault of the null plugin itself. If we are talking trash like Symantec/Norton or McAffee then trying to cater to them will just end up in misery. I'm also fairly certain they've blacklisted pcsx2.exe itself at certain points in development.

As far as 'not properly interfacing with pcsx2 anymore' I am curious about this. Interface how? The purpose of the null plugin is to prevent being stuck at the 'plugins' dialog because there are no available plugins suitable or available. That's all it does. It would be 'blank' otherwise. The only purpose null plugins should have is to tell PCSX2 'I am a blank plugin so just ignore me but don't bother the user with a missing plugin error'. That's it.

Fallbacks are good to have and the presence of the null plugins don't seem to break anything. They only takes up 10-20 kb each so keeping them in the git archives might be a good idea. It is difficult for any developers to anticipate the changes of removing or modifying things like this. For example, computers without an optical drive might freak out at the cdvdgigaherz plugin since there's no optical drive available. How much testing is done on how many systems? Having a fallback 'null' plugin is a good idea.

[turtleli]

Fallback: I don't see how it's better. In some cases, it brings confusion - I'm pretty sure I've seen on the forums "I can't load GSdx, so I loaded GSnull which loads fine but nothing is rendering" before I removed GSnull. And if something breaks, we need to know about it instead of having users just use another plugin in cases where it's possible.

Interfacing: the plugin API has changed over time. The null plugins haven't been kept up to date with the changes, so there are now interfaces that aren't used by PCSX2, or interfaces that are missing but are dealt with by compatibility functions within PCSX2 itself. Null plugins also require maintenance, even if they're generally meant to do nothing.

Antivirus: If false positives can be reduced it saves our users unnecessary hassle. We're trying to cater for our users, not for antivirus companies.

IMO, not having to unnecessarily maintain null plugins saves everyone some hassle.

In the latest git build from the pcsx2.net main website (PCSX2 v1.5.0-dev-1319-gb00ae97 compiled Sept-20-2016) I've noticed the dev9gigaherz plugin isn't even detected in PCSX2.

That's not a recent thing if winpcap isn't installed?

For example, computers without an optical drive might freak out at the cdvdgigaherz plugin since there's no optical drive available.

Err... what? How?

[gregory38]

Seriously, some people complain because they have a plugin choice. And others complain because of no choice. (sorry I'm in bad mood today)

Those null plugins are useless. It is quite simple. If you installation is broken, you need to fix it, if PCSX2 build is broken, we must fix it.

[Blackbird88]

Winpcap needs to be mentioned somewhere as requirement for the DEV9 plugin or there needs to be some error message stating so, otherwise the user will never realize.

[mirh]

Mhh.. There is a point about confusion for noobs.
Though it's not like any dev couldn't still prefer null for their.. "simplicity"?
I dunno (but fuck dolphin with its monolithic design)

Anyway, perhaps compile them only on non-release builds?

[gregory38]

Dev perfers to avoid compiling useless file. Those plugins are nice as toy. On linux I compile them based on a build option. There is also a full project file build on msvc.

[jcdenton2k]

I guess I'll have to hang onto my null plugins in case future commits decide to remove those as well.
Going to go ahead and close this issue then.