Recent Posts

Pages: [1] 2 3 ... 10
Programming with Blackvoxel / Re: Programmatic handling of the player
« Last post by Enigma on November 30, 2019, 02:21:30 pm »
Hi MUY_Belgium,

Thanks for your suggestions.

About PlayerSetAccell(), the player displacement is not proportionnal to the values because of air friction and ground friction. Blackvoxel use realistic physics formulae. To make it simple, the air friction is proportionnal to square of the speed. So, if you accelerate the player to an high speed, the friction will be very high... so the speed will go down very fast.
In an realistic world, the player should die above some limits.

For PlayerMove(), there is a bug. The good news is that's already fixed in our work. Stay tunned, we'll try to make a bugfix release in the next few days.

The values indicated in PlayerMove() is in player unit, not in voxel unit. The player unit is 256.0 units for a voxel.

The actual limit is 5000 units.

Best regards,
The Blackvoxel Team

General Discussion / Re: Questions
« Last post by Enigma on November 30, 2019, 02:18:45 pm »
So, thanks for your encouragements and your positive thoughts  :)

The photorealistic voxel engine you spoke about are not a likely "improvement" way for Blackvoxel engine. That's completely different way, architecture and engine type. Not the same needs and objectives.

In the eventuality we'll make an uprade of the rendering system someday, it would likely end up in something specificly chiselled for the Blackvoxel needs.

Our original goal for Blackvoxel was to make a good game, to make something different and creative by exploring new concepts. Competing in the general engine costly race against big game companies is a completely different business.

In the hope we have answered to your question, we wish you a good game.
The Blackvoxel Team
Programming with Blackvoxel / Re: Programmatic handling of the player
« Last post by MUY_Belgium on November 28, 2019, 12:46:58 am »
I have not used those function too.  Indeed throwing the user anywhere to the sky rapidly kill it.  There is programmation exemples but i cannot remember where i found then.  I noticed that this code cause the player to go up really fast.  I usually finish this with "u" (stop all robots).  Use this onderground only!

  local Diff = GetInfo(5) - GetY(); 
  if (GetZ() == GetInfo(6)) //  && Diff>0 && Diff<4)
    PlayerSetAccel(0.0, 1500.0, 0.0)
    if (Diff>1) Move(4);

For horizontal displacments, I could not manage to use PlayerSetAccel and used PlayerMove instead.  I really cannot figure out what the numbers figures, player displacement seems not proportionnal to the numbers given in arguments but

PlayerMove(15.0, 0.0, 0.0);

seems to safelly displace the player by 23 voxels if the place is empty with a ground.

You may want to foound a way to limit the number of UP to 16, 32 or 64 voxel depending upon the extraction robot you are using...
General Discussion / Re: Questions
« Last post by Voxel Space on November 21, 2019, 03:10:46 am »
 A dream can be what you make it, but mostly it is a mirror; one that reflects the choices of the past into the progress of today, to show a glint of what can be tomorrow... it is up to you to position that light to form the next image. My dream is not of voxels, not a game, but a way to change the outcome of the world. Voxels seem to be a good start, not for the dream itself, but as a guide on how to get there; voxels can show a world of their own; an idea, that gives a way for the image to be seen; a choice, for how tomorrow will become. This 'dream' is already being made by people who realized it, engines like Atomontage and Voxel Farm can both create fully volumetric (realistic) voxelized space. No matter how useful they are, their methods of execution is why they can fall, the reason for asking if your engine has the same capability is because yours has what the others are missing: a pillar to support the weight of progress, and its continuous use by others; a vital piece of freedom, called Open Source. While the other engines have more functionality, a high price to pay (more in their decisions than in their actual cost ) is what makes the option seem much further away than it truly is; behind a wall with a locked entrance when it should be open. As a city built on greed will blacken in the fog of ignorance.. ignorance of the strength and opportunity that its foundation holds for everyone willing to improve it, for the ones they keep outside the walls also in search of a better place. This will not stop their journey. With the knowledge of the downfalls held by these establishments and the skills to proceed, they will build their own city, not as strong initially, but one with the shared potential to surpass the ones in lead... because what may seem like a barrier  is usually a chance to build something great.

Even if this is not the purpose of your engine, no matter how small in comparison, it is built on a good foundation, I hope to see it become even better and maybe even make my own mods for it some day! Good Luck, and ... Thanks! ;D

General Discussion / Re: Questions
« Last post by Enigma on November 20, 2019, 10:10:21 am »
Hi and welcome to the Blackvoxel Forum.

