IRC logs for #openttd on OFTC at 2008-11-16
⏴ go to previous day
00:09:44 <Eddi|zuHause> interesting, "kfnmnpa" gives 4 google results ;)
00:12:19 <Eddi|zuHause> wasn't there once a competition to find a word that gives exactly one google result?
00:12:42 <SpComb> or perhaps it was two dictionary words that give exactly one result
00:13:44 <Eddi|zuHause> what's more interesting about "kfnmnpa" is that these seem like german sites, what was there in the english version?
00:17:58 <Eddi|zuHause> it's a scene from scrubs, where turk changes his cell phone number to "call tur(k)", and J.D. says he can't remember that, and he'd stay with "kfnmnpa"
00:24:51 <Aali> Eddi|zuHause: its kfnmnpa in english too
00:33:15 *** Eddi|zuHause has joined #openttd
01:15:58 *** HerzogDeXtEr1 has joined #openttd
01:16:29 *** Yeggstry is now known as Yeggzzz
01:19:48 *** XeryusTC is now known as Xeryus|bnc
01:19:49 *** Sacro__ has joined #openttd
01:24:37 *** ChanServ sets mode: +v tokai
04:25:03 *** Doorslammer has joined #openttd
04:28:15 *** DASPRiD is now known as DASPRiD|off
05:31:51 <George> OTTD devs, what about FS 1941? A patch was updated as frosch has suggested.
06:52:40 *** Singaporekid has joined #openttd
07:41:13 *** FloSoft has joined #openttd
07:48:24 *** Alberth has joined #openttd
08:00:12 *** DephNet[Paul] has joined #openttd
08:08:38 *** De_Ghosty has joined #openttd
10:50:54 *** Progman has joined #openttd
11:07:36 *** Swallow has joined #openttd
11:07:41 *** Vikthor has joined #openttd
11:07:42 <yorick> why are the MP_VOID tiles still kept?
11:11:34 *** stillunknown has joined #openttd
11:33:30 *** FloSoft has joined #openttd
11:42:31 *** Yeggzzz is now known as Yeggstry
11:43:33 *** Dred_furst has joined #openttd
11:44:29 <CIA-5> OpenTTD: truebrain * r14579 /branches/noai/ (bin/ai/regression/regression.txt src/ai/api/ai_engine.cpp): [NoAI] -Fix: ships have their own rules for refitting (Morloth)
11:52:22 *** Belugas has joined #openttd
11:52:22 *** ChanServ sets mode: +o Belugas
12:29:05 *** yorick is now known as Guest3547
12:39:34 *** Xeryus|bnc is now known as XeryusTC
12:44:10 <yorick> debug builds are 30 mb :o
12:48:27 <FauxFaux> 7-zip'll fix that quite quickly.
12:52:09 <Alberth> hg repo of trunk is already 70MB without building anything
12:53:00 <Rubidium> that's what a few years of history does ;)
12:55:32 <Eddi|zuHause> time for another repository crash :p
12:57:35 <Rubidium> then we'd just reimport a hg/git repository
12:58:40 <Eddi|zuHause> but that wouldn't solve the history size problem then :p
13:01:13 <Qball> git normally manages history quiet efficient
13:02:45 <Ammler> is ottd git repo smaller?
13:05:51 <CIA-5> OpenTTD: rubidium * r14580 /trunk/ (Makefile.bundle.in media/ os/win32/installer/install.nsi): -Fix [FS#2404]: scripts directory not being copied into bundles.
13:06:38 <yorick> Rubidium, I still don't see the use of a double-check on a CMD_OFFLINE command...
13:07:07 <yorick> better just remove the CMD_OFFLINE-ness if running debug mode
13:07:28 <yorick> and make it CMD_SERVER?
13:15:14 <Eddi|zuHause> sounds like a horrible idea
13:15:26 <Eddi|zuHause> the server might be a player, too
13:15:47 <Eddi|zuHause> which would then be unlimitedly able to cheat
13:17:23 <yorick> what did you think I need it for...
13:19:48 *** NukeBuster has joined #openttd
13:22:36 <yorick> nono, feeding the landflattener-restore script
13:23:04 <yorick> I can't be a control-freak admin without unlimited money!
13:24:17 <yorick> btw, you have no way to access the money-cheat in non-debug mode
13:25:00 <planetmaker> hu? Works for me in SP.
13:25:29 <yorick> the client-side check is not really needed
13:25:43 *** Antdovu has joined #openttd
13:32:53 *** Hirundo has joined #openttd
13:38:35 *** Hirundo is now known as Swallow
13:50:09 <CIA-5> OpenTTD: rubidium * r14581 /trunk/src/rail_cmd.cpp: -Fix: make rail, road and canal building behave the same when overbuilding already built stretches.
13:52:51 *** Singaporekid has joined #openttd
14:07:54 *** Eddi|zuHause has joined #openttd
14:08:07 *** ChanServ sets mode: +v tokai
14:08:43 <yorick> SB(_m[t].m3, 0, 2, 1); <-- if I do this, will bit 0 be set to 1?
14:12:00 <yorick> SB(_m[t].m3, 2, 0, 1); <-- and if I do this, bit 1 is set to 1?
14:12:53 <SmatZ> 2 = starting bit position 0 = number of affected bits (0 is meaningless here) 1 = value to write
14:13:52 <glx> SB(_m[t].m3, 0, 2, 2); or SB(_m[t].m3, 1, 1, 1); or SETBIT(_m[t].m3, 1);
14:18:03 <CIA-5> OpenTTD: rubidium * r14582 /trunk/src/ (lang/english.txt terraform_cmd.cpp terraform_gui.cpp):
14:18:03 <CIA-5> OpenTTD: -Fix [FS#2392]: blank box on cost estimation of levelling a flat area.
14:18:03 <CIA-5> OpenTTD: -Fix: make levelling, raising and lowering of an area behave the same.
14:21:38 *** TrogDoor has joined #openttd
14:24:42 * sladen thought it would pop by after having made the effort of signing up with flyspray
14:25:26 <sladen> do we have a 'Rubidium' around here?
14:27:03 <planetmaker> never seen or heard of him :P
14:27:35 <planetmaker> except... when looking through commit list, talking about OpenTTD and stuff ;)
14:28:43 * Rubidium doesn't remember seeing or hearing a 'Rubidium' either
14:29:57 <Antdovu> what is this 'OpenTTD' you keep talking about?
14:30:43 <planetmaker> Open tedious tasks in development ;)
14:31:49 <Eddi|zuHause> how do MSVC builds get endian_target.h?
14:34:31 <Rubidium> Eddi|zuHause: they don't
14:34:46 <Eddi|zuHause> then why is this thing telling me it doesn't find it...
14:36:13 <Rubidium> Eddi|zuHause: probably because WIN32/WIN64 isn't defined
14:36:25 <sladen> Rubidium: the error comes (of the bug that was closed earlier) comes from gfxinit/CheckExternalFiles(); which is checking only that the uppercase MD5s in tables/files.h files_win[] match
14:36:45 <glx> and that's weird as WIN32/WIN64 are magically defined
14:37:14 *** stillunk1own has joined #openttd
14:37:33 <Rubidium> sladen: so you weren't using trunk?
14:38:10 * sladen looks. apparently not. 0.6.0
14:39:05 <glx> so why did you set reported version to trunk ?
14:39:13 <Eddi|zuHause> well, i don't exactly use MSVC :p... my command line looks something like this: edgcpfe --microsoft --microsoft_bugs --microsoft_version=1400 -x -e3 -tused -D_M_IX86=500 -DWIN32 -D_CONSOLE -DWIN32_EXCEPTION_TRACKER -DWIN32_ENABLE_DIRECTMUSIC_SUPPORT -DWITH_ZLIB -DWITH_PNG -DWITH_FREETYPE -DENABLE_NETWORK -DWITH_PERSONAL_DIR -DPERSONAL_DIR=\"OpenTTD\" -DWITH_ASSERT articulated_vehicles.cpp
14:39:29 <sladen> glx: because it my old tree on the harddrive
14:39:45 <sladen> glx: so this is something that got changed/fixed in the last 6 month
14:40:00 <Eddi|zuHause> where i read the -D thingies out of the vcproj
14:40:19 <glx> sladen: I mean "Reported Version ,...trunk" in the FS task details
14:40:52 <Eddi|zuHause> rortom: well, there are things that microsoft does non-standard, and things, that microsoft does plainly wrong :p
14:41:08 <Eddi|zuHause> hence the two switches for microsoft dialect ;)
14:41:15 <rortom> Eddi|zuHause: who wonders ;)
14:41:36 <Rubidium> sladen: nothing did change the last 6 months; since *at least* 0.4.0 both uppercase and lowercase are checked
14:42:26 <sladen> let me suck down the latest over GPRS and I'll retest
14:42:49 <Rubidium> sladen: furthermore it works on unix with lowercase names
14:43:38 <sladen> Rubidium: (that aside, in this particular case, on this particular machine, on this particular day, I have a repeatable issue)
14:44:20 <glx> and why not put the files in the usual places? like ~/.openttd/data ?
14:44:21 <sladen> bugs are things that occur when what is intended does not match what actually happens
14:45:29 <sladen> glx: I unpacked them, cd'ed to that directory, ran openttd. To move them is extra hassle; and increases the general barrier to entry
14:46:26 <glx> but openttd still searches them in a data subdir
14:46:56 <glx> be it in ~/.openttd, cwd, install dir or /usr/local/games/openttd
14:47:54 <sladen> so moving them (or rather a symlink) into ~/.openttd/data does make it start without complaint
14:48:34 <sladen> so the actual issue is openttd not finding lowercase datafiles when in the current directory
14:48:53 <Antdovu> resizing windows: uint diff = delta.x / 2; <-- should really be a signed type
14:49:18 <sladen> Antdovu: what if the window origin is off-screen
14:49:26 <glx> the actual issue is you not reading the readme file :)
14:50:28 <sladen> glx: well, I can't argue with that.
14:51:29 <Rubidium> sladen: the actual issue is more openttd finding the uppercase datafiles when in the current directory
14:55:57 *** stillunknown has joined #openttd
15:11:10 <sladen> Rubidium: oh? (ah, it doesn't find uppercase, so skips the check without complaining?)
15:15:13 <sladen> nope, mixed case fails
15:15:36 *** TrogDoor is now known as Doorslammer
15:15:50 <sladen> Rubidium: puzzled, did you intentionally write _uppercase_?
15:19:48 <Rubidium> sladen: I do not see *any* reason why it would find them uppercased and it wouldn't find them lowercased. For each location where the uppercase could fail immediately the lowercase version is tried, unless you've got a non-official binary
15:20:51 <Rubidium> I can't even reproduce it locally
15:21:15 *** |Jeroen| has joined #openttd
15:33:05 <Ammler> how would you make a "or" statement with nfo?
15:35:16 <Ammler> something like "if not (param1 or param2) then goto x"
15:35:48 <Eddi|zuHause> not (a or b) == (not a) and (not b)
15:37:16 <Ammler> and how to make a and?
15:38:11 <Aali> Ammler: just chain up some action7's
15:38:21 <Ammler> yeah, that would need 3
15:38:32 <Eddi|zuHause> if (a and b) == if (a) if (b)
15:38:34 <Ammler> I am thinking, if it would work with 2?
15:39:09 <Ammler> if would skip a unconditional jump
15:40:53 <Eddi|zuHause> i don't see your problem
15:41:22 <Ammler> Eddi|zuHause: is it possible with 2 action7?
15:41:30 <Aali> if you want to leave out the unconditional jump, just invert the logic
15:42:44 <Aali> you would of course need to adjust the skip values
15:43:27 <Eddi|zuHause> can't you do expression evaluation with advanced action 2?
15:44:56 <Eddi|zuHause> or maybe you should use a higher level language that just gets compiled into NFO
15:45:32 <Ammler> well, I do it with my 3, I was just wondering
15:46:01 <Eddi|zuHause> well, the problem you face is probably very common for assembler problems
15:50:08 <Ammler> he, now I know, why my escapes don't work
15:50:38 <Ammler> as I compiled nforenum
15:54:10 <Eddi|zuHause> error: no operator "-=" matches these operands
15:54:11 <Eddi|zuHause> operand types are: std::list<CargoPacket *,
15:54:13 <Eddi|zuHause> std::allocator<CargoPacket *>>::_Iterator<true> -=
15:54:20 <Eddi|zuHause> maybe i should give up...
15:55:18 <Antdovu> if all else fails, read the manual/docs/interface
15:55:44 <Alberth> Eddi|zuHause: you seem to subtract a ptrdiff from a list<> container
15:55:52 <Aali> Eddi|zuHause: what exactly are you doing anyway?
15:56:06 <Rubidium> he's trying to move an iterator more than one position at a time
15:56:12 <Eddi|zuHause> getting this compiler to compile openttd
15:56:39 <Aali> Eddi|zuHause: well its not ready for it :P
15:56:47 <Alberth> Eddi|zuHause: svn revert ; ./configure ; make :)
15:57:15 <Eddi|zuHause> Alberth: it's about the compiler, not about openttd
15:57:41 <Eddi|zuHause> and apparently it's getting confused with the template instantiation
15:57:41 <Rubidium> and looking at the specs... the random access iterator which Eddi|zuHause assumes he is using isn't used for iterating lists
15:58:47 <Eddi|zuHause> i didn't make any modifications to the source... that would be silly for such a test ;)
15:58:57 <Alberth> Rubidium, Eddi|zuHauseoh right, I missed the ::Iterator<true> :(
16:00:48 <Eddi|zuHause> well, if i change instantiation method from -tall to -tused, i get this error:
16:00:49 <Eddi|zuHause> "autoreplace.cpp", line 14: error: identifier "_EngineRenew_pool" is undefined
16:00:52 <Eddi|zuHause> DEFINE_OLD_POOL_GENERIC(EngineRenew, EngineRenew)
16:01:39 <Rubidium> then the compiler's not understanding that _EngineRenew_pool is used?
16:12:39 <Eddi|zuHause> when i manually expand the macro, it changes to this message:
16:12:42 <Eddi|zuHause> "/home/johannes/spiele/OpenTTDx/trunk/src/autoreplace.cpp", line 14: error:
16:12:45 <Eddi|zuHause> identifier "_EngineRenew_pool" is undefined
16:12:45 <Eddi|zuHause> OldMemoryPool<EngineRenew> _EngineRenew_pool( "EngineRenew", EngineRenew_POOL_MAX_BLOCKS, EngineRenew_POOL_BLOCK_SIZE_BITS, sizeof(EngineRenew), PoolNewBlock<EngineRenew, &_EngineRenew_pool>, PoolCleanBlock<EngineRenew, &_EngineRenew_pool>); template EngineRenew *PoolItem<EngineRenew, EngineRenewID, &_EngineRenew_pool>::AllocateSafeRaw(uint &first);
16:13:14 <Eddi|zuHause> so it chokes on this reference to itself, or something...
16:17:33 *** Ridayah has joined #openttd
16:20:54 <Antdovu> how can I make my window catch all keystrokes, not just some of them?
16:22:05 *** lobstar is now known as lobster
16:23:05 <Antdovu> it gets esc, enter, some letters but not 'l' (opens landscape toolbar instead)
16:32:36 *** lobster_MB has joined #openttd
16:45:13 *** Hirundo has joined #openttd
16:45:14 *** Hirundo is now known as Swallow
16:51:59 <Eddi|zuHause> Antdovu: there are some global shortcuts, it'll be difficult to override those
16:52:06 <Eddi|zuHause> except you have a text field
16:54:02 *** KillaloT has joined #openttd
16:55:49 <Antdovu> I have "struct SaveLoadCompanyInfoWindow : public QueryStringBaseWindow"
16:57:05 <Antdovu> I basically used the save/load window as a reference
17:06:35 <china> anyone good at autocad mechanical '08 here? i need help with changing the font size on the output of linear measurment lines.
17:15:13 <Ammler> if I use the special control string 0E, it does make the text smaller after but the linehigh for the whole text
17:15:56 <Ammler> is that, why nforenum warns about?
17:16:39 <Ammler> nforenum complains also about colors...
17:22:47 <Swallow> @china I don't know anything about your specific version, but in AutoCAD 2007 the DIMSTYLE command is most likely what you're looking for
17:37:32 *** questionmark has joined #openttd
17:37:39 *** yorick is now known as Guest3574
17:37:39 *** questionmark is now known as yorick
17:46:44 <ln> ¿donde están Gonozal_VIII y meush?
17:48:27 *** Hirundo has joined #openttd
17:50:23 <Eddi|zuHause> yorick: what exactly is this picture supposed to tell us?
17:50:52 <yorick> my 'lively' river flooded the town
17:51:10 *** Hirundo is now known as Swallow
17:51:19 <Eddi|zuHause> well, obviously you should add rivers before towns :p
17:52:18 <Eddi|zuHause> and it needs a higher chance for bending before it hits an obstacle ;)
17:53:00 <yorick> it currently has no chance of bending at all :-p
17:53:13 <Antdovu> hint: make sure not to overflow the buggers
17:53:13 <yorick> unless it hits an obstacle, that is
17:54:25 <yorick> how should I be able to overflow the buffers?
17:55:17 <Eddi|zuHause> build a buffer. flow the river over it
17:55:37 <Antdovu> just check for null pointer
17:56:23 <Eddi|zuHause> next thing he'll tell us is to defrag the hdd
17:56:33 <Antdovu> sometimes you can have leaks so rivers go underground
17:57:03 <Antdovu> that way you can overflow the basements
17:57:31 <Antdovu> any of you confused now?
17:57:49 <yorick> and that's a too big chance
17:57:56 <yorick> it looks more like a snake now
17:59:09 *** frosch123 has joined #openttd
18:00:30 <yorick> random is rather predictable...
18:02:59 <Antdovu> you can always distill randomness...
18:59:34 <CIA-5> OpenTTD: translators * r14583 /trunk/src/lang/ (6 files in 2 dirs): (log message trimmed)
18:59:34 <CIA-5> OpenTTD: -Update: WebTranslator2 update to 2008-11-16 18:59:11
18:59:34 <CIA-5> OpenTTD: dutch - 4 changed by Excel20 (4)
18:59:34 <CIA-5> OpenTTD: english_US - 7 fixed by WhiteRabbit (7)
18:59:34 <CIA-5> OpenTTD: french - 2 fixed, 2 changed by glx (4)
18:59:36 <CIA-5> OpenTTD: persian - 21 fixed by ali sattari (21)
18:59:36 <CIA-5> OpenTTD: portuguese - 49 fixed by joznaz (49)
19:02:04 *** questionmark has joined #openttd
19:02:12 *** mortal` has joined #openttd
19:10:13 *** Hirundo has joined #openttd
19:11:56 *** Hirundo is now known as Swallow
19:17:50 <Antdovu> openttd has been discontinued
19:17:58 <planetmaker> openttd: /home/openttd/svn-public/src/oldpool.h:125: T* OldMemoryPool<T>::Get(uint) const [with T = Station]: Assertion `index < this->GetSize()' failed.
19:18:00 <planetmaker> Server has exited <-- r14572. is it known?
19:19:12 <SmatZ> planetmaker: I saw that today at PS, but failed to reproduce :-x
19:19:34 <planetmaker> yeah, thats from ps right now
19:21:08 <SmatZ> the same assert twice in one day
19:21:36 <Rubidium> the savegame can already be compromised
19:21:43 <Eddi|zuHause> background radiation ;)
19:22:21 <Aali> any specific reason why openttd doesn't get a backtrace on its own?
19:22:55 <Rubidium> because there isn't a cross-platform-compatible way to do that
19:23:05 <Eddi|zuHause> Aali: do you want to compile a debugger into every binary?
19:23:17 <Rubidium> and releasing 30+MB binaries isn't quite what we want to do either
19:25:27 <Aali> because those are some lame excuses
19:25:33 <Aali> and they dont make any sense
19:26:18 <Aali> you dont have to generate a proper backtrace for every platform out there for it to be useful
19:26:38 <Antdovu> so for which one do you want to generate it?
19:26:38 <Rubidium> Aali: so, what platforms should we do it for?
19:26:40 <Aali> you dont have to resolve symbols, just printing the address is fine for official builds
19:27:13 <Eddi|zuHause> Aali: MSVC releases do that already
19:27:37 <Eddi|zuHause> they produce a crash.dmp file, which you can then load into the MSVC debugger
19:28:16 <Aali> yeah, and thats great, what about other platforms?
19:28:26 <petern> 19:26 < Aali> you dont have to generate a proper backtrace for every platform
19:28:28 <Aali> something similar should be doable for linux, at the very least
19:28:30 <Eddi|zuHause> and my wild guess is that these are 98% of all binaries out there
19:28:36 <Rubidium> Eddi|zuHause: not that those dumps contain much usuable information
19:29:00 <Rubidium> Aali: please show me your implementation
19:29:12 <Eddi|zuHause> i did not say that... but a random backtrace does not usually contain enough useful information either ;)
19:30:31 <SmatZ> though... even printing 256 bytes on top of stack would help
19:32:42 <Eddi|zuHause> or you could just run the server in gdb
19:33:26 <Aali> unless you want to make a habit of always running it in gdb, but thats just wrong :/
19:33:54 <Eddi|zuHause> Aali: so instead you want to compile gdb into the binary for all people?
19:34:16 <Aali> Eddi|zuHause: printing the top of the stack is hardly compiling gdb into the binary
19:35:00 <Rubidium> telling people to upload their binary so we can debug it is useful?
19:35:26 <Eddi|zuHause> no, but it's nothing compared to a human readable or even interactive representation of the program state either
19:35:45 <Aali> why would they need to upload their binary?
19:35:58 <Rubidium> Aali: because the stacktrace depends heavily on the binary
19:36:05 <Aali> if its not an official binary its not your problem
19:36:09 <Rubidium> and because the binary usually isn't a binary build by us
19:36:20 <SmatZ> it could help for debugging releases (when people usually use the precompiled binary)
19:36:29 <Eddi|zuHause> Aali: because 80% of all people who run linux and report bugs use custom binaries
19:37:09 <Eddi|zuHause> and 87% of all statistics are made up on the fly :p
19:37:38 <Aali> Eddi|zuHause: and what did you lose there? what happens to those people? are they going to be pissed because they got some extra bytes on their system?
19:38:29 <Rubidium> Aali: the unix/osx people that report crashes have (as far as I can remember) always used custom build binaries
19:38:43 <Eddi|zuHause> Aali: backtraces of those binaries are 100% useless unless you have the exact binary to match
19:38:44 <Aali> its not going to hinder debugging with homebrewed binaries, and its sure to help people who do use the official binaries
19:39:33 <Eddi|zuHause> Aali: it's about developers debugging other people's bugs
19:40:29 <Aali> and that will suffer from this simple addition?
19:40:44 <Eddi|zuHause> no, but it will not gain anything
19:40:54 <Eddi|zuHause> which makes it an unreasonable effort
19:41:10 <Aali> fine, whatever, its your loss
19:41:39 <Eddi|zuHause> well, you were already told: if you provide an implementation, it might be considered
19:42:47 <Aali> and you just tried to convince me it wasn't worth the effort :P
19:43:15 <Eddi|zuHause> yes, but you don't have to believe me :p
19:43:44 *** Hirundo has joined #openttd
19:44:38 <Aali> on another note, has anyone else noticed how mercurial queues tends to "lose" files randomly?
19:45:52 <Aali> sometimes i have to revert files i haven't touched because they've been deleted or otherwise mutilated by mq :/
20:02:15 <Antdovu> Suppose I have a window and do something useful in OnTimeout(). Where would be a good place to delete the window?
20:06:32 <CIA-5> OpenTTD: glx * r14584 /trunk/configure: -Fix: reconfigure when any *.in file is changed
20:10:47 <glx> be careful when you delete a window
20:13:05 <Antdovu> I already discovered that it will crash in any of the places I tried :P
20:15:50 <CIA-5> OpenTTD: michi_cc * r14585 /trunk/os/win32/installer/install.nsi: -Fix (r14580): File mask for the script directory was wrong in the Win32 install script.
20:18:52 <Antdovu> Is it safe to mark it useless, then mark it dirty and finally delete it in OnPaint()?
20:21:27 <SmatZ> I don't think it is a good idea
20:23:35 <Antdovu> it seems to work but there is likely a better solution
20:24:05 <Vikthor> I wonder, shouldn't be the wagon(or rather road vehicle) length callback called after refit too?
20:24:35 <frosch123> isn't it called when leaving the depot?
20:24:43 <frosch123> SmatZ should know :)
20:29:05 <frosch123> hmm, it seems like the depot-thingie only applies to trains
20:29:11 <Vikthor> doesn't seem to work for me and it doesn't seem so form the code, but then again maybe I am doing something wrong in the grf
20:29:14 *** Schwalbe has joined #openttd
20:29:16 *** Schwalbe is now known as Swallow
20:29:16 *** questionmark has joined #openttd
20:30:00 <SmatZ> Vikthor: for trains, it is called
20:30:07 <SmatZ> for road vehicles, it isn't
20:30:29 <frosch123> RoadVehUpdateCache() would be more appropiate (I guess)
20:30:59 <Vikthor> yeah, that was my second guess
20:32:13 <Vikthor> and another question, when you allowed refitting to zero capacity, would it be possible to allow refiting from zero capacity?
20:32:38 <frosch123> err, it is not allowed?
20:34:28 <frosch123> hmm, I doubt that is correct
20:35:57 <frosch123> but, seems like that was the reason zero was not allowed :)
20:37:06 <Vikthor> maybe it it's correct, but my grf worked with that patch, though I know that's not enough for trunk inclusion
20:37:38 <Antdovu> OK, so nobody actually knows where I should delete the window? :(
20:37:51 <frosch123> I fear there are some interactions between "cargo_cap == 0" and "cargo_type == INVALID_CARGO" :(
20:40:31 <Swallow> @Antdovu do you use DeleteWindowById(...) or something similar?
20:42:49 <Vikthor> hmm, anyway by allowing refiting to 0 and not from 0, we at least behave as TTDPatch 2.6 r 2071
20:42:50 <frosch123> Antdovu: I did not understand your initial problem, but maybe you want to call OnTimeout in the destructor
20:44:16 <Vikthor> Seems like people will have to take care to which cargo they refit, because for some of them they will not be able to refit back :p
20:45:09 <Antdovu> OnTimeout is called by something out of my control
20:46:03 <Antdovu> it gets called when the Save button or enter key is pressed
20:46:25 <Antdovu> like when you try to save the game
20:47:32 <Rubidium> Antdovu: we can keep guessing for possible solutions and even what you are trying to do, but that doesn't help you solving your issue
20:48:32 <Rubidium> for example showing a diff of what you've done so far
20:53:18 <Antdovu> the interesting place in code: "// ALL DONE, now need to get rid of the window"
20:54:34 <glx> Antdovu: why include vector and string everywhere?
20:55:43 <Rubidium> Antdovu: move the ontimeout code to the onclick and most likely it works
20:56:42 <SmatZ> Antdovu: why references when pointers are much better readable?
20:57:56 <frosch123> [21:58] <SmatZ> Antdovu: why references when pointers are much better readable? <- with that attitude you will not get the job of my first job interview either :)
20:57:57 <Rubidium> ontimeout isn't meant for handling user input, but rather to force updates of the window (resorting lists etc)
20:59:17 <SmatZ> frosch123: you failed because of this opinion? the job wasn't at your level then ;-)
20:59:33 <SmatZ> like, level(frosch123) > level(job)
21:00:56 <frosch123> well, the question was quite confusing in the end, as he was heading for const reference vs. stack copy ...
21:05:45 *** Nite_Owl has joined #openttd
21:06:16 <Antdovu> Rubidium: that worked :)
21:07:12 *** mortal`` has joined #openttd
21:08:44 <Antdovu> now I just need to figure out why the main window catches my OnKeyPress()
21:11:37 <glx> Antdovu: probably HandleKeypress doesn't know your window has an input box
21:14:17 <Antdovu> how can I let it know that it does?
21:15:27 <Eddi|zuHause> look at other windows that have an edit box?
21:15:43 <glx> just look at HandleKeypress() source
21:15:59 <glx> it's very easy to see what is needed
21:37:54 <CIA-5> OpenTTD: rubidium * r14586 /trunk/Makefile.bundle.in: -Fix (r14580): missing mkdir causing make install to fail when there's no scripts directory already.
21:51:26 *** lobstar_MB has joined #openttd
21:52:05 *** lobstar has joined #openttd
21:59:01 <Antdovu> randomly generated description?
21:59:20 *** Vikthor has joined #openttd
22:09:12 <Ammler> is that known, if you load a game with enabled magic bulldozer on a server, you can use it?
22:14:10 <mrfrenzy> I read in the forum if you leave the magic bulldozer on the cities will use it to destroy whatever is in the way when building roads - including industries and stations
22:14:40 <frosch123> maybe that is no longer true
22:15:48 <SmatZ> but maybe it is a bug :-P
22:16:01 <Eddi|zuHause> Ammler: if you used the money cheat on a savegame, and then load it in MP, you don't lose the money either
22:16:19 <Rubidium> the town destroying industries with magic bulldozer? That's a feature!
22:16:53 <Ammler> indeed, nice feature :-)
22:17:02 <Eddi|zuHause> i don't see a reason why the cheat should magically turn itself of...
22:17:13 <Eddi|zuHause> except if you can prove it's not MP safe
22:17:24 <frosch123> well, the old feature of removing industries using the terraform tool was removed
22:17:34 <Ammler> the other cheats aren't MP safe?
22:17:45 <frosch123> I don't know whether that also removed the town removing industries feature
22:18:16 <Eddi|zuHause> Ammler: i don't think they have been properly checked for that :p
22:18:36 <Ammler> Always thought, there is an other reason, to not allow those on MP.
22:18:54 <Rubidium> changing player isn't safe
22:18:55 <Eddi|zuHause> you got your causality reversed
22:19:02 <Rubidium> neither is changing climate
22:19:09 <Ammler> Rubidium: dih proved it other
22:19:41 <Rubidium> Ammler: if you change player and do a command you'll get kicked
22:19:56 <Eddi|zuHause> not the cheats are not allowed in MP because they are not safe, they are not safe because they weren't made safe because they're not useable in MP anyway
22:19:59 <Rubidium> i.e. it isn't MP safe
22:20:01 <Ammler> Rubidium: with the cheat.
22:20:22 <Rubidium> well, yes... we're talking about cheats, right?
22:20:50 <Ammler> I am wondering, the map is still there :-)
22:23:50 <Aali> Ammler: i'm looking at the wwottdgd patches right now, what was the mysterious server problem with the 55 clients patch?
22:24:23 <Rubidium> Aali: buffer overruns/overflows
22:24:28 <Ammler> Aali: that problem is fixed on current trunk
22:24:46 <Aali> because i couldn't find it :)
22:25:23 <Ammler> hehe, nice, planetmaker will be happy about help for wwottdgd/3 ;-)
22:26:56 <planetmaker> and also here a good night to all :)
22:27:48 *** stillunknown has joined #openttd
22:28:39 <Aali> i was just looking for the one-tile terraform patch originally, but some of the other stuff you've done caught my eye :)
22:29:59 <planetmaker> mind that most wasn't done by me. I just collected them
22:30:57 <Aali> hmm, i get a 403 on gui+move+mute.diff
22:34:46 <Aali> (i can still get the other file of course, but should that be there?)
22:37:01 <planetmaker> should be changed
22:37:13 <planetmaker> so, now really off. bye :)
22:43:00 <Antdovu> is IniFile::RemoveGroup() supposed to delete group "AA" if it gets "A" as the group it is supposed to delete?
22:45:12 <Antdovu> that is: should IniFile::RemoveGroup("A") delete an existing group named "AA" if there is no group named "A"?
22:49:36 <Antdovu> because that is exactly what it currently does
22:50:16 <Antdovu> it removes the first group with the given prefix, not caring whether they are actually equal
22:52:20 <SmatZ> I would say it may cause buffer overflow
22:53:23 <Antdovu> I would say that it probably breaks newgrf presets
22:55:33 <Aali> i would say that it should check strlen(A) == strlen(B) before comparing anything
22:56:55 <Antdovu> amazing idea: use strcmp(s1, s2) to compare 2 strings
22:58:00 <Aali> i haven't looked at the code, but yes, that might work
22:58:02 <Antdovu> took me ages to find out why my delete button kept deleting the wrong files :(
22:59:14 <Antdovu> well, you have a group "AA" and try to delete "A" then it deletes "AA" unless you also have "AA"
22:59:43 <Antdovu> if (memcmp(group->name, name, len) == 0)
23:00:05 <Aali> clever use of memcmp, there
23:01:17 <Aali> i assume len is assigned from strlen somewhere?
23:02:30 <Aali> so its just like a strcmp, except with 50% more bugs
23:03:23 <Antdovu> made me waste over an hour debugging my code
23:04:34 <Rubidium> it's not even that obscure for a bug
23:05:07 <Rubidium> it only wonders me that it's found now; it's there for eons (r1-ish)
23:07:43 <Patrick> it might be from the Old Code then
23:08:29 *** Yeggstry is now known as Yeggzzz
23:14:48 <dihedral> Rubidium, real r1 or r1 from this repo? :P
23:15:43 <Rubidium> more pre any r1 (0.2.0)
23:18:13 <Antdovu> how often do ancient bugs like that crawl out in openttd?
23:18:36 <Rubidium> less often over time
23:22:11 <Eddi|zuHause> finding of such bugs increases with new features that overcome old limitations, and decrease with old code being rewritten
23:23:05 <Eddi|zuHause> the higher the standards of the new code, the more likely the decreasing part will dominate
23:25:19 <Antdovu> this shows that the newgrf presets patch either wasn't tested that much or the weird behaviour wasn't noticed
23:26:11 <Antdovu> (I am working on something that uses the same method of storage)
23:54:02 <welshdragon> openttd is driving me mad. i've been having connection lost all night on brianetta's server
23:56:50 <Rubidium> that isn't OpenTTD's fault
23:57:14 <Eddi|zuHause> i've been overoccupying the internet :p
23:58:16 <welshdragon> Eddi|zuHause, that'll do me
23:58:16 <Rubidium> okay, OpenTTD requires that your client replies to some requests of the server within 8 seconds
23:59:17 <Rubidium> and if your OS can't maintain a connections that replies within 8 seconds there's something wrong with either your OS or the ISP(s) or your local network
23:59:40 <welshdragon> Rubidium, probably the isop's
23:59:57 <welshdragon> (well, isp here in Hull)
continue to next day ⏵
