Thanks for the invite man. I'm not sure where to respond to it, but assuming that here is ok, I'll be there
- FlowerChild
- Registered Member
-
Member for 13 years, 2 months, and 3 days
Last active Wed, Jun, 16 2021 20:45:17
- 10 Followers
- 7,791 Total Posts
- 3593 Thanks
-
Jun 29, 2012FlowerChild posted a message on Minecraft API Discussion - Sat, 20:00 CEST, #minecraftdev on EsperPosted in: News
Thanks for the invite man. I'm not sure where to respond to it, but assuming that here is ok, I'll be there -
Jun 26, 2012FlowerChild posted a message on Minecraft API Discussion - Sat, 20:00 CEST, #minecraftdev on EsperPosted in: News
-Adding custom animated textures. -
Jun 26, 2012FlowerChild posted a message on Minecraft API Discussion - Sat, 20:00 CEST, #minecraftdev on EsperPosted in: News
I don't have any particular issue with it. However, the practicality and feasibility of doing something like that is up to Mojang and the original authors of those APIs.
It's really not as simple as dropping the code into MC. Given that the source for MC is obfuscated, they aren't even really working on the same code-base. Given that, and given that they would most certainly want to review each and every change, it's likely Mojang would have to effectively rewrite them from scratch anyways. -
Jun 26, 2012FlowerChild posted a message on Minecraft API Discussion - Sat, 20:00 CEST, #minecraftdev on EsperPosted in: NewsQuote from roemba
I understand what you mean with that and sure, I'm really excited for the mod API. I'm just afraid for some 'half-mods': mods who are partially API and miss a lot of features from the original. I understand that the mod API can't be everything at once but we will not quickly see some big mods make it to 'plugins' as they are just too complicated. Taking the base of modloader and forge then makes this whole process a lot easier and smoother. I think that would help a lot
I think many of the really extensive mods will *never* be plug-ins man. I already accepted weeks ago that BTW likely never would be given the number of base-class changes I make, but that doesn't make an API any less valuable, nor does it prevent such mods from being compatible with plug-ins.
Mojang seems to understand this, as it's already been publicly stated that they view mods in MC separating into two distinct categories in the future: mods and plug-ins. To think that the most extensive mods out there would fit into the plug-in category just isn't realistic IMO.
Quote from lindyhopfan
Maybe one way we can present a view of what modders should be invited is to notice that the ModList spreadsheet here Link Removed tracks top mods by popularity. This way we can present the following top 15 mods and their developers without regard for which mods are our personal favorites:
Going off number of MCF forum posts to indicate popularity is flawed in itself, as a number of the mods mentioned have their own forums separate from that, which will inevitably reduce MCF traffic in the related threads.
I don't think there's currently a good method of objectively determining mod popularity, and if Mojang makes a subjective decision about that it's bound to result in hurt feelings and a lot of chaos as additional modders try to get in on that. I sincerely doubt the modding community needs a big cock-fight to erupt over whose mod is more popular than whose when Mojang is trying to organize communication between everyone.
Honestly, I think restricting it to API devs is probably the right move at this stage. -
Jun 26, 2012FlowerChild posted a message on Minecraft API Discussion - Sat, 20:00 CEST, #minecraftdev on EsperPosted in: NewsQuote from roemba
Considering the mod API we may also not forget (which I then will suspect to happen) that when the API doesn't cover all of minecraft's game mechanics or at least most of the areas current mods use, developers will start modding the game by themselves again so then the modding API doesn't make that much of a difference.
Sure it does man. Compatibility isn't an all or nothing affair, nor do you need to eliminate *all* base class mods to ensure compatibility with others. For example, even when I was with the Forge, I was still making base-class changes, and slowly migrating them into the API as needed, and when it was common enough functionality that it seemed it would benefit modders in general. Still, BTW remained compatible with the other Forge mods at the time.
The really important part is the common functionality that virtually all mods require and which basically forces each of us to modify the same base class files to get the job done. Stuff like extended texture indexes and blockIDs, and then extending into more obscure functionality. Already, if Mojang would take care of those aspects, it would make a huge difference to the modding scene, and that doesn't even require a full-fledged API.
Less used functionality can definitely wait and has very little impact on mod compatibility. For example, who gives a damn if I'm modifying EntityCow? I don't think there are too many cow mods out there that it would cause problems with.
So yeah...don't write off the benefit of an official API just because it can't feasibly do absolutely everything out of the gate. -
Jun 26, 2012FlowerChild posted a message on Minecraft API Discussion - Sat, 20:00 CEST, #minecraftdev on EsperPosted in: News
<shrug> I can understand them wanting to restrict this to API developers as it can be assumed that most modder API requests have already filtered through them.
I suspect I'll just wait for the logs and see what happens. If they arrange one of these to talk to the authors of the big mods at some point, I might join in then. -
Mar 30, 2012FlowerChild posted a message on 1.2.5 Snapshot News - Modders Can Prepare NowPosted in: NewsQuote from flanigomik
well now that i said that i cant duplicate it anymore in vanilla but here is a report without you mod (for reference) note: i can play for hours at a time but when it hapens it keeps happening
Wordlgen isn't my specialty by a long shot, but it looks like it might have something to do with overlapping aspects like abandoned mine-shafts and a stronghold or something similar.
Hopefully this is the big bug that 1.2.5 is intended to address, but it does look like you have a number of mods installed that affect worldgen there, so it's a bit ambiguous if this is a mod or a vanilla issue.
Quote from King Korihor
The bug is self-inflicted as there is a built-in exception deliberately thrown in the official Mojang code in Minecraft when under some circumstances a block is "generated" multiple times. In other words you grow a tree and then have that tree get taken out by mountain building code (or something similar). When the exception is thrown, Minecraft simply shuts down and the exception isn't being handled inside the software.
Gotcha. Strange I hadn't heard a thing about this from any of my players.
Ignore what I said above then. It looks like this is a known issue -
Mar 29, 2012FlowerChild posted a message on 1.2.5 Snapshot News - Modders Can Prepare NowPosted in: NewsQuote from flanigomik
i actually am using your mod it is one of my favorites but there is a MAJOR crash bug in both vanilla and your mod within 1.2.4 tera gen something about terrain already being decorated
Ah, sorry, wrong one. Thought you were talking about the blocks at height-limit world-conversion bug that wound up getting fixed in 1.2.4.
This is a new one I don't have any information on. Must be rather infrequent as this is actually the first time I've heard about it. -
Mar 29, 2012FlowerChild posted a message on 1.2.5 Snapshot News - Modders Can Prepare NowPosted in: NewsQuote from flanigomik
my favorite world is unplayable because of a bug in the generation sub-routen
and all you moders you want them to slow down??
Yes, because slowing down tends to imply *testing* code before releasing it to the general public and not releasing it with world-destroying bugs. The releases we're still getting now are mainly bug-fixes for a release that occurred about a month ago.
Too bad you weren't using BTW btw. I fixed that vanilla world-conversion bug in the first release of the mod for 1.2.3. -
Mar 29, 2012FlowerChild posted a message on 1.2.5 Snapshot News - Modders Can Prepare NowPosted in: NewsQuote from King Korihor
Jeb did explicitly say that the purpose of this snapshot was for the MCP guys to be able to prepare their tools for the 1.2.5 update. Perhaps it is reading between the lines, but if new classes and methods are going to be introduced into the formal release that isn't in this snapshot, what would be the point of even mentioning MCP and Bukkit? THAT is where the "headline" came from.
You're really stretching it man. I think the headline is very clear, and Jeb's statement (which I had also seen) was very clear.
The two statements give completely different impressions. The headline says that this somehow allows all modders to prepare now for the 1.2.5 update. Jeb's post says that it will help MCP and Bukkit prepare. They are not the same thing by any stretch. -
Mar 29, 2012FlowerChild posted a message on 1.2.5 Snapshot News - Modders Can Prepare NowPosted in: News
Quote from King Korihor
It isn't that it will make updating mods faster, but rather that mod developers will have the tools available to update their mods when the vast majority of Minecraft players finally see the "Do you want to update?" screens on their game.
To my knowledge, Jeb has said NOTHING about this pre-release having anything to do with "Modders Can Prepare Now".
THAT is what I'm objecting to and why I have no idea where the headline for this news item came from. That headline seems to be pure fiction created by whomever wrote it.
I'm not complaining about what Jeb is doing with the pre-release. I'm complaining about a baseless headline that has the potential for promoting update-trolling by misrepresenting the actual situation. -
Mar 29, 2012FlowerChild posted a message on 1.2.5 Snapshot News - Modders Can Prepare NowPosted in: NewsQuote from CovertJaguar
People like you are very reason this should never have been posted. This snapshot wont make updating faster. It will just make more people complain that we update too slow.
Glad I'm not the only modder that reacted this way. I definitely had a 'wtf?' moment when I saw this headline. -
Mar 29, 2012FlowerChild posted a message on 1.2.5 Snapshot News - Modders Can Prepare NowAre you guys trying to promote update trolling with this headline?Posted in: News
Seriously, where did you get this idea that the 1.2.5 pre-release somehow helps modders prepare for the eventual release? I think I'm a fairly well known modder, and I can think of no way in which this allows me to prepare beyond adjusting my schedule to accommodate wasting several hours on the update once it's officially out.
It's a rather irresponsible statement IMO which I think will inevitably just raise community expectations that mods will somehow magically and instantly update to 1.2.5 once it's out, and up the already epic level of update-trolling that we modders are normally subjected to with each vanilla release.
I can hear it already: "Why isn't Better Than Wolves updated to 1.2.5 yet! You were given time to prepare!"
Thanks MCF. - To post a comment, please login.
0
0
Yeah, there was a little too much "AAAAHHHH!!!!" in the rain sound, that was much more appropriate for a storm
0
Frequency of rain has remained the same. The sound of storms is now what the sound of rain used to be, and the sound of rain is greatly reduced. Storms only occur a portion of the time when it's raining.
You do the math
5
Version 4.89999999 of Better Than Wolves is ready for download!
Download Link
This release contains the following changes:
-Added sound for when Gear Boxes are being overpowered by a Wind Mill in a storm to serve as a warning that damage will occur.
-Added ability to inject something directly into something from something else. If you found the various features in the temples already, you'll know what I'm talking about
-Added a small grace period when the player switches dimensions in which ghasts and the enderdragon will not attack unless attacked first. This is to prevent problems with popping into a dimension and immediately getting wiped out due purely to bad luck.
-Changed Wind Mills to only spin out of control in storms, rather than just in rain or snow. This decreases the downtime you'll experience with them overall, but also means you'll have to keep a closer eye on the weather to make sure there isn't any resulting breakage.
-Changed (increased) the frequency of lightning bolts in storms to make the storm condition more evident and menacing overall.
-Changed snow and rain to look and sound less intense when there isn't a storm going to make the storm state more distinct, and to reduce the annoyance associated with the sound of rain.
-Changed HC Spawning so that if time is advanced to the next day on respawn, any storms will also stop to prevent the player having mobs spawn around them. Similar to time advancing to the next day, this only affects single player.
-Changed (increased) the chance of storms occurring to make them a more significant threat.
-Changed the way storms work, so that a storm will only start after it's been raining/snowing for awhile to give the player a chance to react to changing weather conditions. Basically, a storm won't just kick in out of nowhere from a clear sky anymore, but if it starts to rain/snow, you may want to prepare for a potential storm.
-Changed the order in which the Mill Stone processes items so that there's somewhat of a softest to hardest material order to it. In other words, cocoa beans will grind before netherrack, and that kind of thing.
-Changed (reduced) the amount of hunger that melon slices restore slightly for balance.
-Fixed vanilla problem with it not getting visibly darker during storms, despite the fact that the game logic for monster spawns and such still treated it as such (it was basically an issue of the storm state not being communicated from the server to the client). This should make storms much more evident when they occur.
-Fixed vanilla problem that was causing a delay in the transmission of changes in rain between server and client.
-Fixed item duplication bug with the Block Dispenser when failing to place clay balls.
-Fixed problem with Gear Boxes not breaking when overpowered in some circumstances.
-Fixed problem with the magic letters that flow between bookshelves and the Infernal Enchanter appearing in the opposite directions from where they were supposed to.
-Fixed a problem with how the Hopper was outputting XP orbs that was sometimes causing them to appear in the wrong locations.
Enjoy!
-------------
If you'd like to say thanks for this release and help contribute to the further development of Better Than Wolves, please consider making a donation:
2
0
Ah. Fair enough. I'll take a look.
0
It's not ideal, I agree, but that's the way it's always worked, and really makes very little difference in practice.
I might do a pass at some point though to at least ensure that there's some vague semblance of "softer items first", kinda like what I've done with the Crucible melting stuff like gold first.
0
Indeed: the end is nigh!
1
No, and no it doesn't.
That's a fair point. I should probably stop any storms that are going when that happens. Mobs can't spawn in regular rain.
1
No no. I may have put that the wrong way. I just made additional refinements to the existing weather states to make them more visually distinct. No changes to gameplay really, it's just that given the importance of storms in BTW in terms of the world getting a lot more dangerous, I thought it important that players be able to quickly recognize them, beyond just the vanilla sky darkening thing (which wasn't working anyways).
7
BTW man, just wanted to thank you again for this. I put in some work on it this afternoon and given how easy it was to correct the vanilla bug instead of writing something from scratch (the storm code was still in there, it was just a simple matter of communicating the state from server to client at appropriate times, which is why it wasn't working), I had some time left over to refine storm behavior further to make it more polished overall.
So yeah man, I'm quite pleased with the results, and basically we all get a bit of bonus content thanks to you pointing this out
3
Now with added risky behavior
0
Oh wow man, thanks for that! I hadn't even noticed when it was lost, and that should make correcting it substantially easier.
0
Hehe...thanks man
We discuss something related to that a bit later in the recording (might be the next episode, but not certain) where I get into the whole "Luke Skywalker vs the Death Star" analogy and talk about some of my early gaming experiences with Red Baron. That game did a great job of making you feel like an initially insignificant part of a larger world, and that both continues to act as an inspiration for me now, and has become a big part of my overall design ideology.
0
How is that odd? Fishing is a time consuming and rather last resort kind of activity and we still had plenty of animals around to hunt. That iron also isn't going anywhere, so it's sitting there handy for us in our base when we decide to start smelting.
To me, it would seem odd to spend any of that iron on fishing rods when there are plenty of other options available at present, and when we could be saving it for our first pick.