Root & User Access...

With the change to how code can be edited OOG in 1.56 (I think) so that instead of unzipping the cc/rom/.. folders and editing them for changes to programs that you want to apply to all computers. Now to make such changes you need to add any changed files to a resource pack and then reload the game for any changes to take affect (which is a pain).

So suggestion; add additional directories to the save game directories.

Currently I have

• /world/computer/1
• /world/computer/2
• /world/computer/3

So in addition to that I would like to see a directory called root which would give access to all the computers to the programs it holds. By default it's write protected from in game. (Ideally OP-editable.) In a server environment it would also be nice to be able to make directories with usernames that then allow individual users to have their own 'root' directory.

• user (overrides)
• Individual Computers/Turtles (overrides)
• root (overrides)
• resource packs (overrides)
• mods/peripherals (overrides)
• Main CC .zip

So in future I'd have:

• /world/computer/root
• /world/computer/LostNinja
• /world/computer/LostNinja/1
• /world/computer/LostNinja/2
• /world/computer/LostNinja/3
• /world/computer/admin
• /world/computer/admin/1
• /world/computer/admin/2
• /world/computer/admin/3

Or similar…

Root could also contain API/Help/etc folders for direct comparison/replacement of the default code.

And then I can edit files directly again and need only reboot individual machines to see changes. In the server environment I can manage who has easy access to specific scripts (without enabling http). Perhaps even add overrides to specific programs for specific users. On a decently set-up system I'd even be able to add specific quota's per player. (That is at the OS level and not within the game…)

if the same user had access to different pcs, its not a idea to go ahead with

Don't really understand what you mean. The idea is that each user would retain their current ability to label PCs and save programs locally to PCs. But instead of saving each PC within a global list of PCs (as is the current method IIRC); player 1 places and save a program and PC1, player 2 places and saves a program on PC2. When player 1 makes a new new PC/Program it's PC3 as opposed to PC2.

With this idea each player would have their own directory with the PCs saved within those directories. To share programs they would have to save them to a disk and physically give the disk to who they want to share the program with.

The Root directory would contain global programs added by an Operator (through FTP or similar), these would be available to every PC/Turtle that is placed by anyone. It could also contain sub directories for APIs, Advanced PC/Turtle specific, Turtle Specific or Help files. All of which would be available to everyone.

The User Directory would contain sub directories for each PC/Turtle placed by that player. Files in these folders would override files in the root directory. So if everyone has access to a program called Build and a user created a new program called Build this would be run instead of the program in the root directory.

For the end user who has no interest in where files are saved, there would be no visible change to how the mod works. Everything (bar any bugs) would work as it does now. For those of us who prefer using an OOG IDE to edit their code, or who manage servers with CC. An addition like this could be very useful.

This isn't going to happen for a variety of reasons, not least of which is that your idea completely kills the entire ability to share a computer with someone.

Not sure why that would be the case. If I place a computer it would create a new instance in world/computer/LostNinja/1 any that computer once named would be linked to that directory until it's renamed. And or the files therein deleted. If I physically give the computer to someone else to place, as long as they don't rename it it would retain the link to the directory it originally saved to.

That is in the world/computer/ directory there is a master list of all computers (labels.txt):

5 M001
6 M002

Re-purpose this to handle owner too:

<id> <user> <label>
7 LostNinja M003

In fact the only really new mechanic that would be needed would be to remove names on picked up devices, suggest shift right click while it's in your hand.

But certainly as mentioned before there should be no functional change unless you want the IDE support or the ability to manage scripts in a SMP environment.

And fair enough if it's not going to happen it won't happen. I'd quite like to know the other reasons though. Not being a java coder (or any real coder) I cannot say how difficult this suggestion would be, but on the face of it, it appears to be a fairly simple addition.

This can be implemented in Lua anyway.

This completely breaks backward compatibility with saved worlds.
This completely breaks the globally-unique-ID system, therefore breaking rednet.
This depends overly much on labels.
This triples the number of external directories that must be looked at for files on every computer.
This allows magical changes of directory contents depending on which player placed the computer.
Computers placed by turtles have no meaningful owner.

Use resource packs instead.

Lyqyd, on 16 December 2013 - 01:47 PM said:

This completely breaks backward compatibility with saved worlds.
This completely breaks the globally-unique-ID system, therefore breaking rednet.
This depends overly much on labels.
This triples the number of external directories that must be looked at for files on every computer.
This allows magical changes of directory contents depending on which player placed the computer.
Computers placed by turtles have no meaningful owner.

Use resource packs instead.

The computer could have the same ID, but users inside. Like a menu to add users and turtles could interact with computers to add its owner. How can we use resource packs for users?

The stated original problem was adding files to /rom, which the use of resource packs allows. The other stuff included in the suggestion is unlikely to happen.