Is there a good way to place down beams in the air? 

And I'm having trouble figuring out how to use support beams to increase the verticallity of my builds. I'll but a bunch of support beams a long a walle, but i don't see the stress decreasing at all on the bottom block.

Also I think you shouldn't be able to place your beam on the block outline that the beams create.

Something cool about this mod that I just realized is constructing windmills will now be a much more interesting endeaver.

Thanks!

The bug:

erh yes ok, I know why. The outline you are seeing is actually intended, it allows you to place blocks "on" beams, say after placing a beam "stilt" from ground to up in the air, and then you place a roof on the beam, or bridge/platform/step. But in that added functionality, I bet I forgot to create a beam "beamknobindex"-based refresh of the block/beam collbox point's outline, if environmemt destroys the beam's start point. If you reload the save, it should perhaps remove it.

Your description is great, so don't worry about pictures. I'll fix it in a 0.6.1 hotfix soon, when I get some more bugs identified!

This mod seems amazing so far! I managed to find a glitch with the suport beams were they will create an invisible block outline around the beams for the vanilla and modded beams. this hit box blocks the player from placing more beams in the same area. but if the beam is destroyed not by the player say a falling block this hit box will stay and enable any connected block to never go above 93% stress.I have pictures but I am not sure how to send them lol.

I kno rite? It's @#€^ awesome! The model works!! Rest is just balancing and refactoring, easy. And thanks!

And yeah i'll change the stick beam recipe and then look at the thatch tensile strength some more. 

Edit: and yes, a beam collapse math too probably for at least stick beams perhaps, just have to implement it carefully.

Absolutely adoring this right now, the bigger issue is that this small part was 10 stick beams and has bankrupted me and my family for the next few generations. Wattle + support beams is a very good compromise and makes the house much more realistic. 

Still I'd say thatch got the short stick out of this deal, but I'm quite happy seeing the execution work out nicely even if it's in this small scale.

