How should support scripts be released?

[Greek2me]

I'm curious what the preferred method is so I can follow it for my scripts.

[Ad Bot]

[Shappeh]

Making any requirement for the end-user is less-preferable.

I feel like the community should develop some Add-On standard (clan?) for questions such as this. Although these questions are not often asked on the forums, I ask myself these kind of questions a lot when I code.

Sorry to get off-topic but I've had that idea for a while.

[Dannu]

So something like the equivalent of the internet police? I feel like a lot of people, especially newer coders would get stuff on, if there was some standard or a deciding party.

[Dannu]

Also, OT: I think a individual add-on for something very popular and broad and specific cs files for a more specific support script. There's rarely any wrong answers.

[elm]

Would be nice to have a support_ prefix, but I guess you can just go with script_. Or maybe, script_Support_. I voted for them to be packaged as add-ons.

[Greek2me]

So something like the equivalent of the internet police? I feel like a lot of people, especially newer coders would get stuff on, if there was some standard or a deciding party.

The point is to make things easier for people, not more complicated.

Would be nice to have a support_ prefix, but I guess you can just go with script_. Or maybe, script_Support_. I voted for them to be packaged as add-ons.

I've been releasing all of my support scripts as Support_*.cs files. However, I also released my updater as Support_Updater.zip, because it's too large to be included with add-ons. It's a strange dilemma.

[Headcrab Zombie]

I voted the latter, because the person downloading them (usually) isn't the end user, but a developer using them for their addons

Labeling them 'add-ons', packaged and everything, might lead people to thinking they are standalone add-ons, and trying to download and use them as such

[Shappeh]

Labeling them 'add-ons', packaged and everything, might lead people to thinking they are standalone add-ons, and trying to download and use them as such

This is a really good point. Adding to my previous reply, I think Add-Ons should not be prefixed with "Support" because that usually means that the Add-On is intended to be coupled with another Add-On or multiple Add-Ons. An Add-On should add a feature to the game with or without any additional Add-Ons but that brings Greek2Me's issue back up...

I also released my updater as Support_Updater.zip, because it's too large to be included with add-ons.

It also includes Support_*.cs files within the Support_Updater file. Going by my initial decision, modders could include Support_Updater script files in a folder within their Add-Ons but that could just be too much work for too little of an effect; Just packaging Support_Updater as a separate Add-On might be a better idea in the long run.

I don't know, I'm stumped!

[portify]

The simple solution for simple scripts is to simply bundle the script with your add-on (either with a Support_ prefix or in a separate lib/, support/ or whatever else folder) as well as include a clause at the top which doesn't exec it if a newer version has not already been executed. It's a problem for larger things, though. I've written a TS library to be used as a support script and it takes like 3000+ MS to exec it. That coupled with the size makes bundling it a bad idea.

[Greek2me]

I've written a TS library to be used as a support script and it takes like 3000+ MS to exec it. That coupled with the size makes bundling it a bad idea.

That's not terrible. It'll only be executed one time, and storage space isn't too much of any issue. We're talking a couple MB at most. If it is an issue, would you be able to modularize it and break it into smaller support scripts?

[portify]

That's not terrible. It'll only be executed one time, and storage space isn't too much of any issue. We're talking a couple MB at most. If it is an issue, would you be able to modularize it and break it into smaller support scripts?

The issue is that if add-on X bundles version 1, add-on Y bundles version 2 and add-on Z bundles version 3, then yes, it will be executed more than once depending on the alphabetical sorting (potentially up to 10 seconds exec time already).

It wouldn't be viable to break it apart because of how everything in it depends on other parts of the library.

[Thorfin25]

The issue is that if add-on X bundles version 1, add-on Y bundles version 2 and add-on Z bundles version 3, then yes, it will be executed more than once depending on the alphabetical sorting (potentially up to 10 seconds exec time already).

Why not have it check for a global variable at the start to exec it or not, one that simply has the version. So if Y executes, then X tries to execute it'll stop X, then if Z tries to execute seeing as to how it's newer it will execute? Although this method isn't the best and if somebody removes Z after it executes then the global variable will stay and X/Y wont ever execute.

[Xalos]

Why not have it check for a global variable at the start to exec it or not, one that simply has the version. So if Y executes, then X tries to execute it'll stop X, then if Z tries to execute seeing as to how it's newer it will execute?

That's what he's saying, but since Blockland loads add-ons in reverse alphabetical order, then if Z has v1, Y has v2, and X has v3, then all three will think they have the latest version and try to run.

Although this method isn't the best and if somebody removes Z after it executes then the global variable will stay and X/Y wont ever execute.

Don't use $Pref::* variable names for library version compatibility.

[-Jetz-]

I vote separate add-on. If a problem is found in the support library, it's easier to fix the library and have the end user download it once, rather than fix the library, have everyone who has used it in an add-on download it, update the add-ons they used it in, and then have the end user download all the updates.