Methods of reducing variance

jasonrohrer · 2019-05-04 17:01:38

And DAMN... actually making multiple tiers manually here is really out of the question.

There are so many stages to the pumps.... add water, add charcoal, running, wet, dry. Each of these would have to have a manually-created version for each stage of exhaustion, and transitions hooking them all together.... way too error prone.

I've gotta get this update out, so I'm going to punt here, and leave it at 1/20 for now, and see where that takes us.

Maybe will think through a "sounding rod" type solution in the future, but would need a way to limit how far they could travel or something.... more work/thought needed.

Booklat1 · 2019-05-04 17:13:22

Jason, can you make a loud sound effect for pumps drying? helps people become aware of it

Dodge · 2019-05-04 17:13:58

Yeah so i dont see any other solution than making:

first pump->second pump->third pump->fourth pump->pump that has probability to get exhausted

all are different objects so the "uses" are not used other than for the buckets, every level could have probabilities to get to the next level

So replace the "uses" with a completely new object

But you have to manually make every variation of the object which is tedious (first pump fired, first pump with water, first pump with full boiler etc)

Unless you can code it in the editor to create the objects and all it's variations dynamically by entering the number of total level of the object (pump) you want.

With the correct transitions...

Dodge · 2019-05-04 17:25:29

jasonrohrer wrote:

And DAMN... actually making multiple tiers manually here is really out of the question.
There are so many stages to the pumps.... add water, add charcoal, running, wet, dry. Each of these would have to have a manually-created version for each stage of exhaustion, and transitions hooking them all together.... way too error prone.
I've gotta get this update out, so I'm going to punt here, and leave it at 1/20 for now, and see where that takes us.
Maybe will think through a "sounding rod" type solution in the future, but would need a way to limit how far they could travel or something.... more work/thought needed.

It could be coded in the editor where you enter the number of tiers you want and it automaticaly creates all the variations but to get everything right including the transitions sounds complicated i guess the transitions could be copied too in relation to their level so the variations matches the level, then you would only need to check manually the variation that goes to the next tier.

Sukallinen · 2019-05-04 17:35:23

Dodge wrote:

But you have to manually make every variation of the object which is tedious (first pump fired, first pump with water, first pump with full boiler etc)

Hmm, copies (like different colored hats) out of the question like Dodge said, having 5,4,3... ? Were the different colored clothing copied or manually added ? But nvm since already decided. And IRL too new stuff randomly break easier than those that have been used a bit.

Dodge · 2019-05-04 17:46:18

Wouldnt it be possible to use the decay timer as use for tiers?

For example when you first use the pump it sets a ridiculously high decay number of seconds like 500000000 seconds then if you hit a "bad try" in the probability when emptying the well, it reduces the timer by 100000000, after 5 bad tries the timer should be at minus something and the pump decays to exhausted pump.

wondible · 2019-05-04 17:51:03

Dodge wrote:

Wouldnt it be possible to use the decay timer as use for tiers?

I think the problem here is that decay time is already used by the firing process.

https://onetech.info/2224-Firing-Newcomen-Pump

thundersen · 2019-05-04 18:02:08

EDIT:

wondible wrote:

Dodge wrote:
Wouldnt it be possible to use the decay timer as use for tiers?
I think the problem here is that decay time is already used by the firing process.
https://onetech.info/2224-Firing-Newcomen-Pump

If that can't be worked around, the following is moot.

How about a time-based decay for the Newcomen Pump?

Say you have half an hour to crank out as much water into cisterns as you can, but then it inevitably decays into a broken pump. Maybe increase the time for the firing pump from 15 to 30 seconds (or any number that makes more sense) to reduce the maximum number of buckets you can get out of it.

In the optimal case where empty cisterns, charcoal and a bucket are available you might need 5 seconds for emptying, refilling water and charcoal and firing. That would be 1800s / 35s * 2 buckets = 103 buckets of maximum water gain. In reality you would hardly have charcoal and cisterns ready all the time. So in a well-run town you might expect 40-50 buckets with a hefty investment of lifetime and kindling.

Last edited by thundersen (2019-05-04 18:04:23)

Spoonwood · 2019-05-04 18:07:04

