- Sky
- Blueberry
- Slate
- Blackcurrant
- Watermelon
- Strawberry
- Orange
- Banana
- Apple
- Emerald
- Chocolate
- Charcoal
Forum Connectivity Upgrade Read more...
×
All Activity
This stream auto-updates
- Yesterday
-
- Last week
-
This is a port of cmatrix for OC Key Bindings: Q: Quit 0-9: Set Speed (0: fast: 9 slow) @: Set Colour to Green !: Set Colour to Red #: Set Colour to Yellow $: Set Colour to Blue &: Set Colour to White %: Set Colour to Magenta ^: Set Colour to Cyan Installation: oppm install cmatrix
-
Yes i have discord, anyways if i mentionned GERT it's because i find interesting the idea of connecting minecraft servers each other. It allows for a OC "internet", since oc servers can now technically be acessed from any minecraft server having a GERT address. Which allows for endless possibilities in oc web.
-
Do you have a Discord (preferred) or IRC account we can use to talk more about this? I'm interested since you mentioned GERT
-
-
OHML is a markup language based on XML, it is a simpler, OC-graphics adapted version of HTML.Par Part 1: Why i got that idea? It all started when i noticed that most network programs/libraries were either DNS system, or Website system. I tought it was very important to maintain an universal language for webpages. It is the first step of having a stable and universal "OCnet", which will follow with server and client implementations. Protocols, etc.. To finally have it united. It would mostly be useful with GERT since it allow for one, global, routing technology. Part 2: OHML versions OHML patch versions (1.0.1, 1.0.5, etc.) minor changes (more understandable descriptions, new optional arguments) can be asked in comments section, might get accepted, and when features are froze, set as a new minor version of OHML specifications. OHML minor versions (1.2, 1.1, 1.42) will accept features (new tags, deprecations, rename of tags/arguments, etc.) can also be asked in comments, they will get a seperate title from their major version, and have the space feature-freeze process than patch versions. OHML major versions (2, 4, 5) can start from a little draft based on a major feature (removal fo tags, minor/medium changes in way how code is wrote, etc.), and then should be put in another OETF thread, to add new features, validate them, and polish them. OHML v1.0 tags: Table about all tags and their (XML) arguments is available in png format, attached to this topic. Examples: Image: <image file="blabla.pic"></image> = "blabla.pic" showen as PIC (MineOS image) format Text: <text>Hello!</text> <text>World</text> Script: <script lang="some_script_language">Some multi-line script</script> Hyperlink: <a href="/superdupernews.ohm">Show super duper news</a> Part 3: HREF format An HREF format defined in <a> tag can be relative or absolute. If a href starts with any supported protocol name followed by "://" (ex: ohtp://), the link is fully absolute and should be coutned as the same than if the user inputed it as a website. It's a normal URL Then, if a href starts with "/", it is relative to the website host (can be ohtp://test.com), so, the full path is: {WEBSITE HOST} + {HREF} Finally, starts with nothing above, it is relative and should be appended to the actual URL URL are in the same format than real ones (protocol://host://webpage) OHML, being a markup language, will not support any kind of dynamic coding like <if> statements, <print> statements, etc., dynamic coding is handled by <script> tags and scripts languages supported by the browser. (Currently no script language has been made, it's coming). Anyway thanks for reading that long document about OHML, feel free to ask me things. I am actually making a protocol for it (OHTP) and then a basic server + client implementation. A OHML decoder hasn't been done yet, but since OHML is based on XML, any XML parser will do the job, then just show tags appropriate content and here it is! OHML is ready for any people making a script format and a web protocol. Community will choose by itself which one is used.
- 2 replies
-
- 1
-
-
- web
- opencomputers
- (and 1 more)
-
ALTEAR joined the community
-
katt1204 joined the community
-
@squidflex So everything is hooked up. Can you please hit the "CHARGE" button on the GUI and see if that changes anything for you? If it does then BRGC simply decides, that it's overproducing energy. Although 1600 mB/t sounds odd (as it should be 2000 mB/t -> 1 turbine).
-
Totally Awesome. Love it so much. Thank you guys ! <3
-
-
Maybe add compat for RFTools Power multiblock battery? You'll need to use a mod I wrote to get the full power level though, as it uses 64-bit integers for power storage, and the RF API only supports 32-bit integers.
-
Ah, my bad...I omitted that I've tried setting up BRGC a few times now. Even with the turbines and the Energy Core attached, BRGC sets the rod insertion upwards of 96%. This improves fuel depletion considerably, but it greatly reduces the amount of steam produced. As expected, if I disconnect the OC cable from the reactor and reduce the rod insertion, the steam output is fine again. With the turbines attached to BRGC, the controller shuts down one of the turbines after increasing rod insertion to 96% or higher. Should I only run one turbine off my reactor? Thanks!
-
I'm not an expert but as far as I know you need to hook the turbines in because BRGC will adjust your reactor to output exactly what the turbines need, without the turbines hooked up it could be confused. The other possibility is that you need to use the GUI, to go to the battery page and click charge, by default it will try to produce the same amount of power that you are currently using therefore keeping the battery at a steady level instead of charging to max. I'm not sure of exactly what the button names are so those are approximate instructions. Hope one of those things helps!
-
I'm having some trouble with BRGC... I have an actively cooled reactor running two turbines, which are charging a Draconic Evolution Energy Core. Without BRGC, the reactor produces 4000mB/t steam, which is piped out to the turbines. After connecting only the reactor to BRGC, it calibrated and set the rod insertion to 96% or higher. This cuts steam output down to about 1600mB/t and my turbines are barely spinning. Why does BRGC set the rod insertion so high? I assume I'm doing something wrong here, but I'm not sure what. Can someone point me in the right direction? Thanks!
-
squidflex joined the community
-
More authority over the 'harware'. (OC Developer Request)
Varscott11 replied to Varscott11's question in Requests
I did think that was strange. I though it meant that you can and loading it back could be dangerous. For the purpose of a virtual memory manager in a game, It really doesn't need to fully swap code segments. That is a bit overkill. After all most memory usage comes from data (usually) such as tables and what not anyway. I wouldn't really say it is not possible to swap code either. You cannot swap the current state of a coroutine but you can swap static chunks via string.dump and load. -
More authority over the 'harware'. (OC Developer Request)
payonel replied to Varscott11's question in Requests
btw, I made a typo (which I'll correct inline), I meant to say that (in regards to memory swapping) we cannot serialize all data types. So for a kernel to really swap memory, it would only be able to swap specific segments of data ... and could not force arbitrary user code to fully swap. It is sadly outside what Lua can do. We kill the the current coroutine that is long running. So you can catch it yourself, in your kernel, without the kernel crashing. This isn't a detail of machine.lua, but rather, how lua hooks work. And yes, I empathize with the challenge of that switch. Strangely I found have found that I enjoy the two contrasting worlds (lua <--> c++). -
More authority over the 'harware'. (OC Developer Request)
Varscott11 replied to Varscott11's question in Requests
I'm not mad at all and in fact I do actually agree with many of the points you have made. Some things I didn't know for example was the OC collects garbage at 10 instruction intervals. This is HUGE for me to know. Since I don't know a lot about the Minecraft Java environment I didn't know either that debug hooks aren't persisted. The fact that all types can be arbitrarily serialized now that I see that, can pose security problems not just for OC but for a kernel as well. The only thing I am not sure about is the OC killing a long running process for you. Does it kill the coroutine that is long running or just stop the Lua state. I can search for this myself in machine.lua so don't worry about that, but I'm pretty sure it doesn't notify the kernel via a signal so there is no way to know what happened and to do any cleanup if necessary. I will gladly do work arounds if I can to ensure security and stability (My kernel is centered around strong security). I just need to understand how the mod operates to do such work arounds and this gives me an insight. All in all though I respect your opinions and I'm now a bit reinsured that though it is limited in many ways, there are options. I recently started to work in the mod as a way to get away from the super low-level work of developing a kernel irl with C and x86 ASM and it is a quite difficult switch from complete control to less control. Thanks for your review! -
More authority over the 'harware'. (OC Developer Request)
payonel replied to Varscott11's question in Requests
I appreciate the interest and enthusiasm. I disagree with a few of the points you've made if you would allow me to explain. "almost" as in it isn't. Killing a thread pre-emptively is the only thing you can do in this case and that is not multithread nor cooperative. You can't resume coroutines from the same Lua state either. It isn't lightening fast, debug hooks are actually extremely costly. Also, we cannot persist debug hooks, thus when a machine is unloaded and reloaded in chunks, any state and special hook magic you might make would be lost. We collect garbage when you've yielded 10 times. Also, lua state will collect garbage dynamically You can already do that, see pcall. Or, run untrusted code in a sandboxed coroutine. The coroutine will die if they OOM. We looked into this, unfortunately you cannot arbitrarily serialize all value types in lua. Kernel Security: There is nothing MORE secure about unboxing any part of the sandbox. In fact, you could just run the machine.lua code, again, inside minecraft, and run an OS inside that sandbox. Sandbox inception! You wouldn't have debug hook, but hooks do not increase security, we only use them for stopping long running processes. And you don't need to do that, we do it for you. We are not in favor of making it this easy for uninformed server owners to expose their private server environments to users. Users have brought this up before and we (developers) are in strong agreement about this. Hopefully you're still reading this far, and not just mad at me for shooting down your sincere request, inspired by your obvious passion. I wanted to encourage you to ignore the constraints of the sandbox, and rather, look at what you really can do with developing a custom kernel. There is a lot more power than you might give credit to the system as it is. I whole heartedly agree that the virtual world in OC can be restricting, and at times extremely frustrating. I sympathize. Look at OpenOS. I have spent thousands of hours of my life developing OpenOS. WIthout a question, the single hardest part has been memory optimization and refinement. I'm a C++ developer (irl); I live in a world where I have complete and precise control over memory management (allocation, monitoring, profiling...). The way Lua allocates memory in chunks for its stack makes knowing the true cost of operations and new code actually very difficult to measure. I built an OC emulator primarily to provide a way for me to profile and measure memory usage. But none of this would have been "easier" outside the sandbox. -
This is more of a request of the Open Computers developers and may be a bit far fetched, but hear me out. At the very beginning when a BIOS is run, it is running in a sandboxed environment. This makes perfect sense as the Lua interpreter will blindly execute instructions on a real CPU on a real computer which can lead to major security risks if not protected properly. This is done by 'machine.lua' but this is where a problem starts to arise. Theoretically there is enough to build a fully functioning operating system, but it is actually quite limited and this is kind of strange. In real operating systems, the kernel has complete undisputed control over the entire computer. It stands to reason that this is where the sandbox security should be implemented and would allow for so many possibilities that would make the mod shine. Here are some things to be considered: SEMI-PREEMPTIVE MULTITHREADING: I am aware it is not possible to yield from a Lua hook but you can force a coroutine to terminate. This is demonstrated in machine.lua. This combined with some clever mechanisms can result in an almost hybrid between preemptive and cooperative multithreading system with lightning fast interrupt (event) dispatching. MEMORY MANAGEMENT: A computer can only use a relatively small amount of memory by default. This makes perfect sense. I mean if 30 people on a server all have a mega server farm and each in game computer can allocate 1GB, you will run out of memory on the host computer very fast. The problem is that memory management is very limited without collectgarbage. With it you can implement some sort of memory tracing allowing you to terminate a coroutine (via preempt checks for example) if it exceeds allowed memory. This actually makes the system more secure than it currently is because you can stop a malicious program from infinitely allocating memory until the computer runs out crashing it. VIRTUAL MEMORY SWAP FILE: With the unrestricted use of the debug library it can be possible to serialize upvalues and globals and write them to a disk when they are guaranteed not to be used in order to save precious memory. KERNEL SECURITY: Having complete control is actually more of a benefit to everyone (granted the kernel code is trusted). The kernel can implement security on it's level that is more relevant to it's interests as well as prevent any other code from exploiting the actual mod or Lua interpreter. After all, code has to be chosen to be run by the kernel and can be sanctioned at will. A simple file system protection layer can ensure a program cannot write or read from the kernel on the disk completely user spacing any program. Of course I'm not saying remove all security measures from the mod. That's just crazy. However simply adding an option to the config file to allow something like 'disableSandbox' that would grant the entire Lua Standard Library would be a godsend. If anything it would be completely sufficient to wrap all these functions that prevent the kernel from doing anything that can directly harm the host or going any lower level. Plus it is up to the user to truly decide if something is trusted. If the user wants to install a kernel to their host server with complete access, they would have the freedom to do so if they do so understand the risk. The config file is full of these sorts of trust dependent options already. So long as a person cannot access the save and .minecraft directories from a Lua state, that should be mostly it. For those who are happy with what there is they will have no change as the normal OC sandbox should be enabled by default. To top it all off, I have managed to implement all of the above in an unsandboxed Lua environment, so it would be so amazing if it can be ported. I don't know what goes into developing OC but in my mind it shouldn't take more that skipping the sandbox init if the config says to do so. These are my thoughts and they may just very well be dreams but if there are any OC developers reading this or anyone really, tell me what you think of this idea.
-
Mikey joined the community
-
1. OpenOS doesn't add to nor remove from the debug library, what you see in OpenOS is available to all user space programs/custom operating systems 2. The debug library filtering/sandboxing occurs in the "hardware", before your eeprom code is executed, by our machine.lua (which builds the sandbox) 3. OpenOS has no kernel.lua and never has. OpenOS never calls debug.sethook anywhere. The machine.lua I mentioned (which again, runs OUTSIDE the sandbox, running unsandboxed, running lua code unavailable to OpenOS, unavailable to any user code), but this machine.lua used to be called kernel.lua -- renamed December 7th 2014. Yes, it uses debug.sethook, but users (and openos) are inside the sandbox.
-
I've been searching far and wide on the forums, and i have seen a single script so far that was supposed to get a Drone to follow the player, which I've painstakingly tried, I've went through anything i could think of, but the code did not seem to work. The post, which i am referring to: And so, i'd like to ask if anyone could help me code a script or anything like that of such nature, or point me to a post where this has been done and is working fine even now. would be highly appreciated. I'm also not sure if this is the right section to post such a request/question.
-
Is this list a part of OpenOS or actually what you have provided by the mod what you start the computer? I'm asking this because the OpenOS Kernel.lua seems to be using debug.sethook
-
for k in pairs(debug) do print(k) end traceback getupvalue getlocal getinfo getlocal, btw, is limited, it only returns the first result (the name of the field, not its value)
-
I've looked at the page showing everything that can be used in an init script and well as the Open Computers kernel.lua but I still have some questions: What is available in the debug library (Lua 5.3) aka debug.sethook for example. Can someone please post what functions are and aren't available?
-
This is a simple GUI for OPPM: Usage: Klick a Package to set it's status: White: Package is not installed Yellow: Package will be installed Green: Package is installed. Red: Package will be removed. Click "Apply" to apply changes. Right click a Package to get more Information.
- Earlier
-
yeah about that... I might have forgotten to document the version I used for this... I haven't even checked if my code even works on the latest version... its going to take me a while to sort this out actually... so you might want to start tweaking the code a bit while I can't...
-
yea i thought so, thank you anyway
-
Paging @SuPeRMiNoR2 Looking at the last updated time of that file, it was last updated 3 years ago and many internal changes to OC/OpenOS have happened in that time, resulting in the error you got.
-
a programmer named SuPeRMiNoR2 made a port of alongtimeago and i tried to install it on my computer, but im not sure what im doing so i could be doing something wrong or the code isnt working anymore i saw his program listed on https://openprograms.github.io/ and the program on github https://github.com/OpenPrograms/SuPeRMiNoR2-Programs/tree/master/random/alongtimeago this is my first time using opencomputers so i installed oppm and typed oppm install alongtimeago, it installed and i typed alongtimeago and after a few seconds it just said cannot resume dead coroutine