Edit: The balance for the stick beam (if it's being considered as a tier 0 scaffolding) is a careful one, I'd very strictly balance it towards thatch and at most wood, making it so that it can't support anything heavier at risk of collapse. I'd honestly be fine with 3 firewood + knife dura for 1 beam, A couple trees and you have the scaffolding for your house. 

Hmyeah youre right I think stick beams recipe should probably just be two or three sticks and then a knife dura hit. So it becomes analogue to wattle.

Duly noted, i'll change that in a 0.6.1 shortly, and thanks for the excellent testing feedback!

Yeah I find the ruins to be fine, the idea of having to enter one with support beams sounds nice, but it still begs the question as to how they... were used before. That's a question for more fully fledged lore of in how much disarray the ruins are and how long ago they were used. They should be structurally sound after all. Maybe making the non-obtainable (are they non-obtainable?) moss-rust-layered blocks act as a sort of glueing agent that makes the stress very lax? 

My only real piece of balance feedback would be thatch vs wood, right now I can safely bridge with wood which is fairly inexpensive in mid game but completely unobtainable early, whereas the comparatively very-expensive thatch roofs are worse than making a roof out of bricks, if you've ever tried making a roof out of bricks, it isn't easy.

Edit: I may also currently be very dumb in regards to making the thatch roof, maybe it's a lot simpler, but if I'm understanding correctly I need a metric ton of stick beams

Wattle fences are cheap and very nerfed, stick beams are fairly expensive and extremely reliable, maybe an inbetween?

But you might be right in the sense that thevstick support beam recipe should perhaps not require rope/ an extra binding ingredient.

Yeah no idea why responses aren't below the comment.

Regarding beams: well for a roof you effectively now only need 2/3 the actual roof blocks. And the anchor design is, at a minimum easily made stick beams can just be used. But yes, you can consider this a hardcore mod, I'm a as tough/realistic as possible kind of player, so that's of course reflected in the mod. Civilization ain't easy.

Yes regarding the chiselled microblocks: you will probably need to look into playing with the pickup on crouch setting. I have yet to find a way to allow chiselled blocks work as structural stress blocks without also including the, well, chiselled blocks in ruins after the player starts excavating. You can't gate them away, engine limitation, and also I'm not sure I want to, since now a ruin actually becomes an archaelogical, dangerous dig site, as if it was a mined cave. I kinda like that.

Re: your edit. As far as I can tell from the screenshot: you wattle is arched into the cobnle block, from the cobble wall. The cobble block is also braced by the thatch roof. Your wattle is also close to collapse.

It's a balancing issue, not a model issue, from prior feedback, a few people were unhappy with too nerfed wattle.

Re: thatch: yes it's thatch. It's layered grass. I can't really see why you aren't just building a room, then angle the roof with stick beams, then place the thatch? Like in your posted video? 

You cant build a roof by placing grass, then place wattle stick next to it then place grass on top of that. As in real life, that just collapses.

Try creative and then place the beam skeleton if you wanna see fast what i mean, you are not going to build a roof by just placing unsupported, unarched blocks, until you get much better blocktech and materials, in this mod.

Hmm I'd say it's fairly expensive to make full on support beams for a thatch roof, considering support beams can support way heavier and often cheaper roofs. I'll try the wattle. 

In other news, Ruins are pretty ruinous right now. Hopefully I don't keep dying to them. Also, it's dropping the chiseled blocks which can't be easily placed and clutter a lot, probably intentional so that if you're building with chiseled blocks it doesn't destroy your progress? But otherwise It'd be nice if they broke into normal granite stone (pebbles)

I forgot to make it a reply, but the threads get lengthy and this is kind of a bad way for feedback anyway, it's too cluttery

Edit: Here's my point on the roofing support for thatch, if I understood correctly, bending strength is what makes it so that it can be extended laterally without increasing stress, and it's 3 times worse than cobblestone right now. So, it needs supports to be put in place, but wattle fences also have low bending strength so you need a complete scaffolding of the roof. 

Side note, weight doesn't seem to be propagating downwards so you can put a heavy stone block on top of a flimsy fence at 82% stress and it's the same as putting light grass.

 I unfortunately cant necessarily recommend just assuming the new system works out of the box on your old house, roofing wasn't even implemented in 0.5.1 😅

Your roof/floor/ceiling isnt falling yet, since no blocks have been disturbed yet.

For how it works now: well basically like in your video, make stick support beams, and possibly wattle poles, place the skeleton (remember to use shift when needed),  place the thatch on the beams and voila. The beamspans have pseudo collisionboxes now, if you will, that you can okace blocks on.

Now for cobblestone floors/ ceilings I would obviously recommend stronger beams than stick, probably at least oak, and then slabs to halve the mass. You could even thin out the floor even further mass wise by chiselling.

Collapsing on 100% stress while supported by weak beams is deferred to a later version, where walking on said blocks would trigger collapse.

The model more nerd mathwise: beams give an anchor, that prevents collapse/ falling from being isolated in air. But they only reduce stress if actually angled unto the block, like in real life. The anchor itself is much weaker than a ground anchor.

This is how it was after two hours of testing it out and having the walls fall in on me, before the update. This continues to work even if the stress of the cobblestone says 100. 

hey can you guess what happens once I update this block (this is a failure of my own making)

edit: What's the intended way of building a thatch roof now? that feels like it should be early game. 

test. Ok the responses appear above the comment, huh.

huh, you can respond to comments now?! or was it always like that? 

anyway, great! thank you for the testing! 

The ceiling, well the system is completely, totally different now. So if you could elaborate a bit on that ceiling scenario, possibly with screenshots, that would be great! Any ceiling is possible if you just put support beams under it. But wood ceilings/ floors are best now, the IRL reality that the values are simulating is you can't really build just stone horizontally cantilevered more than 1 or 2 blocks, the brick and mortar tensile strength is too low (though clay brick and fireclay brick can cantilever decently far). So you'll need support beams or arches, if you aren't flooring with wood.

Testing it out right now, my cellar with a ceiling with distributed horizontal load is still holding up on 1 layer of cobblestone, but now I can make a moat out of cobblestone without it collapsing sideways arbitrarily.

Rasea XD lmao. Yes v0.5.1 might be a tad bit too nerfing.

Hopefully with decent materials, you can easily build to 6 block high cobblestone in v0.6, AND be safe in the knowledge that it's actually structurally rEaLiStIc bEhAviOoooor. Also, if you build walls, not just pillars, there is both a confinement effect and a lateral bracing effect that reduces stress.

A nice side effect of the new beam functionality that I haven't mentioned yet, is, that if you angle the beam =< 45 degrees, you can use it to support larger roofs, as in real life. Another nice side effect is you can now place the beam endpoint in air, so you can make unwalled roof covers on beam stilts.

I'll probably upload it later today, just have to make some new videos first. The possible/probable bugs in v0.6 will most likely be overarchingly related to 1) buildings that use arches as support for floors above them, 2) chiseled block fractioning of overall block stress in the blockspace of the former unchiseled block, and 3) then perhaps performance spikes/server tick overload from some missing edge case gate or condition for blockscanning, I haven't discovered the need to implement yet. But the mod actually works along with betterruins now too, at least the betterruins ruins I've tested on so far.

edit: ran the calculation on granite, sandstone and chalk cobblestone : They are 7, 5, 4 high max each. Remember though that sandstone and chalk have lower mass, so perhaps this has applications for constructions higher up, or making pillars go further if they don't need to support as much further up. But then you could also just use wood for that.

Waiting very patiently for this, my 3 block tall cobblestone hut will become a reality this weekend.

Short update for interested players:

• The new system is done (gReAtsuccEs).
• After this, I did value rebalances on earthern, wood, stone, metal. The basic math building blocks/ blocktype and material values are mass, crush strength, stiffness, bending strength, interblock support strength (how high you can build by making walls, bastions, multipillar columns etc. by benefitting from physical phenomena of lateral bracing (diverts crush from above, increases stiffness), and confinement (increases crush strength and buckling point by being surrounded by other blocks)'
• Post v0.6, the blocktype and material values, along with arch and angled cantilever constructions, are probably what I will need most feedback on from interested players
  • the system itself should be intuitive and logical (basically follows IRL structural engineering, except for some edge cases like lateral earth pressure on walls (currently set out of scope), flying buttressing, shear stress (minimal impact in voxel space, set out of scope) and some arch mechanics).
  • wood good horizontal, stone good vertical, metal best of both worlds
• Refactoring has been quite succesful so far, all of the collapse tick overloading I was experiencing in testing was solved easily via queuing over ticks.
• v0.6 upload expected this weekend at the latest.

U3er yup those bugs, along with the rest of them, is basically leftovers or incomplete conditioning from making a system partly based on the vanilla system, which is directed at something completely different than buildings, namely very performance efficient rock caveins.

Doing it that way had one critical advantage though: very small drain on performance (since it was route tracing based, not based on each single block having 3-4 values that needed recalculating every time some block below or above it far away in the building changed, only the route changed values).

In the new system, beams basically reduce stress for the block it anchors to, which allows more construction to be built on top of that block. The variables affecting stress I have so far is:

• verticalload governing total weight crushing from above
• bendingmoment stress on a cantilever root, calculated by horizontal bfs, and tensile bending strength capping how much a cantilever block can resist
• anchorstrength flood-fill modifier looking for, as far as i remember, 50 ground blocks
• groundbeta flat reduction modifier for ground blocks by the ground being sand/soil/gravel/rock
• compressive strength defining the crush of the block itself
• elastic modulus and columnheight determining buckling from vertical height.
• mass of the block, which goes into weight distributed downward and bending moment (heavier horizontal pillar blocks put more stress on the root block
• beam bonus, a flat stress reduction modifier determined by beam material (stick vs woodtypes vs metaltypes).

This might all sound genious if I had figured it out myself, but it was really just copying existing engineering values and putting them into existing equations and trying to make them fit on a voxel block game, for example the Rankine-Gordon equation is used to make an axial ratio, which then combines with a bending ratio that uses the AISCH H1-1 formula. It was the same with the eccentricity thing, I, not being a structural engineer, just didn't understand eccentricity was meaningless in a voxel block game.

Now all of the above I guess you can imagine will require some massive refactoring, so it doesn't drain performance into the abyss.

Funnily enough, the worst performance bug I'm dealing with currently isn't even server side, it's massive lagging caused by the TOOLTIP displaying block stress on the client side getting overloaded by the calculations lol. Luckily that one should be an easy fix, I just need to understand the vanilla Vintage Story performance hooks and api stuff better than my current understanding.

edit: oh yeah and maybe you can tell from the variables above, I also have not yet added a wall or multipillar column buttressing effect yet.

edit2: hmm this dialectic commenting is working well. Just realized if I simulate IRL even more aggressively, for example by treating 10 single blocks in a column as an actual single column mathematically, thus becoming more "real" in its bending, crushing and buckling math, I could theoretically at the same time reduce the amount of calculations from 10 to 1, using the same BFS scan vanilla already uses. But how to deal with angling/ arching in that environment.Hmmm. 

That all sounds awesome, sounds like ill need to give it another install when 0.6 comes around.  Actually installed and tested 5.1 on my save today and my new 2 story house didn't completely collapes at first.  There was of course areas I could have pre supported more, but there were some weird spots on my ground floor where the plank floor blocks which were sitting on top of perfectly stable cobblestone blocks which made up the ceiling of my cellar were at a 33% instability for no apparent reason which tried collapsing when I walked on them, doors were also still triggering collapses when next to instable blocks, and I noticed that support beams were only supplying support to blocks either on their ancor point or end point.  But i'm assuming this should be fixed in 0.6 from what I see.

Purhnicus

re: wattle fence : Which version are you on? Wattle is nerfed, but latest version should allow wattle to be placed on structures. 

re.: packed dirt : Packed dirt should have falling sideways enabled. Have you got soil, gravel and sand instability set to on or off?

re.: whatever 0.5 version you are using, the system will be fundamentally changed in 0.6, and wattle will change behavior to be placeable in the way you are describing easily, while packed dirt reliably falls.

There seem to be strange things happening with wattle fences on supported structures, I want to build on top of a cobble platform raised from the ground and when I place wattle fences they seem to fall through the drystone blocks or skitter off the 5x7 platform and go to the ground, also when breaking rammed earth it turns into packed dirt that one could be on me though. Just wanted you to know these strange things, I've been messing around with building to see how it'll go in a survival world with buds and lastly packed dirt can tower a much higher 1x1 tower seemingly forever.

Belen U3er

success, I now have a functioning physical model that simulates correctly:
1- cantilevers falling at root stress overload.
2- arches support eachother and keystone transmits stress downward unto both branches. 
3 - branching "fuzzy" cantilevers at angles transmit stress to the root on the pillar. 
4- partial collapse at root stress point, not total structure collapse.
5- anchoring in ground differentiated by quality of the ground (volume until a flood fill capbounded)
6- anchoring goes from ground level, not from depth of pillar, so a deep pillar gets same stress (or better if the deep pillar starts on rock) at ground level as a normal pillar placed on ground.
7- support beams work.
8- no unintuitive collapse, and no collapses on block disturbance by doors etc.
9- system doesn't affect initial chunk worldgen or later worldgen structures unless disturbed by player. The disturbance is not excessive either so in testing ends up creating a fun little minigame, where support beams have application for securing architectural digs and so on. Tested on BetterRuins as well. euh scratch that for now, some of these ruins are just way too big lol.
10- little addition of wet mudbrick, was missing from Wilderlands Block Adjustments.

All that's outstanding that I can currently think of is:
a- wall and multi-column buttressing
b- support beam span also supports blocks, and can support a block suspended in air at both beam end or start point and beamspan (trivial implementation in this model).
c- foundation width reduction of stress.
d- balancing of values
e- perhaps dynamic load from player items (chests, contents) to simulate necessity of sound construction of warehouses/ granaries/ factories 
f- refactoring, refactoring, refactoring. But the system seems to work in singleplayer so far.


The path to 0.6 is clear and paved with physically correctly simulated construction blocks.

Belen

sure, i can explain no problem. So vanilla Vintage Story has an instability system for rock. It's what creates cave ins, if you mine and disturb rock, and the rock cave roof above you has instability. The logic of that system is defined in unstablerock.cs and a bunch of other .cs files, that you can find on the vintage story github, and somewhat sparingly documented on the apidocs.vintagestory.at documentation site. Vintage Story is part open source, so it follows other open source projects' general formatting: code on github, dev comments in the code, documentation on a separate site or in .md files on the same github. The github is also where you go, if you wanna clone the mod template you would be using when setting up a visual studio suite for modding not only json files, but also .cs code.

Anyway this stuff then gets compiled into a .dll which you can find in the Vintage Story game folder and explore with ILSpy. In those game files is where some of the proprietary Anego Studios code resides, basically what they've spent years making and therefore don't want to necessarily disclose (intellectual property) and what you pay for, product-wise. At least as far as I understand.

But the instability system is fully disclosed, and you can see it uses different values/variables to create the behavior of collapsing rock when unstable. These are maxsupportdistance (how far the rock supports horizontally if supported itself), collapsechance (how likely the rock is to collapse if neighboring block is removed or disturbed. This is what is creating U3er's open-door-collapses-blocks frustrations), and some other stuff related to falling sounds and fall damage from getting hit by that block. The system ALSO uses something akin to a so-called BFS flood fill to discover through route tracing if a rock block is supported by stable rock blocks or not, as far as I remember by checking how far the rock is from 4 vertical consecutive rock blocks (an anchor), while checking how supported it is by neighboring blocks' maxsupportdistance.

CollapseStory 0.5's model uses maxsupportdistance and collapsechance along with my own new variables, and inverts the direction of stability. The vanilla model has no concept of instability increasing vertically upwards, and does not work on anything but rock blocks. These variables are Loadcap (how tall a certain blocktype of a certain material can rise vertically before accruing instability) and InstabilityPerBlock (how much extra instability each certain vertical or horizontal block of a certain material placed in a pillar or construction adds). These are added together in different calculations and checks+gates to simulate instability for construction.

The system ALSO applies a Dijsktra algorithm, instead of BFS. It does this because Dijkstra is cost-aware, can handle different blocks having different final sum instability values, and tries to find the LOWEST COST route to the ground anchor, where BFS treats all blocks the same and just finds the shortest route. This is because the BFS-enabled cave-in system is a primitive system that only needs to emulate cave-ins, not player construction.

Now for the material part. The material affecting the block type (sandstone material weaker than granite) is partly inspired by how the Vintage Story devs have applied a three-tier system to the strength of rocks in the cave-in system (can be seen in the rock.json found in the survival version folder in the game directory tree on your disk. In that vanilla system, sandstone collapses more easily than granite.

That idea I then take and apply to all constructed blocks in a general scale going from rammed earth all the way up to riveted steel blocks.

Finally, the support beam absolute hell.

Support beams are defined in many different .cs files in vanilla vintage story, almost all of them available on the github (just search for "beam" or "supportbeam"). But the actual implementation is very primitive in the current game version. Support beams are basically two points that teleport stability between a hanging vertical rock block and a nested, stable rock block at some ground level. The beam span itself is just a graphical gimmick currently. There is a collbox only at one of the two points. The player becomes extremely confused since 1) they can't find the collbox to remove the beam, 2) beams dont propagate stability when placed horizontally on a ceiling, 3) if the player places the beam on the horizontal facing of something, the whole transmitted instability calculation becomes janky. This effectively means the support beam is currently used in 99% of cases mostly for building cosmetics. That's of course absurd and a bit sad, there is the foundation for something great, especially if redesigned alongside an actual construction engineering system.

I have actually succeeded in circumventing this in CollapseStory, by implementing lots of conditionals and gates, to make for example horizontal beams work. But it was a really big pain. 

So, now I'm trying to make an actual physical model work, that uses real construction engineering values, in a voxel game. That is no small challenge. There is a whole game, Medieval engineers, that didn't succeed in finding a decent working model for simulating this in voxel games. The main challenge is figuring out how to simulate diagonals in 3d space in a voxel game, which is in effect bounded by a mesh of nodes, where you can only place what equates to a 1 cubic metre block of some type and material either horizontally or vertically.

If I get it to work, I would effectively have solved tons of problems, and I can implement a much nicer and easier version of instability (which would become real physics variables summing in a block's "stress"), and of support beam functionality in that new model. 

But it is clear the main challenge is to somehow model diagonality on a voxel 3d space, it's the current bottleneck in my coding. System works fine horizontally and vertically, but the necessity of gates and conditionals reappears when trying to make it work on "voxel diagonals" (meaning constructions moving diagonally or angled based on one-step-horizontal, then one-step-vertical, then one-step-horizontal ad nauseam). 

In construction engineering, this would be called eccentricity : the angled line of some construction applying an effect to a structural center.If the line is perfect (e.g the pillar ist 90* vertical), there's no eccentricity. If the line is angled (an unfinished arch), the distance between the angling and the center is the eccentricity value.

Through this, bending is applied. If there was no eccentricity, only crushing would be applied, and simulating real construction in voxel space would be easy peasy. But bco eccentricity and bending, you suddenly have a setup where you have to model diagonality and angling on horizontal and vertical steps that literally only go sideways or up-down. NOT. EASY.

This is why most games with some construction suite actually cheat, and ONLY apply crushing on set blocks, by calculating additively increased "instability", and they also often only apply that to the endpoint, not the actual block in the construction that receives the crushing, earlier down in the construction.

Arches are a good example: already arches are in fact working in this system, since it's logic is based on real world construction physics. But by introducing arches, I now need to figure out how to solve the issue that is, that if I place blocks on top of an arch's keystone, the stress ends up on the keystone itself, but not on the voussoirs, imposts or abutments. And so on.

Now I THINK the system will work given time with me working on it. But if I can't resolve the issue of applying real world diagonality and angling in a voxel game, I can always fall back to Dijkstra, remove the janky foundation feature and implement a flood-fill of some kind to anchor constructed blocks to ground via a scan across other constructed blocks, and then call it a day, here you go, a partly-simulated IRL construction mod. But lets hope it does not come to that.

Edit: HMMMmmmmm. Maybe if I reverse engineer chiseling, then each "cubic meter of block"/ single node in a cube actually becomes a blocktype and material cubic meter consisting of lots of tiny points, through which thrust and angle can actually be traced. Although the compute would probably be ridiculous.

Edit2" scratch the eccentricity thing, i was apparently talking out my ass, after researching some more that's for calculating bending stress on verticals hitting a foundation vertical off its horizontal geometric center, meaningless in a voxel block context. But I have found the actual equation that correctly combines crush, buckle and bending in a summed stress value, so hopefully now it's mostly a code question of making all blocks transmit, receive and read/update that value in a full construction.

Out of curiosity, when you say you are ditching the vanilla instability system entirely, what exactly does that mean?

U3er hey , I did disclaim it was an alpha XD

But yes, the model doesn't fit the business case. I'm surprised building a simple house with granite ashlar is difficult, but I totally understand every block with > 0 instability getting collapse chance rolled on a door opening is totally unsustainable.

Your feedback has been determining in me ditching dijkstra. Another conditional solution would be to make my affected blocks only chance collapsing above, say 50% instability. But it would be another patch on an unfitting model. The next model will take a bit longer but will simulate much better, will point progressively to the actual block under stress, not just furthest from ground, and will only trigger collapse on 100% stress or some similar predictable, understandable cap. Dijkstra was the best approximation using the vanilla unstablerock system, but it's insufficient. See you then after the upload.

edit: well that was easier than expected, quick dummy setup after coming back from vacay using some, supposedly, IRL values;

• weight/mass, tension strength vs cohesion (fibres vs. mortar vs. wet clay) horizontally, slenderness sensitivty (how isolated it can act vertically upwards).
• Differentiation, so for example if you place a 4 block tall granite cobblestone pillar, then continue the pillar with kapok planks until collapse, the column will collapse at the lowest kapok plank block in the pillar, NOT at the granite cobblestone lowest block, so the granite cobblestone part of the pillar remains standing after collapse of the upper "story/floor" abstraction, since why would it collapse in this model, it's much stronger and under much lighter weight pressure above from the kapok wood. NEAT! 
• Stability anchoring on ground is based on a flood fill detection of 50 ground blocks, with rock/soil/gravel/sand giving small-differences different stability. This should solve all cellar, ground floor, foundation and deep pillar issues, they're naturally solved by the model. The flood fill also means if you accidentally build right on top of an undiscovered cave, your structure becomes more unstable (well mathematically, it won't cause a cave ceiling collapse, in practice I will probably need to set some conditions to emulate cave-ceiling-then-floor-collapse somehow in interaction between vanilla and mod systems. Could be hella cool tho.)
• No collapse before most-stressed block equal to or below 0% stability.
• Tooltip based on redoing the exact calculation client-side, so no server 2x performance hit or new, suspicious network ports or packets.
  
  Now it's just a slog to find the right values for all the blocks and materials (cantilevers currently fall on first block in most cases), and then making support beams work (which should be simpler in this model). But very promising. I should have gone direct to establishing a completely separate system from the start. Oh well. 

(weird sepia is just from reducing the amount of colors so you can upload pngs under the vintage story forum KB limit)

i have been using granite ashlar, pine logs, and oak planks.  Using granite ashlar for all foundations and house frame ( at least the vertical parts, tend to use logs for horizontal parts, wood planks and such for the walls and flooring. 
But I've turned off the mod for now though because the instability is too inconsistent to work with right now without pulling my hair out, at this point I just need a house that isn't collapsing around me even with excessive support beam bracing. lol  Though I'm still trying to build according to the expected behaviors and parimeters of this mod since it looks like you have something far more intuitive and stable in the works and I like how the limitations make your builds look.  But I'm mostly doing so in the hope that when the mod is more refined and I turn it back on my house doesn't immedietly collapse lol

@HumanCarrion but why tho :')

I've found a solution though. I implemented dijsktra as compromise between realism and performance.

But looking at a new model I'm thinking on, thrusttrace, turns out i can model ACTUAL loadbearing, mass, weight, buckling, horizontal vectoring (arches), that is ACTUALLY 1000x more efficient than dijkstra with its tons of conditions and Gates. The only conditionals i would have to deal with would be loops in domes and similar. At least I think. Deep pillars and cellars are naturally integrated, wood has natural much higher tension strength (natural beams) but stone naturally much mor loadbearing mass.

Sandstone and granite can use real values (sandstone actually only 20-40% weaker), and the actual big difference can be relegated to how fast sandstone degrades compared to granite, in the 0.9/ 1.0 degradation feature.

I'm basically just ditching the vanilla instability system entirely.

Exciting!

But i guess i could make a non hardcore setting in the config too

In any case, the whole system would become much more intuitive and bug/ edge case free for you guys.

oh and can you please add a config option to make blocks of different material (like the sandstone and granite coblestone for example) have the same stability 

@U3er hm it could be neither poor design nor bugs, but simply instability being set too high on a specific blocktype and material. What bl8cks and materials are you using? Ashlar very good, sandstone ashlar bad, granite ashlar very good.

Re. Doors: that's very interesting. It means base vanilla code sets opening or closing a door as something that triggers a check/ roll for collapse chance. I hadn't spotted this, since I didn't want to integrate doors before i had fixed not being able to place them on a beam collbox (in a doorframe)

Re.: scan 16 deep horizontally scanning for 3 consecutive soil blocks is probably too restrictive. It was a compromise between efficiency, exploit mitigation, and realism. The engine limitation I'm trying to work around is VS soil blocks dont have instability, so there's only two states to work with for structural block foundations, grounded = true or false. No "foundation stable to x %"

"Like if I'm building a cellar underneath my house, and one side of the foundation only has a block or two or of dirt in between it and the cellar walls, does it cancel out the integrity boost, or does it just subtract from it a little depending on how much dirt it's not detecting on one of its sides?"

I'm not sure I completely understand the example, but one block deep gives a small bonus for a pillar, one horizontal neighbor foundation block embedded in ground gives more, two = more, three = more, four = most.

No current discerning between rock and soil.

Documentation will come with 0.6, so you're not left totally alone with trying to figure out what's going on.

 I'm considering just modelling as realistic as possible, screw efficiency and performance, get the models right and then just downscale to hit acceptable multiplayer performance. That approach would solve most of your issues, but that's long term.

Edit: sorry brainfart. Yes two soil blocks is too low to give "foundation" In one direction, re the scan explained above. But the foundation only starts from being surrounded by soil-> having a neighbor surrounded by soil on 3 faces. In your cellar try placing some horisontal braces inside the soil, behind the wall, to trigger foundation bonus.

But what you're actually pointing to creating the new instability is me removing or nerfing blocks being grounded horizontally and then getting a separate bonus by simply touching soil. I believe I removed that to again avoid exploiting (make a structure infinitely tall by beaming dirt next to it). I didn't implement a soil depth scan out of performance concerns. It's a real issue and why many servers play with soil instability off, but agqin maybe i should just say screw it, implement a best off design, then refactor downwards to a sweet spot performance wise.

I don't know how much to assign to either poor design or bugs, but I've been struggling to build a solid foundation for my "2nd" rebuild of my entire house after updating this mod and finding that my old house is completely in incompatible with the new changes as it gradually begins to collapse. 

But right now I have been having trouble with doors, where opening them causes all the blocks around them to have a chance of collapsing if there's even a fraction of instability.  Even Stone, and I've been using ashlar blocks. 

Also, I'm assuming if I dig my foundation into Stone it will work even better than if I dug it into dirt. But my real question is in regard to how much the surrounding dirt adds to the foundations integrity. 

So I see it checks to see if there's dirt blocks on all four sides at least three blocks out to determine a strong foundation. 

Is this a requirement? Like if I'm building a cellar underneath my house, and one side of the foundation only has a block or two or of dirt in between it and the cellar walls, does it cancel out the integrity boost, or does it just subtract from it a little depending on how much dirt it's not detecting on one of its sides?

Ryumachinae hey man are you getting angry? Perhaps English is your second language, but you appear, propably unintentionally, angry and frustrated, and it's not really conducive to other people answering your comments, just fyi. It's a free mod in development on a (at least aesthetically) cozy survival game, no need to get knickers in twists :)

1) wood blocks : As I've said many times, wood will have it's own unique differentiation, it's just not implemented yet. The mod is 1600 lines of code and v0.5.1, so for that you will just have to wait. Also do you actually read what I write in comments and in the mod description? Functionally that is not a loadbearing block you've placed. That's a freehanging log block, hanging from the ceiling? To get loadbearing on that, just place a horizontal beam under it from and to the two pillars?

2) you are free to make your own values using my now implemented public constants, but this is a hardcore mod, it's intent is to gap your construction behind tech tiers. If you are messing in the jsons, be aware those only change the default (highest) tier of material. But already, you can easily build 3-4 blocks high with rammed earth, if you make proper foundations and some beams to support. You are also free to report test results here, but I won't be clicking external links, and I can't recommend people doing the same.

3) the reason fence adds instability in that context is partly because of me changing fence values to suit you yourself, probably making them OP, and then the Dijkstra route probably going the shortest route to ground, through the fence, and then ending with that instability column, again bc this is v0.5.1, an alpha. I'll note down your comment as a report to lock at the structneighbors calculation and reassess the additive stability from horizontal neighbor blocks and their immediate vertical downward block (the two blocks adding stability thru structneighbours).

I am messing with the values on my own, but in general I am getting outcomes far more in line to what I expect. essentially, I have normalized values based on material used, but overall the collapse chances and instability added values have all come DOWN significantly, try it out if you feel like this current version is too much https://mega.nz/file/g5R0ARzB#SpIpeSHA3D7X5f70eAyAEuh5TWVkagMQalbRuoP1gNs

Stability is very messed up and unintuitive now, when i set up full wood blocks I expect them to be a LOT more stable then they are. That center log is VERY clearly designed to be load-bearing, yet it itself has 64% stability??? look at ALL of the work I have to do to keep a single floor stable. IMHO you need to rethink how this works becaus this is absolutely excessive, I dont think the percentage based system works well for structures at all.

How is it when tehres nothing under this log theres no instability, but when i put a fence udner it instability is ADDED?? I am expecting it to do the exact opposite here.

Hope you have a good break!

Belen uploaded a v0.5.1 with the fix, will be a bit before v0.6 bco holidays.

No problem!

Belen

allright got it fixed, via a farther X Z soil scan around a foundation checking for more than just one soil block in the given axis. 

But then I waded into trying to give additional stability from deeper foundations, which kinda works, but only if the deeper part of the pillar is surrounded by soil (rip cellars giving stability to walls above).

I'll go back to just the gate at the first horizontal foundation embedded in a substantial soil layer.

I'll add your bug to the list on the page and put "fixed in v0.6", thx for the help

Belen

thank you for such an exhaustive bug report! A+ 

Yup that's the dijkstra routing into a foundation thinking it's not a foundation bug. Currently working on it. In your example, it's reading into your ground nested block two y levels down, and then thinks it's further above ground than it is. It is one of many issues with using the Dijkstra algorithm, but can be gated, in ever increasing complex ways, hence why Im considering going back to just simpler valheimy geometric calculation at a later point, and just deal with support beams in that calculation environment.

I think this is a bug.

For some reason, when I have two building blocks down, with one acting as a foundation, and then place a door next to it, it then gains instability for some reason.

If I just place one block down one the surface and place a door next to it, it loses no stability.

Link to image showing this.

Belen Thanks! Yeah, it's great fun to make. It IS basically barebones feature complete, so luckily there's no more "try", the rest of the work is just fixing bugs and slapping on increased functionality and compatches, and finally finding the correct values for each block and material, that matches reality and good gameplay. Which can take a long time though.

First of all, much of your confusion stems from me not reaching a state, before now with v.0.5 really, where I could document and explain the stability calculations and modifiers on the modpage, since they weren't implemented yet. But I'll write better documentation going forward.

There's a short explanation of loadcap, if you open your handbook, go to guides, then select collapsestory guide. It means how tall a pillar of a specific block and material can be raised, before instability starts accruing. The instability itself accrues according to blocktype and material as well (basically the blocktype and material is a modifier on how much increased instability is added everytime you place a cantilever or vertical block, or vice versa how much stability is added to the side and upward, if the block is placed in a somewhat stable position in the structure.) This also means you can combine materials, for example an early farmhouse could be cobblestone granite, then wood or daub, dependent on material availability. Bracing that farmhouse with beams will then also add stability to the structure.

Re.: foundations : that's one of the videos above: if you place the foundation in a line or cross section (- or +) in the ground, under the pillar, it receives more stability. But currently half of that stability is canceled out, if it's part of a wall, and not a lone pillar. That's the thing I explained about one calculation gating out another, in my first reply. That gate hasn't been fixed yet, since this is an alpha release, and yes it's that bug you're mentioning, I just haven't listed it yet, since it is actually a bug I fixed, but that got reintroduced later (lots of those cause of the nature of the dijkstra algoritm I'm using).

