Tasks that are Easy Enough for newcoming programmers
#21
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.
Reply
Thanks given by:
#22
(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 Undecided
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.
Reply
Thanks given by:
#23
(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 Smile
Reply
Thanks given by:
#24
Added a new task, AnvilStats module for OreNests.
Reply
Thanks given by:
#25
Please do read again the second paragraph of the very first postTongue

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.
Reply
Thanks given by:
#26
Added the "Unify Finishers" task.
Reply
Thanks given by:
#27
Spring finisher has been already added, and finishers have been unified.
Reply
Thanks given by:
#28
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
Reply
Thanks given by:
#29
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.
Reply
Thanks given by:
#30
Added vine growth to the list.
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)