This is a read-only snapshot of the ComputerCraft forums, taken in April 2020.
infinitebrainspace's profile picture

Yet another shared files suggestion?

Started by infinitebrainspace, 03 December 2014 - 06:45 PM
infinitebrainspace #1
Posted 03 December 2014 - 07:45 PM
All the posts about changing the bios, or crafting chips into a computer, security issues etc. I haven't found any posts about shared files. To accommodate safe, grief resistant, non-bios related file sharing that doesn't require a change to the ROM folder, I propose this:

A SPECIAL CC "CLONING" TABLE WITH 64 SLOTS.

Place up to 64 devices (pocket computers, computers, turtles) into the Cloning table, Click "Clone" and all of them will have the same ID (according to lastID.txt). This will allow all these devices to share data files, and no existing folder structures will have to be changed (actually they would all be pointing to the same folder / files).

Before the Clone button is clicked:
The user can optionally specify a label to be given to all clones in this set.

When the Clone button is clicked:
The lastID.txt file would have to be updated.
all devices in the cloning table would have to be given the same ID.
a folder with that ID would have to be created in the world\computer folder.
if no label is defined by user, all clones of this set would get the label "Clone" + id ("clone"..(id))

I suppose it could also be used for cloning disks, so if I edit a file on one disk all the clones get changed too.
Disks would not be allowed to be cloned with computers/turtles/pocket computers.

Once this set of clones is crafted, you CAN NOT use any of them to clone more of the same.
attempting to use one of them would essentially change its id to the new clone set id, and you would lose it as a member of the original clone set.

The only problem I can think of is a griefer changing / deleting the code in one of them, would do the same in all clones of that set.

I currently have to go into the server's file system, make the LastID.txt file read-only, place each device and click on it, create a file ("s") in one of them, and then go back into the server's file system to unread-only the LastID.txt file (which I have forgotten to do a few times).

This works, but limits the process to server-admins, and WILL cause problems if another user happens to place a new device in the world while the LastID file is frozen.

Also, this is a hack, and I feel dirty using it.
Edited on 03 December 2014 - 07:04 PM
Lyqyd #2
Posted 03 December 2014 - 08:07 PM
I suspect that this would be extraordinarily unlikely to ever be implemented. It completely breaks the fourth wall, as well as enabling instantaneous communication regardless of distance.

If you're really insistent on having such a thing, you should be able to set it up using just creative mode (though not across multiple types of devices). Place and label one computer, then break it and place as many as you like of the dropped computer/turtle.
ElvishJerricco #3
Posted 03 December 2014 - 08:12 PM
If you're really insistent on having such a thing, you should be able to set it up using just creative mode (though not across multiple types of devices). Place and label one computer, then break it and place as many as you like of the dropped computer/turtle.

And with cheat mode in NEI i believe you can copy the labelled device as well. Still doesn't let him go across device types though.

Anyway yea this suggestion doesn't really fit. Copying devices isn't the way we're intended to be doing communications.
infinitebrainspace #4
Posted 03 December 2014 - 08:21 PM
If you're really insistent on having such a thing, you should be able to set it up using just creative mode (though not across multiple types of devices). Place and label one computer, then break it and place as many as you like of the dropped computer/turtle.

This is true, and I have done it that way. My co-administrator and I don't like going into creative mode (its a pride thing). And true, it does allow instantaneous communication without the distance limitation. I didn't know it was a wall (let alone know there were 4 of them). I'm not using it to bypass the wireless range limitation, but it does allow me to access my inventory system from any location (put stuff in or take stuff out). It also provides me with a pocket teleporter - which only works if I tickle the server in the world spawn chunk at log-in (but you already read my bug report about the startup not working). anyway thanks for the heads-up on the unlikely implementation. At least I know why (sort of). I guess I should ask "what are the WALLS" so I don't post anymore suggestions that will break them.
ElvishJerricco #5
Posted 03 December 2014 - 08:32 PM
I guess I should ask "what are the WALLS" so I don't post anymore suggestions that will break them.

The fourth wall is an imaginary wall on the set of a TV show. The idea is that in TV shows (particularly sitcoms), the camera gets to face the scene from a direction that you normally don't get to look at. The wall that should be where the camera is, is called the fourth wall because the three other walls are visible in the scene. Breaking the fourth wall is the writers of a show letting the audience know that the fourth wall doesn't actually exist by referencing that this is in fact a TV show. For example, having a character look directly into the camera and say something. Or making a joke about one of the actors' real name.

