+- Forums - Open Redstone Engineers (https://forum.openredstone.org)
+-- Forum: ORE General (https://forum.openredstone.org/forum-39.html)
+--- Forum: Projects & Inventions (https://forum.openredstone.org/forum-19.html)
+---- Forum: Completed Projects (https://forum.openredstone.org/forum-21.html)
+---- Thread: intOREnet is finally here! (/thread-11490.html)
intOREnet is finally here! - slugdude - 12-25-2016
Nope, today is not April 1st.
Introduction
I sincerely apologise for the delay, but I'm lazy and good at procrastinating and partly busy with schoolwork -- but it's here now! I will start placing the routers and wires on the plots to which I already have permission later today. A map can be seen here: https://docs.google.com/spreadsheets/d/10LVhXGYJ5rgfqjgyeJRmLAwKTy2QwjaCFSBoDRxUUAw/edit?usp=sharing
(For some stupid reason Google Sheets won't work for me on Chromium. If you have the same problem try Firefox, works for me there)
Please note that this map has not been updated for a while so there are likely more plots that belong to new people that are not on this list. It would be really handy if staff could fix Dynmap as it makes keeping the map up to date way easier. Never mind, it works but it's just not map.openredstone.org anymore.
If anyone has an issue with their plot status on the map, speak to me in-game or alternatively by forum PM, preferably not in this thread.
This post will serve as an introduction to what intOREnet is, how to use it, and if you're interested, how it works, in full. I will be answering questions below but please keep "m9 can I be coonectereded pl0x" to in-game messages, or forum PMs. I will also be editing this post to add to it if things change, such that this becomes like a one-stop place for intOREnet information.
Before I proceed, I must say that I have not built LAN hardware yet. I will some time after January 2017 (got mock exams), and you can still use intOREnet without it, but you will be limited to one device per person (though if you're feeling adventurous, you could make your own LAN hardware and I'd be happy to help. Speak to me if you're interested).
"So - what is intOREnet?"
As the very punny name implies, intOREnet is an ORE internet. It is often abbreviated to iOn.
"But what can I do with it?"
Pretty much anything involving sending messages over large distances, much like the Internet in real life, but slower.
"Why would I want it?"
Because it's fun, and my vision is for it to inspire more redstone innovation. I've already heard people's plans for intOREnet devices, such as an email server, a file server and even multiplayer games over intOREnet (though with that last one, intOREnet will be very slow so it's probably mostly limited to turn based games.)
"Won't it be laggy?"
Maybe. Because PlotSquared (our plot plugin) does not allow pistons to push over plot boarders, I am limited to using hopper chunk loading. Besides, the pistons weren't very good at keeping the fairly large routers loaded for long enough for them to process. Hoppers should be more reliable with the drawback that they would need to keep the chunks loaded permanently. However, I will keep to the promise I made to staff when I started this project, that was that if intOREnet created noticable performance impacts then I would have to remove some or all of it.
But, consider this - the server render distance seems to be about 11, which means that a single person keeps a 22*22 chunk area (because 10 is the distance from the player, not the length of the area so double it) loaded which is 484 chunks. Imagine those chunks arranged in a line, the length of that line in metres would be 484*16 = 7744m. So 7.7km of wire could be loaded with no extra lag than another person coming online. That's a lot. Plus, I hear our new build server is really powerful.
There's only one sure-fire way of finding out if it's an issue though.
"Wait wait wait - what about the lag created by the redstone?"
The routers are designed to do absolutely nothing while idle, so no updates (not even a clock). I am not using instawire, because when it's slower it's easier on the server. In early tests last year I found instawire to be too laggy whereas normal wire had no issue. So nothing will even happen on intOREnet if nobody is sending packets. And I anticipate that packets won't be sent *that* often anyway.
"Will there be intOREnet on the school server?"
Unfortunately not. The plots on school are a mess with many people inactive, who I can't contact. Since I require a plot owner's permission to build on their plot as Nick and the other staff made sure, it would be near impossible to connect.
"Why can't school people just claim a bunch of plots in the corner?"
Because the hopper chunk loading requires a direct connection to spawn chunks. Hence why I made sure I got a plot next to spawn on the new 1.8 world regen.
"How do I get started?"
Well, first your plot needs to be connected. If you want to be connected, first check the map. If your plot is bright green it means you've already asked and intOREnet will be rolled out to you eventually. If it's dark green, then you've asked, but intOREnet can't reach you. You can move your plot to one of the pink plots (if they're still free - map is outdated) if you want to (but let me know so I can update the map).
Once you have intOREnet connection, you must know a few things to start making intOREnet compatible devices, which brings me on to:
Usage guide and guidelines
Before I proceed, there are a few rules about devices on intOREnet and if I find anyone breaking them, I will disconnect you either temporarily or permanently.
- Don't send data to someone unless you know they are correctly set up to receive and process it. If, for example, you send printer data to someone's email receiver, then they will just get a bunch of gibberish. I highly recommend, if you make a device, you incorporate some sort of system to check if the data is legit. You could possibly whitelist certain addresses to make sure you only receive data from those addresses.
- Don't send gibberish on intOREnet. This can clutter up the network, make it slower for everyone else, confuse the routers and even cause damage to other people's devices. This will not be tolerated.
- Leave a reasonable gap between packets. While this won't actually break anything it's a good guideline to follow since if you send a packet to a router, then send another packet before it's done processing, the second packet will either be dropped or get cut in half and sent like that, which would count as gibberish. The current-gen routers may take up to 100 ticks to process a packet before it's ready to receive another. If this is too slow for you then tough. At some point in the distant future I will create a better router, but these ones work for now.
- No tampering with intOREnet hardware beyond your LAN (or single device, if LANs still aren't a thing and/or your device is plugged directly into the net) unless I have authorised it. This can seriously mess up the router's routing tables and all of the routers' routing tables across the network may need to be reset which will take a long time.
- Never send packets addressed starting with 000. These are special packets designed for address designation and can mess up the network. The LAN hardware in the future should prevent this but it does not exist yet so... just... don't.
- (If RS technology gets there) Malware is allowed for testing and proof-of-concept only. Malicious attacks on other users will not be tolerated.
- No attempting to spoof your source address.
- No tampering or expanding the chunk-loading hoppers without my permission.
- If I tell everyone to stop sending stuff for a while, stop sending stuff! It's important.
- No DDoSing!
First, some terminology that I will use:
Packet: How you send data on a network. Contains at least a destination address, a source address and the data you want to send.
Router: These devices decide which direction each packet should go in order to reach it's destination.
LAN: Local Area Network. It consists of any devices connected to each other locally before the connection to intOREnet.
Dropped packet: A packet that is discarded and not sent.
Protocol: Defines how devices must construct the packet to understand each other
Encapsulated: When you have a protocol within the data section of another protocol.
Collision: When two or more packets reach a router at similar times.
Acknowledgement: A way to make sure your packet was delivered.
Address: A unique number associated to each device. (I know it can mean other things on the real internet but I'm keeping this noob-friendly.
-----------------------------------------------------------------------------------------------------------------------------------
Firstly, you must know that packet delivery is not 100% guaranteed. If a collision occurs with a packet you sent, the packet may be dropped and you will not be notified. If your data needs to be delivered, you will need to have an acknowledgement system in place.
Packets on intOREnet are sent on a single wire, as 1 bit per tick (or 10 bps, bits per second) serial. The first bit is always a 1 (known as a lead bit, to let devices know that a packet is coming.
Lets move on to the protocol every intOREnet device must use, which I call FLiP (Fixed Length intOREnet Packeting):
![[Image: mhaRp43.png]](http://i.imgur.com/mhaRp43.png)
The above image illustrates how a FLiP packet should be constructed. The unused flags are there because in future iterations of intOREnet they will be used to ensure backwards compatibility. Also, the one awkwardly shoved between the two addresses is because initially it was a lead bit because my previous router design required one there too. (it was terrible, don't ask).
The addresses are comprised of three parts. The first two make up the address of the LAN you wish to send to (don't worry about the fact there's two parts as it's not important for using intOREnet. The last three bits say which device on the LAN you want to send to (if someone has a device connected directly to intOREnet and not via a LAN then they will receive any packet addressed to anything on that 'LAN').
The source address should always be the address of the sender. LAN hardware in the future may be able to prevent you messing up the first 7 bits of the source address, but as LANs aren't a thing yet, you will need to make sure this is right. Spoofing this is against the rules.
Finally, the data section can contain anything that you want the recipient to receive. The routers will not read the data and will not alter the packet at all.
It is a packet structured like this *must* be what leaves your device otherwise intOREnet will not understand how to process it and will count as gibberish as far as the rules go. Also, it is a packet like this that will arrive back at your device.
Your connection to intOREnet is just two data wires and hoppers for chunk loading. If you have LAN hardware then you may have up to 7 sets of 2 wires, for up to 7 devices. One wire is for sending data, the other is for receiving.
There are also special addresses. 1111111XXX will send to the XXX device on your LAN (like 192.168.X.X in real life), and 1111111000 can be used as a loopback address (like 127.0.0.1 in real life). As such, no-one will have the LAN address of 1111111.
Sending to addresses starting with 000 is strictly forbidden.
While you can just send raw data to wherever you need it, I don't recommend it. Instead, I suggest you create your own protocol and encapsulate it in a FLiP packet. This will allow others to also use the same protocol and easily differentiate between different protocols. Yay for standardisation. There should be a commonly used protocol that has an identifier to tell it what kind of data it carries and lots of people should use this. I won't be enforcing a system like this but I highly recommend it. This will also make it easy to reject data that you don't have the means to process.
That's pretty much all you need to do to use intOREnet, but I know many of you will be interested to know what happens to your packet after it is sent, and for you, I move on to:
Explanation of how it works
It does not matter if you do not understand this section - it is not required for using intOREnet.
The physical topology for intOREnet is a partially connected mesh, with a LAN (or not, if they still don't exist) on each node.
The way routers on intOREnet route is that they all have 4 connections. One to the North (00), one to the East (01), one to the south (10) and one to the West (11). When it receives a packet, it looks into it's memory (it's routing table) and picks out two bits that match the destination address of the packet. These two bits tell the router which direction it needs to send the data in.
But there's a twist: Having a memory slot for every single address would make the routers an insane size. So instead, intOREnet will be broken down into 7 areas, each with 15 LANs on it (except for area 111, which will have 14 LANs). The area is what is called the prefix in the FLiP illustration above. So, when a router receives a packet, it first checks to see if it it destined for a LAN in the same are as it (which is hardcoded into each router). If it does, it routes as normal. If it does not, it routes the packet 'in the general direction' of the area it is destined for. This drastically reduces the size of the routers and by extension the speed (due to memory latency).
So how does it know where to send it?
When a new node is connected then a special packet addressed to 0000000000, and the source address of the address that is to be used, must be sent out. When a router receives this. it acts very differently from normal. First, it checks to see if the source address's area matches it's hardcoded area. If it does, it takes the direction the packet came from and tries to store it in it's routing table. If there is already an entry for that address, it discards the packet and stops. Is there isn't then it proceeds to send the packet in every direction.
If the area does not match, then it will do the same, except it will store for the 3 bit address of the area instead of the 4 bit address of the LAN. The result is every router on the net now knows the optimal route to get to that address. The upside is that this method does not require complicated routing calculations. The downside is that all network traffic must cease otherwise collisions will interfere (and the odd quirk that two routes to the same must not equal each other in terms of ticks).
When a collision occurs at a router, the first arrived packet will get processed (even if they were only one tick apart). The second packet gets dropped. If they arrive in the same tick, both will be dropped. The collision system in intOREnet is not very good and I will be improving it over time. But for now, it works, and I didn't want to delay the project any more.
Summary
I'm sorry this took so long. Over the next few days (possibly weeks if things pop up but hopefully days) I will start laying down the intOREnet wires and routers.
Happy intOREnetting.
RE: intOREnet is finally here! - Dcentrics - 12-25-2016
heheh k
RE: intOREnet is finally here! - Laythe - 12-26-2016
Gratz slug!
I never thought I'd see the day.
RE: intOREnet is finally here! - Halflife390 - 12-26-2016
About time :
RE: intOREnet is finally here! - Matthew - 12-27-2016
13:11 below paukku!! HOOK ME UP BABY!! lol
honestly tho this is impressive as fuck
RE: intOREnet is finally here! - LordDecapo - 12-27-2016
btw, that slugdude piston cpu thing plot.. that wire is like the intercoastal wires we have between NA and EU
RE: intOREnet is finally here! - slugdude - 12-27-2016
(12-27-2016, 01:08 AM)Matthew Wrote: 13:11 below paukku!! HOOK ME UP BABY!! lol
honestly tho this is impressive as fuck
(12-25-2016, 09:41 PM)slugdude Wrote: please keep "m9 can I be coonectereded pl0x" to in-game messages, or forum PMs.
RE: intOREnet is finally here! - slugdude - 12-27-2016
(12-27-2016, 01:13 AM)LordDecapo Wrote: btw, that slugdude piston cpu thing plot.. that wire is like the intercoastal wires we have between NA and EU
Mmhmm I *totally* didn't make up some random project to get another plot because some asshole testificate was threatening to claim that plot.
PistonCPU will actually be a thing tho once I finish all this intOREnet shizzle.
RE: intOREnet is finally here! - qwerasd205 - 12-27-2016
So here's an idea for a standardized protocol declaration packet:
A: I'm trying to connect to you, are you alive? (A ping)
B: I am alive. (A pong)
B: are you alive? (A ping)
A: I am alive. (A pong)
*Please note that for every packet beyond this point the other client responds with an acknowledgement. If no ack is received the packet is re-sent*
A: I want to use protocol X do you support it? (2 packets: protocol request, and protocol declaration)
B: Yes, I do support protocol X, I run protocol X with Y and Z specifications (1 packet: Yes I do support protocol X. N packets: specifications)
A: Okay, I'm beginning now. (1 packet)
RE: intOREnet is finally here! - slugdude - 12-27-2016
UPDATE!
The first successful message was sent on intOREnet today on a small-scale test between my plot and Qwerasd's, involving two routers. Everything is functioning as normal and I will soon be placing *a lot* of wires.
![[Image: 3XGvKCS.png]](http://i.imgur.com/3XGvKCS.png)
Naturally, I hooked my receive up to a firework dispenser.
RE: intOREnet is finally here! - qwerasd205 - 12-27-2016
(12-27-2016, 05:12 AM)qwerasd205 Wrote: So here's an idea for a standardized protocol declaration packet:
A: I'm trying to connect to you, are you alive? (A ping)
B: I am alive. (A pong)
B: are you alive? (A ping)
A: I am alive. (A pong)
*Please note that for every packet beyond this point the other client responds with an acknowledgement. If no ack is received the packet is re-sent*
A: I want to use protocol X do you support it? (2 packets: protocol request, and protocol declaration)
B: Yes, I do support protocol X, I run protocol X with Y and Z specifications (1 packet: Yes I do support protocol X. N packets: specifications)
A: Okay, I'm beginning now. (1 packet)
After B responds with specifications there should also be a "That is all" packet
RE: intOREnet is finally here! - LordDecapo - 12-27-2016
(12-27-2016, 04:27 AM)EmpirerBAD Wrote: EUREKA! - reliable 10 bps transmission between an ADC & DAC (until there is another problem...)
just ironed out the problem with my keyboard data transmission. Put dust after the locked repeaters in the mux and every key is mapped correctly! Global email is on the way... when there is support for "connection switching" as upposed to "packet switching" in Intorenet (may just run email as a separate network?)
NEW DOWNLOAD (you won't regret it).
https://www.dropbox.com/s/3929kqhm34l0h07/2017%20keyboard%20raw%20data%20transmission%2010%20bps%20fixed.zip?dl=0
The mux engine got a warm-up fn to smooth some irregularities out
Algorithm for encoding the keyboard raw data to a 5-bit code exists, but I haven't made a presentable setup of it.
![[Image: qDPDcJn.png]](http://i.imgur.com/qDPDcJn.png)
STOP posting like this.
This is NOT rrelated to OP, you are NOT OP...
Make your OWN post for your OWN stuff... don't clutter others posts with your stuff.
This is your warning..
RE: intOREnet is finally here! - Koyarno - 12-27-2016
And you're posting this in public capo where a private message would have sufficed.
@slug you have every permission to run lines/edit my plots for your system
Also looking forward to improvements in the future and maybe i will reverse engineer it some time.
RE: intOREnet is finally here! - LordDecapo - 12-27-2016
(12-27-2016, 03:24 PM)Koyarno Wrote: And you're posting this in public capo where a private message would have sufficed.
@slug you have every permission to run lines/edit my plots for your system
Also looking forward to improvements in the future and maybe i will reverse engineer it some time.
shhh koy shh
ps. hi
RE: intOREnet is finally here! - qwerasd205 - 12-27-2016
Okay after some thoughts.
Here's a better packet exchange for protocol identification.
--
Total success:
A: Ping!
B: Pong!
B: Ping!
A: Pong!
A: This is a protocol request
B: Affirmative
A: For protocol X
B: Yeah, I use version Y
A: Okay I'm starting transmission now.
--
B online but does not use protocol X:
A: Ping!
B: Pong!
B: Ping!
A: Pong!
A: This is a protocol request
B: Affirmative
A: For protocol X
B: Oh, I don't have protocol X support (all 1s in the data.)
A: Okay, carrying on.
--
B is not online:
A: Ping!
B: ...
--
B is online but A isn't reachable:
A: Ping!
B: Pong!
B: Ping!
A: ...
(After a few failed pings from B):
B: Not getting a pong, terminating connection.
--
Keep in mind with all of these after a timeout if no ack is received a new packet is sent, after a few failed packets (no response) a termination is sent.
RE: intOREnet is finally here! - jxu - 12-29-2016
Update the map, my neighbor (the only person in between me and sweet internet access) is wrongly listed
Also how did you know I wanted to participate?
It doesn't matter if he doesn't agree. Just dig underneath his plot, like the elaborate tunnel system underneath my old old plot. The RDF one. Good times with rsw.
RE: intOREnet is finally here! - PersonUser519 - 12-29-2016
What is the address based on? Is it a random binary string, is it related to a fixed address?
RE: intOREnet is finally here! - slugdude - 12-29-2016
(12-29-2016, 07:58 AM)͝ ͟ ͜ Wrote: Update the map, my neighbor (the only person in between me and sweet internet access) is wrongly listed
Also how did you know I wanted to participate?
It doesn't matter if he doesn't agree. Just dig underneath his plot, like the elaborate tunnel system underneath my old old plot. The RDF one. Good times with rsw.
I'll update the map when I get a chance.
I'm not allowed to do that, says Nickster.
RE: intOREnet is finally here! - lollershihi - 12-30-2016
To reduce the amount of dropped packets, why don't you send a packet into a "loop" at the entrance of a router if another packet is being "processed", and give it a "second chance" about 56 ticks later?
RE: intOREnet is finally here! - tokumei - 01-01-2017
Or use a queue.
RE: intOREnet is finally here! - Koyarno - 01-02-2017
I think those were later goals slug wanted to address. I guess that the busy routers could have additional buffers (or 1 for each direction) and/or processing multiple packets at once. It is not impossible, it just requires a lot of timing and planning.
My take on it:
- 1 input buffer NESW shared, 1 output. so 1:1. Can only handle 1 connection well without dropping packets.
- >= 2 input buffers NESW shared, 1 proces. so 2:1 Can handle more connections at once without dropping packets.
- 4 directional input buffers, 1 proces. 4:1. Same as above but a bit easier to make i guess
- 4 directional input buffers, 4 processes so 4:4. pretty much a router on steroids. Each direction can handle its own address calculation but this does require many decoders, a 4:4 crossbar and cooldown clocks.
As it is right now, the routers can only handle 1 connection and collision detection is pretty poor. Long way to go still
RE: intOREnet is finally here! - slugdude - 01-03-2017
(01-02-2017, 11:46 AM)Koyarno Wrote: I think those were later goals slug wanted to address. I guess that the busy routers could have additional buffers (or 1 for each direction) and/or processing multiple packets at once. It is not impossible, it just requires a lot of timing and planning.
My take on it:
- 1 input buffer NESW shared, 1 output. so 1:1. Can only handle 1 connection well without dropping packets.
- >= 2 input buffers NESW shared, 1 proces. so 2:1 Can handle more connections at once without dropping packets.
- 4 directional input buffers, 1 proces. 4:1. Same as above but a bit easier to make i guess
- 4 directional input buffers, 4 processes so 4:4. pretty much a router on steroids. Each direction can handle its own address calculation but this does require many decoders, a 4:4 crossbar and cooldown clocks.
As it is right now, the routers can only handle 1 connection and collision detection is pretty poor. Long way to go still
With multiple processes, you'd have to worry about collisions occuring when two or more packets are sent in the same direction, so like there would be two or more packets coming out of the same router in the same direction at the same time -______- effort.
RE: intOREnet is finally here! - Koyarno - 01-03-2017
That is the point of those clocks/timers; one for each direction. you cannot send while the clock is still active and there has to be some priority given for another packet if there are multiple competing.
RE: intOREnet is finally here! - slugdude - 01-04-2017
Actually with my current method of processing the packet that wouldn't be too hard on second thought.
Also update: Sorry for the delays in iOn rollout, after the aPuly WE derp, I couldn't do stuff until it was sorted, then I kinda forgot and now I got school stuff irl to worry about. But don't worry, I'll still be doing this when I get the chance.
RE: intOREnet is finally here! - LambdaPI - 01-04-2017
Can you implement TCP/IP?
RE: intOREnet is finally here! - LambdaPI - 01-04-2017
Also, I would love to be connected, but I am far away and yea. Sadness. If you can put some wires over unclaimed plots, that would be good and I would be connected
RE: intOREnet is finally here! - slugdude - 01-05-2017
(01-04-2017, 05:59 PM)LambdaPI Wrote: Also, I would love to be connected, but I am far away and yea. Sadness. If you can put some wires over unclaimed plots, that would be good and I would be connected
I'm not allowed to use unclaimed plots.
RE: intOREnet is finally here! - jxu - 01-05-2017
(01-05-2017, 08:55 AM)slugdude Wrote:(01-04-2017, 05:59 PM)LambdaPI Wrote: Also, I would love to be connected, but I am far away and yea. Sadness. If you can put some wires over unclaimed plots, that would be good and I would be connected
I'm not allowed to use unclaimed plots.
Claim eminent domain
RE: intOREnet is finally here! - LambdaPI - 01-06-2017
Rip lam 2k16
RE: intOREnet is finally here! - LambdaPI - 01-06-2017
Unless i casually claim 5 more plots
RE: intOREnet is finally here! - slugdude - 01-06-2017
(01-06-2017, 08:30 AM)LambdaPI Wrote: Unless i casually claim 5 more plots
Or just one.
Next to Laythe, Maze, or my pistoncpu plot maybe?
RE: intOREnet is finally here! - LordDecapo - 01-06-2017
Or you can just build on one of my plots...
Or capo can get more plots and I'll claim the stretch of plots over to urs
lol
RE: intOREnet is finally here! - Koyarno - 01-06-2017
^ all the more room for me to build architectural stuff on it :p
RE: intOREnet is finally here! - Apuly - 01-10-2017
(01-04-2017, 05:55 PM)LambdaPI Wrote: Can you implement TCP/IP?
I'm hoping you're talking about a modified version of TCP?
Sending up to 536870944 bytes of data over intOREnet doesn't sound like a good idea.
RE: intOREnet is finally here! - slugdude - 01-14-2017
Progress update: The reason rollout has stalled is that after Apuly's WE derp, a large area spamming from Rodentman's plot to CDPIV's had all redstone dust removed from it, and wasn't caught in the initial restore from backup. IntOREnet needs to *go in this area*. Inevitably it will get restored, meaning anything I build there will get deleted. Admins are nowhere in sight, so I've been waiting for the last week to talk to anybody.
RE: intOREnet is finally here! - Chibill - 01-17-2017
Slug I can restore it with the back up.... Co knows you placed stuff.... You could have like told us. (Like even in game....)
RE: intOREnet is finally here! - slugdude - 01-17-2017
(01-17-2017, 08:11 AM)Chibill Wrote: Slut I can restore it with the back up.... Co knows you placed stuff.... You could have like told us. (Like even in game....)
>Slut
Also everything is fine now chibill that was posted before we fixed it.
RE: intOREnet is finally here! - Chibill - 01-18-2017
That is like my worst typo on ORE..... does not help it was 1 am but.
RE: intOREnet is finally here! - slugdude - 01-18-2017
(01-18-2017, 05:53 AM)Chibill Wrote: Fuck the typo!
Also the police.
RE: intOREnet is finally here! - embizone - 01-24-2017
Idk how the destination address is resolved but instead of having a big decoder programmed with directions, why not number the plots and use 2 comparators for x and y to route the packet. Think this would make the router half the size. You'd also then only have to program two 4 bit constants on the router instead of redesigning a whole decoder.
RE: intOREnet is finally here! - Apuly - 01-26-2017
That would be:
1: too ezpz
2: not really routing for as far as I know
RE: intOREnet is finally here! - embizone - 01-27-2017
(01-26-2017, 09:18 AM)Apuly Wrote: That would be:
1: too ezpz
2: not really routing for as far as I know
It would be easier and more efficient. Just because the addresses have a predictable pattern doesn't make it not routing.
RE: intOREnet is finally here! - slugdude - 01-31-2017
(01-27-2017, 04:03 AM)embizone Wrote:(01-26-2017, 09:18 AM)Apuly Wrote: That would be:
1: too ezpz
2: not really routing for as far as I know
It would be easier and more efficient. Just because the addresses have a predictable pattern doesn't make it not routing.
Coords each way would need to go up to 40 (20 each way), so I'd have 5 bits, *2 for X/y that's 10 bits, then plus 3 for LAN = 13 bits.
Secondly, it may not always be possible to route straight up/north, say, if the plot north of the router does not have wires on it (say, for example that plot happens to be JeremyG's plot).
Thirdly, it would require a grid of wires which is much more chunks that would need to be loaded.
RE: intOREnet is finally here! - greatgamer34 - 02-06-2017
why can you do a ring network arch?
RE: intOREnet is finally here! - slugdude - 02-12-2017
(02-06-2017, 05:07 PM)greatgamer34 Wrote: why can you do a ring network arch?
Because that's dumb for a large scale network, the signal might have to travel the whole map just to get to the plot behind you...
Anyway, back to why I'm here.
Its no secret that intOREnet is delayed. There seems to be an issue with chunk loading and I can't figure out why.
The hopper loading worked on a small scale test that me and Qwerasd did, but doesn't seem to be working on a larger scale, and I have no idea why. It works in vanilla singleplayer.
Possible suspects (I have no actual knowledge about what may be causing it, these are just guesses):
- Spigot optimizing stuff like not doing spawn chunks properly.
- PlotSquared interfering with chunk loading on a per plot basis.
RE: intOREnet is finally here! - Chibill - 02-12-2017
Or its the fact that in 1.10 you need something with inventory on top of the hopper for it to work. (And you only need one per chunk not a line.
RE: intOREnet is finally here! - Chibill - 02-12-2017
I can a video on it if you need it.
RE: intOREnet is finally here! - slugdude - 02-13-2017
(02-12-2017, 07:22 PM)Chibill Wrote: Or its the fact that in 1.10 you need something with inventory on top of the hopper for it to work. (And you only need one per chunk not a line.
Huh, I'll try that later. Also why can't you just use the hopper's inventory itself?
My testing was in 1.10 though so... :/
RE: intOREnet is finally here! - Chibill - 02-13-2017
in 1.11 they fixed a server tps problem with hoppers.
RE: intOREnet is finally here! - slugdude - 02-13-2017
(02-13-2017, 04:51 PM)Chibill Wrote: in 1.11 they fixed a server tps problem with hoppers.
Details?
RE: intOREnet is finally here! - Chibill - 02-13-2017
I know they played with the timing and stuff. And the youtubers that discovered the chunkloading in all the videos they have a furnace over the hopper. (Looking for a vid now)
RE: intOREnet is finally here! - Chibill - 02-13-2017
It might be that you just need an item in it. (So it tries to look for some where to push) as seen here https://youtu.be/KYba7FqY4LQ?t=17m59s (in 1.8)