Jump to content

Some web services and downloads are currently unavailable due to internal restructuring. In the meantime you can probably find what you're looking for in our Discord chat server. For more information, check the newsfeed or ask in Discord.

(AMC)

Minecraft mod pack created for Asterion Minecraft

This is a legacy project. Support for this project was discontinued in January 2016.

While Ginever Entertainment no longer provides any official support for this project, you may be able to find help within the wider Ginever community. For more information, feel free to ask in the forums or in our Discord server.

Sign in to follow this  

The future of Robbit


Tinytimrob

Advance warning: This blog post is rather long. I apologize for the long length of the post, but I wanted to be thorough and cover everything that I felt was relevant. I would appreciate it if you did not 'TLDR' and skip this post because you will lack the context for future Robbit developments if you elect to do that (and I don't want to have to repeat myself!) Thanks.

Introduction

Since the Robbit development freeze in March 2015, and the closedown of Asterion Minecraft in January, I find myself continually being pestered for a private Minecraft server by the Ginever community. A lot of people have been playing single-player Robbit, setting up small Robbit LAN worlds, and some people have even been playing vanilla! I'm also getting quite a few requests for a dedicated server jar. I wasn't really expecting all this fuss, but it does seem that there is still quite a large interest (at least within the internal community members) for a private server that people can just play on casually. People have come up with some ad-hoc solutions so far, but nothing great.

I considered what to do about this. I'm not able to enjoy Vanilla any more because it seems really limited, so I don't really want to run a private server using Vanilla. I also had someone suggest that we put together a new mod pack not reliant on Robbit core, but I'm not fond of that idea either (for obvious reasons). The only thing I can come up with that would realistically be viable is to run a private dedicated Robbit server. It will either be run over Hamachi as a LAN server, or it will be operated with a whitelist. The latter is more likely. Because this will be a private server that is not open to the public, we will not focus too much on our traditionally elaborate setup (like spawn areas, time capsules, etc) and there will be no factions, groups or plots. The texture pack whitelisting will also be turned off. It will therefore effectively be very similar to that of a single player LAN world.

My plan is to have a main overworld area (using the traditional dims of -1/0/1) and a fresh set of dims 100/101 for free creative building. The remaining dims will be disabled. In place of the previous faction teleporting commands, the /warp command will return so that we can teleport around to peoples' constructions.

Effectively, it's going to be Madras Overworld 2.

A name hasn't been decided on yet for this new private server, so I'd love to hear some suggestions. Please feel free to post ideas as a comment in response to this blog post.

The plan to create a dedicated private server requires me to work on a new update to Robbit, because the Robbit dedicated server was never designed for this purpose and isn't currently able to run in the needed configuration. I have therefore been considering whether there is something else we can put into the update while I'm working on it.

The technical issues regarding new updates to Robbit

The recent release of Minecraft 1.9 means that the mod pack is now considerably behind vanilla Minecraft in some areas. I really want to add feature parity at least with vanilla MC if we're starting up a new server, but unfortunately this is hard to implement in-place.

My design philosophy with Robbit has always been for it to feel streamlined and smooth, with strong effort on making sure the pack doesn't feel like a randomly thrown together and disjointed mess. Any future updates should preferably continue to honour this philosophy. Part of the implementation of this philosophy was the desire to avoid the 'jumbled mess' of items in NEI; to this end, previous versions of Robbit changed the block and item IDs so that similarly related items were ordered next to each other. For example, all planks would be next to each other, because they had consecutive IDs. This design decision was chosen because NEI ordered content via ID number, and it was largely what people were using to find stuff.

Unfortunately, this led to a problem of map compatibility between versions, because the IDs often changed around. Subsequently, we went with chunk remapping - an in-house system which went along on every major Robbit update, looked at the ID numbers of every single block and item in the game and remapped every block in every chunk one at a time. It started out very simple, but it became increasingly more elaborate as time went on in order to solve new remapping challenges, such as dealing with removal or replacement of mods without breaking map compatibility. For example, the conversion of lighting and wiring from RedPower to Project Red was done by the chunk remapper, which had to do a very complex and long winded conversion because the mods were designed in fundamentally different and incompatible ways - it took several weeks to perfect. Nobody else had this sort of conversion and upgrade system in place for their map files, which is mostly why old maps died with their mod packs.

The main disadvantage of chunk remapping is time. It is a very slow process. The remapper has to process every single block and item in the game and that can take a while. Single player worlds have only a few dims and are typically very small so the remapping doesn't take very long (maybe 5 or 10 minutes), but the Asterion Minecraft world archive is over 30 GB in size and might take up to 24 hours to remap. It's also a huge memory hog.

There is also the problem that since we switched to MapWriter for Delicious Doughnut (1.6), a local cache of the explored areas of each server you play on is retained by MapWriter so that it can re-render the map data as you are exploring. This causes a problem for the chunk remapper, because if the world gets remapped, the ID layout of the exploration cache no longer matches reality. The in-game map would go crazy and corrupt itself, maybe even crash the game. So either we have to remap the exploration cache as well, or delete it. The former would potentially cause every person rejoining the server after an update to go through a 24 hour loading screen on their first sign-in; obviously that wasn't acceptable so I was forced to opt for the latter and delete the data.

These issues are the main reason why Robbit was not developed and rolled out onto the server in small segments, and why we preferred to infrequently release major patches, rather than regularly release small ones. It was inconvenient for the server to be down for such a long time every time new stuff was added, and inconvenient to have to wipe the minimap exploration data on every remap. Other servers and mod packs obviously did not have this problem, but instead they suffered from a disjointed mess of items in NEI/creative, along with the loss of compatibility when they made breaking changes to the map files. There are pros and cons to each approach and the choice we made was to preserve the philosophy of the pack.

Now you might wonder why I'm telling you all of this stuff. Well, it has great impact on future developments.

When the Asterion Minecraft server closed, I released a world archive for people to explore and reminisce. If I release a new hotfix which forces a remap on people, everyone who wants to open the world archive has to remap the archive data, which might take days on a very slow computer. The alternative is for me remap the world on my end, and then force everyone to redownload the archive - but it's pretty huge, and that's a lot to ask of people. So, I feel that any updates we release in future have to retain compatibility with the map archive without forcing a remap.

Subsequently we can't delete anything from the game, or replace any mods with alternatives (like we did when we moved from RedPower to Project Red), at least not in a way that breaks map compatibility.

I still feel that honouring the philosophy of the mod pack's design is important. I don't want the loss of the server to undermine everything that Robbit stands for. Therefore I'm forced to find another way.

Avoiding remaps in future versions

Because we can't remap the world any more, and I still want to be able to add new stuff, and I still want it to appear in order, I was left with no choice. I spent a few days refactoring parts of the internals of Robbit and the mods in the pack in order to come up with a new approach to ID mapping in Minecraft. It works as follows:

Each block and item in Minecraft now has two different ID numbers: a mapping ID and a sorting ID. The mapping ID is the same as always, and is used for storing data in save files and identifying blocks and items within the world. But crucially, it is no longer used for sorting. That job is now assigned to the sorting ID, which is now used instead of the mapping ID whenever the game needs to sort items (in the NEI list, in the creative inventory, in the Inventory Tweaks mod, in the Applied Energistics crafting terminals, etc). Because these two IDs are allowed to be different, and changing the sorting ID of an item or block does not break save file compatibility, this system can be used to effectively slot new items into the middle of the sorted list of items without requiring the save file to be remapped. However, it has one major limitation: it is not possible to remove blocks or items from the pack, or to fundamentally change how they are represented on disk. In short, if we want to replace a mod with one that works differently, or delete something from the pack entirely, we will still have to resort to a remap.

Because a remap is being avoided, any new stuff we add to Robbit in the future has to work seamlessly in synergy with what we already have. But this approach actually allows us to add new stuff. Which is great news!

Crucially, because we're not breaking compatibility with previous map files, this new development approach also has one major advantage - content can be developed in small segments and then rolled out in small trickles as soon as it is ready for use.

The future of the mod pack

Due to the fact that we can now use a 'trickling update' approach to development, and the fact that we don't have much free time to work on Minecraft any more (because we have to focus on Intryon), we are opting to pursue the development of Fondant Fancy (the next main Robbit update) in the form of many small patches. Whenever we have free time and we are not able to spend it on Intryon for some reason, and we feel like working on Robbit, we will contribute to Fondant Fancy. And when enough new stuff is finished and working to warrant an update, we will roll that content out immediately.

The primary focus during the early stage of the Fondant branch will be the backporting of missing 1.8 and 1.9 content. The initial focus is for 1.8 feature parity; once that's done, work will start on 1.9. The choice was made to backport because it is WAY easier than trying to forward-port everything in the modpack to MC 1.9 - the internals of 1.9 are enormously different to 1.7, and most stuff would have to be rewritten from scratch, which is way beyond the scope of this project (and the main reason most mods are still not officially updated to 1.8 or 1.9 yet despite 1.8 having been out for so long). It is possible we will eventually update Robbit to a newer version of Minecraft, but for now, that option is extremely far out of our reach, and not really viable given the resources we have available. It's also dependent on critical mods being updated to 1.8+, which seems to be fairly unlikely.

Personally, I suspect that any version of Robbit that would hypothetically get built around a newer version of Minecraft than 1.7.10 would probably end up being some sort of "Robbit 2". Whether or not we ever develop that is highly debatable. I'm not going to rule it out, because I just don't know, but I'm not promising anything either. Long-term development of Minecraft related stuff isn't financially viable for Ginever (especially with all the continual changes to Minecraft internals and the plummeting user base) and the Robbit mod pack sits in questionable legal ground (because of the childish bickering between mod authors over mod ownership and licensing), which is precisely why Robbit was relegated to an unofficial side project in the first place. We will work on it if we can (for fan service and other such reasons) but can't highly prioritize development work if there is other stuff to work on.

What is coming soon?

There will be another blog post later (when I'm able to access a computer that can run Robbit) which will detail development progress on Fondant branch. As with the other Ginever projects, I will endeavour to post blog updates whenever it is feasible to do so.

All I'm going to say for now is this - bat wings, rubber wood planks, ocean monuments, banners, and slime blocks. You can probably figure out the rest.

That's all for now folks! (Sorry for the long post.)

Sign in to follow this  


User Feedback

Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Create a new GineverAccount today. It's easy!

Register a new account

Sign In with GineverAccount 5.1

Already have an account? Sign in here.

Sign In Now

×