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.
wjg999

Tool reworking

24 posts in this topic

As of now there are no ways to enchant items through normal means and enchanting itself would not be in the spirit of terrafirmacraft as it is magic.

The answer to this could be the ability to rework tools combining gems/items with tools or armor in order to increase certain aspects.

An example would be a chipped/flawless diamond which could add a certain % of durability extra to the weapon/tool/armor, dependent on the quality of the gem, once it is welded to it and reworked, this however also has a chance of backfiring as when reworking the item durability is still dependent on the smithing skills of the player.

Another example could be an item created by adding "metal", bones and cacti together in order to make "painfull scales" which depending on the metal used will armor that it is welded to a Thorns enchant once it is reworked.

 

So in short: No enchantments directly, items need to be welded to another tool or armor and then worked in order to gain an enchantment dependent on the item welded on. 

0

Share this post


Link to post
Share on other sites

What you recommend would require complete rewrite of all tools. And would require similar system as Tinker's Construct is using. And then, we can have modular tools. But that would require tons of effort.

1

Share this post


Link to post
Share on other sites

What you recommend would require complete rewrite of all tools. And would require similar system as Tinker's Construct is using. And then, we can have modular tools. But that would require tons of effort.

I would love a system like Tinker's Construct. However being that it's random as to what gems you get. Well, Gems would need to be updated, so that you could seek them out..
0

Share this post


Link to post
Share on other sites

@Euphoric I do not see why it would require a full rewrite of all tools as it would be the same as smithing armor.

Example of armor compared with tool reworking:

stage1 armor + (double) sheet = stage2 armor ->  work stage 2 armor to gain armor with slight durability loss due to smithing mechanics.

tool/armor + diamond = unworked tool -> work unworked tool to gain tool with enchant with slight durability loss due to smithing mechanics.

0

Share this post


Link to post
Share on other sites

Because armor is hard-coded and the recipe is only one. People would definitely want more than one type of upgrade. Then, then they would like to have multiple upgrades. The amount of combinations grows exponentially, so you can't rely on Minecraft's item and ID system. And there is also problem of durability. MC doesn't really like crafting of items with durability. You need to use metadata hackery that TC is using.

 

Also, if they would implement some kind of upgrade system, it would inevitably get compared to TCon's and it would be hard to accept something that is worse than that.

0

Share this post


Link to post
Share on other sites

Because armor is hard-coded and the recipe is only one. People would definitely want more than one type of upgrade. Then, then they would like to have multiple upgrades. The amount of combinations grows exponentially, so you can't rely on Minecraft's item and ID system. And there is also problem of durability. MC doesn't really like crafting of items with durability. You need to use metadata hackery that TC is using.

 

Also, if they would implement some kind of upgrade system, it would inevitably get compared to TCon's and it would be hard to accept something that is worse than that.

 

Metadata (I think you meant NBT data) isn't "hackery", it was introduced for this exact reason - to have more control over the properties of an entity. And it's good for that.

1

Share this post


Link to post
Share on other sites

[OT]

Metadata (I think you meant NBT data) isn't "hackery", it was introduced for this exact reason - to have more control over the properties of an entity. And it's good for that.

It is hackery when compared to normal use of OOP. If items were normal objects with properties, inheritance, ability to implement interfaces and proper composition, then it would be 1000x easier to implement and debug them. Property bags are good for dynamic languages. But they have absolutely nothing to do in static languages like Java. And that is also why I'm saying MC is not properly designed for this kind of extensibility.

[/OT]

0

Share this post


Link to post
Share on other sites

[OT]

It is hackery when compared to normal use of OOP. If items were normal objects with properties, inheritance, ability to implement interfaces and proper composition, then it would be 1000x easier to implement and debug them. Property bags are good for dynamic languages. But they have absolutely nothing to do in static languages like Java. And that is also why I'm saying MC is not properly designed for this kind of extensibility.

[/OT]

I seem to missed the part of my programming course where adding members similar to Maps and Lists is considered "going against the normal use of OOP". Especially considering they are virtually in every Object Oriented language I can think of, "static" it be or "dynamic".

 

So, let's see here.

What if we have a class we want to add a new property to?

 

Case 1: If class has a property map (NTB Compound works just as well as default AbstractMap from java.util package), I just add the property and add processing unit for my property (if I add spoiling gauge, I add two double type fields for all classes and set its values to appropriate levels for things that spoil and to null for all the rest. In my handler I call these fields by name and process the data).

 

