Tsuarok

Yes man do that, any translation would be appreciated.

I'll look into it, but I won't be able to do it for about two weeks; I'm going on vacation to the US on Friday.

Honestly, if possible, I'd like to see us getting away from UIs.  Have the glory hole (or forge or whatever) be something that you hold right click in front of to heat the glass.  You could shift-right click with the blowpipe to add some air in, or right click to spin it.  Do either too many times and the product would be ruined (though you should be able to remelt it and try again).

Well that sounds amazing.  Honestly, I was pretty much just joking; I don't think I'd have the time to introduce myself to java and go on to code something so complex within the lifespan of minecraft.

About M3L, I don't think he really wanted to make it at first.  I guess he felt that the forge team was somewhat hostile to his requests, and he wanted to do something that was completely open source and disallowed core mods as a way to ensure cross-mod compatibility.  Something about being able to create your own hooks instead of modifying base classes.  Whatever that means.  

Received with much appreciation. Tsuarok given that there is a need for this conversion of sort by other TFC-ers and those who are less technically savvy, is it possible for you to create a youtube video tutorial for the TFC community clearly showcasing the steps in order for us to better grasp a better understanding as to how one would precisely go about executing the stated directives?  

Unfortunately, my computer curls up into a little ball and cries for it's mommy when I try to record while minecraft is running.  I could do a forum post with some pictures or something... though since MCEdit won't work with 1.8, and it looks like Codewarrior (the guy who made MCEdit) is MIA since 2013 or so, I'm not sure if it's going to be worth it.

May I also point out one thing, the seed you are wanting is in 1.7, with the current build (Build 78) is for minecraft version 1.6.4...

As long as it's not 1.8 (MCEdit doesn't work with 1.8), it shouldn't matter.  He'll be replacing any vanilla blocks anyway.  The MCEdit route basically just copies the shape of the terrain into TFC.

If compatibility with other mod would've lied on TFC developers, I wouldn't write that post implying responsibility on LW devs. However, that's not the case.

You are terribly wrong by trying to generalize my opinion based on a single instance where I'm right to have the exact one I stated.

 

It's not TFC devs responsibility to gut the LW mod and make its cloud height adjustable. Nor is't their responsibility to add config options for LW mod to make it recognize other mods' blocks.

 

Compatibility with other mods is more tricky thing and would have to have its own thread, tbh. And even though I'm no TFC dev, I'm pretty sure I can easily explain why the < modname> is incompatible on case-by-case basis, and what steps should be taken to ensure compatibility.

Yeah, like I'd said in the previous post, you are right.  I wasn't really generalizing your opinion honestly; I've heard that opinion from many people, and in many cases (though not this one) it's not appropriate.  Just frustrated at hearing yet again that compatibility is someone else's responsibility.  I'm afraid I accidentally derailed the thread.

This topic has been derailed by Tsuarok and I considering the compatibility issues starting in post #8 are no longer related to the localized weather mod. Its unfortunate that Tsuarok and I chose to derail this topic with mod compatibility issues unrelated to the localized weather mod considering mod compatibility with the Localized weather mod should be on the LW devs and not the TFC devs.

 

Most of the time mod incompatibility is due dimensional/health/damage/blockresistance incompatibility caused by the TFC devs for no good reason. Thats the problem irritating Tsuarok and I. Neither Tsuarok or I should have derailed this topic, and I apologize for my part in the derailment. Its a serious problem that needs to be addressed, but its off topic here

My bad.

On topic:  It looks like a really cool mod, and probably playable if the height were adjustable.  Despite what I'd said earlier, I have to agree that there's little TFC should do in this regard.  Either a compatibility addon or an adjustable height from the mod author would be needed.  It should remain a separate mod, but I'd definitely check it out.

It might be cool to have TFC add some code that changed the way some plants behave based on the weather if the mod is installed.

Sounds like I'll have a lot of work to do

Normally I would agree with your statements here that it shouldn't be the mod authors responsibility to make thier mod compatible with total conversions that are incompatible with most mods, but in this case transcengopher/Kitty are right

 

