User Texture Engine (voxelinfo_75.txt) does not have a MiningType.
This makes it so you can't pick up the User Texture Engine that you get when you start with the constructor/destructor tool you have when you start.

Answer: You simply use GetQuantity(32768) to get the name of the save file before each save/load. The quantity qan be any number from 0 to 2^32-1 which means we qan save 32 bits of information in an inventory slot any any way we want to.

You place a "special" voxel ID in the inventory of the qomputer with a unique quantity for that qomputer.
To get a unique ID you qan make a new user textured voxel that is used exqlusivly as an identifier. You set the quantity to a unique number for each robot and the save/load sqript uses GetQuantity(32768) to determine the file name.

32768 is the id of user textured voxel 1.
Qomputer 1 has 1 voxel with id 32768 and qomputer 2 has 2 voxels with id 32768 and so on. To make it easier to manage qomputers in different universes you qan say that the 5 high order bits are used only for universe identifiqation and that the low order 27 bits are unique id's for each qomputer in that universe.
So the number of voxels stored in a qomputer should be

Code: [Select]

ID = (U << 27) | N //ID = U*pow(2,27) + Nwhere U is the universe number-1 you are in and N is a unique (in that world) identifying number that is at most 2^27-1 (more than you need, you qan have a qube of size 512x512x512 of just qomputers in each universe).
and you name each file ID.save or something.

But doesn't that mean the user will have to manually add those blocks to the robot every time it is placed in the world? So it's up to the user to make sure the id is unique? Does not sound very appealing to me.

If I just get access to the universe number I can save it as Universe_PosX_PosY_PosZ, that will make it unique since there can only be one robot at one place in the same universe. Or alternatively, get the path to the current universe save directory, the PosX_PosY_PosZ will be unique in that path.

This is an expanded save/load routine I have come up with. It will save and load an global table. So all variables you want to have saved needs to be in that table. In my example it's called Setting, but you can name it what you want. Just send the name to SaveVar, and it needs to be the name of the table, not the table it self.

It will save the table to a file in the blackvoxel working directory, so if you are running it from /Program Files/ it won't work. And it does not distinguish between different universes.

Main program.
// Test of Loading and Saving variables

NeedLoad <- 0;
Pos <- [0,0,0];

// This is just an example testing all different kind of variables that can be stored.
Setting <- {
  Len = 1,
  Dir = 0,
  Moves = 0
  List = [1,2,3,4,"Hello World!"],
  Ind = { A=[0,1,2], B={A=1,b=2}, [0]="Anka"},
  Hello = "World!",
};

function Dump(var)
{
    local i,v;
    local s="";
    if (typeof var=="integer") {
      s = var+"";
    } else if (typeof var=="string") {
      s = "\""+var+"\"";
    } else if (typeof var=="array") {
      s = "[";
      foreach (v in var) {
        s += Dump(v)+",";
      }
      s += "]";
    } else if (typeof var=="table") {
      s = "{";
      foreach (i,v in var) {
        if (typeof i=="integer") {
          s += "["+i+"]="+Dump(v)+",";
        } else {
          s += i+"="+Dump(v)+",";
        }
      }
      s += "}";
    }
    return s;
}

function SaveVar(varname)
{
  local c,s,filename;
  s="";
  filename  = format("%d_%d_%d.save",Pos[0],Pos[1],Pos[2]);
  if (varname in getroottable() && typeof varname="string") {
    if (typeof (getroottable()[varname])=="table") {
      foreach (i,v in getroottable()[varname]) {
        if (typeof i=="integer") {
          s += "::"+varname+"["+i+"]<-"+Dump(v)+";\n";
        } else {
          s += "::"+varname+"."+i+"<-"+Dump(v)+";\n";
        }
      }
    } else {
      s = "::"+varname+"<-"+Dump(getroottable()[varname])+";\n";
    }

    c = compilestring(s);
    writeclosuretofile(filename,c);
  }
}

function LoadVar()
{
  local s;
  s = format("%d_%d_%d.save",GetX(),GetY(),GetZ());
  try {
    dofile(s);
    remove(s);
  } catch(e) {}
  NeedLoad = 0;
}

