Templates prior to 1.7.x will not work in 1.7.x due to the changes that Mojang made. However, you can update them by changing the block id numbers to the new naming scheme. The Minecraft Wiki is probably the best place to find the block ids and such.
Does anyone have a link to that old ruins compilation from around ~1.5? I wanted to take a look at the IDs, but I'm unable to find it (my new forum's search function is broken). Some of those ruins were pretty neat. It'll be a shame to lose them for 1.7 and further Ruins versions.
The Special Mobs rewrite is definitely coming for 1.6.4. After that, I'll probably be moving into 1.7 for the most part. We'll see how updating to 1.7 goes, though.
Do you have any plans for improving Lost Books? As much as I like Special Mobs, Deadly World, and Lava Monsters, I still consider Lost Books to be most unique and essential mod in your impressive mod collection.
No modder in their right mind would try to recode their mod for every version of Minecraft to-date, I don't care how simple it is. ... And your lunacy about asking for backports is hogwash, plain and simple.
I was obviously being sarcastic. The point is that there is a clear and continuous pattern with many of the users (most of them probably young, but still) on this forum, where they beg mod authors to stay from updating or keep up-to-day backports for older versions of the game, only to be first to start begging them to update as soon as they themselves switch to a newer version. Updating the client is at least 100 times faster and easier than updating the mod, so they may want to give mod authors some advance time in order to keep up with their personal needs. It's a reasonable view.
As for 1.6 staying viable for a long time, you're partly right, but the vast majority of more popular mods already have working 1.7.2+ builds, and if Tall Worlds beta will come out for 1.8 and its authors manage to make it compatible with Forge, no one will ever look at pre-1.8 versions because of the modding revolution it'll bring. That last one is a very big "IF", I know, but hey, let me dream about it a little bit
I track a lot of mods' progress myself, and although many small or older ones still haven't been updated past 1.6, there's almost no reason to care about them enough to stay away from updating, especially if you consider the quality and amount of content being developed for 1.7+ right now. Once again, the best analogy is to look at 1.4.7 and see how many users and mod authors still cling to that version and use the same arguments against updating to 1.5+ some people are trying to use with 1.7+.
(the answer: not a lot)
EDIT: Anyway, the last thing I want is to argue with you for the sake of arguing or somehow pressure someone into doing something they don't want to do. I did mentioned my desire for the mod to be updated to not-even-currently-released 1.8 (so, obviously, at the author's convenience) and some facts about 1.7's code changes and effects they had on the modding community, but as long as this discussion goes, I'd rather prefer to concentrate on something more productive than that.
=/ Sorry to burst your bubble, but even after 1.8 comes out, it could be 6 months before forge updates, and even longer before most forge mods update. Just look at how long it took for them to update to 1.7, and then how long it took to work out the major bugs, and finally then how long it took individual modders to update their code...
Sounds like you joined the modding scene after 1.6 came out. As far as I know, updating to a newer version never was nearly as time-consuming as it was with 1.7 and updating to 1.8 won't take a fraction of the time it took us to update beyond 1.7.
The 1.7 patch (which was officially called "The Update that Changed the World") was unique in the fact that the vast changes in its code broke almost every single thing imaginable and we had to wait for first (buggy and barely functional) MCP and Forge updates for at least several months. It was highly irregular. To compare, working Forge builds for versions 1.6, 1.5, and 1.4 were all released at the same day or sooner (based on pre-release code) as official Minecraft updates. That's right, not even a few days or weeks after. The same day.
Unless soon-to-be-released 1.8 suddenly decides to change everything we know about it based on the latest snapshot, it doesn't seem at all that any of the dire expectations about 1.8 are true. Considering how easy it was to update from 1.7.2 to 1.7.10 (a lot of mods didn't even have to update their code to keep working), it's very reasonable to expect a working 1.8 Forge build within a few weeks at most (and probably much sooner than that), and many mod authors being able to update their 1.7.10 mods to 1.8 without almost no effort at all. As as I said, the 1.7 update was mostly an aberration, not a pattern.
so, for now could you focus on 1.6.4 for the time being?[ ...] i'm glad you're gonna try to support 2 versions instead of just dropping support for one of them, like most modders do.
What about supporting 1.5.2? 1.4.7? 1.2.5? Even earlier versions? When does it stop? 1.8 is a vast improvement over 1.6 in several regards. It's worth (and certainly much easier for everyone) to update your server for the performance optimizations alone, let alone the fact that (considering how easy it is to update 1.7.2 mods to 1.8) in a month or two into 1.8, the 1.6 version will be all but forgotten. The same people who begged mod authors not to update will be wondering why it takes so long to get past 1.7 (possibly the most mod-devastating update in Minecraft's history) and begging mod authors to hurry it up and update to 1.8.
Sorry if I get too emotional here, but I have a long list of mods I expect to install when 1.8 comes out (my last server version was 1.5.2, so there's a lot of new stuff to experience there, no doubt). There are only few mods on that list that haven't updated or aren't in the process of updating beyond 1.7 yet, and this mod is one of them. Considering that this "small" mod is easily in the top ten of my most desirable and most immersive mods for the game—a list that includes established behemoths like Biomes O'Plenty, Mo' Creatures, Optifine, etc—I really don't want some shortsighted detractors to convince Tmtravlr to divert his precious time on maintaining a version that for all intents and purposes will become obsolete in a few months at the most.
They are still the defaults. If there are no music tracks that could apply to a certain situation, say for instance in a custom dimension, where you haven't added any music, then it will play that music instead.
If you want them to play with your custom music, you'll have to add them to the folders too. =)
Good to know, thanks for the explanation. I just hope you'll have no troubles updating to upcoming 1.8. I already spent hours on preparing music folders for the mod I don't even have installed on my 1.7.2 test version, heh-heh.
skins.2=1 2 3 4 5
weights.2=1 1 95 1 1 (to force skin #3 take priority regardless of biomes)
...as well as using most of the commands separately and in combination with several other things, and nothing worked--all 5 random textures kept spawning at their usual random 20% rate no matter the biome. Since I'm convinced my .properties file was in order, it must have been some kind of a glitch or an issue with a slightly older version of Optifine, so I hope that updating to a newer version will fix it immediately. Thanks again, I really appreciate the effort.
By the way, what happens to default music tracks (calm1.ogg, piano1.ogg, etc) when the mod is enabled? Can they override the mod's music or they are being fully ignored by the game in favor of the mod's custom playlist settings?
The random mobs per biome seem to be working with Soartex Fanver and so are blocks per biome working too. I just tested it myself with Minecraft 1.7.10 with Optifine HD U A4.
Are you sure you have Random Textures turned on in your optifine settings?
Random Textures are on and I can see random mob textures just fine, but I can't force a particular texture to spawn in a particular biome (say by forcing skin #3 to take priority in Plains with "skins.1=3 biomes.1=Plains" in .properties). Anyway, thanks for your help. It may be an issue with the U_D3 1.7.2 version of Optifine. I'll try to set up Forge for 1.7.10 and test again with the latest version.
Random Mobs
You may include multiple skins for the same mob and the game will automatically pick one at random. Add a number to the end of the filename before the .png, e.g., /mob/creeper2.png. Start at number 2 and do not skip any numbers. For the wolf textures, make sure you include the same number of wolf, wolf_tame, and wolf_angry textures or it will look strange when a wolf changes moods.
I try to create a .properties file to set up biome-specific mob textures in OptiFine_1.7.2_HD_U_D3 (say to make cow2.png only show in deserts and cow3.png only in Plains), but no matter what format I use, nothing seems to be working.
Can somebody confirm that it still can be done in Optifine for 1.7.2 and up? Other MCpatcher functions work just fine, including .properties files for blocks (as opposed to entities), but I just have no idea why I can't get mobs properties to work.
Nobody knows? It's kind of a big deal for me (I have a whole bunch of different-looking per-biome mob textures prepared already), so I'd really appreciate an answer. Not to mention that a lot of resource packs (Fairlight, Soartex, Conquest, to name a few) use the feature, so if it no longer works, their authors would probably like to hear about it as well.
Perhaps; maybe another way to do that would be to have songs that play "in sunlight", songs that play "in moonlight", songs the specifically play in darkness (when the light is below a certain level), and songs that play when in unnatural (for example torch) light.
Sounds like a very flexible approach to me, and probably not that difficult to implement, too. I actually forgot you can check for moonlight as well as sunlight, so I was thinking about altitude checks and other crazier ideas instead of keeping it simple and to the point.
I don't know how far you want to take the mod's development, but a more advanced version of the day/night (or safe/dangerous) idea is to make additional config options for considering things like sunlight and altitude instead of just time settings.
The advantage of this is that uplifting "day" music will play during sunny times on the surface, and ominous "night" music will play during bad weather (mostly rain and thunderstorms) and time spent underground (regardless of time of day, since it's usually more dangerous down there).
The slight disadvantage of this is that it won't be able to recognize safe player housings (which usually deserve more uplifting music themes than of ominous ones) and weather conditions like snowfall (also usually considered more uplifting or neutral than ominous or depressing). It doesn't seem like that big a deal though, since the snow/rain thing is fairly minor and players can always use jukeboxes to set up appropriate music for their housing. I guess the mod could also avoid it with extra config options for each weather type and some kind of a separate radius-based music block that can be used to set up a "music sphere" for player housing, but it's probably a lot of work for a small and simple mod like this.
Anyway, just a little bit of brainstorming thrown at you. I'll personally be more than happy with a simple port to 1.7+ and even with the most basic day/time implementation.
Mrdnra, most likely you just need to disable "Threaded Optimization" / "OpenGL Threading" in the video drivers' control panel to remove the flickering.
Ben, you have a lot of valid points (I especially like you taking co-op into consideration), but as long as it's not just about increased difficulty and lack of convenience. If you can make it possible to re-acquire the items needed to access/traverse some areas (there's a number of ways to do that, from re-spawning key bosses with rare items dropping from regular mobs to having bosses drop reusable crafting components needed to recreate progression items), it shouldn't be that big of a deal. In any case, thanks on taking progression this seriously. Minecraft can certainly use some of Terraria-like stuff in its design.
EDIT: Could anyone please answer my earlier question and tell me if the wiki is maintained and is fairly up-to-date?
br> Random Mobs
You may include multiple skins for the same mob and the game will automatically pick one at random. Add a number to the end of the filename before the .png, e.g., /mob/creeper2.png. Start at number 2 and do not skip any numbers. For the wolf textures, make sure you include the same number of wolf, wolf_tame, and wolf_angry textures or it will look strange when a wolf changes moods.
I try to create a .properties file to set up biome-specific mob textures in OptiFine_1.7.2_HD_U_D3 (say to make cow2.png only show in deserts and cow3.png only in Plains), but no matter what format I use, nothing seems to be working.
Can somebody confirm that it still can be done in Optifine for 1.7.2 and up? Other MCpatcher functions work just fine, including .properties files for blocks (as opposed to entities), but I just have no idea why I can't get mobs properties to work.
0
Does anyone have a link to that old ruins compilation from around ~1.5? I wanted to take a look at the IDs, but I'm unable to find it (my new forum's search function is broken). Some of those ruins were pretty neat. It'll be a shame to lose them for 1.7 and further Ruins versions.
0
Do you have any plans for improving Lost Books? As much as I like Special Mobs, Deadly World, and Lava Monsters, I still consider Lost Books to be most unique and essential mod in your impressive mod collection.
0
I was obviously being sarcastic. The point is that there is a clear and continuous pattern with many of the users (most of them probably young, but still) on this forum, where they beg mod authors to stay from updating or keep up-to-day backports for older versions of the game, only to be first to start begging them to update as soon as they themselves switch to a newer version. Updating the client is at least 100 times faster and easier than updating the mod, so they may want to give mod authors some advance time in order to keep up with their personal needs. It's a reasonable view.
As for 1.6 staying viable for a long time, you're partly right, but the vast majority of more popular mods already have working 1.7.2+ builds, and if Tall Worlds beta will come out for 1.8 and its authors manage to make it compatible with Forge, no one will ever look at pre-1.8 versions because of the modding revolution it'll bring. That last one is a very big "IF", I know, but hey, let me dream about it a little bit
I track a lot of mods' progress myself, and although many small or older ones still haven't been updated past 1.6, there's almost no reason to care about them enough to stay away from updating, especially if you consider the quality and amount of content being developed for 1.7+ right now. Once again, the best analogy is to look at 1.4.7 and see how many users and mod authors still cling to that version and use the same arguments against updating to 1.5+ some people are trying to use with 1.7+.
EDIT: Anyway, the last thing I want is to argue with you for the sake of arguing or somehow pressure someone into doing something they don't want to do. I did mentioned my desire for the mod to be updated to not-even-currently-released 1.8 (so, obviously, at the author's convenience) and some facts about 1.7's code changes and effects they had on the modding community, but as long as this discussion goes, I'd rather prefer to concentrate on something more productive than that.
0
Sounds like you joined the modding scene after 1.6 came out. As far as I know, updating to a newer version never was nearly as time-consuming as it was with 1.7 and updating to 1.8 won't take a fraction of the time it took us to update beyond 1.7.
The 1.7 patch (which was officially called "The Update that Changed the World") was unique in the fact that the vast changes in its code broke almost every single thing imaginable and we had to wait for first (buggy and barely functional) MCP and Forge updates for at least several months. It was highly irregular. To compare, working Forge builds for versions 1.6, 1.5, and 1.4 were all released at the same day or sooner (based on pre-release code) as official Minecraft updates. That's right, not even a few days or weeks after. The same day.
Unless soon-to-be-released 1.8 suddenly decides to change everything we know about it based on the latest snapshot, it doesn't seem at all that any of the dire expectations about 1.8 are true. Considering how easy it was to update from 1.7.2 to 1.7.10 (a lot of mods didn't even have to update their code to keep working), it's very reasonable to expect a working 1.8 Forge build within a few weeks at most (and probably much sooner than that), and many mod authors being able to update their 1.7.10 mods to 1.8 without almost no effort at all. As as I said, the 1.7 update was mostly an aberration, not a pattern.
0
What about supporting 1.5.2? 1.4.7? 1.2.5? Even earlier versions? When does it stop? 1.8 is a vast improvement over 1.6 in several regards. It's worth (and certainly much easier for everyone) to update your server for the performance optimizations alone, let alone the fact that (considering how easy it is to update 1.7.2 mods to 1.8) in a month or two into 1.8, the 1.6 version will be all but forgotten. The same people who begged mod authors not to update will be wondering why it takes so long to get past 1.7 (possibly the most mod-devastating update in Minecraft's history) and begging mod authors to hurry it up and update to 1.8.
Sorry if I get too emotional here, but I have a long list of mods I expect to install when 1.8 comes out (my last server version was 1.5.2, so there's a lot of new stuff to experience there, no doubt). There are only few mods on that list that haven't updated or aren't in the process of updating beyond 1.7 yet, and this mod is one of them. Considering that this "small" mod is easily in the top ten of my most desirable and most immersive mods for the game—a list that includes established behemoths like Biomes O'Plenty, Mo' Creatures, Optifine, etc—I really don't want some shortsighted detractors to convince Tmtravlr to divert his precious time on maintaining a version that for all intents and purposes will become obsolete in a few months at the most.
0
Good to know, thanks for the explanation. I just hope you'll have no troubles updating to upcoming 1.8. I already spent hours on preparing music folders for the mod I don't even have installed on my 1.7.2 test version, heh-heh.
0
skins.1=3
biomes.1=Plains
skins.2=1 2 3 4 5
weights.2=1 1 95 1 1 (to force skin #3 take priority regardless of biomes)
...as well as using most of the commands separately and in combination with several other things, and nothing worked--all 5 random textures kept spawning at their usual random 20% rate no matter the biome. Since I'm convinced my .properties file was in order, it must have been some kind of a glitch or an issue with a slightly older version of Optifine, so I hope that updating to a newer version will fix it immediately. Thanks again, I really appreciate the effort.
0
0
Random Textures are on and I can see random mob textures just fine, but I can't force a particular texture to spawn in a particular biome (say by forcing skin #3 to take priority in Plains with "skins.1=3 biomes.1=Plains" in .properties). Anyway, thanks for your help. It may be an issue with the U_D3 1.7.2 version of Optifine. I'll try to set up Forge for 1.7.10 and test again with the latest version.
0
Nobody knows? It's kind of a big deal for me (I have a whole bunch of different-looking per-biome mob textures prepared already), so I'd really appreciate an answer. Not to mention that a lot of resource packs (Fairlight, Soartex, Conquest, to name a few) use the feature, so if it no longer works, their authors would probably like to hear about it as well.
0
Sounds like a very flexible approach to me, and probably not that difficult to implement, too. I actually forgot you can check for moonlight as well as sunlight, so I was thinking about altitude checks and other crazier ideas instead of keeping it simple and to the point.
0
The advantage of this is that uplifting "day" music will play during sunny times on the surface, and ominous "night" music will play during bad weather (mostly rain and thunderstorms) and time spent underground (regardless of time of day, since it's usually more dangerous down there).
The slight disadvantage of this is that it won't be able to recognize safe player housings (which usually deserve more uplifting music themes than of ominous ones) and weather conditions like snowfall (also usually considered more uplifting or neutral than ominous or depressing). It doesn't seem like that big a deal though, since the snow/rain thing is fairly minor and players can always use jukeboxes to set up appropriate music for their housing. I guess the mod could also avoid it with extra config options for each weather type and some kind of a separate radius-based music block that can be used to set up a "music sphere" for player housing, but it's probably a lot of work for a small and simple mod like this.
Anyway, just a little bit of brainstorming thrown at you. I'll personally be more than happy with a simple port to 1.7+ and even with the most basic day/time implementation.
0
0
EDIT: Could anyone please answer my earlier question and tell me if the wiki is maintained and is fairly up-to-date?
0
I try to create a .properties file to set up biome-specific mob textures in OptiFine_1.7.2_HD_U_D3 (say to make cow2.png only show in deserts and cow3.png only in Plains), but no matter what format I use, nothing seems to be working.
Can somebody confirm that it still can be done in Optifine for 1.7.2 and up? Other MCpatcher functions work just fine, including .properties files for blocks (as opposed to entities), but I just have no idea why I can't get mobs properties to work.