Case 2: If I can't use maps, I can't change base class in any way, extention it is. I extend the class. In my handler, since I can't really expect to recieve only my classes (it should accept the Item class, not MyModFoodItem class, really), I should fiddle with getting real class for all objects I recieve (which bound to leave some tricky leftovers that aren't that obvoius to deal with) and verifying it. Since original classes are still in the system, and default game still calls for them over my extenders, I should also extend base game class so it knows about my new shiny classes, I also should mod main method in one way or another for the same reason. And god forbid there are two mods installed at the same time that add different properties. Or, what even worse, the properties are the same, but your modded handlers expect values in slightly different format than the other mod's. Basically, I just rewrite the base classes and flip the bird at all those pesky bastards that want at least some basic cross-mod compatibility.

 

Do you see yet?

0

Share this post


Link to post
Share on other sites

We are going heavily OT here, but I need to respond.

 

 Maps and Lists is considered "going against the normal use of OOP"

Stop mistaking Maps and Lists and Property bags. Those have completely different meanings.

 

What if we have a class we want to add a new property to?

Your design is wrong. "Want to add new property" should never be a requirement. Unless you are using dynamic language.

 

I just add the property and add processing unit for my property

You are decoupling data and behavior. You are already going against OOP.

 

I can't change base class in any way

This is actually heavily desired trait. It makes the whole code predictable. Unpredictable code is hard to work with and reason about.

 

 I should also extend base game class so it knows about my new shiny classes, I also should mod main method in one way or another for the same reason.

This is what I mean by MC not being designed for extensibility. Properly extensible and modular code should allow you to use your implementations instead of defaults.

 

 And god forbid there are two mods installed at the same time that add different properties. 

Under properly designed system, composition of multiple implementations should be simple and straightforward. But that has requirement of actually being modular. Which MC is not.

 

 Or, what even worse, the properties are the same, but your modded handlers expect values in slightly different format than the other mod's.

That is what you get from decoupling your data and behavior operating over this data.

 

Do you see yet?

I just see your programming course didn't mention SOLID and fact that inheritance is terrible way for code reuse.

0

Share this post


Link to post
Share on other sites

Stop mistaking Maps and Lists and Property bags. Those have completely different meanings.

 

You named NTBC a property bag, but maps are apparently not? Be consistent. Or you then have to specify how "property bag" is different from the map. Because to me and these guys it is mostly the same thing - an object that can store multiple pairs of value entries and their names, of specified type, that can be easily get and set by name, which is how NTB in minecraft works.

 

You are decoupling data and behavior. You are already going against OOP.

I'm not going against OOP, nor do I do it using property collections. Unless you really expect people to write all computational methods right inside the classes that are storing values, eliminating all good programming practices that involve division on storage entities and processing entities. Which makes no clucking sense, so I assume you don't expect it, considering you mentioning SOLID.

 

This is what I mean by MC not being designed for extensibility. Properly extensible and modular code should allow you to use your implementations instead of defaults.

 

Under properly designed system, composition of multiple implementations should be simple and straightforward. But that has requirement of actually being modular

I challenge thee to provide a concept of good and easily expandable system that wil not only allow for modification (easiest thing in java or OOP for that matter), but also will allow it to properly handle infinite number of possible behaviour overrides on the same class without shitting itself. Oh, and don't use collections - they are bad, as you said. I expect lots of instanceof checking and if() statements.

 

That is what you get from decoupling your data and behavior operating over this data.

So, I'm supposed to work on a once-and-for-all-set objects and check their instanceof responce or what? Why not just add a collection of properties that will do it instead?

 

inheritance is terrible way for code reuse.

Copy/paste reuse is even worse. And you can't not reuse code in any descently sized system.

0

Share this post


Link to post
Share on other sites

You named NTBC a property bag, but maps are apparently not? Be consisntent. Or you then have to specify how "property bag" is different from the map. Because to me and these guys it is mostly the same thing - an object that can store multiple pairs of value entries and their names, of specified type, that can be easily get and set by name, which is how NTB in minecraft works.

Property bag is specific way to use a Map to store additional/all data about object in form of String/Object Map. Map is generic way to store Key/Value pairs of types that user defines. They are related, but they are not the same.

 

 Unless you really expect people to write all computational methods right inside the classes that are storing values, eliminating all good programming practices that involve division on storage entities and processing entities. Which makes no clucking sense, so I assume you don't expect it, considering you mentioning SOLID.

