Locating physical neighbours of objects

I am building a model that will simulate the mining of an ore body in an underground mine. The blocks of ore are represented as flow items (ie they cannot be connected to other objects). Suppose all blocks are 1x1x1 in size, and I want to mine a block at position (5,3,3) next. I can't get to it directly because other blocks are in the way. One way to get to (5,3,3) is to mine (5,3,1) first and then (5,3,2). I need a structure to store the neighbour relationship between objects so that I can quickly know which blocks to mine first to clear the way to the block I am targeting.

One method that I found is to store this information in a global table (for each block, store the name of their direct neighbour in each direction). Another way is to convert my script to C++ code and store a 3-dimensional array containing pointers to the object in the adjacent position (block (5,3,3) would be stored at position 5,3,3 in the array). I just don't know how to store this information globally.

Do you have any recommendations? Is the global table the best way to go? Is there an easier way to quickly get neighbour information of objects displayed in the model?

Thanks in advance.

Take a look at the NamedConnections development thread which will allow you to connect items and read the relationships easily.

Attached is a simple model that shows the relationships for creating a stack in a queue. The realtionships that are created are called "above" and "below". The code is on the Queue entry trigger which uses the user commands (which are in the NamedConnections library).

If, at the start you fill a rack as floor storage, then you'd perhaps use the rack commands along with the bay, level and height to figure out the positions and then set up the relationships. Of course if you can do that, perhaps that's quicker than making these links.

The rack idea is a good one because of indexing. The level/bay concept is easy as they become x/y indices when the rack is on the floor. But the height concept eludes me because it seems that the rack wants to stack flowitems starting at the lowest point. In the ore body it is possible that a block has no "down" neighbour so I would want a blank space underneath (ie I want to control the elevation of each block that I insert).

I can think of two approaches:
-create an invisible box in a position with no ore block
-create one rack for every Z-elevation in the ore body

I believe that having a different rack for each Z-elevation is the way to go but I welcome feedback.

You could load up the rack while creating the links and then just delete the blocks where nothing exists - the ones above stay where they are. Deleting a block also deletes any links to it on other blocks.

Attached is a model that creates the links above, below, north, south, east and west. The link setup code is again on the entrytrigger.

To test, just right click an item/block and set as so(). Then open a script and run getconnected(so(),"above") and replace "above" with the direction names from the previous paragraph (I was going to write ' from above' - confusing ). You'll see the script returns a pointer to the block in the direction you specified.

I ended up going with the rack idea. Prior to hitting 'Run' I execute a script that inserts items into the rack as described in the prior post. However when I click 'Run' some of my flowitems are moved to the front of the rack for no reason while other flowitems are changed to red colour. This is not the behaviour I want - I just want the rack to be a placeholder for items and do nothing else. Is there anything special that I have to do stop this from happening?

Thanks again.

A few options here:
1) record the height when the block enters the rack and the when an item is transported out restore all the heights of the other objects in the same bay and level
2) Instead of unloading the block, try a moveobject or just destroy it.
3) Override the exit logic (last resort)

As for turning red - is that something to do with marking bays that have called for transport in the Rack GUI page?

Originally Posted by Jason Lightfoot

A few options here:
1) record the height when the block enters the rack and the when an item is transported out restore all the heights of the other objects in the same bay and level
2) Instead of unloading the block, try a moveobject or just destroy it.
3) Override the exit logic (last resort)

As for turning red - is that something to do with marking bays that have called for transport in the Rack GUI page?

I have the marking bays ready option turned off yet some blocks still turn red. I am already using moveobject to move the boxes into the rack in my script. I simply want the rack to not do anything once I hit Run. The boxes should not move at all during the execution.

The scripting is nice but the built-in functionality is what is causing the problems.

Can you post your model or a small example?

Disregard what I wrote. When working on other parts of the model I decided to add a buildall() at the end of my script and that took care of the bizarre rack behaviour. Thanks for all the help!