Its not unreasonable for the LW mod to be compatible with any mod that modifies the terrain height. Its not just TFC that does this. And making a pull request (or feature request if they don't have a github) to include TFC grass in the storm code is not unreasonable. People make similar requests for modded metals/stone/wood all the time.

Yeah, I was mostly just speaking in general.  Nearly every time I suggest changes to compatibility I get the response that it's the other mod author's responsibility to use TFC's API, even for fairly basic things.  This attitude would be fine if compatibility were not a stated goal of the mod, but it is.  

For most mod authors, compatibility with TFC is not exactly high on their list.  If we want other mods to work with TFC, it's on us to make it happen.

So... this may be old news for some of you, but Cuchaz is building the Tall Worlds Mod, a cubic chunks mod which will raise the height cap from 256 to 16,000,000, setting the sea level at y=0 and going up and down by 8,000km.  

Obviously in order to use this in TFC, terrain generation would need to be modified rather heavily, but I think that it would be pretty much amazing to have this option in TFC.

The mod isn't done yet, and will be released for 1.8, so we'll not see it here for a while, but this has me so excited I might just have to teach myself to code so that I can integrate this into TFC.

Ocean trenches, actual mountains!  I think this would be amazing!

There's no integration required, and, frankly, compatibility addon is required not from TFC, really, but from Weather2 developers. About the only thing TFC can do in this scenario is provide some information on current temperature and moisture - things that weather mods seems to have hardcoded in (I didn't research so I might be wrong on that one), but even then it's mostly a common-API- and/or reflective-callable-type thing, and a bulk of work should still be done from the weather mod side of thing.

 

Another thing I would very like you guys to understand:

The beauty of a system we currently have with Minecraft modding is in its modular nature. YOU decide what will build your Minecraft playtime experience, not some other guy who thinks he knows better than you what kind of stuff you'll like - the part that made me not like Flower Child as a designer, but that's beyond the point. By suggesting TFC devs to incorporate this and this and that too you not only demand them doing way more work than is required to have "this and this and that too" in your game of Minecraft (which is the main reason for them not doing these sorts of thing, if you look from their perspective), but also denying the very best thing Minecraft modding has going for it.

 

Also, is it just me, or weather effects look too detailed for Minecraft?

Placing all responsibility with other mod makers is very limiting; why should other mods strive for TFC compatibility when most of the player base uses vanilla?  If TFC truly wants to be compatible with other mods, effort needs to be made on our end to utilize APIs (when availible), request required hooks from the mod authors, etc.  If not, stating that a goal of TFC is compatibility but placing all responsibility on others is disingenuous.

Obviously other mods shouldn't be required for TFC, but effort should be made to make them run out of the box.  If not, compatibility is simply not going to happen.

I haven't been on the forums much lately, so it missed your PM; sorry.  

Since you've started a topic on it, I'll just reply here.

You could use either world painter or MCEdit to achieve this, but I'd suggest the latter.

Basically, open the seed world in MCEdit, and copy all the terrain you want to use.  Hopefully you'll have the required RAM.

Next, create a new TFC world and look for a suitable spot to put your new terrain.  It should have a similar distribution of plants to the terrain from the seed.

Open this area in MCEdit, and paste in your new terrain.

From here you can do one of two things.  The easiest method would be to choose a rock type for the whole terrain and change out the sand, dirt, stone, and ores for TFC sand and dirt, and TFC stone (eliminating the ores).  Plants will likely need to be eliminated.

Select the area and tell MCEdit to have minecraft populate the terrain.  This will get you your ores, plants, etc.  Note, the rocks you get will be from the original stone layer, not the new stone.

If you want to be a bit more seamless, you can match the materials to the underlying terrain, though this will take a really long time. 

Just to chime in, I love the detailed models.  They're awesome.