Breaking the fourth wall in the context of CC means doing things that make sense to us as users, but don't make any sense from the perspective of how a computer should work in a 3D world. For example, this suggestion. In the real world, I can't just take two computers and make them quantumly entangled copies of each other. That doesn't make sense. But in CC it's possible. So you're suggesting that we make this a part of the mod, which breaks the fourth wall by looking into the camera and saying "these aren't real computers, this is a mod where impossible things are possible".
Edited on 03 December 2014 - 07:35 PM
infinitebrainspace #6
Posted 03 December 2014 - 08:38 PM
And with cheat mode in NEI i believe you can copy the labelled device as well. Still doesn't let him go across device types though.

Anyway yea this suggestion doesn't really fit. Copying devices isn't the way we're intended to be doing communications.

The multiple devices thing is irrelevant. They are not "Copied". You would have to have crafted them all first, then put them in the cloning table. As far as I know, turtles, computers, and pocket computers all use the same lastID.txt file, and all create a sequentially numbered folder in the same parent folder. Disks have their own folder, and their own lastID file - that's why they couldn't be cloned with the others.

Creative mode lets me make them without crafting, so I have to craft them all in survival mode, go into creative, godmode and copy as Lyqyd suggested, then destroy the ones I crafted in survival (this at least keeps me honest). Oh well, I guess I'll just have to cheat to get what I want (and stay as honest as I can).
infinitebrainspace #7
Posted 03 December 2014 - 08:44 PM
I understand. I don't like it, but I understand.


I don't like overcooked asperagas (cant spell it) either, but I - well come to think about it… Never mind.

Thanks for the description of the fourth wall. I will try not to look into the camera and say anything about Dan200.
Bomb Bloke #8
Posted 03 December 2014 - 11:47 PM
If you want a bunch of computers with an identical startup file, one other way to do it is to put that file on a disk, insert it into a disk drive, then connect all your computers to that drive via network cables. They'll all boot off the one disk.
Cranium #9
Posted 04 December 2014 - 12:26 AM
If you want a bunch of computers with an identical startup file, one other way to do it is to put that file on a disk, insert it into a disk drive, then connect all your computers to that drive via network cables. They'll all boot off the one disk.
That's exactly the method I thought of first to solve the "identical bootup sequence" issue addressed here.

Alternatively, if you're wanting a certain file to be available in all computers, you can simply use resource packs. But that makes them read/execute only.
infinitebrainspace #10
Posted 04 December 2014 - 02:02 PM
If you want a bunch of computers with an identical startup file, one other way to do it is to put that file on a disk, insert it into a disk drive, then connect all your computers to that drive via network cables. They'll all boot off the one disk.

I'm talking about SHARING DATA files, if turtle A changes the file "boogers.dat", I want turtle B to see the change as soon as it happens. If my turtles are moving around, or 3000 blocks apart, they cant share data on a floppy disk.

