Jump to content
  • Sky
  • Blueberry
  • Slate
  • Blackcurrant
  • Watermelon
  • Strawberry
  • Orange
  • Banana
  • Apple
  • Emerald
  • Chocolate
  • Charcoal
  • Announcements

    • Lizzy Trickster

      Latest Stable OpenComputers Version   11/26/16

      The latest released version of OpenComputers is version 1.7 for MC 1.7.10, 1.8.9, 1.9.4, 1.10.2, 1.11.2 & 1.12.1. See more information here! Beta/Dev builds can be found at the Jenkins Build Server (ci.cil.li)


  • Content count

  • Joined

  • Last visited

About MajGenRelativity

  • Rank
    Junior Member

Contact Methods

  • Minecraft
  • GitHub
  • IRC

Profile Information

  • Gender

Recent Profile Visitors

345 profile views
  1. Blockly for OC

    Looks good!
  2. OETF #8 - Allocated Network Card Port Numbers

    148 reserved! Sorry for the delay
  3. OETF #8 - Allocated Network Card Port Numbers

    Added! Thank you for reserving
  4. OETF #8 - Allocated Network Card Port Numbers

    While GERT is almost certainly going to go down to 1 port, I'm going to hang onto a second port reservation just in case I want to split up commands or reservations or whatever to extend the system.
  5. OETF #8 - Allocated Network Card Port Numbers

    As of right now, it does only need 1 port, but I'm holding off collapsing the reservation down fully until v1.0, when I'll know for certain how things work. I've already reduced the reservation by ~1,000 ports though
  6. OETF #8 - Allocated Network Card Port Numbers

    Lol, you must have looked at the GitHub listing. I keep forgetting to remove the reserved ports for my chat program, as it is garbage, and should be rewritten to use GERT. I don't really want to reserve ports for programs that don't even exist as ideas yet, so I'm not sure what to think about your suggestion. If you have a specific program you want a port(s) reserved for, let me know! Edit: Thinking back on my chat program, it's actually pretty ancient (circa 2+ years ago). One of the first programs I ever created. But, I'm removing the reservation because I will revise it to run over GERT which means it does not require its own port reservation.
  7. This is a centralized repository to allow users to communicate on what port numbers their programs use, and to reserve them in an effort to minimize overlap. This is a copy of: https://github.com/GlobalEmpire/GERT/blob/master/Reserved OC network card ports.txt If you would like to reserve a number, please do any of the following: 1. Post in this thread 2. Message MajGenRelativity on Discord 3. Message Gavle on irc.esper.net Currently Reserved Ports: Port 14: Ethernet over OC: Reserved by SolraBizna Port 148: GUI service: Reserved by Dustpuppy Port 4096: MultICE Networking: Reserved by Izaya Ports 4378-4379: GERTi: Reserved by Global Empire Port 9100: Network Print Service: Reserved by Dustpuppy
  8. OETF #6 - Global Empire Routing Technology

    Thank you for your input. The whitepaper will be updated with new information as soon as we hit Release Candidate 1, which should be no more than 2 months away.
  9. OETF #6 - Global Empire Routing Technology

    An updated version of this whitepaper, or instructions to an end-user on how to set up GERTi?
  10. OETF #6 - Global Empire Routing Technology

    The formatting is terrible because I just copypasted it from GitHub do to the fact that the whitepaper won't be finished until the protocol is done. Once we make it to Release Candidate 1, I will be making a video with instructions on how to set up a basic network to play around with, and how to harness the power of GERT for great and amazing things. Please let me know if there is anything else I can do to improve the appeal.
  11. Content taken from GERT Whitepaper hosted at: https://github.com/GlobalEmpire/GERT/blob/master/GERT Whitepaper.txt It's pronounced gurt (as in yogurt) 1. Introduction The time is NOW! With the Ocranet technology impending, it's important to decide on a standard networking implementation to allow for maximum compatibility and ease of use. The Global Empire is actively engaged in promting the growth of new networking standards, and has stepped up to the plate for Ocranet. The time has come for GERT - Global Empire Routing Technology. GERTe is an inter-server networking standard built to maximize the potential of Ocranet, while GERTi is an infra-server networking bringing enterprise grade failure tolerance and end-user simplicity right into your OC computer. 2. Compatability. GERTe (e for external) can be made compatible with any infra-server networking technology, as long as it is Ocranet/GERTe network addressing aware. GERTi (i for internal) can also be made compatible with any inter-server networking technology, as long as it is Ocranet/GERTi network addressing aware. While GERT is designed to be a leading standard for Ocranet technology, the Global Empire encourages enhancements to the system. 3. Technical Terminology A. Ocranet: The base networking protocol GERT is built on. To ensure a minimum level of compatibility, this should be used as the inter server networking standard. B. Gateway: An OpenComputers computer with an internet card that is responsible from connecting an interior infra-server network to an external inter-server (preferably Ocranet based) network. C. GERT: The complete Global Empire Routing Technology package. This has been designed to be the leading Ocranet implementation with a maximum balance of ease of use and flexibility. It may also be referred to as GERTc for clarity. D. GERTe: The Global Empire Routing Technology external implementation. This is solely for communication between minecraft servers, and handles gateway to gateway communication. E. GERTi: The Global Empire Routing Technology internal implementation. This is solely for communication inside a minecraft server using OC equipment. F. GENS: Global Empire Name service Server. Performs a similar operation as a real-world DNS server and translates an Ocranet "telephone" number into a real-world IP address. G. End-user, an OC computer that is connected to a gateway. H. Cell: An Ocranet packet. 4. GERTe operation A. Premise Global Empire Routing Technology external is designed to provide the routing implementation for Ocranet with maximum flexibility, and minimal routing overhead. B. Implementation Overview Ocranet is built on using "telephone" style numbers to allow minecraft servers to communicate with each other. GERTe specifies a way to turn that "telephone" number into a real connection. By communicating with a GENS server at the beginning of a new connection with a server, it internally translates the entered "telephone" number into a real-world IP address for direct communications. C. Gateway Implementation Details Startup Procedure: Upon startup, the Ocranet gateway downloads a real-wrold IP address list of GENS servers. 1a. If download fails, throw error 1b. If download succeeds, continue Operating procedure: 1. An Ocranet gateway receives a request to contact a server with a "telephone" number and, optionally, a port number. 2. The Ocranet gateway contacts a GENS server chosen randomly from the list. 2a. If the GENS server is successfully contacted, proceed to step 4. 2b. If the GENS server is unsuccessfully contacted, begin trying servers in succession from top to bottom. 2c. If no GENS server is reachable, throw error. 3. The Ocranet gateway requests that the GENS server lookup the "telephone" number and return the real-world IP address of the number. 3a. If the GENS server cannot find the "telephone" number, throw error 3b. If the GENS server returns the real-world IP address, store internally for use. 4. The Ocranet gateway attempts to contact the other Ocranet gateway on either the port number provided, or the standard contact port number (tbd). 4a. If the end-point cannot be contacted, try up to 5 attempts. 4b. If the end-point proves unreachable, throw error 4c. If the end-point is contacted, continue. 5. The Ocranet starting gateway transfers data as requested over the connection, and maintains the connection until requested, or 30 minutes elapse. 6. Upon request, the Ocranet gateway transmits a close signal and then closes the connection. OUT OF DATE OUT OF DATE OUT OF DATE OUT OF DATE OUT OF DATE OUT OF DATE OUT OF DATE OUT OF DATE OUT OF DATE OUT OF DATE update coming soon(tm) D. GENS implementation details 1. Maintain table of "telephone" number and real-world IP address pairs. 2. Upon request from a new gateway / other GENS to register a new pair, contact the IP address listed on the selected port with an acknowledgement packet. 2a. If the gateway responds, add / update (in case of "telephone" collision) the pair to table, and proceed to 3. 2b. If the gateway does not respond after 5 attempts, ignore request to add pairing. 3. If the request did not come from another GENS, transmit pairing to other GENS so they can update the pairing. 4. Upon request from gateway to retrieve pairing, lookup pairing in table. 4a. If pairing found, transmit pairing to gateway. 4b. If pairing not found, transmit error to gateway. E. GERTi integration details Transmission Side: 1. GERTi makes use of a 3-digit extension code to an Ocranet "telephone" number, so monitor all outgoing requests for the 3 digit code. 2. Upon recognition of extended length number, strip the last 3 digits from GENS request, and use the extended format cell when in communication with the destination GERTi networked gateway. Reception Side: 1. Strip the 3-digit extension code from Ocranet extended format cell. 2. Use the 3 digits as keys to locate UUID of computer. 3. Open connection to computer through GERTi routing and transmit data. 5. GERTi Operation A. Premise A robust internal network is necessary for Ocranet to become viable and useful for inter-server networking. GERTi provides a simple, distributed, failure-tolerant network for OC computers inside of a minecraft server. GERTi handles the networking of OC computers to a gateway outside of the server. B. Implementation overwiew Upon startup, a GERTi enabled computer will use all available communication channels to attempt to reach a gateway through up to 2 intermediate computers. At a maximum, this allows for 1000 publicly addressable computers on an internal network with good planning, and a maximum of 10 publicly addressable computers with no planning. C. Implementation details Startup: 1. Upon startup, a GERTi enabled computer checks for tunnel cards andwired/wireless network cards. 2. If it has a linked card, attempt to check for a GERTi computer on the other end. 2a. If the other computer has GERTi and is Tier 0 (gateway)/Tier 1/Tier 2, store the other computer's UUID, store the other computer's network card UUID, store the other computer's tier, and set this computer's tier to other computer's tier+1. Advance to step 3. 2b. If the other computer is not GERTi enabled, advance to 3. 3. If it has a wired/wireless card, do a broadcast on a standard port (tbd) to look for GERTi enabled computers. 3a. For each reply that is from a computer with GERT and is a gateway(Tier 0)/Tier 1/Tier 2, store the other computer's UUID, and store the other computer's tier. Advance to 4 3b. If no response from any other computer, advance to 4. 4. Sort table entries by computers' GERTi tier, then UUID. 5. Assign GERTi channel numbers based on table entries. 6. Set this computer's tier to that of the lowest GERTi channel number's tier plus 1. 7. Engage listener so that other computers that send out broadcasts can connect through this computer. 7a. On connection request, reply with computer Tier number, computer UUID, and network card number, if this computer is lower than tier 0/1/2. 8. Forward local database connections up through chain to gateway. Communication 1. Upon inter-server communication requests from within the computer, attempt to connect to lowest tier number connection. 1a. Upon initial acknowledgement request, continue sending all communications through that node. 1a. If ack request fails, attempt to contact gateway through successively higher tier number nodes. 2. Upon inter-server communication request from a child node, follow step 1. 2a. If step 1 fails, send a FAIL cell to child node. 2b. If step 1 succeeds, send a CONNECT cell to child node. 3. Upon infra-server communication request from within the computer, attempt to lookup target computer UUID in local database 3a. If UUID is found, transmit directly, skip rest of 7. 3b. If UUID is not found, request parent node to look up UUID in its local database. 3c. Continue requesting up chain until connection achieved or gateway reached, then use gateway to route. 4. Upon infra-server communication request from a child node, attempt to lookup target computer UUID in local database. 4a. If UUID is found, transmit CONNECT cell to child node and route directly, skip rest of 8. 4b. If UUID is not found, request parent node to look up UUID in its local database. 4c. Continue requesting up chain until connection achieved or gateway reached, then use gateway to route. 4d. Upon receiving CONNECT, transmit connect to child node, and route through CONNECT sender. D. GERTi Gateway operation Startup: 1. Follow normal startup operation for a GERTi device, but mark computer as Tier 0. 2. Attempt to connect to external routing protocol (GERTe preferred, but not necessary) 3. Collect and organize routing table and paths to every child node. Communication: 1. Upon infra-server communication request from a child node, look up most efficient (fewest hops) path to requested node. 1a. If path found and verified, route communication to destination 1b. If path not found / not usable, attempt to route through alternate paths. 1c. If no paths usable / device not found, transmit FAIL cell to originator node. 2. Upon inter-server communication request from a child node, prepare Ocranet cell for transmission to external routing protocol. 2a. If external protocol not available, send FAIL cell. WIP End of whitepaper If you have any questions, please comment on this thread, create an issue on the GE/GERT repository, contact MajGenRelativity or Gavle on IRC or Discord, or you can just shout loudly into the air. Any of those work
  12. Hello! Yuon Survival is a 1.7.10 Custom Modpack Survival server looking for players! Features: Custom Modpack: The modpack is custom designed around a good balance of tech and magic to open as many options as possible! Balanced Rules: Beyond some rules to prevent extremes, the server is open to many different play styles to foster a wide community. Online 24/7: Hosted on a professional server to ensure maximum uptime Whitelisted to ensure the safety of all players Clean Map: While the map has been around for a while, it is virtually untouched If you have questions or want to join, feel free to respond to this thread or join #yuonsurvival on irc.esper.net Server IP: ModPack : https://goo.gl/5knI8U Mod List: https://goo.gl/bXmAVb IRC: irc.esper.net channel #yuonsurvival Discord: https://discord.gg/uAKet
  13. Basic Wired Networking Protocol

    This is a basic wired networking protocol that allows you to set up a rudimentary chat application over a WIRED network. This is the foundation for a far FAR more robust protocol I am developing local term = require("term") local component = require("component") local event = require("event") local m = component.modem local str="0" -- determine what channel people want to listen on term.write("What channel do you want to chat on? \n") local channel=io.read() m.open(tonumber(channel)) -- begin event event.listen("modem_message", function(_,_,from,port,_,message) -- decipher, and print local cipher = "1234567890qwertyuiopasdfghjklzxcvbnm" local function decrypt(str) str = str:gsub("%d",function(a) return string.char(cipher:find(a,nil,true)+47) end) str = str:gsub("%l",function(a) return string.char(cipher:find(a,nil,true)+86) end) return str end if string.sub(tostring(message), 1, 9)=="encrypted" then str=tostring(message) message=decrypt(str) local strlngth=string.len(tostring(message)) message=string.sub(tostring(message), 10, strlngth) print("Got a message from " .. from .. " on port " .. port .. ": " .. tostring(message)) else print("Got a message from " .. from .. " on port " .. port .. ": " .. tostring(message)) end end) -- send a message term.write("is this going to be encrypted? \n") -- register cipher local cipher = "1234567890qwertyuiopasdfghjklzxcvbnm" local function encrypt(str) str = str:gsub("%d",function(a) a=a:byte()-47 return cipher:sub(a,a) end) str = str:gsub("%l",function(a) a=a:byte()-86 return cipher:sub(a,a) end) return str end -- determine whether encryption should be used local useEC=io.read() if useEC=="yes" then term.write("Encryption activated \n") end while true do str=io.read() if tostring(str)=="endme" then os.exit() end if useEC=="yes" then str=encrypt(str) str="encrypted" .. " " .. str end -- send message m.broadcast(tonumber(channel), str) end
  14. Networked computers accessing each others screens

    I tried setting the primary screen, and it didn't work. I didn't try it in combo with the keyboard though
  15. I have two computers. Each one has a screen and keyboard on top of each, and the two cases, but not the screens, are connected by a network cable. When the computers start up, the text appears on one screen, then the default OS screen appears on the other screen. This ends up being really confusing! I tried writing an autorun script that told each computer to set its respective screen as the primary screen component, but it didn't work. If anybody could help me out, that would be great!