It seems that so far you've considered use counters, as in use of the pumps via buckets of water. But, what if you put a counter on the number of charcoals dumped in a charcoal pump, or kerosone charges dumped in a kerosone pump? Or, I think better when I think about diesel water pumps needing a dump, what about a counter tracking the number of uses of the firebrand lighting the pump? Would either work? Just ideas... I certainly don't know enough about the code to have a clue about the feasibility of either idea.

Edit: I like the time decay idea also. Just aesthetically, no idea about the implementation of that in the code.

Last edited by Spoonwood (2019-05-04 18:08:07)

zed · 2019-05-04 18:11:37

Could you use movement transitions for this?

So one cell north of each springhead you have an object representing the
aquifer. This has "uses" representing the amount of water left in the aquifer.
On a decay timer, it tries to move south. If it hits a dried out pump, the
pump becomes ready to fire up, and the aquifer loses a use. If I'm reading the
code right, leaving behind a modified version of the moving object like this
is something the engine already allows.

Later uses of the aquifer could only trigger the transition with more advanced
pumps.

Last edited by zed (2019-05-05 08:19:55)

Spoonwood · 2019-05-04 18:22:29

Could the newcomen atmospheric core have a use counter and it's affected by how many times it gets fired? If so, maybe the oil rig needs a different type of machine to run it rather than a newcomen atmospheric core. Or maybe one oil rig running out at some point comes as desireable, I don't know.

Last edited by Spoonwood (2019-05-04 18:22:48)

wondible · 2019-05-04 18:34:45

thundersen wrote:

How about a time-based decay for the Newcomen Pump?
Say you have half an hour to crank out as much water into cisterns as you can

Alternately, could you get 30 secs (TBD) of infinite water per firing? Maybe that would let use count get tracked over firing.

Dodge · 2019-05-04 18:52:52

Or firing the pump could fill a water container that you remove from the pump then empty with the buckets and put back on the pump when empty.

BladeWoods · 2019-05-04 19:17:42

I would consider adding just a single additional stage, so instead of wet 5%-> exhausted it's something like wet 10%-> less wet 10%-> exhausted

Average is still 20, but the variability is reduced be a LOT.

Impossible to exhaust in 1 use. Chance to exhaust in two uses is down to 1% (1/10 * 1/10) vs 4.75% (19/20 * 1/20)

Spoonwood · 2019-05-04 19:19:36

BladeWoods wrote:

I would consider adding just a single additional stage, so instead of wet 5%-> exhausted it's something like wet 10%-> less wet 10%-> exhausted
Average is still 20, but the variability is reduced be a LOT.
Impossible to exhaust in 1 use. Chance to exhaust in two uses is down to 1% (1/10 * 1/10) vs 4.75% (19/20 * 1/20)

I like this idea. Not sure the numbers work out as best though.

BladeWoods · 2019-05-04 21:29:59

Yo, what about cows? They seem to track cycles through the number of moves. Cows go from Milk Cow to Dry Cow and back, but the maximum number of times this cycle can repeat is 3 (Is this correct?).

Could the pump be made into an unmoving animal with move numbers to limit the number of cycles to exactly 20?

Last edited by BladeWoods (2019-05-04 21:32:32)

pein · 2019-05-04 22:23:56

well he needs a name, same as onetech displays it
just because you don't see or know it's breaking, it's breaking

so the feedback part is better for us

i had a shovel broke in like 7-8 uses and i was like: wtf i didn't made the vein first
now a newbee breaks a tool it feels bad when he just born and doesn't know how it works, thinks he done something wrong
also when you got a crackled shovel, you don't go out with it

yeah, we can imagine that the water is coming from the newcommen but those states are same object actually
it stores nothing it just cycles between states
so cant track it

so basically same for cistern, only says chances and 100% that you take on out or put one in it
that's why you cant use bowl on it cause doesn't convert the water storage

what you say is still a rule change from 0% of breaking to 5% so needs to track the damage and carry it over
after it would lose the 5 guaranteed, it becomes a new object which has a hazard of breaking so i has differrent rule to apply, which doesn't have to be visible but it would be better if it is

jasonrohrer · 2019-05-07 05:45:35

Zed, that's an interesting hack of an idea. Maybe it could work!