I totally understand the wall thing, and agree that CC should not implement such a feature. However, I am going to do this in vanilla CC with vanilla MC. I just have to figure out how (and I'm going to do it without going into Creative mode, or humping the lastID.txt file). When I do, I'll be sure to post the method.

if all my computers were sitting in a single loaded chunk, I would net-cable them all to 1 floppy drive, and share the data on 1 disk, but that's not the case.

Don't get me wrong, all these suggestions are valid, and appreciated, they just don't fit my needs.
theoriginalbit #11
Posted 04 December 2014 - 02:18 PM
if all my computers were sitting in a single loaded chunk, I would net-cable them all to 1 floppy drive, and share the data on 1 disk, but that's not the case.
except Turtles cannot accept that kind of connection. perhaps you could make some kind of program and release it on the forums. It'd be no small task, but you could make the program run behind a shell and detect any FS changes and sync them out over a rednet protocol to all other devices that can listen, each in turn perhaps relaying them on to try and get good coverage on the change.
Cranium #12
Posted 04 December 2014 - 05:04 PM
Don't get me wrong, all these suggestions are valid, and appreciated, they just don't fit my needs.
To be frank, your needs are quite strange, and you're making things more difficult in the long run than you need to.
I can't possibly think of any valid reason to change things to make this a default behaviour, even if it were enabled by config. As you said before, it's incredibly easy for someone to completely wipe one computer, and thus all files are lost forever. If you want communication to be coordinated across turtles several thousand blocks between each other, you can always increase the rednet range, or use the built in repeater system in CC 1.6x. If you want all computers to share a file that can be executed, read, and written to, and keep the file synced across devices, then you just need to build a file sync function. All you'd need to do is check the current file against the broadcasted file through rednet, and if it changes, simply rewrite the file.
infinitebrainspace #13
Posted 06 December 2014 - 03:47 AM
I have discovered (with much work) a way to accomplish what I want with vanilla MC / CC (and not in Creative mode or by fidling with the lastID.txt file. It does require a command block, but I can make a computer or a turtle have whatever ID I want it to. I'm still working on Expanded turtles, but with the base turtles I can always add the equipment I need after it is created. I have tested it, and discovered the following:
If you want a turtle, you type (or put into a command block)

"give @p ComputerCraft:CC-Turtle 1 (x)"
where x is:
Base turtle (ID * 4) + 4.
Mining turtle (ID * 4) + 5.
Wireless Turtle (ID * 4) + 6.
Wireless Mining Turtle (Id * 4) + 7

For Computers "give @p ComputerCraft:CC-Computer 1 (x)"
where x is:
Computer (ID + 1)
Advanced Computer (ID + 16385) - so if you wanted ID 10 you would use 16395

I hope to have Pocket Computers, Advanced Turtles, and Expanded Turtles figured out soon. It would help a lot if Someone out there knows the formulae for these.

This was all tested on SP, and I will test it on MP when I figure out the rest of the devices.
valithor #14
Posted 06 December 2014 - 06:10 AM
-snip

The method you posted works for everything except Pocket Computers. Pocket Computers use a different way to store ID, so you will most likely not be able to spawn them in using these commands.
infinitebrainspace #15
Posted 08 December 2014 - 08:25 PM
-
The method you posted works for everything except Pocket Computers. Pocket Computers use a different way to store ID, so you will most likely not be able to spawn them in using these commands.
Yes, They update the lastID.txt file as soon as they are "given", regardless of the value used for damage in the give command. The others don't update the lastID.txt file until the user places them, and then only if they didn't have a specific ID assigned at the time of "give".
Using a 1 for damage in the give always produces an advanced pocket computer, and using 0 always produces a basic pocket computer, but always gives according to the lastID.txt file. Still trying to find the secret though. I've tried numbers between -32767 and 65536, and none of them worked, so its not going to be easy. Maybe I need to learn java (or maybe Dan200 will tell me the secret… NOT!)
Edited on 08 December 2014 - 08:31 PM
Cranium #16
Posted 08 December 2014 - 10:08 PM
The fact still remains that this isn't something that most computers do now. What you may be thinking is shared storage for computers, but that goes back to my previous suggestion. If it's the automatic synchronization of files between computers, so that each computer has the most recent copy of the updated program, then you want to do it through programming, not hacking.

If you're wanting something to "clone" computers, this is easily done with a program that checks file dates that were added with a modified fs api.
valithor #17
Posted 08 December 2014 - 10:09 PM
-snip

As i said your method will not work with pocket computers. I know because I have written a bukkit plugin for a server I managed specifically for spawning computers in with a certain id. Pocket Computers, however, do not use damage values to store ids. They use something else, so as I stated before your method will work for everything except pocket computers.
infinitebrainspace #18
Posted 09 December 2014 - 02:12 PM
The fact still remains that this isn't something that most computers do now. What you may be thinking is shared storage for computers, but that goes back to my previous suggestion. If it's the automatic synchronization of files between computers, so that each computer has the most recent copy of the updated program, then you want to do it through programming, not hacking.

If you're wanting something to "clone" computers, this is easily done with a program that checks file dates that were added with a modified fs api.

The real fact is, that we are doing it right now. Both your computer and mine are sharing the same files on a database on another computer somewhere. Yes, it is through the internet, and yes they are separate PC's and YES they both have different ID's and YES we may both be using wireless to get to the internet. That said, it is also a fact that ComputerCraft does not have and internet. The real world has all the chunks loaded all the time. I don't have to worry about the Computercraft.info website ever being in an unloaded chunk (well maybe that's what happened this last weekend).

Maybe what is needed is a VPN Router device that can be linked to other VPN Routers which share a common folder (as opposed to a common ID). Then the communication between Client computers would be wireless / wired to the VPN Router at each location. The linked VPN's would share files, but would not have any direct interface to those files. The client computers would be able to share information with other clients through the VPN. The only user interface on the VPN device would be the linking of the VPN's (associating them with a common vpnid). The client would "map" the VPN to a logical drive (using rednet.map(vpnid)?), and be able to use the VPN as if it were a network drive. If one VPN is in an unloaded chunk, the files would still be available to the client in the local VPN chunk which would be loaded as long as the user stayed in that chunk. Placing VPNs in locations where users frequent would allow them to access their data from that location. This would keep the fourth wall intact, and be well within the realm of relative reality, without negating the need for wireless / wired devices. I don't want synchronized data, I want shared data (not copies of data). In effect I suppose it could negate the wireless range limitation, but you would still have to be in range of the "mapped" VPN, and that is also not beyond relative reality - I cant get to ComputerCraft.info if I'm out of range of my wireless Router, but as long as I am within range I can.
Edited on 09 December 2014 - 01:15 PM
KingofGamesYami #19
Posted 09 December 2014 - 02:16 PM
That still breaks the fourth wall. You just made range limitless. If you really want to do something like that, buy a server and code a php script to interact with the http api.
infinitebrainspace #20
Posted 09 December 2014 - 03:27 PM
.
-snip That still breaks the fourth wall. You just made range limitless.
-snip buy a server

I fail to see how this breaks the fourth wall. I am not proposing that some magical unrealistic device do something that is unbelievable, or pointing out that these computers are obviously just pixels on your monitor. I think the fact that "Texas becomes non-existent the moment you travel to Arizona and the movie you were recording in Texas just stops recording, and only resumes when you get back" - breaks the fourth wall. That's where relative reality comes in to play.

Range would be limited between the client and the VPN, just not between VPNs. Example: My laptop can't talk directly with yours wirelessly because we are out of range, but if we are on the same network, or we are both on the internet, we can. I'm proposing a virtual internet in CC. Not just for me, or my needs, but because it is inevitable that the Mod should progress in it's technology - which means the old technology may get left behind. Why should we still be mailing floppy disks to our cousins in Hawaii when we can simply e-mail them with an attachment (if their chunk is loaded). ComputerCraft allows / provides computers for Minecraft. Should those computers be Tandy TRS80's using 300 baud modems and talking to BBS's forever, or should they progress to relatively modern computers, with relatively modern capabilities? Wireless range is a realistic limitation, I agree. I just think that once you have wirelessly connected to a Virtual network (or virtual internet) you should be able to use it as such.
Everyone thinks I am trying to bypass the wireless range. I am only trying to have a way that my inventory computers can look at a file in real time, and tell me what I have in inventory. If that data is on one computer, and that computer is in an unloaded chunk. My data is not available. Repeaters only work if they (and the target Computer) are in loaded chunks. Providing hundreds of repeaters is acceptable, but employing hundreds of world anchors is not. If I have 30 locations, and each location has a computer looking at the same data, my problem is solved, because wherever I go, the chunk is loaded, and the data is available. The range limitation of wireless is not the problem, the distance from a loaded chunk is. Even if the wireless range was infinite, my data would not be available if it is stored in an unloaded computer. how realistic is that. woops, Texas just unloaded so I can't get to my data, or maybe just one of the repeaters between here and there unloaded, either way, I cant get to it. I'm all for the wireless range limitation, it's a good thing. if we could just get the signal to work in an unloaded chunk, I would be happy.

If I had the money to buy a server, I would not be playing games on a computer. I would be out riding snowmobiles, or motorcycles, or something much more fun.
Edited on 09 December 2014 - 02:49 PM
KingofGamesYami #21
Posted 09 December 2014 - 03:46 PM
See, the thing is, irl we built an internet. We have internet hubs, and connections. We have wifi routers, and satellites. In computercraft we have wireless modems (wifi routers), computers (internet hubs), networking cable (connections) and wireless turtles serve as satallites.

I see what you mean about unloaded chunks though, I'm not sure there's any way to get around a basic game mechanic - and should we? The game unloads chunks for a reason - our computers cannot handle it if they didn't. Have you ever been on a server where several players operate chunkloading devices? It'll start out nice, then as more and more people chunkload, the server slows down. Eventually, chunkloaders are banned or limitied to one per player.
infinitebrainspace #22
Posted 09 December 2014 - 04:20 PM
I don't think chunk loaders are the answer either. and I don't believe the game should have more than the immediate chunks surrounding a player loaded all the time. That's why this is so frustrating for me. I have explained my point (to death), and it seems that it's just not going to get anywhere. So be it. I think I will just use the cloning process to create the VPN routers, and see if I can make my own VPN network. I think I can place vpn routers in place of repeaters, so they will HAVE to be within wireless Range of each other, but not necessarily in loaded chunks. The target Computer on the other hand, will have to be Loaded, so it will have to be in the world spawn chunk. A bunch of VPN repeaters spreading out from the "hub" to each location… sounds like a Client-server network to me. Since each VPN spoke will be on a separate net, they will not interfere with each other as they get close to the hub. and I can have xyz coordinates in a file to determine if they are in range of each other or not (shared folder) If both the client and the server are both within range of the ends of the spoke, the connection would be valid, and communication possible (even if the vpn repeaters in between are not loaded). The hub will have to be able to send / receive information from any one of the spokes, and reply back to the appropriate one. Here's where the wireless signal duration gets tricky. I don't know how long a signal stays in the queue before it gets lost (or does it ever get lost). It wouldn't be an issue between the first node of the spoke, and the last, or between the client, and the first node, but between the hub and the multiple last nodes would be tricky. I can imagine that the spokes may branch at times also (going to other locations), so I will have to accommodate for that. I may have to use something similar to an IP address for the clients, so they get the information they asked for. This should be fun.
I'll keep you all posted on my progress.
Edited on 09 December 2014 - 03:31 PM
Cranium #23
Posted 09 December 2014 - 04:32 PM
You're not creating a VPN, or anything that's realistically transmutable to the real life. What you're doing is quantum linked computers, where they DO magically link their files, without having to do what real computers do, and pull information from a central database. Those files aren't magically there, they're hosted on a computer somewhere, and wired networks transmit that data to your various devices, and wireless modems retransmit that data to anything wireless.

We have exactly what you need to build what you're doing, and in a much more realistic way. If you are worried about chunks being unloaded, and destroying a repeater network, you can always increase the modem range. Remeber, chunks near spawn never unload, so that's a great place to put any networks.
Lyqyd #24
Posted 09 December 2014 - 07:55 PM
In fact, everything needed to keep files synced across multiple devices in ComputerCraft has already been programmed! Yes, you'd have to keep routers chunk loaded if you wanted it to work across a large area, but it is certainly already possible.
infinitebrainspace #25
Posted 09 December 2014 - 10:15 PM
You're not creating a VPN, or anything that's realistically transmutable to the real life. What you're doing is quantum linked computers, where they DO magically link their files, without having to do what real computers do, and pull information from a central database.

So the existing wireless system does not use Quantum linking, it really uses a wireless transmission to talk to another computer. there are no files in the ROM folder that multiple computers share during this non-quantum wireless communication. The only difference between what I'm suggesting and what is currently happening, is that I don't have read/write access to the ROM folder, and I'm OK with that. as long as we agree that its ok for the developer to use quantum connections, but not me. I also agree that it is totally possible to accomplish this using chunkloaders. Its just not practical, and it kills the server. I'm not suggesting that we lowly users have open access to the ROM folder, It was just a suggestion that maybe something could be done to allow transmission through unloaded chunks. As long as a repeater was placed within range of another, it could transmit (however that is done at the ROM quantum level) across unloaded chunks. The devices must still have been placed, and if removed, the signal would be interrupted. also it would require both the sender and receiver to be in loaded chunks. at least this would limit the number of chunkloaders needed. Are you saying that because the users know the chunks are unloaded, it becomes a quantum connection? or just because I happen to be quantum linking at a visible level instead of doing it behind the scenes? My choices are a) use as many chunkloaders as it takes and kill my server. b)try to convince the developers to implement a device that resolves this issue without negating the wireless range limitation, or c)hack a solution on my own. Choice a is not going to happen because I want my server to be up more than it's down. I'm currently working on b, but it seems like I'm spinning my wheels, so it looks like c is going to win this one. Maybe if I develop something (visibly quantum) that works within the wireless range limitation, and still transmits across Unloaded chunks BETWEEN the sender and receiver, it may get implemented at the developers invisible quantum level. Probably not, but one can hope. I better get started on my requirements specification.
valithor #26
Posted 09 December 2014 - 10:29 PM
-snip

