IRC logs for #openttd on OFTC at 2010-08-22
⏴ go to previous day
00:22:49 <TruePika> How unoptimized is the original pathfinder when used with ships?
00:23:24 <TruePika> I have 2 ships, a few planes, and who knows how many trains and road vehicals, and my system is starting to lag
00:23:39 <TruePika> Total vehical count being at least 120
00:24:58 <TruePika> Actual counts 90 trains, 24 RVs, 2 ships, 5 aircraft; all pathfinders are set to the reccomended settings
00:25:17 <TruePika> And it seems the system is starting to lag
00:26:10 <TruePika> I usually use larger train counts, as well as RV counts and aircraft counts, and the system doesn't lag AFAIKO
01:06:26 <Eddi|zuHause> TruePika: simple test: stop all ships/trains/rv/aircraft from the ship/train/rv/aircraft list, and see if it still lags
01:11:05 <TruePika> Lol, just stopped all trains and the network came to a halt
01:12:48 <TruePika> Nope, not laggy (and a couple of airplanes are still in the air - I told them to go to depots)
01:13:06 * TruePika gets only ships @ those airplanes going
01:14:19 <TruePika> Yup, it looks like the ship PF is the source of the problem
01:14:37 *** Eddi|zuHause2 has joined #openttd
01:15:25 <TruePika> Eddi|zuHause2: In case you ping timeout'd, I confirmed that it is the ship PF
01:15:41 <TruePika> And I confirmed that it is set to the original
01:16:05 <TruePika> The route isn't very far; less than 50 tiles IIRC
01:16:46 <TruePika> Yup, total width of route is about 45 tiles
01:17:22 <TruePika> And it is partially 'waypointed' in the way of stations along that 45 tile route
01:18:47 <TruePika> Lol, just re-started the trains:
01:19:03 <TruePika> Train 62's profit last year was -$2
01:22:26 * TruePika thinks that some window in OTTD should be able to give a value of how much lag there is at the time
01:38:25 *** Progman_ has joined #openttd
01:46:00 *** Progman_ is now known as Progman
02:02:56 <TruePika> Great, now I'm getting all sorts of lag without any vehicals going
02:11:27 <TruePika> For some reason, my ssh daemon is nearing the top for CPU usage, I'm checking DenyHosts...
02:12:00 <TruePika> O_o it was never properly set up
02:16:56 *** thvdburgt has joined #openttd
02:23:20 <TruePika> All this time, I thought DENYHOSTS was working properly
02:23:59 <TruePika> Well, that should help with SOME of the lag
02:25:00 *** rhaeder has joined #openttd
02:34:53 <TruePika> How long in real time is one day supposed to be if there is no lag? It might just be graphical lag I'm getting
02:35:56 <TruePika> ^^ I don't think that's the answer :)
02:38:31 <TruePika> Found it, 2+2/9 seconds
02:39:32 <TruePika> Lol I actually can barely tell if I'm lagging or not when using that number
04:26:33 <TruePika> ...I'm back and no conversation went on???
04:29:13 *** roboboy has joined #openttd
04:33:20 <TruePika> It looks like all of the tasks for 1.0.4 have been completed on the FS
04:33:55 <TruePika> I added another item onto it, one which should be easy to impliment
04:56:21 *** Eddi|zuHause2 has joined #openttd
06:23:09 *** Kurimus has joined #openttd
06:28:28 <TruePika> Well, it's 11:30 here, night
06:37:45 *** ^Spike^ has joined #openttd
07:23:34 *** roboboy has joined #openttd
07:49:10 *** Alberth has joined #openttd
07:53:11 <VVG> vc++ users, how do i check all files in a project for incosistent line endings?
07:53:41 <VVG> it's a paing to check them one by one after every failed attempt of tortoise svn to create a patch
07:53:55 *** roboboy has joined #openttd
07:54:13 <Alberth> isn't it simply the file that tortoise complains about?
07:55:02 *** roboboy has joined #openttd
07:55:13 <VVG> it stops after first file it encounters
07:55:41 <VVG> so atm it's create a patch, get to know on which file tortoise failed 1st, go fix it, repeat
07:56:16 <Rubidium> MSVC generally doesn't change line endings
07:56:32 <Rubidium> or at least I haven't heard anyone complaining about it
07:56:44 <VVG> well, then this is not a general case here :)
07:57:16 <Rubidium> I'd just run unix2dos over all (source) files
07:57:45 <VVG> msvc, on some file reloading, popups a dialog "file contains incosistent line endings", with a choice to fix them.
07:58:00 <VVG> of course, those are files i have edited
07:58:16 <VVG> but then again, i edited them in msvc
07:58:18 <Rubidium> one the files that were changed in my patch?
07:58:30 <Alberth> so the list of modified files seems like a good candidate
07:59:06 <VVG> hm, i didn't apply your patch directly, but copypasted the parts to where needed
07:59:26 <Rubidium> so you copy-pasted unix newlines
07:59:29 <VVG> may be this is due to copypasting from some other source but msvc?
07:59:44 <Alberth> yay for smart copy/paste handling
08:05:21 <Zuu> I usually do copy pasting from patches in vim where you see inconsintent new-line characters.
08:06:05 <Zuu> Or I can just do a s/\r//g on the patch file before copying code from it.
08:06:38 <Rubidium> I just found out (a day ago) that my editor's remove trailing spaces removes '\r's as well
08:07:30 <Zuu> hmm, editor support for removing trailing spaces sounds like a good idea.
08:08:11 <Zuu> Though, making a regex to detect them is not hard. You just have to remember to do it.
08:09:14 <Terkhen> remembering to run it is the hard part, yes :)
08:14:37 *** Cybertinus has joined #openttd
08:21:22 <Alberth> I have vim highlighting TAB and trailing whitespace
08:23:38 <Terkhen> I should search for similar features in notepad++
08:32:11 *** De_Ghosty has joined #openttd
08:49:12 *** Progman has joined #openttd
08:52:51 <VVG> asd /* Unfortunately, SetDate() may be called when _date_fract is not initialized */ <-- There is this comment line from old itim. Is this still true?
08:57:05 <Alberth> in general, don't trust comments, whether they hold should be verified by studying the code
08:58:55 <Alberth> about this one, somebody wrote that as a warning, so either assume it is still tha case (ie assume the worst case), or find the code that invalidates that claim
09:00:42 <Alberth> oh, and a third option is of course to fix the code so it will not happen
09:09:10 *** ^Spike^ has joined #openttd
09:18:24 <CIA-2> OpenTTD: rubidium * r20591 /trunk/src/ (7 files in 2 dirs): -Codechange: make sure _date_fract is set when SetDate is called. Some places wouldn't reset _date_fract correctly at all
09:18:29 <trebuchet> or remove the comment if the code is found to invalidate the claim
09:20:19 <Alberth> that would be a logical next step.
09:22:08 <CIA-2> OpenTTD: rubidium * r20592 /trunk/src/ (date.cpp saveload/afterload.cpp): -Fix (r2041): no (proper) savegame conversion was done when _date_fract got a new value range
09:27:55 <VVG> that's some great commits!
09:32:44 <Rubidium> yeah, I'm great at breaking patches
09:35:11 <Rubidium> so do I, because depending on the implementation I might've broken the daylength patches
09:36:43 <VVG> btw, what's the range some of the daylength patches set length of day in ticks?
09:38:51 <VVG> could have guessed as much
09:42:34 <SpComb> some mad people use up to 64 * DAY_TICKS
09:43:46 <DorpsGek> Rubidium: 55.3513513514
09:44:19 <Rubidium> that ain't going to work with the timetable stuff VVG is writing
09:45:27 <Rubidium> unless you get really creative
09:45:33 <DorpsGek> Rubidium: 5867441.6612
09:46:16 <Rubidium> @calc 2**44 / 5000000 / 366 / 74
09:46:16 <DorpsGek> Rubidium: 129.908329969
09:46:28 <Rubidium> ooh... that could work
09:48:52 <Rubidium> 2 to the power of (number of bits not used for the vehicle id) divided by the number of years a game has at most divided by the number of days a year (upper bound) divided by the number of ticks a normal day has
09:49:05 <Rubidium> and that returns the daylength factor that could be "hacked" in
09:50:15 <Rubidium> @calc 1826212865 / 5000000
09:50:15 <DorpsGek> Rubidium: 365.242573
09:50:28 <Rubidium> @calc 2**44 / 1826212865 / 74
09:50:28 <DorpsGek> Rubidium: 130.177729223
09:50:32 <VVG> not following you here :(
09:50:43 <planetmaker> !calc !pi*1e7 / 365
09:50:50 <planetmaker> @calc !pi*1e7 / 365
09:50:50 <DorpsGek> planetmaker: Error: invalid syntax (<string>, line 1)
09:51:07 <planetmaker> @calc pi*1e7 / 365
09:51:07 <DorpsGek> planetmaker: Error: invalid syntax (<string>, line 1)
09:51:10 <Rubidium> VVG: that's probably good :)
09:51:16 <planetmaker> @calc pi*10**7 / 365
09:51:16 <DorpsGek> planetmaker: 86071.0316052
09:51:50 <planetmaker> @calc pi*10**7 / 365.242573 / 24 / 3600
09:51:50 <DorpsGek> planetmaker: 0.995530881971
09:51:54 <VVG> with latest commints, calculating virtual time right in setdate works with a new game and a one save of mine
09:53:32 <Rubidium> for what it's worth, the 1826212865 is MAX_DAY in OpenTTD, i.e. the date of 31st of December 5000000
09:54:49 *** Eddi|zuHause2 is now known as Eddi|zuHause
09:55:06 <VVG> Currently, i'm limited by int64 at calculating _date * DAY_TICKS * vsecs_per_tick
09:57:06 <Rubidium> oh, for that you'll still have roughly 2**20 bits free, i.e. whenever vsecs_per_tick gets close to 1 million you might get into trouble
09:57:09 *** frosch123 has joined #openttd
09:57:59 <VVG> well, it's day_ticks that might increase :)
09:58:04 <Rubidium> although arguably vsecs_per_tick probably remains somewhere in the neighbourhood of 1..5; even 256 would be stretching it very far
09:58:21 <VVG> even with 4 it goes by quite fast
09:59:14 <VVG> when i tried to timetable, on a big map on a small route my local train fit in 365 cycle just by.
09:59:45 <Rubidium> VVG: I just "shown you" that 130 is the maximum day length factor that can be accomplished with the current network protocol
10:00:23 <Rubidium> which leaves the 20 bits used for the vehicle id in CmdSetTimetableStart for the vsecs_per_tick
10:00:24 <VVG> i take this statement as is, because i don't get what you showed :)
10:01:15 <VVG> it's int32 right now and 20 bits are used for vehid, that leaves 12 free bits
10:01:56 <Rubidium> yes, those 12 bits are used for the ticks within a given date
10:02:37 <Rubidium> the vsecs_per_tick is done (much) later
10:03:21 <Rubidium> it isn't used in the protocol at all
10:03:49 <VVG> i pass offset as ticks right now, that limits it to 4095
10:04:33 <VVG> not sure how vsecs factor in here
10:05:31 <Rubidium> VVG: it doesn't, which is why the 20 bits used here for VehicleID are essentially "free" after (date * DAY_TICKS + _date_fract)
10:06:30 <Rubidium> so if you multiply that number by vsecs_per_tick you *can* multiply it by a vsecs_per_ticks up to 2**20 without causing any (overflow) problems
10:08:32 *** KenjiE20 has joined #openttd
10:10:52 <Rubidium> then just don't bother about the daylength patch. It'll work fine
10:11:13 <trebuchet> How do I get myself to become addicted to OpenTTD
10:14:10 <trebuchet> I'm under house arrest for a year and they wont allow internet.
10:16:34 <Rubidium> and thus you're asking people on the internet for advice?
10:19:27 <VVG> what can be done about timetable being, well, too precise?
10:20:00 <Rubidium> how can the timetable be too precise?
10:20:42 <Rubidium> if you want to show seconds, you want such precision in the timetable as well I'd reckon.
10:21:04 <Rubidium> if you don't want them, then minute granularity is good enough (and you can only enter stuff in minutes anyway)
10:25:56 <VVG> they fluctuate even when vehicle is staying.
10:26:36 <Rubidium> that smells like a bug
10:26:42 <VVG> if i move timetable window they fluctuate too :)
10:27:15 <Rubidium> that definitely smells like a logic bug
10:29:06 <avdg> hmm… does openttd windows have minimum sizes?
10:29:23 <avdg> I don't see 1 on the osx binary and it creates crashes
10:29:40 <planetmaker> or do you mean the global window?
10:29:50 <planetmaker> that I don't know
10:29:53 <VVG> SetDParam(param1, STR_JUST_TIME);
10:29:53 <VVG> SetDParam(param2, (_virtual_time + TicksToTime(ticks)) % SECONDS_PER_REAL_DAY );
10:30:00 <avdg> I'll post the bug on the tracker
10:30:54 <VVG> inline Time TicksToTime(Ticks ticks) { return ticks * _settings_client.gui.virtual_seconds_per_tick; } and that
10:31:02 <planetmaker> I don't call that window size usable anymore, though ;-)
10:31:18 <planetmaker> what was it? like... 10 pixels high?
10:32:45 <Rubidium> it doesn't crash with SDL regardless of how small I make it although SDL (or my WM) limits it to at least 1 or 2 pixels high and a dozen or so wide
10:33:09 <VVG> i don't see where a fault can be :(
10:33:22 <planetmaker> Message: Assertion failed at line 153 of /Users/ingo/ottd/trunk/src/core/math_func.hpp: min <= max <-- that's what happens, Rubidium
10:33:45 <planetmaker> let's get a backtrace
10:34:11 <Rubidium> find the clamps in the OSX gui code and one of those will be it
10:34:51 <avdg> does it work on other os?
10:35:00 <Rubidium> it doesn't crash on Windows either
10:35:24 <Rubidium> can't be bothered to check Allegro, but that being mostly a copy of SDL it's unlikely to crash either
10:36:06 <Alberth> VVG: what is 'param1' and 'param2'? usually those are constants
10:37:56 <VVG> static void SetArrivalDepartParams(int param1, int param2, Ticks ticks) from here
10:40:14 <Rubidium> planetmaker/avdg: might it be that your title bar isn't 22 pixels high?
10:40:19 <avdg> I think the best solution is to add a minimum size, I wasn't able to resize the window again when it was on his smallest possible size
10:40:34 <planetmaker> that may well be. It's smaller afaik
10:40:45 <Rubidium> there *is* a minimum size of 64x64 on all supported platforms
10:41:19 <planetmaker> hm. I count 22 pixels
10:41:59 <planetmaker> well. It crashed only when I made the window less high than half of the toolbar would be
10:42:18 <planetmaker> like 3 or 4 pixels
10:42:24 * Rubidium will just blame 10410
10:42:54 <avdg> thats how a window looks like
10:45:08 <avdg> wait, I'll post such a window too :p
10:46:48 <avdg> thats how small you can get that window
10:49:03 <Alberth> VVG: check the contents of the string you are printing, there are some explanations of the string system at the development wiki
10:53:02 <planetmaker> I now tried one minute to make it bigger again before it crashed
10:53:32 <avdg> it happens the same here
10:53:46 <avdg> on the last try it didn't crash at all
10:57:45 <planetmaker> neither here. With 23 defined as height
10:58:12 <avdg> hmm, so there is no mimimum size on all platforms?
10:58:14 <planetmaker> Which *I think* is correct
10:58:30 <planetmaker> because it's 22 pixels menu bar + 1 pixel window
10:58:36 <planetmaker> I can't get it smaller
11:01:24 <planetmaker> I can't get it to crash again
11:02:58 <avdg> my window opens now at his smallest state
11:05:16 <planetmaker> hm... I get an idea: click on something in the overly minimized state
11:05:32 <avdg> now I have a window I can't resize anymore :(
11:05:57 <planetmaker> edit your openttd.cfg. And yes, you can re-size. Just tricky
11:07:12 <planetmaker> Better idea: tooltip tries to show. That crashes.
11:07:20 <planetmaker> That is also consistent with the backtrace
11:07:50 <avdg> hmm I can't locate that file :(
11:08:13 <planetmaker> Documents/OpenTTD/openttd.cfg
11:09:11 <VVG> Alberth: not sure what i should check there. STR_JUST_TIME prints ok in another place.
11:09:34 *** Devroush has joined #openttd
11:10:54 <VVG> you sound like i said something stupid :(
11:11:26 <avdg> hmm I can drag and drop the opening window :p
11:14:33 <avdg> pm: I think I know whats the problem, donno what you have
11:14:48 <planetmaker> it fails to show the tooltip
11:15:27 <avdg> hmm maybe it isn't osx dependent
11:15:45 <planetmaker> what is the problem in your eyes?
11:16:00 <avdg> I have moved a windows while the height was smaller then the caption bar
11:17:18 <avdg> I know how to reproduce it
11:17:25 <planetmaker> it's triggering the tooltip showing
11:17:46 <planetmaker> which you trigger, if you're in the vicinity of the main menu
11:17:59 <Alberth> VVG: no, I just don't know it either, and I wanted you to know I read your message
11:18:29 <avdg> the bug only occers when the window is smaller then the caption bar and you try to move it
11:18:49 <avdg> A theory that I have is that the captionbar can not be lower then 0
11:19:11 <avdg> but because it doesn't fit, it has to go lower then 0 somehow
11:19:40 <planetmaker> yes. It's the wrong call of clamp
11:20:03 <Alberth> the program goes at length to make sure the caption bar stays visible, otherwise you cannot move the window any more
11:20:48 <planetmaker> yes, but clamp is called like clamp(value, 5, 3)
11:22:14 *** ajmiles has joined #openttd
11:25:17 <planetmaker> Alberth: you can probably try yourself: make the window height 1 pixel. Then make sure the tooltip is called by hovering over the main menu
11:27:41 <Alberth> Thanks for finding out and for the patch.
11:27:41 <Alberth> Unfortunately, now is bad moment, as I am doing other experiments at this moment. Will look at it later, if one of the other devs doesn't first.
11:28:26 *** LunarWolf has joined #openttd
11:29:29 <LunarWolf> Is there a fix for signaling?
11:30:01 <VVG> what's wrong with signaling?
11:30:26 <LunarWolf> I have a bug that they are facing in the wrong direction and in addition do not work as they should
11:30:53 <planetmaker> LunarWolf: first try without 32bpp
11:31:05 <planetmaker> they might have mixed up things
11:31:28 <planetmaker> without any newgrfs also
11:31:40 <planetmaker> if it then is still broken... then it's a bug
11:31:50 <planetmaker> otherwise it's a newgrf problem or a 32bpp set problem
11:32:10 <planetmaker> that said: it works for me
11:35:25 <LunarWolf> And you can not somehow isolate that game does not alter signaling 8bpp to 32bpp.
11:35:40 <planetmaker> signaling isn't altered.
11:35:44 <planetmaker> But graphics might be wrong
11:37:52 <planetmaker> you talk to the correct guys in the 32bpp thread
11:41:23 <planetmaker> but asking "when will this be fixed" won't speed up the process ;-)
11:42:05 <LunarWolf> I wrote in one thread about this, but somehow I do not see an effect, because someone solve this problem.
11:43:28 <planetmaker> people have a life, you know
11:43:31 <LunarWolf> know, encoding is not easy to
11:44:15 <planetmaker> I'm sure they'll address that. But chances to have it addressed in 24h are not the best usually
11:44:52 <LunarWolf> I sit alone and write in C + + program to decode a single game, because the distributor did not even know how to patch do (did, but still the game crashes after a while)
11:46:30 <LunarWolf> and best of all, do not want them to bring and distribute the additive
11:47:49 <LunarWolf> even the locations they did wrong (fonts are badly done, or not so what you need)
11:49:28 <planetmaker> then skip those graphics. The default graphics have little issues
11:53:22 <LunarWolf> in which the file is a signaling?
11:55:02 <VVG> http://pastebin.ca/1922600 i have that piecie of code, in timetable_gui.cpp This is to parse a HH:MM:SS string and to convert it later to seconds. Does this look ok? It does what it is supposed to, but i wonder if there are better ways.
11:55:35 <LunarWolf> I may be able to repair or isolate.
11:59:03 <Alberth> VVG: It needs range checking, I think. Also, I'd write it by manipulating characters, but that may be just me, I am not a fan of scanf()
11:59:32 <Alberth> return 0 is useful in any way?
12:00:16 <Alberth> why is adding more text at the end bad?
12:02:12 <VVG> well, that piecie of code is from original itim, a tiny bit adjust to parse query string. return 0 there is because i thought it is a proper way, with no basis on anything. about trail characerts, i think that's because it's not supposed to be anything but HH:MM:SS, a HH:MM:SSS kinda wrong there
12:03:56 *** LunarWolf has left #openttd
12:05:51 <Alberth> Whether 0 is acceptable depends on what the value is used for,
12:06:24 <Alberth> yeah, you don't want "123" as seconds, but "12 " would be ok imho
12:08:36 *** TomyLobo has joined #openttd
12:09:20 <VVG> you mean, just the seconds?
12:09:34 <VVG> as in, only one value scanned?
12:17:07 <VVG> compiler gives a warning about unsafe use of bool if i try to use 0 < assigned < 4 :(
12:18:56 <VVG> is that an ottd internal function?
12:20:37 <VVG> not really needed in my case, since it's a range of 1-3, that's all. Was just a bit surprised that a < b < c inside an if gets me a warning
12:24:18 <VVG> it produces something unexpected, when inputing just one value
12:24:36 <Hirundo> a < b < c evaluates to (a < b) < c
12:26:45 <Hirundo> and not (a < b) && (b < c) as you might expect, depending on your expectations
12:28:20 <VVG> no wonder compiler complained :)
12:35:58 *** Adambean has joined #openttd
12:39:29 <VVG> well, as i am no "programer, who decides whether the suspicion is justified", it's kinda scary :)
12:42:52 <VVG> hm. it looks like determing whether there were addition characters doesn't matter, they are just truncated anyway. But just one digit is not enough, it produces some strange results. So if only seconds wanted it has to be 00:00:XX, 00:XX if only minutes, XX:00 if only hours, XX:XX for hours minutes.
12:51:03 <VVG> I noticed the "\ No newline at end of file" while looking through diff. Is this critical, bad habit, or doesn't matter at all?
12:53:10 <avdg> look up at the backslash
12:53:38 <frosch123> very old compilers cannot deal with lines not ending in new-line. they might ignore it
12:54:09 <avdg> it normally can't hurt, depending on the coding style
12:55:18 <Alberth> VVG: you apparently don't type 'ENTER' after the last line
12:55:30 <Alberth> and the editor doesn't add a newline either
12:55:45 <GVV> well, i guessed as much myself :)
12:56:25 <VVG> does it matter? should i be more carefull in the future?
12:57:30 <Alberth> as frosch123 said, old compilers may have trouble with it
12:57:49 <VVG> sorry, i got dropped didn't see anything after my question
13:17:01 <andythenorth> can New Objects do anything useful for gameplay?
13:17:42 <andythenorth> or eye candy only?
13:18:25 <VVG> Okay. I want to share with any of you who is interested what i have done here. What would be a good place to upload a diff, that doesn't require registration?
13:19:06 * planetmaker guesses: Eye candy only
13:22:17 <avdg> hmm, now I can find the "diff" format on pastebin :p
13:23:05 <andythenorth> so NewObjects don't accept / produce cargo
13:23:31 <andythenorth> can they be built by the map generator? I assume so (lighthouse, transmitter)
13:23:50 <planetmaker> specs indicate, they can. At least in the SE
13:24:08 <planetmaker> map generator depends. Before it generates objects, I'd rather have rivers ;-)
13:24:51 <andythenorth> but we get what's interesting to person writing code, not what we wish for :D
13:25:20 <VVG> wrong syntax selected i think
13:25:43 <andythenorth> NewObjects can be built on water? (prop 10 implies so)
13:26:32 <VVG> in case you wonder where the clock is, it's on click switch with date status bar :)
13:27:17 * andythenorth thinks NewObjects could be used to provide reefs, sandbanks, lightships, lighthouses at sea etc
13:27:34 <andythenorth> in two of those cases, cargo production / acceptance might be valid
13:28:05 <andythenorth> I thought of industries for lightship, lighthouse. It's not the right way to do it though
13:29:20 * andythenorth wonders about a new industry cb: distance to nearest new object of class XXXX
13:34:56 *** welshdragon has left #openttd
13:35:15 <Hirundo> VVG: what text editor do you use?
13:40:04 <VVG> msvc to edit source, tortoise svn diff to copypast the lines from to pastebin
13:43:14 <Hirundo> I ask, because spaces/tabs are sometimes intermixed (e.g. english.txt) this often breaks is someone else uses a different tab width
13:44:04 <VVG> might be just a mistake on my side, not a text editor :(
13:44:48 <Hirundo> Using a text editor that makes whitespace visible helps
13:45:56 <Hirundo> Such minor issues aside, is it necessary to store the virtual time globally, while it basically carries zero information?
13:46:23 <frosch123> andythenorth: be careful with chickens
13:46:33 <frosch123> some object might want to check for industries nearby
13:47:24 <planetmaker> [15:28] <andythenorth> I thought of industries for lightship, lighthouse. It's not the right way to do it though <-- what does a light house produce? Increased feel-good factor? ;-)
13:47:51 <VVG> ever incrementing, looping around 24h. THere is a clock running using it
13:47:52 <andythenorth> well, just passengers, maybe waste (if that cargo is enabled)
13:47:53 <planetmaker> it accepts tourists then? :-P
13:48:14 <andythenorth> it's not a good case for an industry
13:48:24 <andythenorth> but is good eye candy
13:48:33 <VVG> in any case, that's how it was in original patch :)
13:50:29 <andythenorth> can new objects have stations built in?
13:50:33 <Hirundo> ShowTimeDropDown feels like code duplication to me
13:52:30 <VVG> you mean, it can be done one ine place for both windows?
13:53:44 *** Phoenix_the_II has joined #openttd
13:53:58 *** Biolunar has joined #openttd
13:54:06 <andythenorth> Fish seems to be the FIRS money maker cargo in 1870 :o
13:54:33 <planetmaker> Probably it's klipfisk from Kristiansund
13:54:41 <planetmaker> can be shipped everywhere for big $$$
13:55:10 * andythenorth needs more money
13:55:18 <Hirundo> VVG: I was just referring to the fact that hours, minutes and seconds have nearly the same code
14:07:30 <Hirundo> I can't really put my finger on it, but the whole patch feels a bit overcomplicated
14:07:52 <planetmaker> hm... our clients crash upon connect to our server :-(
14:08:11 <Hirundo> for example, there are now four different settings regarding the precise look of the timetable clock etc
14:09:40 <Alberth> that sounds like 3 too many :)
14:10:01 <planetmaker> *** set a breakpoint in malloc_error_break to debug <-- where do I find that routine? My grep fails...
14:10:44 <planetmaker> I can't re-compile libc
14:11:39 <Rubidium> if it says you should do so I'd argue that that part of the library has debug symbols compiled in
14:13:14 <planetmaker> you try to tell me something... can you... yes
14:13:22 <planetmaker> ... tell me what exactly?
14:13:48 <Rubidium> breakpoint malloc_error_break
14:14:00 <planetmaker> ok :-) I didn't know that. Will try
14:14:07 <Rubidium> but if it's 4067, did you download some missing NewGRFs before connecting?
14:14:40 <planetmaker> I just connected with 'join company' from the lobby, straight after startup
14:15:05 <VVG> i admit, seconds from actual clock can be removed. what about timetables? all four choices for now seem feasable
14:15:10 <Rubidium> as it smells like FS#4055
14:17:27 <Hirundo> the statusbar settings are pretty bogus IMO, the rest can be left as-is
14:19:02 <planetmaker> Rubidium: I used the 'search server' function, though
14:20:22 <planetmaker> Rubidium: backtrace with breakpoint attached to 4055 or 4067? What do you prefer?
14:23:59 <VVG> both of status bar settings?
14:35:30 <planetmaker> that's the most recent one from the PS
14:46:47 *** JVassie has joined #openttd
14:49:59 *** HerzogDeXtEr has joined #openttd
15:18:11 * Zuu wonders how far *Ar4er will keep trying to write an AI without basic programming knowledge.
15:20:00 <Alberth> as long as someone tells him what to do, is my guess
15:42:11 * Rubidium wonders when someone writes the equivalent of labview for AIs
15:42:24 * roboboy might oneday consider trying to write an AI
15:42:44 * avdg might to give squirel another try
15:44:27 <planetmaker> lol labview for AIs :-)
15:46:58 *** ChanServ sets mode: +v glx_
15:49:52 <Rubidium> planetmaker: now try to envision labview and matlab glued together with java :)
15:50:17 <planetmaker> I can imagine nicely labview and matlab glued together. But java... urgs
15:51:34 <planetmaker> so... that basically exists
15:56:13 <Alberth> I kind of expected that, at least the LV / ML combination
15:57:17 <planetmaker> yes, the latter exists, I knew that :-)
15:58:02 <planetmaker> or rather: it'd have surprised me a lot, if they offer IDL interface but not ML
15:58:08 <frosch123> the interesting part about labview is, that you can tell advanced users from beginners just by asking them about "shift registers"
15:58:20 *** Pixo[hol] has joined #openttd
15:58:39 <planetmaker> they can be quite useful indeed
15:58:57 <Rubidium> I'd say: by some clicking
15:59:43 <frosch123> we do not like germans here
15:59:57 <Pixo[hol]> :P no problem at all
16:00:51 <Pixo[hol]> :D ia have a technical problem, and after hours of websearch i cant isolate the problem
16:01:32 <Pixo[hol]> openTTD 1.0.3 x64 on windows 7 dont play any sound since this morning
16:03:06 <planetmaker> sound, music or both?
16:03:09 <Rubidium> do other applications play sound?
16:03:26 <Pixo[hol]> yes all other windows application play sound
16:03:43 <Pixo[hol]> i reinstalled openTTD
16:04:01 <Rubidium> start openttd, in the main menu click on "Game options"
16:04:26 <Rubidium> there's an area, almost at the bottom, that says "Base sound sets"
16:04:29 <planetmaker> NoSound and NoMusic as base sets?
16:04:50 <Pixo[hol]> no there are the OpenSFX and OpenMSX
16:04:51 <Rubidium> which set have been chosen, i.e. what does the dropdown directly below "Base sound sets" say?
16:05:33 <planetmaker> Pixo[hol]: if those two are selected, is the output volume also not set to very low?
16:05:39 <Hirundo> Is your application-specific volume set correctly in the windows mixer?
16:05:40 <planetmaker> You can check that (only) ingame
16:06:04 <planetmaker> i.e. start a map and go to the music & sound settings there
16:06:46 <Pixo[hol]> the windows volume is normal to
16:06:51 <Pixo[hol]> lika all other applicatins
16:07:34 <Rubidium> how familiar are you with the command prompt?
16:08:16 <Pixo[hol]> the windows one? not really familiar
16:08:44 *** asnoehu has joined #openttd
16:09:13 <Rubidium> yes, well familiar enough to start OpenTTD from there with -ddriver=1 as parameter?
16:10:39 *** asnoehu is now known as tycoondemon
16:10:56 <Rubidium> and it should have opened a second window with some text on it
16:11:16 <Rubidium> what does that say about the sound driver(s)?
16:11:42 <Rubidium> you can to pastebin.com
16:14:42 <Rubidium> so it all went fine (for x64 standards)
16:15:31 <Rubidium> now I'm out of ideas (don't use Windows myself, so I'm not really familiar with new "features")
16:16:00 <Rubidium> although maybe you can check Hirundo's comment about application specific volume settings (never heard of it myself)
16:16:17 <Pixo[hol]> yeah i checked this one
16:16:34 <Pixo[hol]> all applications on normal
16:22:19 *** Brianetta has joined #openttd
16:33:43 <roboboy> I get no music with the same setup as above using either orig_win or openMSX
16:35:28 <roboboy> the Jazz Jukebox shows no music at all except when I open the window to create a programme, then it shows all the tracks
16:38:22 <Rubidium> planetmaker: is the server still running?
16:38:54 <Rubidium> or have you killed it already?
16:42:49 <avdg> combuster has already coming up with an evil patch
16:43:48 *** [com]buster has joined #openttd
16:45:06 <Pixo[hol]> ok sound is working, i think its a bug
16:47:48 <Rubidium> avdg: that's just stupid
16:47:51 <CIA-2> OpenTTD: rubidium * r20593 /trunk/src/order_backup.h:
16:47:51 <CIA-2> OpenTTD: -Fix: (rlongago, r20547): long ago the service interval was int16, after which
16:47:51 <CIA-2> OpenTTD: is got converted to Date except in the order backup. Much later I copied the
16:47:51 <CIA-2> OpenTTD: savegame snippets from a vehicle and applied that on the order backup. Presto,
16:47:51 <CIA-2> OpenTTD: reading/writing 32 bits (of Date) into 16 bits of ancient style service
16:47:53 <CIA-2> OpenTTD: interval. That would then "spoil" the name pointer and that eventually crashes
16:47:55 <CIA-2> OpenTTD: OpenTTD as it's likely to be an invalid pointer.
16:48:36 <Terkhen> Pixo[hol] roboboy: music and sound work for me under windows 7 with openttd 1.0.3 x64
16:50:08 <Rubidium> avdg: although there's another server side fix, but that might break player behaviour
16:50:46 <Rubidium> in any case, I suggest that #openttdcoop migrates to r20954+ in two hours
16:56:03 *** Cybertinus has joined #openttd
16:59:49 * Rubidium waves in the general direction of Vjenne
17:00:30 <planetmaker> [18:50] <Rubidium> in any case, I suggest that #openttdcoop migrates to r20954+ in two hours <-- nice :-)
17:01:23 <Rubidium> oh, one tip: make sure everyone is disconnected before you do the final save (the save you're going to reload into the new nightly)
17:02:00 <planetmaker> everyone disconected? What difference does it make?
17:02:30 <Rubidium> planetmaker: the crash cause is the order backup pool. If everyone is disconnected that pool ought to be empty
17:03:49 <Eddi|zuHause> good morning everybody.
17:03:58 *** roboboy has joined #openttd
17:04:32 <Eddi|zuHause> EBacklogTooLong...
17:04:32 <planetmaker> moin Eddi|zuHause
17:06:44 * frosch123 does not recognise any parts
17:10:51 *** Cybertinus has joined #openttd
17:13:41 <planetmaker> Rubidium: if we play with the patch for the current version: will we need a no-player save again when we update in two hours?
17:14:11 <Rubidium> planetmaker: probably not
17:19:41 <planetmaker> thank you very much :-) You made a number of players quite happy :-)
17:25:40 *** Pixo[hol] has left #openttd
17:26:25 *** Progman has joined #openttd
17:34:08 <avdg> actually not so funny :/
17:35:21 <Rubidium> yay for social engineering :(
17:45:48 <CIA-2> OpenTTD: translators * r20594 /trunk/src/lang/ (10 files): (log message trimmed)
17:45:48 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:48 <CIA-2> OpenTTD: german - 2 changes by planetmaker
17:45:48 <CIA-2> OpenTTD: icelandic - 19 changes by grjonib
17:45:48 <CIA-2> OpenTTD: italian - 1 changes by lorenzodv
17:45:49 <CIA-2> OpenTTD: polish - 6 changes by xine
17:45:49 <CIA-2> OpenTTD: portuguese - 15 changes by JayCity
17:53:06 *** devilsadvocate_ has quit IRC
17:59:31 *** ProfFrink has joined #openttd
18:04:06 *** ChanServ sets mode: +v glx_
18:05:13 *** ProfFrink is now known as Prof_Frink
18:07:12 *** fmauneko has joined #openttd
18:14:10 *** Cybertinus has joined #openttd
18:34:31 <andythenorth> planetmaker: I lost your transfer order patch again :(
18:34:43 <andythenorth> can you remind where it is - sorry
18:34:47 <planetmaker> somewhere on flyspray :-)
18:35:30 * planetmaker has an ever growing dir of patches ;-)
18:35:51 <planetmaker> most of which can meanwhile be considered junk, though
18:36:34 <andythenorth> patch fails to apply against 20594
18:37:42 <andythenorth> don't understand why :o
18:40:52 <planetmaker> uhm... andythenorth because there are now 1 million vehicles, not only 64k
18:43:05 <Alberth> andythenorth: you don't save cargo fractions, do you? (ie 7ton of wool gets lost without ever producing goods)
18:43:26 <andythenorth> Alberth: it's a ticket :)
18:44:06 <andythenorth> I need to fix that one :)
18:44:48 <Alberth> yeah, it makes playing with trucks less fun
18:45:40 <planetmaker> andythenorth: checkout the FS entry again
18:46:06 *** Cybertinus has joined #openttd
18:46:10 *** devilsadvocate has joined #openttd
18:46:32 <andythenorth> that would be a nice one for trunk :o
18:47:26 <Rubidium> I'm still wondering whether Ctrl-Click unload should trigger "Transfer and leave empty"
18:51:29 <Vitus> That sounds like good idea, indeed :)
18:51:31 <planetmaker> might be a nice idea, Rubidium
18:55:39 *** devilsadvocate has quit IRC
18:58:56 *** devilsadvocate has joined #openttd
19:05:24 <avdg> looks like we have another crash :(
19:07:06 *** devilsadvocate has quit IRC
19:08:15 <planetmaker> wrong os, avdg :-P
19:09:26 <Rubidium> avdg: file a bug report with the crash.dmp and all other related files
19:10:14 <Rubidium> and that ancient 0.3.[34] savegame you're loading
19:12:29 <Rubidium> planetmaker: the 4066 diff fixes your problems? As it won't fix my 4066 crash
19:13:01 <planetmaker> hm. avdg said he could also still crash it
19:13:19 <planetmaker> but from what I tested, it didn't crash here then anymore
19:13:34 <avdg> donno, its better to let him give the word
19:13:35 <Eddi|zuHause> might be two differrent crashes
19:13:42 <Rubidium> so there's a "not high enough" and "not wide enough" crash in there
19:16:00 <CIA-2> OpenTTD: frosch * r20595 /trunk/src/vehicle_cmd.cpp: -Fix (r20536)[FS#4068]: Autoreplace needs refitting of wagons in free wagon chains.
19:17:26 <avdg> so giant has a random crash, so he doesn't know the source of it
19:22:39 *** fmauneko has joined #openttd
19:24:13 <frosch123> 0.3.x savegames are not random
19:25:10 <Giant> you basically named all I know atm haha
19:26:38 <avdg> do you have still problems with the binaries?
19:27:23 <Rubidium> avdg: so he's the guy of the crashlog you pasted?
19:28:43 *** TruePikachu has joined #openttd
19:28:43 <Giant> doesn't really happen to often when actually playing though
19:28:54 <Giant> mostly at starting the game up
19:30:29 <frosch123> ah, so it is the titlegame
19:30:41 <Rubidium> avdg: in that case Giant should post the crash.log, crash.dmp, crash.png, crash.sav etc to bugs.openttd.org
19:30:54 <avdg> I know, he's kinda lazy :p
19:33:34 <Rubidium> avdg: if he's too lazy we can't fix the bug he is triggering
19:34:10 <Giant> am already working on it....
19:36:20 <Giant> Rubidium: no crash.sav existant
19:36:59 <Rubidium> then attach the savegame you were loading/did load before it crashed (the OpenTTD 0.3.3/0.3.4 one)
19:37:11 <Giant> wasn't loading this time
19:37:24 <Giant> was updating/downloading newgrfs this time
19:38:06 <Rubidium> so you've already let OpenTTD overwrite the previous crashlog, the one avdg showed a while ago?
19:38:45 <frosch123> Rubidium: isn't the titlegame a 0.3.4 one?
19:40:02 <Alberth> then it should be ok :)
19:40:28 <Rubidium> guess the addition of NewGRFs did uhm... fool me
19:40:46 <avdg> rubidium: same steps, same error
19:41:16 <Rubidium> avdg: build a debug build, run it in gdb and once it crashes "bt full" and pastebin that
19:41:44 <avdg> hmm never ran a debug build
19:41:57 <Rubidium> ./configure --enable-debug=3
19:42:19 <Rubidium> wait a bit for it to compile and start OpenTTD, reproduce issue
19:42:35 <Rubidium> type "bt full" in the (gdb) prompt
19:43:41 <avdg> hmm does it matter if the patch is applied or not?
19:51:43 <Rubidium> could you paste the last few lines of the console then? Basically from after the compilation completed
19:53:59 <avdg> I've run openttd in an other cli tab
19:54:02 *** LunarWolf has joined #openttd
19:54:29 <Rubidium> avdg: type run in that gdb window
19:54:56 <Rubidium> make run-gdb is supposed to start OpenTTD when gdb is started, but apparantly there's yet another thing that doesn't work on Mac OS X
19:55:49 <avdg> should I type bt full again?
19:58:28 <LunarWolf> hi, trying to find the culprit responsible for the malfunction signaling.
19:58:46 <Rubidium> LunarWolf: 32bpp graphics?
19:59:05 <Rubidium> then (s)he's most likely not here
19:59:41 <Agame> how many days are there in openttd calendar?
19:59:43 <Rubidium> avdg: hmm, that trace looks way different from what I could reproduce
20:00:16 <LunarWolf> but I noticed that when you try to extract the files "BaseSet" something crashes and I have no spirites
20:00:19 <planetmaker> Rubidium: the make run-gdb required configure debug=3 or otherwise normally, too?
20:00:55 <Rubidium> Agame: but that's the total number of unique days in OpenTTD; generally it's 365 or 366 a year
20:01:17 <Rubidium> planetmaker: make run-gdb doesn't require a particular debuglevel, but... the higher the better the information
20:02:13 <avdg> pm: you're right about the missing sprites, the bugreport is clear as water
20:02:23 * Rubidium wonders why avdg's OpenTTD thinks of dragging windows, or is it that he dragged a window when he made the resolution really low?
20:02:36 <avdg> its smaller then the caption bar
20:03:05 <avdg> same steps as on the bugreport
20:03:10 <planetmaker> that's particular to your build. doesn't crash for me
20:03:44 <Rubidium> avdg: but then I can't reproduce it because as soon as I release my mouse the window gets forced to the minimum 64x64 pixels
20:03:58 <Rubidium> which is way higher than the few pixels you've got
20:04:08 <Rubidium> and that means that that issue is Mac OS X specific
20:04:53 <planetmaker> hm... draging which window? Main window or an ingame window?
20:05:21 <Rubidium> but to drag a window in OpenTTD you need to release the mouse resizing the window, right?
20:05:25 <planetmaker> Rubidium: you OpenTTD window gets forced to 64^2 pixels?
20:06:13 <LunarWolf> ! E: \ Game MOD \ OpenTTD \ 32bpp \ Graphics Base Set \ baseset_12-03-10 \ BaseSet.tar: Can not open ogfxe_extra (sprites \ openttdd -> ogfxe_extra)
20:06:20 <planetmaker> avdg: does it still happen, if you update your OpenGFX, that is if the error message doesn't exist anymore?
20:06:54 <planetmaker> you'll need to get a nightly download of it
20:07:25 <avdg> its not in the online content
20:07:38 <avdg> can you provide me the url then?
20:08:00 <LunarWolf> so with all the files in the sprites 'baseset_12-03-10'
20:08:27 <planetmaker> oh. Well, my windows were 1px hight, if I wanted. let's see
20:08:54 <avdg> should I leave the other patch too?
20:09:12 <Rubidium> glx: he's using the 32bpp extra zoom thing
20:09:13 <glx> LunarWolf: there use to have openttdd.grf and openttdw.grf, but in recent nightlies there's only openttd.grf
20:11:15 <LunarWolf> This is a WinRAR archive
20:11:43 <Rubidium> OpenTTD can't open winrar files
20:12:24 <LunarWolf> PCX unpacked correctly
20:13:19 <Rubidium> avdg: new version, same url
20:13:59 <Rubidium> new version of the diff, with the same url, for you to try
20:14:06 <Rubidium> might fix your compile error
20:14:28 * Rubidium wonders why he's going on this hack-and-stab approach of fixing OS X specific bugs again...
20:16:19 <Rubidium> avdg: arguably you just applied a diff as you got compile errors on the lines that diff changed. I maybe have fixed those compile errors and uploaded a new version of that diff with the same name, i.e. the url remained the same
20:16:52 <Rubidium> then your browser is stupid in caching the file
20:17:12 <Rubidium> anyhow s/max/max<int
20:17:14 <Rubidium> anyhow s/max/max<int>/
20:18:52 <avdg> hmm have to reapply both patches, before svn and patch complains :p
20:19:54 * avdg isn't happy about freezing terminal
20:21:21 <planetmaker> window can still be made to 1px height with that patched
20:21:40 <avdg> that patch is osx specific isn't it?
20:21:51 <Rubidium> yes, it's very osx specific
20:22:20 <avdg> ok, I can't drag the window and nothing happens
20:23:24 <avdg> if thats what you've had in mind, then its ok
20:23:34 <LunarWolf> whether it is signaling slump 32bpp graphics, without removing other graphics
20:23:54 <Alberth> avdg: (about terminal freezing) forgot the < or the -i option of patch ?
20:24:35 <Alberth> good programmers type a patch from the keyboard :p
20:26:00 <CIA-2> OpenTTD: rubidium * r20596 /trunk/src/misc_gui.cpp: -Fix [FS#4066]: crash when the tooltip is wider than the window is
20:31:59 <avdg> I can make it smaller then 64 pixels, but when its smaller, the "paint" isn't updated and it doens't receive input from mouse and keyboard
20:33:44 <Rubidium> ah well, can't be bothered anymore. Just filed a bug report about OSX not obeying the 64x64 minimum size
20:34:11 <Rubidium> and those remaining crashes are "just" caused by that issue
20:35:21 <avdg> well, I'm happy openttd doesn't crash, for now
20:35:58 <avdg> :p but its a kinda strange bugreport, isn't it
20:36:49 <avdg> no, the minimum size in general
20:37:41 <Rubidium> anything below 320x240 is (IMO) unplayable, so why should we even support those hypothetical cases?
20:37:59 <Markk> Is there any port to Android?
20:38:28 <Rubidium> whether it works I don't know
20:38:31 * avdg gives an reward for someone who invents openttd on 100x100
20:38:46 <Rubidium> probably won't ever get on android market either
20:39:13 <Wolf01> Rubidium, yes I play it on my 8x8 led matrix :D
20:40:40 <Markk> Rubidium: you know where I can find it?
20:41:11 <Rubidium> nope, just got a mail of someone saying he had made one
20:49:40 *** welshdragon has joined #openttd
20:50:02 *** ChanServ sets mode: +v tokai
20:50:18 <PeterT> I hate those damn patched servers that make everyone think that /reset is a valid command
20:50:31 <Eddi|zuHause> <Agame> how many days are there in openttd calendar? <-- it's a zero-based normalized gregorian calendar, so 365.2425 days
20:51:06 <Eddi|zuHause> hm, i guess he's already gone
20:53:10 <Vitus> OpenTTD obeys this completly, right? (I mean, leap year every 4 years, no leap year every 100 years and leap year every 400 years)
20:54:03 <Eddi|zuHause> and opposing to the real historical calendars, it hss a year 0
20:54:18 <Eddi|zuHause> historically, it jumped from -1 to +1
20:56:02 * avdg wonders if there is someone playing before the year 0
20:56:16 <Eddi|zuHause> that is not possible
20:56:33 <Eddi|zuHause> openttd starts in year 0 and ends in year 5000000
20:56:53 <Eddi|zuHause> which amounts to the number of days Rubidium mentioned above
20:57:32 <Eddi|zuHause> @calc 5*10**6*365.2425
20:57:32 <DorpsGek> Eddi|zuHause: 1826212500
20:58:16 <DorpsGek> Eddi|zuHause: 2147483648
21:00:36 <Eddi|zuHause> @calc 1/4-1/100+1/400
21:00:36 <DorpsGek> Eddi|zuHause: 0.2425
21:00:43 <Rubidium> @calc 1826212865 - 1826212500
21:01:01 <Rubidium> ah yes... that explains
21:01:28 <Eddi|zuHause> it's 5000001 years
21:13:00 *** orudge` has joined #openttd
21:13:00 *** ChanServ sets mode: +o orudge`
21:15:20 <Rubidium> the legal alien has arrived, just not quite in New York it seems :)
21:16:30 *** LunarWolf has joined #openttd
21:18:39 <LunarWolf> I installed OpenTTD whole again and I noticed that:
21:18:56 <TruePikachu> Could someone please integrate FS#4065 for me, please?
21:19:10 <LunarWolf> 32bpp_extra-nightly-R38 has a conflict with baseset_12-03-10
21:20:10 <TruePikachu> It would be nice if you can tell how much your game is lagging, especially with development now, where lots of things contrubute to lag ;)
21:22:25 <TruePikachu> LunarWolf: That was not exactly @ you
21:22:43 <TruePikachu> I just want to know how much my game lags, so I made FS#4065
21:23:32 <TruePikachu> The computer was built for Win98, and I put Linux on it
21:24:19 <TruePikachu> Slackware, of course, to get the best preformance, but OpenTTD is being a bit sluggish graphics-wise with 120 vehicles
21:24:26 <LunarWolf> FS # 40650 - do not know the
21:24:44 <TruePikachu> No zero at the end
21:25:22 <Rubidium> LunarWolf: just ignore him :)
21:26:04 <TruePikachu> ^ that's wrong too, you put two Ks
21:27:15 <TruePikachu> Rubidium: Why do you keep thinking I'm trying to troll?
21:27:18 <Eddi|zuHause> TruePikachu: TT (original) ran slightly laggish on a 486DX66 with a 256^2 map with 80 trains and ~360 vehicles total.
21:28:14 <TruePikachu> Eddi|zuHause: Well, This is a PIII running at 800MHz, 192MB RAM, and it seems to lag on 120 vehicles total
21:28:29 *** Brianetta has joined #openttd
21:28:36 <TruePikachu> Although I am not sure if it's preformance lag or graphics lag
21:28:41 <Eddi|zuHause> vehicles being each wagon counted individually
21:28:51 <TruePikachu> (i.e. if each tick is still 30ms)
21:29:01 <TruePikachu> Eddi|zuHause: Oh, well, see previous comment
21:29:15 <LunarWolf> I will not have problems with using such number of trains
21:29:42 <TruePikachu> Well, I can't really upgrade my computer anytime soon ;)
21:30:28 <TruePikachu> It would be nice if there was a way to measure lag
21:31:12 <Eddi|zuHause> currently the most time consuming part is AIs using up all available opcodes
21:31:21 <TruePikachu> That's why I created FS#4065 - it tells you how fast the graphics are being, and how fast the game is being
21:31:28 <Eddi|zuHause> you can reduce that number, but afair not during a running game
21:31:35 <TruePikachu> ...at least, it would tell you if implimented
21:31:49 * andythenorth is looking for European bo-bo locomotives to MOC in Lego
21:32:04 <andythenorth> got to be full width body
21:33:01 <LunarWolf> old times, I have 2 computers, the one currently in use, and the second is the 3D graphics, animation, rending
21:33:42 <Eddi|zuHause> andythenorth: E04, E18, E11, E03? (not sure if they really all were Bo'Bo')
21:33:48 <TruePikachu> Xrufuian told me at one point that he could get old parts from his upgrading of his computers
21:34:15 <TruePikachu> But school, the only place where I could actually _get_ the parts themselves, doesn't start for 3 more weeks
21:34:54 <TruePikachu> So, for right now, I would need a software solution
21:35:00 <LunarWolf> OMG. Even three hours rendering
21:36:43 <TruePikachu> I'm not sure, but KDE may be causing part of the problem
21:37:38 <TruePikachu> It would be nice if I could find an X server which will run JUST OpenTTD, instead of tons of background components as well
21:38:24 <TruePikachu> (i.e. I could just do something like "<x server> openttd" from the terminal)
21:38:35 * andythenorth searches for Lego parts that suit
21:39:37 <TruePikachu> andythenorth: Are your parts sorted?
21:40:04 <andythenorth> I have to buy more for a new train though
21:40:07 <TruePikachu> I have this big tub full of Legos
21:40:16 <TruePikachu> None of them are sorted :P
21:40:42 <TruePikachu> Pain in the butt and pain in the hands
21:40:52 <andythenorth> I have a tub like that
21:41:04 <andythenorth> I need to sort it :P
21:43:03 <avdg> :/ why didn't I report other issues *blames hisself*
21:44:47 <LunarWolf> 32bpp_extra-nightly-R38 is incompatible, the signals are not working properly
21:45:00 <Rubidium> andythenorth: doesn't look in any way like my family
21:45:28 <Rubidium> LunarWolf: you're better off writing such stuff in the 32bpp graphics subforum
21:45:47 <Rubidium> because most here can't be really bothered with the whole extrazoom 32bpp graphics stuff
21:47:34 <LunarWolf> 32bpp_extra-nightly-R28 and it works correctly
22:01:58 *** Devroush has joined #openttd
22:19:24 *** Noldo_ is now known as Noldo
22:33:44 <Eddi|zuHause> andythenorth: and the page you linked to opens in editor, not in browser [probably wrong mime type]
23:06:47 *** roboboy has joined #openttd
23:55:10 * TruePikachu is watching the LED counter
continue to next day ⏵