I do. That is main thing behind encapsulation. And using reflection is special case it is not really "breaking" encapsulation. And you could still follow this and abide by SOLID. For example you could have GetDataToSave() method, that only returns data in a way good for saving. This would keep the encapsulation and still have good SOLID properties, because the entity is not doing the saving itself. Also, if you mention division between storing and processing entities, you probably mean Anemic Model , which is considered bad, especially with relation to OOP design.

I challenge thee to provide a concept of good and easily expandable system that wil not only allow for modification (easiest thing in java or OOP for that matter), but also will allow it to properly handle infinite number of possible behaviour overrides on the same class without shitting itself.

This might take a while, but it is doable. And I don't have time for that right now. But I would probably use some kind of collection of commands/strategies, that get stored on the entity/item.

Oh, and don't use collections - they are bad, as you said. 

I said property bags are bad. And as I explained above, they are different things than collections and maps. Which are generic data structures, that allow you to specify which kind of data you want to save.

So, I'm supposed to work on a once-and-for-all-set objects and check their instanceof responce or what?

You are still thinking about objects in a way of storing data, instead of way to represent behavior. If you would do that, you would realize you "just" create bunch of generic APIs and then use polymorphism to express different behaviors over this API. For that matter, I heavily recommend reading this, It opened my eyes to the way of proper OOP design.

Copy/paste reuse is even worse.

Oh, so you never heard about code reuse using composition or about "composition over inheritance"? Because if you didn't then you have still lot to learn and it answers all your questions properly.

0

Share this post


Link to post
Share on other sites

Property bag is specific way to use a Map to store additional/all data about object in form of String/Object Map. Map is generic way to store Key/Value pairs of types that user defines. They are related, but they are not the same.

Wait a second here. So, you are telling me, storing pairs <Object,Object> is perfectly fine, but storing <String, Object> is an immediate blasphemy, or what? I can't trace your logic to the part where <String, Byte> maps (which NTBC is) become a black stain on OOP's shiny buttocks.

And using reflection is special case it is not really "breaking" encapsulation. And you could still follow this and abide by SOLID. For example you could have GetDataToSave() method, that only returns data in a way good for saving

And how is assigning GetDataToSave() is different from what Minecraft is doing? Are you even aware of what's happening with NBT during object life cycle or were you just hearing things at random about it?

you "just" create bunch of generic APIs and then use polymorphism to express different behaviors over this API.

So, every time a mod wants to redesign an iron pick class with an interface, it would extend it and replace all instances on it. And then when several mods do that, pick gets replaced with whatever mod's logic gets priority in compilation and/or thread runtime, while other mods can go choke on a Fish. Good design decisions, innit?

property bags are different things than collections and maps. Which are generic data structures, that allow you to specify which kind of data you want to save.

NBTC is not a property bag then. And all this conversation where you told me to go learn things I already know was not even neccessary.

0

Share this post


Link to post
Share on other sites

 So, you are telling me, storing pairs <Object,Object> is perfectly fine, but storing <String, Object> is an immediate blasphemy, or what?  I can't trace your logic to the part where <String, Byte> maps (which NTBC is) become a black stain on OOP's shiny buttocks.

NBTC is not a property bag then.

I'm talking about how you use those data structures, not how they are implemented. Using both map<Object, Object>, map<String, Object> and even map<String, Byte> is wrong simply because:

  • You loose type safety. The code that reads values needs to know what kind of type is saved under what key. Or it needs to do some kind of reflection over returned type. This is what dynamic languages do. Property bags are way to simulate dynamic typing. C# for example has dynamic type which is basically Dictionary<string, Object> with bunch of syntactic sugar. But both Java and C# are mainly static languages, so using such dynamic typing should be heavily discouraged. If you use specific type for value, for example map<string, int>, you will always get int out of it, no matter what you try. Yeah, you can encode your data as int, but then why not save that data directly? You are basically doing manually what language and compiler can do for you.
  • You separate data from behavior. OOP is all about grouping behavior with it's related data. If you separate those, you can just fine do procedural programming. Basically, you are making it really hard to apply many OOP principles like polymorphism. Eg. it will be hard to extend the code without having to change it. I have seen enough code like this to know that this kind of suboptimal OOP design can lead to huge increase in maintenance and change costs.

And how is assigning GetDataToSave() is different from what Minecraft is doing? Are you even aware of what's happening with NBT during object life cycle or were you just hearing things at random about it?