ROM is similar to buying a computer with software installed. While it may be same as another computer if edited the changes are not made to every computer. By modifying the ROM you are in a way changing the software that comes on the computer (not linking them).

In game no one has access to the ROM, whether it be dan or some new person who is just using the mod for the first time. With that said anyone can add programs to the ROM through resourcepacks (yes you can install resources packs to a server). The solution to the problem you are trying to face is the exact same irl and in the game. You need to write a script that will synchronize files between a number of computers, this script will likely implement the modemn api. Your range problem is the exact same as in the real world, except for the fact that areas of the mc world can be unloaded. A way around this would be to just increase the rednet range in the config.

Solution: Increase rednet range so all computers are within range of each other, and write a script that will sync files.

On a server putting up relay systems become impractical, and the only way for rednet use to be practical is to increase rednet range.

Everything needed to do this is already in the game, so support is very unlikely to be added.
Edited on 09 December 2014 - 09:38 PM
Dragon53535 #27
Posted 10 December 2014 - 01:01 AM
–snip–
There is no need for quantum linking computers over a long distance, for the average CC user, everything they'll really want is within a 50 block radius, so it's unlikely that anyone other than you will NEED to port files over a large distance. You could, pop into creative and just copy the computer, but as you already said, you don't want to do that. Basically, you're saying, I don't want to use the solution that's already available to me, and instead I'll try to convince the mod creator to take time out of his day to code something that I specifically want.

