IRC logs for #openttd on OFTC at 2010-08-28
⏴ go to previous day
00:10:53 *** roboboy has joined #openttd
00:20:08 *** Timmaexx has joined #openttd
00:26:44 *** TruePikachu has joined #openttd
00:40:07 *** tim is now known as Timmaexx
01:15:03 *** roboboy has joined #openttd
01:37:18 *** De_Ghosty has joined #openttd
02:40:32 *** draconnier has joined #openttd
04:56:26 *** Eddi|zuHause has joined #openttd
05:12:54 *** perk111 has joined #openttd
06:14:58 *** robotboy has joined #openttd
06:28:49 *** devilsadvocate has quit IRC
06:29:42 *** devilsadvocate has joined #openttd
06:33:03 <Terkhen> nice, a night log that does not look like someone's twitter
06:34:09 <dihedral> esp if you are referring to Pi-Gesundheit (as Rubidium tends to nick name him/her/it)
06:35:07 <Rubidium> dihedral: sorry, but that name is coming from Eddi
06:35:37 <dihedral> anyway, good morning ;-)
06:38:17 *** ^Spike^ has joined #openttd
06:38:34 *** devilsadvocate has quit IRC
06:55:35 <planetmaker> I just 'stole' your FIRS colour scheme for newgrf descriptions, andythenorth ;-)
06:56:28 <andythenorth> I'm not sure it was mine anyway :o
06:58:30 <planetmaker> It kinda follows from they style of the GUI around it
06:59:47 <andythenorth> /me ponders reworking some FIRS cargo chains
07:01:38 <andythenorth> probably not necessary
07:02:18 * andythenorth should play a game
07:04:51 * andythenorth thinks there are problems with town cargos
07:05:40 <dihedral> Terkhen, luckily you did not enter the channel like... just now ^^
07:06:23 <planetmaker> apropos town cargos, andythenorth
07:06:53 <planetmaker> There's the proposal to modify TTRS banks such that they become a money press, accepting paper and <something>
07:07:12 <andythenorth> I saw that. Not interesting to me, but would be an easy add-on
07:07:32 <planetmaker> alternative is: they become just houses
07:11:22 <andythenorth> planetmaker: use slot 1E or similar for a 'currency' cargo
07:11:49 <andythenorth> then put a bank somewhere up around 40
07:23:43 *** George|2 has joined #openttd
07:26:28 *** Kurimus has joined #openttd
07:28:49 <planetmaker> andythenorth: no new cargo. Just accepting existing FIRS cargos
07:29:00 <andythenorth> nothing produced?
07:29:28 *** fonsinchen has joined #openttd
07:29:36 *** lordaro has joined #openttd
07:30:46 <lordaro> woo! i'm back! TrueBrain active yet?
07:32:12 <lordaro> :p this is my best bet of finding him
07:32:28 <dihedral> it's your best bet of hitting a few ignore lists
07:33:14 <lordaro> well how would you suggest finding TrueBrain?
07:33:23 <dihedral> have a look at the logs ;-)
07:33:28 <planetmaker> lordaro: you last post in the thread you asked him to read doesn't contain a question. At least at the time you asked
07:33:35 <planetmaker> As such he already answered you
07:34:00 <dihedral> + he asked why on earth you so desperately want an answer from him if anybody else could answer
07:34:01 <planetmaker> There was no lie that you missed him yesterday(?) answering you
07:34:38 <lordaro> ok, where are the logs?
07:35:02 *** last_evolution has joined #openttd
07:42:03 <lordaro> so he replied in the ~1 hour i wasn't on here. typical:-/
07:52:02 <Yexo> lordaro: "help?" is technically a question, but it's not one you'll get an answer too
07:53:28 <Yexo> in that case my point applies even more, there is no question at all in that post except for "how to contact TB?"
07:53:50 <dihedral> like i said, stalker!
07:54:35 <Yexo> lordaro: I tried to run the tournament system yesterday too
07:54:53 <Yexo> the main problem is that the score output from openttd doesn't end up at stdout
07:55:10 <Yexo> I haven't been able to found out why not
07:55:58 <lordaro> well if you can't find out why not, i've got no hope:-(
07:56:31 <dihedral> then you have no hope
07:57:06 <Yexo> you might have better luck on a non-windows os
07:59:10 <lordaro> i'm on ubuntu now, and always have been :(
08:03:32 *** planetmaker has left #openttd
08:03:38 *** planetmaker has joined #openttd
08:15:15 <andythenorth> planetmaker: wondering if Sand & Gravel should be one single cargo
08:16:05 <planetmaker> hm. Maybe. Let me see how they're used
08:19:05 <andythenorth> I think it's the wrong choice
08:19:08 <andythenorth> sand goes to glass works
08:19:15 <andythenorth> it was just a thought
08:19:42 *** robotboy is now known as roboboy
08:20:17 <planetmaker> hehe glass made from gravel ;-)
08:20:57 <roboboy> not verry see through
08:41:13 <andythenorth> map without water would be an edge case for FIRS
08:41:21 <andythenorth> is it likely, or pathological?
08:43:16 <planetmaker> it's not unheart of
08:43:36 <planetmaker> even though personally I'd prefer usually one with at least a little
08:43:47 <planetmaker> but FIRS should not rely on it indeed
08:44:06 *** Progman has joined #openttd
08:44:14 * andythenorth goes back to deleting stuff
08:44:25 * andythenorth will think about water later
08:45:37 *** Alberth has joined #openttd
08:45:46 <planetmaker> good thing about VCS is that you could still bring it all back easily ;-)
08:46:00 <planetmaker> andythenorth: when you delete strings... delete them also from translations
08:46:09 <Alberth> unless you mess with the history :)
08:46:17 <andythenorth> (delete strings, not mess history)
08:46:31 <planetmaker> Alberth: you nasty guy ;-)
08:46:32 <andythenorth> planetmaker: I even preserved the 'groups of 5' formatting :P
08:46:35 <planetmaker> good morning to you
08:47:00 <planetmaker> andythenorth: I found it makes it easier to keep track. Besides it was nearly like that in the original 7F file
08:47:29 <andythenorth> that's because I formatted it that way for readability :)
08:52:44 <Terkhen> I should group the spanish translation too
08:54:34 <planetmaker> I guess I'll wait yet another month before I touch the German one again. Too many changes :-P
08:54:54 <andythenorth> Terkhen: it's pretty quick
09:09:14 <andythenorth> Terkhen: don't do that formatting yet (unless it's done already) :P
09:09:23 <andythenorth> you'll have some merge to do otherwise
09:09:41 <Terkhen> don't worry, I'll do it after lunch
09:11:51 * andythenorth murders FIRS survey supplies concept :P
09:14:08 <andythenorth> the idea was that players would only be able to fund primary industry near to a Survey Camp
09:14:16 <andythenorth> Survey Camp would need Survey Supplies or it would close
09:14:25 <andythenorth> think it would be un-fun
09:21:06 *** Chillosophy has joined #openttd
09:26:47 *** devilsadvocate has joined #openttd
09:27:15 <Terkhen> seems complicated, yes
09:29:17 *** TomyLobo has joined #openttd
09:37:01 <V453000> hi ... what does "smoke_amount" setting do?
09:37:27 <V453000> I have it in [vehicles] in the cfg but have no idea what is going on :)
09:39:13 <andythenorth> V453000: you get default smoke from trains, or 'more smoke'
09:39:23 <andythenorth> some people think 'more smoke' looks better :)
09:39:44 *** |Jeroen| has joined #openttd
09:43:05 <V453000> hehe it looks nice indeed
09:45:55 <andythenorth> I invented way too many Farm cargos for FIRS
09:46:06 <andythenorth> and hauling food is realistic but boring :P
09:50:47 *** roboboy has joined #openttd
09:53:00 <planetmaker> andythenorth: it seems somewhat that after some time you grow bored of _any_ cargo ;-)
09:53:27 <planetmaker> if you go by that _any_ cargo you'll ever invent is boring
09:53:33 <planetmaker> Except maybe contrabant
09:53:34 <andythenorth> well I like Steel
09:53:51 * andythenorth thinks of other cargos
09:53:55 <andythenorth> nah, all boring :P
10:04:10 *** lordaro1 has joined #openttd
10:07:42 <Rubidium> Yexo/lordaro1: the patch seems to print the company information just fine, although it will only print it 10 ticks *before* the end. So if you set ticks to a million and wait two minutes it hasn't reached that point yet and thus it doesn't print and thus it seems to fail.
10:08:14 <Rubidium> what *could* be happening is that no AI is started, but there should always be a "local" company that's making a loss as it's not managed
10:09:24 <Rubidium> hmm, oh... "openttd -g" doesn't start a new company when using -v null
10:10:00 <Rubidium> bin/openttd -v null:ticks=11 <- works fine (uses intro game, which has a company)
10:10:21 <Rubidium> bin/openttd -g pile_final.sav -v null:ticks=11 <- works fine (uses an OTTDcoop game, which has a company)
10:10:32 <lordaro1> thanks Rubidium, and no, i didn't leave the room (it said i ping timeout-ed on my irc thing)
10:10:48 <Rubidium> bin/openttd -g -v null:ticks=11 <- appears to fail (has no company)
10:13:53 <lordaro1> can't say i know what to do with the information though;-), do i have to modify the python script or the patch?
10:14:09 * andythenorth needs more cargo slots :P
10:17:36 <andythenorth> wasting a cargo slot, and very boring :P
10:18:13 <Eddi|zuHause> you can make a different cargo get TE_WATER ;)
10:18:35 <lordaro1> yeah, who needs water anyway :D
10:22:45 <andythenorth> I need to sort a python dict on the keys
10:22:54 <andythenorth> umm, not on the keys, on the values
10:23:09 <andythenorth> default sort is keys, I need a lambda sort, but it baffles me :(
10:23:24 <Eddi|zuHause> lambdas are easy ;)
10:23:47 <Eddi|zuHause> like "lambda key,value: value"
10:24:19 <Eddi|zuHause> don't be afraid of lambdas ;)
10:25:04 <andythenorth> in fact I need to sort the order of a dict of dicts, based on values in the nested dicts
10:25:40 <andythenorth> {'mapping_by_industry': {'windmill': {'title': 'Windmill', 'accepts': ('grain', 'manufacturing_supplies'), 'coded_status': 'coded', 'produces': ('food',)}, 'steel_mill': {'title': 'Steel Mill', 'accepts': ('coal', 'iron', 'scrap_metal'), 'coded_status': 'coded', 'produces': ('steel',)}}
10:25:47 <andythenorth> needs to sort on title
10:26:10 <andythenorth> mapping_by_industry is a list
10:26:27 <andythenorth> that paste above has syntax errors
10:26:42 <andythenorth> give it another } it should be fine
10:28:01 *** KenjiE20 has joined #openttd
10:28:25 <Eddi|zuHause> what should the output format be?
10:28:36 <Eddi|zuHause> obviously, to be sorted, it must be a list
10:29:04 <Eddi|zuHause> or do you want an iterator that spits out the industries in the right order?
10:31:52 <andythenorth> if the list mapping_by_industry was sorted correctly, that would do it
10:32:29 <Eddi|zuHause> what i did now is something like:
10:32:41 <Eddi|zuHause> c=b['mapping_by_industry'].items()
10:32:43 <Eddi|zuHause> c.sort(key=lambda x: x[1]['title'])
10:34:16 <andythenorth> Eddi|zuHause: 'sort takes no keyword arguments'
10:34:22 <andythenorth> maybe my python version is too old
10:34:35 <Eddi|zuHause> i have 2.5, that is already very old ;)
10:35:05 <andythenorth> we don't upgrade production webservers to newest versions, stuff...breaks :P
10:35:07 <planetmaker> but many things still want a 2.x version
10:35:44 <Eddi|zuHause> andythenorth: i don't know that old python versions, but probably you just have to rewrite it a little
10:36:01 <andythenorth> there is a way to do it, I just don't grok lambda
10:36:07 <andythenorth> maybe it's not needed :o
10:36:19 <andythenorth> it's only ordering lists of industries on my website neatly
10:39:00 <Eddi|zuHause> andythenorth: try this: c.sort(lambda x,y: cmp(x[1]['title'],y[1]['title'])
10:39:21 <Rubidium> yup, python 2.5 must be more than 2 years old already
10:39:43 <andythenorth> the box is about 6 years old
10:39:54 <Eddi|zuHause> i remember when i started with python, 2.6 was about to be released
10:40:20 <Eddi|zuHause> that must be around 2 years ago, yes
10:41:58 <Eddi|zuHause> andythenorth: also add ) ad libitum ;)
10:42:13 <andythenorth> Eddi|zuHause: works (with a tweak) thanks
10:43:11 <Eddi|zuHause> don't be afraid of lambdas. they are more afraid of you than you are of them
10:43:58 <andythenorth> Eddi|zuHause: thanks
10:45:26 <Rubidium> in any case lambda's are almost people: Λ/λ vs 人 isn't that much of a difference
10:45:53 <Rubidium> s/'// (written too much Dutch lately)
10:46:32 <Eddi|zuHause> dutch makes extensive use of '?
10:46:57 <Eddi|zuHause> or you mean you are overcompensating? ;)
10:47:52 <Rubidium> Eddi|zuHause: if a word ends with a, i, o, u, y the plural is "'s"
10:48:07 <Rubidium> so, "lambda's" is plural for lambda in Dutch
10:48:22 <Eddi|zuHause> that sounds very confusing indeed ;)
10:48:46 <Rubidium> except when the word ends in eau, then plural is just s; e.g. cadeaus
10:49:10 <Eddi|zuHause> those are probably all french loan words ;)
10:49:33 <Rubidium> for extra fun, if it ends with s or f it becomes respectively zen and ven
10:50:10 <andythenorth> with 32 cargos, the highest ID is 1F yes? using 20 is an off-by-one error?
10:50:13 <Rubidium> e.g. huis -> huizen, but not always... fiets -> fietsen
10:50:59 <Alberth> andythenorth: assuming the first one has number 0, yes
10:51:00 <Eddi|zuHause> i don't know all the rules in german, but additional to adding "-s" you could also have to append "-en" or "-er" and turn the vowel into an umlaut to make plural
10:51:10 <Rubidium> and for extra added fun: if it's a abbreviation and ends with an s you add "'en", e.g. GPS'en
10:51:43 <Eddi|zuHause> e.g. "Haus" -> "Häuser"
10:52:14 <Eddi|zuHause> other times, you change nothing at all, especially when the word already ends with "-en"
10:52:21 <Eddi|zuHause> e.g. "Wagen" -> "Wagen"
10:52:33 <planetmaker> Teller -> Teller ;-)
10:53:02 <planetmaker> but "Vater" -> "Väter"
10:53:31 <Eddi|zuHause> i have no idea how foreign people learn that stuff :p
10:53:36 <Rubidium> what? DarkVäter... that would've been useful
10:54:20 <Eddi|zuHause> having two of them? ;)
10:56:08 <planetmaker> If there's "DarkVater", there's of course also "BrightVater" ;-)
11:12:46 *** ajmiles has joined #openttd
11:23:29 * andythenorth ponders adding Cement and Clay
11:23:52 <planetmaker> sounds like a circle
11:24:02 <planetmaker> where you started 20 months ago ;-)
11:24:15 <andythenorth> the answer is 'economies' :P
11:24:19 *** frosch123 has joined #openttd
11:41:36 <Eddi|zuHause> you need to finalize the cargo scheme somewhen :p
11:51:31 <frosch123> do you have set a reminder to alarm when 0.5 years passed?
11:53:05 *** roboboy has joined #openttd
11:55:23 <Alberth> for what??? their magical return?
11:57:58 *** Devroush has joined #openttd
12:06:23 <andythenorth> Question: FIRS provides a Bakery and a Brewery in most towns. Both accept Grain and produce Food. Which do you deliver to?
12:11:45 <andythenorth> Or is cake better than beer?
12:12:00 <frosch123> sm*tz would deliver the brewery
12:17:20 <Rubidium> cake is more yummy than beer
12:18:38 * andythenorth wonders if we can patch Tropic to remove Water for town growth
12:18:40 <Eddi|zuHause> maybe you need to give each one some distinctive features that makes it in some way better, in another way worse than the other
12:18:43 <andythenorth> then I can have the cargo slot
12:19:05 <Eddi|zuHause> andythenorth: maybe food can get both TE_FOOD and TE_WATER?
12:19:18 <andythenorth> how does that work?
12:19:23 <andythenorth> sounds interesting?
12:19:26 <Eddi|zuHause> how should i know ;)
12:20:21 <roboboy> well bear does contain warter
12:21:33 <andythenorth> me didn't know about town growth prop for cargos
12:21:40 <frosch123> yeah, give bear town effect water :p
12:22:04 * andythenorth lived in canada for a bit
12:22:12 <andythenorth> bear had a different effect in canada
12:23:04 <Eddi|zuHause> "Wenn du als Bär braun bist, dann kommst du in Bayern nicht mal lebendig über die Grenze!"
12:25:01 * andythenorth ponders making Goods behave as Water
12:35:48 <roboboy> out of interest, why does the wiki sugest I stick svn in a folder called local when setting up MinGW/MSYS?
12:36:51 <VVG> i wonder, was there ever an idea of defining a climate through newgrf?
12:36:54 <Rubidium> got question. Find out who added that bit of text and ask that person
12:37:25 <frosch123> VVG: define "climate"
12:37:58 <andythenorth> is Paper an interesting cargo?
12:37:59 <VVG> those map settings that get's changed when choosing a climate in newgame gui
12:38:39 <frosch123> ok, what is the difference between a "climate" and a "newgrf preset", except the gui at world creation?
12:38:58 *** wollollo has joined #openttd
12:39:54 <VVG> it was just a random thought that popped up in my head after reading last screen of your conversation here
12:41:15 <frosch123> too bad, you do not give me an opportunity to rant about the "canadian climate" :)
12:41:36 <lordaro1> roboboy: probably Petert, he re-did most of the page recently (ok, i think it was just after christmas)
12:42:17 <Hirundo> andythenorth: Cargoes on their own are rarely 'interesting', it's about their position in the big picture
12:42:44 <lordaro1> roboboy again: also, as you can see from that page, zlib is broken, there is a work around on the forums somewhere though...
12:42:51 <VVG> frosch123: sorry about that!
12:48:23 <frosch123> i think it is called canadian theme pack or so
12:50:01 <frosch123> it is a project which wants to replace basically everything (including the font), and does not cooperate with anything else. i.e. big monolithical crap
12:51:09 <VVG> sounds like they a keeping in line with the spirit of canadian train set
12:51:11 <dihedral> reminds me of alain :-P
12:51:56 <frosch123> canadian train set is part of the thing
12:52:16 <lordaro1> good news irc people!! AI Tournament is now functional! (at least, i think so, it generated some results that seem to be in roughly the correct order)
12:53:21 *** Progman has joined #openttd
12:53:55 <VVG> frosch123: yeah, know that
12:54:35 <VVG> i recall i got a bit frustrated when i tried to get canadian trains to behave friendly with other train sets i had loaded in a game
12:56:41 <frosch123> dihedral: but thanks to give me the opportunity :)
13:00:06 *** Adambean has joined #openttd
13:00:52 *** fonsinchen has joined #openttd
13:02:18 <dihedral> lordaro1, you really think all the "irc people" are interested? :-P
13:02:52 <VVG> doesn't look like virtual time patch is of any interest to anyone :(
13:04:04 <lordaro1> dihedral: well someone like Yexo or Rubidium or anyone else who's followed this from the start.
13:04:04 <lordaro1> wait. when did i become lordaro1?
13:05:21 <dihedral> i am guessing at least one of them is glad that it works, but only because someone else then stopps bugging them :-P
13:07:56 <VVG> Setting time_taken based on a gui setting, this is not quite multiplayer safe, is it?
13:08:19 <Rubidium> so you'd have to pass the rounding factor in the command (thought it did that)
13:08:54 <Rubidium> oh no, it just always rounds to days
13:09:35 <Rubidium> bad luck; then you'll need to pass some sort of rounding factor I guess
13:09:55 <Rubidium> in autofill timetable
13:10:17 <VVG> for now i only thought about setting rounding factor by some server side setting
13:10:31 <VVG> now i need to check on source code to see how autofill works :)
13:10:50 *** lordaro has joined #openttd
13:42:05 *** rhaeder has joined #openttd
13:47:31 <roboboy> hmph the machine I was setting MinGW up on just suddenly turned it's self off whilst compiling wget
13:51:22 <lordaro> lol, i have a computer that does that occasionally. i think it over-heats, but i'm not sure...
13:57:23 <roboboy> is there anything special I need to setup in MinGW for DOS compiling
14:02:12 <CIA-2> OpenTTD: rubidium * r20644 /trunk/src/ (6 files): -Codechange [FS#4086]: unify the vehicle breakdown code (Hirundo)
14:05:43 *** robotboy has joined #openttd
14:06:38 <robotboy> brb whilst I watch it compile wget
14:14:49 <CIA-2> OpenTTD: rubidium * r20645 /trunk/src/ (6 files): -Codechange [FS#4086]: unify the code for checking for breakdown handling as well (Hirundo)
14:19:07 <CIA-2> OpenTTD: rubidium * r20646 /trunk/src/vehicle.cpp: -Codechange: make the code flow of breakdown handling a bit clearer
14:29:11 *** |Jeroen| has joined #openttd
14:34:32 *** Biolunar has joined #openttd
14:39:35 <VVG> I introduced v->time_taken_rounding_factor, its value is set inside cmdautofill based on some bits passed there inside p2. updatevehicletimetables uses time_taken_rounding_factor when rounding. By default, rounding_factor = 1, DAY_TICKS in case of days. Is this ok considering network gameplay?
14:45:54 *** rhaeder has joined #openttd
14:46:22 <Hirundo> As I've stated before, why not make days and virtual minutes a multiple of one another and do away with all the complicated stuff, including virtual seconds which are too small for practical use anyway
14:47:25 <planetmaker> ^ multiplier? ;-)
14:48:28 <planetmaker> indeed it might be unneeded. Or does anyone play real-time?
14:48:32 <VVG> Hirundo: dunno. I use what is in ITiM
14:49:21 <planetmaker> think anew. Think concept :-) :-P Whatever the outcome then is
14:49:28 <Hirundo> There is most likely a reason that what is in ITiM is not in trunk
14:51:16 <Hirundo> I'll watch the whitespace next time Rubidium, thanks for including it this fast
14:52:27 <VVG> not sure, what can be achieved by making days and virtual time a multiple of each other
14:53:37 <Hirundo> For example, you don't need all this rounding magic, you can just round to DAY_TICKS
14:54:29 <Hirundo> Also you could probably get away with using something like _date / 60 and _date % 60 for hours and minutes, respectively
14:55:07 <Hirundo> Saving the lots of effort that is required to keep _virtual_time or whatever it's called in sync with the actual date/time
14:55:12 <VVG> do you suggest to base virtual time on days, and not on ticks? right?
14:55:59 <VVG> in that case, i don't see any point in doing so
14:56:11 <Rubidium> Hirundo: but what's 1 day then? 1 minute?
14:56:14 <VVG> as of now, it's a reference time system independent of days, whatever their length is
14:57:48 <Rubidium> if so you're probably going to have a lot of rounding trouble like why is 1 minute + 1 minute + 1 minute = 2:58?
14:57:56 <Hirundo> For me, calculating in hours/minutes is far easier than calculating the 60th day after february the 15th
14:58:51 *** robotboy has joined #openttd
14:59:33 <Hirundo> Those 99% who use stable OpenTTD don't care about daylength patches anyway, or about whether a minute is 60 or 74 ticks
15:00:05 <Rubidium> Hirundo: no, but the 1% that does will file bug reports
15:00:16 <Hirundo> Bug reports about what?
15:00:29 <Rubidium> rounding issues and the like
15:01:12 <Rubidium> FS#4084 is well... not a bug I'd see a stable user trigger
15:01:13 <Hirundo> If you keep one day = one minute, there should not be visible rounding issues besides the current
15:02:29 <Rubidium> oh, no seconds at all?
15:02:45 <VVG> well, there are vibisble rounding issues in trunk. By default it is rounding to days, and you can often see that vehicle is X ticks earlier.
15:04:33 <Hirundo> Does your (real world) timetable list trains that leave at 11:33:26 ?
15:05:27 <Hirundo> One point of attention would be, though, that things should not break too badly when using the date cheat
15:06:29 <Rubidium> nope, though AFAIK the Shinkansen's operator's timetable lists passings at "waypoints" (stations it doesn't stop) in seconds. There departing or arriving a few seconds late is already considered "bad"
15:06:30 <VVG> that's something yet to work out, they seem to break sometimes :)
15:08:38 * robotboy shall go and brush his teeth and then go to bed
15:13:19 <VVG> real world timetable operators, do they use seconds when making a new timetable?
15:16:14 <planetmaker> as mathematical basis
15:16:18 * Rubidium blames Duke University, RIPE NCC and Cisco for our unreachable (over IPv4) server of yesterday
15:28:03 *** Timmaexx has joined #openttd
15:29:39 *** Timmaexx_ has joined #openttd
15:36:44 *** devilsadvocate has quit IRC
15:55:03 <VVG> date cheat "breaks" timetables set with virtual time :(
15:56:04 <VVG> always, the sometimes part i meantion was because tt window didn't update while paused when i tested
15:59:05 * Lakie is looking over all the new spec currently.
16:00:08 <Lakie> If the slope check bit isn't set is it safe to assume using the old logic of tile must be flat?
16:00:29 <Lakie> Or should it just accept anything
16:01:05 <Rubidium> Lakie: depending on what "flat" exactly means, yes use the old logic
16:01:25 <Rubidium> in my logic "flat" means an area that is flat after foundations are built
16:01:27 <Lakie> Well, considering objects can be any size, I wasn't sure so decided on flat-flat.
16:01:53 <Lakie> Since foundations could be used if it was built of the side of a mountain
16:02:29 <Rubidium> Lakie: the logic I use requires the final "surface" to be at the same heightlevel
16:03:03 <Rubidium> (that diff is 95% copy-paste-edit, so might quite well be not right at all)
16:03:39 <Rubidium> although the objectflags comment in grfact.asm is (AFAICS) wrong, as well as the comment on var 43 (last chunk)
16:04:28 <Lakie> Well, var43 was changed fairly recently to return company colours with owner (as planned but not implemented).
16:05:04 <Lakie> And yes, I noticed it in the objects.inc it was marked dword but is actually a word. :/
16:05:14 <Lakie> I obviously failed to update comments.
16:06:52 <Rubidium> Lakie: but I hardly doubt that it *ever* returned the construction stage :)
16:07:10 <Lakie> Ah yes, I just noticed that
16:07:28 <Lakie> Lol, lots of stuff from the really begining spec is in comments. :S
16:08:08 <Lakie> I'll probably change the slope check slightly, checking the auto slope flag before doing any calcs
16:08:41 <Lakie> Due you think I should allow the instance pointer to go throuh for autoslope (I imagine allowing most 40/60 vars to be used?
16:10:11 <Rubidium> I'm not checking autoslope during construction at all
16:11:07 <Lakie> Ok, I'll try explain better when being modified by autoslope it calls the callback
16:11:36 <Lakie> Should it allow a instance pointer so the usual vars work or not (ie. construction time / menu)?
16:11:38 <Rubidium> then it gets an instance in my implementation (pretty hard not to give it)
16:11:53 <Rubidium> whether it's useful is something I'm not sure of
16:12:17 <Lakie> Well, I have been wondering myself, as it used to kill the instance (the xor esi, esi)
16:13:13 <Lakie> I suppose one could check the tiles around it for their current slopes via var62? to make a better decision?
16:17:20 <Lakie> I assume just disabling autoslope on grf not loaded and if bit not set will suffice also?
16:19:08 <Lakie> In which case "Custom slope check" would determine callback 157 and if not set it'd just check that it'd still be all the same (current) height level?
16:19:56 <Lakie> I say currently to prevent say a HQ dropping down a whole height level because each new tile would be the same new height.
16:20:18 <Lakie> each tiles' new height level would be the same*
16:21:23 <Rubidium> autoslope won't allow tiles to change height level in OpenTTD
16:21:52 <Lakie> Ok, well due to this small oversight mine could (which is a bug)...
16:22:30 <Lakie> But am I right in thinking the autoslope bit changes wheither it can be altered or not?
16:22:42 <Lakie> And the slopecheck is for callback 157?
16:23:58 <Rubidium> yes, slopecheck during construction of the object
16:24:12 <Rubidium> autoslope during changing slope under the object once it is built
16:24:42 <Rubidium> so during construction call callback 157
16:27:16 *** lobster has joined #openttd
16:28:18 <Lakie> Ok, I meant for autoslope, dopes it go can I alter (autoslope bit) -> call slope check -> should I call cb157 or just test still flat (slope check bit)?
16:29:16 <Lakie> Never mind, noticed the 15D, although that only allows either allowing or checking.
16:31:07 <Lakie> So I'd check the bit (assuming no as default), call the callback 15D, the follow the usual calc slope and ask grf via 157 or should I just make sure its flat (after adjustments)?
16:33:22 <Lakie> Originally I felt just allowing or denying autoslope too restrictive so decided to allow the grf to check the slope
16:33:36 <Rubidium> I think you don't understand autoslope
16:34:06 <Rubidium> stupid OpenTTD name I guess
16:34:32 <Rubidium> hmm, the name is in the spec
16:34:42 <Lakie> The idea is to allow alteration of the slope without destroying / rebuilding the tile, preferably without affecting the tile height.
16:35:23 <Rubidium> that isn't related to callback 157 in any way
16:36:59 <Lakie> I feel it is, whilst its simple for the majority to just allow or disable, I imagine there will be objects will accept some combinations but nt others, thus allowing all so long as height stays same may not work as intented but I can change it to the usual allow or reject if needed, much simplier
16:38:23 <Rubidium> Lakie: just use the simple method, i.e. keep it the same as industries/houses
16:39:37 <Rubidium> as for the landslope check to be ran properly you need to apply the changes first, then if it fails (says no) you need to revert everything
16:39:42 <Rubidium> which isn't that trivial
16:40:35 <Lakie> Well, actually I used to calculate the new slope before changing, downside is that it lead to the obvious issue
16:41:08 <Lakie> That without the tiles becide it, it wasn't possible to completely workout if it was dropping a level
16:41:30 <Lakie> Not from the grf anyway, my code should have checked it though
16:42:59 <Lakie> But going simple is easy enough, saves me quite some code
16:45:24 <Lakie> By the same whim, I assume you'd prefer objects without foundations deny autoslope?
16:47:37 <Rubidium> autoslope is enabled by default and the NewGRF has to disable it
16:50:30 <Lakie> This said, I'd still prefer to deny modification of objects whose grfs are not loaded
16:50:46 <Lakie> modifcation of slopes under objects*
16:50:58 <Rubidium> that sounds reasonable
17:00:25 <Rubidium> Lakie: in any case, I'd be extremely happy if you implement the real changes first. The real changes being new land slope callback number, callback flag for land slope callback, the xy -> yx swap (or is that just documentation being wrong?), and variable 42 from year -> date
17:01:35 <Lakie> Well, I'm working on it, as for xy/yx I'm unsure if its the doc or code wrong, will check that over, flag for the slope callback is simple enough, as ids changing autoslope
17:02:15 <Lakie> Not sure about var42 as it involves changing some internal structures so I'm looking over the save/load system to see if I can retreive a game saved with patch version x
17:02:35 *** lobstar has joined #openttd
17:02:37 <Lakie> (To migrate the structure over nicely)
17:03:06 <Rubidium> Lakie: a temporary solution would be to just get the year and multiply that
17:03:40 <Lakie> That was my thought, however ideally it should store the date anyway, so it still needs reworking. :)
17:05:56 <Rubidium> any problems with the proposed specs as written down?
17:06:23 <Lakie> Not really, I thik most of it is either cloning or reusing code from other places
17:06:46 <Lakie> 'cept maybe the towns but thats probably cloning too
17:07:06 <Rubidium> yup, it's mostly (copied) from industry(tiles)
17:11:33 <Lakie> I'll probably need to hook towns deletion so it deletes any objects built in the scenerio editor.
17:12:07 <Lakie> I don't think towns can be removed during a game so probably need not write mirgration code?
17:12:28 <Rubidium> yup, town's can't be removed during a running game
17:13:38 <Lakie> Although can't one open a game in the scenerio editor, so I guess I will have to after all. :/
17:13:51 <Lakie> Least there be objects disappearing (or a crash)
17:14:03 <Rubidium> Lakie: he can, but then removing a town should remove it's industries, stations and such as well
17:14:27 <Lakie> Removing a town removes the players stations?
17:14:43 <Lakie> In which case I suppose its valid to remove objects.
17:15:05 <Rubidium> hmm, no in OpenTTD it doesn't. It just disallows removal of the town until there are no depots/stations associated with that town anymore
17:15:21 <Rubidium> though that code might be a fairly recent addition
17:15:44 <Lakie> Ah ok, so I'd check for that also (probably added and just needs appending too, hopefully)
17:17:57 *** lobstar has joined #openttd
17:18:24 <Lakie> Ah, um, ok, well since I can't get the data of which game version saved it (or so it seems), I suppose the best option is to swap some variables around.
17:18:45 <Lakie> Downside is the this to a foobar date
17:20:05 <Lakie> (For objects built prechanges)
17:21:14 *** zachanima has joined #openttd
17:22:50 <Rubidium> you could loop over the map after loading and do: if (date == 0) date = year * 365;
17:23:29 <Lakie> True, I don't really even need to do it on the map, only the object pool
17:24:17 *** lobstah has joined #openttd
17:29:25 <CIA-2> OpenTTD: rubidium * r20647 /trunk/src/ (8 files in 2 dirs): -Codechange: update some of the object spec information
17:31:07 <CIA-2> OpenTTD: rubidium * r20648 /trunk/src/ (6 files in 3 dirs): -Codechange: implement the NewGRF override manager for objects
17:32:42 <CIA-2> OpenTTD: rubidium * r20649 /trunk/src/ (5 files in 3 dirs): -Codechange: implement classes for objects
17:35:08 <planetmaker> So additionally to a map covered with coal mine transportation wheel industries we'll it have covered in the other part with transmitters :-)
17:35:12 <CIA-2> OpenTTD: rubidium * r20650 /trunk/src/ (newgrf_object.h table/object_land.h): -Codechange: add some variables to the object's spec
17:36:41 <CIA-2> OpenTTD: rubidium * r20651 /trunk/src/ (newgrf_object.cpp newgrf_object.h object_cmd.cpp): -Codechange: add a function to determine whether an object is available and use it
17:38:20 <CIA-2> OpenTTD: rubidium * r20652 /trunk/src/ (newgrf_object.cpp newgrf_object.h): -Codechange: implement a function to get the index of a spec.
17:40:54 <TrueBrain> I see my favorite stalker returned
17:41:09 <planetmaker> hello TrueBrain :-)
17:41:28 <TrueBrain> I agree with the assement of dihedral, it gives the feeling of a stalker
17:41:54 <TrueBrain> I also wonder what is not understood about the 'unsupported' part of an 'unsupported patch'
17:42:19 <Rubidium> TrueBrain: obviously the "un" part
17:42:26 <planetmaker> :-) Well... YOU have written it. So the impossible has to be possible, hasn't it? :-P
17:42:42 <TrueBrain> planetmaker: of course 5000 revisions later it should still work flawless :)
17:42:48 <TrueBrain> just poorly programmed I guess :)
17:42:54 <DorpsGek> Is keeping track of everyone's last presence considered stalking ?
17:43:24 <planetmaker> presence != talking ;-)
17:43:27 <TrueBrain> then again, you are known to be a big stalker
17:44:24 <TrueBrain> but okay, without joking, was there any outstanding question regarding this dude?
17:44:33 <Rubidium> talking about your pet... what do you think of the fact that Duke University, RIPE NCC and Cisco conspired and blocked his internet access yesterday morning?
17:45:30 <CIA-2> OpenTTD: translators * r20653 /trunk/src/lang/ (5 files in 2 dirs):
17:45:30 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:30 <CIA-2> OpenTTD: simplified_chinese - 23 changes by ww9980
17:45:30 <CIA-2> OpenTTD: traditional_chinese - 2 changes by ww9980
17:45:30 <CIA-2> OpenTTD: esperanto - 6 changes by Christopher
17:45:32 <CIA-2> OpenTTD: icelandic - 108 changes by grjonib
17:45:32 <CIA-2> OpenTTD: thai - 6 changes by angelix
17:45:48 <TrueBrain> Rubidium: yeah, I made a BGP bounce request
17:46:24 <TrueBrain> rerouted his IP subnet over some transit lines via BGP rerouting, which caused a failure on the transit connection of his provider, putting it off for a few hours
17:46:28 <Rubidium> heh, maybe VirtualBox is/was doing something similar to that as well
17:46:28 <TrueBrain> easy if you know what you are doing
17:47:12 <TrueBrain> either way, I only see a 20 minute blackout?
17:48:17 <TrueBrain> the whole server was unreachable?
17:48:23 <TrueBrain> or only to a selective places?
17:48:39 <Rubidium> over IPv6 it was reachable, otherwise it wasn't
17:48:49 <planetmaker> ams-ix was missing 100GBit bandwidth at that time ;-)
17:48:52 <TrueBrain> Rubidium: also for you, it was unreachable?
17:49:01 <Rubidium> yes, except over IPv6
17:49:13 *** BlackTow3x has joined #openttd
17:49:18 <planetmaker> s/bandwidth/traffic/
17:49:35 <TrueBrain> core routers lost their BGP :D
17:50:41 <Rubidium> basically Cisco routers corrupted the valid (experimental) BGP updates
17:50:47 <TrueBrain> funny enough my (ISP) AS kept running ..
17:50:54 <TrueBrain> then again, we run Foundary
17:51:44 <TrueBrain> shows once again how vulnarable the BGP protocol is
17:51:55 <TrueBrain> and the way we create the BGP network (automated)
17:52:58 <TrueBrain> funny on the other hand is how fast diagnostic is done and reported on ;)
17:53:37 <planetmaker> I guess loosing 1/6 of the Dutch traffic is enough incentive ;-)
17:53:45 <TrueBrain> but okay, that it is Cisco only is the reason I didn't see it pass my desk yet :)
17:54:07 <planetmaker> it even showed in cix-de, but not that much
17:54:09 <TrueBrain> planetmaker: well, also, if no diagnostic is done, that AS will be disconnected from all other ASes instantly :)
17:54:33 <TrueBrain> so it is pretty critical for the AS causing the problem to get out ASAP that it was not his fault :)
17:55:00 <TrueBrain> as losing your (transit) connectivity is not something anyone would enjoy :)
17:55:02 <Rubidium> the probem here is that the corruption propagates
17:55:18 <TrueBrain> Rubidium: well, only one level. Then the session is reset
17:55:26 <TrueBrain> otherwise you would have seen a world-wide outage :)
17:55:46 <Rubidium> enough Cisco routers that bombed out :)
17:56:00 <TrueBrain> also shows tha tmost of the core routers are NOT cisco :D
17:56:10 <TrueBrain> be sane, use Foundary or similar :)
17:56:47 <TrueBrain> how often can you mistype :(
17:57:22 <planetmaker> that explains why only a little dip is seen in de... a lot of traffic to Northern America routes over Amsterdam.
17:57:27 <TrueBrain> back to my stalker: was there any topic I should read, or should I just not bother?
17:57:33 * Lakie starts copy/pasting code from newindustries...
17:57:56 <planetmaker> TrueBrain, I guess what you prefer ;-)
17:58:10 <TrueBrain> planetmaker: no, I ask you guys; I really REALYL do not feel like opening the forums
17:58:20 <TrueBrain> so if you say: nothing you can help with, I leave it :)
18:00:56 <planetmaker> IIRC Yexo tried it, too and there was something he didn't yet figure out - but which you would maybe know
18:02:03 <Rubidium> TrueBrain: you time will be better spent on WT3 / the website bugs
18:12:46 <Lakie> Rubidium: I think it's the documentatoin wrong over yx, since the code appears to do yx (y = 0x100, x = 0x1)
18:16:11 <Lakie> I assume just returning date in var42
18:18:30 *** BlackTow3x has left #openttd
18:21:23 <CIA-2> OpenTTD: rubidium * r20654 /trunk/src/ (newgrf.cpp newgrf.h newgrf_commons.cpp): -Codechange: implement reading action0 of objects
18:22:39 <CIA-2> OpenTTD: rubidium * r20655 /trunk/src/ (newgrf.cpp newgrf_object.h): -Codechange: implement reading the action3 of objects
18:23:26 <CIA-2> OpenTTD: rubidium * r20656 /trunk/src/ (4 files in 2 dirs): -Codechange: implement counting of objects
18:24:10 <CIA-2> OpenTTD: rubidium * r20657 /trunk/src/sprite.h: -Codechange: add function to draw NewGRF tileseq in the GUI
18:28:46 <CIA-2> OpenTTD: rubidium * r20658 /trunk/src/ (4 files in 2 dirs): -Codechange: add the colour of an object to the object instance
18:37:54 *** Phoenix_the_II has joined #openttd
18:38:11 <CIA-2> OpenTTD: rubidium * r20659 /trunk/src/ (6 files in 4 dirs): -Feature: make the (flat) area around an industry configurable (Eddi|zuHause)
18:39:07 * andythenorth wonders what that does :o
18:39:23 <Lakie> Rubidium: For sell factor do I assume like buy factor that if left 0, its unset?
18:39:32 <Lakie> Or would you prefer as 0xFF?
18:40:23 <Rubidium> yes, same behaviour as the buy factor
18:40:36 <Rubidium> *except* that if the buy factor is set, the sell factor is set to the same value
18:40:44 <Wolf01> uhm, I've been away for some time, any new?
18:40:49 <Lakie> I asked since some of the animation properties have default values
18:41:15 <Lakie> Yeah, well the fallback is to use the buy factor (*.2)
18:41:47 <Rubidium> okay, that's fine as well
18:42:00 <Rubidium> and if less than 5 it becomes 0?
18:42:33 <Lakie> I imagine you'd mul by cost then by .2
18:43:34 <Lakie> well, something like (buyfactor*basecost.objects)/5
18:43:47 <Rubidium> ah, okay. Makes sense as well
18:43:59 <Lakie> To avoid errors of below a 5th
18:44:16 <VVG> after giving some thought about making date cheat compatible with virtual time, i came to conclusion, it's easir to implement daylength patch where day is 24h virtual time long and vsecs_per_tick is configurable with a loong range :)
18:44:34 <VVG> which is out of my league :(
18:45:05 <SpComb> daylength patches sell like hotcakes
18:45:14 * SpComb considers charging for windows builds
18:46:57 <VVG> looks like they are too hot to make it into trunk for now
18:48:50 <SpComb> toss it in and see what happens?
18:49:00 <Zuu> hmm, I seem to lack motivation to do AI coding tonight. Oh well, I only promised to eventually take a look at the bug in CluelessPlus. :-p
18:49:31 <andythenorth> another fricking industry setting
18:49:47 <andythenorth> another combination to test
18:49:48 <OwenS> SpComb: CoD4:MW? Soo oldschool :p
18:49:53 <CIA-2> OpenTTD: rubidium * r20660 /trunk/src/ (4 files): -Codechange: implement (most) of action2 support for objects
18:50:01 <Terkhen> andythenorth: related to removing water?
18:50:13 <OwenS> SpComb: That would be MW2 '_
18:50:18 <glx> OwenS: but more recent can't do local network
18:50:42 <andythenorth> Terkhen: nah, it controls the industry platform
18:50:43 <OwenS> glx: I presume this is a limitation of the PC version only? :p
18:50:46 <CIA-2> OpenTTD: rubidium * r20661 /trunk/src/ (newgrf_callbacks.h object_cmd.cpp): -Codechange: implement the "decide colour" callback for objects
18:50:59 <SpComb> well who plays FPSs on consoles
18:51:27 <OwenS> Some of us got tired of nursing Windows installs to play games :p
18:51:33 <glx> FPS without keyboard+mouse is weird
18:51:34 <andythenorth> providing reliable industry map generation across the many possible combinations of settings is already difficult
18:51:41 <andythenorth> now it's approximately impossible
18:51:45 <andythenorth> so I'm going to stop trying :P
18:51:59 <CIA-2> OpenTTD: rubidium * r20662 /trunk/src/ (5 files): -Codechange: implement object animation
18:52:11 <andythenorth> you can laugh, but I have to waste my weekends testing :P
18:52:24 <Terkhen> it's a detail that can be sorted out once everything else is working already
18:52:34 * Terkhen would never play an FPS without a mouse
18:53:03 * Rubidium wonders when the last time was he played a FPS
18:53:28 <andythenorth> so there are now 10 settings that all affect industry placement, plus map size
18:53:29 <Rubidium> I *think* it was playing "tag" with "Unreal Tournament"
18:53:29 <OwenS> The only FPSes I play on PC these days are made by Valve...
18:53:35 <DorpsGek> andythenorth: Error: unexpected EOF while parsing (<string>, line 1)
18:53:40 <OwenS> OK, and perhaps occasionally ID
18:54:09 <SpComb> you just hold down space and run around
18:54:13 <Terkhen> andythenorth: there's no common solution for all settings
18:54:23 <andythenorth> what's the number of combinations from 10 independent variables?
18:54:25 <CIA-2> OpenTTD: rubidium * r20663 /trunk/src/object_cmd.cpp: -Codechange: add the GRF name to the tile info window
18:54:27 <OwenS> SpComb: And rocketjump ^^
18:54:43 <Lakie> Rubidium: Whats the default for "objectheight", 0?
18:54:43 <Rubidium> SpComb: it wasn't when I played it :)
18:54:58 <planetmaker> @calc factorial(10)
18:54:58 <DorpsGek> planetmaker: Error: 'factorial' is not a defined function.
18:55:04 <DorpsGek> planetmaker: Error: 'factor' is not a defined function.
18:55:18 <OwenS> bc's built in function list is lame
18:55:32 <andythenorth> @calc 3628800 * 3
18:55:32 <DorpsGek> andythenorth: 10886400
18:55:32 <CIA-2> OpenTTD: rubidium * r20664 /trunk/src/ (newgrf_callbacks.h object_cmd.cpp): -Codechange: implement the land slope callback for objects
18:55:39 <andythenorth> how many map size combinations are there?
18:56:19 <planetmaker> @calc 2**4 * 2**4
18:56:22 <andythenorth> @calc 10886400 * 256
18:56:22 <DorpsGek> andythenorth: 2786918400
18:56:32 <CIA-2> OpenTTD: rubidium * r20665 /trunk/src/ (object_cmd.cpp table/object_land.h): -Codechange: make clearing object tiles behave (more) like TTDPatch
18:56:39 <andythenorth> @calc 10886400 * 36
18:56:39 <DorpsGek> andythenorth: 391910400
18:56:48 <andythenorth> and there are 3 climates with different placement rules
18:56:57 <andythenorth> @calc 391910400*3
18:56:57 <DorpsGek> andythenorth: 1175731200
18:57:05 <andythenorth> I'm ignoring random seed :P
18:57:12 <Terkhen> then the only option is to find a method that work for all settings
18:57:30 <andythenorth> So I need to test 1.1bn combinations?
18:57:35 <andythenorth> I need more than a weekend :P
18:57:44 <CIA-2> OpenTTD: rubidium * r20666 /trunk/src/object_cmd.cpp: -Codechange: enable drawing of (NewGRF) objects
18:58:00 <Alberth> andythenorth: you didn't include devs messing with the industry code :)
18:58:10 <andythenorth> or the fact that some of the industry code is weird
18:58:18 <andythenorth> we found some stuff before that was just...broken
18:59:13 <Rubidium> @calc (2**32-1)*6*6*2*4*4*4*6*(2**4)
18:59:13 <DorpsGek> Rubidium: 1899956092354560
18:59:18 <andythenorth> maybe I can crowdsource the testing :P
18:59:35 <Rubidium> and that's without industries, towns or trees
18:59:57 <Rubidium> and without checking for duplicates
19:00:33 <CIA-2> OpenTTD: rubidium * r20667 /trunk/src/ (newgrf_callbacks.h object_cmd.cpp): -Codechange: implement the autoslope callback for objects
19:02:32 <CIA-2> OpenTTD: rubidium * r20668 /trunk/src/ (object_cmd.cpp station_cmd.cpp tunnelbridge_cmd.cpp): -Codechange: add (more) support for bridges over objects
19:03:02 <Wolf01> add stations too, you are already touching it...
19:04:04 <Rubidium> not sure whether that goes bit wise
19:05:36 <frosch123> they are even free for industries :o
19:06:02 <frosch123> ouch, i suppose that is another issue with the fields ... likely they are not bridgeable :p
19:06:28 <Lakie> Rubidium: property 13, bit 2, is that the tile proc of the northen tile by any chance?
19:06:31 <frosch123> well, the bits are free :)
19:06:49 <Wolf01> why not? fields existed from the beginning®
19:07:00 <planetmaker> Wolf01, not those ;-)
19:07:14 <Rubidium> Lakie: that answer was not meant for you, but for frosch
19:07:14 <Wolf01> oh, newfields... interesting
19:08:13 <Rubidium> Lakie: nope, it isn't. Don't know what the cycle length of that is
19:08:24 <frosch123> tileloop is 256 ticks
19:08:38 <Rubidium> then we could (still) make it that way
19:08:55 <Rubidium> is that (way) easier for you?
19:09:04 <frosch123> for some reason some objects are processed every 250 ticks, some every 256 ticks
19:09:33 <Lakie> Odd, well if they are already processed somewhere at 250 ticks I can work it so
19:09:35 <Rubidium> Lakie: then trigger 1 first, after that trigger 2?
19:09:44 <frosch123> hmm, s/objects/things/, "objects" might be a bad term here :)
19:09:50 <Rubidium> Lakie: I've added code to trigger it every 250 ticks
19:09:52 <Lakie> Its just if not I'd have to go find somewhere to patch
19:10:01 <Rubidium> so, the tileloop it is
19:10:19 <Wolf01> use "stuff" and you are always right
19:10:44 <frosch123> stations are processed every 250 ticks, industries every 256, so everything is different :)
19:10:46 * Lakie looks up how these triggers work
19:10:47 <planetmaker> frosch123, just change it all to 256 ;-)
19:13:35 <CIA-2> OpenTTD: rubidium * r20669 /trunk/src/ (landscape.cpp newgrf_animation_type.h object_cmd.cpp): -Codechange: trigger the whole object every 256 ticks instead of every 250 ticks
19:24:56 *** fonsinchen has joined #openttd
19:38:38 <Lakie> Rubidium: with your implmentation do you have animation stored on a per tile basis or the whole industry?
19:39:54 <Rubidium> you mean whether a tile is animated or not, right?
19:40:09 <Lakie> I meant the animation counter?
19:40:27 <Rubidium> yes, that's per tile
19:40:31 <Lakie> The tile being animated or not would be from that wierd little function handler?
19:41:03 <Rubidium> I store 8 bits (like industry tiles) on the map
19:41:18 <Rubidium> with some var60+x you can get the animation state of other tiles as well
19:41:40 <Lakie> Hmm... ok, might need to change a few things...
19:41:41 <Rubidium> the tile being animated uses the same stuff as industries as well
19:42:21 <Lakie> Mainly the yx stuff which shouldn't be too bad (I hope)
19:43:30 <Lakie> This said, I'm dropping cached flags
19:43:56 <CIA-2> OpenTTD: rubidium * r20670 /trunk/ (13 files in 4 dirs):
19:43:56 <CIA-2> OpenTTD: -Add: support for action F
19:43:56 <CIA-2> OpenTTD: -Add: a window to select (NewGRF) objects
19:44:05 <Lakie> Depending on where landscape 2 is used, I can probaby reuse that for per tile animation
19:44:48 <Rubidium> hmm... too late already?
19:45:07 <Lakie> Na, only var42 using it
19:46:10 <CIA-2> OpenTTD: rubidium * r20671 /trunk/src/ (6 files in 3 dirs): -Add: feature F (not action F as written mistakenly in the previous message) support for the scenario editor
19:46:49 <CIA-2> OpenTTD: rubidium * r20672 /trunk/src/lang/ (50 files in 2 dirs): -Remove: some stale strings
19:46:53 *** wollollo has joined #openttd
19:47:45 <Lakie> I suppose its more convient per tile, less overheads.
19:48:58 <CIA-2> OpenTTD: rubidium * r20673 /trunk/src/ (4 files in 3 dirs): -Codechange: add support for inspecting objects
20:06:49 *** welshdragon has joined #openttd
20:15:59 <CIA-2> OpenTTD: alberth * r20674 /trunk/src/ (6 files in 2 dirs): -Codechange: Remove declared functions that do not exist (anymore) otherwise.
20:22:50 <Lakie> Rubidium: I notice the newhouses / industries code has sound in its retun, should I also support that or just ommit it?
20:24:24 <dihedral> Interesting commits there rubidium
20:24:33 <Rubidium> Lakie: OpenTTD does the sound stuff for objects as well
20:24:49 <Lakie> So carbon copy bar the storage location
20:24:50 <Rubidium> just as the animation code is generic
20:25:18 <Rubidium> actually OpenTTD stores the animation frame/stage/state in the same location as well :)
20:25:21 <Lakie> It could easily be generic here, but meh, someone didn't bother with it
20:25:43 <Rubidium> Lakie: neither did anyone in OpenTTD, until I removed the duplication a few days ago
20:26:09 <Rubidium> Lakie: that's the benefit of our map format. If it suits us we can reorder stuff (unification!)
20:26:40 <Lakie> Well, its easier to do that in c++ than asm. :(
20:49:21 *** JVassie has joined #openttd
21:03:37 *** PhoenixII has joined #openttd
21:08:56 *** Phoenix_the_II has quit IRC
21:20:20 *** fmauneko has joined #openttd
21:32:18 <frosch123> isn't it amazing that a year has exactly as many months as there are bits in 3 nibbles?
21:33:03 <SpComb> unless it's a year with a leap-month
21:35:15 <frosch123> ottd should support the Iranian Calendar
21:35:37 <VVG> what about chinese or mayan?
21:36:06 <SpComb> gotta drop your western mindset
21:36:58 <VVG> what about russian calendar?
21:39:20 <frosch123> anyway, that calender with the october revolution
21:39:34 * frosch123 hopes he did not mess everything up
21:41:22 <ShawnR> Question, is there anyway to drag things like the sign list or map outside of the openttd window?
21:41:36 <VVG> that's a thing of the past!
21:42:04 <Eddi|zuHause> frosch123: that's the julian calendar. in the gregorian calender, the october revolution is in november
21:42:10 <VVG> i have to admit i had no idea there was so much involved into calnder :(
21:42:21 <ShawnR> well, i'm runing dual monitors and i wanted to actully beable to use both monitors while playing. Thanks
21:42:40 <Alberth> make a multi-monitor openttd window
21:43:07 <SpComb> with every other day off?
21:43:29 <Eddi|zuHause> the gregorian calendar is synchronized to the julian calendar at around 300 A.D.
21:43:34 <Alberth> better 5 days work, 5 days free :)
21:44:18 <frosch123> SpComb: i prefer xkcd's 28-hour days
21:44:48 <Eddi|zuHause> yes, we need a metric week ;)
21:45:43 <Eddi|zuHause> in metropolis (movie, 1927) they had a metric clock that showed 10 hours
21:45:56 <CIA-2> OpenTTD: rubidium * r20675 /trunk/src/newgrf.cpp: -Add [FS#4077]: method to access the (action 14) NewGRF version of other NewGRFs
21:46:59 <Eddi|zuHause> man... i spent the evening in a "Bierzelt", and now i have hundreds of crazy tunes in my head...
21:48:10 <Eddi|zuHause> why does a copying process over a 100MBit network take only 4MiB/s?
21:48:59 <Rubidium> encryption limits speed?
21:49:17 <Rubidium> you're using SMB that floods with a ginormous amount on UDP packets?
21:49:24 <VVG> i think i got confused here
21:49:25 <Wolf01> I'll invent a DEG clock where ours are based on the Hearth's rotation... uhm.. maybe I've already seen it in the Flinstones
21:49:42 <VVG> it's still a gregorian calender, that was in use before WW2 in USSR
21:49:45 <Eddi|zuHause> Rubidium: i'm using SMB, yes. not sure what it actually does on the physical network
21:53:24 <Eddi|zuHause> lots of commits today...
21:57:37 *** Brianetta has joined #openttd
22:01:20 *** b_jonas has joined #openttd
22:01:34 <VVG> it seems i can't just give up the idea of using vsec_per_tick as a base for daylenght patch, it just keeps popping up in my head :(
22:02:26 <SpComb> ticks per day, days per tick
22:02:48 <Eddi|zuHause> VVG: i don't think that's any kind of good approach
22:02:52 <SpComb> or is time and day freerunning?
22:03:10 <SpComb> ie. not tied to eachother
22:03:32 <VVG> premise is, day is 24h long, 84600 seconds. one tick is customizable amout of seconds, from 1 up to 100 may be
22:03:38 <Eddi|zuHause> the only purpose of virtual time is synchronising timetables
22:04:03 <VVG> they "break" with current implementation when using date cheat :(
22:04:07 <Eddi|zuHause> Wolf01: no, that's not virtual time
22:04:20 <b_jonas> play longer? you can play forever
22:04:59 <b_jonas> do you mean get the years pass longer so you have to wait more for new technology?
22:05:39 <b_jonas> instead of changing time, can't you just change the dates in the grf for that?
22:05:50 <Wolf01> I like to play at full speed and see my vehicles and trains riding fast, but years pass fast too
22:08:12 <Wolf01> elrail introduction: year 2355
22:08:50 <Eddi|zuHause> VVG: not for impkementation, no
22:10:02 <VVG> some other solution needed then to keep the timetables set with virtual time in sync when using date cheat then :(
22:11:19 <Eddi|zuHause> VVG: doesn't that only need setting the start date upon switching the year?
22:12:21 <Eddi|zuHause> i never used the date cheat, how does that work in trunk anyway?
22:12:23 <VVG> the actual arrival/departure times shown change when date cheating
22:12:41 <VVG> call setdate with new parameters
22:13:06 <Wolf01> run 2 dates, date A which is tied to the gui, the grf introduction dates etc, date B starts from 0 and not changeable, tied with timetables and other date-breakable functions
22:13:07 <Eddi|zuHause> VVG: yes, the arrival times change
22:13:54 <Eddi|zuHause> VVG: you als also check the max-year-loop
22:14:12 <Wolf01> it's just to add another date variable, initialise it at the beginning of the game and save it to the savegame
22:14:42 <Eddi|zuHause> Wolf01: but that variable can overflow
22:15:26 <Wolf01> not if both are initialised at the same value instead of 0
22:15:30 <Eddi|zuHause> VVG: at the end of max_year, the date is set back to beginning of max_year
22:16:27 <VVG> i doubt there are many people playing till year 5000000
22:16:48 <Wolf01> VVG, I might start a game in year 499999
22:16:48 <Eddi|zuHause> VVG: don't doubt. prove.
22:17:52 <Eddi|zuHause> VVG: some crazy person might want to make the loop-year configurable
22:17:57 <VVG> prove what? atm playing at year 500000 should break virtual time, since it's _date*DAY_TICKS that virtual time is based on
22:18:11 <Wolf01> ram based date variable, more the ram you have, more you can play
22:19:21 <Wolf01> ok, I think I'm tired enough today...
22:19:34 <Eddi|zuHause> Wolf01: i mean someone might want to set the loop year to 2030 or something
22:19:51 <VVG> is that configurable in config?
22:20:07 <Eddi|zuHause> VVG: no, currently only in the code
22:20:37 <Eddi|zuHause> VVG: the point is, it's possible, so your patch needs to handle it
22:20:48 <Eddi|zuHause> there is a loop year even in trunk
22:21:05 <Eddi|zuHause> even if it is "unlikely" that someone reaches it
22:21:38 <Eddi|zuHause> someone at intel also calculated that it is "unlikely" that people hit the pentium bug...
22:22:08 <planetmaker> 640k RAM should be enough for all
22:22:32 <planetmaker> and this programme won't be used anymore in year 2k ;-)
22:22:38 <VVG> original patch didn't consider it, so i didn't too. Even though that logic is flawed, there is anothor argument here that stops me from considering such a case - i have no idea how to handle it :)
22:22:49 <Eddi|zuHause> the pentium bug was giving incorrect results in certain float-divisions
22:23:54 <Eddi|zuHause> but the calculation by that intel guy was based on a flawed distribution of float numbers
22:24:11 <Eddi|zuHause> someone else did the calculation with another distribution, and came to a much higher chance
22:24:31 <Eddi|zuHause> which then caused intel to withdraw the product
22:24:46 <Eddi|zuHause> and call back the already sold units
22:24:57 <Rubidium> Lakie: I'm removing varact64 (seems that 65 does the same), to 65 becomes 64 now
22:25:26 <Lakie> Currently working throiugh animation and triggers.
22:25:54 <VVG> well, back to original ida of mine, loop year thingie can be done combining day lentgh and virtual time, making a day 24h long. Loop year breaking current implementaion of virtual problem solved :)
22:26:05 <Lakie> For the tile proc, should I call the global followed by the tile one for the north tile?
22:26:12 <Lakie> Or the other way round?
22:26:38 <CIA-2> OpenTTD: rubidium * r20676 /trunk/src/newgrf_object.cpp: -Codechange: it's not needed to supply two almost identical vars
22:27:09 <Rubidium> Lakie: The synchronised periodic tile loop is called directly after the (unsynchronised) periodic tile loop of the northern tile.
22:27:24 <Rubidium> i.e. the "global" after the "tile" one
22:27:31 <Lakie> Ah, ok, I had it in the reverse order.
22:28:34 <Eddi|zuHause> # Schnapps, das war sein letztes Wort
22:28:42 <Eddi|zuHause> # Dann trugen ihn die Engel fort
22:28:56 <Eddi|zuHause> (*please get it out of my head*)
22:29:19 <Eddi|zuHause> Rubidium: luckily, that song is long forgotten ;)
22:30:27 <Rubidium> why do I remember it then?
22:34:01 <Eddi|zuHause> "Das Jodeln wurde von Japanern erfunden"
22:34:02 <Eddi|zuHause> "Eine Gruppe Japaner wanderte durch die Alpen, als ihnen das Radio den Abhang hinuntergefallen ist."
22:34:04 <Eddi|zuHause> "Da riefen sie einem Wanderer weiter unten zu:"
22:34:05 <Eddi|zuHause> "Hol du die Ladio?"
22:37:24 <Eddi|zuHause> Rubidium: it's ok, as long as it's in quotes ;)
22:37:54 <Eddi|zuHause> and it's really not translatable
22:38:44 <planetmaker> indeed... but... "long forgotten" and a quote here... that's rather an oxymoron
22:39:57 <Eddi|zuHause> planetmaker: -ENOPARSE
22:41:26 <planetmaker> you quote a long-forgotten song. That is an oxymoron. Obviously
22:41:36 <planetmaker> a contradiction in itself
22:41:53 <Eddi|zuHause> planetmaker: no, i said the one mentioned by Rubidium is long forgotten
22:42:55 <planetmaker> even then ;-) If you didn't recall, you couldn't state that it is forgotten ;-)
22:44:31 <Eddi|zuHause> planetmaker: well, technically, it's a 50/50 chance between "forgotten" and "never existed" ;)
22:45:44 <planetmaker> how do you determine such probability?
22:46:03 <planetmaker> (these hairs certainly can be cut even WAY more :-P)
22:46:16 <Eddi|zuHause> assuming a flawed distribution ;)
22:46:26 <frosch123> Eddi|zuHause: next time please drink so much that you cannot type anymore
22:46:50 <Eddi|zuHause> frosch123: that's difficult, because i always have a ~20km drive home...
22:47:21 <frosch123> agreed, then "cannot type anymore" might be a bit rude
22:47:37 <Eddi|zuHause> but my keyboard doesn't type well anymore
22:47:58 <Eddi|zuHause> i think either the batteries are going empty, or my USB port finally gives up...
22:53:59 <Eddi|zuHause> hm... why do dolphin, kio_file and kio_smb use 33% CPU each?
22:54:53 *** nicfer1 has joined #openttd
22:56:06 <Eddi|zuHause> that could explain the funky responsiveness that the keyboard gives me...
22:56:21 <Lakie> Rubidium: I don't suppose you'll go for the behaviour of just using the old object animation behaviour if objectanimframes is -1, which was inc aimation every 4 ticks of the animcounter?
22:58:42 <planetmaker> Lakie: is there a newgrf which uses it?
22:58:52 <Lakie> Most of the old spec ones
22:59:35 <planetmaker> hm. And there's presumably another method to the same end now, right?
23:00:08 <planetmaker> hm. seems redundant
23:00:43 <Lakie> True, though one can set the flag for animated and leaved animed frames -1
23:00:45 <planetmaker> I'm missing oversight how many or big those existing newgrf are
23:01:10 <Lakie> The spec was only starting to be adopted (after 2 years of nothing)
23:01:11 <planetmaker> in which case I'd skip a legacy setting
23:01:38 <planetmaker> he, that's a big latency time
23:02:51 <Rubidium> Lakie: yep, though actually once every tick unless the NewGRF changes that
23:03:06 <Rubidium> (default of 0 is easier than default of 2)
23:03:44 <Lakie> Though I'm not sure test <vl>, 0 would work as planned
23:04:00 <Lakie> I suppose it would always be true though
23:04:48 <Rubidium> Lakie: for stations animation speed's lower limit is 0, so it must be possible
23:05:14 <Lakie> Was mainly working through industries
23:05:44 <Lakie> Looks like it should work as intented
23:09:36 *** last_evolution has quit IRC
23:27:05 <Rubidium> frosch123: growth speed should ofcourse be PGP signed :)
23:27:08 *** KenjiE20 has joined #openttd
23:27:29 <planetmaker> there we are back at the black boxes
23:27:42 <planetmaker> only play-able with OpenGFX < 0.2
23:28:11 <frosch123> hmm, periodical callback to send email?
23:28:48 <Rubidium> no, just PGP signing the town growth so we know it's genuine
23:29:45 <planetmaker> Rubidium: nothing. But town growth is not for people < 18
23:30:07 <frosch123> good point, access to storage of other grf should need a password
23:38:16 <Eddi|zuHause> hm... i'm not entirely sure what happened now... the copying is over, but now i have 90% "wa" cycles
23:39:19 <Eddi|zuHause> Rubidium: for more than 10 minutes?
23:40:47 <Eddi|zuHause> i closed all dolphins, but when i read iotop correctly, two dolphin instances are swapping like hell
23:44:06 <Eddi|zuHause> i now killed everything in "ps aux | grep dolphin", now swap dropped from 1.5GB to 700MB
23:44:26 <Eddi|zuHause> and io now seems back to mormal levels
23:45:28 <Eddi|zuHause> while at it, what's an nscd?
23:45:54 <Rubidium> name service cache daemon
23:46:00 <Eddi|zuHause> ah... a name service cache demon
23:46:44 <Rubidium> though it doesn't seem that useful for a home computer
23:46:55 <Rubidium> caching passwd and groups
23:50:04 <Eddi|zuHause> i stopped it, and nothing seems to have changed... so i guess i really don't need it
continue to next day ⏵
