New Blocks
#1
Whilst browsing the available plugins, I made an observation. There is no plugin that adds some sort of block. Correct me if I missed it.
So, I have one thing to ask: why is that? Is it because no one was interested in making one? Or because there is no way of doing thus? If the latter is the case, does anyone know if there are plans on adding such a feature?
Reply
Thanks given by:
#2
MCServer supports all the blocks you want and more. You place some kind of furnace from the "More Furnaces Mod"? No problem MCServer will save them. The thing that is much harder to do though is creating a handler. There is no real way of doing that in a plugin.
Reply
Thanks given by:
#3
Currently there is no way of implementing any special block behavior in a plugin, and there is no plan for that either. There are quite a lot of obstacles in the way, to name a few:
- what to do if the plugin ceases to exist and the block is loaded?
- what to do if the plugin is reloaded mid-game?
- how much performance would be lost when implementing blocks in a plugin? The calls are not exactly cheap.
Reply
Thanks given by:
#4
There should at least be an API to register a new type of block and give it to players.
Reply
Thanks given by:
#5
You can give any block to a player, using the numeric ID. To add a block type name, just edit items.ini, no need for a plugin.
Reply
Thanks given by:
#6
I see three ways of providing support for handlers

Lua way one:
Create a new blockhandler cUnknownBlock with hooks for all the calls.

This is the most expensive in performance but fits the existing apis.

Lua way two:
Create a new blockhandler cUnknownBlock which wraps a lua table of functions. Then provide a function to register this blockhandler in a cache kept by cBlockhandler.

This is less expensive as we only call one plugin but is more complicated.

C++ way:
Use dynamic loaders to load user provided shared objects that register a factory with cBlockhandler then behave like any other handler.

Most performant but most complicated to use.

I think we should go for the second lua way as we dont want to be calling hooks for every tick.
Reply
Thanks given by:
#7
What if the server just offered the data but what to-be-actually-done with the block was handled by a client-sided mod?
Reply
Thanks given by:
#8
You'd continue with current behaviour of using a generic block-handler that just does the basics.
Reply
Thanks given by: jimmis98
#9
Nevertheless, it would really be nice if the server were to provide a very simplistic way of adding new stuff, like, a plain file that would store additional smelting/crafting recipes, another file with additional items and another with additional blocks (all of the containing only the bare minimum, like new IDs so that lua or other mods can refer to them). And they would have a simplistic form too. For example:
file A (additional recipes): (where # is the recipe's increasining number inside the file, as well as its identification)
recipe # = {[id for item on slot 1],[id for item on slot 2],[and],[so],[on],[...],[...],[...],[...]}
etc...
You get my point... (and probably I don't get yours... Mine is a very narrow-minded approach to the situation, so I apologize beforehands)

A question if I may? How would someone go about creating a world-generation altering mod?

(Please don't judge me harshly, I just want to be able to completly ditch the java server)

I am truely amazed by the activeness of the forum... New answers arrive the same day, discussions carry on... Wow
Reply
Thanks given by:
#10
Don't worry about your posts, you've brought up a couple of big holes in our plugin api which we need to fix.

As for simplistic blocks the crafting.txt handles recipies and items.ini handles names used internally. MCServer *should* be able to handle additional IDs without any modifications so it all should be implemented already.

Feel free to post if you have any issues with it though.

As for world generation there isn't an API for directly modifying generation but you can modify the chunk when the OnChunkGenerated hook fires. This does need additional thought so if you'd like to suggest an API we'd be interested.
Reply
Thanks given by:




Users browsing this thread: 6 Guest(s)