Thats the plan Rainfall on earth is determined by air currents, ocean currents and terrain. Air currents and ocean currents generally follow an equation based on latitude to determine direction, with ocean currents being redirected by continents. For TFC, this means that chunks will have to trace back along the wind current that would pass over them to see where it came from. When that trace finds the ocean, we can determine how much moisture the air current takes on and how the temperature will be affected. This tells us how much it might rain in the original chunk. The advantage of this method is that we only need to check the biome ane coordinates of other chunks, making it fast and accurate

But... wouldn't this require all the relevant chucks to be generated?  I mean, you could end up with a situation where tons of trees are generating and then suddenly a whole new continent exists that completely changes rainfall patterns, making the area a desert.  Or could you maybe pregenerate a height map of ungenerated chunks allowing you to simply check if something is there?  Oh, that would be really useful for improved river and lake generation too... no idea if it's possible though.

oh, you're just using that bukkit plugin that teleports you? Unless there's been a pretty major update, that's a pretty brutal approach to world wrapping, and not really what I (or, well, anyone) has in mind when you talk about wrapping the world. How cruel would it be to have all that phantom terrain off behind the teleport boundary, taunting you with trees, crops, and minerals, only to teleport you away when you try to approach them? XD

 

Could you not just copy the terrain from one side to the other?  Maybe have it update on server reset.

This is a mod for Minecraft. The terrain is never going to be in more gradual slopes than single block steps.

Well, I guess I won't make that post asking for No Cubes compatibility...

in previous threads I've stated that if carts make it into TFC, they will only be useful on roads with chiseled slopes. Wheels have trouble with cliffs, soils and grasses. There's a reason rome built stone roads all over their empire- it's because horse carts and chariots have a heck of a time trudging through mud and sand.

Stairs seem like a reasonable compromise.  Either that or make a ramp modal and ramp chisel mode.  The modal would be to eliminate the extreme lag generated by freely-chiseled entities. 

That said, people successfully dragged wagons across the US prairies without roads, albeit somewhat slowly.  I'd suggest a compromise, drastically reducing speed over non-flat surfaces.  After all, these Romans build the roads to increase the speed of travel, not because it was otherwise impossible.

Dunk thought it was broken, but it's not the case. I have forges under working blast furnaces in a couple spots in my test world because metal sheets don't block the chimney.

 Awesome, ty Kitty

One of the things I do is to set a forge under the crucible under the blast furnace.

So if for any reason I have to leave the server. I can heat up the metal again.

I used to do this in B77, but I thought they removed the ability, something about forge sky access... could be wrong though.

I successfully use it.  If you have any problems, you can PM me for information on which mods I have under which tabs.  I have a whole slew of different mods for different servers.

idk, a sawmill would be unnecessary in late game.  By then you usually have all the wood you need.  If they put it in, it should be a fairly early structure.

The sled would necessarily eliminate the AI though... the player would be in control, riding on the sled.

Cool and fun idea.  Also, horse-drawn sleighs were common during the winter, allowing rapid travel without needing roads.

As other's have mentioned, it seems to me like it would fit in best with an inventory/transportation infrastructure update.  Something like:

Dogs and horses can rapidly pull sleighs on snow and ice, including going over 1 high blocks.

Horses can slowly pull wagons over one high blocks, and rapidly pull over level ground and maybe stairs(roads incentive)

Each dog/horse attached to the wagon/sleigh increases the speed, up to, say 6 dogs or 4 horses (but horses would be somewhat faster).

Inventory stuff to make this worthwhile.

cNPCs only allows the creation of crafting table recipes (well, and their own crafting bench recipes, which is really just a 4x4 crafting table), though both the input and output items can come from any mod. 

As it often does when posting in these forums, my ignorance of more than the utter basics of programming is shining through.  I'd sort of assumed that adding a TFC recipe would be a similar single line of code that would be simple to automatically generate if given inputs and outputs.  Obviously this is not the case.  Thanks for taking the time to explain it.

This is exactly the mindset that we are trying to AVOID. Too many people lump TFC and Better Than Wolves together and assume that everything should be added to TFC, and that no other mods should ever be required. This is a horribly unrealistic expectation to have on our developers, and is honestly quite selfish. Compatibility will always be a priority going forward, even if it means that some features won't be added.

 

 

