Bay 12 Games Forum

Just a comment:

Density matters only because weapons are designated with a fixed volume. In the real world, this makes no sense:if you wanted a hammer that keeps its shape after repeated blows, you'd pick a reasonably tough material, then enlarge the hammer head until you could no longer swing it repeatedly. So I'd recommend you just make a "heavy hammer" with a larger size rather than to use an unrealistic, or worse, made-up high density material.

Quote from: lethosor on September 17, 2014, 02:32:47 pm

[...] This brings up another point: there are now multiple "0.40.12-r1" builds floating around that have different behaviors and features. Among other things, "hack-wish" no longer crashes in certain cases, "search" has been updated for 0.40.12, and workflow no longer produces repeating error messages. However, since builds built before these changes identify themselves as "0.40.12-r1", there's no easy way to tell which build of "0.40.12-r1" that specific bug reports apply to, for example.

That.  That's been a persistent problem for the past month, month and a half.

Not only is it causing confusion, it's also against the DFHack license.

Quote from: the license boilerplate

[...]
2. Altered source versions must be plainly marked as such, and
must not be misrepresented as being the original software.
[...]

Now in the current mess, salithus didn't exactly alter the source; he mixed-and-matched code from the official repo, part of it at a time when the repo was between official releases.  As I understand it.

It's still a problem.

Maybe the actual repo master branch should always have a DFHACK_RELEASE string with "-unofficial" appended to it?  (EDIT: in the file CMakeLists.txt)

And to make an official release, branch the master and change only that one string?

How about it, Peterix, expwnent, lethosor ?

I'd rather the DFHack developers not worry about unofficial builds. And I think those willing to build DFHack on their own should be hesitant to provide those builds to others -- do we really want to encourage others to download and run unknown executable's? 

But I can see the need to provide bleeding edge builds for lazy eager die-hards who want to run Toady's latest and have their DFHack too. Here's my solution: If someone wants to post a link or reference to an unofficial build, just do so in a separate message thread. Anyone wanting the official build can come here (or the latest thread), which is identified by the current version.

For those working on starter and mod packs, put whatever *you* want in those packs; just understand that users expect some level of testing on your part to identify any major issues or problems (and aren't likely to care at all about version identifiers).

Code: [Select]

[INORGANIC:DIAMOND_LY]
[USE_MATERIAL_TEMPLATE:STONE_TEMPLATE]
[TILE:15][IS_GEM:light yellow diamond:STP:OVERWRITE_SOLID][DISPLAY_COLOR:7:7:1][MATERIAL_VALUE:30]
[SPEC_HEAT:409]
[IGNITE_POINT:11440]
[MELTING_POINT:NONE]
[BOILING_POINT:16708]
[MOLAR_MASS:1201]
[IMPACT_YIELD:210000000]
[IMPACT_FRACTURE:420000000]
[IMPACT_STRAIN_AT_YIELD:47404]
[COMPRESSIVE_YIELD:210000000]
[COMPRESSIVE_FRACTURE:420000000]
[COMPRESSIVE_STRAIN_AT_YIELD:47404] bulk modulus 443 GPa
[TENSILE_YIELD:60000000]
[TENSILE_FRACTURE:120000000]
[TENSILE_STRAIN_AT_YIELD:4918] young's modulus 1220 GPa
[TORSION_YIELD:60000000]
[TORSION_FRACTURE:120000000]
[TORSION_STRAIN_AT_YIELD:4918]
[SHEAR_YIELD:60000000]
[SHEAR_FRACTURE:120000000]
[SHEAR_STRAIN_AT_YIELD:12552] shear modulus 478 GPa
[BENDING_YIELD:60000000]
[BENDING_FRACTURE:120000000]
[BENDING_STRAIN_AT_YIELD:12552]
[ENVIRONMENT_SPEC:KIMBERLITE:CLUSTER_SMALL:100]
[SOLID_DENSITY:3520]
[STATE_COLOR:ALL_SOLID:CREAM]
I decided to get Diamond's actual properties and, uh.

It's actually stronger than Adamantine by an order of magnitude. It said that the tensile strength was "60 GPa"; Adamantine is 5 GPa. What.

Adamantine also has 5000000/0 young's, bulk and shear modulus, though, so that's a bit different.

Diamond's actual properties? Those are theoretical values obtained at the molecular (nanometer) level. If I wanted "actual" properties, I'd use this information (from wikipedia):

A diamond will shatter if hit with an ordinary hammer. The toughness of natural diamond has been measured as 2.0 MPa m1/2, which is good compared to other gemstones, but poor compared to most engineering materials.

I'd rate the practical impact strength at no more that 10 MPa (back of the envelope calculation of impact from a hammer strike). Yield should be the same, so strain at stress is zero (simulating the shatter effect).

To be fair, there's much nonsense in the vanilla materials data as well.

Do I have a point? perhaps two:
1) numbers don't always make better "data".
2) mod what you want... but if you want broad acceptance of your mod, watch out for features that require suspension of disbelief (gem weapons that never break)

Back to the original question, updating the values of organic materials would be madness... much pain for little gain. For every situation where you made something more realistic, you'd break something somewhere else.

There are many problems with the simplified mechanics of DF. Here are some of the major ones I see:

• Shear mechanics are typically directional. Any material with grain, including wood, bone, or even forged metals, will have a different sheer strength depending on the direction of the blow relative to the grain. This difference can be up to an order of magnitude.
• There's really no such thing as impact strain. Impact resistance is about energy absorption, not force (per unit area) or even momentum.
• Different materials used in conjunction can have significantly improved material properties. Reinforced concrete would be a good example. A more relevant example is the strength of bone inside the body, with muscle pretension and support from ligaments and tendons, versus the properties of a bone item, as in a crossbow bolt.

All in all, I see the current material properties as a very reasonable compromise. I would not worry about the material property accuracy until the game mechanics are improved (or at least announced as final).

Great work on the equations. I'll likely use them in my top-secret mod project, where I already have improved raws for many inorganic materials.

I must be missing something. Why use Perl to create a custom markup language? What's wrong with html, or any of the various other markup standards?

Can Lua coroutines be used in user scripts (scripts directory, or game save init.lua)?

Potential use would be limit computation time per game tick for scripts such as Putnam's itemsyndrome.

Hard-coded, meaning you can't remove the buildings by modifying raw files.

But what about with dfhack?

Can someone help explain autoSyndrome to me?

I've been playing around with it, and it appears to be very limited in functionality. When the job complete event is called, the unit reference has already been removed from the job.

The lua eventful interface adds in the unit and building references, in addition to the job itself. I'm not sure why the cpp event isn't implemented in the same way.

Edit: I'm referring to a a built copy of the latest git files at https://github.com/peterix/dfhack