Jump to content


O.S's Content

There have been 8 items by O.S (Search limited from 29-March 23)


By content type

See this member's

Sort by                Order  

#226908 Computer Craft Check Door

Posted by O.S on 21 July 2015 - 11:12 PM in Ask a Pro

Goodluck. Sorry I couldn't provide what you wanted. :(

Neither, I'm afraid. My current project I'm trying to keep entirely Vanilla CC.



#226775 posting same text to multiple wired monitors

Posted by O.S on 21 July 2015 - 09:11 AM in Ask a Pro

Ach, wrong on all accounts. Ah well, I'll just crawl back into my lurker hole. :)

Though now I know that function is much more useful than I previously thought.



#226773 posting same text to multiple wired monitors

Posted by O.S on 21 July 2015 - 08:55 AM in Ask a Pro

Doesn't peripheral.find('type') only return the first of the given type?

You're right about using getType(), there is no reason not to use it there. I got stuck in the mindset of working with those strings. :P



#226769 posting same text to multiple wired monitors

Posted by O.S on 21 July 2015 - 07:49 AM in Ask a Pro

View Postflaghacker, on 21 July 2015 - 06:50 AM, said:

names = {"monitor_1", "..."}
monitors = {}

for i, name in ipairs (names) do
  monitors[i] = peripheral.wrap (name)
end
...
Yes, if you are going to repeatedly access/change these monitors, I second flaghacker's approach of making a table of wrapped monitors (opposed to just a table of their string names) so you can easily pull them back up without needed to rerun the peripheral.wrap loop.

It also looks like you want to have updating time on the signs, so maybe something like this will strike the right balance for simplicity:
print('Store Sign Engaged')
text = "Welcome to Renegade Inc"
names = {"monitor_6", "monitor_7",
		 "monitor_8", "monitor_9",
		 "monitor_10", "monitor_11",
		 "monitor_12", "monitor_13"}
monitors = {}

for i, name in ipairs (names) do
  monitors[i] = peripheral.wrap (name)
  monitors[i].setTextScale(2)
  -- Anything else you want to set up the first time
end

while true do
   for _, mon in ipairs (monitors) do
	  mon.clear()
	  mon.setCursorPos(1,1)
	  mon.write(text)
	  mon.setCursorPos(1,2)
	  mon.write(textutils.formateTime(os.time(),false))
   end
   sleep(1)
end

Also, if you don't want to hardcode your monitor names (in case you add, remove, or move them around) you can use the peripheral API to automatically find them like so:
local names = peripheral.getNames()
local monitors = {}
for _, v in ipairs(names) do
   if(string.find(v, "monitor")) then
	  table.insert(monitors, peripheral.wrap(v))
   end
end
*This only works for networked monitors (since they have "monitor" in their name) and won't see monitors directly touching the computer.

View Postflaghacker, on 21 July 2015 - 06:50 AM, said:

Edit: :ph34r:, read the post above me for an excellent explenation on for loops :P
Appreciate that. :)



#226762 *Efficiently* Exploring an Area

Posted by O.S on 21 July 2015 - 06:56 AM in Ask a Pro

Ah, this looks promising! I'm already implementing A* for pathfinding once the map is filled out, but I haven't come upon D* yet. It might take me some time to fully absorb this, but many thanks for the nudge in the right direction! :D



#226760 posting same text to multiple wired monitors

Posted by O.S on 21 July 2015 - 06:49 AM in Ask a Pro

You are going to want a loop to feed your monitors into peripheral.wrap()

Right now, you are passing it a table (monitorWrap) not the individual strings it is expecting. Something like:

for k, v in ipairs(monitorWrap) do
   local monitor = peripheral.wrap(v)
   -- Do stuff to current monitor
end

k is the key or index to the table. (Not really needed in your case)
v is the value at that index. (one of the strings in your table)
ipairs can really only be used with the default ordered numerical keys (like you are using here), otherwise you need pairs.



#226753 Computer Craft Check Door

Posted by O.S on 21 July 2015 - 05:19 AM in Ask a Pro

Not that I know of with a computer, but with a turtle you can use inspect().

Say you have a set up like this:
!_<
With the door ( _ ) on the south edge of the block and the turtle ( < ) facing the door to the east and a lever ( ! ) on the west side.

Running turtle.inspect() returns
true
{
   name = "minecraft:wooden_door",
   metadata = 7,
}

If you flip the lever and call it again, you get:
true
{
   name = "minecraft:wooden_door",
   metadata = 3,
}

Now, two points:
  • Those metadata values will change based on the way the door faces, so you'll need to experiment.
  • This only seems to work with doors opened by redstone, opening it by hand and calling the function seems to cause a block update of some sort causing the door to close and the "closed" metadata value to be returned. The turtle never 'sees' the door as open. So this would probably only work for your purpose with a iron door.

That said, if you're using a redstone signal to open/close the door, you can just use a regular computer to read that signal with redstone.getOutput(side).



#226751 *Efficiently* Exploring an Area

Posted by O.S on 21 July 2015 - 04:39 AM in Ask a Pro

Background:

Its been a while since I've messed with CC or even Lua, but I've decided to come back and tackle a project gave up on a few years back. I don't want to complicate my question with too many details but basically I'm building a semi-autonomous system. To do so, my turtles are keeping maps of their environment, which means they will need to explore a bit.


My question (if you haven't figured out from the title):
What would be the most efficient (I was thinking more time, than fuel) method for sweeping an unknown area?

A ) The simplest would be three nested loops for x, y, z. Possibly by chunk. But with that would waste time in cases of overlap (areas already explored) as well as reaching blocked off areas. (Imagine being under a 'U' shape, trying to get inside)


B ) To deal with weird U shaped pockets and whatnot, I added a maximum radius from the starting block, creating more of a sphere than cube. Then to minimize overlap, I throw a Dijkstra's out there (favoring forward, up, and down movement to minimize rotating time) to find all nearby unmapped blocks.


C ) Alternative solution is a recursive search where as the turtle travels, it checks all adjacent blocks and queues up unmapped ones. Then it continues on until it hits (1) a dead-end/nothing unmapped or (2) hits the maxed radius. It then backtracks to next queued (last added) unmapped block.


A is obviously the most accurate, as it hits every block, which also makes it the slowest. B is almost as accuate (skips blocks inaccessible within the radius) but faster as it minimizes rotating. C might miss some blocks that aren't touched (and then queued) but is almost 3 times faster than B to complete.

Now, I'm not looking for a code handout :P. Just maybe a fresh mind to point out where I've gone wrong in my logic. Is there something I missed? Maybe a tweak to one of the above methods that blows the others out of the water? Some method entirely new (and probably embarrassingly obvious) that I haven't stumbled upon?

My (ugly as hell) code and testing examples can be provided upon request.