1. Bioxx is already considering this. The main issue is that while damage and health can use floating-point values, all of the mods currently out there that actually do some sort of visual representation of health use integers. For example, the damage indicators mod.

 

2. This is something that can really only be implemented through the use of an API. It is something that would have to be added via addon mods, and not something that can be simply done with just config files like CustomNPC's and Minetweaker currently does.

 

3. Valid point, but extremely low on the priority list.

 

4. Once again this would have to be done through some sort of connection with the API. This is one factor where compatibility is a two-way street. The other mods that wish to be compatible with TFC will have to also edit their mods to use our API in their biomes.

 

5. Another two-way street. By working with other mod authors, they can add compatibility to their mods so that if TFC is installed, they generate using TFC dirt/grass instead of the vanilla blocks.

 

6. These structures don't rely on vanilla blocks to generate as far as I know, they simply pick a spot and appear at the first area on the surface that is large enough. Nothing more really has to be done for this compatibility.

It's too bad that most of these will require third party programmers.  As long as they are required to make this work, compatibility will be very slow moving.  I suppose the devs could go ahead and make crossover compatibility for each and every mod individually, but that would be a huge amount of work.

For #2, why could it not be done within TFC alone.  The system Custom NPCs uses isn't a config option, it's a UI interface in game that looks like a crafting grid with an output slot.  You put the ingredients into the grid, put the desired output item into the output slot, and it just saves the recipe for that world.  Since the input and output items are chosen in game, all items from all installed mods are present, so there's no need to mess with item ids or anything.  It seems to me a simple and elegant solution for TFC recipe integration.  Say, an anvil interface were you put in the input and output, click out the rules, and it saves the recipe.  Leather and pottery would be even easier (though I'm not sure I can actually think of any mods in which TFC pottery would be an appropriate crafting medium).  Finally, alloys would simply have the same input and output slots, and some sort of field to set ratio ranges.  I'm not sure why any of this would be impossible, or even very difficult, to implement.

 

That's a good comeback. I see your point of view and agree that the more content the best. But I want the content in the game to follow a linear progression so when playing The only non TFC mods I add are Minimaps and SmartMoving. But I digress my problem with the compatibility is not a question of purism. I have heard a few times in this forum that this or that feature would not be changed to keep compatibility. 

I do not want the DEV's to be as stubborn as some mod creators that boast that their mod is inconpatible with everything. I just wish for then not to be over-concern if is going to be compatible or not.  If the choice is between adding a feature or compatibility add the feature.

 

I totally agree.  I'd like them to make no compromises, but afterwards, go back and say, "How can we make other mods compatible with this."  Note that that is not, "How can we make this compatible with other mods?".  I hope that all of my suggestions, rather than weakening the superior systems put in place by the TFC team, simply allow one to build on these systems.  My hope is that the second suggestion would allow people to tailor the progression in a balanced and fun way.  

The main reason that I'm not sure what to do about biomes, because compromising there is simply not the option I wish to be taken.

I'm basically trying to suggest how to keep TFC more or less untouched while adding the option for using other mods.

I don't really understand the need for compatibility with other mods. Pretty much any mod that is not an addon will break the gameplay intended for TFC.

Most mods will add creatures or npcs, machines or dimensions. No matter what it will ruin the TFC experience.

Careful integration via #2 on my list should be able to address any balance issues.  

This mod has vastly improved crafting and collection with it's systems, but no matter how much content the devs add, more can be had with more mods.  Allowing us to integrate other mod's items using these superior systems can greatly expand what can be done in the game while maintaining balanced gameplay.

Ah, good point about the strongholds; some crafting recipes would do just fine.

Although, I'm now thinking that I need one more item on the list: structure generation.  Many mods use structures to contain more challenging content that would be too tough for starting players.

I fear you're right about the biomes, I just don't see how vanilla-style biomes could fit in.  I too hope that I'm wrong.