samisalreadytaken / vscripts

GNU General Public License v2.0
33 stars 1 forks source link

Auto Pickup (as submitted to the workshop) overwrites gameinit.lua and is incompatible with other init-modifying addons #1

Closed PeterSHollander closed 4 years ago

PeterSHollander commented 4 years ago

Presently, if any other mods which utilize a custom gameinit.lua file are enabled, only the most recently enabled addon's gameinit.lua will be called. Therefore, if the Auto Pickup mod is enabled, and subsequently another init-based mod is enabled, then only the latter mod will be active, as its gameinit.lua overwrites that of Auto Pickup. Vice versa, if Auto Pickup is enabled last, then it will overwrite any previously existing gameinit.lua files.

A group of developers on the Half-Life: Alyx Modding Discord have collaborated and agreed on a standard for mods moving forward which enables an unlimited number of init-based mods to be active at once - I strongly encourage you check it out (Scalable Init Support)!

samisalreadytaken commented 4 years ago

https://steamcommunity.com/sharedfiles/filedetails/?id=2187633818

The very idea of having a workshop submission as a mandatory dependancy, forcing developers to use an arbitrary "/mods/init/" directory for no reason is restrictive, not scalable.

Apart from these ridiculous aspects of it, it also includes completely unnecessary files, convars and global functions that the user should have full control over. Things that should only be available for the developer, and not visible to the end user. Ever heard of libraries..? It may even look like it's doing something to someone that doesn't know any better.

Also considering how the "scripting" channel on that Discord server consists only of beginners, I would rather not take their word for anything.

I'm closing this issue because I am never going to add a random dysfunctional addon as a dependency.

PeterSHollander commented 4 years ago

I would argue that forcing developers to conform to the same standard in their own code base (arbitrarily placing the addon's init file in the base vscripts folder) is just as restrictive. And if that agreed upon standard has to change in the future, there is no guarantee that all implementations will support such a change, and then you're back to square one where game/gameinit.lua is being overwritten by conflicting standards. Having a dependency, on the contrary, is able to evolve over time from one centralized location.

Adding dependencies to workshop submissions is quite easy, and the user is notified upon downloading your addon if they do not already possess said dependencies; it is difficult for a user to mess that process up. I am sorry that our effort to future-proof this sort of standardization is frustrating to you.

samisalreadytaken commented 4 years ago

if that agreed upon standard has to change in the future, there is no guarantee that all implementations will support such a change Having a dependency, on the contrary, is able to evolve over time

Having a "standard" that is auto-updated without the consent or knowledge of the developer itself creates compatibility issues.

There is a reason why libraries and standards versioned. A change (which would never happen in this case because there is no functionality to change) would ruin all that depend on a centralised and auto-updated system. Can you imagine a forced system-breaking change in software/hardware without the developers knowing, while it is in use? All (major) updates should require the developers manually adjusting their work to the changes.

placing the addon's init file in the base vscripts folder) is just as restrictive.

Developers are free to work in any directory under the root. Why would having the base initialiser, which subsequently would run other custom files, in the root directory where the user can see at all times be restrictive? There is no logic to having a "/mods/init/" folder. The root is where no files exist other than their own; so why hide the initialiser under 2 folders? As far as I know such structure and wording does not exist in Source either.

Having a mandatory workshop dependency for all addons is needless clutter and confusion for the end user, and practically free advertisement for you.

I stand by what I said in the guide. The developer should be in full control of everything, the initialiser script should be in the root and not under arbitrary directories, the global initialiser should be created and placed by the developer, not used as a workshop dependancy.