33 replies to this topic

[KingofGamesYami]

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]

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 by infinitebrainspace, 09 December 2014 - 04:31 PM.

[Cranium]

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]

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]

Cranium, on 09 December 2014 - 04:32 PM, said:

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]

infinitebrainspace, on 09 December 2014 - 10:15 PM, said:

-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 by valithor, 09 December 2014 - 10:38 PM.

[Dragon53535]

infinitebrainspace, on 09 December 2014 - 10:15 PM, said:

--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 by Dragon53535, 10 December 2014 - 01:02 AM.

[infinitebrainspace]

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]

infinitebrainspace, on 10 December 2014 - 01:55 AM, said:

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 post

Adding 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 by valithor, 10 December 2014 - 03:00 AM.

[infinitebrainspace]

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 by infinitebrainspace, 10 December 2014 - 04:29 AM.

[theoriginalbit]

infinitebrainspace, on 10 December 2014 - 04:01 AM, said:

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.

infinitebrainspace, on 10 December 2014 - 04:01 AM, said:

I don't know if I can increase the wireless signal to go 3000 blocks

of course you can, look in the config

infinitebrainspace, on 10 December 2014 - 04:01 AM, said:

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 by theoriginalbit, 10 December 2014 - 07:04 AM.

[valithor]

infinitebrainspace, on 10 December 2014 - 04:01 AM, said:

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.

infinitebrainspace, on 10 December 2014 - 04:01 AM, said:

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 by valithor, 10 December 2014 - 10:08 PM.

[Agent Silence]

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 by Requiem, 10 December 2014 - 10:56 PM.

[Lyqyd]

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.