For the beams, you are also lacking documentation, since I haven't written it yet here on the modpage, or in guide sections. But you take one beam, then you start it at the block, you want to support, then you drag it to the ground. If you hold down shift when placing either end, the beam will "stick" automatically to the highlighted block. Place it either vertical or angled. For a rammed earth block on top of a rammed earth block, with no foundation, that would give the top rammed earth block 50% instability without a support beam, circa 37% with one stick beam. I say circa, because the final stab increased from the beam is also dependent on angle (45 degree or above). You can place another beam and reduce the instability to 29%, and so on. But beams have diminishing returns, so the first gives the most stability. 

But the beam has to go between the block you want to support, and then ground (soil for example). Only for later, in much taller constructions with better beams, blocks and material will you be able to transmit some stability from blocks lower in the construction to blocks higher.

If you placed foundations underneath, that stability increases even further. If you place the hut up against a dirt or rock hill, the general structure will also receive increased stability, since being grounded will propagate through the blocks neighboring the soil or rock blocks.

But using rammed earth and stick beams, the lowest tech, you will never be able to get enough stability to move above one floor of two blocks height. You can roof that floor with thatch or whatever without problem though, also since I haven't modded instability unto roof blocks yet (still thinking about how roof will have unique qualities, and for what purpose. This also means you can make a block stable currently, but just putting a roof block on top of it :D ). 

