Found a bug in GetInfo(22) when Voxel_Unload() is called during a program change. The program number indicated was wrong. Fixed.

V1.22b3 on Windows

GetPath(), GetInfo() and GetInfoName all just return -1 when called in Voxel_Load or Voxel_Unload where we really need them.

GetPath(0) return 3 instead of 4 as said in the release notes, but GetPath(4) returns the correct result.

Thanks a lot. That's fixed. New beta released now.

Code: [Select]

PickVoxel3D(0,0,0)Qrashes the BV qlient :>

Also fixed.

The result from GetGameTime() seems to start over from 0 at an odd time. I've seem the value go as high as 1271305784 before starting from 0. But 1271305784 isn't even near max value for a 32 bit integer. And the value also seems to start very high.

If I did the math correctly there should take 49 days before the value would overflow in an unsigned 32 bit integer, half that if it's signed and only positive numbers are used. But I've seen it start over from 0 several times in one day.

Yep, that's not regular. Shouldn't have such values. So, there is a problem hiding somewhere.

With the last modification the values are now relative from the start of the game and saved when exiting. So, value shouldn't be so high.

Will look at that.

Could we please have a 64 bit windows exe, or at least a Large Address Aware Windows 32 bit exe. I would like to experiment with larger loaded world size.

That there is a 64 bit Ubuntu version doesn't help me since my machine running Ubuntu only has 2G of memory

That's in to-do list and we are convinced these are important features.

Unfortunately, it will require much more work than just activating some flags on the compiler. So, I'm not sure we will do that soon nor for the upcoming stable Release.

Some elements to understand :

We don't use Microsoft compiler for the Windows version.

Even the Windows version of Blackvoxel is built entirely... on Linux with a rather complex build system.

The GCC port we use for Windows don't support 64 bit mode. So will have to build, evaluate and validate a complete new toolchain for supporting 64 bits.

Already tried to activate large address aware on actual toolchain without success. It seems the compiler option isn't supported. But will have to try some trick we found and continue digging that way. Also, we must ensure it won't make some problem (It should not... but who knows).

That said, if you want that feature now, there are on the web some utilities that can force activation of LAA mode by simply modifying the .exe file to set the LAA flag.

The Blackvoxel Team

Now it's possible to save variables between game save/load with the following code.

Code: [Select]

Len <- 1;
Dir <- 0;
Moves <- 0;

function Voxel_Load()
{
    try {
        dofile("save.nut");
        remove("save.nut");
    } catch(e) {}
}

function Voxel_Unload()
{
    local s;
    s = compilestring(format("::Moves<-%d;\n::Dir<-%d;\n::Len<-%d;\n",Moves,Dir,Len));
    writeclosuretofile("save.nut",s);
}

But there is not enough information available to the script to distinguish different robots apart or different universes.

I was thinking I could save the variables for a script in it's Voxel_Unload function. I need to have a way to separated several programmable robots that all run the same script apart. So I thought their x,y,z position should do. But those are not available in the Voxel_Load and Voxel_Unload.
I also need to separate the saved variables from different universes, but there is no way of knowing what universe we are in.
There should probably also be a way for a script to read it's program number. (In case you have copied or renamed it)

I also have trouble identifying if Voxel_Load was called because the robot was placed in the world, loaded, or had it's program changed. I really only want to load stored variables when the robot is loaded into the world, not when it is first placed, or had it's program changed.

All in all, it would probably be better if there was a specific blackvoxel function that handled the saving and loading of variables that a script could use.

Yep, we agree. That would be a good idea to provide a kind of serial number for the robot.  And something like getting a directory and path to save the files for a particular game.

Hi Enigma! :>

Quote from: Enigma on October 23, 2013, 01:37:20 am

• Added : New Egmy (Not yet activated).
• Fixed : Programmable Robot : Redone some init/load/save code.
• Fixed : Programming : Access to libraries (iolib...) wasn't working.

Error: Egmy not defined. Egmy was not found in diqtionary or acronym list.
What is an Egmy? :Q

What was fixed with init/load/save qode and in what way was access to libraries fixed for programming? There are no funqtions that deal with iolib that were exposed before or now. I'm qonfused.

Yep, Egmy isn't in dictionnary So they should add it 

The Squirrel iolib is a set of squirrel optional functionalities required to access files in programs.

This is part of what the Squirrel author named "Squirrel Standard Library".

So, to explain clearly what it's mean, in 1.22 you can write such kind of code for saving data into files.

local fh = file("test.txt","wb+");
fh.writen('N', 'b');
fh.close();

The Blackvoxel Team

It would be nice with more aqtual 3D voxel terrain. Right now everything except for the (mesmerizing) trees is heightmap based. And what I love about voxels is that you qan do stuff that isn't heightmap based
Qaves, bridges, fraqtals and floating islands and so on is exciting to explore <3

We had this idea, but not yet the time to realize it.

The Blackvoxel Team

Atomiq Qompressor has id 49 but the manual says 100!

Thanks. Fixed !