安裝 Steam
登入
|
語言
簡體中文
日本語(日文)
한국어(韓文)
ไทย(泰文)
Български(保加利亞文)
Čeština(捷克文)
Dansk(丹麥文)
Deutsch(德文)
English(英文)
Español - España(西班牙文 - 西班牙)
Español - Latinoamérica(西班牙文 - 拉丁美洲)
Ελληνικά(希臘文)
Français(法文)
Italiano(義大利文)
Bahasa Indonesia(印尼語)
Magyar(匈牙利文)
Nederlands(荷蘭文)
Norsk(挪威文)
Polski(波蘭文)
Português(葡萄牙文 - 葡萄牙)
Português - Brasil(葡萄牙文 - 巴西)
Română(羅馬尼亞文)
Русский(俄文)
Suomi(芬蘭文)
Svenska(瑞典文)
Türkçe(土耳其文)
tiếng Việt(越南文)
Українська(烏克蘭文)
回報翻譯問題
http://steamcommunity.com/sharedfiles/filedetails/?id=790990151
This weight reduction effect i talked earlier must have a higher importance than I thought. The consequence of it (being able to build a 95 tower when it's already super hard to make one to 50) is quite fun in fact ^^
1) un nain bécile : 95
2) Aryemis: 89
3) Frost: 78
4) SquirrelsBane: 67
5) The Dovahkiin: 66
6) Milo: 65
7) Cocorico: 51
@Aryemis: definintely strange, I just rechecked my code and I can't see where the destruction of one structure could have a consequence on another one, but it seems it definitely has. If you wish you could send me your saved game (contact at gaddygames dot com) so I can check what happens with the exact forces numbers
I'm also quite confused at one thing in the physics, for some reason replacing 2x of the light composite blocks with one composite steel doesn't work, it makes the structure heavier as a whole... Or maybe it just focuses the forces on the center block and makes that one break faster than the others ?
@un nain bécile
Looks like I have some more work to do...
I guess I need to start from the ground up to beat that.
Though honestly I don't really have any more ideas.
First as a remark, the tower is perfectly legit, no problem at all =) And really a huge congrats to both you and un nain bécile =)
Now about the bug, I finally understand why it happens. And that's not good new, it would be really hard to control and/or fix. It's due to a change of the process order of the blocks of the tower, that happens when you suddenly remove a lot of blocks from your secondary tower.
Because unlike the water simulation that runs on all the world always in the same order, for the physics blocks i actually have an array of physical blocks (as there are really few of them compared to the 1million blocks of the world). So this array has an order, and for optimization reason when I remove a block from the array, the order of the array are modified (I replace the removed value by the last value of the array and decrease its length by 1)
Now, why this change of processing order make it collapse ? In a normal situation it wouldn't change anything... but here your tower is so optimized, so almost-collapsing everywhere that it's a really really unstable state... so a tiny change make it collapse (around the location when your tower goes from 1 block width to 2).
So the only possible action to avoid such "change order" would be to avoid removing an "old" physics block. If you remove any physic block, you would have to also remove all the blocks that have been added after this one.
Anyway, it was great to better understand my physic code and its limitation thanks to this contest and your incredible towers =)
PS: Aryemis I don't understand what you mean with your sentence about the 2x replacement of light physic blocks
I can't see how the previous issue would do that (but maybe i missed something)
Are you perhaps using a 16/32-bit float? If so, switching to something wider may solve your block ordering/consistency issues fairly cheaply.
@Frost: had you build a rainshield ? As water can add pressure and force on the blocks. Or maybe when you clicked in the menus you accidentally added a block on the tower (as i've some bugs with clicks on the menus that also clic on the game behind)
@Basic: the physic is in integer, not floating points
I've been consistently seeing strange behaviour, with the tower breaking somewhere it's not stressed.
It's like I've somehow hit the limit of the number of light composite I can put, and the next one I put on top takes one out in the 2x light composite part. And thus it seems like it broke in a non-stressed place.
That's the only explanation I've found so far anyway.
Aryemis could you post a screenshot of your 93 tower ? So it can be counted officially (even if it doesn't change the #2 rank)
More seriously, about the strange breaking location, after investigation yes it seems to happen when the tower is big enough to prevent the engine to balance it correctly enough, because the forces have so much distance to move through.
Because of that, sometimes at the end of the frame some block are in a very specific physic situation : their forces output are negative, meaning that there are more forces that goes into the block that forces that goes out from it. In a normal situation the force output is positive and equal to the block own weight.
This "negative weight" is normally the consequence of a "floating block", a block that is not linked to any ground anchor, and so cannot channel its force correctly into the ground. In this case the weight cannot balance at all, and so some blocks have a positive output, and other have a negative (the total being equal to 0, as they can't dissipate it through the ground). It's a very useful way to detect such floating group of blocks (which is not that easy to detect at all). In consequence I break the block when I detect such negative output.
Well.. sorry for the confusing text... my conclusion is that it's one more limitation of my physic engine, that happens only on huge constructions with very extreme forces.
This specific bug I think would occur more on blocks that have low forces, but close to blocks that have high forces (so for example it can happens near the place where you reduce the width of the tower, on the outside column). If those close high pressure block have a lot of balancing to do, they might make the outside block balance very hard to do, and result in a negative output at the end of the frame.
Thanks for the explanation anyway, it should help me find a way around this.
I think that it's also something to do with the very low weight of the blocks at that height, which means their self-force is extremely low.
Maybe the setting for detecting negative forces is a bit too sensitive for the low weight at this height ?
It's probably more trouble than it's worth to fix though.
We're definitely hitting the limits of the engine at those heights though. Possibly for the same reason, but since hitting 90+, I have to be slow when I bulid the spire, otherwise it just breaks randomly before even getting to 80...
Which was really not an issue even when building to 89 (on a different design admittedly).
I could improve the balancing in each update, before checking this layout, but it would take more CPU. Or maybe wait for several frames with a negative layout before breaking the block, but it would ask to memorize it etc, so not the priority