Author: allaryin

I am currently busy with an entirely unrelated project but found the time this weekend to hammer out fixes for few issues that were brought to my attention with classic EBXL builds. These updates are in testing and will be published to Curse once I receive confirmation from the affected users that everything works for them.

Until then, I’m going to post them here.

MC 1.6.4 – EBXL 3.15.9 (rc)

• Fixed log renderer registration to avoid some issues when running on servers.

Download: ExtrabiomesXL-1.6.4-3.15.9.jar (775.2 KB)

MC 1.7.10 – EBXL 3.16.4 (rc)

• Fixed name generation for certain leaf blocks. The old (lazy/broken) behavior was causing problems with Veinminer, Factorization, and probably other mods.
• Moved stack trace logging when an unfamiliar build of IC2 is detected.

Download: extrabiomesxl_1.7.10-3.16.4.jar (869.9 KB)

Well, it’s been two months since I last updated everyone here, and that’s largely because it’s been too long since I’ve made any progress worth showing. I’d gotten caught up trying to fix a rendering bug with Carnivora’s next release that cost me about a week and fried my brain for modding for a month. I’ve also been involved in discussions with other modders about some things that will only be announced if they start to pan out (but shouldn’t be eating actual development time from me).

And it’s HOT outside.

For those of you who don’t live in warm climates, I cannot begin to explain the mental toll 100F can take on a person. Especially a person who’s air conditioning is on the fritz 😉

And I’ve been distracted playing Persona 3… 😛

BUT! We do have progress on the mod.

Sorry for the extremely ugly screenshot, but the point is that EBXS Meadows does in fact have strawberries now – and the next build I release will make them available to people.

I’ve completely rewritten the way crops are handled, which should make different plant types easier to manage and more consistent in the future. Hopefully I’ll actually be able to knock out onions quickly now 🙂

I am also making wild crop spawning completely configurable. This is one place I really let people down in the original EBXL release – Strawberries were hard-coded to spawn in certain biomes and had non-configurable spawn density. That is going to change.

In the new release, it will be possible to not only add a new biome to the approved list for wild crops, but it will also be possible to configure the patch size. We will have the same default size and patch frequency as before, but all of these numbers will be tweakable.

OreDict Conventions

On that note, the subject of ore dictionary names for crops has come up on the forum thread, and is worth addressing generally.

We have always tried to maintain as much compatibility as possible with other mods. It’s a thing that matters to me. When it comes to crop mods, there really aren’t very many options out there. The main mod in question is of course Pam’s Harvestcraft. I’ve worked with Pam in the past to help her improve mod compatibility, and I play with her mod more often than not.

So when one of my mods introduces a food item to the game, you can be certain it is going to be as compatible with Harvestcraft as I can possibly make it. You can use Extrabiomes strawberries in her recipes, you can use Carnivora calamari in them, etc… Pam has a very consistent pattern for her ore dictionary naming, and I match it for this reason.

Not everyone agrees with this naming scheme, however. 10pak, the author of the wonderful Plant MegaPack mod (which we totally recommend), has a different opinion. PMP’s strawberries register themselves as “foodStrawberry” and HC’s strawberries register themselves as “cropStrawberry”.

10pak’s blog post asserts that this is because a “published standard” says to do it that way. I’d normally want to agree with him… but I can’t for the following reasons:

• The “standard” in question is a wiki page maintained by the community at large.
• The argument that “other mods were here first” should carry weight. The whole point of the ore dictionary is cross-mod compatibility. Precedent really should matter.
• His interpretation of the wiki post is flawed. According to the post, Forge itself registers potatoes and carrots as “cropPotato” and “cropCarrot”, not as “foodPotato” or “foodCarrot”.

There is, unfortunately, not any sort of formal standards committee for this sort of thing. The closest thing we have is the community of developers using the api’s in question and you’ll never get all of us into a room together to hash things out. The wiki page he’s hinging his decision to refuse compatibility with everyone else on is maintained by random community members whose names I don’t personally recognize. I’m not going to judge their opinions as superior to that of the actual established standard usage – even if that’s what they were saying.

So, in the future, I will continue to register strawberries as “cropStrawberry”. This agrees with Forge’s usage as well as that of the majority of food mods out there.

However, while I disagree with 10pak’s decision, I can respect it. In an attempt to extend compatibility in both directions and support PMP, I will also provide a configuration option to also register crops as “food”. The ore dictionary doesn’t care. The only downside to registering something with multiple names is that most unifying mechanics won’t combine stacks of items unless all of their ore dictionary names match, but that’s a small price to pay for making everyone’s plants get along better.