Then, finally, if you place a horizontal beam (has to be completely horizontal) between two pillars, you can place blocks, also rammed earth, on top of that beam, and they will be stable. But only the first blocks directly on the beam. This is for doorways and so on. If you want to place a door, currently there is an engine limitation in that you cannot place a door on top of a beam's collisionbox. I recommend dragging the beam from the other side of where you want to place the door, and through, in such cases, until I find a solution, probably involving some kind of ray tracing shenanigans.

If you want to experiment with design, I propose you try out writing /tm c in chat, then press F3 . That puts you in flying creative mode, and when you open your inventory, a magic box appears where you can select and grab one of every block in the game. When you are done experimenting, just write /tm s in chat and you are back in survival mode :)

Edit: also, forgot. Sticks are, well, sticks. Don't count on them for much constructing, beside horizontal lintel stuff, roofing off open areas or lifting light construction off gorund, and then a handful of percent extra stability for blocks. For sound construction in a pre-metal industry era, get your hands on maple, oak or walnut, or, best of all, ebony or purpleheart, and make beams from those woodtypes. 

DreamEater I have a few questions:

What do you mean by loadcap?

I don't notice I difference in the stability when embedding the blocks into the ground for the foundation. Actually I do, but only sometimes? It doesn't work if I do it as a lone pillar. Might have something to do with the bug you were talking about.

How do you put the beams on the wall to stablize it without it falling before you can do so? I am just putting vertical pillars on everyblock, but I don't know if that is the best way to do that.

Also, thanks for responding and I love what this mod is trying to do!

