Automatic "Modified" property on all scripts

I have several folders of Modules and Scripts in a blank place file, which I use in all my projects and a few plugins. Problem is, some may break over time, or I may optimize them, or modify them for some other reason. This means my “master copies” are more up-to-date than scripts throughout all my plugins and places, and I have no easy way to tell what is old and what is new.

Yes, I could upload these scripts and require them from there so they’re always up-to-date, but it’s a pain/difficult to remember to keep the online copy updated along with my local copy, and it’s not always desirable/possible to have the delay while the script is being required from the web.

I could also include a version number in my scripts, but I’ve tried that before and I forget too often to update this number.

We’re all aware of the “Date Modified” or “Date Updated” properties our documents have. It would be extremely helpful if scripts had such a read-only property as well. Whenever you modify the script’s name or source this property would behave as expected, changing to reflect the current time and date.

That way I could tell at a glance if a script is outdated. I’d probably make a plugin that scans a game’s directory for my scripts, and if the timestamp is too old, replace it with my updated copy.

OPINIONS!!!

  • Good idea
  • Bad idea / pointless idea

0 voters

1 Like

Could you just not just use LinkedSource?

Seems like you would benefit from working with files instead of scripts. :slight_smile: :slight_smile: :slight_smile:

On that topic, I made a pretty neat ‘compiler’ (in Lua) for ModuleScripts. It requires LuaXML and LuaFileSystem:

http://hastebin.com/finabobime.lua

To use it, run it on the command line like so:

# to build
lua build.lua build path/to/source
# to clean
lua build.lua clean path/to/built/models

Right now there’s a little bit hard-coded (the location for ‘built’ code, which is in ‘./build/’) but for the most part it should be fairly modular and easy to edit.

Also, you can expand ‘build variables’ within the code using %variableName% within your code, and then define it as an environment variable before running the script. However, it has not been tested completely and may break with things like %% in patterns, or the percent sign in general.

1 Like

Awesome! I brought it up in the first place because I happen to be working on a related project. I’ll probably make a post about it in the coming weeks.

1 Like

I may be wrong, but I do not think LinkedSource works across places – if it did then it would be beautiful, but like DataStore I believe it is universe specific which is incredibly annoying.

If you want a LinkedSource across places, that’s what requiring a Module from the website is.

Except anyone can require it into their places then (not just you) and you have to worry about someone finding a loophole in your attempt to prevent other games from using it and stealing your code

If you don’t make it a Free Model, you’re the only one that can require it. If you don’t own it, then you get a 409 error trying to load it.

You can only require a module if it’s named MainModule, which enables everyone to require it. You can use InsertService to insert it and require it though, which is what I imagine you’re referring to. When you said require my brain immediately went to MainModule and forgot about InsertService – oops!

How are you requiring your Module in a way that anyone can access it? Are you sure it’s not listed as a Free Model? For me, both require(assetId) and InsertService return 409 errors if it isn’t the creator’s account.

7 posts were split to a new topic: Removing ability to require non-owned module scripts

1 Like