Great job guys !!

[mgueydan]

Hello everyone,

I just discovered the amazing MCServer. I think you guys are making great work.

As I'm no rookie in C++ development, I tried to join the effort. You will find some of my intervention on tickets : 404 (that I created) 277, 297.

404 is simple ini-File fix
277 is bug-fixing
297 is kinda new feature
all of three are working fine on my local version of MCServer.

Code updates are posted inside comments on FlySpray (that's not the best way, but at least that can be cancelled without any difficulties)

That way anyone who is responsible of integration here will know if my work is good enough to be integrated (i think so, but, as I'm me, I'm not really impartial).

Whatever the result would be. I think you are making great work here.
Please keep going.

[xoft]

Hi, welcome to the community.

It's always good to hear praise, and it's really awesome to be inspiring someone enough to join the team. We're lacking the manpower needed to keep up with the vanilla MC, so every helping hand counts.

As for the contributions, I see you've made a real effort on describing them in the flyspray tracker; I personally would have preferred a patch file. Since FS doesn't seem to accept file attachments at all, the easiest way would be either to post them to this forum, or send them via PM to one of the devs. Currently, that means FakeTruth or myself (I do hope the other contributors won't take offense for me not including them).

Unfortunately I'm already working on FS #297 (player staying on fire) as a part of a bigger rewrite, I'm moving all the damage-handling code from cPawn to cEntity and unifying the fire handling there. I was hoping it would be a fast fix, but it turned out a big one, so it's still gonna take some time. Just as a quick tasting of the new refactoring, I'd like to drop all the cPawn's MetaData, replacing them with cEntity's functions and the network protocol translating functions like IsOnFire() to entity metadata as needed. We've already seen several changes in the protocol that de facto broke these things, so it makes more sense to have them separate from protocol representation.

Feel free to post the other two as patches here, I'd like to review them before merging

Thanks again.

[FakeTruth]

Hey there,

That's great news
If you eventually feel confident enough to commit changes yourself send me a message so I can give you access to the repository.

[mgueydan]

Hello,

Here are the requested patches. Two of them already are useless, but that way you can see my code.

I'm gonna try a new bug today, please tell me if you want me to try to solve specific problems.

And if you do, which ones.

Thanks.

[tonibm19]

I'm gonna try a new bug today, please tell me if you want me to try to solve specific problems.

And if you do, which ones.

Maybe try to fix FS#403. It would be fine to have nether without sheeps and cows.

[mgueydan]

Maybe try to fix FS#403. It would be fine to have nether without sheeps and cows.

Okay i'll try to do that.

Never played in nether for now, plus have not seen any part of the landscape or generator for now, so I'll have to learn some things before reading code.

Tried to generate a Nether world. For now I just was able to generate some chunck of Forest in an huge empty laval lake.
   

[tonibm19]

STR_Warrior made a patch that fixes it.

[mgueydan]

I'll have to learn some things before reading code.

Finally I was weak and dived into code. Seams to be pretty easy indeed.
Just have to find how to test.

---

Just have to find how to test.

Did some of change inside world.ini and I'm now in something new. Is this Nether, I'm not sure.
   
Maybe there is same way for me to get an already working nether world.ini somewhere ?

[xoft]

Wow, you seem uniquely drawn to weird generator settings, I'm especially curious how you managed to generate the screenshot in post #8, can you post your world.ini?

For a Nether world, you need to set world.ini properly. Best to delete the entire [Generator] section and replace it with contents below; the server will auto-fill the missing values.

Code:

[Generator]
BiomeGen=Constant
ConstantBiome=Nether
HeightGen=Flat
FlatHeight=128
CompositionGen=Nether
Structures=WormNestCaves
Finishers=BottomLava, LavaSprings
BottomLavaHeight=30

# This sets the proper lighting mode on the client
[General]
Dimension=-1

We really need to update the wiki on world.ini, the nether settings are missing altogether.

---

Of course, once you set this world.ini, it's best to delete all the mcr files so that the entire world is regenerated; otherwise you'll have leftovers from the already-generated world. That's probably what happened in post #6's screenshot.

[xoft]

Well, if you really want something to do, it'd be great if you had a look at FS #348: http://www.mc-server.org/support/index.p...ask_id=348
It calls for a per-world configuration of the mobs allowed to spawn (if any at all).
I had imagined the world.ini would contain a section like this:

Code:

[Mobs]
Enabled=1
Allow=Cow,Sheep,Pig

This would be read into cWorld and the mob spawning would take this into account, together with the current biome (which imho is better than current dimension) when deciding what mob to spawn. Also, keep in mind that the spawning will need to be changed later, so that it takes the current light value into consideration and can spawn mobs underground; but don't go there yet, leave this to be implemented at a later time. Especially the light value will be a challenge, since it will require some cooperation with the lighting engine thread, with lots of deadlock potential

I envision you'd create a simple framework for this that can translate between "cow" and E_ENTITY_TYPE_COW and will provide a unified entrypoint to check "is this entity type allowed here?", with "here" being for now a biome; later we will expand it to take light value, block contents and entity size into account.