Belen hmm well, to nerf the can-build-house-immediately-on-spawning-in packed dirt behavior, pdirt is now fallsideways (it's unstable, also to the sides). This then moves the immediate-house-on-spawning behavior unto rammed earth, since rammed earth doesn't require neither sand nor clay. Since rammed earth is so cheap, you have to nerf it in some ways, including very low stability, here it's 1) loadcap before gaining stability set to one, and 2) then also my introduction of needing at least a flint axe to make roughhewn fences for the framing of rammed earth, and flint shovel to compact the packed dirt in the frame into rammed earth.

But building foundations (meaning the wall is embedded in the ground one block deep and that block has "foundation" player made and placed blocks neighboring it) will in fact increase the second y level rammed earth block's stability, so it ends up with 3% instability. And reinforcing the 2nd y level blocks with STICK beams, which are made of firewood (flint axe), (flint) knife and rope, you actually end up with 2nd y level 0% instability, and the 3rd y level rammed earth blocks have something like 30-40 instability i think, you can then strengthen further with stick beams unto that y level or unto the pillar blocks below. You can also place a structural block (e.g more rammed earth on the outer side of the wall, so the wall becomes a right triangle, increasing the 3rd y level block to below 15-20% stability. But then further vertical rammed earth construction is then capped off by diminishing returns, unless you choose to apply more advanced beams.

Effectively creating a mini-puzzle gameplay loop, if you wanna build without clay.

This ultra-strengthening is currently hampered a bit though in that the different dijkstra routes-to-ground and foundation calculation cancels each other out (one part ends up gating another part's check-for-foundation), so in a wall of more structural blocks with foundations, a rammed earth block in that wall at y level 2 ends up with 34% instability, instead of the lone pillar's 3%. That will get fixed at some point though, along with packed dirt needing to be recognized as a foundation block as well (not hay and straw tho).

Finally, if it still proves too weak, I can always either reduce the instabilityperblock (per block placed vertically upwards), the collapse chance or finally increase the loadcap by 1. But the best approach would probably be just reducing IPB.

What is the point of rammed earth if it can only go 1 high? At early stages, you don't have access to beams, so really can't build 2 high.

Sylvaris thx for the question! Yeah the interest for that specific feature has been noticeable in the comments thread, so I'll try at some point, when I reach v0.8 or v0.9. Currently the priority is ; arch buttressing; handbook specific block strength details; vanilla roof system; wood distinct diversification system/ figuring out nice log diversification (someone mentioned increased strength of the discrete log block if all the log faces were placed so the log blocks look graphically x blocks long in one single log, a good idea); compatching to wilderlands, roof mod etc; in-mod scaffolding; deterioration over time; brainstorm on choice of math algorithm (is it truly impossible to apply a simpler, more valheimy math model while still keeping VS support beams, on the full feature end state); refactoring for multiplayer.

Regarding deterioration:

First I was looking at setting default reinforcement values from the vanilla reinforcement system at player placement of blocks, and then use the system to state the condition of the block, and then decreasing reinforcement values as ticks over time = degradation, and then at some reinforcement level, possibly 0, replace with damaged block version, and when that ticks to 0 reinforcement = collapse. But that system is built around player ownership of specific blocks on reinforcement, since it was designed for multiplayer PVP stuff, so it wasn't nearly as plug-inable as I thought, when I looked at it a few days ago. If it wasn't for that fact, the system would be DIRECTLY translatable to a deterioration model = each block has default reinforcement according to type and material -> player can reinforce further with a plumb-and-square, this can also increase the stability of the block -> block deteriorates -> player repairs with plumb-and-square. But the vanilla setting of block ownership on player plumb-and-square use means that if I were to use that system, I would have to either disable the vanilla system, or patch a route for it, maybe a lock-and-key version of the plumb-and-square, that the player then has to use to actually apply the vanilla system on specific blocks, otherwise reinforcement values are general. And finally also correct for reinforcement not requiring a player to break every single block up to 1200 times (the value for a steel reinforced block), if they wanna move or remove their reinforced block.

Patching the vanilla reinforcement system is perfectly doable, but rn seems very complicated, and how much compute overhead and bug exposure are you introducing, and so on.

Using the cementation furnace model, as far as I understand it, it is not applicaple to deterioration really, since it's either or chance based replacement of one block with another on every single use of the furnace. The only thing that scales unto something like natural deterioration over time naturally is the plumb-and-square reinforcement system, if it wasn't for the whole player ownership thing.

TBH wasn't aware of immersive weathering at all, never played minecraft (my modding ventures previously has been in rimworld, barotrauma and a smidge of Project Zomboid). I'll look into how they do it.

If you have any further ideas of the degradation system to implement, be sure to let me know! Haven't actually looked much into the code of the furnace thing.

edit: hmm technically stripping the reinforcement system of having to place player UIDs on every reinforced block would probably give a server performance increase. But then again, I have no idea if server maintenance of these block registry/ dictionary values are actually even that much of a drain.

I noticed that in the future features you mentioned block degredation, would this be similar to how the cementation furnace's bricks degrade? Or would it be more similar to Immersive Weathering from ThatOtherBlockGame™? I'm very excited to see how this mod progresses! It'd make for great stories and battes on servers.

Ryumachinae 

hmm you sure, it still does that? It was my visual studio again, forcing json content according to template, but the last file I put up should have the "dependency = 1.2.2.0" removed. Let me know if not.

the newest build isnt working says it requires 1.22.0 which doesnt exist yet

Ryumachinae uh im not disagreeing on the values needing a pass, im trying to find the good balance :) So, if you could help me with this. Would half the inherent stability of the parent block and material default be more intuitive? How would that feel, do you think?
Regarding wattle, yes I understand, ideally I would have the degradation system already in place, so wattle would just be very weak over time, but I'm just a dude, and getting a working gravity simulation in place over one week's (although sometimes intensive) work in my free time is actually already pretty uh unexpected.

So, wattle is going to be nerfed somehow in this mod, that is not going to change. But I agree maybe it should only be nerfed up to and above 2 or 3 blocks high, not 1. This can be easily introduced by me just adding 1 extra loadcap to the json, this would mean instability only starts 1 block later. But this would also mean you can place stone blocks on top of a wattle stick up to a pretty unrealistic height. Anyhoo I'll be sure to look into a solution for v0.5

edit: ok I see now. Instability transmission to both anchor block columns from a horizontal beam is back. That's a bug probably compounding the already existing problem of you trying to place fences on beams without them collapsing from too low inherent stability. It was fixed earlier but probably got reintroduced while I was fixing block placement on beam span without falling (the beam movement between anchor points). It will be fixed in v0.5 along with the fence value pass.

the thing is if i have a 3x3 wall area surrounded by full wood blocks, i expect to be able to place any kind of fencing there easily and for it to not only be stable but to provide stability as a whole. Fencing is not the same as stacking dirt blocks on top of each other, its implied the fencing material is INTER locked. that implies stability. I would re-evalue what you're trying to deny someone doing with fencing, IRL wattle fencing can be quite tall and stable, id reccomend looking up videos. Not to mention if it isnt stable, how do you expect people to make daub walls?

Perfect, exactly the kind of feedback I'm looking for, thank you!

RockSowe

• Different stability values : yes, wood has different value according to material, and possibly type of block (fence vs. full block for example). I will add the different steps of the calculation on the mod page, for player reference, at some point. Reason I haven't so far is, it's simply so long, type and material defines the starting sum in 4 values which are then used across 6 steps in a logic chain with 21 equations/ functions. But equations set aside, these end result values for wood might be unrealistic and unintuitive, so if one specific type or material feels wrong, be sure to let me know!
• plank block interaction w stone block foundations : Hmm i can't reproduce the behavior. I tested with pine plank blocks on ashlar cross foundation nested in ground, pine plank blocks on ashlar block on gravel, pine plank blocks on ashlar block on ashlar cross foundation and line foundation, and the stability values in the pillar behaved nicely and according to expected estimates. Are there any other elements involved either directly attaching or nearby and/or is this construction repeated over the same spot? My guess would be either 1) interaction from the support beam ghost collbox bug, which is fixed in v0.5 or 2) one of the lower elements in the first construction is horizontally facing another soil/rock/playermade block, which would transmit increased stability logically, but other than that I have no intuitions? Can you tell me exactly the layout and elements of the structures?
• ashlar columns topped w. oak planks, 2% vs 29% instability. The one oak block with 29% instability would then be the 7th block on the column of GRANITE/ ceiling default material tier ashlar, otherwise totally isolated from any other construction, calculation wise. I cannot reproduce the other block's 2% in testing over several trials. My bet is either 1) again that a beam has supported the second column at one point, and then has been removed, and then the ghost collbox remains, adding stability, it would match a stainless steel beam having been removed, or 2) your column is in fact not 7 blocks tall, but 8, with one foundation 8th block nested in ground and a neighboring foundation block to it, with 1 soil block above ground next to the second block vertical from the foundation, which would also give 2% instability for the oak block. Is the second column exactly the same construction as the first and have you touched the second column in any way before it now being a single block isolated column with an oak top block with 2% instability? Are you using full plank blocks for the oak on the second pillar or something else?

Ryumachinae

• Yes, that is something I need help with and lots of data on. In vanilla, if you were resource restricted, you just built wattle fences everywhere to both keep everything out and to get above ground. With more advanced fencing, you just fenced off your whole base easily from enemies and animals. This is ofc extremely unrealistic if we use medieval construction reality as analogue, there fences that were more than one or two meters tall would fall quickly over time, also the reason we still have lots of dryrock or cobble half to one meter thick fencing still standing around our countryside today, from that time, the "blocks" didnt fall over so you placed blocks instead of wood fencing. So in the mod, fences are made very unstable, so you can't achieve the same effect nearly as easily, and fences cannot become the basis of any taller structural foundation. Essentially you can only build them one block high, unless you build more stable structures either at their endpoint, or by support beaming them horizontally at each vertical block cross-section, since they then rest on the beam. But in my replication of your report, I can see that not even with a beam underneath them do they go below 100% instability on the second vertical level, so you are completely right, I need to pass over fence values. This is good, because I am actually starting to run out of things to do in 0.5, now the ghost beam collbox is fixed and the baseline functionality is working (outside of, as in your report example, easily changed values possibly being all over the place). So thanks for the report, fence values definetely need re-evaluation.

Im experiencing weird behaviour with fencing, i feel like it should be a lot more stable, especially the plank types. Planks imply theres atleat a lot of nail-less fitting going on, you can get very stable wooden structures that way. But fencing will often collapse THROUGH blocks for whatever reason.

Okay yeah fencing introduces an ABSURD amount of instability on what are otherwise stable structures, I cannt use them for walls even with full blocks and beams for support which is ridiculous.

Noticed Inconsistnecy with wooden planks in general:
I have noticed that different wodden plank types have diffrent stability values, this seems to be intended behavior and is not what I'm talking about.

Certain types of wooden planks interact counterintuitively with stone foundations, becoming significantly more unstable than even rammed earth when placed atop ashlar brick. Specifically tested Granite and Pine. Is this inteded behavior?

similarly, I have two identical collumns of ashlar, placed on naturally generated soil, topped with oak planks and one has 2% instability while the other has 29% instability. Is there an explanation for this?

All tests on version 0.4

Algernon woow thx man, high praise coming from you! Be aware though, in chaotic conditions, broken beams still leave ghost blocks in air bco of, my current hypothesis, race conditions and rerendering after breaking. But it will get sorted at some point before 1.0!

edit: tehtelev had the fix! all hail. The bugfix will be implemented in 0.5.

Must have mod from now on, should be in vanilla

RockSowe the direct documentation? Why not just fire up ILspy and look in the dll/ extract the .cs and look in VScode or notepad (though can't promise it looks pretty, stone tier is formatted differently than the other tiers for example, and probably remnants from the old model in there too)? The calculation itself is straightforward, each type has a separate value (rammed earth to riveted metal) + material used on the types that can have different materials (mudbrick to metal). That's applied to both blocktype and beamtype (stick(though that one only has a default value)/wood/metal). The default that is then affected by the material is usually the ceiling. If you mean in the handbook, I just haven't had the time to make specific entries for each type + material, given it's lower priority than actually fixing and bugsquashing the main intended functionality (pseudogravity in all progressively discovered player edge cases). The value from that calculation is then fired into the other calculations for stability along with vanilla maxSupportDistance, collapsechance etc, and my own LoadCap and InstabilityPerBlock (applied in order to achieve progressive upward vertical instability).

re: support beams, if angled, then no it's not intendended (and currently corrected in the 0.4 draft version), if horizontal, then yes, and yes the bug is known. The problem is, VS' beam system is a slapped on feature, not well-designed, so it only works vertically (designed to scan for 4 solid blocks beneath the endpoint of the beam = stability propagates to the upward end of the beam into the rock ceiling, and the beam span itself is literally only a graphical gimmick to avoid the player thinking this is just two points teleporting stability between them. In the unstablerock.cs code comments, Tyron himself is throwing expletives over the primitive functionality of the beams).

So if you want support beams to support load to blocks on a horizontal beam's span without start and endpoint propagating stability from one vertical column to another for no reason, you have to do shitloads of math functions. It worked in the old, math-wise more Valheimy model that I replaced with the more efficient Dijkstra algorithm in 0.3, but I didn't make the horizontal beams work in the new model, it was an oversight. But it's fixed now in my 0.4 draft, I just wanna get arch keystone buttressing to work or finally conclude that it doesn't work with Dijkstra before uploading 0.4. And on top of that, you have to figure out two extremely frustrating things: 1) How to make beams drop on anchor block removal or collapse without leaving ghost stability in the "dictionary" or memory of the node, so the stability and collisionbox of the now removed beam doesn't get reapplied to a new block placed in that node, and 2) how to allow placement of a block ontop of an existing support beam's collisionbox (engine limitation), so players can make doorframes and actually place doors in them without being blocked by the support beam's start point collisionbox anchored on the face of the doorframe either left or right upper block. Here I up until today actually also did another oversight in ignoring many efficient and powerful api calls one could make, in the vanilla VS code, and tried to make my own math for doing stuff instead.

This is an early alpha with quite complex math in it, so I hope you don't expect it to work more than 40-60% right now, at least not before I declare the above fixed in a logical and efficient way.

oneil thank you! and yeah I actually brainstormed deterioration a bit more at work today, the key really is to get it working properly in unloaded chunks too, in a multiplayer environment. But afaik that is not as hard as it sounds, the VS engine is a, how to say, "strong" engine, it's actually quite beautiful, so well done devs. 

re: One Roof mod, me too, but that will be a while unfortunately, CollapseStory is currently basically only 40% done and unpolished, so compatches is for later.

Could I ask for documentation on how the mod determines what blocks types are what stability?

edit:
Also support beams only work when directly under the block and not when it is between two blocks ] | [ is this intentional behavior?

Amazing mod idea that i think we were a lot to think about it. First real attempt, if you manage deterioration too without to much  lag, this could be epic i wish you the best ! One of the mod i would love to see compat with is One roof mod.

@everyone

good news, fixed the cantilever adding stability to parent column bug, the infinite stability above horizontal beams bug, and the angled beams buttressing walls. Beams buttressing a wall now adds stability much more aggressively (like 2-4 extra blocks height, depending on type and material of block and beam).

Will spend some more time before I upload 0.4 trying to get arch buttressing to work, might need to revert to a chunk/block-based model w both vertical and horizontal calculation subsystems instead of node based model (to get around having to mirror/double dijkstra routing around a keystone in an arch to identify symmetry, get around not being able to set a fixed 0 stability for blocks touching a horizontal beam but not the blocks directly above it without overcomplicated checks, making a beam ghost instability fix easier and stuff like that. dijkstra is a fastet route through nodes algorithm, doesn't account for surfaces and voxel world "pseudo angles"/ right triangle lego layouts, and hence more difficult to calculate stored beam anchor point to be removed, since it's not stored as on the face of the anchor block)

Mollycoddle not in my plans currently, but i might consider upping their block stability a bit, but the point of the mod is to kinda negate early early tech skyscrapers. Stick beams can support each block easily though, if you're thinking of roofs or primitive bridges of shorter length.

HumanCarrion sure thing, can't promise wood won't get some other unique quality, but horizontal bonus seems most likely

This is interesting, will logs get a bonus depending on block orientation (ie multiple log blocks placed so they align into 'one continous log' to simulate using entire felled trees as supports?

amazing
will be waiting for wood horizontal thing

abculatter_2 I'm familiar with IRG, it's excellent, but I won't have the time to compatch any mods until I get CollapseStory to a more stable, bug-free state. Hopefully that will be a matter of a few weeks rather than months tho. You are super welcome to report incompats with it here, much appreciated! But in principle the two systems shouldn't affect each other at all, his oregen pattern is in rock, naturally, and I don't touch rock at all, I only use the unstablerock.cs behaviors, independently from rock blocks. 

U3er huh, interesting, well might be a really easy update then when 1.22 releases! and yeah it's super fun w. the instability, makes building much more interesting! Originally i think I got the need for construction "gravity" in VS from Dune, since it has a similar, but much simpler, constraint. And yeah, as in many other aspects of stuff, constraints in building lead to more creativity and often more aesthetics.

Salima allright, well lemme know if u need or want to report anything else at a later point :)

Ryumachinae hah, well yeah I honestly thought I had disclaimed that pretty well in the mod description and the in-game introduction guide, but maybe not, so; as much feedback as possible on bugs and stuff! If you can describe the bugs here in the comments field, context, behavior, mod version, game version etc., perhaps with descriptive strings from the log files when possible, would be much appreciated and would speed up the process to 1.0.0 stable. I honestly wonder why I don't get these errors in my log files or on runtime, perhaps there's some verbose logging setting as of yet unknown to me.

There are still similar errors as the one i mentioned previously, did you need help finding them?

nevermind, figured it out, something weird on my end

Been playing with the mod in 1.22 and it's been working pretty well so far aside from a weird 17% stability on all quarter log corner pieces, regardless of adjacent supports.  Been also playing with the Wilderlands Block adjustments, though I had to go in and delete their soil jsons so it wouldn't break.  Your mod does basically something similar so hasn't affected my game.  Did all this mid save too, and boy-howdy was gutting my entire house to make it work hella fun...  Though I have a fully functioning cellar now and the house looks 20 times better :D

Was wondering, have you done any testing with Interesting Ore Gen? That mod adds its own cave-in mechanics and is decently popular, it'd probably be worth looking into if you have time. If I get back into vintage story anytime soon I'll probably be playing with this mod and that one together and can report any issues I find.

Joyhop 

cool I had a look at the Valheim system via the fandom wiki. It works on MaxSupport, MinSupport, VerticalLoss/HorizontalLoss.

Just for understanding/ reference, "chunk" means the local matrix of the 3d grid in VS that blocks are placed into, which is loaded when players enter it/ are near it. The local local 1x1 position of what a block is placed into could be called a cell, but afaik VS devs don't use that terminology, so I use chunk as shorthand for that 1x1 grid position.

Valheim's system calculates stability in either X or Y axis separately (as in my old system, so this is inferior to Dijkstra's nodes applied unto VS' blocks) and then Pythagoras to calculate at angles (superior to my current system, but, as it would be applied in my system if so, also implemented in Valheim as a post-main-calculation-subsystem).

The final stability function is actually kinda similar to mine, but uses the different values, so the resultant support values and mechanics are ofc totally different.

It also calculates a summed support from all parents, accounted for degrees. That accounting is one of two places where the system seems more advanced/ closer to IRL than my modded system on top of VS' engine/ block based technology. The other place is in that you can place a block/building element in an unstable chunk position, and it only degrades unto breaking/falling after some ticks have passed, where in my system or in vanilla VS' cavein system, that only happens on checks for disturbance in neighboring blocks). The first accounting iof angles s interesting to me and I might check out if this could be applied to the mod, the last tick-degradation is not, as it seems to introduce something that is too inefficient compute-wise for too little positive gameplay impact.

