ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

DiscardedSlinky · 2019-07-31 20:36:08

I SPENT 3 LIVES IN THE SLINKER TOWN, MAKE THE ENGINE THE FIRST LIFE THEN THE NEXT TWO WAS ON OIL.

AND IT BROKE IN

O

N

E

U

S

E

one use

MY LIFE IS NOTHING BUT PAIN. PLEASE MAKE IT STOP.

sigmen4020 · 2019-07-31 20:56:10

Wow that’s really unlucky. Jason could you at least make more reasonable chance of oil, now that you can work really hard to get it just to lose the rig in one use.

As someone who has used up to 12 pipes at one oil rig (my first try at getting oil if you can believe it) it’s pretty unreasonable that you can do all that work for potentially just one can of kerosene.

Either make getting oil as predictable as making a Diesel engine, or increase the chances of getting a guzzling rig.

There’s a big reason that people prefer making Diesel engines over the oil grind and that is we dislike the rng. The oil grind was only exciting the first few times, but now it’s getting repetitive. People are making Diesel engines before getting because they are sick of the oil grind.

Lum · 2019-07-31 21:28:31

It's like finding a shiny pokemon but more sad

Last edited by Lum (2019-07-31 21:29:54)

SpiritBomb32 · 2019-07-31 23:02:04

F

jasonrohrer · 2019-07-31 23:53:59

With lower-tech water pumps, I'm stuck having them break permanently 1/20 of the time (20 uses on average) because the "uses" are occupied with counting how many buckets are left after each pumping.

For oil wells, this isn't the case. I think I can fix it to be more like an axe (4 uses with 1/5 chance of going down a use each time, resulting in expected 20 uses, but much lower variance).

jasonrohrer · 2019-08-01 00:14:05

Fixed here:

https://github.com/jasonrohrer/OneLifeD … 0e0375c353

Will go live later today.

Thaulos · 2019-08-01 00:14:23

Good stuff.

Mr.XIX · 2019-08-01 00:40:16

jasonrohrer wrote:

With lower-tech water pumps, I'm stuck having them break permanently 1/20 of the time (20 uses on average) because the "uses" are occupied with counting how many buckets are left after each pumping.

You can work around this by making an object of every water-state of the pump or make an object of every breaking-state of the pump.

Not very clean coding but hey, since when is that top priority right?

jasonrohrer · 2019-08-01 01:30:38

This isn't coding.

This is editing in an editor.

Specifying 20 transitions like that is extremely error prone.

There was some talk of a water barrel or something that would fill with 7 buckets in one go, and then get removed, allowing the uses to track the age of the pump. Or a separate "pump primer" object that would track the age of the pump.

Anyway, I never did that, because there weren't huge complaints about the pump breaking after the first pumping. It can happen 1/20 of the time....

Mr.XIX · 2019-08-01 11:25:55

jasonrohrer wrote:

This isn't coding.
This is editing in an editor.

Let me rephrase: "Not very clean editing but hey, since when is that top priority right?" (Looking at you cabbage seed and maple sapling!)

jasonrohrer wrote:

Specifying 20 transitions like that is extremely error prone.

I think you are overestimating the change (6 objects, a category, a few general uses), but I get why this is error prone and not desired.

jasonrohrer wrote:

There was some talk of a water barrel or something that would fill with 7 buckets in one go, and then get removed, allowing the uses to track the age of the pump. Or a separate "pump primer" object that would track the age of the pump.
Anyway, I never did that, because there weren't huge complaints about the pump breaking after the first pumping. It can happen 1/20 of the time....

Have you ever thought of reworking some of the engine here?

To make it possible for multiple use trackers can be added under different names, and having the possibility for them to be checked in transitions? (the min use fraction only checks for 0 or 1 right now which is highly undesirable)

Also, the possibility to play a sound on a given transition instead on an object would remove some error prone material.
Right now we 'need' objects like 'Bow#JustShot', 'Partial Bucket of Water' and 'Full Bucket of Water' just to get sounds to work correctly.

I realize this is not top priority, but it would clean up some of the old work and open up some great content possibilities for the future!

DiscardedSlinky · 2019-08-01 12:45:12

Thank you Jason. I'm glad no one has to experience that pain again.

jasonrohrer · 2019-08-01 16:53:52

I have thought about reworking....

But the code that makes use-tracking work is already really really complicated.

The engine was always meant for A+B=C+D and one object per tile.

Once I ran into some combinatoric explosion issues, I added some stuff on top of that to deal (multi-use objects, categories, patterns, etc.) But all of those things generate A+B=C+D under the hood.

So if a berry bush has 6 uses, the server and database actually sees all six of them as separate, unique objects. When I'm editing it, I see one object with 6 uses.

This allowed such things to be added with absolutely no client or protocol changes, for example. The client and the protocol don't know about uses, for the most part.

In some ways, this is a crazy way to do things. The normal way would be to plan it out ahead of time and build all the complexity into the database format and the protocol.

HOWEVER, it also might be a more sane way to do things. To have a robust core engine that is very simple (one object per tile with no other tags or properties, just a 32-bit ID number telling us which kind of object it is) and then build on top of that. If there's a bug somewhere, you don't have to look down in the database or protocol, because those are simple and were tested and perfected 3 years ago. And they aren't changing. The database structure has pretty much never changed in 3 years. I hasn't needed to.

But I've built all kinds of crazy stuff on top of that (uses, variable objects (locks), patterns, categories, probability sets). The code generates primitive objects and transitions that fulfill the higher-level requirements. That code itself is pretty complicated, though.

It's kinda like having a "pixel raster" as a fundamental primitive (a grid of RGBA values) and then doing all kinds of crazy stuff with that (Photoshop builds everything on top of that).

Anyway, there is a limit to this approach, in that the generation code gets complicated and intertwined (an object fulfilling a pattern that also has uses?), and it can't get much more complicated without the danger of major bugs lurking.

Use tracking generates N dummy objects and all associated transitions to go between those use states. Multi-use tracking would generate M*N objects and I'm not even sure how many transitions. I think it's M*N*2 transitions. You can see how easy it would be for that code to miss a case somewhere....

Mr.XIX · 2019-08-01 20:22:05

Thanks for your in-depth response.
I have so many questions, and you probably don't have the time, but I'm gonna ask anyway.

Looks like the easy, robust core needs to handle it all. We are a moving train now.

If done correctly everything can be reduced to an A+B=C+D.
Patterns of multiple use objects are a great example on that one.
The amount of transitions created can get pretty wicked I imagine.

What is the order of the limit of the number of transitions?
Is the easy and robust core fast enough to handle mass-created transitions?
(lookup-times are the bottleneck?)

I personally do not know how you implemented storage in the game, but I can't imagine you create every storage possibility as object.

This means that an object like a chest has a memory of its containing objects?
Isn't there a possibility to exploit that feature?
Is there a reason not to implement complexer objects with attributes?

One Hour One Life Forums

#1 2019-07-31 20:36:08

ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#2 2019-07-31 20:56:10

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#3 2019-07-31 21:28:31

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#4 2019-07-31 23:02:04

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#5 2019-07-31 23:53:59

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#6 2019-08-01 00:14:05

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#7 2019-08-01 00:14:23

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#8 2019-08-01 00:40:16

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#9 2019-08-01 01:30:38

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#10 2019-08-01 11:25:55

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#11 2019-08-01 12:45:12

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#12 2019-08-01 16:53:52

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

#13 2019-08-01 20:22:05

Re: ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE ONE USE

Board footer