Jump to content

Tak Suyu

Members
  • Posts

    2
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!

Tak Suyu's Achievements

Tree Puncher

Tree Puncher (2/8)

0

Reputation

  1. I apologize if this sounds extreme or completely irrational, but the fact of the matter is that the Block ID situation sucks. One of the biggest problems with the modding community in its current state is that we have to meld these block id's together in some form so that they can play together without trouble. While in the beginning we started with configuration files that would let you change the block id associated with the block itself did help, that is still a rather tedious task to get enough mods to work together. Forge has a great function right now that lets compliant mods auto assign block ids and it'll take care of most of the problem no problem. A much greater fix in my opinion, but still missing something. The current problem with the system how it is, is that the auto block id allocation process cannot handle new elements without getting rid of the traces of the past allocation. This particular case would be that previous config folders may have to be erased to accommodate the new mod. In an even more serious case removing and then adding a new element, a mod in most cases, may create overlapping configs and lead to instability once a mod is then again added to the mix. This leads to quite a sad situation for modded servers in times like version bumps that vanilla servers just don't have; Stability. There are very few cases of servers that can continue to use their maps without major problems. From experience it takes a very careful and diligent server administrator to keep things like that working well. While most people would just throw the notion to the wind and make a new map, I don't really think we should have to destroy precious work like that. I do realize that time to time vanilla servers do have problems with version updates and the likes. It happens to any program; Sometimes. I propose thinking of a way to lay the foundation of a way where we don't have to deal with block ids and leading to a stable design that would allow servers to last the test of time. Something that will account for mods dropping in and out do to the nature of the beast that it is. Changes that occur among vanilla, mods, compatibility, and even modding layers. Now that the introduction is completed, let me get to the real meat of my post. This plan is hardly far from finished and certainly doesn't cover everything. That's why forums like this exist for however, to bring people together and lay down ideas for the next person to pick them up and add to it. Usually fruitless, but I personally think that depends on how much it really matters to the community as a whole. My idea as it stands is that we have a few very core things: Something to represent everythingFrom what I can tell is that there is already a system in place that can be mighty useful for this task. Block metadata is already used to scrunch block ids for many mods that have all sorts of functions. There's a few problems with the system like block states and whatnot but those can more or less be remedied with some sharp wit. We could have something that ultimately resembles most if not all blocks so long as they are handled by MCForge or FML. This may break the creed of not adding anything directly to the game, but I think that hardly matters at this point as solutions need to be made. MCForge/FML handle a staggering major or mods anyway, so adding a choice for modders to partake in a system like this is hardly asking much. If MCForge/FML were to have this "polymorphic super metadata" block it would have to be able to reliably tell what it is from another one and the high level actions it would have to undertake. Block States and the like would have to be sorted out and the current "BlockID" would have to be handled in some form. There's a handy technology that we all use today called NAT, that allows us to take one IP address and tie it to any address in the IP spectrum with a few exceptions due to limitations of the systems it was built upon. This idea could help quite a bit with our current situation of "too many blockid's what do we do". Since every mod already associates with MCForge/FML through mod id's why not tie their block id's to it also. This would allow the modder plenty of room with their own mod and assuming no one has the same mod id, which they shouldn't, they would have plenty of space to grow. This would also serve the purpose of handling mods coming in and out far better than the current systems configs. Downside however is that it would rely heavily on MCForge/FML to translate the blocks from a placeholder to the respective mod. [*]Making a system sturdy enough to encompass any situations we may come across All the little nitty gritty stuff has to be fleshed out in ideas like this so that the core foundation isn't continuously remodeled ultimately defeating the entire purpose [*]Standing the test of time I would like to see a modded server that can really stand the test of time so we can have amazing projects with all sorts of mod blocks that are able to push through version updates, both minecraft and mods, and shine like some of the other vanilla servers. I realize that my idea is a lot of work, probably for small gains in the first place. However this is what people like us code for; to fix mundane things. I'd love to see discussion on the topic even if nothing gets done right away, and most of all I would like to thank you for at least taking the time to read this post. It's a pleasure and I would love to talk to people who feel the same or hell even the opposite of how I feel, so that I can see more sides to this subject and possibly create an even better idea. ~ Tak Suyu
  2. Allowing a hook for world generation options such as only this ore or this mod specific properties would be a godsend for multi world bukkit servers and the like.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.