Blackvoxel Forum
Blackvoxel => Troubleshooting & Bug Reports => Topic started by: Qon on October 06, 2013, 07:55:17 pm
-
Starting this thread with some minor things since overall everything seems to be very stable and bug free.
Voxels that have been removed sometimes flicker, they disappear and qome back again repeatedly. They don't seem to "exist"/have any effect though.
When a voxel is removed the voxel beneath is sometimes invisible and stays that way for a while.
Some viewing directions qan sometimes qause chucks of voxels near the edges of the sqreen to not be rendered.
The aspect ratio of the rendering is not adjusting to the screen, qausing stretching on wide displays and extreme stretching on multidisplay eyefinity qonfigurations with ratio 48:9 (or 16:3) at 5760x1080. When this is fixed I ask that you make it Hor+ and not Ver-. http://en.wikipedia.org/wiki/Hor%2B#Image_scaling_methods (http://en.wikipedia.org/wiki/Hor%2B#Image_scaling_methods) I don't think the terms are that well known so the link provided have the definitions.
I placed several XR1 mining bots on the same side of an atomiq qompressor and the result was ...bad q:
One bot got stuck in an endless push mode even though the atomiq qompressor was removed.
To reproduce:
Put 2 xr1's at the same side of a AQ with a short interval. The last bot will then pick up the 1st bot while it's in push mode. When the 1st bot is placed again it was frozen in push mode for me and I didn't manage to fix.
-
If you run A.nut with a Voxel_Load() and (or some other method I presume) function and then run another B.nut without Voxel_Load() then the Voxel_Load() method from A.nut will be exequted when you run B.nut. To work around this you need an empty Voxel_Load() methods in every .nut to overwrite any possible leftovers from other nuts.
print() is bugged, it only flushes changes to disk when error() is used. Temporary workaround: Use error() as print.
-
Tanks for this nice and precise bug report. You really have a very good eye that see even little things.
We will fix the multi screen aspect ratio problem as soon as possible because it's an important feature.
The ghost translucent voxel flickering is also a known bug that we will try to kill someday even if it show rarely.
For other glitches like the sector sometimes not showing on the edge or black voxel sometime visible, they are not really bugs.
Yes, we understand that's may sound very surprising.
So, let's explain : they are the consequence of very aggressive display optimisations.
The problem is that even modern and powerful PC hardware had hard pain at rendering a massive voxel dynamic world. Actual PC hardware isn't too bad for Vector game engines. But when it's coming to Voxel, there's a lot of bottlenecks everywhere. High level graphics API wasn't designed for Voxels.
So, we had to develop a lot of optimisations to make Blackvoxel Massive Voxel Interaction a true reality. That's why the engine take nearly 2 years of work.
Sometime, we had to make some difficult choices : does a very fast algorithm is suitable even if it show rarely some discrete and minor glitchs?
There are some cases where it is worth really the horsepower gain. And Blackvoxel needed a lot of power to make a dynamic world. So aggressive optimizations are a necessity.
Some of these algorithms has been fine tuned to get the best rapport between performance gain and visibility with standard hardware in mind. In the future, we may expose some additional settings for the user to fine tune with their hardware and their preferences.
They are also additional things you can do for optimizing rendering like disabling vertical sync as it's speed up sector refresh and minimize the apparition time of the "black under voxel" effect. Yes, even for powerful hardware. And yes, the optimisation guide said the opposite. In fact, it is outdated since the last rendering engine interaction.
Dreaming on the future is showing us nextgen PC with their huge memory bus, integrated GPU without bus bottlenecks and maybe low level graphics api that will help for non-vector rendering engines.
The Blackvoxel Team
-
I get 180-360 fps, I think I have a few cycles to spare :)
I had 45-60 fps while reqording and moving like 0.5MV of water simultaneously. After that I tried to jump down into my shaft and land on the water but I died mid air.
I have video footage which I took sqreenshots of. The video files qlimbed to 55GB in just a few minutes, need to qompress it I guess~
(http://s11.postimg.org/yymtz42tr/vlc_2013_10_07_22_26_40_78.png) (http://postimg.org/image/yymtz42tr/)
0.2 seconds later:
(http://s11.postimg.org/aguqb809b/vlc_2013_10_07_22_26_48_51.png) (http://postimg.org/image/aguqb809b/)
-
If you run A.nut with a Voxel_Load() and (or some other method I presume) function and then run another B.nut without Voxel_Load() then the Voxel_Load() method from A.nut will be exequted when you run B.nut. To work around this you need an empty Voxel_Load() methods in every .nut to overwrite any possible leftovers from other nuts.
print() is bugged, it only flushes changes to disk when error() is used. Temporary workaround: Use error() as print.
We are looking at this and managed to reproduce the issue successfully. Will be fixed :)
-
I believe this is some sort of bug
(http://s17.postimg.org/cuv52o4a3/blackvoxel_2013_10_08_09_17_57_98.jpg) (http://postimg.org/image/cuv52o4a3/)
White voxels in the sky. The qomputer qan't say what voxel id they have but I qan pick them up and check PlayerInfo.dat for their id numbers (several different types) if you want. They aren't really hurting anyone though q:
-
I believe this is some sort of bug
(http://s17.postimg.org/cuv52o4a3/blackvoxel_2013_10_08_09_17_57_98.jpg) (http://postimg.org/image/cuv52o4a3/)
White voxels in the sky. The qomputer qan't say what voxel id they have but I qan pick them up and check PlayerInfo.dat for their id numbers (several different types) if you want. They aren't really hurting anyone though q:
This look like a bug. Yes, it could help to know the voxeltype values. Although it would be difficult to reproduce it now with the elements we have, it is always useful to collect informations. Stacking informations is a good way to find such type of bugs.
The Blackvoxel Team
-
So the qomputer qan check their IDs but it qan't pick up the white voxels. I qan though with my qonstructor/destructor tier 3. Here's my PlayerInfo.dat
So these white voxels have id numbers at 0xFFFF or slightly less.
The qoorinates and the shape of the thing is visible in these images:
(http://s16.postimg.org/sjrfq4o35/blackvoxel_2013_10_09_20_13_58_32.png) (http://postimg.org/image/sjrfq4o35/)
(http://s16.postimg.org/styy9h2pd/blackvoxel_2013_10_09_20_16_15_23.png) (http://postimg.org/image/styy9h2pd/)
There's a pillar of blackrock blue in this image but there's a white voxel at every position (95,64-127,207)
(http://s16.postimg.org/sihhwpm9d/blackvoxel_2013_10_09_20_18_41_11.png) (http://postimg.org/image/sihhwpm9d/)
424c 4b50 4c41 5952 0200 0200 ba02 0000
c1ee f5d5 9e45 e640 1497 802f 9640 5d3f
f504 9e15 70df ee40 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 878d 3dcc 0292 7440
0000 0000 0000 0000 cf2f e876 ad9c 6a40
c1ee f5d5 9e45 e640 e08b 2550 0700 7c40
f504 9e15 70df ee40 878d 3dcc 0292 7440
0000 0000 0000 0000 cf2f e876 ad9c 6a40
e803 0000 0100 9d0e 630a 0000 5400 7fd0
a000 0000 5500 dc2b 1872 0800 5800 722d
0a00 0000 5700 a62d 1400 0000 5c00 a32d
0100 0000 3100 c42f 0100 0000 cbff 4613
0d00 0000 aacb 7bd7 0200 0000 99ff ffd7
0d00 0000 bb99 0cd8 0800 0000 ffff b219
9401 0000 bbff d62f 0d00 0000 ffdc a52d
0400 0000 dcff a12d 0f00 0000 9999 a52d
0a00 0000 cbed a42d 1100 0000 edff a42d
1300 0000 dcbb a22d 0300 0000 cbaa a42d
0e00 0000 aaff a52d 1500 0000 99bb c82d
0200 0000 bbdc 8735 0200 0000 aa99 44d8
0400 0000 6c00 41d8 0100 0000 aaaa 00d8
0400 0000 ffed fed7 0800 0000 bbbb 00d8
0200 0000 99aa 02d8 0100 0000 bbaa fbd5
0100 0000 0000 9af7 0000 0000 0000 8a2e
0000 0000 0000 a42d 0000 0000 0000 222d
0000 0000 0000 45e7 0000 0000 0000 d4d5
0000 0000 0000 fcd7 0000 0000 0000 00d8
0000 0000 0000 44d8 0000 0000 0000 98d8
0000 0000 4d00 a635 0100 0000 9e00 dd2d
0400 0000 0000 a72d 0000 0000 0000 a52d
0000 0000 0000 f42d 0000 0000 0000 ae35
0000 0000 0000 f6d8 0000 0000 0000 41d8
0000 0000 0000 33d6 0000 0000 0000 35db
0000 0000 0000 ed2b 0000 0000 0000 992d
0000 0000 0000 792f 0000 0000 0000 9a08
0000 0000 0000 bad6 0000 0000 0000 ffd7
0000 0000 0000 fdd7 0000 0000 0000 fed7
0000 0000 0000 fdd7 0000 0000 0000 fed7
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0052 4944
4558 5445 4e01 0000 0000
-
...
Thanks for these useful informations.
This gives us some clues.
-
Running Blackvoxel in windowed mode on Windows 7. So these bugs may only exist there.
- The game hogs the mouse even when it does not have focus. If I use alt-tab to switch to another application Blackvoxel still hides the mouse cursor and rotates the view when I try to move the mouse to the focused window.
- Even when the mouse is hidden in the game, you can still drag and drop the icons on the right toolbar. Happens often that I pick up those icons by mistake since it is impossible to see where the mouse cursor are when it is hidden. Drag and drop should only be enabled when the mouse cursor is visible. (This also happens when Blackvoxel is run fullscreen.)
- If two sequencers are placed so close together that there is at least one voxel that they both can use as input, one of them will operate extremely slow. Like only pick up voxels once ever 15-20 seconds.
- Manufacturing recipe for Silicon Wafer is messed up. The manual say 10 x BlackRock Blue Sky. But to actually make it you also need to add 1 x BlackRock Blue, but you will get the BlackRock Blue also as the output. Also all manufacturing instructions in the manual (on the web) that uses the Silicon Wafer links to the wrong place if you click it.
- Not sure if it is a bug or not. According to the manual Voxel bitmaps are supposed to use the lower right part as the inventory icon, but they use the same area for the inventory icon as for the top of the voxel.
- Robot programing. GetGameTime() returns a negative number. Which causes all the examples that use GetGameTime() to not work. It's still possible to make it work, but not like in the examples. Windows specific bug??
-
Hello Toupie,
Welcome to the Blackvoxel Forum!
Thanks for your reports. We will look at all this closely.
The Blackvoxel Team
-
Thanks. Oh. And I forgot one small bug I've noticed.
When a programmable computer places the last of a voxeltype in its inventory, that voxeltyp still is visible in the computers inventory, but with a quantity of 0. Manually moving another voxeltype into to that inventory slot clears it.
And don't take these bug reports as complaints. I only want to try and help make Blackvoxel better since I see some great potential in it.
-
Many functions should be qallable in Voxel_Load and Voxel_Unload, like GetX() and others. Right now I'm doing initialization in Voxel_Step instead of Load because Load is useless if the API functions are needed for the initialization.
And GetX() is not updated qorrectly when Move() is qalled. The position is updated about a second later.
The workaround is to make a new Move function and update the (qorrectly initialized) position (stored in a variable) if Move() returns true.
-
...And the light green blackrock is qalled "purple" in the manual ;)
-
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.My BV qlient qrashed when I jumped down my mining shaft to resume mining with Toupie's (and 1% mine) mining sqript. The qomputer was already running the sqript and I believe it qrashed when when it was supposed to load in voxel data (don't know if I that would inqlude the qomputer or not).
-
Hello Toupie,
Thanks. Oh. And I forgot one small bug I've noticed.
When a programmable computer places the last of a voxeltype in its inventory, that voxeltyp still is visible in the computers inventory, but with a quantity of 0. Manually moving another voxeltype into to that inventory slot clears it.
And don't take these bug reports as complaints. I only want to try and help make Blackvoxel better since I see some great potential in it.
That's added in the list.
We are pleased that users report bugs because it helps to improve the game. We know that it takes time to you to make bug reports, so we thank you for that.
The Blackvoxel Team
-
Tried to make my own textures and failed miserably. Maybe I did something wrong?
I didn't make them transparent. Some faces are missing qompletely and the qolors are wrong. Green looks purple and red looks blue. Submitted the
The first 2 images depict qubes with the RGB texture and the others are with black texture with some red on it. The last 7 images were kinda qool so I just uploaded them even though they might not be that useful :>
I tried both replacing textures in the texture folder and using the UserTexture object and got the same result.
(http://s22.postimg.org/3nw929inh/blackvoxel_2013_10_13_14_35_35_03.png) (http://postimg.org/image/3nw929inh/) (http://s22.postimg.org/6ffisvh65/blackvoxel_2013_10_13_14_35_44_91.png) (http://postimg.org/image/6ffisvh65/) (http://s22.postimg.org/8cc8xg7u5/blackvoxel_2013_10_13_14_39_19_67.png) (http://postimg.org/image/8cc8xg7u5/) (http://s22.postimg.org/cwyfcdrjh/blackvoxel_2013_10_13_14_43_08_30.png) (http://postimg.org/image/cwyfcdrjh/) (http://s22.postimg.org/s0klghdwt/blackvoxel_2013_10_13_14_43_32_62.png) (http://postimg.org/image/s0klghdwt/) (http://s22.postimg.org/mxyo7yf8t/blackvoxel_2013_10_13_14_43_38_82.png) (http://postimg.org/image/mxyo7yf8t/)(http://s22.postimg.org/ofk4jijzh/blackvoxel_2013_10_13_14_43_47_36.png) (http://postimg.org/image/ofk4jijzh/) (http://s22.postimg.org/44cvayh0t/blackvoxel_2013_10_13_14_43_54_69.png) (http://postimg.org/image/44cvayh0t/) (http://s22.postimg.org/nc007jzcd/blackvoxel_2013_10_13_14_44_03_15.png) (http://postimg.org/image/nc007jzcd/) (http://s22.postimg.org/55d402y0d/blackvoxel_2013_10_13_14_44_45_68.png) (http://postimg.org/image/55d402y0d/)
Textures:
(http://s24.postimg.org/aysoh5cdd/voxeltexture_1.jpg) (http://postimg.org/image/aysoh5cdd/)
(I qan't uplod the red paint texture, too big for attachment and postimage.org doesn't accept it )
-
I noticed that postimage.org uses PNG qompression on images.
http://speedy.sh/BdmFx/voxeltexture-1.bmp (http://speedy.sh/BdmFx/voxeltexture-1.bmp)
http://speedy.sh/rEfpz/voxeltexture-1.bmp (http://speedy.sh/rEfpz/voxeltexture-1.bmp)
I used A8R8G8B8 with the latest GIMP. Don't see what I qould've done to sqrew it up but it's the textures that have problems also. The file you linked to http://www.blackvoxel.com/dm_download.php?file=4 (http://www.blackvoxel.com/dm_download.php?file=4) works.
My textures look qorrect in an image viewer...
-
Looked at your bmp and everything appeared good to me right except it lacked an alpha channel on the second one.
I tried to do a step by step explication for your second image to work. I downloaded the latest Gimp version on Windows to be sure using the same name for the menu (the ubuntu 12.04 version I use is slightly outdated) and.... just discovered the same issue as you.
Crawling on the web, found a lot of complaints with the latest versions of Gimp and BMP. Even with the new "compatibility mode" checkbox it didn't worked .
So I will have to look in it what they did with the file format on the latest Gimp versions.
For interim solution until we found a way to fix it would be to get the 2.6.12 version of Gimp. I just tested it OK on Windows : http://sourceforge.net/projects/gimp-win/files/GIMP%20%2B%20GTK%2B%20%28stable%20release%29/GIMP%202.6.12%20%2B%20GTK%2B%202.16.6/ (http://sourceforge.net/projects/gimp-win/files/GIMP%20%2B%20GTK%2B%20%28stable%20release%29/GIMP%202.6.12%20%2B%20GTK%2B%202.16.6/)
All images must have an alpha channel (Layer -> Transparency -> Add Alpha channel), event the images that don't use transparency. And the inventory image should be done (use the same as the center). For now, it isn't used but will be in the future.
For images using transparency like glass, it must have a voxelinfo. It's not needed for regular voxels.
The Blackvoxel Team
-
Thank you now it works :)
-
We look forward to seeing the result!
:)
-
Qreated a new world to try some stuff out and gave myself 0xffff ffff of some items and 0xffff of some others and picking stuff up with my tool and with qomputers and maybe pushing and pulling voxels has qaused the qlient to qrash several times now. Have fun debugging ;)
Ask me about details if you need any. I don't really know why it qrashes though
Assertion failed: _gc_chain==NULL, file /home/laurent/workspace/blackvoxel/src/sc_Squirrel3/squirrel/sqstate.cpp, line 204
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
And another qrash (I might be pushing and pulling to/from empty space):
AN ERROR HAS OCCURED [indexing bool with string]
CALLSTACK
*FUNCTION [main()] C:\Users\Qon\Documents\Blackvoxel\Universes\2\Scripts\Squirrel\6.nut line [6]
*FUNCTION [qbits_save()] C:\Users\Qon\Documents\Blackvoxel\Universes\2\Scripts\Squirrel\6.nut line [14]
*FUNCTION [Voxel_Step()] C:\Users\Qon\Documents\Blackvoxel\Universes\2\Scripts\Squirrel\6.nut line [51]
LOCALS
[vargv] ARRAY
[this] true
[n] -117167720
[this] TABLE
[n] 0
[this] TABLE
I have no function qalled main and line 14 is
n--
Also qompressors seems to dupliqate when I pick them with the qomputer and the items that I try to pull from the qompressor stays inside it. And when I place a qompressor again the items are still inside! :Q
It's entirely possible that I'm doing something odd... I'm a bit tired q:
-
I picked up some infeqted voxels and some smiley monsters and played a bit with them.
The infeqted voxels were kind of unprediqtable, sometimes (or some places where) when I spawned them they didn't affect nearby blocks and turned to red liquid almost immediatly. Other times they started spreading endlessly and it took a looong time before any of the blocks finally turned to red liquid. That didn't stop its spreading since it qontinued to spread many times faster than it turned into liquid. My whole world was infeqted. The whole blue enter qube and, the water and white blackrocks around it, all the green blocks and the lava around that and then the big tree forest. At that time only a few blocks in the center had turned into liquid and everything else as far as I qould see was orange.
Good thing I had a backup of my world :o
-
I picked up some infeqted voxels and some smiley monsters and played a bit with them.
The infeqted voxels were kind of unprediqtable, sometimes (or some places where) when I spawned them they didn't affect nearby blocks and turned to red liquid almost immediatly. Other times they started spreading endlessly and it took a looong time before any of the blocks finally turned to red liquid. That didn't stop its spreading since it qontinued to spread many times faster than it turned into liquid. My whole world was infeqted. The whole blue enter qube and, the water and white blackrocks around it, all the green blocks and the lava around that and then the big tree forest. At that time only a few blocks in the center had turned into liquid and everything else as far as I qould see was orange.
Good thing I had a backup of my world :o
;D
It seems that these spreading voxels can be very unfriendly when used outside the sequence initiated by the "smiley" voxel ???.
In the normal case sequence, the spread time depends on of how many "smiley" voxel are disturbed at the same time.
The Blackvoxel Team
-
Same thing happened when I started the reaqtion by placing a smiley.
I tried to pick it up immediatly after placing it and succeeded but sometimes my inventory qount didn't go up.
-
PullVoxelFrom() will fail if the programmable robot does not have any internal storage slots without an voxel type, even if some of the slots have zero quantity. This combined with the bug that leaves the voxel type in the slots when you empty them makes for a game breaking bug. Once the programmable robot has filled all it's slots it can't ever pick up anything more until you manually fix those left over zero quantity voxels.
A workaround is to make sure you always have at least one slot that is completely empty, no quantity and no voxel type. But that reduces the programmable robots internal storage to 19 instead of 20.
-
Infinite death loop.
If you dig a deep hole at location x:0 z:0 you will end up in an infinite death loop if you die since you always respawn at x:0 y:0 z:0.
Either put a voxel below the player spawn point on respawn or scan for a safe place to respawn the player. (The later is probably prefered, or you could be stranded on a single voxel without anything in your inventory to build your way out.)
-
Atomiq Qompressor has id 49 but the manual says 100!
-
http://www.blackvoxel.com/view.php?node=1476
Siliqon Wafer needs a blackrock blue to be made but the recipe in the manual doesn't mention it.
-
Infinite death loop.
If you dig a deep hole at location x:0 z:0 you will end up in an infinite death loop if you die since you always respawn at x:0 y:0 z:0.
Either put a voxel below the player spawn point on respawn or scan for a safe place to respawn the player. (The later is probably prefered, or you could be stranded on a single voxel without anything in your inventory to build your way out.)
Thanks. We will fix that ;)
-
Atomiq Qompressor has id 49 but the manual says 100!
Thanks. Fixed ! :P
-
http://www.blackvoxel.com/view.php?node=1476
Siliqon Wafer needs a blackrock blue to be made but the recipe in the manual doesn't mention it.
Yes and there was a bug in the code. As was mentioned above, the Blackrock Blue was also got in the output. Fixed in the code and the manual. ;)