Azdoine wrote:
That makes a surprising amount of sense...
Goddamit Mojang.
Remember..."The Nether" was originally named "Hell" until it was changed due to public reaction.
Again: paying too much attention to public reaction in game design is bad bad mojo. Hence why "fuck off" is my typical response to critique :)
To be fair to Mojang, I think the Nether makes more sense in context and works better with the rest of the game. 'Hell' doesn't fit with the rest of Minecraft.
Last_Jedi_Standing wrote:
To be fair to Mojang, I think the Nether makes more sense in context and works better with the rest of the game. 'Hell' doesn't fit with the rest of Minecraft.
Oh...I don't have any objection to the name itself. It's all about the reason why it was changed.
actually, if you remember so far back; before infdev there was a terrain type named 'hell.' actually it was there before crafting, i remember it being the map type notch used to show off torches when they were first introduced; because it was always night. After infdev it disappeared until the Halloween update two (or is it three now) years ago and came back on a world of it's own.
Oh i miss indev- back when fire could destroy every tree on the 250X250 map.
I wound up spending a rather ungodly amount of time on the mod today, and just dragged myself away a few minutes ago after noticing the time once I successfully planted some carrots in some Planters ;)
All 1.4 related problems are fixed, and I've been putting a lot of work into going over the new vanilla features one by one tweaking and nerfing as necessary.
The only real outstanding issue I have left that I want to address is the whole animal in the nether thing, which I'll resolve tomorrow.
After that, port to server, and we should be good to go :)
Hehe, got into the code space did you? :P Great news to hear that things are going well for you! Your success gave me the last-minute motivation to meet my deadline!
I thoroughly enjoy your dev diary, as I've said before. It's neat that you provide insight on the process of making a kick-ass mod. If only big game developers could be as open as you are...
Anyway, great to hear things are going well, and keep up the good work! I may get a pre-paid visa card so I can pitch in for a coffee :P Depends on how many dimes I can scrounge up!
At one point I thought that the world was perfect.
Then I found BTW.
Now I'm in therapy.
Sarudak wrote:Is that in 1.4? Cause I use default textures but I don't play without BTW.
Yup, this is 1.4. I've been playing around in it for a couple of days now with BTW, and the new textures have been grating on my nerves.
Pork chops just kinda look like an indistinct blob of flesh in your inventory now, for example. I'm really not sure why they did this, as I think it just looks objectively worse.
IIRC they added the potatoes and carrots without dark outlines around them, and when the community complained about the stylistic differences between the old and the new they went back and changed all the other food to be consistent with the new stuff. A little backwards if you ask me, but hey, its mojang :/
They seem to show a lack of care for textures in general. I wonder if it's a combination of them being programmers and them figuring most people use texture packs...
Sarudak wrote:They seem to show a lack of care for textures in general. I wonder if it's a combination of them being programmers and them figuring most people use texture packs...
Well, I'm hardly one to complain, as I certainly don't consider myself an artist, but it does seem odd to me that they'd take a step that seems so blatantly in the wrong direction.
It seems pretty simple to me when exhibit A looks one way, and exhibit B looks worse :)
Sarudak wrote:They seem to show a lack of care for textures in general. I wonder if it's a combination of them being programmers and them figuring most people use texture packs...
Well, I'm hardly one to complain, as I certainly don't consider myself an artist, but it does seem odd to me that they'd take a step that seems so blatantly in the wrong direction.
It seems pretty simple to me when exhibit A looks one way, and exhibit B looks worse :)
Can you just change it back? That seems like it'd be a pretty easy thing to do.
Last_Jedi_Standing wrote:
Can you just change it back? That seems like it'd be a pretty easy thing to do.
Errr...not that simple. It would involve integrating the old vanilla texture sheet with the new, and continuing to maintain that, which is probably more the domain of texture packs rather than the mod.
I also don't want to get in the habit of redistributing a whole whack of Mojang's artwork.
This might actually be the first time I use a texture pack if they really look as bad as you make them out to be. I suppose you can't suggest any particular pack without making it look like your favourite, can you?
Well, FC doesn't have to distribute any Mojang art. If you want the old porkchops back, just make a copy of your items.png from 1.3 and turn it into a texture pack by merging it with the 1.4 terrain and items, just like FC said. Zip that up and load it as your texture pack.
Sure, you'll have to update the file everytime Mojang adds new items or terrain texures, but texture pack artists do that every time too (and a whole lot more of it!).
PizzaSHARK wrote:It's fun trying to quietly assassinate your kids and family members
Just a brief status update before I get back to "work" :)
Yesterday, I decided to take care of an issue that has turned out to be a problem with SMP servers. It turns out that the reliable block update code for the mod is causing memory leaks and leading to instability with time on servers.
As a result, for the next release I'll be turning the option for it off by default, until I can set aside the time to really dig into Mojang's block-update code and figure out why this is happening. However, this leads to a number of other problems in that a number of mod blocks are dependent on this code to not "freeze up" when an update is dropped.
Stoked fire is a perfect example, as it "dies down" back to regular fire with time due to a series of regularly scheduled block updates. If however, one of these is dropped on chunk save/load (which frequently happens without the reliable block update code), then it will never revert back to regular fire. We've also seen problems with the Buddy Block very rarely jamming as even with the reliable block updates, it appears that the odd one was still being dropped on occasion.
Now, how I handled this in the past, before reliable block updates, was that you can flag blocks within MC to receive random updates when loaded. This is normally used for stuff like growing grass or other vegetation, but can also be used to clear these kinds of jams, because even if a block drops an update, you know it will still eventually receive a random one.
The old problem with this however is that this totally messes with reliable timing on blocks, because you can have a random update pop up when you already have one scheduled or what have you, and suddenly the block gets updated faster than you would have liked. There is also no way with vanilla code to differentiate between a random update and a scheduled one.
I mentioned a little while ago however, that I had started modifying block.class, and that it had many advantages. This happens to be one of them. What I've done now is split random updates, and scheduled updates, into two entirely separate things, so I can differentiate between them within the code. What this allows me to do is process scheduled updates as normal, and use the random ones to specifically check if the block has become "jammed", and schedule a regular one if so.
This totally avoids the problem I've described. Now jams can be cleared without messing with the regular updates a block should receive (add on mods may benefit from this as well).
So, what I'm doing at the moment is going through mod blocks and making sure that they're setup to handle this kind of thing properly, without having to depend on the reliable block update code. It shouldn't take me more than a few more hours, but I just wanted to give a head's up on this as my decision to tackle it now has obviously delayed the update slightly. However, it has turned out to be a big enough problem with SMP that I want to get it out of the way sooner rather than later.
Anbaric wrote:
Wait, does that mean what I think it does? *Crosses fingers* Might you elaborate on this statement some more? I would just ask, but I'm afraid of it sounding like a suggestion.
I have no idea what you mean. Dicking me around with ambiguous posts is sure to piss me off quicker than asking a direct question though.
I apologize profusely, and will keep that in mind.
FlowerChild wrote:All the rendering glitches for blocks and items have been fixed.
So does this mean that textures now show up properly on the blocks? Cauldrons, Crucibles, Hoppers, Axles won't have to have such an ambiguous horizontal texture to look good?
This is the problem
Show
Good Cauldron:
Bad Cauldron:
Things about me.
Show
1: I hate all updates past 1.2.5. Server lag in SP?!?
2: I've never made it to SFS.
3:
Anbaric wrote:So does this mean that textures now show up properly on the blocks? Cauldrons, Crucibles, Hoppers, Axles won't have to have such an ambiguous horizontal texture to look good?
No, that's a vanilla rendering bug, and to my knowledge, they've yet to fix it. It's also an issue specifically related to texture-packs, so it's not something I'll be addressing myself.
Might happen when they finish rewriting the rendering code for 1.5 though.
I was speaking specifically of rendering bugs associated with the port to 1.4...not things in general.
