[ 3 / biz / cgl / ck / diy / fa / ic / jp / lit / sci / vr / vt ] [ index / top / reports ] [ become a patron ] [ status ]
2023-11: Warosu is now out of extended maintenance.

/sci/ - Science & Math

Search:


View post   

>> No.1998519 [View]

>>1998500
That's close, but you're using an object oriented model which makes me cry a little inside for the process inefficiency.

._.
>moar trolling

>> No.1998492 [View]

>>1998483
>full moon is a lunar eclipse

> A full moon is just any other moon with no part of the moon blocked by a shadow

> Blocked by a shadow

>Maximum Trolling.jpg

>> No.1998486 [View]

>>1998480
hmm. Very clever, then. Use more words to explain your ideas next time, Mr. Full Moon. =3

>> No.1998481 [View]

>>1998472
:3
I'll be back the next time I have a problem I would like help "solving".

>> No.1998474 [View]

>>1998469
I am still using the Fault system.

>> No.1998471 [View]

>>1998463
>averaging it out
I'm not averaging anything.
I'm using a strict total. And I'm not using all adjacents.
Only the adjacent faulted squares.

it's like a guy says "FULL MOON is the answer"
And the answer turns out to be a lunar eclipse
Guy:
>I was rite.jpg

>> No.1998461 [View]

>>1998450
Well more importantly, like I said - I don't want to draw weight from ALL adjacent squares.
Just the randomly selected faulted ones.

He seemed to want me to discard my entire Fault system. Which was an inherent part of the logic problem.

>> No.1998454 [View]

>>1998449
>present a problem
>people change the problem
>people insult the problem
>people insult the OP
>trolled all day
>get a few suggestions, but nothing miraculous
>Try to reason with trolls
>probably a mistake
>trolling gets worse

>work hard at it anyway
>find a solution to your own problem

>trolls become angry and throw a few last insults

...
...
...

umad.jpg

>> No.1998437 [View]

No? I didn't think so. You all have been horribly arrogant, doing-it-wrong, pig-faced monsters who would sooner complain about a car's antenna ball than fix its engine.

The design goes into paper testing before it moves to rigor alpha, since no one has objections or flaws to point out

Peace~

>> No.1998431 [View]

>>1998424
The tile would have a 1:3 chance of causing a cascade collapse.

I think this design will work.
Some more tests.

Personally I want to THANK /sci/
(and /v/, if you're there... you know who you are)

for being .. absolute, unreasonable, annoying and trolling bastards

while I worked out this very delicate game math
Thanks very much.

If anyone has comments *snrk* on proposed solution, now's the time to comment...

>> No.1998424 [View]
File: 18 KB, 794x578, 6.png [View same] [iqdb] [saucenao] [google]
1998424

Proposed solution results in this...

>> No.1998411 [View]

One obvious possibility is "Weight of all adjacent neighbors +1"
But I hate that. It defeats the fault system.

What about "Weight of all FAULTED neighbors +1"?
Would this cause reverb? ...

maybe... NOT.
Maybe not!

>> No.1998407 [View]

Currently, the weight for a tile is simply expressed as "Fault Tile +1"
Which is efficient and works.
But if we... change this.
hmm

>> No.1998404 [View]

The model originally had single tie weight correlation to drastically reduce the number of calculations to determine collapse.

The "stick" example. The "box" example.

But if we look at the "fan" design. We have an issue.
I think the solution... may lie in... the way the WEIGHT is calculated for a ceiling tile, when it is dug out.

>> No.1998400 [View]

mm. Weight deltas. Fault cascades that come to a single point.

>> No.1998399 [View]

We originally chose an inverted Anchoring system in the vain hopes of AVOIDING this scenario, but it looks like we are stuck with the old "pull the rug out from under it" puzzle, after all. I don't think reversing the order of the faults or the alignment system will help one bit - the curent setup makes it easy to track collapses.

>> No.1998396 [View]

What we REALLY ... really want, is the original design.

One block dug, ONE weight process.

So what happens when the dug-out block was loadbearing. We have generally boiled it all down to this point.

>> No.1998391 [View]

>ridiculous amounts of cascades
This problem got worse though.
Consider a "Delta" shape.
Where a fairly tough material (steel) has a great many connections leading to one panel. We could see a LOT of bogdown from loops, and even if those loops collapse, the bogdown per square dug could get extreme.

Especially with a high tension limit material like Steel, in a very large dug out room.

now we are talking nightmare mode. If we solve THIS, the whole issue can be put to bed.

>> No.1998388 [View]

>> the moment an infinite weight loop reaches a collapse point, the loop collapses.

So we don't have to worry about infinite loops. Problem one of three has been beheaded.

Now we have to worry about processing HUGE amounts of cascades, vs. unrealistic structures.
Let's cross out unrealistic structures, and focus on ridiculous amounts of cascades.

>> No.1998383 [View]

>>1998379
oh, but that's ONE truth - the moment an infinite weight loop reaches a collapse point, it's not infinite anymore.

The whole loop will collapse.
o.o

Amazing. A whole THREAD of geniuses and not a single fucker noticed.

>> No.1998381 [View]

>>1998376
Thanks.

>> No.1998379 [View]

From one perspective, the number of links to a cascade is strictly limited to the amount of weight that will cause a collapse.

i.e. a tunnel with connected Faults will cascade weight ONLY up to the tensionpoint.

If weight 5 collapses the most times it will possibly cascade is 5... unless.
>.o ooh, unless the cascade forks. That's ugly

>> No.1998372 [View]

Actually calculating physics on the blocks is way too loaded, it will bog a comp down to nothing.
Let's not make flight simulator here.

Let's find a solution to the original problem.

Infinite cascades, Cascade bulk, and unrealistic structures.

>> No.1998371 [View]

=================
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
Troll line

OK, resuming work on the actual problem -.-

Navigation
View posts[+24][+48][+96]