Public access to all life log data

TrustyWay · 2018-07-05 17:09:29

Never mind we did it on discord at the very same moment. You people shpuld check it out.

Last edited by TrustyWay (2018-07-05 17:16:27)

Chard · 2018-07-05 17:36:05

Right. That explains all the deaths without births. The births without deaths are obvious.

Thanks, Jason. My validation is almost done I just have one more thing:

lifeLog_server1.onehouronelife.com/2018_03March_29_Thursday.txt:B 1522325449 151203 33645a2fe7aef8f7e7588408fadc11a1d3a0bc92 F (-534,-720) noParent pop=30 chain=1
lifeLog_server1.onehouronelife.com/2018_03March_29_Thursday.txt:D 1522327655 151203 33645a2fe7aef8f7e7588408fadc11a1d3a0bc92 age=50.90 F (-536,-710) disconnect pop=33

Timestamps are 2206 seconds apart on an Eve for a death age of 50.77 not 50.90 as reported.

Another instance:

lifeLog_server1.onehouronelife.com/2018_05May_18_Friday.txt:B 1526637853 563908 7c82c56d382f57377c970e05cd513917d18bab01 F (183154,57803) noParent pop=38 chain=1
lifeLog_server1.onehouronelife.com/2018_05May_18_Friday.txt:D 1526638851 563908 7c82c56d382f57377c970e05cd513917d18bab01 age=30.67 F (183239,57792) disconnect pop=34

Timestamps are 998 seconds apart for 30.63 death age not 30.67.

sc0rp · 2018-07-06 08:47:32

jasonrohrer wrote:

So.... April 16 was the day that a bunch of servers were rebooted by Linode without warning.
The server is supposed to save the next ID to disk constantly as it is updated, but during a hard reboot, I guess this didn't happen for some reason. Maybe the reboot happened right at the moment it was trying to write the file.

There is no single fsync in the whole KissDB source, so it's not written to disk constantly. Once in a while, maybe twice a minute. Depends of file system used.

jasonrohrer wrote:

Weird that it happened the same way for a bunch of servers on the same day, but there you have it.

It's kind of expected - without fsync write happens when OS and file system feels like it. Also KissDB overwrites existing data on updates. There is no journal or anything. Corruption is only matter of time on partial writes during OS crash or power loss.

Straight form KissDB docs:
"""
It's also probably not a good choice if you need a long-lived database for critical data, since it lacks recovery features and is brittle if its internals are modified. It would be better for a cache of data that can be restored or "re-learned," such as keys, Bitcoin transactions, nodes on a peer-to-peer network, log analysis results, rendered web pages, session cookies, auth tokens, etc.
"""

jasonrohrer · 2018-07-06 15:00:11

The nextPlayerID is not stored in a .db file, but in a straight text file that is fully closed each time it is written. I'm pretty sure that closing a file causes an fsync.

Chard, the "age" is set when "logDeath" is called, and the timestamps are computed later, inside the logDeath code. There is nothing in that code that should block, but there's no guarantee of how long that code should take to execute. Server process could go to sleep to make room for some system process or whatever. So I think that's it, probably.

sc0rp · 2018-07-06 15:12:56

jasonrohrer wrote:

The nextPlayerID is not stored in a .db file, but in a straight text file that is fully closed each time it is written. I'm pretty sure that closing a file causes an fsync.

No, it doesn't - writing lots of small files would be extremely slow if it did.

http://man7.org/linux/man-pages/man3/fclose.3.html
Note that fclose() flushes only the user-space buffers provided by
the C library. To ensure that the data is physically stored on disk
the kernel buffers must be flushed too, for example, with sync(2) or
fsync(2).

If you creating new file you must fsync parent directory as well:
http://blog.httrack.com/blog/2013/11/15 … out-fsync/

jasonrohrer · 2018-07-06 15:59:17

Well, I guess I should put a sync in there then!

