IRC logs for #openttd on OFTC at 2010-08-21
⏴ go to previous day
00:13:31 *** theholyduck has joined #openttd
00:26:37 *** ChanServ sets mode: +v tokai
00:45:31 *** roboboy has joined #openttd
01:03:22 *** ChanServ sets mode: +v glx_
01:39:53 *** roboboy has joined #openttd
01:52:38 <TruePika> I'm just wondering, what's the benefit of NOT taking a prototype vehicle?
01:53:23 <TruePika> I mean, it asks you, so there should be a benifit for not taking it
02:00:49 <Eddi|zuHause> prototypes may have bad reliability
02:01:03 <Eddi|zuHause> so they might not be particularly useful
02:02:23 <Eddi|zuHause> also, you might not have a need for this particular vehicle, and if you don't build it, you won't get any more prototype offers in the future
02:02:43 <Eddi|zuHause> e.g. if you have only trains, you might not be interested in a truck
02:04:01 <Eddi|zuHause> this can also apply if you don't have a lot of money to spend on new vehicles
02:09:26 <TruePika> But you can take the offer, but not build it, for example
02:18:37 *** roboboy has joined #openttd
02:25:23 *** rhaeder1 has joined #openttd
04:30:10 *** tetrahedonism has joined #openttd
04:32:47 *** Keyboard_Warrior has joined #openttd
04:39:52 *** roboboy has joined #openttd
04:56:22 *** Eddi|zuHause has joined #openttd
05:27:27 <TruePika> What is the ratio for ticks:days?
05:36:04 <TruePika> I checked the page from the Forum, and the number of ticks per day seems rather odd (74); I would have expected a fraction or a number 2^n
05:37:47 <TruePika> I thought that I read somewhere that the ratio was 3.5 days/256 ticks ~= 73.143 ticks per day, which does not round to 74
05:38:22 <TruePika> So could someone tell me the exact ratio, or at least the source file which would have it?
06:03:50 <TruePika> Lol, I was just reading a security tip for disabling root login by ssh, and there were comments. The last one mentioned that they couldn't find a specific file in their distrubution. "Does that mean that there isn't a problem and that I can ignore it?"
06:36:17 *** Kurimus has joined #openttd
06:37:42 *** ^Spike^ has joined #openttd
07:02:03 *** devilsadvocate has quit IRC
07:02:18 <planetmaker> tab completion fail :S
07:35:09 *** Progman has joined #openttd
08:32:19 *** TomyLobo has joined #openttd
08:34:10 *** roboboy has joined #openttd
08:55:28 *** frosch123 has joined #openttd
09:15:36 *** Keyboard_Warrior has quit IRC
09:20:04 *** trebuchet has joined #openttd
09:44:45 *** SmatZ is now known as Guest337
09:44:46 *** smatz_ is now known as SmatZ
09:54:08 <Eddi|zuHause> why did the forum just tell me the nightly backup was running?
09:56:48 <andythenorth> Oil Wells or Oil Field?
09:57:18 <planetmaker> oil wells pump the oil out of an oil field (which is below Earth)
09:57:23 *** thvdburgt has joined #openttd
09:57:34 * andythenorth peers into lang files
10:03:19 *** buttmonkey has joined #openttd
10:15:24 * andythenorth ponders slopes / foundations
10:15:47 <andythenorth> currently *all* building on slopes uses foundations
10:16:12 <andythenorth> in RL the alternative way to build on slope is to take ground away and build a retaining wall
10:16:31 <andythenorth> I could do this in FIRS, but it doesn't fit with the rest of the game world
10:16:42 <SpComb> there were some mockups of cuttings/retaining walls in the TTDPatch forums eons ago
10:16:47 <SpComb> it would be quite useful
10:17:21 <SpComb> but it would require a certain amount of revamping of the construction/landscaping interface
10:17:29 <Yexo> you should be careful with that though, it might look very strange if the tile next to it gets a foundation, (ie retaining wall + foundation above it)
10:17:32 <SpComb> good thing might be that it would lead towards underground building as well :)
10:18:00 <andythenorth> Yexo: sounds like what already happens with building on steep slopes?
10:18:03 <Yexo> depening on the side of the tile it might be invisible
10:18:14 <Yexo> andythenorth: could be, no idea what actually happens in that case
10:18:28 <andythenorth> steep slopes can produce two layers of foundation
10:18:38 <andythenorth> if I add retaining walls...that would be three layers of foundation :o
10:19:39 <Eddi|zuHause> andythenorth: it may be a problem if the retaining wall is _behind_ the foundation
10:19:59 <andythenorth> I don't think that would happen
10:20:30 <Eddi|zuHause> the tile might disappear and become unclickable
10:20:55 <andythenorth> Eddi|zuHause: unlikely, I tested something like this for FIRS before. I couldn't make it look good so I stopped
10:21:07 <andythenorth> it doesn't need any new code, it's just how the tile is drawn
10:21:24 <andythenorth> or how multiple layered sprites are arranged
10:21:38 <andythenorth> it's a visual effect, the slope still exists under the tile as normal
10:22:02 <andythenorth> but it would be a *lot* of work to make it look good :P
10:22:46 <SpComb> can't see anything under-slope there
10:23:23 <andythenorth> no, that's the current situation. That's what I'm wondering about improving ;)
10:24:27 <Eddi|zuHause> might be my side, but it doesn't load properly...
10:25:26 <andythenorth> Eddi|zuHause: :o it's just a (big) png
10:26:17 <Eddi|zuHause> maybe my line is just congested
10:26:24 <Eddi|zuHause> seems to have finished now
10:26:49 <Eddi|zuHause> looks fine to me
10:31:28 *** roboboy has joined #openttd
10:36:27 *** KenjiE20 has joined #openttd
10:36:47 <andythenorth> can I rename Forest as Logging Operation?
10:37:04 *** thvdburgt has joined #openttd
10:38:06 <[hta]specx> I had an idea; Im not sure if its feasbile. But the idea is to add another build option; where the player can build elevated concrete plateau's. A sort of one-time 3D building
10:38:39 <[hta]specx> just 1x1 tiles players can put on top of tracks/roads, on whih players can built more tracks/roads
10:41:27 <[hta]specx> I have seen patches where vertical building is tried to implemented but they all fail since its seemingly very hard to implement a good UI for vertical building (which level to display?). This idea would be a simple compromise. But although I have read quite some ottd code, its not enough to be able to say whether it can be done without too much patching
10:43:01 *** fmauneko has joined #openttd
10:43:23 *** fmauneko has joined #openttd
10:43:48 *** Alberth has joined #openttd
10:44:09 <[hta]specx> It's inspired by the dutch construction sector, where the chairman said: new dutch cities should be build from the ground up, literally
10:49:07 <Rubidium> [hta]specx: they are pretty stupid in that case
10:49:13 *** Biolunar has joined #openttd
10:51:00 <Rubidium> because they would instantly sink in the soggy ground where most of the cities are built
10:51:09 <[hta]specx> makes perfect sense to me to first build a metro system, then a layer of some sort of public cargo railnetwork, then a layer of tubes for trash, then a layer of houses
10:51:35 <[hta]specx> they didnt say foundations wheren't needed anymore ;)
10:52:09 <Rubidium> so they build from the ground down, and after that they go into the heights
10:52:53 <[hta]specx> when foundations are put in place, they build from the ground up ;)
10:53:24 *** ajmiles has joined #openttd
10:54:44 *** Devroush has joined #openttd
10:57:25 <CIA-2> OpenTTD: rubidium * r20586 /trunk/Makefile.grf.in: -Codechange: silence nforenum and grfcodec progress output (if possible)
10:59:17 <CIA-2> OpenTTD: frosch * r20587 /trunk/src/widget.cpp: -Codechange (r20456)[FS#4035]: Revert to scrollbars without minimal size to simplify window setup.
11:30:53 <CIA-2> OpenTTD: rubidium * r20588 /trunk/Makefile.grf.in: -Fix (r20586): apparantly some NFORenums don't return an error code when an unknown command line option is given
12:11:31 *** Adambean has joined #openttd
12:27:18 *** theholyduck has joined #openttd
12:51:05 <VVG> http://pastebin.ca/1921994 i have that piece of code to compute the starting date of timetable and an offset value in ticks, if needed. that offset value later is goes to lateness_counter when Updatevehicletimetable runs. The code doesn't seem to work properly, i'm loosing some ticks. 40 ticks on one paused save game of mine, when 1 sec = 1 tick. Or even more if it's more vsec per tick. Can't
12:51:05 <VVG> figure out why that happens
12:53:49 <Alberth> more, probably, 1 game day = 74 ticks = about 2.3 seconds real time
12:55:38 <VVG> ? by sec i meant one virtual sec. it's counted in ticks.
12:59:23 <Alberth> VVG: I have no clue what is done there, but did you check the calculations?
12:59:25 <Rubidium> it's 33.(3) ticks a second
13:00:11 <VVG> Alberth: that's what i'm trying to do :)
13:00:20 <Alberth> VVG: one way is by using the debugger, another one is to output computed values to stdout
13:00:25 <Alberth> (if that exists in windows)
13:01:03 <VVG> this looks like a time i have to learn to use debugger
13:01:13 <avdg> just create extra widgets :p
13:01:28 <avdg> or drop values in your console
13:01:30 <VVG> there i can check exact values of all kinds var and what's happening, step by step, right?
13:01:50 * Rubidium wonders whether the "wrong" offset is always wrong in the same way
13:02:14 <Rubidium> i.e. whether the starting date is always too early or always too late (without regarding those precisely on time)
13:02:16 <VVG> how can i output some var into console of openttd?
13:03:04 <VVG> the actual date in days is supposed to be early by offset value
13:03:07 <Rubidium> might be that you're adding instead of subtracting in he command
13:03:32 <Rubidium> or updatevehicletimetable or whatever it's called
13:04:22 <VVG> that's the relevan bit from updatevehicletimetable
13:04:44 <Rubidium> does changing that to a + solve the issue?
13:04:57 <VVG> i must admit i didn't check that :(
13:13:42 <VVG> it makes no difference o_0. This leads me to a conclusion i don't properly set offset value.
13:18:26 <VVG> if i use SB(vehid_and_offset, 20, 12, timetable_start_offset) and then GB(p1, 20, 12), i get save value, right?
13:18:44 <VVG> vehid an p1 being one var
13:19:30 <Rubidium> yes, assuming you assign the return of GB to something
13:20:06 <VVG> can i check current _date_fract from console?
13:20:41 <Alberth> not much use, it changes constantly
13:21:11 <Alberth> you need to know it when you are in your function
13:21:19 <VVG> savegame of mine i check the code on is paused and from trunk
13:21:43 <VVG> i wonder what it's current value there is
13:22:31 <Alberth> I simply use printf() in the code to output such info
13:22:44 <Alberth> but I don't know whether that also works with windows
13:29:42 <thvdburgt> The horse carriages of eGRVTS don't like realistic acceleration; they have 0hp power and travel 1km/h
14:01:29 *** bartavelle has joined #openttd
14:04:53 <Rubidium> jordi: any idea how long I should wait for a reply from the (Debian) release-team before poking them (on IRC)?
14:05:36 <Eddi|zuHause> 2 minutes, use all uppercase, lots of 4 letter words and exclamation marks
14:06:07 <Rubidium> nah, I did send them an email on wednesday
14:06:52 <Alberth> then leave before anybody has a chance to answer
14:10:28 <frosch123> hmm, is there something like an uppercase exclamation mark?
14:12:12 <Rubidium> frosch123¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
14:12:44 <Rubidium> ¡¡¡¡¡¡¡¡¡¡frosch123!!!!!!!!!! would be more correct
14:16:19 * planetmaker 's ears are ringing
14:16:33 <Eddi|zuHause> somebody is thinking of you
14:19:18 *** roboboy has joined #openttd
14:19:51 <frosch123> Rub¡d¡um: do you have a highlight for that?
14:20:55 <Rubidium> frosch123: no, but Rub, d and um do
14:31:56 *** Cybertinus has joined #openttd
14:34:24 *** Cybertinus has joined #openttd
14:42:01 <VVG> I found a way to see what values i have: char ssstr[32]; snprintf(ssstr, 32, "%d", vehid_and_offset); IConsoleWarning(ssstr); :)
14:43:27 <Eddi|zuHause> VVG: what happened to Debug()?
14:44:51 *** |Jeroen| has joined #openttd
14:44:55 <VVG> i have no idea about it and how to use it. My simple attempt to figure it out failed
14:45:21 <Rubidium> Eddi|zuHause: got renamed to DEBUG? Has maybe difficult to understand params? Doesn't dump to the in-game console?
14:46:06 <Eddi|zuHause> wasn't there "developer" setting to redirect this to the console?
14:46:15 <Eddi|zuHause> or do i mix up things there
14:47:21 <Rubidium> then he doesn't know what setting it is
14:48:44 <VVG> if i rung a debug compile i have a console window. I accidentaly complied the version 17629 as debug and console had some dbg messages about nested widgets. But how to take advantage of that i do not know
14:49:53 *** HerzogDeXtEr1 has joined #openttd
14:50:59 <Alberth> printf("hai\n"); does not end up there?
14:52:12 <VVG> dunno, it's was a bit too high level to figure out to try :)
15:03:15 <Eddi|zuHause> VVG: using the debug macro/function or making a debug build are two entirely different shoes
15:24:19 *** ChanServ sets mode: +v glx_
15:39:24 *** devilsadvocate has joined #openttd
16:05:48 *** ChanServ sets mode: +v tokai
16:17:48 *** Chillosophy has joined #openttd
16:39:59 <Rubidium> if he doesn't even stay long enough for us to welcome him...
16:45:37 <VVG> ottd lacks tilde->q->tab->enter way to quit :)
16:49:12 <Rubidium> the debug build does, somewhat
16:51:23 <VVG> in debug build? in release alt+0 does nothing for me
16:59:08 <Rubidium> why do you think I mentioned debug builds?
17:00:16 *** mib_909f6j has joined #openttd
17:01:17 <VVG> it wasn't clear to me, hence the question
17:31:50 *** TheMask96 has joined #openttd
17:37:21 *** Adambean has joined #openttd
17:38:20 *** jrabbit has joined #openttd
17:38:31 <jrabbit> what happened to the nice mac builds?!?
17:39:53 <Noldo> there should be quite a lot of information and discussion about that in the forums
17:39:54 <jrabbit> I mean wtf... theres not even a fink package
17:39:59 <Rubidium> they got discontinued
17:40:13 <jrabbit> put it on the main site or request someoen to take over
17:40:29 <Rubidium> jrabbit: did so for many months, nobody took over
17:40:40 <jrabbit> jfc I don't have time to package some other app that managed to blow their nice buidl setup up
17:41:37 <Rubidium> and we didn't blow the build setup. It still works; we just don't publish binaries anymore
17:42:45 <Rubidium> but with all open bug reports at the time of branching 1.0 were Mac OS X bugs it was quite clear there was nobody caring enough about Mac OS X
17:42:55 <jrabbit> thats a method of providing your program that was fairly stable
17:43:42 <planetmaker> jrabbit: there's only one solution: become the maintainer yourself
17:44:02 <planetmaker> statements like "why don't you do ..." are pointless.
17:44:10 <planetmaker> All people do what they do for their own fun
17:44:22 <jrabbit> havign read that forum post
17:45:01 <planetmaker> Getting yourself informed is your task, not our
17:45:48 <CIA-2> OpenTTD: translators * r20589 /trunk/src/lang/ (7 files): (log message trimmed)
17:45:49 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:49 <CIA-2> OpenTTD: belarusian - 1 changes by KorneySan
17:45:49 <CIA-2> OpenTTD: esperanto - 8 changes by Christopher
17:45:49 <CIA-2> OpenTTD: icelandic - 10 changes by grjonib
17:45:50 <CIA-2> OpenTTD: italian - 4 changes by lorenzodv
17:45:50 <CIA-2> OpenTTD: russian - 3 changes by Lone_Wolf
17:46:03 <jrabbit> Pissing off mac packagers isn't a great way to try and get them to build software they like for people who complain about not owning a mac
17:46:04 <Rubidium> says one of the few Mac OS X users :)
17:46:25 <Rubidium> jrabbit: in what way have we pissed of mac packagers?
17:46:29 <planetmaker> jrabbit: there is no packager for mac either
17:46:39 <Rubidium> now I'm starting to get really interested
17:46:41 <planetmaker> it was built by the local compile farm
17:46:49 <jrabbit> Rubidium: nah don't worry about it its mroe usign the same arguements assholes use in the past
17:47:04 <jrabbit> it jsut reminds me of some bastards :)
17:47:44 * planetmaker wonders how good arguments have to be when the adversary are already called 'assholes' and 'bastards'
17:47:46 <jrabbit> Some python develoepr who thought he could fork exec however he goddamn well pleased and if it broke on a mac then obviosly you should buy him one
17:47:56 <jrabbit> planetmaker: no arguements to be had
17:48:14 <Rubidium> still... how (and where) did *we*, OpenTTD developers, piss of Mac packagers?
17:48:14 <Noldo> I'm a bit sceptical about this conversation giving any new point of views to the issue
17:49:09 <jrabbit> Rubidium: lol some forum post from a year ago, who cares
17:49:27 <planetmaker> you started the topic, you know..
17:49:31 * jrabbit mentioned it in #fink hopefully someone will pick it up
17:49:37 <jrabbit> planetmaker: well yes and got my info
17:49:54 <Rubidium> jrabbit: I care, because you are accusing us of pissing of packagers and I would like to know where we did that
17:52:54 *** devilsadvocate has quit IRC
17:57:17 <Rubidium> exactly how I expected this to end...
17:57:26 <Rubidium> can't back up his claims
17:57:55 <planetmaker> it was soooo predictable indeed
17:57:56 <VVG> do such kind of things happen often around this part of the internet?
17:58:08 <planetmaker> it's definitely not the first time
17:58:21 <planetmaker> so for certain definitions of 'often' yes
17:58:50 <Rubidium> although it is definitely the first time someone claims we pissed off OpenTTD's packagers
17:59:05 *** tokai|mdlx has joined #openttd
17:59:55 *** Progman has joined #openttd
18:01:31 <avdg1> :p so typical "macfan" (readed history)
18:02:19 <Rubidium> talking about macfans, can anyone confirm the "gossip" that OpenTTD is gone from itunes again?
18:02:25 <frosch123> yeah, other mac users hide in the shadows because of those, you only identify them if you meet them
18:02:49 <avdg1> hmm, I didn't use itunes that much
18:03:25 <avdg> :p I'm just trying a mac
18:03:40 *** devilsadvocate has joined #openttd
18:03:41 <avdg> I like it and I'm happy, but thats all
18:05:11 <Rubidium> good, then you can fix the OSX specific bugs!
18:06:00 <avdg> you saw I'm not a great developer :p
18:06:30 <Rubidium> oh... you're soo young in the OpenTTD circles
18:06:44 <Rubidium> never seen the handywork of the previous Mac OS X maintainer
18:08:41 <Rubidium> or the attempts of your fellow Mac OS X users at fixing Mac OS X specific bugs
18:09:42 <avdg> :p I'm just someone who loves to keep running into a wall
18:09:55 <avdg> too bad I rarely get over it
18:12:49 <Zuu> avdg: But if you would get over the wall, then you would have to find a way out of the room. :-)
18:13:19 * Rubidium wonders whether "getting over the wall" means using another more "free" operating system
18:14:14 <planetmaker> Well, OSX is less troublesome for me than windows and linux have been
18:14:38 <planetmaker> at least for work stuff
18:15:46 *** Brianetta has joined #openttd
18:21:52 <avdg> hmm someone wants to learn oop from me :p
18:26:47 <VVG> finally, in that save game of mine, if vsec = 1 tick, the start date shown is off by current _date_fract.
18:32:51 <VVG> I have a current tick, and a time ticks that timetable shoult start in. So i do offset = ticks % DAY_TICKS, then calculte start date as date = _date + (ticks-offset) / DAY_TICKS. that offset value later goes into lateness_counter. Why can _date_fract matter here?
18:40:41 *** Eddi|zuHause has joined #openttd
18:43:07 *** [hta]specx has joined #openttd
18:43:51 <VVG> hm, UpdateVehicleTimetable, i assumed it's called when vehicle arrives at some of his orders, is that right?
19:18:39 <dihedral> my java client is working ^^
19:19:16 <dihedral> i do not think you do :-P
19:19:27 <dihedral> unless you know java better than you know c/c++ ^^
19:20:35 * Rubidium "knows" java longer than c/c++, does that count?
19:21:28 <Rubidium> although... got a Java book, couldn't get it working, learnt myself C and a little later C++ instead before actually learning Java
19:21:35 <VVG> how does knowing one better than other matters? Your thing works, mine not quite, thus, i'm envious :)
19:23:31 <frosch123> my shell script is working ^^
19:23:51 <Rubidium> VVG: you still have some weeks before you pass the time dihedral spent on his little Java project
19:24:42 <dihedral> erm... refactoring :-P
19:25:02 <dihedral> plus my gf left for brazil for 12 months, so i spent some time with her too ^^
19:25:28 <Rubidium> so... you have even more time because there's no $gf nearby
19:25:52 <VVG> hm, i think i just managed to provide start_time properly!, atleast numbers shown at the time of arrival at 1st order suggests so
19:26:10 <VVG> but, i do not quite get how i managed to
19:27:54 <Rubidium> lets update ICU on the CF
19:28:13 <glx> good luck and have fun ;)
19:29:22 <frosch123> maybe that is only a trick to unbore himself
19:29:44 <Rubidium> argh... started the VM without network
19:31:08 *** TruePika has joined #openttd
19:44:26 <VVG> got it to crash in a game with start year 4999900 when trying to set a start date :(
19:57:34 <dihedral> Rubidium, but perhaps i understand a wee bit more of what i am doing too :-P
20:09:04 <Rubidium> well... given the trouble you had I'm not 100% sure about that
20:10:33 <Rubidium> now lets see whether everything survived the ICU updates
20:13:00 <Terkhen> I hope it is easier for a "frequently tested" platform
20:13:24 <Rubidium> I'm just doing a full release run on the 1.0 branch :)
20:14:10 *** andythenorth has left #openttd
20:15:58 *** andythenorth has joined #openttd
20:16:42 <VVG> http://pastebin.ca/1922211 i have piece of code, is this enough to wokr around int32 date limit? the DateToTimeNonCapped is used only in DateToTime, no other places i think
20:18:25 <Alberth> If SECONDS_PER_REAL_DAY < INT32_MAX, then minu() seems a bit useless to me
20:19:09 <Alberth> assuming DateToTimeNonCapped(date, fract) >= 0, otherwise weird things happen probably
20:20:33 * Rubidium wonders whether the compiler figures that date * DAY_TICKS may result in a (u)int64
20:26:56 <Steve^> Hey, when trains get stuck for a while they automatically reverse, can this be turned off?
20:28:59 <Alberth> discussed several times at the forums
20:29:34 <Alberth> but I cannot remember what path finder settings to change :p
20:30:09 <Steve^> I can't see anything obvious in the options
20:30:29 <Steve^> Also, can you change the default size of the depot window?
20:31:35 <Zuu> The settings to change do only exist in the openttd.cfg and may also be changed from the console in-game.
20:32:22 <Zuu> Actually, for any running game, you must use the console to change the settings since they are stored in the savegame - not the config file.
20:32:31 <planetmaker> Rubidium: does an object have an owner?
20:33:05 <Zuu> For settings that exist in the GUI, it is enough to change them from within the game and then save the game.
20:33:42 <Zuu> A few settings are interface settings that are not stored in the save games, but are instead shared among all games.
20:34:04 <Steve^> this is more complicated than I had hoped
20:34:07 <Alberth> Steve^: default size of depot window can be changed by modifying a constant and recompiling
20:34:12 <Zuu> all games = all saves + multiplayer within OpenTTD of corse. :-)
20:37:01 <Zuu> Steve^: you should probably in addition to changing it for your save game, also do it in your openttd.cfg or you will get the same problem in your next new game.
20:37:09 <planetmaker> I propose to add another variable to objects: owner. Like industries var 45 or vehicle var 43.
20:41:35 <Rubidium> you currently can't replace the existing objects
20:43:33 <planetmaker> that doesn't limit the use of such variable :-)
20:43:46 <planetmaker> Possibly... reading more... rather like industy var A7: owner
20:44:03 <planetmaker> And maybe nearby tile: Must be next to shore or so
20:46:09 <Steve^> I don't think I'll bother
20:51:07 <planetmaker> [22:41] <Rubidium> you currently can't replace the existing objects <-- that doesn't really make sense for objects which one can remove
20:51:24 <planetmaker> though... it's the same with all other things except stations...
20:52:54 <Steve^> I once mistakenly sent a goods train to a station, now its doomed to have good delivered it forever from the factory?
20:53:35 <frosch123> planetmaker: you can already access the company colour, isn't that enough?
20:54:08 <frosch123> well, with "already" i mean the specs in the post :p
20:55:57 <planetmaker> are you sure that CC - access is good? Wasn't there some desync with the colour of trains?
20:56:10 <planetmaker> the yellow and blue ones?
20:57:02 <frosch123> that was the issue with enabling/disabling "detailed" company colours
20:57:07 <planetmaker> and... CC != owner... would be a shame for the statue to change only because the company now uses red ink instead of pink ;-)
20:57:13 <frosch123> btw. was that fixed? or did we forget to open a task?
20:57:23 <planetmaker> I don't recall it being fixed
20:58:01 <Zuu> Steve^: IIRC there is a console command that resets all stations.
20:58:12 <planetmaker> I'm somewhat sure we had a task, though. But it was IIRC a two-split task... so this part might have become forgotten
20:58:18 <Steve^> this console does many things then :P
20:58:27 <Zuu> You could try to search the wiki or look through the console help to see what commands it has.
20:58:55 <Zuu> The console is also useful for reading the backlog in multiplayer.
20:59:33 <frosch123> yeah, i also remember that i wrote something down
21:00:42 <planetmaker> hm... I don't find a related task in FS
21:03:50 <frosch123> let's open a new task :)
21:07:10 <VVG> This is what i get when trying to set a start time at year 4999900
21:07:41 <VVG> google says it's acces violation. Can this be because it's overflow int32?
21:07:49 <CIA-2> OpenTTD: rubidium * r20590 /trunk/Makefile.bundle.in: -Fix: only unix2dos text files when generating the Windows installer
21:08:07 * VVG looks up what a segfault is
21:08:32 <glx> segmentation fault, same as access violation :)
21:08:32 <Rubidium> segfault is a pseudonym access violation
21:08:49 <VVG> already looked that up :)
21:09:35 <glx> possible causes are null pointer dereference, ...
21:11:32 <TruePika> Steve^: I am pretty sure, regarding the station rating, that, if the rating goes low enough for long enough, it will disappear
21:12:19 <VVG> in vc++ 2008, the first line in call stack window, is the last line before a crash?
21:13:37 <TruePika> Wait, rating regards delivering from, not to :P
21:13:53 <TruePika> Well, what makes you sure that you're doomed to make the delivery?
21:14:20 <TruePika> Does the town have a factory/sawmill/etc?
21:15:09 <TruePika> If so, then, by delivering cargo to it, it will produce goods, which will do a chain reaction:
21:15:20 <Steve^> with two stations by it
21:15:29 <TruePika> 2. No delivery -> lowers ratings
21:15:44 <TruePika> 3a. lower rating -> rating disappears
21:15:46 <Steve^> I want to collect all the goods from just one station, but it delivers some to the other station too, meaning I get 70% coverage
21:15:54 <TruePika> 3b. Low rating makes goods disappear
21:16:19 <TruePika> Just ignore the accidental station
21:16:33 <TruePika> Over time, it will stop recieving goods
21:16:57 <TruePika> That is because of that chain reaction
21:17:14 <TruePika> I'm pretty sure goods start disappearing at 10% rating
21:17:38 <TruePika> If you want to try lowering the rating even further, look at the Game Mechanics page on the Wiki
21:18:11 <TruePika> I'm not sure what exactly causes the station to abort goods, you'll have to check the source for that
21:18:30 * TruePika puts in a feature request
21:18:35 <Steve^> ah, it somehow has a 19% rating
21:18:50 <Steve^> so it's impossible to get 100% and somehow doing nothing doesn't give 0%
21:22:33 <Rubidium> it is possible to get a 100% station and industry rating. It's extremely difficult though
21:22:57 <Steve^> everything that a factory makes I put on a train
21:23:05 <Steve^> is it because it takes a while for delivery?
21:23:37 <Rubidium> because getting a 100% rating for a station is simply difficult and that's a precondition for the industry rating going to 100%
21:24:22 <VVG> it's my quick hack for debugging that was the reason for crash, kinda relieving
21:24:49 <Rubidium> or to put it differently: why should it be easy to get a perfect score?
21:28:41 <TruePika> Steve^: For 100%, look at the Game Mechanics page on the Wiki. You need to handle age and max speed as well
21:29:13 <TruePika> Theoretically, a train could be made in NewGRF which would bring the rating to the maximum by having a high enough speed
21:29:43 <TruePika> Also, ad campaigns can easily bring rating to 100%
21:37:10 <Steve^> whilst it shouldn't be easy, I don't like invisible criteria
21:37:23 <Steve^> (I shouldn't need to read the wiki to play the game)
21:37:59 <planetmaker> you play it, don't you?
21:38:29 <TruePika> This is a technical aspect for computing the exact station rating
21:38:41 <TruePika> You don't need to read it
21:38:47 <Steve^> apparently only to 80% of what I should be
21:39:07 <TruePika> Just like, for Pokemon, you don't need to read the damage formula
21:39:31 <Steve^> agreed, I don't read that to beat all my opponents
21:39:39 <TruePika> If you undertand the just of it, it helps
21:39:54 <Steve^> I wouldn't need to read it to understand why I can't beat my opponent without suffering damage
21:40:20 <Steve^> BUT if at the end of the battle it said I scored 80% when I wasn't damaged, it should let me know why
21:40:34 <Steve^> if I haven't clearly done anything wrong
21:40:46 <planetmaker> not clearly something wrong != optimal
21:40:50 <TruePika> But imagine you're capturing a PkMn without False Swipe (~ trying to beat a different station's rating)
21:41:22 <TruePika> If you understand the just, you can do less damage when you want to, and know what contrubutes the most to station rating
21:41:48 <planetmaker> and why should "not doing something wrong" be the same as "do everything as good as it can ever be"?
21:42:09 <TruePika> For that, look @ the Co-op
21:42:28 <TruePika> In OpenTTD, if your network gains you some money, there isn't anything wrong
21:42:51 <TruePika> In the Co-op, you want everything optimised
21:42:55 <planetmaker> A game should be playable without much study
21:43:11 <Steve^> I don't know what "the Co-op" is
21:43:22 <planetmaker> But a game needs not present a cake-walk to eternal high-score on the silver-platter. That'd be boring
21:43:27 <TruePika> Xrufuian doesn't study the game mechanics, and he surpasses me :P
21:43:27 <Prof_Frink> Is that the real Hatman?
21:43:49 <TruePika> Steve^: see www.openttdcoop.org
21:43:54 <Steve^> is there only one Co-op?
21:44:29 <planetmaker> You can probably coop on many servers
21:44:38 <planetmaker> Just we bring it to the limit ;-)
21:45:11 <TruePika> But #openttdcoop is the most popular, and is officially liscensed by OpenTTD.org :D
21:45:13 <planetmaker> and nearly exclusively do so. Though the stable server...
21:45:21 <planetmaker> ... that's open playground
21:46:01 <TruePika> There technically can be an infinite number of co-ops
21:46:19 <VVG> vc2008 have a key combination of ctrl+break. What that break key is?
21:46:23 <TruePika> Technically, if 2 players are sharing a company, it's a co-op
21:46:53 <TruePika> In the group with Scroll Lock
21:47:00 <Steve^> "Since the introduction of YAPF (Yet Another Path Finder) we’ve had the auto-balancer. This balances trains over two or more tracks depending on the status of the first 10 signals on those tracks."
21:47:14 <TruePika> Yeah, in fact Ctrl+Break even existed back in qBasic 1.0
21:47:16 <VVG> it even says so on my keyboard, but i never noticed it :(
21:47:20 <Steve^> I think I should read more about this
21:47:36 <TruePika> Steve^: That is because of the pathfinder penalty weight
21:47:45 <planetmaker> it's something which happens automatically
21:47:59 <Steve^> so now you can have two track systems?
21:48:39 <TruePika> Or you can more easily split a track, the load-balanced way
21:49:00 <planetmaker> it's faster to have two independent tracks
21:49:28 <TruePika> Sorted by speed and accelleration
21:50:15 <planetmaker> no effective difference
21:50:18 <Steve^> I thought that's how PBS works
21:50:56 <planetmaker> it would work with pbs, yes. But that doesn't mean that the thing shown doesn't work
21:50:57 <TruePika> Actually, that should use pre-signals on the entry for maximum effectivness
21:51:10 <planetmaker> And the signal spacing is smaller this way
21:51:28 <VVG> iirc that's because pbs heavier on cpu a bit
21:51:34 <TruePika> Oh yeah, pre-signals increase virtual SD
21:51:37 <Steve^> ah, because they can go right up to the before-bridge signals
21:52:15 <TruePika> I use PBS only where needed now
21:52:22 <VVG> pbs is used in such setups only when there is no enough space
21:53:09 <TruePika> I use KISS, so I use PBS more frequently than the co-op
21:54:07 <TruePika> But there are many, many situations where pre and block signals are better
21:55:01 <TruePika> Also remember that mixing Pre/Block with PBS causes crashes more frequently
21:55:30 <TruePika> PBS will happily reserve a path, and Pre/Block will happily cross that path
21:55:36 <Steve^> damn, coop server version mismatch! I wanna take a peek at the madness
21:56:02 <VVG> if you talk about ps, game just started, no madness yet
21:56:09 <planetmaker> a) get the correct version and b) the password is only available in our irc channel
21:56:11 <VVG> also, it uses nightly builds
21:56:41 <planetmaker> the stable server runs usual 1.0.3, possibly with some newgrf
21:56:47 <TruePika> Steve^: There are previous games availible for download
21:57:28 <TruePika> And each one is equally crazy
21:57:49 <TruePika> But you don't have to wait for them to be built up
21:57:50 <planetmaker> :-) But there's not that many who have as many players :-)
21:57:54 <VVG> range is from simple to insane
21:57:57 <Steve^> do people run AIs on these coop games?
21:58:11 <TruePika> Rarely, but sometimes
21:58:19 <planetmaker> also, only we as server owners could enable them
21:58:21 <TruePika> Usually only on private games
21:58:24 <Steve^> oh, the guy talks too!
21:58:35 <Steve^> He is using an EMU for grain and livestock!
21:59:00 <Steve^> (Some random coop server I'm spectating)
21:59:00 <TruePika> What do you mean by 'the guy talks too'?
21:59:14 <Steve^> I thought he must be an AI for the things he's done, but he spoke
21:59:26 <TruePika> Oh, AIs can't be paired with the players
21:59:48 <planetmaker> that can't be a compliment :-D
22:00:11 <TruePika> I mean, you can't run a company with ChooChooAI as your partner
22:00:14 <Steve^> I never play with AIs, so I have no idea what to look for now
22:00:36 <Steve^> I remember the days before signals where the AI would build single tracks with perfect passing spots
22:00:38 <TruePika> My networks are challenging enough
22:01:32 <TruePika> I mix PAX and FGT with different speeds on the same 4-track mainline (and, in my current game, I split the 4-track into 2 2-track)
22:01:35 <VVG> How do i restict a lenght of a ZEROFILL_NUM? Or where that should happen?
22:02:04 <Rubidium> why would you restrict the length?
22:02:24 <TruePika> It's 3, I should probably get working on my game
22:02:26 <Rubidium> in any case, the first dparam is the value and the second the minimum length (IIRC)
22:02:26 <VVG> to not get a bunch of zeroes showing up
22:03:31 * TruePika should probably put his savegames into folders :P
22:04:01 <Rubidium> yes, it'll print any number but if the number is less than the minimum length it'll put zeros in front of it
22:05:23 <Steve^> this.. map.. is.. massive
22:05:33 <Rubidium> i.e. passing 1 and 4 gives you 0001, but passing 12345 and 4 it'll give you 12345
22:06:40 <VVG> ahha, so one lenght of 2 will work for HH:MM:SS thing?
22:08:41 <Zuu> TruePika: In SP you can play with an AI as partner on an unmodified OpenTTD build, but you need to use the cheats to do so.
22:11:07 <VVG> atm itim intoduces a lot of different strings for formatting time, which seems a bit of an overkill to me. Am i think right here, that it should be ok with just 4 strings, HH:MM:AM/PM HH:MM:SS:AM/PM and HH:MM:SS, HH:MM:SS ?
22:12:37 <planetmaker> VVG: rather make there three strings: HH, MM and SS
22:12:53 <Rubidium> planetmaker: actually, I don't think that is such a good idea :)
22:12:54 <planetmaker> whether PM AM etc pp - that's up to the translator. As well as which separators and arangement is used
22:13:40 <planetmaker> Rubidium: I'd hate to have am / pm representation of time ;-)
22:14:37 <avdg> hmm let the user define if, its something personal
22:14:59 <Rubidium> I'd make one for HH:MM, one for HH:MM:SS, one "pm", one "am" and "{STRING} {STRING}" for giving the translator control over the order of time + am/pm thingy
22:15:02 <VVG> well, i typoed there, it should have been HH:MM and HH:MM:SS at the end :)
22:15:30 <planetmaker> hm, sounds also feasable :-)
22:15:45 <Rubidium> although.... "{STRING} pm" and "{STRING} am" would work as well (with even less strings)
22:16:04 <frosch123> timeformat is not really a translation thingie
22:16:12 <Rubidium> even so, I'd add a {TIME} and handle the actual formatting in strings.cpp
22:16:20 <frosch123> i am sure there are modern british people who use sane time formats
22:17:10 <VVG> a bit too much info now, can't get it all into my head :)
22:17:12 <frosch123> i also use only iso dates nowasays
22:18:05 <planetmaker> hehe Zuu. Saying you could recommend ... but won't is a nice way of advertisement :-)
22:18:35 * Rubidium tries to remember that "internet time" thing from some years back
22:19:18 <Zuu> It could fire back though. People thinking "now I can ignore those.." :-)
22:19:29 <frosch123> you mean those weird 2000 times without ":"
22:19:56 <Rubidium> ah... beats; one day is 1000 beats
22:19:56 <frosch123> where the last digits are 60 system nevertheless
22:20:28 <frosch123> oh, those beats, haha, we had a trainee some months ago who talked about those all day :p
22:20:30 <planetmaker> should be 74 ticks :-P
22:21:45 <avdg> what exactly times the ticks :p
22:22:00 <frosch123> maybe we should measure time and date in seconds since 2004-03-06
22:22:01 <VVG> an example. A set a string format for TIME_SHORT, that should be HH:MM. I add STR_TIME_SHORT :{ZEROFILL_NUM}, and SCC_TIME_SHORT with proper formating in strings.cpp, if i were to use {TIME_SHORT} later, is that right?
22:22:43 <Zuu> Hmm 74 / 24 = 3.08... So a tick every 20 minutes. :-)
22:23:02 <Rubidium> is there really a distinction between TIME_SHORT and TIME_LONG besides some global setting?
22:23:14 <frosch123> Zuu: coop games on my old machine could reach that
22:23:55 <Zuu> that must have been a slow machine or a heavy game :-)
22:24:02 <VVG> time short HH:MM time long HH:MM:SS, depending on a switch in settings, all values in timetable are show according to it
22:24:54 <Rubidium> so that can all be handled in strings.cpp; no need to polute stuff with TIME_SHORT / TIME_LONG when they're chosen bug the same setting each and every time
22:24:57 <planetmaker> VVG: I think the suggestion was to just use {TIME} and leave the rest ^
22:25:01 <Rubidium> (same for pm/am stuff)
22:26:18 <Rubidium> should be a relatively trivial excercise
22:26:43 <VVG> so it's only SCC_TIME that's added to trunk instead of a bunch of them i have right now?
22:26:57 *** Progman has joined #openttd
22:32:50 <TomyLobo> [00:15:01] <@Rubidium> I'd make one for HH:MM, one for HH:MM:SS, one "pm", one "am" and "{STRING} {STRING}" for giving the translator control over the order of time + am/pm thingy
22:32:59 <TomyLobo> why not like excel does it
22:33:11 <TomyLobo> i.e. format elements for everything
22:33:23 <TomyLobo> 12h hour, 24h hour, am/pm
22:33:52 <TomyLobo> i just skimmed, what do you mean?
22:34:10 <frosch123> read the more recent lines :p
22:34:52 *** devilsadvocate_ has joined #openttd
22:35:11 <TomyLobo> i still dont see anything comparable to my proposal
22:35:36 *** devilsadvocate has quit IRC
22:35:50 <frosch123> well, it was said to add a {TIME} code, and not put the format into the translations
22:36:06 <frosch123> so, it would work just like the other units in ottd
22:36:10 <TomyLobo> you mean use the system format?
22:36:53 <frosch123> you can already select between si/metric/imperial units, currencies, different date formats, and so on
22:36:58 <frosch123> independent of the locale
22:37:32 <TomyLobo> for one, i use the english language pack, but i dont want am/pm time
22:38:10 <TomyLobo> (which i think is of no value in the 21st century)
22:39:06 <Eddi|zuHause> [21.08.2010 22:20] * Rubidium wonders whether the compiler figures that date * DAY_TICKS may result in a (u)int64 <-- theoretically the processor spits out 64 bit anyway, the question is whether the compiler recognizes that, or just throws the higher 32 bit away
22:39:56 <frosch123> though i know that 11am is followed by 12pm, i am not sure whether between those hours is 12:00 am or 12:00 pm
22:40:15 <VVG> STR_FORMAT_DATE_ISO :{2:NUM}-{1:RAW_STRING}-{0:RAW_STRING} <-- What are those 2, 1 and 0?
22:40:36 <Eddi|zuHause> frosch123: they screwed up, they call it 12 but they count it like 0
22:40:37 <frosch123> the indes of the SetDParam
22:41:17 <Eddi|zuHause> yes (i'm fairly sure)
22:41:17 <TomyLobo> Rubidium Eddi|zuHause C is pretty strict with that. it'll cut away the most significant dword
22:41:52 <TomyLobo> you'd need an intrinsic or something to do that
22:42:33 <Eddi|zuHause> TomyLobo: you mean even if i assign the result to an int64, that still contains only the lower 32 bit?
22:42:46 <TomyLobo> but cast means it'll do a 64bit multiplication, which can be slow on 32 bit machines
22:43:05 <TomyLobo> it will be converted after the multiplication :D
22:43:09 <Eddi|zuHause> what a stupid thing to do...
22:43:25 <TomyLobo> (int32 x int32) -> int32 -> int64
22:43:49 <TomyLobo> that's the way C and C++ work
22:44:02 <Eddi|zuHause> that's the first thing i would optimize...
22:44:04 <TomyLobo> C++ can't overload based on return type
22:44:15 <TomyLobo> it's not an optimization
22:44:20 <TomyLobo> it's a different result
22:45:39 <TomyLobo> if you want to overload functions and operators based on return type, take a look at Opal or another functional language
22:45:44 <TomyLobo> they tend to have that
22:46:17 <TomyLobo> but they also tend to abstract away from concrete data types like int32 :)
22:50:48 <Rubidium> frosch123: yes, pm -> post mortem, i.e. after the middle of the day has been murdered :)
22:53:04 <frosch123> well, starting the day at 12:00 am is not any better :)
22:55:08 <VVG> whoa, very kind of you, thanks, i'm gonna shamelessly copy all of that!
22:55:46 <frosch123> pff, casting bools to ints :p
22:55:55 * avdg is interested in the results :p
22:56:44 <Rubidium> was to lazy to "fix" that
22:57:47 <Rubidium> in any case, the settings strings need better wording and the statusbar gui is... uhm... a big hack (tm)
22:58:48 <frosch123> nah, noone would consider the date useful, time is far better
23:01:13 <VVG> itim used to show only HH:MM time in status bar, but it's still breaks with years like 4999999
23:03:28 <Rubidium> VVG: fail/breaks in what way?
23:09:20 <VVG> err, mind that it's not from your diff
23:09:45 <Rubidium> that's "just" updating the widget's size correctly
23:16:15 <VVG> in your diff, those settings are global right? So, if i want a short time in status bar, and long in timetable, ain't possible right away, right?
23:16:27 <TomyLobo> according to the standard
23:16:27 * avdg hates safari that shows a popup you can't close
23:17:25 * avdg kills safari with the taskscheduler
23:17:59 <TomyLobo> true becomes 1, false becomes 0
23:18:14 <VVG> bleh, i was wondering how safari combines with popups, before you cleared thins up with your "kills"
23:18:49 <avdg> you mean at * is interested in the results * ?
23:18:57 <avdg> was meant to the patch :p
23:20:08 <TomyLobo> C++ standard 4.5.4 [conv.prom]: An rvalue of type bool can be converted to an rvalue of type int, with false becoming zero and true becoming one.
23:44:50 <Eddi|zuHause> showing virtual seconds in the statusbar makes not a lot of sense, assuming using 1 tick = 1 virtual second
continue to next day ⏵