I was not talking about anything in relation to NBT with that. Read what you said what I replied to. We were talking about encapsulation and separation of concerns.

Also, there is one huge difference between GetDataToSave(saveContext) -way and using NBT/property bag directly : In former, the object has no idea that some kind of NBT-like structure exists. the saveContext can be implemented separately and it can save it as property bag, in relational DB or as a document in Document DB. Anything goes. This kind of indirection is what makes OOP so powerfull. You could also easily implement it in hiearchical pattern, by having object implement IPersisted, which contains this method and method to read it, you could just pass this object to the saveContext and have whole object persisted without need to go through it's individual data. 

So, every time a mod wants to redesign an iron pick class with an interface, it would extend it and replace all instances on it. And then when several mods do that, pick gets replaced with whatever mod's logic gets priority in compilation and/or thread runtime, while other mods can go choke on a Fish. Good design decisions, innit?

Again, stop thinking about extension using inheritance. Start thinking using composition. 

For example, Item could have collection of Behaviors. Modmaker could implement a new behavior and then add this behavior to the item. Item itself would then execute individual behaviors so one behavior would be original one, another would be from ModA and next one from ModB, etc..

This is obviously combination of Strategy Pattern and Composite Pattern. 

0

Share this post


Link to post
Share on other sites

I'm talking about how you use those data structures, not how they are implemented. Using both map<Object, Object>, map<String, Object> and even map<String, Byte> is wrong simply because:

  • You loose type safety. The code that reads values needs to know what kind of type is saved under what key. Or it needs to do some kind of reflection over returned type. This is what dynamic languages do. Property bags are way to simulate dynamic typing. C# for example has dynamic type which is basically Dictionary<string, Object> with bunch of syntactic sugar. But both Java and C# are mainly static languages, so using such dynamic typing should be heavily discouraged. If you use specific type for value, for example map<string, int>, you will always get int out of it, no matter what you try. Yeah, you can encode your data as int, but then why not save that data directly? You are basically doing manually what language and compiler can do for you.
  • You separate data from behavior. OOP is all about grouping behavior with it's related data. If you separate those, you can just fine do procedural programming. Basically, you are making it really hard to apply many OOP principles like polymorphism. Eg. it will be hard to extend the code without having to change it. I have seen enough code like this to know that this kind of suboptimal OOP design can lead to huge increase in maintenance and change costs.

Yet again - read what NBTC is and how it is used. Because it's not really a <String, Object>, but <String, <Class, Object>> map. Or rather it's not a map at all - it used like one is all. And you can't really get Integer from whichever place String is stored. And there's no more separation between bata and behaviour to it than using primitive type variables in object1.methodA->object2.methodB messaging via parameters.

 

 

there is one huge difference between GetDataToSave(saveContext) -way and using NBT/property bag directly : In former, the object has no idea that some kind of NBT-like structure exists. the saveContext can be implemented separately and it can save it as property bag, in relational DB or as a document in Document DB.

NBTC is serialized object's parameters, and it makes no sense to separate NBT saving from it, considering how much you talked about this kind of separation being badbadbadbad. There's no need to have another object knowing exactly what kinds and how many private fields your object has, don't you think? Sure, getField(), fine. But you still separating a single method into another class, using additional memory and create-call-invoke time, that will do just fine without this separation.

 

 

Modmaker could implement a new behavior and then add this behavior to the item. Item itself would then execute individual behaviors so one behavior would be original one, another would be from ModA and next one from ModB, etc..

So then saveBehaviourContext() would result in exactly NBT-type structure.

0

Share this post


Link to post
Share on other sites

I also want to add on to the first post about the tool upgrades. Between steel, blue steel, red steel, and blacksteel. There is little difference between breaking ability. Witch makes it almost not worth getting any other steel. Unless u want it for the color.  Giving enhancements to the tools and having to get up to the other tools to have better/ more enhancesmenta would make getting redsteel and blue steel a better choice to get to. Or just give u that reason to get them    Lets say. Steel gets only 1 upgrade black steel 2 red steel and blue steel get 3-4 upgrade slots.. ?? Anyone like? :)

1

Share this post


Link to post
Share on other sites

I had an idea for tools instead of enchanting them with gems they get different values based on the percentage of materials used

so a bismuth bronze pick is made of

10-20% Bismuth

50-70% Copper

20-30% Zinc

we could make it so that a 50-60% Copper bismuth bronze pick has a slightly higher mining speed with less durability

