Content: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Background: Slate Blackcurrant Watermelon Strawberry Orange Banana Apple Emerald Chocolate Marble
Pattern: Blank Waves Notes Sharp Wood Rockface Leather Honey Vertical Triangles
Welcome to TerraFirmaCraft Forums

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

  • Announcements

    • Dries007

      ATTENTION Forum Database Breach   03/04/2019

      There has been a breach of our database. Please make sure you change your password (use a password manager, like Lastpass).
      If you used this password anywhere else, change that too! The passwords themselves are stored hashed, but may old accounts still had old, insecure (by today's standards) hashes from back when they where created. This means they can be "cracked" more easily. Other leaked information includes: email, IP, account name.
      I'm trying my best to find out more and keep everyone up to date. Discord (http://invite.gg/TerraFirmaCraft) is the best option for up to date news and questions. I'm sorry for this, but the damage has been done. All I can do is try to make sure it doesn't happen again.
    • Claycorp

      This forum is now READ ONLY!   01/20/2020

      As of this post and forever into the future this forum has been put into READ ONLY MODE. There will be no new posts! A replacement is coming SoonTM . If you wish to stay up-to-date on whats going on or post your content. Please use the Discord or Sub-Reddit until the new forums are running.

      Any questions or comments can be directed to Claycorp on either platform.
Tsuarok

Compatibility Checklist

12 posts in this topic

So, I understand that a current development goal in TFC is compatibility with other mods.  I think that one of the few things that Mojang did right in it's implementation of survival was allowing mods.  IMO, survival as it should be should include as much compatibility as possible (without making gameplay sacrifices).  That said, I'd like to make a list of things that devs can look at for increasing compatibility with other mods.  Please feel free to add any ideas you may have on this subject.

 

1. Return HP and damage to vanilla-reasonable levels.

          Many mods add in new mobs, and in every case, they simply don't stand a chance.  Since damage can use floating-point values, this should have no other effect on gameplay.  We should be able to keep the improved HP UI, and even display damage at current levels if desired.

 

2. Include a system to allow server administrators (and individuals in SP) to easily add in new alloy, leather, pottery, and anvil recipes.

          Progression in TFC is rather different than in vanilla, and it's awesome.  To truly integrate mods that add tons of new abilities and items, these need to be carefully added in at the correct tier for reasons of balance.  I'd recommend some system like Custom NPCs has for it's custom recipes, but a config file could be used as well, if it's easier.

 

3. Stabilize the other dimensions, and add the option for end frames/obsidian generation or crafting.

          Some mods use stuff from these places.  While I have no desire to see them standardly available in TFC, there needs to be the option to enable them, and they need to function smoothly.

 

4.  Biomes

          This is a really tough problem, since TFC changes terrain generation so much.  In reality, while I feel that it's very important to allow mods that include custom biomes, I have no good ideas on actual implementation in the TFC system.  Please post suggestions.

 

5.  Dirt that is dirt

          Mod trees and other plants do not grow on TFC dirt.  I'm not sure that this could be done, because there are not enough metadata slots to simply expand the dirt block, and limiting the number of dirt types for the sake of compatibility is not, imo, an option.  But some way to convert trees, perhaps some type of whitelist in the config files, may be sufficient.

 

6.  Structures

         Many mods add challenges in the form of structures, allowing partitioning of content based on challenge level.  This is pretty fantastic, since it gives you something to work toward.  Some way to add these into terrain generation would be good.

 

7.  Villages

          Similar to the previous point, a great many mods expand on villages and their inhabitants.  Like the other dimensions, these have no place in "vanilla TFC," but should be available if needed for other mod's content.

 

I know that compatibility, while a development goal, is often trumped in terms of priority by other features.  And that is okay.  I'd rather have ya'll make the best mod you can, and then figure out how to make it work with other stuff.  That said, it never hurts to keep compatibility in mind, because other mods can add so much to the TFC experience, and sometimes taking that extra step of asking yourself how this new system will interact with other mods can be quite worthwhile.

 

Again, please feel free to add any ideas you may have to improve compatibility.

2

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

The current end goal of TFC is to make steel.

 

Now if you are playing in a competitive server against other players, this works as you can compete to get better equipment before they do

 

If there is no PvP involved there is really is no point to the end goal of TFC. Ok you get red/blue steel, which gives you magical buckets. Yep thats pretty much it

 

There are no areas of TFC that you need > copper tools for. There are no non-player enemies in which you need even wrought iron equipment to defeat. The best parts of the game are "I made my first pickaxe" and "I have steel". The first opens the world of mining. You really only get to the second one for non PvP reasons because it is fun to get there

 

TFC is the WIP cool world generation mod and the best early game tech tree mod out there

 

The devs have mentioned possible end game content. They may get around to that at some time in the future. They may not. That is up to them. If they aren't going to, then having other mods provide end game content is really the only option. Otherwise they created a mod where the end goal is raw materials in which you really can't do much other than make rail networks.

 

 

----------------------------------------------

RE: Tsuarok

 

Point 3: Strongholds aren't actually neccesary (although that is one way to do it). As long as there are ender frames and ender pearls, people can get to the end. Ender frames could be made craftable (presumedly including materials found in the nether)

 

Point 4: Any overworld biome mod will require compatibility patches to modify the mod biomes. Unless someone has a brilliant idea that can prove this statement wrong

0

Share this post


Link to post
Share on other sites

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.

 

I won't ask you to add other content mods, but for me, adding things like thaumcraft would enhance the experience, not ruin it.  Understanding that this could in no way effect your game experience, since you won't need to install anything you don't want to, I have to wonder why you'd be against people playing the game the way that they'd most enjoy.

 

And the fact is, working towards compatibility has the potential to add more content than any other update the devs could do.  Something I've noticed when playing on servers is that the population booms just after an update, and then fairly rapidly falls off a month or two later, when people have finished all the TFC content.  Adding more content is a slow process, especially given that this mod is simply a hobby for the devs.  But having the whole of vanilla mods available in TFC would be able to extend content almost indefinitely.  I feel that this would be good for the mod and a hell of a lot more fun.

 

...snip

----------------------------------------------

RE: Tsuarok

 

Point 3: Strongholds aren't actually neccesary (although that is one way to do it). As long as there are ender frames and ender pearls, people can get to the end. Ender frames could be made craftable (presumedly including materials found in the nether)

 

Point 4: Any overworld biome mod will require compatibility patches to modify the mod biomes. Unless someone has a brilliant idea that can prove this statement wrong

 

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.

0

Share this post


Link to post
Share on other sites

 

 

And the fact is, working towards compatibility has the potential to add more content than any other update the devs could do.  Something I've noticed when playing on servers is that the population booms just after an update, and then fairly rapidly falls off a month or two later, when people have finished all the TFC content.  Adding more content is a slow process, especially given that this mod is simply a hobby for the devs.  But having the whole of vanilla mods available in TFC would be able to extend content almost indefinitely.  I feel that this would be good for the mod and a hell of a lot more fun.

 

 

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.

 

0

Share this post


Link to post
Share on other sites

 

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.

0

Share this post


Link to post
Share on other sites

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.

 

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. Return HP and damage to vanilla-reasonable levels.

 

2. Include a system to allow server administrators (and individuals in SP) to easily add in new alloy, leather, pottery, and anvil recipes.

 

3. Stabilize the other dimensions, and add the option for end frames/obsidian generation or crafting.

 

4.  Biomes

 

5.  Dirt that is dirt

 

6.  Structures

 

7.  Villages

 

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.

0

Share this post


Link to post
Share on other sites

I don't know what other modding communities people pay attention to here. The gregtech community for example used to consider making TFC and gregtech compatible. The amount of effort required to make the combination work made even GregoriousT give up on it. I think it sais a lot that when gregtech was looking to implement a geologically accurate map with 35 ores and 23 rock types a user decided to make his own rather than try to make TFC core work with the rest of the forge mods commonly paired with gregtech

 

People asked Reika for TFC compatibilty, IIRC the awnser was something like what is TFC

 

Its been ~ 1 year since I last checked if Railcraft is TFC compatible. It at least used to be. If that is still true that is one mod that won't require a compatibility patch

 

Besides Railcraft (and possibly other content mods I didn't think about when writing this post), content mods will require compatibility patches (such as the TFC-BC crossover addon) to be TFC compatible. Those patches (if they are to exist) will have to come from the TFC community

 

My posts in this thread are not attempts to influence the development of TFC. They are stating facts. As long as the devs don't have a problem with these facts, there is no problem.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

 

To be honest I've never used CustomNPC first-hand. So my biggest question here that might prove a point is this, is the only vanilla things that you are able to customize using this mod crafting recipes? What about anvils and repairing items? What about smelting recipes in the furnace? Does CustomNPC let you do these too?

 

The point I'm trying to get across is that the reason it is so easy for these mods to implement new crafting recipes is because the base code of Minecraft makes creating new recipes extremely simple. Vanilla Minecraft has a hardcoded gameregistry that is specifically for registering crafting recipes.

 

For example, here's our code for how to craft a Thatch Block:

GameRegistry.addRecipe(new ItemStack(TFCBlocks.Thatch,1), new Object[] {"PP","PP",Character.valueOf('P'),new ItemStack(TFCItems.Straw, 1)});

For every single other interface such as the anvil, quern, pit kilns, knapping, clay forming, etc TFC had to write it's own manager to handle all of this stuff from scratch. Because it was written from the ground up, it is nowhere near as elegant as the vanilla registry that handles crafting recipes, so adding in new things to the manager other than directly hardcoding them into the mod or through an addon is much more work.

 

Edit: It should also be noted that Minetweaker had to write their own scripting language from scratch just so that the user-end of the system isn't essentially writing an addon mod in java. CustomNPCs also has integrated scripting langauges, but they use already existing ones such as javascript, which is why users lean more towards using the in-game interfaces.

 

http://www.kodevelopment.nl/minecraft/customnpcs/scripting

 

http://minetweaker3.powerofbytes.com/wiki/Guide:Script_Introduction

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites
For every single other interface such as the anvil, quern, pit kilns, knapping, clay forming, etc TFC had to write it's own manager to handle all of this stuff from scratch. Because it was written from the ground up, it is nowhere near as elegant as the vanilla registry that handles crafting recipes, so adding in new things to the manager other than directly hardcoding them into the mod or through an addon is much more work.
 
My guess, this is half your problem right here. You don't really have proper managers, per se, but rather just tricked-up UIs. If you have to hardcode each recipe, then you don't really have a crafting manager. A crafting manager collects the dispirate separate recipes together and organizes them automatically for use by the individual UIs. If your anvil crafting "manager" were a manager, the only thing you have to do to add a new recipe is add a few lines, and you're done. As such, it's at present just a tile entity UI that produces stuff.

A manager is practically an API in and of itself that other suites in your code use to add functionality. For instance, were I to code up an axe, I would use something like the following pseudocode:

TFCPlan axePlan = new TFCPlan(new Object[]     {" *   ", "**** ", "*****", "**** ", " *   ", '*'});    // this is the pattern for knapping and clay formingTFCSmithyWorkingRules axeRules = new TFCSmithyWorkingRules(new Object[]    {177, "P", "LMH", "U", 'P', TFCEnums.Punch, 'L', TFCEnums.LightHit,    					   'M', TFCEnums.MediumHit, 'H', TFCEnums.HeavyHit,    					   'U', TFCEnums.Upset});    // first number represents where on the scale the player should land on     // the last technique, while each string represents the techniques used in    // the last, penultimate, and third from last step.TFCProductArray axeProducts = new TFCProductArray(new Object[]    {TFCItems.CopperIngot, TFCItems.CopperAxeHead,    TFCItems.BronzeIngot, TFCItems.BronzeAxeHead,      // ...etc...    TFCItems.RedSteelIngot, TFCItems.RedSteelAxeHead});    // specifies all the metals that may be used in axeheads, with their     // associated axehead object types.TFCCraftingManager.addKnapping(axePlan, new ItemStack(TFCItems.stoneAxeHead, 1));TFCCraftingManager.addClayForm(axePlan, new ItemStack(TFCItems.axeClayForm, 1), new ItemStack(TFCItems.axeHardClayForm, 1));TFCCraftingManager.addCasting(axeHardClayForm, axeProducts);TFCCraftingManager.addSmithing(axeRules, axeProducts);

And there we go: we've just added the axe through the (prospective new) TFC crafting manager. The axePlan specifies the pattern to be used for the axe in knapping and clay molding. addKnapping() links that pattern to the stone axe head for knapping (the knapping submanager handles durability considerations). addClayForm() links the pattern to an unfired clay form item (axeClayForm), and to its hardened counterpart (axeHardClayForm) for kiln firing. Finally, addCasting() and addSmithing() adds the axehead recipes to the casting submanager and anvil submanager respectively. (The manager deduces which casting and smithing recipes are valid via other data, like knowing that the material copper (selected by the ingot) is castable and is valid as a casting recipe, while steel is not.)

This speeds development because you no longer have to hard code a new crafting task into the manager itself every time you create a new item to be crafted using one of the above methods. When you break it down, the templates for such crafting recipes are actually very simple. Once you get it working for a wide variety of recipes, TFCCraftingManager is ready to be opened up as an API.

 

I suggest that the next time one of your UIs needs an overhaul, that you recode it with something like the above pseudocode API, and will probably only require refactoring of the code. Trust me, this will save a lot of work down the line.

1

Share this post


Link to post
Share on other sites