Foods that aren’t cultivated but might benefit from ore dictionary registration will be registered as “food” in my mods, and not as “crop”. So that means that I will be registering chocolate as “foodChocolate”, which I don’t think anyone will dispute.

I don’t like this solution, I wish everyone would just agree on a usage… but that’s not going to happen any time soon.

Something Completely Different

Well, not really different, just a brief anecdote. About 15 years ago, I was writing a MUD with a number of other people. We decided that players and npc’s alike needed to eat. So, I wrote a hunger system into the game. It killed many many idle players. It was glorious.

We provided players with numerous food sources, from cultivated farm plots to fruit trees to hunted game. Back then, I made the following decisions for filenames:

• /econ/crop/carrot.c
• /items/food/bread.c

So… yeah 🙂

So, there are usable builds of the mod available to the public. Some dozen people have even downloaded the thing and are presumably wondering what all the fuss is all about.

After all, the code isn’t public yet, and I haven’t even replicated all of the features of the original EBXL components I am recreating. Both of these will change quickly.

As far as source visibility questions go, I am currently developing in private Gitlab repositories visible only to the core EBXL team. This is the result of a few problems we had doing things the more traditional way during EBXL3.14-3.16’s development cycle. There’s no reason to go into specifics right now, but chief among the problems was the issue of account ownership. I have full control of the Gitlab account, so can do what I need with it.

In a few days, when I have multiple submods preparing for a shift from alpha to beta status and am happier with the way the core mod works, then I will make the code visible to the public – and will gladly begin accepting PR’s there. It will still likely be hosted on Gitlab for the time being, but that could change.

That said, the next submod I am going to start work on is Meadows. This is largely because there are no fundamental features of the planned Meadow mod that I do not already have implemented as part of either Core or Autumn.

Once Meadows is in alpha, I am hopeful that Zenth will have caught up on the art backlog, and I will be able to resume work on adding onions and mushrooms to Autumn.

We don’t plan on adding very much food to the general biome mods, but we will add a decent amount. The total current plan includes:

1. strawberries (identical to those currently provided by EBXL)
2. onions
3. mushrooms (more than one type)
4. rice
5. cherries (from sakura trees)
6. one more thing as of yet tbd

And that’s it. We will add a few basic recipes for each of these raw ingredients – ie, while you will be able to eat them raw, it will be possible to process them further to improve their nutritional value.

We have dozens of fruit trees and other crop types planned – but none of those will go into base biome mods. They belong in the farming submod that I discussed a year ago.

So… I’m working steadily on things. I may take a break now and again to work on Carnivora or MCUpdater, but EBXS is still my #1 priority. I’m even working on the mod instead of working on my Kerbal Space Station 🙂

The AutumnWoods alpha release is now available to the brave. Seriously, don’t download and use this, it’s only meant for testing – but I’m pretty sure some people will want to poke at things anyway, so this is for them.

• ebxs-autumn-woods-0.0.1.jar (ebxs-autumn-woods-0.0.jar)
• ebxs-core-0.1.jar

Both mods are required.

Things will probably go poorly if EBXL is installed at the same time, so please don’t do that 🙂

Any bugs should be reported on the Extrabiomes MCF thread for now.

Update: The original 0.0(.0) build has been rendered obsolete by 0.0.1, which while not much of a change is much better in practice.

Changelog 0.0.1

• Added en_US localization.
• Added plank recipes for autumn logs.
• Fixed minor performance issue at chunk generation time.

Well, now that’s more like it.

We have flowers and trees. The trees drop the right kind of saplings, and those saplings can be used to make more trees.

The flowers aren’t usable as dye yet – and the custom autumn wood furniture isn’t available yet, but this is a good point to have reached, and I will be releasing the first public alpha of Core and Autumn today for those who want to mess around with things.

Remaining Todo Items:

• Add wild onions.
• Add a few more flowers.
• Add a few new types of mushrooms.
• Add japanese maple and sakura trees.
• Make tree generation more cpu friendly.
• Add cherries.
• Flesh out remaining recipes for wood and flowers.
• Add upstream version checking to Core.

Once I’ve knocked all of that out, we’ll declare the Autumn submod feature complete. While I’m waiting for some art, I will be starting up on the Meadow submod. Hopefully, I will be able to spin out a basic alpha of it very quickly since it doesn’t require very much in the way of new logic.

The alpha builds will be listed on Curse, NEM, and here soon.

Update:
See here for download links.

Last Thursday night, I finished the rewrite on flowers and flower spawning logic:

