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
Off the top of my head I suspect what's happening is that the power drain that occurs as pulses pass through gear boxes is sometimes shortening the length beneath the threshold required to keep the fire stoked. What I would suggest trying is shortening the number of gear boxes between where you're applying the redstone signal, and the individual bellows.
If you want to be absolutely certain if this is the source of the problem, there's also a config style setting to disable that power drain. It's in there to prevent infinite mechanical power loops, by causing them to bleed off power over time.
Let me know if that helps you out. I can take a look next time I get a chance and maybe tweak the timings to be a tad more forgiving if that's the cause.
0
Just updated the download links in the OP and release post to a small 'b' patch release with the following change:
-Removed certain animals not being able to jump under certain circumstances as it just came across as being buggy. I'll likely add this back in later once I have a chance to adapt pathing to it.
0
[**** NEW RELEASE ****]
Version 4.AFFFFFFF of Better Than Wolves is ready for download!
Download Link
This release contains the following changes:
WARNING: Your animals are about to die. Some will definitely die. They may all die. You will reach skyward with freakishly long arms and beg mercy from an uncaring and unresponsive cubic universe. If you do get a response, it will likely sound a lot like laughter. If this freaks you the heck out, please consider backing up your savegame before installing this release. Otherwise, there's nothing to worry about.
-Added Animageddon. Accept no pork based substitutes.
-Changed the glass block recipe to require 8 blocks of sand and 1 Nether Quartz in a Crucible to produce 4 blocks of glass. This was done to better balance it relative to other building options.
-Changed the math involved in determining when pathfinding has arrived at a destination slightly to provide more accurate outcomes.
-Fixed a problem where a crash could occur when pumpkins and melons grew on top of their own stem.
Fffffffffff...
-------------
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:
0
Ah! Got it! Thanks for the info man. It encouraged me to check the relevant portion of the stem code over and it looks like the stem crushed was trying to set its own data after it had already been replaced, resulting in the bug. Was totally my bad.
Will be fixed for the next release.
0
Weird. I'm unfortunately not in a position to put out a release in the short term to get a fix out to you, so removing them might be the best bet for now.
0
Looks like it's a pumpkin or melon that's causing it. I'll dig into the error in a few minutes and try to track it down, but if you have time when entering the save I'd suggest harvesting any of those in the area.
Are you using any addons? I'm rather uncertain how a block could get into that state otherwise.
EDIT: I put in an additional check to prevent that happening in the next release, but like I said above, it doesn't look like the pumpkin/melon should have gotten into that state in the first place unless there was some code outside the mod setting it that way.
2
Huh, that's really interesting. I didn't think that change to the 1m cubes would have that heavy an impact. I just streamlined the rendering pipeline slightly to eliminate a bunch of conditional checks on the most common kinds of blocks, that weren't actually relevant given their fixed dimensions.
I wouldn't expect it to have a heavy impact, but it must have been the bottleneck on your particular system. Thanks for the info man. No need for further tests, I just wanted to get a general idea of which change was likely responsible.
0
Just updated the download link in the OP with a 'e' patch release that contains the following:
-Fixed a problem with AI pathfinding that was causing mobs and animals to run in circles and generally spaz out. This was particularly noticeable when attempting to get animals to follow you with grass or seeds.
3
Interesting. What was the last version you had played before 'd'? I'm trying to get an impression for which changes it might have been that made such a difference on your system.
I reduced a lot of extra calculations in pathfinding in 'c', and that would probably be my first guess.
Regardless, glad it helped
1
Just updated the download link in the OP to a new 'd' version of the latest release that contains the following changes:
-Changed cows and sheep to be able to graze on Grass Slabs, and cows to be able to graze on Mycelium Slabs.
-Changed cows and sheep to clear any snow or ash cover resting on blocks they graze on.
-Changed grass and Mycelium to not grow from or to blocks under snow or ash cover.
-Changed rendering of most full 1m cube blocks slightly to increase performance.
-Fixed a problem where the extended arms of pistons could no longer be collided with.
-Fixed a problem where pistons, piston arms (if appropriately oriented), and blocks pushed by pistons, could no longer
support falling blocks.
---------------------------
It also contains the changes from the previous patch releases as well:
4.ABCFEFE c
-Changed (refactored) the changes the mod makes to Snowmen to simplify the related code somewhat.
-Changed some vanilla pathfinding code to provide improved performance and more accurate outcomes.
-Changed Netherwart to make sounds more appropriate for vegetation.
-Fixed a problem with Netherwart's collision volume that made it impossible to harvest.
-Fixed a vanilla AI problem that was causing mobs and animals to tend to favor wandering towards the northwest.
----------------------
4.ABCFEFE b
-Added recipes to convert Iron and Gold Ore Blocks back into chunks.
-Fixed a problem with pickaxes not being effective on Netherbrick stairs and a few other Netherbrick based blocks.
1
Yup, it's been down for the last 12 hours or so. Will let folks know when I know more.
0
Sorry about that. I can certainly post updates here as well, I just wasn't sure if there were too many people still downloading from this location, and I didn't want to keep bumping the thread with patch posts if not.
0
That's already fixed. If you redownload, you'll notice that the file is now at 4.ABCFEFEc. I don't generally post notification of these small patch releases here, but I do update the download links, and you can get more detailed info on them over at the BTW forums.
0
[**** NEW RELEASE ****]
Version 4.ABCFEFE of Better Than Wolves is ready for download!
Download Link
This release contains the following changes:
WARNING: This release substantially changes the rules of mob spawning, in ways that can result in brutal and unexpected dismemberment. Please make sure you understand the following changes thoroughly before playing in an existing world, lest you come home to a Creeper to the spleen, or to find your rustic wood mob trap's output has dropped to nothing.
-Added a new mob-spawning system that is listed as individual changes below, but as a summary of how it all works: mobs can now spawn on almost any shape of block, but are restricted by the materials they can spawn on. No mobs can spawn on wood, giant mushroom blocks, Mycelium. or Bedrock. Jungle spiders are the only mobs that can spawn on leaves (as before). In the nether, mobs may only spawn on Netherbrick or Netherrack (as before). That's it, that's all.
-Added new flammable giant mushroom blocks. This will not affect blocks already placed in your world, but since mushrooms will now potentially grow into giant flaming emblems of the apocalypse, be sure to check in on any farms you have that might be affected.
-Added Blocks of Iron and Gold Ore. These can either be created in the crafting grid with 9 ore, or through piston packing. They can be smelted in a Kiln for a full ingot, which provides both a means of smelting in bulk, and an alternate method of automating ore smelting.
-Added the ability to see where mobs can spawn in the Nether while wearing Ender Spectacles.
-Changed all mobs to be able to spawn on pretty much any kind of block. I may have missed some, but the goal here is to reach a point where if there's room for a mob to reasonably stand on a block, it can spawn there. If I forgot any, I'll correct them in the future, so please don't rely on block shape to prevent mob spawning anymore as it may change at any time.
-Changed mobs to not be able to spawn on blocks primarily made of wood (a thin surface layer like on Pistons and Turntables won't prevent spawning). The overall intent here is to make mob spawning less block type and more material dependent, both so that there's more of a progression and internal consistency to being able to build with spawn-proof blocks, and to further emphasize the unique building properties of different block types. Any flaming death that results is purely coincidental, as is any perceived glee I may seem to express at such events.
-Changed mobs to be able to spawn in 1-block high gaps if their body shape allows it. This mainly applies to the various types of spiders, but also prevents exploiting certain block shapes to create player walkable areas that mobs can't spawn in.
-Changed mobs to be able to spawn on ice. This was done to prevent frozen bodies of water from being big safe zones, especially in the early game.
-Changed mobs to be able to spawn on glass blocks to prevent glass from being a non-flammable, non-gravity-affected, non-mob-spawning, commonly-available, uber-material-of-doomy-doom-doom.
-Changed slimes to not be able to spawn on wood (like other mobs) in addition to their existing spawn restrictions, which remain unchanged from previous releases.
-Changed Ender Spectacles to accurately reflect all the changes to mob-spawning in this release. If you're uncertain if a particular block type can spawn mobs on top of it, then Ender Specs are an ideal way to find this out.
-Changed (refactored) how the burn times for various blocks work internally for the sake of simplifying the related code a bit.
-Changed (refactored) a metric dung-ton of block code, both vanilla and mod, in the process of fixing the collision thing I describe below. Please let me know if you run into any new weird block behavior, as it would be exceedingly unlikely that I didn't make a single mistake in the process. On the bright side, I made a number of small unlisted improvements as I went along as well.
-Changed a number of blocks to render fewer non-visible faces to help with performance, in the process of refactoring their code.
-Changed cows to panic if you attempt to milk one that doesn't have a full udder.
-Fixed a problem where spiders targeting something other than the player could wind up hanging around without despawning for an exceedingly long time.
-Fixed a few vanilla problems where mobs (and other entities, like items) would sometimes fall through slabs and other sub-blocks, which became more noticeable now that mobs can spawn on them. This is not related to the various visual glitches which can occur along these lines with entities bouncing between positions, but rather the entities themselves sometimes actually passing through the block. Major thanks to Alexander Gundermann (taurose) for diagnosing and thoroughly documenting several Minecraft collision bugs here: https://github.com/taurose/Unglitch, as the information he has provided has been invaluable in resolving some of these issues. This fix only covers the first issue (the race condition) he describes (as well as some secondary issues I discovered), but I'll likely be verifying and fixing a number of the problems he documents in upcoming releases. Suffice it to say there are a LOT of collision issues in 1.5.2.
-Fixed vanilla problem where mobs and animals would get stuck in blocks and sometimes suffocate on chunk load. This corresponds to item 3 (Floating Point Errors on Entity Load) in the documentation linked above. Note that when loading old saves or chunks you may still see such errors occur, as the mobs in question will have already been saved embedded within those blocks, but it won't happen again to any new or non-embedded mobs after that first load.
-Fixed vanilla AI/pathfinding problems with animals getting stuck in fence corners (or the corners of other partial blocks) and refusing to move unless pushed out. I greatly reduced such entities lingering excessively around non-corner edges as well, as they were often times trying to move through those blocks instead of pathing away from them before this fix.
-Fixed a problem where ground cover (snow and ash) resting around cobble walls would change the shape of the wall.
-Fixed an issue where Hand Cranks could no longer rest on top of Mill Stones, for I am a river to my people.
-Fixed a problem where dedicated servers would crash on startup if they were using the mod's config file.
-Fixed a problem with the Saw block playing a sawing sound when first placed, and under some other odd circumstances.
-Fixed a vanilla problem that was limiting the number of mobs that would spawn in flat areas with lots of ground cover like snow, or tall grass. This was particularly noticeable in superflat worlds where it would prevent mobs from spawning entirely, but affected general mob spawning as well.
-Fixed a problem where Iron Chisels could not be stuck as blocks into Cobblestone.
-Fixed a problem where Pickaxes could be stuck as blocks into glass.
-Fixed a problem where Jack'O'Lanterns would still drop a torch when extinguished by water, even though they are now crafted with a Candle.
-Fixed a vanilla issue where some chunks would not properly render, even though they were fully loaded on the client, resulting in lines of missing chunks in the world. Much thanks to Andrés del Campo Novales for providing a very simple solution to this problem here: https://bugs.mojang.com/browse/MC-129 . Please let me know if you see any new chunk or visual oddities as I suspect there might be a bit more work to be done here. I've seen what felt to be a few weird things here and there, but overall this feels like too big an improvement to do without.
-Removed the config files options for limiting slime and nether mob spawning. Given the extent to which mob spawning has now changed, configuring individual aspects of its behavior is no longer feasible, and I do not believe these options were used much anyways.
-Removed all the high-efficiency crafting recipes involving stone sub-blocks, as they were rendered obsolete by the inclusion of Stone Bricks in the last release.
Happy Holidays Everyone!
-------------
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:
0
Full install instructions are linked within the readme:
http://www.sargunster.com/btwforum/viewtopic.php?f=9&t=9272