I would like to ask a few questions before purchasing BlackVoxel's paid content (adventure mode):
What the limitations to the school mode are, what extra
functionality is added in the paid Adventure version that makes
it worth buying?

To make it simple, in adventure mode, you have access to the whole world :
You are intended to play, extract resources, process it, use machines to build stuff, machines and make airplanes.
You have access to all materials, so you can access the complete tech tree.

In school mode, you are limited to the flat blue central zone. The other zones doesn't exists in this mode.
The school mode is mainly intended to teach and learn programming with the 3 actual programmable robots.
In this mode, you can get stuff like programmable robots and automation directly with the "J" key.
The school mode in not really intended for playing. Even if we did not disabled the regular game mechanics,
 you can not access other zones in the world, so some materials will be missing to really play the game.

is the Voxel Fire engine modifiable
to include octree /light rendering systems or would it be an
impractical modification for the underlying code? If not, what is the
extent of the engine's capability, would it be easier to start from
scratch to make a sandboxed game like TROVE or Un-turned (with
physics) or could the engine manage it?

To answer in few words, the VoxelFire engine is a specialized game engine, not a general purpose game creation tool like (as example) Unity, the Unreal Engine or the Godot Game engine (to speak about a free software tool) that would allow easy game creation. I know that many of the game like you mentionned are often made with the Unity game engine.

The VoxelFire engine was thinked in first place to make possible what the Blackvoxel game needed to do. This game have very specific needs that would not have been possible without a custom engine. Programming an engine like the VoxelFire takes a long time.

With the definition you gave, you are far enough from the Blackvoxel paradigm. And modifiying a game engine (or more, creating a new one) is not something I would recommand unless you know very well what you are doing. It requires a very good level in programming and can take a very long time.

In addition if you want to create a game, you have take also into account the terms of the licence of the game engine. The GPL V3+ licence of the VoxelFire code means you have to comply with it.

keep improving, and it will become what most hope for... A software that
can be used for almost anything voxelized, best of all, Open Source.

Such a tool would be a dream. But I'm affraid it won't exist.
First because the word "voxel" can mean a lot of very different things. I mean, really different. And there is not best choice. What is good depend on the game.
Then because game engines are like cars. You can't have an "all in one" vehicle that can be best than specialized vehicle in their specific area. What you can call "the best car" depends on what you want to do.
VoxelFire can be good in Blackvoxel because it is specialized for what this specific game have to do.
Unforunately, specializing means making choices. Some choice you have to make in a game engine to make it better for some uses means... that you have a price to pay : it will be worst or not suitable for some other uses.

Best regards,
The Blackvoxel Team

General Discussion / Questions
« Last post by Voxel Space on November 20, 2019, 03:11:05 am »
I would like to ask a few questions before purchasing BlackVoxel's paid content (adventure mode):
What the limitations to the school mode are, what extra
functionality is added in the paid Adventure version that makes
it worth buying?  is the Voxel Fire engine modifiable
to include octree /light rendering systems or would it be an
impractical modification for the underlying code? If not, what is the
extent of the engine's capability, would it be easier to start from
scratch to make a sandboxed game like TROVE or Un-turned (with
physics) or could the engine manage it? 

This is a good base engine,
keep improving, and it will become what most hope for... A software that
can be used for almost anything voxelized, best of all, Open Source.

Thank You!

General Discussion / Re: School Mode
« Last post by Enigma on November 15, 2019, 09:51:24 pm »
Hi D3x0r,

Thanks for your comment and tought!

The good new is that you don't have to dig. In school mode, a special key "j" give you access to programmable robots and other automations automation stuff directly without following the habitual proces (digging, collecting resources, making metals).

Open the inventory and press "j" key. Pressing again give access to another page. Look at this page

Your post suggest us some improvements to the school mode to let user know minimal information on how to get started. We will think about it.

Best regards,
The Blackvoxel Team
General Discussion / School Mode
« Last post by d3x0r on November 01, 2019, 04:11:02 am »
Hello!  Great to see updates from y'all.

School shouldn't be tedious.... Right now, to get to be able to make your first tool... you have to dig, and I'm gussing it's 1.5 seconds(? 2?) per dig block?

( 64 * 3 = 192 ) * 1.5 = 382 seconds... 6 and a half minutes. (9 almost 10 minutes?)

And then I can find greenstone, and be able to return with it to the surface where my machine.