Ribbz · 2018-07-06 16:41:29

I'll just leave this here. It's a log of July MTD kills that goes over the Day over Day, Summary, #of Innocents/murderers killed etc. Determines if innocent via checking to see if that player id had committed a murder.

Also please note this is just for Server 1.

https://megashare.megahd.com.br/07a4f73 … 1a48d957f1

subria · 2018-08-13 03:43:15

Is email hash changed everyday?

jasonrohrer · 2018-08-13 15:45:35

Shouldn't be... using the same secret salt every day, and using SHA1.

Sypower · 2018-09-24 20:33:14

Seeing all this data gets me more excited than it should.... Thanks for sharing!

Having everyone's email address encrypted is meant to prevent other people from seeing your email address, right? You're not trying to prevent people from finding their own lives on the server? Because I think it would be interesting to see how/where my small contributions fit in to the bigger picture.

I'm thinking that I could find out what my unique identifier is by logging on to a server that isn't very busy, making note of my birth and death time, and then looking at the logs the next day to see the what identifiers were close to that time.

wondible · 2018-09-25 13:51:52

Sypower wrote:

I'm thinking that I could find out what my unique identifier is by logging on to a server that isn't very busy, making note of my birth and death time, and then looking at the logs the next day to see the what identifiers were close to that time.

Name log is included, so any recent life can be enough, especially if you look up mother's name and perhaps some other relatives via the lineage site. That is the technique I was using for my family tree charts. (Unfortunately the ids used on the lineage server are unrelated to the ones in the life logs)

jasonrohrer · 2018-09-25 14:59:18

Yeah, it's meant for privacy from others, not to prevent you from finding your own data.

wondible · 2018-10-21 14:58:09

Is it intended that death by animals is reported as hunger in the lifelog? It is reported as animal in the lineage browser.

Example:
http://lineage.onehouronelife.com/serve … id=1262942
Server 1 player id 1431196, 2018_10October_20_Saturday.txt
D 1540073967 1431196 e45aa4e489b35b6b0fd9f59f0049c688237a9a86 age=28.40 M (9971235,-38998) hunger pop=37

themadhatterz · 2018-11-25 22:25:46

Question on when the files appear. Seems they might appear, then be updated? Can anyone confirm behavior they have seen. Building some scraping on this and marking files as read so I don't re-read them.

However if files get updated after appearing, I would miss data.

Sylverone · 2018-12-21 15:04:14

Pretty cool. It'll be interesting to see if any nifty automated tools get built to use this data. For instance more expansive family trees, statistic graphs and so on.

lionon · 2018-12-21 16:32:47

jasonrohrer wrote:

I've realized that posting hashed email addresses is probably not a great idea:
https://freedom-to-tinker.com/2018/04/0 … addresses/
So I'm going to take the data down now and re-work the format to use something else as a unique, per-user identifier.

Hmmm ... 2 things:

First:
http://lineage.onehouronelife.com/serve … front_page
you can check anyway if someone with a given email owns the game and when they play... Which I consider not so cool

Second:
Since as far I get you are using the same salt for everyone I hope it is big enough to make brute force guessing the salt unreasonable. Since one can figure out their hash key and one uses their email it's just a matter of brute-forcing trying out combinations for the salt (if it's too short)...

I suggest everyone to receive a token on their email, just something randomized and that to be used as key without a connection to the email. hashed or not.

jasonrohrer · 2019-02-23 23:14:51

Yes, the "pepper" used in the hash is long enough.

As far as the lineage server stuff goes, well... it's just too inconvenient to have a separate code that everyone gets.

Though now that there's a FRIENDS button in the client, that opens a URL, maybe it could be automated.

But being able to search by email address is pretty nice.

If someone knows your email address... they know you, right?

Chard · 2019-02-24 01:37:05

I’d say no more than someone knowing your home address, or your IP address. There’s a difference between knowing someone and being happy for them to see your play history. Privacy isn’t about hiding information, it’s about making people feel safe.