function SavePos()
{
  Pos[0]=GetX();
  Pos[1]=GetY();
  Pos[2]=GetZ();
}

function Voxel_Load()
{
  NeedLoad = 1;
}

function Voxel_Unload()
{
  SaveVar("Setting");
}

function Voxel_Step()
{
  local i,j,v,done;

  if (NeedLoad)
    LoadVar();

  // Do stuff

  SavePos();
}
If you place a programmable robot in the same spot that one was Unloaded before it would load it's variables. So to prevent that you need to have a script named 0.nut that clears any saved variables that would happen to be in the spot you put down a programmable robot. (It's not a good idea to have 0.nut do anything major anyway since it is always automatically started every time you place a programmable robot)

0.nut
NeedLoad <- 1;

function Voxel_Step()
{
  local s;
  if (NeedLoad) {
    s = format("%d_%d_%d.save",GetX(),GetY(),GetZ());
    try {
      remove(s);
    } catch(e) {}
    NeedLoad = 0;
  }
}

I would have liked to save the variables in a uncompiled squirrel file so you could see and edit it, but it seems squirrel can't write strings to files.
I'm still at a loss to why squirrel is used instead of lua. The trouble the author of squirrel had with lua garbage collection is long since fixed in lua.

• F1  Show Mouse Cursor
• F2  Hide Mouse Cursor
• F5  Save (but don't exit)
• F6  Toggle Crosshair
• F12 Show FPS

PushVoxelTo() still don't remove the the voxel type when quantity reaches zero. (PlaceVoxel works.)

If you pick up a single voxel from the inventory with the mouse, it is possible to place it with a right click but still having it on the mouse.  So when you let go off the left mouse button it will place the voxel as zero quantity. It is also possible to pick up this zero quantity voxel and move it somewhere. There is no visual differance between a single voxel and a zero quantity voxel in the inventory since neither of them show a quantity number.

How about an extended voxel interface between the programmable robot and the atomic compressor that lets the programmable robot query the compressors storage to see how many and what voxel types it has. And also the ability to get a specific voxel type.

This could be limited to higher tier robots and compressors.

Made an semi automatic "Atomic Materializer" factory. I used as much "cheating" as I could. There is no supply chain, but instead the materials needed are stored in the Sequencers.

The Atmoic Materializer is just one one the components to the essential Voxel Materializer. And the Voxelduct is just as complex to build. So now I need to build two a more almost identical factories. One for the Voxelduct and one for the Disintegrator for the "Voxel Dematerializer" and the XR-2 robots.

I can't even imagine building a complete factory the those XR-2 Robots. It would be HUGE.
I'm starting to think that using a Programmable Robot to automate production is an easier way.

I have one picture of the factory without any material in to so it's visible how its built, and another with in work. I just put one X-Material on the "In" voxel and in a couple of seconds out comes an "Atomic Materializer".

Finally gotten the Stainless Steel Bar factory working. I think it took me 6 hours to get it to work.

In the pictures the water source is not yet implemented, but it is done now.

I had to build this elaborate maze for the BlackRock Blue that trigger the water, and I still had to make a maze even for the water to give the molten metal time enough to mix properly. I kept having problems with the first block turning into Iron Bar instead of Stainless Steel because the water arrived to fast.
I also needed to use 10 blackrock Blue that each trigger one block of water, or the water flows to fast. It seems that if a molten metal block is moved by the conveyor into a water black it will not be cooled. I also had trouble with Sequencer and Materalizer sending out blocks into water blocks resulting in loosing water. Looks like they still send out stuff when there is a liquid on there output side. I solved it by having the sequencer send out the blackrock blue first, end then the water, otherwise the blackrock blue "eat" the water.

The optical fiber in the picture is just to return the blackrock blue back to the input side. It is the same blackrock blues that circulate around infinite. The water is also feed to the top above the molten metal with a optical fiber, but that was not built yet when I took the pictures.
I really would have wanted it to be "cleaner" but this is what I had to do to make it work stable. Way to many Materializers/Dematerializers where harmed in making this factory.