Now, off rant. There are three known ways to do what you want.

A: Creative, you don't want to do this, but it's there.
B: Wireless repeaters, again, you don't want to do this, but it's for other reasons.
C: Using a bug that will be fixed in probably the next CC version. Not saying exactly what it is.
Edited on 10 December 2014 - 12:02 AM
infinitebrainspace #28
Posted 10 December 2014 - 01:55 AM
Such a great addition to Minecraft. I find it hard to believe I'm the only one that has locations spread out over large areas. Maybe this game isn't for 57 year old men that want to play in the sandbox. OK, I give. I could argue this point forever, but while I'm arguing, my carrots aren't growing.
valithor #29
Posted 10 December 2014 - 02:45 AM
Such a great addition to Minecraft. I find it hard to believe I'm the only one that has locations spread out over large areas. Maybe this game isn't for 57 year old men that want to play in the sandbox. OK, I give. I could argue this point forever, but while I'm arguing, my carrots aren't growing.

Although this suggestion is useful, as many have said it breaks the fourth wall. Many people here, if this was implemented would love it, but something like this just is not possible in the real world. The internet has limitations, which include wifi not being everywhere, wifi having range (similar to rednet having range), and the rate data is transfered is not instantaneous. Because of these limitations no two computers will have the exact same thing at the same time, so the ability to clone a computer does not even have a chance. Although if you were to suggest the ability to clone the current programs of a computer onto another one that may have a chance (when you are crafting the new computer). The continuous sync of programs on multiple computers definately does not.