lionon · 2019-02-24 06:16:01

jasonrohrer wrote:

If someone knows your email address... they know you, right?

And that should allow them to watch closely my playing times?

Whatever · 2019-03-10 13:45:02

@jasonrohrer
if i go to this website: http://onehouronelife.com/publicLifeLogData/
i can see all servers are up to date, except for bigserver_1 http://onehouronelife.com/publicLifeLog … elife.com/
which has its last entry over a month ago, is this server not being used?

wondible · 2019-03-10 14:35:26

Whatever wrote:

i can see all servers are up to date, except for bigserver_1

bigserver1 had an issues (I think IP banned in certain countires) and had it's map data migrated to bigserver2

Whatever · 2019-03-10 19:08:51

Thanks wondible, i made some stats and added them here: https://onehouronelife.com/forums/viewt … 275#p49275 on page 3

Update:

I now also created tools to gain stats about players, you can find everything about it here: https://onehouronelife.com/forums/viewtopic.php?id=5607
I also found out that the data is a little bit corrupted, sometimes deaths are missing, or lines might be incomplete, or contain random symbols. But those errors are not often.

Last edited by Whatever (2019-03-17 15:17:00)

lychee · 2019-05-16 14:06:48

Hey everyone!

If I wanted to track tutorial spawns, any advice on what coordinate ranges/servers I should be looking at?

lychee · 2019-05-16 14:12:09

Also is there a server reset log with reset times?

wondible · 2019-05-16 17:02:21

lychee wrote:

Hey everyone!
If I wanted to track tutorial spawns, any advice on what coordinate ranges/servers I should be looking at?

I've been using birthx < 5000000 to EXCLUDE tutorials, might be other junk out there too. If i recall tutorials travel upward in a vertical line, but the line can be bumped out farther (and may have wrapped due to unexpected conditions) I'm also using > -5000000 to cut out some of the wrapping.

I don't know of any apocolyse/reset log. I've been manually tracking the approximate times of the most recent ones for possible future use.

One Hour One Life Forums

#26 2018-07-05 17:09:29

Re: Public access to all life log data

#27 2018-07-05 17:36:05

Re: Public access to all life log data

#28 2018-07-06 08:47:32

Re: Public access to all life log data

#29 2018-07-06 15:00:11

Re: Public access to all life log data

#30 2018-07-06 15:12:56

Re: Public access to all life log data

#31 2018-07-06 15:59:17

Re: Public access to all life log data

#32 2018-07-06 16:41:29

Re: Public access to all life log data

#33 2018-08-13 03:43:15

Re: Public access to all life log data

#34 2018-08-13 15:45:35

Re: Public access to all life log data

#35 2018-09-24 20:33:14

Re: Public access to all life log data

#36 2018-09-25 13:51:52

Re: Public access to all life log data

#37 2018-09-25 14:59:18

Re: Public access to all life log data

#38 2018-10-21 14:58:09

Re: Public access to all life log data

#39 2018-11-25 22:25:46

Re: Public access to all life log data

#40 2018-12-21 15:04:14

Re: Public access to all life log data

#41 2018-12-21 16:32:47

Re: Public access to all life log data

#42 2019-02-23 23:14:51

Re: Public access to all life log data

#43 2019-02-24 01:37:05

Re: Public access to all life log data

#44 2019-02-24 06:16:01

Re: Public access to all life log data

#45 2019-03-10 13:45:02

Re: Public access to all life log data

#46 2019-03-10 14:35:26

Re: Public access to all life log data

#47 2019-03-10 19:08:51

Re: Public access to all life log data

#48 2019-05-16 14:06:48

Re: Public access to all life log data

#49 2019-05-16 14:12:09

Re: Public access to all life log data

#50 2019-05-16 17:02:21

Re: Public access to all life log data

Board footer