- Sky
- Blueberry
- Slate
- Blackcurrant
- Watermelon
- Strawberry
- Orange
- Banana
- Apple
- Emerald
- Chocolate
- Charcoal
Molinko
-
Content Count
451 -
Joined
-
Last visited
-
Days Won
35
Everything posted by Molinko
-
Getting error "bad argument #1 (number expected, got string):"
Molinko replied to 24KaratCarrot's question in Programming
I have an idea™... I think your error may be from the filesystem api file handle... It's just a hunch that when is called passing(or not passing...) nil somehow results in a string being used hence the error.. bad argument #1 (number expected, got string) The doc recommends using the 'io' library instead of the 'filesystem' lib because it has buffered streams. Perhaps some fuckery is afoot.. I'd say try this and report back . 1 local manager = {} 2 3 local fs = require("filesystem") -- # maybe you don't need this anymore?.. 4 local component = require("component") 5 l -
Getting error "bad argument #1 (number expected, got string):"
Molinko replied to 24KaratCarrot's question in Programming
address is misspelled as 'addresss'. too many s... That was surprisingly hard -
@BrisingrAerowing I have seen it. It's quite nice . I've had a hard time just understanding the way the shell and tty work together... Specifically viewports(windows? )... Would I be right in saying that in @Dustpuppy's version he is doing all the drawing to the screen himself? I'm having a hard time... lol What I really want to do is intercept the gpu I think.. Id like to have new processes get their own window, under my control. Including the shell. Is there a way to bind the terminal to a fake gpu proxy? Perhaps I can mock(intercept) the gpu proxy and redirect stdout to my drawbuffer..
-
Hello, and thank you in advance. I'm building a windowing system for OpenOS and was wondering if somebody could help me understand OpenOS's tty system? Basically I would like some tips for hijacking the initial terminal window. My plan is to put the terminals 'viewport' into a window and any subsequent processes into their respective windows. Any tips on the 'best' or 'appropriate' way to claim control of the shell window specifically would be greatly appreciated. Please ask any questions if I wasn't clear. Cheers! - Molinko
-
@applejag Gave what I think is the best answer to your question. OpenOS functions that yield for and event can interrupt when the OS see's the ctrl+alt+c keys pressed. Basically most OS(kernel?) methods can throw an error in the user level(your program), if they receive the "interrupted" signal. If you run @applejag's example above, and pressed ctrl+alt+c to interrupt then it would be os.sleep that would get the interrupted event and throw and error into your program. Using the 'pcall' function will 'swallow' this error and thus preserve your program. One unintended side effect of this is that
-
I like your style
-
If you read the 'Interrupts' section I posted from the wiki it says that calls to computer.pullSignal, and thus event.pull* methods, will call error inside themselves to basically crash your program when ctrl alt c is held. Personally I don't know why you need an inescapable beeper not in foreground process but who am I to judge... I haven't tested this but I think you would simply call the raw coroutine.yield instead of computer or event methods, which really just wrap coroutine methods with some extra stuff. th = thread.create(function() while true do coroutine.yield(1) -- # Thi
-
Its really hard to understand your question. What I think might be happening is that the program you're testing the thread library in, or rather the parent process the thread is attached to, is receiving the interrupted event. When a threads 'host process' exits(ends) the attached processes 'join'(die). So to answer what I think your question is, stop pulling the interrupted event in whatever 'host process' is running your threads. FYI 'interrupted' events are queued by the OpenOS kernel and they bubble. See Interrupts Starting In OpenOS 1.6.4 and later, interrupts have been cleane
-
Virtual waypoints for the self are pretty useless. There's no reason you couldn't just navigate using script local variables. Navigation components deploying a discoverable waypoint isn't any weirder really than the nav component detecting normal waypoint blocks. I just figured if the nav component can detect them why not be able to spoof them within reasonable limits. Its not op because any navigation card would be limited to detecting virtual waypoints with the same proximity limitations of normal waypoints.
-
Yes. Here's an example. drone 'A' (with a navigation upgrade) calls the 'setWaypoint' method, setting a waypoint relative to its current position. drone 'B' (with a navigation upgrade) calls the 'getWaypoints' method, returning a list of waypoints (1 of these waypoints is drone 'A'). Considering that navigation upgrades are limited by the map they were created with, drone 'A's "real world" location would have to lie within the map bounds of drone 'B's navigation upgrade. I hope this is clearer. Cheers.
-
The virtual waypoint is within the map boundaries of a navigation component. Really it's like a navigation upgrade can detect other navigation upgrades while the latter posts it's virtual waypoint.
-
I suggest that the Navigation component should be able to set and delete a virtual waypoint around itself. This would be useful for robot/drone to robot/drone navigation thus further extending the reusability of drone programs and setup of robot programs alike. Also, perhaps some logical limitations to this could be that while the virtual waypoint is deployed drone or robot movement is stopped. However, I don't think this is necessary. Examples of le code.. nav = component.navigation nav.setWaypoint('waypoint 1', 12, -1) -- # waypoint label, redstone level, vertical offset of virtual
-
May I suggest the Geolyzer component to scan the building area? This way the script could clear only the necessary areas before building. This could potentially speed up hollow builds by a lot. Maybe it could just scan the areas expected to be hollow and clear obstructions to the actual model in the build path, this way scanning would be limited too as opposed to scanning the entire build area. Just some thoughts on efficiency. Nice script btw
-
Perhaps you could use a timeout callback that uses event.push to queue a "fake" key event with the enter key. Just an idea..
-
I really love how nice this looks .
-
Tables are like lists. Sometimes you want and ordered list. Sometimes the order doesn't really matter logically but the categories or types of things in your list matter. Ordered tables uses indexes(numbers) as accessors to values in a list(table). Property tables use keys(strings) as accessors to values. Take these examples. -- # An ordered list. (table) local groceries = { [1] = 'apples', [2] = 'oranges', [3] = 'cereal', [4] = 'frozen pizza' } print( groceries[1], groceries[3] ) -- # output:>> 'apples' 'cereal' -- # A table with properties. Usually a good reason to use p
-
I believe @Gorzoid is probably right. In case he's not, have you tried using the duration parameter on the call to robot.use()? robot.use(sides.front, nil, 1) -- # call the 'use' method for 1 second.
-
This is looking really cool!!! Great work. I couldn't tell which version of the ECMAScript/Javascript language is embedded here? ES4, ES5..???
-
I dig it mang. Nice job, this is really cool
-
event.pullMultiple is a "blocking" call, meaning it waits until an event has happened. Supply it with a timeout in seconds as the first argument to resume every so often. event.pullMultiple(1, 'interrupted', 'touch') -- # 1 is the number of second to wait for an event before resuming.
-
I imagine there is more to do than just printing a line so I'll assume the Thread library is what you're looking for.
-
term.read with dobreak option is in the later versions of OpenOS. It may have not been available to you yet. The older version of term.read takes a list of option arguments instead of an options table. It can be used like so.. term.read(nil, false) Dobreak is the second arg here, set to false, nil will default to dobreak bring true.
-
term.read returns the input as a string with a newline character at the end. If you want to compare words after taking input without cleaning the string use io.read instead of term.read. Or with term.read({dobreak=false})
-
io.read and term.read both return a string. Use tonumber(a)==2
-
The screenshot resolution is hard to read. Could you post the full code in 'code' tags?