and a pick with 60-70% Copper bismuth bronze pick would have a lower mining speed but a little more durability

this could also be specific to seed so players cant know exactly how it works and maybe have it also be influenced by their tool smithing level

also making a material of a "perfect mix" would give other "enchantments" such as silk touch or fortune but making fortune work for only the probability of getting gems cuz I like finding them when I dig :D

that's my idea for a realistic enchanting in this mod :D

0

Share this post


Link to post
Share on other sites

I like that you are trying to add the enchanting characteristics in a different way.

I do not however think gems would be the way. It's the same as saying that they some how are imbuing the tools and weapons with magical powers,

I think we  have enough alloys in the mod to use in that manner.

So for example blue steel would add  fire protection and  red steel would add fire aspect.

We could think of alloys to recreate most of the vanilla enchantments.

That would be a much better reward for high tier metals than red/blue steel bucket. 

0

Share this post


Link to post
Share on other sites

I do not however think gems would be the way. It's the same as saying that they some how are imbuing the tools and weapons with magical powers,

Exactly!

 

 

So for example blue steel would add  fire protection and  red steel would add fire aspect.

Wait no!

 

I was thinking about enchantments, and some are realistic, like Sharpness.

We could actually use a gem for this. You put the sword in an anvil and then there should be a slot for gems. Gems could be used to sharpen a sword's blade. And it's pretty simple. Different gems give you a different damage increase, but you will also lose a really little bit of durability, because after all you're also taking metal away while sharpening the sword. Anyway, diamonds should be the ones that increase the sharpness the most, while weaker gems would gradually increase sharpness less and less, like emerald, it should add less damage than diamond. Also, when you use a gem, it has a great chance to break and become a more flawed version of it, following this pattern:

exquisite > flawless > normal > flawed > chipped > broken gem, it simply disappears.

 

Then the gems could also be used as efficiency for tools, because after all a tool is efficient when it's sharp, because a pickaxe breaks rocks quickly with that sharp point, a shovel passes through dirt faster if sharp enough, an axe would chop better if sharp, and also do more damage, because it's also used as weapon, and so on. So gems would work to add sharpness to weapons and efficiency to tools.

 

Now I would exclude some unrealistic enchantments

 

Fire protection, because we only have metal armors and they're good heat conductors, leather armor would just burn.

 

Feather falling, because we are heavy and yet I don't know a way to magically fall slower without a parachute.

 

Respiration, because armors shouldn't add a magical way to breathe better underwater.

 

Aqua affinity. This is a bit tricky to explain. Yes you could make an armor lighter, and this would allow you to mine faster underwater, but what happens if you are not using an armor?You mine slow anyway, so there's no sense in adding an armor to make you mine faster

 

Depth Strider, same reason as Aqua affinity

 

Smite, because either a sword is more painful for everyone or it's not painful at all.

 

Bane of arthropods, same reason as Smite

 

Fire aspect, really, we shouldn't have swords able to set enemies on fire if we want a believable game.

 

Silk touch. Ok, on this we could discuss a bit, but I think that it could break the TFC balance if you could acquire some blocks as they are generated.

 

Fortune, for balance reasons, again we could discuss on this.

 

Power, because it increases arrows damage. I think that we should need to change arrow types instead of adding something to the bow that affects arrows. The bow has nothing to do with how much an arrow is painful

 

Flame, again for the same reason of Power. We could lit some existing arrows instead.

 

Infinity, for obvious reasons.

 

Luck of the sea, because there's no believable way to make a fishing rod more lucky...

 

As for the other non excluded enchantments, I may add them later, I just want to see how this suggestion goes first.

0

Share this post


Link to post
Share on other sites

But all you saying about believable could be achieved with the notion of alloys.

I think is easy to imagine that blue steel is some kind of alloy that can resist fire since it can pick up lava.

The same logic could be applied to most of  the enchantments.

A good alloy is what makes a better sword not some gem.

Alloys will make tools and weapons harder to break (durability)

Sharper and faster (efficiency )

I can even see thorns. As actual thorns outside an armor.

1

Share this post


Link to post
Share on other sites

But all you saying about believable could be achieved with the notion of alloys.

I think is easy to imagine that blue steel is some kind of alloy that can resist fire since it can pick up lava.

Yeah, I was just disagreeing with the fire aspect part. I think blue steel should be the only thing that can create fire resistant things, so the fire resistance would only be present in blue steel armors.

 

 

I can even see thorns. As actual thorns outside an armor.