That being said you can accomplish what you are wanting through rednet, and since you said you are on a server and dont want repeaters. You could increase rednet range to accomidate your needs.

old postAdding something like this to the game would break the mod. Even in real life what you are talking about is impossible, so why put it in a mod that trys to be realistic? You can recreate the internet from irl with a little work with the rednet api, but even the internet has limitations (there is not wifi everywhere, it has a range, data transfer is not instantaneous). Unfortunately as I said it requires work, which most people are not willing to put forth.

The only reason this suggestion is being disregarded without a second look is the fact as many have said previously it breaks the fourth wall. This suggestion is just not possible in the real world.

While this suggestion would be incredibly useful it is just not realistic, and as a result little to no chance of being added.

My suggestion still stands, write a script that allows sharing files, and increase range. As you said earlier you are on a server, and from my experience managing a server, you almost have to increase rednet range for it to be useful. Putting up rednet relays is just unreasonable, as they have to be loaded to work. By increasing rednet range to a extremely high number any computer any where in the world can comunicate with another.
Edited on 10 December 2014 - 02:00 AM
infinitebrainspace #30
Posted 10 December 2014 - 04:01 AM
it only breaks the fourth wall if I do it. not if its done by the developer.
I also suggested that by using the quantum link (the developer) could include a repeater that would
cross unloaded chunks, and still require them to be within range of each other. again, the methods used to even have wireless communication are all at the quantum level already. I'm suggesting those methods be used in a way that allows communication over unloaded chunks. I've conceded the issue of cloning. It breaks the darn wall. I've conceded the issue of shared files. It breaks the fourth wall, Both of these issues are aimed at one thing, getting my information across unloaded chunks. I don't know if I can increase the wireless signal to go 3000 blocks, and if so, will it cross over unloaded chunks (im sure it will, since it is quantum linking)?
I would love to use repeaters if I could make just the block they are on stay loaded without a whole chunk having to be loaded as well. It really doesn't matter anyway. I'll just stay in my 50 block radius and grow carrots. Better yet - I'll program a mele turtle to mow my grass, while I tip cows over and race pigs around the perimeter.
Edited on 10 December 2014 - 03:29 AM
theoriginalbit #31
Posted 10 December 2014 - 07:02 AM
I also suggested that by using the quantum link (the developer) could include a repeater that would cross unloaded chunks, and still require them to be within range of each other.
Rednet messages over both Wireless and Wired networks can be received over unloaded chunks. All it requires is both ends be loaded.