Now for why VS' engine seems far, far superior for simulating construction to Valheim's on most other accounts, and hence with much more opportunity to create crazy mod functionality;

• The building "blocks" in Valheim seem way too large for sufficient detailing and simulation of IRL construction (or geography).
• The building blocks are not "part of" the geographic world, since the geographic world in Valheim is a big ground mesh (like, say, in Dune Awakening). This means that it will never get close to simulating the level of detail of a VS world, bco engine constraints, and also creates tons of exploit concerns (players can find ways under the mesh, also what happened in Dune Awakening).
• The building blocks only measure the distance to that mesh/ ground level in their stability calculation, which makes impossible any future implementation of the nature of the soil you are building on, and what effect that would have on the construction's stability (like say you can't implement a sub-ground level neighbor scan of the kinds of blocks x range beneath the construction to calculate a stability bonus or penalty to the construction's foundation blocks, since there are none in Valheim. So you can't model a building built on a sandpit being more unstable than one built on granite rock.
• In basement building, the 4 to 6x larger size of the equivalent to "blocks" in Valheim is also revealed, again an engine constraint on detail.

The graphical, colored pre-placement display looks nice, but that is in fact a separate system tacked onto the underlying building block system, and as such could be chosen to be feature-copied into CollapseStory at a later point in time, but I would again intuitively find that in the calculation of efficiency vs. positive gameplay impact, efficiency would probably win.

But the way they handle angles through Pythagoras does seem interesting, I'll keep that in mind going forward, could be an easy solution to both archway buttressing, cantilever stability without checks for air underneath and so on, so thanks for putting it on my radar :)

A last note: again the main limitation to VS construction wise seems to be the vanilla support beam system, that doesn't treat intermediate beam segments as blocks, and doesn't work horizontally, so seeing what a different system can do in Valheim becomes another argument for attempting to make a new support beam system at some point.

