Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
Patch integrated as rev 1002.
In BlockID.h / .cpp, there are various arrays that can be used to determine whether a block has a specific property; I think nonsolidness is one of them. This might help you alleviate the bug.
Also, I'm not sure but I think your code might have problems with Y == 255. Didn't test it; just by looking I see an addition to a Y-coord without a proper check for range.
Posts: 6
Threads: 0
Joined: Nov 2011
Thanks: 0
Given 3 thank(s) in 2 post(s)
10-23-2012, 05:13 AM
(This post was last modified: 10-23-2012, 05:16 AM by funmaker.)
(10-23-2012, 04:07 AM)xoft Wrote: In BlockID.h / .cpp, there are various arrays that can be used to determine whether a block has a specific property; I think nonsolidness is one of them. This might help you alleviate the bug.
Code: NIBBLETYPE g_BlockLightValue[256];
NIBBLETYPE g_BlockSpreadLightFalloff[256];
bool g_BlockTransparent[256];
bool g_BlockOneHitDig[256];
bool g_BlockPistonBreakable[256];
bool g_BlockIsSnowable[256];
bool g_BlockRequiresSpecialTool[256];
none of these arrays can determine nonsolidness 
I think I should make something like:
bool g_BlockIsSolid[256];
and
bool cBlockHandle::CanBePlacedOnNonSolid();
Solid block is a full, nontransparent block.
This should be very userful for blocks like redstone, ladders, etc.
What are you think about it?
(10-23-2012, 04:07 AM)xoft Wrote: Also, I'm not sure but I think your code might have problems with Y == 255. Didn't test it; just by looking I see an addition to a Y-coord without a proper check for range.
Funcion cChunk::GetBlock(int,int,int) uses cliping on arguments.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
10-23-2012, 05:40 AM
(This post was last modified: 10-23-2012, 05:49 AM by xoft.)
(10-23-2012, 05:13 AM)funmaker Wrote: bool g_BlockIsSolid[256];
Sounds reasonable.
(10-23-2012, 05:13 AM)funmaker Wrote: bool cBlockHandle::CanBePlacedOnNonSolid();
Isn't this a bit useless? Once you have that array, the blocks that cannot be placed on non-solids will check against it. I don't think there's so many of those that it would need a special function.
Quote:Funcion cChunk::GetBlock(int,int,int) uses cliping on arguments.
M'kay, but only after going through the list of blocks queued for changing and finding the correct chunk. So you're wasting two critical section locks and a chunk lookup. Sure, it isn't much, but we can't afford wasting even this much if we want to be high-performance 
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
Added a new task, AnvilStats module for OreNests.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
Please do read again the second paragraph of the very first post 
For suggestions, start a new thread or put them in the flyspray tracker. Posting them in the middle of a forum is pretty useless.
level.dat is created only with the spawn position, so that tools like Minutor can work with the level data; it's not intended to be used in any other way. There's no point in saving the seed, since the terrain generation is much different from vanilla. Time, weather and all the other useful stuff should probably be saved in the world.ini file, since they shouldn't be dependent on the storage schema used.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
Added the "Unify Finishers" task.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
Spring finisher has been already added, and finishers have been unified.
Posts: 1
Threads: 0
Joined: May 2013
Thanks: 0
Given 0 thank(s) in 0 post(s)
Yesterday found this project and it seems very interesting. But I noticed there is a problem with stairs, which are placed incorrectly. Tried to create patch for this. But not sure with that condition. I started to study code today so I'm little lost in all these magic numbers. But seems working in my testings.
https://www.dropbox.com/s/umt4ymh5o7bqawb/stairs.patch
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
05-21-2013, 05:46 AM
(This post was last modified: 05-21-2013, 05:54 AM by xoft.)
Hello, and welcome.
Good job on that, only I'd keep the comparison as "greater-than", because older protocols (pre-1.3 clients) don't send the cursor coords and expect the stairs rightside-up; the protocol handler gives the cursor a dummy value of all eights (i. e. in the middle).
As for magic numbers, we're getting rid of most of them, but the ones used here don't make much sense to be named, "half-cursor" or whatever for 8, and "bit_3" for 0x4.
I suppose you've already seen the materials we mostly use, most of the data values are in the minecraftwiki.net ( http://www.minecraftwiki.net/wiki/Data_values ) and the protocol is documented in wiki.vg ( http://wiki.vg/Protocol ).
I'll commit your patch to the codebase now.
I updated the list in the first post - removed the finished items and added block rotation and mirroring.
Posts: 6,485
Threads: 176
Joined: Jan 2012
Thanks: 131
Given 1075 thank(s) in 852 post(s)
Added vine growth to the list.
|