Shortly after I finished up with that, I also discussed plans for additional features of the submod with the team. Zenth has knocked out some of the new art for a new plant we are adding, and we’ve discussed which flowers to add to which biome mods.

The current monolithic EBXL builds provide something like 40 flower types (I’m not looking it up right now). Future submods will provide no more than 15 each. As shown in the screenshot above, Autumn currently provides 2 of our legacy flowers plus our autumn shrubs. No other EBXS mod will provide these plants directly – but we will make it possible for them to spawn in other submod biomes if they are available.

On Friday, I started work on the first pass of what will be several on improving tree behavior. Initially, the trees will still be dumb, but I hope to make them slightly less so as time goes on.

And then my computer died. Like physically started shutting itself off. So… yeah. I’m working to isolate the failed component – but don’t expect to have a good desktop at home again any time soon. In the mean time, I’m still working on the mod in less than ideal dev conditions.

So… I really shouldn’t make promises, because things like this always happen :P. I’ll keep everyone posted as things progress.

This post is a technical look into the mod’s development process and may not be of general interest. You have been warned.

I’ve been officially working on the Extrabiomes rewrite for a few days now, and am on track to release a very broken alpha build for people to play around with on Friday.

Because so much behavior will be duplicated between the planned submods, and because so much communication is desired between them, I am implementing as much logic as possible in a separate mod – Extrabiomes:Core.

If installed by itself, Core won’t offer very much functionality. Eventually, I have plans to add some general biome tweaking options to Core that will allow you to modify vanilla behaviors and the like – but that isn’t a high priority right now.

One of the biggest things Core will do is eliminate redundant logic for things like config files and tree generation. This way, we don’t wind up in a situation where we are maintaining 12 different mods, each with 12 different copies of my improved leaf decay system. Instead, they will be able to hook into Core for that. It certainly isn’t a new idea, any time a single developer or group has to maintain multiple similar products they are likely to consider doing this sort of thing.

The other thing Core does is allow me to communicate between mods. I have written a system that allows submods to fire off events to inform Core of their features or ask Core for its status. Right now, I’m not doing anything terribly exciting with it.

For example, Autumn Woods is registering itself with Core and Core then actually handles registering the biome with Minecraft. Additionally, Core keeps a list of every biome any registered submod provides, so when Autumn Woods needs to choose a biome id, it asks Core. If I implemented Meadows with this system (which I will soon), Core would know the biome ID’s requested by both mods and would be able to log a conflict just a little more intelligently than if there was no communication going on.

Currently, the Autumn Woods biome is generating in world and setting its temperature, humidity, and grass color appropriately. But I haven’t ported any trees or flowers over yet, so it looks kind of funny:

It’s not much to look at yet, but it will be more interesting very soon. I plan on implementing flowers tonight and will write trees tomorrow.

If you look at our public Github repository, you will notice that not much has been done on EBXL since things calmed down in the wake of our port to MC1.7.10. This is because I have spent the last several months working on a new version of Extrabiomes in private.

There were three major changes in this version of the mod:

1. It was for Minecraft 1.8 – I started work on this back in November of ’14, when the first public Forge builds for MC1.8 started rolling out.
2. It was a from-scratch rewrite of the mod – EBXL is a very old mod, we have a lot of legacy code supporting design decisions back in the stone ages. Every time we want to change something, we’re having to deal with some of this legacy cruft.
3. It was not ExtraBiomeXL – And this is what I want to talk about.

In recent years, the trend has been for mods to grow and grow and grow. This bloat eventually kills them. If large mods want to survive they almost universally either split off into multiple mods or have majorly incompatible rewrites that pare down features while only keeping the mod’s name intact. A small handful of “kitchen sink” mods have survived and continue to be popular to this day – but every one of them (that I can think of) has had rough patches where they fell out of favor because their bloat caught up with their quality.

EBXL has always been governed by a few simple principles. The mod’s content has always been based in reality (so no crashed alien arkship biomes). It has always been a well focused biome-oriented mod (so no outrageous tech trees and complicated smelting mechanics for making hats out of bacon). And every block or item added by the mod has always had an in-game use (so no completely useless mud brick drops or something).

The more time passes and the more the base game changes, the more we want to add to this mod. But the more we add, the more danger we get in of becoming too heavy and adding things that either dillute the value of the mod or conflict seriously with other mods.

When I added chocolate covered strawberries to the mod, that was the line. Had we gone any further than that, then we would have been crossing over into kitchen sink territory. But we held off. There is no ice cream maker, no system for building with chocolate bricks, etc…