btw please excuse if my constant comment editing is creating tons of bells for you bco your tag, I'm using your commenting dialectically to think through things and note them here, to build logic chains as the next link pops up in my head, and so I don't forget them later.

Joyhop

thanks for the bug report! Seems I didn't correct the horizontal beam support application properly to match, when I switched to Dijkstra's algorithm (or possibly the original application was bugged and it transferred over). I've added it to the Known Bugs section, and it's an essential fix need, so I will fix it for 0.4.

I am aware of Valheim's system, but don't know what math it uses though, maybe I could look at how it works around horizontal support beams distributing and support load on top of it. I am currently pretty hyped about using Dijkstra's algo tho, since it seems like a very efficient way of emulating gravity, without trying to apply real 3d space calculations instead of uh i guess chunk/block-based 3d space. The problem is though, AFAIK Vintage Story support beams are vastly different from Valheim's, and I think I heard somewhere the devs themselves have stated that support beams were a slapped-on feature more than a fully integrated, well-designed one. So as in the game, in the modding of this mod, the support beams alone has taken up maybe 40% of the total time spent, lol. I'm considering just making a whole new system for the beams, but that's usually hell to integrate, since the original beam logic and all its references to other systems would still exist in vanilla.

- "The first block is 100% stable and the rest get progressively less stable. I dont think it possible to add this system into Vintage Story." Again, I don't know what math the Valheim devs use, but this mod IS an introduction of exactly that system into Vintage Story. The % instability is just % stability formulated inversely. Valheim's 10% stable would be CollapseStory's "Instability : 90%" (as seen in the mod thumbnail). You already have that functionality in VS with this mod right now, just lots of bugs to iron out/ code to slap on to correct for unknown or overlooked extension of functionality into all player use cases (e.g I introduce a subsystem to support beams so they function horizontally as well and carry blocks on top of the beam, not just at start and end point -> I forget to make the Dijkstra start tracing and calculating again from the blocks on top of the beam -> players/you report the bug -> I fix -> I upload new version -> players discover some new bug -> I fix -> repeat until 1.0.0 stable). 

The ruins falling apart is a feature, but an underground ruin cellar collapsing sounds weird, considering the rooms are so small, the blocks should be supported by their faces touching soil. I will not be patching for better ruins until a much later date, I'm still in alpha release stage lol.

Salima I unfortunately literally don't know what to do with your feedback? I would need more info, so I could replicate the bug. Where is it not doing anything, with which blocks in which environment, what tools etc., do you see error reports on runtime (saved in the server-main log found in /Logs in your roaming/vintagestorydata/ directory)?

El_Neuman aw thx man! And yes it will ofc be in 1.22, hopefully sooner rather than later. Honestly I don't even know if it would work right now on 1.22, it might, but 1.22 changes support beams a bit, which often also means new references or names for referenced stuff in the vanilla .cs and jsons.

Miunnak you're welcome! I took your 3 firewood recipe as a recipe template, lemme know if you feel 3 firewood AND rope AND knife durability hit is too much for one single stick beam, it might be.

not sure if i'm doing something wrong but i can't seem to get this mod to do anything?

DreamEater

For the ruins they fall apart whenever a block is broken/updated, otherwise they stay standing as generated. For example I broke a piece of cobweb and an entire underground ruin collapsed on me. Same thing happened on the surface with a regular ruin and with betterruins structures. Not sure if it would be possible to change this. Maybe somehow add a tag to items that enter the players inventory?

I did some quick testing and when a block was placed with a beam below it i was able to build to world height limit. The beams seem to break the instability system at the moment. The two pillars go up to world height.

Valheim has a degredation mechanic as well as a limited building mechanic. The first block is 100% stable and the rest get progressively less stable. I dont think it possible to add this system into Vintage Story. Quick link for a referene if you want to check it out :

Pictures for reference: https://imgur.com/a/DRvFPkV

With some more testing you can hide a beam within a block to give unlimited vertical support. Also chisel blocks act as 100% stable blocks. It may be hard to completely stop infinite height building.

Also maybe a glue mechanic with pitch glue or resin to increase block stability. Maybe a refining process to make really good glue applied to block with the crafting grid or with a chisel/brush?

There seems to be quite alot of interest in this mod. I'll keep more of my ideas off of here to avoid overload lol (engineer brain). Ultimately, make your mod to how you want it to be, you seem to have struck a golden idea with this one. Keep up the good work I love the concept.

Oooh that all sounds super cool :o

If you do get the degradation system going, it would be awesome if actual roof blocks protected the blocks under them. Outside of aesthetics, there is no current reason to use proper roof blocks

Wow, you added the beams, I don't have to use my own mod anymore lol, nice job.

@ArmoredStone I can't promise there is not some engine or compute-in-multiplayer limitation that will make it impossible to do, but I can promise that I will try at some point to create such a system.

In theory/ pseudo-code it would be easy:

1. You apply a default reinforcement value to all player placed blocks, then scale it to block tech via modifiers in c# or define them all in .jsons, excluding the ones you don't want the value to apply to.
2. You degrade the value w. ticks, either over time (least efficient probably), when temporal storms hit, or when it rains or whatever.
3. On value reaching 0, the block either breaks or, if you want to give the player a visual grace cue, you replace it with a damaged version, which then breaks via your chosen tick trigger.
4. The blocks can get repaired via plumb-and-stone
5. Enemies subtract reinforcement value from the blocks with attacks or proximity on their direct route to the player (curremt drifter/ animal AI constraint). Bowtorns could have subtypes that continually shoot at the player despite blocks in the way, with projectiles that explode on block-impact or somesuch.
6. Presto, you have the system, you want.

Also, I don't remember if I figured out this system myself just recently or if Thalius brainstormed it at some point when I was a wilderlands tester, so he or others might already be working on such a system, since the theoretical implementation is pretty straightforward.

Phenomenal mod! I hope it will be on 1.22!

Now I just need some kind of mod that lets drifters break blocks to get to me. Tower defense is so close! 😁

Dream this is one of the mods I have been dying for since I started playing. Thank you so much for making it!

I do have one request for the future. You mentioned a degradation system. I would love an upkeep system like in Rust. And the option to allow decorative, non-important blocks to never degrade (decorating takes forever)

U3er good news, I was somewhat recently a tester on the wilderlands frostbound server, and totally agree with Thalius' vision, so there will definetely be a patch for it at some point. And yes, that whole structure would probably be unsustainable when you activate the mod lol.

Ryumachinae great, thank you! I have absolutely no idea why i don't get errors myself at runtime, but mossybrick is actually located in the /stonebrick folder of vanilla VS, not the /clay folder (to which I called it in my jsons), so I guess I at one point just assumed it was clay brick not ashlar (stonebrick). So that will get fixed next upload, which is coming up shortly. I've added a handbook section too that generally explains the stability values, but direct handbook calls on the specific block will come later, as I've been modding it like a lunatic the last 3 evenings, just spent 30 minutes on a missing comma, and I have to go eat now lol.

I will be following this closely.. I was just thinking how obsurd it was that so many weak building materals like dirt and hay could be used to build single block width towers to the sky.  Especially when I got my first bear kill by building a dirt tower underneath me when I got cornered and now the thousand pound bear was completely helpless against my dirt magic.  Felt so guilty for the cheese kill I just left it there lol.
But ill need to wait till this is made compatible with wilderlands Block adjustments since I have that installed
I also will need to preemptively place support beams since my homestead walls are 3 high dirt based blocks and I have hay supporting the dirt ceiling for my cellar... lol

But can I still install this alongside wilderlands Block adjustments now and it not break but just the blocks it adds not have this mods values?

by the way this produces errors such as [Error] Patch 5 in collapsestory:patches/collapsestory-brick.json: File game:blocktypes/clay/mossybrick.json not found

Ryumachinae ah don't misunderstand me, the books would be a far future feature as well.

And allright allright, I'll slap together a quick table with values and explanations for the in-game handbook in 0.3 :)