Currently, the "water tank" or barrel is probably the most straight-forward idea. You use it on the full pump, and it takes all the water out.

zed · 2019-05-07 16:00:54

You do get a lot of flexibility by having a separate object for the raw
resource -- you can decide in advance how much you want to be available,
inject randomness as you wish, and let different technologies exploit
different amounts of it at different rates.

More generally, movement transitions seem to allow a lot of richness in the
engine. I can imagine one possible path for the game involving letting players
exploit that richness, designing and building intricate multi-tile machines.
Just like with electricity in TCD, it can be turing complete if you ignore
size restrictions (e.g. it looks like you could implement Conway's Game of
Life using movement transitions), so there could be a lot of room for player
ingenuity. I'm not at all sure this would be a good direction for the game...
but it's interesting that it's possible!

jasonrohrer · 2019-05-07 17:03:06

Yes, I did think about that richness, Zed, when I designed the movement stuff.

I tested some robotic field tilling machines, that keep walking East until they get to the end of the field row, and then turn North or whatever. That stuff all works. Though I think they might stop walking once no one is looking.... I can't remember. Maybe the fixed direction movements (N) keep going even if no one is looking.

zed · 2019-05-07 17:11:31

Sounds nice... maybe it's time to add oxen?

jasonrohrer · 2019-05-07 17:46:57

Sounds like you're sharpening your gelding knife over there, Zed!

Tarr · 2019-05-07 18:15:25

I mean I wouldn't be against a plow finally being added. You did say it was coming soon about 11 months ago Jason

Booklat1 · 2019-05-07 19:02:44

Tarr wrote:

I mean I wouldn't be against a plow finally being added. You did say it was coming soon about 11 months ago Jason

plows to expand sheep era tech would be great

Christoffer · 2019-05-08 23:39:58

Being the one who demonstrated the variance control of multi tiered probability in the first place, I feel that I should point out that you can achieve reduced variance with the two systems you already have in place:

1. Instead of always delivering 5 buckets of water per cycle, deliver 5 on average, using a probability of 5/6 to yield water and 1/6 to run dry. Assuming several cycles, the variance of the total will be small (like the total of several dice rolls).

2. The use count “variable” is now free to use for the number of cycles instead of number of buckets. Since use chance has variance control built in, you can now control the variance of the total output by controlling the variance of the number of cycles.

The key is to control the outer loop. The inner loop can use simple probability.

One Hour One Life Forums

#26 2019-05-04 17:01:38

Re: Methods of reducing variance

#27 2019-05-04 17:13:22

Re: Methods of reducing variance

#28 2019-05-04 17:13:58

Re: Methods of reducing variance

#29 2019-05-04 17:25:29

Re: Methods of reducing variance

#30 2019-05-04 17:35:23

Re: Methods of reducing variance

#31 2019-05-04 17:46:18

Re: Methods of reducing variance

#32 2019-05-04 17:51:03

Re: Methods of reducing variance

#33 2019-05-04 18:02:08

Re: Methods of reducing variance

#34 2019-05-04 18:07:04

Re: Methods of reducing variance

#35 2019-05-04 18:11:37

Re: Methods of reducing variance

#36 2019-05-04 18:22:29

Re: Methods of reducing variance

#37 2019-05-04 18:34:45

Re: Methods of reducing variance

#38 2019-05-04 18:52:52

Re: Methods of reducing variance

#39 2019-05-04 19:17:42

Re: Methods of reducing variance

#40 2019-05-04 19:19:36

Re: Methods of reducing variance

#41 2019-05-04 21:29:59

Re: Methods of reducing variance

#42 2019-05-04 22:23:56

Re: Methods of reducing variance

#43 2019-05-07 05:45:35

Re: Methods of reducing variance

#44 2019-05-07 16:00:54

Re: Methods of reducing variance

#45 2019-05-07 17:03:06

Re: Methods of reducing variance

#46 2019-05-07 17:11:31

Re: Methods of reducing variance

#47 2019-05-07 17:46:57

Re: Methods of reducing variance

#48 2019-05-07 18:15:25

Re: Methods of reducing variance

#49 2019-05-07 19:02:44

Re: Methods of reducing variance

#50 2019-05-08 23:39:58

Re: Methods of reducing variance

Board footer