I don't know if I can increase the wireless signal to go 3000 blocks
of course you can, look in the config

I would love to use repeaters if I could make just the block they are on stay loaded without a whole chunk having to be loaded as well.
this is impossible in the world of Minecraft, chunks are the smallest that can be loaded.
Edited on 10 December 2014 - 06:04 AM
valithor #32
Posted 10 December 2014 - 10:05 PM
it only breaks the fourth wall if I do it. not if its done by the developer.

It would break the fourth wall no matter who did it. In no circumstance is it possible for a program being edited on one computer, be simultaneously edited on another. Which is the only reason the developer does not even think about adding things like this. He wants to be at least somewhat realistic. Just to clarify the developer as no more access to the ROM than anyone else while in the game, and everyone has the exact same amount of access as the developer to the ROM out of the game (through resource packs). The ROM is basically a set of software that is installed to all computers, and since this software never changes while the game is running does not break the 4th wall.

The internet though gives a way to update things on other computers, but this is not done simultanoeusly/instantly.

I don't know if I can increase the wireless signal to go 3000 blocks, and if so, will it cross over unloaded chunks (im sure it will, since it is quantum linking)?

No increasing the rednet range is not quantum linking. What everyone means when they use the term quantum linking is that the computers always have the EXACT same thing on them. Increasing the rednet range just gives the possibility of writing a script to update the files.

Although it is not quantum linking, yes it will cross over unloaded chunks. As long as the two computers in question are within the range that you set they will be able to communicate, even if they are in the only two chunks loaded in the entire server.
Edited on 10 December 2014 - 09:08 PM
Agent Silence #33
Posted 10 December 2014 - 10:48 PM
You could achieve this by taking advantage of pastebin.
Edit fs.open()'s exit and flush functions to save it to a pastebin code that expires in 2 minutes and then send that code through rednet to a computer. Then make that computer save all codes under protocol "pasteLink" to a program with the same name as the pastebin link.

BY THE WAY :

Technically speaking, it wouldn't be breaking the forth wall if the quantum mechanic of entanglement were to be in play. And since dan200 also made qCraft, he could make a hidden compatibility with CC to connect two IDs. Because you *HYPOTHETICALLY* can entangle the bit modules of a computer to another computer.
Edited on 10 December 2014 - 09:56 PM
Lyqyd #34
Posted 10 December 2014 - 11:11 PM
If you're sending the pastebin code through rednet, you should instead be sending the file contents through rednet. There's no reason to use pastebin if you have rednet connectivity.

This thread seems to have wandered significantly. I may split it into two threads at some point soon.