The plan always was to add a couple of wild edible plants (rice and onions in addition to strawberries) to the base mod, but create an addon mod that allowed us to add interesting farming and cooking systems. We wanted the addon mod to be something complimentary that likely wouldn’t appeal to everyone and didn’t belong in EBXL Core (what with its focus on being focused), but that hopefully still made sense to a lot of people and added a lot of value to the game in its own right.

The more we thought about it, the more we liked the idea… and the more time it was taking because of the organic nature of the codebase. So, in our infinite brilliance, we decided that it would be a good idea to start over from scratch.

Since the mod was considered largely feature complete for 1.7, we thought the new release of 1.8 made a perfect opportunity to kill two birds with one rewrite.

Our recent release history shows how well that has worked out so far 😛

As I started the rewrite, the first thing I worked on was a sort of plugin architecture that would allow addon mods to talk to each other. And it was about this time that we started talking about possibly thinning down the core mod in favor of breaking a few features out into submods. It wasn’t long before the conversation started us thinking seriously about just splitting the mod up into a half dozen self-contained mods that worked together wherever possible.

Once we realized that this is what we wanted to do – we realized that the XL suffix doesn’t really apply to this new vision for the “mod”. So I’ve spent this entire time trying to wean myself from talking about EBXL and start simply calling things Extrabiomes. We’ve joked a bit about calling the new mod(s) EBXS, and I’ll probably continue referring to it as EBXS in the code.

The first MC1.8 mod that we had wanted to release was Extrabiomes: Autumn Woods. It would have contained (among other things) the autumn woods biome, several of our trees (rewritten for efficiency), and a couple of new mushrooms.

After that, I wanted to release Red Rock as a standalone mod, then Farming, then Meadows, etc… Each smaller mod would allow people the freedom to pick and choose without being saddled with biomes that maybe they didn’t want. Like when you don’t need two different kinds of redwood trees on a server. The smaller mods would also allow us to expedite releases for these smaller mods. If there is a bug in quicksand, we only need to QA our changes to the mod that provides quicksand, not the one that provides cherry trees.

But people aren’t switching to MC1.8. Modding is still very much alive on MC1.7.10 – which is possibly the Minecraft version that has had the most mods ever released for it. NEM lists over 900 mods for 1.7.10, but less than 200 for 1.8.x – and many of those are jar mods.

So. We’re sticking it out with 1.7.

I am going to start on Extrabiomes: Autumn Woods for Minecraft 1.7.10 today and I will have a standalone alpha build available for people interested in testing some time next week.

As far as what happens to the XL bit. Well, we still plan on making a single large download available. It will simply provide the latest version of each of the smaller mods in one bundle, so you can choose for yourself – and we can be more aggressive about making updates to individual biomes, and more aggressive about adding content that maybe doesn’t fit with the theme of the original mod.

Wish us luck.

It’s been entirely too long since we’ve had a release here, and that is completely my fault. But you’re all tired of me beating myself up about that sort of thing, so we’ll just dispense with the drama.

This is a maintenance/bugfix release. It contains numerous small changes that have happened since 3.16.1 was quietly released two weeks after 3.16.0 was released last october.

Download: ExtrabiomesXL 3.16.2 (for MC1.7.10)

Changelog

• Fixed Treecapitator support.
• Added the ability to disable quicksand to the config file.
  • Also added the ability to disable cracked sand, but this behavior is currently untested if you leave wasteland biomes enabled.
• Added the ability to disable “legendary” oak generation to the config file.
• Merged in a lot of localization updates from the community for:
  • French
  • French Canadian
  • Italian
  • Brazilian Portuguese
  • Russian
• Fix for disabled Forestry backpacks crashing things.

Treecapitator fix confirmed 🙂

I’d like to extend a special thank you to everyone on the forums who has kept the discussion alive – which finally convinced me to sit down and bang out some of these fixes today 🙂

As far as why I’ve been so terrible about getting these releases out to the public, well, that’s partially due to what I’ve been working on for the future of the mod.

I had hoped to release at least some teaser screenshots or something by now, but obviously that has not happened. So, I plan on at least announcing something with respect to our plans next week… *ominous foreshadowing*

Howdy. Sorry for the mess, but we’re rebuilding things over here after losing access to the previous domain.

From here on out, EBXL’s home will be at http://extrabiomes.com (no longer .net), and this domain won’t be going away.

We also have plans to bring up a good documentation wiki and download page over here that should materialize soon. Also, maybe I can get Zenth to do something about the ugly theme I’ve managed to cobble together 😛