Packed dirt, hay and straw have the same sidewaysfalling as vanilla sand, gravel and soil, if you look at the first line below the first video (not saying it's an impossibility that I might need to format the explanations on the modpage so they stand out more). For a beartrap, I would use either rammed earth or wattle, as they should get stability from their own type neighbors, and being next to soil. In a future update, you will be able to also just buttress the soil with for example stick support beams (they can kinda buttress currently, making a bear trap w stick support beams works fine, but if any soil block slides due to for example neighbor sliding or plants being removed, the beams drop bco the beambreak on anchor block removal).

Long-term, I'll figure out a role for packed dirt also, possibly by making rammed earth require an extra component besides packed dirt, currently its role is colonized by both cob and rammed earth.

I would skip making an item and either focus on adding data to each indivudal block or make handbook entries, this is a kind of CRITICAL thing to know when building. I had to experiment right away to see what wouldnt vertically collapse, which was important because I had to dig an anti-bear pit right away when testing. At least now theres more of a reason to use rammed earth vs packed dirt

Ryumachinae yes, indeed. I have just set the addition of descriptions as a low priority, until the underlying values are tested and corrected more (since they determine what to write in the descriptions). But even granite cobblestone, with foundations of any buildable kind and 0 < story flooring supported by horizontal beams, should be very simple to construct with, while non-buttressed dark mudbrick is of course much harder to build with (though should be easy for for example flooring on top of horizontal beams). A main goal of the mod is of course to introduce the necessity for stronger materials, not just better block tech, if you want to build high.

edit: come to think of it, you made me wonder, I could even create some books that contain advanced construction info calculations, that can be found as loot in the world. If nothing else, it would look cool in players' library collections hmm.

edit2: procrastinating by researching math models a bit more. I might end up applying a so called Dijkstra's algorithm to replace my application of the vanilla BFS to both Y and X directions, to achieve pseudo-gravity for upward verticals. It would solve most of the janky stability issues (they come from interplaying horizontal and vertical calculations, derived from the vanilla model, which basically only looks to see if a block has a number of vertical blocks under it, then the instability check is passed if so).

Joyhop Thank you! 

and yeah there will be lots of bugs (though fewer now in 0.2 than I anticipated actually) heh. 

re. ruins: Thank you so much for the input on vanilla ruins, very important aspect. In your testing, do you mean they collapse when you remove a block from them or they collapse from game start? I might have been mistaken in my own testing (which was without better ruins), but there the ruins weren't affected, until I started to destory parts of them or build on them. I would imagine it would be the same for betterruins, that afaik also just spawns sets on worldgen. A possibility for betterruins longterm would be some sort of patch that edits the ruins and make them more stable.

The mod patches ALL buildable blocks, since otherwise, players could just remove aged/cracked/mossy/lichen blocks and use them as 100% stable air-floating blocks in their own constructions.

But none of the ruins should be collapsing before any player interaction. Are you seeing this?

re. : vertical support. Yes you are right, I now have 2 player feedbacks on why support beams aren't buttressing vertical constructions sufficiently. I will increase it somehow, and also specify more clearly that buttressing the lower base blocks in a pillar, that aren't above the instability loadcap, also adds to stability. I'm not at my PC so I can't check, but I think if you buttress the lower base blocks, it actually adds more to instability/ the calculation fires on higher stability values, which then propagate upwards, and yes that might be counterintuitive. I would believe 2x more stable would be too much though, but luckily I will just try and base the added stability on IRL buttressing stability.

re. valheim: I haven't played valheim, but I know it has a degradation/rot/maintenance system. Long-term CollapseStory WILL have a degradation system, probably based on the vanilla plumb-and-square reinforcement system values that then tick down over time or when a temporal storm passes through. 

re. : config file. It will probably have a config file long-term, problem is I need to get much more stable/ realistic values across the blocks and calculations, before I decide what variables to manipulate I put in the config. And I just really haven't had the time to test the values themselves properly yet, bco either work or trying to fix the ghost instability bug.

final comment: at the start of modding, I was jerking around with making an actual gravity system based on the vec3d graphical positioning system in vanilla, but gave up since the calculations just became too complex for me, and I was concerned it would be too demanding for multiplayer environments. But it is still possible this could become a thing in a much later version. It would solve many of the vertical check horizontal check neighbor check stability issues with the vanilla cavein/gravity system.

summary: if you could expand on what you are seeing re. collapsing ruins, I would appreciate it. For buttressing, I will just go forward with beams adding 1 extra loadcap to vertical columns in 0.3, it's the simplest, most calculation-efficent solution, and might actually be the best also. It means that if you buttress a vertical column once, you can build 1 extra block high before instability is applied.

(jesus i really need to figure out how to write chat more concisely)

DreamEater

This mod looks amazing and I would love to use it. I have a hard time building good looking buildings without being forced to and this is perfect. Reminds me of the vallheim building sytem.

It seems to break vanilla and betterruins ruins though. They collapse on top of me all the time lol. Not sure if there is a way to negate this. I see you mentioned that it should effect player buildable blocks only. Maybe make those blocks not counted towards instability somehow?

Potentially a config file?

Also refering to the vertical support beam comment by RockSowe. Maybe you could make it so that a support beam could make the material 50%-100% (1.5X, 2.0X) more stabile. And limit it to that. Have a check for what face of the block has beam support?

Blocks REALLY need more immediate data on them a-la 7 days to die, such as how much stability they give. I really dont know what blocks are more or less stable.

RockSowe

hah you caught me in the middle of modding, and actually looking at this (making stick and metal support beams).

I haven't added beam vertical block-by-block stability increase to columns, since I was afraid it would become overpowered. The beams DO in fact propagate support, but uh how do i explain it concisely; a function/calculation called calculatecoluminstbaility has math: beam reduction = (1 - beamRatio) x blocksAboveCap. Meaning, it reduces the realized blocks above the loadcap of the type and material, but only from the blocks that are already above the loadcap (eg. sandstone cobblestone accrues instability after the second vertical block = the loadcap). It was an attempt at introducing marginal gains scaling negatively with how tall the column would be, motivating players to and rewarding them for teching further (so a gameplay loop if you will). The whole point of the mod is to basically ensure players can't build forever high. The subsystem where columns support each other is then something to alleviate that a bit, in that you can build cross columns (columns of 5 blocks in the shape of a + ) that are much more stable than just a single column, it just takes more blocks and hence more "advanced" construction.

I've decided right now on your feedback to fiddle with the values that input into the above calculation a bit, before I try and introduce a hard loadcap increase from beams snapping to columns.

If you see different behavior than from caves, it's because the system is separate, and reversed in a sense. But you have a point in that it might be counterintuitive, hence needing a bridge between the two systems via a hard loadcap increase to the pillar the supported block is part of. I will look into that and test on it.

And thank you so much for the input, it's very valuable. 

Thoughts on vertical beams adding stability to walls? cause it seems like that's not really working rn

Miunnak that's awesome, well done! 

re: collisionboxes, well honestly I don't know, it was mostly a qualified guess on how supportbeamfromsticks implements, I'm currently at work so don't have access to my modding and inspection tools here. 

re: cost, yeah totally agree, the cost should be based on some kind of processing with stone age tools, the obvious one being flint/ stone axe. The reason I want an integrated stick and metal beam in CollapseStory itself is, so I can set the support propagated values in the .cs according to their tech tier and, for metal, material (and their default in their json).

tehtelev, yeah I saw that one, very cool (and very nice presentation page). And yeah could obviously be used together to limit how big a chunk of a building collapses, when some single foundation, roofbeam or pillar collapses. Currently I'm restricting collapse to mostly the collapsing pillar itself, and its dependencies that aren't supported by anything else, in a construction made of neighboring pillars, so it isn't too punishing (if I applied VS' vanilla cavein, the whole numerous-point supported building could collapse from one block removed).

Small update, I released the mod, for now it just turns 3 firewood to 1 beam, perhaps I'll add a variant that looks like firewood.

https://mods.vintagestory.at/show/mod/44940

Didn't think collisionboxes could be different since they visually look same in size with vanilla beams, interesting. I'm glad to hear you'll add beams to the mod but please make sure they're more expensive to make. 2 sticks is too easy imo. Other than that I have no other requests.

It's funny that at the same time, I posted my own mod that limits the number of unstable blocks falling at once. Some of your mod's default functionality will work with my mod as well.

https://mods.vintagestory.at/fallingspawnmanager

Miunnak 

re: supportbeamfromsticks - yeah I figured something like that. This sounds like the collisionbox calculations are off bc sticks in the mod perhaps have slimmer collisionboxes in their own type.

re: modding yourself - that sounds great! be mindful tho, stick support beams will be added to this mod at some point, but have fun! use ILspy to look in the dlls, and visual studio to manipulate both .cs files and jsons in one project, that can then be packed/ solved into the .zip file which is the mod.

re: my mod functionality - ok well that's great! Be sure to report about any building block type instability values being unrealistic or unintuitive/ unfun.

I tried supportbeamfromsticks and it does seem to have some issues by itself like breaking if an item is placed very close or just breaking in general for no apparent reason, I'm currently writing a new mod making 1 beam from 3 firewoods for early game to use (also I think this makes more sense) with your mod to replace it, using vanilla beams, it's just a recipe mod for now but I could try adding texture to it perhaps in future. It's my first ever mod in any game so we'll see if I can in future. Otherwise your mod seems to function fine from what I could test in creative, I'll be on watch for any bugs or problems.

Miunnak thanks, happy to help!

You are very welcome to give feedback on whether supportbeamfromsticks mod works with collapsestory. I didn't mention it as a suggestion in compatibility, since I haven't looked up if the modder names types or classes differently for beam sticks, bc if so, my system would need a patch to hook into his/her support sticks. But in theory they should vanilla propagate stability vertically from one single block to another just fine.

Ryumachinae thanks! And yeah, totally agree. I bet the devs think so too (you can actually see it in the unstablerock.cs comments where Tyron is masking expletives in his brainstorm on how to make support beams work well lol), just much later down the roadmap.

will be following this one, its absolutely a necessity for this game.

Just as I was looking for a mod to make my dirt hut make more sense 7 hours ago you uploaded it lmao, combined with https://mods.vintagestory.at/supportbeamfromsticks hopefully it becomes bit more realistic to make a dirt hut. Thanks for the mod!

Caoimhe thank you! for the interest! 

The logs exist in two states, grown or placed, in vanilla code. Grown logs, and hence trees, aren't affected. In fact worldgenned blocks aren't affected, in my own testing so far, partly bc there is no collapse trigger on worldgen, partly bc worldgenned blocks aren't placed by the player.

Placed logs are affected though, kind of bco the same reasoning as rammed earth and hay being used as infinitely tall towers. But the values are all subject to change! Currently logs have a loadcap of 2 (after which instability is added vertically), a maxsupportdistance of 2 (idem horizontally), instability per block of 0.4 (40% instability per log above cap) and collapsechance of 0.5 (chance of collapsing when unstable). The calculation is collapsechance times (instability / 100) as far as i remember right now. Meaning you will accrue instability quite fast horizontally, especially of you are appending the logs off a tall pillar. This is where the mod needs stick support beams for the log era, just haven't gotten to that yet.

BUT

The system also adds or subtracts from that default based on the strength of the wood, by a foreach api check. For logs, being woodtyped, kapok is weakest so subtracts 1 loadcap etc from the default, while oak, walnut, ebony, purpleheart adds 1 loadcap etc, from this default. The default covers larch, acacia, birch, cypress, redwood (should prob change redwood to stronger).

BUT

These values and tiers are subject to change according to what is actually most immersive and most playable (and also for when I've had the time to research IRL strength values more), hence my hope people will test and comment!

The mod will also make quarter log versions stronger at some point, possibly even in an update tomorrow, if I can fix the support beam bug shenanigans.

EDIT: forgot. You can use any buildable block as foundations as well, ofc., even rammed earth or cob, which are easy recipes.

Very exciting. I'll pay attention to this one. Actually needing to build stable stuctures will be a huge improvement.
How does this handle logs? It would be a problem if trees were to start falling over, and I like to use horizontal logs to form support beams, at least visually.