Yeah, I can see this too, that's why I didn't exclude it. You could bend some metal shards to an armor and work it to give it the thorn enchantment, but wait, a different version of that enchantment, we don't want our armor to magically damage a skeleton that hit us with an arrow or javelin.

 

 

A good alloy is what makes a better sword not some gem.

About this, the alloy itself doesn't make a sword sharper than a sword of a different alloy or metal, it's the blacksmith that sharpens it. You could have a sharp red steel sword and at the same way you could have a sharp copper sword. What the alloy changes is the durability. And you could use the gems to sharpen weapons, so that finally gems could have an use, and it's believable, gems are quite resistant, they're good for sharping the blade of a sword. I didn't mean to say you have to weld the gem to the sword, you just use it as a tool to sharpen, nothing more.

0

Share this post


Link to post
Share on other sites

I haven't thought of gems as a sharpening stone. It may work, I don't know.

As far as alloys go I know that they actually have a saying in how much you can sharp a tool.

Wikipedia here

"The composition of the (sharpening) stone affects the sharpness of the blade (a finer grain produces sharper blades), as does the composition of the blade (some metals take and keep an edge better than others). For example, Western kitchen knives are usually made of softer steel and take an edge angle of 20–22°, while East Asian kitchen knives are traditionally of harder steel and take an edge angle of 15–18°. The Western style kitchen knives are generally in the range of 52 - 58 on the Rockwell scale which denotes the relative hardness of a material. For example, Wüsthof uses a chromium-molybdenum-vanadium steel with a hardness of 58 HRC.[2] As a comparison, Tojiro Senkou produces a line of knives with a hardness of 61 HRC."

So better alloys can be sharpened better than others and keep the sharp longer.

​Different alloys would also make for lighter tools and weapons witch could be translated into speed. 

0

Share this post


Link to post
Share on other sites

 (some metals take and keep an edge better than others).

Oh you meant this. Yes, that's true, different alloys can be sharpen more than others, and can stay sharpen for more. Usually higher alloys could stay sharper for more, but that's not the case of the steel. While being waterproof, steel keeps the sharpness less than iron, with the disadvantage of rusting for this one. So basically alloys should always stay more and more sharp, until iron, then the rest of alloys should be made of steel, which can't keep sharpness more than iron. You can see this if you ever had one of those swiss knives, the ones you use to carve wood and to survive in the wild.

0

Share this post


Link to post
Share on other sites

This is a scissors advertisement so It may not be true:

"The Titanium Bonded blades are 3x harder than steel so they stay sharp longer."

 

Those blades are made of stainless steel with Titanium bonded at the molecular level.

I actually own a pair of those and can confirm that they are sharper and last longer than regular scissors.

We keep saying Red and Blue Steel, but I think the mod is trying to simulate high level alloys with them.

After all if you mix nickel and bronze and steel you not gonna have steel. 

I agree that is easier to sharpen an old iron knife than a stainless steel knife.

But a very good alloy sword is going to be sharper than a iron machete and stay sharper longer.

So I do believe in using the existing system of alloys and just add perks to then in a believable way.

No swords that make the mobs catch on fire.

With a little imagination I can accept that blue steel is fire resistant. We do have fire resistant alloys and off course some kind of padding should be needed but that's another issue.

There is so much that could be added to the game.

For example in making a sword usually the smith is going to use 2 kinds of metal  a flexible one for the center so the sword will bend a little and not break so easy. And a hard one for the edges.

I think we agree on the basic witch is NO MAGIC. Everything else is OK.

0

Share this post


Link to post
Share on other sites

This is a scissors advertisement so It may not be true:

"The Titanium Bonded blades are 3x harder than steel so they stay sharp longer."

 

Those blades are made of stainless steel with Titanium bonded at the molecular level.

I actually own a pair of those and can confirm that they are sharper and last longer than regular scissors.

Yes, I can confirm that adding titanoum to steel can improve its ability to stay sharp. But too bad we don't have titanium to add to steel in this mod, and about the black, red and blue steel, I don't really know how they should behave, so I supposed they should be similar to normal steel.

 

 

I think we agree on the basic witch is NO MAGIC. Everything else is OK.

Yep. Honestly I am thinking about blue steel, should it really be resistant to fire? The thing is that if we want to add this suggestion to the mod, we should also remove the fantasy alloys and replace them with something more believable, ie titanium and steel could make a good sobstitute for black steel.

0

Share this post


Link to post
Share on other sites