Search results

Sounds like a bug. But how difficult is it to get dirt in this pack?

I know this was partially answered already. The plant arrangement UI is purely a decorative function. The gardening trowel tool you have in your hotbar that you used to open that UI doesn't serve any purpose in this pack. But if you want pretty things for the sake of pretty things, then by...

Please be sure to copy me on Garden Stuff-related bugs that are, you know, crashing peoples' clients :) I don't think there will ever be deep cooperation with Botania (for technical and balance reasons), but it should certainly never crash clients.

My bad, I failed to see that this was a terrible necro-bump (shame on you!), and so I was responding to the OP. Not you.

The current logo is clean and easy to identify. I wouldn't consider your design better in either of those aspects.

TiCon Mattock is the correct tool.

Huge memory isn't necessarily a good thing anyway. If your mod list is huge, you'll need it just to be able to run. But a bigger memory slice means longer pauses every time garbage collection kicks in, assuming that your client is continuing to leak memory as you play. My experience so far is...

It's the Microsoft problem. No matter how much you change, people still insist you're yesterday's news.

I left a note in your issue on Garden Stuff integration. I think it requires work on both sides so I'd like to work with you on that. Without knowing the precise direction you're taking growth mechanics though, the direction of that is largely in your court.

We're talking about a game engine that allocates and discards hundreds of thousands of objects willy nilly. Until someone benchmarks two realistic implementations in-game and demonstrates a statistically significant difference between the two, I think it's just noise.

One of the benefits of the in-game config is you have an initialized Forge environment with all the mods loaded. You can use that data to make some of the config editing easier for the user, such as picking valid blocks for a config entry. It's not totally fool proof, but some mods already do...

In this case I was equating an author with their work (if you don't trust their config code, why would you trust any of their other code? Do you assume they just never test that part?) There are a lot of things that can't be edited at runtime (block and item registrations are the most...

If a mod author takes the time to present a config GUI screen, a vote of no confidence in that screen is also a vote of no confidence in the author. Are you sure you want their mod in your game? Some mods also edit their own configs with chat commands.

Bibliocraft potion shelves (and to a lesser extent, item shelves and tool racks). Loading up a dozen potion shelves with items will cause massive render lag and drop your FPS like a rock. Storage drawers blocks not configured to fast rendering will also cause render lag if you spam enough of...

It would be nice if mod authors checked their own logs before releasing. Missing texture? Add a dummy texture or get rid of the load statement, please.

So what happens when CoFHCore, AsieLib, Mantle, etc., etc., all do the same thing because they're not willing to take a dep on DragonAPI? Are all these hooks going to be able to coexist?

Good luck. Lex is either clueless or deliberately antagonistic over this issue.

I think you really don't understand the kind of rendering these mods are doing. How many total permutations does your custom block represent? Most of these tech mods or aesthetic mods have blocks with trillions or unbounded permutations.

And that 10% of dynamic content may take up 90% of what amounts to be a large porting effort.

Sure. Something is going to happen eventually. I hope we do get a real solution baked into Forge though. Otherwise it could turn into a pissing contest between core mods.