The document says.
'Where can you find it ?
You can find this voxel in the ground into the central blue flat zone.'  And the picture shows it on top of black rock blue... I know it's just showing the same block on the same oroginal blank stage, but... it does sort of imply that it can be over blackrrock blue - and it never is.

So ... I think " it's just another random block like copper, okay I'll keep digging sideways... surely they wouldn't force me to climb up and down all the time... " and dig t alot sideways, so now 30 minutes later and still no greenrock ...

Most voxelish digging games put rock only a little ways below dirt.... 4-8 voxels... because there's an infinite supply of dirt (blackrock blue).

So, optimally that's 6 minutes after the first 5-8 playing with the RTFM and external help; and having the cursor trapped to the game, so I can't click back on the browser... (tough, I know, to own the cursor, but give it up when you don't have it. )  There are lose focus events that you can revert the cursor capture... )

And if I was really new, I'd be sidetracked by copper and iron and other things, and it would really take me a long time to get to green rock; (I mentioned that earlier, it's realistically at LEAST 7 minutes, to make your first tool).

I wanted to learn to program, not spend my time in a clicker.

let me just reiterate, as i was closing this window... I missed the (X) a little...

1) when the game is not in focus, do not setmousepotiion on mouse event.  (background window of the browser, I miss the scroll bar a bit, and my mouse snaps to the other thing, but I was JUST typing in the browser... and then I have to get back to the scrollbar, but if there isn't actually another window over where the mosue moves, it's stuck, until you hit I to get to invenotry (free mouse) or something

2) alt-F4 doesn't work.

3) window isn't resizable by clicking on the frame (if you could somehow get the mouse off the game-focus :) )
Programming with Blackvoxel / Re: Odd behavior
« Last post by Enigma on May 15, 2019, 07:22:15 pm »
Hello Animar,

I see what is the problem. The functions you mentioned are executed... but in your case,  they are doing nothing. That's because in some cases, your program is running out of "action ticket".

To make the things simple, you have the right to do only one Move() per Voxel_Step() call. Then, your Voxel_Step() function must terminate before you have the right to do another Move(). That's for limiting the power of the programmable robot to avoid being faster than extraction robots. If you call the Move() function another time, it will do nothing but return "false" to say the move action was refused. In the documentation, the functions consuming the "action ticket" are documented with the sentence like "You can move the robot only once per cycle (per Voxel_Step() call)"

To understand more deeply, an important precision : The Squirell Robot is not running a continuously running program, but a function called cyclically. The function Voxel_Step() is called each time the voxels of the world are moving (Approx 5 time by seconds). It's working synchronously with the Molecular Voxel Interaction Engine. So it's synchronous with other machines. If you want to use a program behaving a more continuous way, see the trick below.

So, there is what you can do :

  • Rethink your program using some "state machine" like the example here : so you'll make only one action per voxel_step.
  • Always call any PickVoxel() before moving the robot.
  • Use the newest "Remote Programmable Robot" along with the Scratch programming language. It have a much simpler behavior and use a continuously running program ( But Squirrel robot remains more powerful and faster.
  • If you want to use some loops with Move() and make it like it's running continuously, you can use a trick : the squirrel generators with the yield() function after each Move() . The yield() will return execution to the Voxel_Step and resume at the same point on the next call. Here is an example.
Code: [Select]
// Continous program called by a function.

// The generator


// My continuously running program

function MyStuff()
  local x,y;
  for (y=0;y<8;y++)
    for (x=0;x<8;x++)
      if (y & 1) Move(1);
      else       Move(3);
    Move(2); yield(true);

// Calling the continuous program using a generator.

function Voxel_Step()
  // Creating the generator.
  if (Rep==0) Rep = MyStuff();
  // Calling the generator... or resuming where it was stopped.
  if (Rep==1) return(0);
  if (!resume Rep) {Rep=1;}

In the hope we have answered your questions, we wish you a good play.

The Blackvoxel Team
Troubleshooting & Bug Reports / Re: Sequencer Bug ?
« Last post by Enigma on May 15, 2019, 07:14:25 pm »
Hi Animar,

This is an intended behavior :)
The idea behind this is that the player should learn to "know what it does".
Like with the real world machines, some mistakes should have costs.  :P
But... not too much.
The problem with Atomic Compressors, they may contains a lot of things and/or very valuable things.
As we played, we found that mistakes with Atomic Compressors was too much punitive. It was very frustrating and ruined gaming experience.
That's why we made an exception to the default policy and protected the Atomic Compressor (and also XR robots in the unloading phase) from direct user mistake.

The Blackvoxel Team
Pages: [1] 2 3 ... 10