IRC logs for #openttd on OFTC at 2007-07-05
⏴ go to previous day
00:07:15 *** lolman_ has joined #openttd
00:25:30 *** ThePizzaKing has joined #openttd
01:04:27 *** lws1984 has joined #openttd
01:04:41 <lws1984> I've got a quick question
01:06:14 <lws1984> With articulated RV's, can you add one vehicle to be latched onto another, like having 2 tramcars as one vehicle?
01:07:52 <Belugas> i don't know... i've not tried ARV
01:08:35 <lws1984> Well, you can't drag it on
01:08:38 <lws1984> you can't ctrl-build it
01:08:44 <lws1984> nor can you ctrl-drag it
01:09:21 <iPandaMojo> There was a patch on the forums allowing that.
01:10:07 <iPandaMojo> And trunk supports callbacks for articulated vehicles currently. There's an articulated tram grf on the forums somewhere that uses it
01:10:26 <iPandaMojo> But most GRFs don't seem to use it yet (no articulated long vehicles :()
01:10:31 <Phazorx> hiroshima trams are properly articulated
01:10:39 <lws1984> Aye, I've got a teaser UK tram set that uses 'em
01:10:44 <iPandaMojo> Ahh, right, that's there name.
01:10:50 <lws1984> but I want to be able to add together two short trams
01:11:38 <iPandaMojo> The screenshot had road vehicle convoys constructed as 1 unit using the patch
01:11:54 <lws1984> Exactly what I'm looking for
01:27:54 <iPandaMojo> The patch was on the page that linked that, which I haven't found >_>
01:31:24 *** Eddi|zuHause2 has joined #openttd
01:32:34 *** Sacro|Laptop has joined #openttd
01:39:43 <lws1984> mmh. that's for TTDPatch, though.
01:46:13 <Belugas> of course... it's the page of steven, one of the ttdpatch devs :)
01:55:37 *** Digitalfox has joined #openttd
02:20:35 *** setrodox has joined #openttd
02:27:47 *** Nukebuster has left #openttd
02:53:05 *** strstrep has joined #openttd
02:54:52 *** ThePizzaKing has joined #openttd
03:11:54 *** iPandaMojo has joined #openttd
03:31:16 *** Noldo_ is now known as Nolfo
04:09:10 *** Nolfo is now known as Noldo
04:33:51 *** Frostregen_ has joined #openttd
04:39:31 *** Frostregen_ is now known as Frostregen
05:03:36 *** Thomas[NL] has joined #openttd
05:15:45 *** Osai^zZz has joined #openttd
05:18:47 *** Osai^zZz is now known as Osai
06:38:56 *** Maedhros has joined #openttd
07:06:25 <CIA-1> OpenTTD: rubidium * r10442 /trunk/src/ (7 files): -Codechange: implement the industry production callback.
07:06:25 <CIA-1> OpenTTD: peter1138 * r10443 /trunk/src/ (newgrf_callbacks.h newgrf_engine.cpp): -Fix: randomizing triggers should be called with callback type set to 1
07:07:35 *** |kami|Death has joined #openttd
07:14:15 *** mikegrb has joined #openttd
07:18:17 *** XeryusTC has joined #openttd
07:34:25 *** Tlustoch has joined #openttd
07:43:41 *** setrodox has joined #openttd
08:33:36 *** tokai|ni has joined #openttd
08:44:44 *** dihedral has joined #openttd
08:45:05 <dihedral> orudge: whats up with tt-forums web server?
08:47:03 <hylje> i believe he's hinting at some funnies regarding it
08:47:59 <dihedral> getting a timeout for nearly every to every second request
08:48:16 <peter1138> no problems from here
09:56:22 *** Tlustoch has joined #openttd
09:58:15 *** Nickman has joined #openttd
10:28:03 *** raimar3 has joined #openttd
10:45:04 *** Vikthor has joined #openttd
10:50:00 *** MarkSlap has joined #openttd
10:54:08 *** Markkisen has joined #openttd
11:13:24 <stillunknown> Is it possible to convert a Vehicle pointer into a subclass pointer?
11:14:31 <Maedhros> v = new Subclass(v) ?
11:15:26 <stillunknown> That's actually useable after creation?
11:16:00 <Noldo> stillunknown: what exactly did you have in mind
11:16:05 <Noldo> what do you need it for?
11:16:45 <stillunknown> If you have functions that are specific for a type of vehicle, you either need to make them static or have empty virtual functions for the base vehicle class.
11:17:03 <stillunknown> The last is a bad idea if the other vehicles don't use the function.
11:17:20 <Noldo> what do you need it for?
11:18:31 <stillunknown> I'd like to make a few Train specific functions non-static, to do that the object must of type Train and not Vehicle.
11:18:48 <Noldo> what kind of functions?
11:18:56 <peter1138> Train *t = (Train*)v; ... heh
11:19:11 <Noldo> where are they called from?
11:19:24 <stillunknown> From functions inside the Train class.
11:19:42 <Noldo> that shouldn't be a problem
11:19:56 <Noldo> this will be correctly typed anyway
11:20:05 <stillunknown> It is, since "this" is a Vehicle object.
11:20:49 <Noldo> but that doesn't matter as long as it's a train
11:20:53 <stillunknown> So at compile time you get complains about lacking a function for all other vehicle types.
11:21:56 <Noldo> you don't have to put the function in to vehicle interface at all if they are only called for trains
11:23:22 <Noldo> but if you have a loop of all vehicles where you want to call some vehicletype specific functions then you need something else
11:24:01 <peter1138> stillunknown: private function, no?
11:24:07 <stillunknown> It did work this time.
11:24:29 <stillunknown> This was a private function.
11:26:26 <stillunknown> Most functions should be private.
11:31:58 <stillunknown> My optimizing session is coming to an end, i used existing acceleration code since it was easier to optimize, but i'm still waiting on the authors ok.
11:38:43 *** Vikthor has joined #openttd
11:47:35 <stillunknown> Is there any common opinion about the usage of other people's patches in your own (with credit)?
12:24:17 <CIA-1> OpenTTD: peter1138 * r10444 /trunk/ (48 files in 7 dirs): -Codechange: switch to c++ classes and inheritance for sound/music/video drivers, using self-registration based on the blitter-model.
12:30:35 <CIA-1> OpenTTD: KUDr * r10445 /trunk/src/win32.cpp: -Fix (Win32, r10444): remove #include "hal.h"
12:32:22 <KUDr> and next week back to work
12:41:22 *** Progman has joined #openttd
12:49:15 <KUDr> hal is hidden advertisement fo IBM
12:50:10 <KUDr> 'I' - 1 = 'H', 'B' - 1 = 'A', 'M' - 1 = 'L'
12:50:54 <KUDr> peter1138: don't try to convince us about "Hardware Abstraction Layer' or so
12:51:38 <peter1138> KUDr: i meant it's not *for* anything, as it no longer exists :)
12:52:23 <KUDr> IBM announced bankrubcy so we removed their advertisemens :)
12:55:53 <peter1138> yeah, we charged too much for them
12:55:56 <peter1138> and brought them down
12:59:24 *** MarkSlap has joined #openttd
13:00:51 <Phazorx> question, server keeps complaining about "slow client" and suggest increasing *net*freq
13:01:06 <Phazorx> what exactly is that and how to deal with it?
13:13:42 *** NukeBuster has joined #openttd
13:19:53 <CIA-1> OpenTTD: peter1138 * r10446 /trunk/src/music/ (extmidi.cpp extmidi.h): -Codechange: Move extmidi's global data into its class.
13:25:39 <peter1138> it tells you what tod o
13:25:59 *** Chicago_R_A has joined #openttd
13:28:41 *** Nickman is now known as Nickman^Away
13:29:42 *** Sacro|Laptop has joined #openttd
13:31:04 <Phazorx> peter1138: i dont see that thing as patch option and have no idea about values
13:36:40 <peter1138> not all options are patch options...
13:42:15 * peter1138 ponders that signal gui
13:44:57 <Phazorx> so is there some kind of guidance i can get on what and how neets to be set with that particular param?
13:45:18 <peter1138> check the current value, and then increase it
13:45:32 <Noldo> peter1138: just tell him where he can do that
13:46:33 *** NukeBuster has joined #openttd
13:49:03 *** valhalla1w is now known as valhallasw
13:50:54 <Tlustoch> Is it possible to use more engines in one train?
13:51:16 <Chicago_R_A> In the build window, build 2 engines and then drag one of them up to the line of the first engine
13:53:07 <Tlustoch> How's the speed increased?
13:59:00 <Phazorx> patch *net_frame_freq
13:59:00 <Phazorx> '*net_frame_freq' is an unknown patch setting.
13:59:07 <Phazorx> 'net_frame_freq' is an unknown patch setting.
14:00:33 <glx> 'net_frame_freq' to display the current value, 'net_frame_freq = value' to change it
14:00:42 *** iPandaMojo has joined #openttd
14:06:51 *** NukeBuster has left #openttd
14:19:23 <stillunknown> Can anyone tell me why trains can go full speed when only the first engine has left the bridge?
14:20:37 <Noldo> it propably just checks that
14:21:07 <stillunknown> But is there a good reason for it?
14:22:23 <peter1138> well it's quicker ;)
14:23:44 <stillunknown> In terms of train speed or code speed?
14:28:31 *** Sacro|Laptop has joined #openttd
14:36:38 *** Progman has joined #openttd
14:49:48 *** Sacro|Laptop has joined #openttd
14:50:45 <stillunknown> Why won't a Vehicle* be changed to a Train* outside the Train class?
14:51:41 <stillunknown> I can't cast it or use the new operator.
14:51:57 <Noldo> what would you like to do?
14:52:35 <stillunknown> I have a function outside the Train class, which only works on trains.
14:52:51 <stillunknown> I removed a useless virtual function from the Vehicle class and now it complains.
14:53:06 <stillunknown> And it won't let me convert the vehicle pointer to a train pointer.
14:53:47 *** lolman_ has joined #openttd
14:53:55 <Noldo> the vehicle pointer only promices that the object that it points to is a vehicle
14:54:20 <stillunknown> I did the same inside the train class, maybe there it's considered safe.
14:54:26 <Noldo> if you convert vehicle pointer to train pointer it's like saying that all vehicles are trains
14:54:57 <iPandaMojo> stillunknown: Erm, no, implicit conversion of Vehicle* to Train* isn't safe inside Train's scope either.
14:55:17 <stillunknown> It's an explicit conversion.
14:55:19 <iPandaMojo> At least, assuming it isn't safe outside of Train's scope.
14:55:34 <stillunknown> v = new (v) Train();
14:55:45 <iPandaMojo> That's not a conversion.
14:55:48 <iPandaMojo> That's a placement new.
14:56:06 <iPandaMojo> And a broken one with that wonky syntax it looks like.
14:56:24 <iPandaMojo> (the v=... part is redundant)
14:56:32 <iPandaMojo> (probably legal/defined behavior, but redundant)
14:56:45 <iPandaMojo> You probably want:
14:57:02 <stillunknown> Nor does openttd.
14:57:11 <iPandaMojo> If v is a Vehicle*, it's worth noting that this is converting Train to Vehicle, not vicea versa.
14:57:20 <stillunknown> On creation time you create a vehicle, then you convert it into whatever you'd like.
14:57:40 <stillunknown> * This class 'wraps' Vehicle; you do not actually instantiate this class.
14:57:40 <stillunknown> * You create a Vehicle using AllocateVehicle, so it is added to the pool
14:57:40 <stillunknown> * and you reinitialize that to a Train using:
14:57:40 <stillunknown> * v = new (v) Train();
14:57:42 <Noldo> that's not how it works
14:58:10 <peter1138> strange crazy magic, perhaps
14:58:38 <iPandaMojo> v= new (v) T(); is black magic >_>
14:59:26 <iPandaMojo> Right. That's an explicit cast.
14:59:40 <iPandaMojo> v = new (v) T(); definately does not involve any explicit casts, I can assert that much.
14:59:42 <Noldo> now you are saying that all vehicles are trains
14:59:53 <iPandaMojo> Well, he's saying that u is a train.
14:59:57 <stillunknown> But i don't see why: Train *something = (Train *)u; doesn't work
14:59:59 <iPandaMojo> Which isn't true for the general case.
15:00:11 <iPandaMojo> Hence the need for an explicit cast if he's figuring this out programmatically.
15:00:19 <iPandaMojo> (To avoid doing this by accident)
15:00:29 <stillunknown> It's in the function AdvanceWagons which is only used for trains.
15:01:24 <iPandaMojo> Train *something = (Train*)u; should work if u is any pointer type.
15:01:24 <ln-> iPandaMojo: "definately" is spelled "definitely"
15:01:42 <iPandaMojo> Gah, thank you for the correction.
15:01:44 <stillunknown> I have that problem too.
15:02:44 <peter1138> yeah, Train *foo = (Train *)bar; should work
15:02:59 <Noldo> but it is somewhat dangerous
15:03:04 <peter1138> possibly assert(bar->type == VEH_TRAIN); just before :)
15:04:02 <Noldo> I'm sure even dynamic_cast can be avoided with proper planning
15:04:14 <Noldo> btw how do memory pools work?
15:04:46 <iPandaMojo> dynamic_cast is just the C++ RTTI version of foo->type checks
15:05:09 <iPandaMojo> (Well, at least where each type == a different class)
15:10:31 <Noldo> but c++ has it's normal way of creating objects and varying from that doesn't sound like a very good idea
15:11:48 <caladan> cause it is more memory efficient
15:16:01 <Eddi|zuHause2> but he's not creating an object
15:16:09 <Eddi|zuHause2> he's just typecasting
15:16:29 <iPandaMojo> I can say this much for certain: new has no place in "casting".
15:16:38 <Eddi|zuHause2> or "inverse polymorphic access"
15:16:41 <iPandaMojo> Only construction, which is quite different.
15:17:00 <iPandaMojo> If you're using memory pools, hide that shit from user code.
15:17:22 <iPandaMojo> The only use of placement new should be inside containers and memory allocators (pools included), really.
15:17:46 <Eddi|zuHause2> yes, how about calling the function with a Train* in the first place?
15:18:03 <caladan> and everywhere else should be calls to memory pools
15:18:04 <iPandaMojo> (Well, there may be an exception or two, but whatever-the-hell he's trying to do certainly isn't one of those exceptions)
15:18:52 <Noldo> I wonder what is the big change stillunknown is going for
15:19:40 * iPandaMojo is too lazy to play 20 questions to figure it out
15:20:26 <Eddi|zuHause2> maybe he should show a typical hand movement of the job :)
15:20:34 <Noldo> also I'm a bit sceptical about archieving memory efficency with custom allocators
15:20:44 <stillunknown> Some of it is bringing more stuff into their respective vehicle classes, most of it is a considerable redesign of the train controller.
15:21:04 <stillunknown> I'm just cleaning things up, like unused virtual functions.
15:21:16 <stillunknown> And no, i'm not using new anywere.
15:21:36 <iPandaMojo> The best memory efficiency is only going to come about with placement hints, but if you're not doing that, custom allocators can be pushed to just about the limit of the envelope
15:21:56 <iPandaMojo> (then what was the point of that line you pasted earlier w/ new in it?)
15:23:04 <stillunknown> I tried something (explicit casting didn't work the first time), i happened to read that and i saw what the new does.
15:23:11 <iPandaMojo> Oh yes: And, technically, the SC++L allocator interface actually allows for a hint to be passed to said allocator.
15:23:25 <iPandaMojo> Not all the containers end up using them but...
15:24:36 <stillunknown> My experience in C++ is limited, as it's just a hobby.
15:25:24 <iPandaMojo> I know too much C++ for my own good.
15:25:38 <stillunknown> So C++ for me is like: C+classes+more overloadable operators+stdlib
15:25:52 <stillunknown> And a few other things i can't think of right now.
15:26:19 <Noldo> stillunknown: are Vehicles and Trains still separate classes in your code, I mean is one inherited from the other?
15:26:25 <iPandaMojo> *overloading in the first place, custom operator implementation in the first place
15:26:49 <stillunknown> Noldo: Yes, they still inherit eachother.
15:26:50 <Eddi|zuHause2> stillunknown: templates :)
15:26:53 <stillunknown> The basic structure remains unchanged.
15:27:22 <Noldo> stillunknown: is it based on trunk or something else?
15:27:57 <stillunknown> My main goal was optimizing trains, i did that, obviously i want it merged at some point.
15:28:06 <iPandaMojo> Template + Macro Metaprogramming with File iteration!
15:28:36 <iPandaMojo> O(N^2) template specializations!
15:29:38 <iPandaMojo> SFINAE, Koeing Lookup, and dependant templates!
15:29:52 <stillunknown> But soon i will have to ask someone how i'm going to get a 120 KiB patch merged :-(
15:30:08 <Eddi|zuHause2> split it in 120 1kB patches :)
15:30:09 <stillunknown> Because much seperation is impossible.
15:30:27 <Eddi|zuHause2> each line separately :p
15:30:43 <stillunknown> Maybe one or two splits, but a lot of the code is interdependent.
15:31:15 <iPandaMojo> I'm half tempted to start trying to get OTTD unit tested
15:31:22 <Eddi|zuHause2> it's probably easier if the devs could follow the development path
15:31:48 <Eddi|zuHause2> iPandaMojo: i think YAPF had a unittest
15:32:16 <stillunknown> Eddi: the development path is pretty much done, and some of the intermediate stages are embarrassing.
15:32:34 <iPandaMojo> panda:~/openttd-trunk-head $ fgrep "Unit Test" * */* */*/*
15:32:34 <iPandaMojo> panda:~/openttd-trunk-head $
15:32:44 <Maedhros> iPandaMojo: i think you'd probably go insane before you managed it, but it would be cool if possible ;)
15:33:00 <Eddi|zuHause2> iPandaMojo: look in the old yapf branch... i think it got removed later
15:33:03 <iPandaMojo> Maedhros: To go insane, one needs to have been sane in the first place.
15:33:12 <iPandaMojo> Removed unit tests? :(
15:33:15 <Maedhros> well, there is that :)
15:33:17 <Noldo> what are those VehicleRoad etc structs in vehicle.h
15:33:35 <Eddi|zuHause2> iPandaMojo: a unittest is not of much use after the product is finished
15:33:54 <stillunknown> Noldo: They are unions of the Vehicle struct.
15:34:16 <Noldo> ok, yes now there it is
15:34:24 <Eddi|zuHause2> iPandaMojo: and the bugs that actually occured later (mostly multiplayer desyncs) you could never have caught with a unittest
15:34:35 <Noldo> is that the stuff you would like to move to the subclasses?
15:35:11 <iPandaMojo> I haven't worked on OTTD that much, but I've encountered bugs that WOULD have been caught by unit tests just fine.
15:35:29 <iPandaMojo> No, you can't catch everything.
15:35:48 <iPandaMojo> But that doesn't mean you can't catch anything that's worthwhile to catch.
15:36:23 <stillunknown> But is it worth the effort?
15:36:28 <Eddi|zuHause2> but after yapf was finished and merged, there was no use for it anymore
15:36:33 <Noldo> oh my, so someone already overloaded new for vehicles
15:36:46 <Eddi|zuHause2> because there were hardly any further changes
15:36:57 <iPandaMojo> What, could none of the tests be reused for any other pathfinder that might be implemented in the future?
15:37:11 <iPandaMojo> Or better yet, to ensure you don't break shit when upgrading the internals to handle, say, PBS?
15:37:14 <Eddi|zuHause2> iPandaMojo: the file is still in SVN
15:37:27 <Eddi|zuHause2> just it's no use in trunk, that's why it got removed
15:38:49 <iPandaMojo> Mmm. See, I'm lazy, so I just leave my tests in so I don't have to go hunting through my SVN history to find whatever tests I might want to use again.
15:39:08 <iPandaMojo> Which, not being in trunk, aren't mantained and thus have probably been broken, both in terms of not compiling AND not running.
15:39:35 <Eddi|zuHause2> !openttd log 6410
15:39:37 <_42_> Eddi|zuHause2: r6410 log: -remove unittest
15:40:10 <Eddi|zuHause2> why that useless highlight in there?
15:40:17 <Noldo> And bacause the new is overloaded the syntax demonstratted earlier is actually valid
15:40:19 <Eddi|zuHause2> !openttd commit 6410
15:40:22 <_42_> Commit by glx :: r6410 /trunk/Makefile (2006-09-06 13:58:31 UTC)
15:40:38 <Noldo> who on earth wrote this stuff??
15:41:37 <Eddi|zuHause2> iPandaMojo: exactly, it's just useless maintenance work to keep it around
15:42:20 <Eddi|zuHause2> (under the assumption that the product is finished and hardly any future changes are to be expected)
15:42:23 <iPandaMojo> Extremely easy mantinence (when it's broken, not when it's been been broken for 1000s of revs) with future worth in a long lived project.
15:43:45 *** Brianetta has joined #openttd
15:43:51 <iPandaMojo> I guess I'm just under the differing impression that more than "hardly any" future changes are to be expected.
15:44:00 *** Nickman^Away is now known as Nickman
15:45:38 <Eddi|zuHause2> iPandaMojo: not in YAPF
15:46:14 <Eddi|zuHause2> YAPF was almost unchanged for a year
15:46:20 *** Digitalfox has joined #openttd
15:46:48 <iPandaMojo> Not much work on PBS right now.
15:47:09 <Eddi|zuHause2> yapf should not be changed (much) for a new PBS
15:47:25 <iPandaMojo> If guaranteed greens ever get worked on, I'd be suprised if that didn't require pathfinder modifications too.
15:47:32 <Eddi|zuHause2> besides, it was already planned with a new PBS implementation in mind
15:48:14 <Eddi|zuHause2> it doesn't need much change, just penalties for red/green signals handled differently
15:50:24 <iPandaMojo> Well, your project.
15:50:29 <iPandaMojo> (or at least not mine)
15:51:28 <Noldo> hylje: it tells who is responsible for each line of code
15:53:01 <Eddi|zuHause2> it's actually just an alias for "svn blame" :p
15:53:30 <Eddi|zuHause2> for people whose glass is half full ;)
15:54:23 <hylje> my glass is twice as large as necessary
15:54:24 <Noldo> yes I used blame, but thought it would be nicer this way
15:54:57 <Noldo> and it's conseptually impossible to determine which is alias for which
15:55:23 <Eddi|zuHause2> ~/spiele/OpenTTD> svn help praise
15:55:23 <Eddi|zuHause2> blame (praise, annotate, ann): Gibt den Inhalt der angegebenen Dateien oder URLs mit
15:55:23 <Eddi|zuHause2> den Revisons- und Autoreninformationen für jede Zeile aus.
15:55:40 <Eddi|zuHause2> it clearly states a "favourite" :)
15:55:53 <iPandaMojo> That could just be based on alphabetical ordering.
15:56:13 <iPandaMojo> Of course, this totally ignores inside the parenthesis, but that's besides the point.... ;-)
15:56:17 <Eddi|zuHause2> yes, because "annotate" comes after "praise" in your alphabet?
15:56:25 <iPandaMojo> Also it comes after blame.
15:59:32 <iPandaMojo> You see, the leading A is accented in... some language... causing the corresponding extended ASCII character to trail "blame" and "praise" in... some encoding :D
16:00:11 <iPandaMojo> Time to move out and stuff. Later.
16:00:26 <Eddi|zuHause2> in german, "ä" ist supposed to be treated like "a" in lexicographic ordering
16:18:34 *** BobingAbout has joined #openttd
16:18:51 *** BobingAbout has left #openttd
16:23:27 <dihedral> Eddi|zuHause2: i always wonderd about that...
16:27:13 <CIA-1> OpenTTD: belugas * r10447 /trunk/src/industry.h: -Codechange: Don't need to specify values on an enum when those values are contiguous
16:39:32 *** Prof_Frink has joined #openttd
16:40:09 <CIA-1> OpenTTD: belugas * r10448 /trunk/src/newgrf.cpp: -Codechange: Industry Tiles and Houses share almost the same spritegroup format.
16:40:25 *** Chris82 has joined #openttd
16:40:32 <CIA-1> OpenTTD: miham * r10449 /trunk/src/lang/ (catalan.txt french.txt russian.txt):
16:40:32 <CIA-1> OpenTTD: -Update: WebTranslator2 update to 2007-07-05 18:40:00
16:40:32 <CIA-1> OpenTTD: catalan - 1 changed by arnaullv (1)
16:40:32 <CIA-1> OpenTTD: french - 4 changed by glx (4)
16:40:33 <CIA-1> OpenTTD: russian - 2 fixed by Smoky555 (2)
16:40:53 <Chris82> I am just looking at the code of Advanced Town Handling
16:41:00 <Chris82> and I was wondering what "distance = DistanceManhattan(tile,t->xy);" means
16:41:13 <Chris82> it's supposed to calculate the distance from the town center, but what is this DistanceManhatten
16:41:18 <Chris82> the patch doesn't define it
16:42:01 <Chris82> hmmm is it still? because I can't find this anywhere
16:42:41 <Chris82> ahhhh my mistake was I wrote Manahtten
16:43:27 <stillunknown> Does adding a patch option require a savegame change?
16:44:09 <Eddi|zuHause2> Chris82: "manhattan distance" == "only use streets and avenues, do not go diagonal"
16:44:10 <Maedhros> if it needs to be synced across network games, yes
16:44:55 <Noldo> mathemathically |x1-x2| + |y1-y2|
16:45:43 <Eddi|zuHause2> it has the advantage of not needing (floating point, or rounded) square roots, like the euclidean distance
16:46:27 <Chris82> ah ok thanks :) then I know how it measures distance now
16:46:34 <Maedhros> and the disadvantage that you can make far more money with a mostly diagonal railway :)
16:48:22 <Chris82> hmmm interesting point :D
16:48:29 <Chris82> ok I have one compiler error saying:
16:48:31 <Chris82> ..\src\clear_cmd.cpp(464) : error C2676: binary '*' : 'CommandCost' does not define this operator or a conversion to a type acceptable to the predefined operator
16:48:39 <Chris82> towncost = (cost * population / 300 * (30 * 1000 / (distance + 15)) / 1000);
16:48:57 <Eddi|zuHause2> probably an old patch
16:49:03 <Chris82> how do I need to change this so it works with CommandCost instead of int32 ?
16:49:16 <Chris82> yeah but I haven't quite gotten how this CommandCost stuff works yet
16:49:52 *** Darkebie has joined #openttd
16:51:14 <Eddi|zuHause2> Chris82: "CommandCost" is a class, and has a member "cost"
16:52:01 <Eddi|zuHause2> (pherhaps "CommandResult" would have been a better name)
16:52:52 <Chris82> hmmm ok well I understand what I can do with cost.AddCost and cost.GetCost
16:52:53 <Eddi|zuHause2> try the GetCost() accessor function
16:53:12 <Chris82> what I don't know is how to calculate anything like x * y + z and make that the costs
16:53:52 <Chris82> oh cost.GetCost() instead of cost indeed compiles, I forgot the () :D
16:53:55 <Eddi|zuHause2> new CommandCost(money)?
16:53:58 <Chris82> let's see if the code works
16:55:06 <Eddi|zuHause2> yeah, the () is one of the stupid things about C-syntax
16:55:58 <Eddi|zuHause2> "function" evaluates to the pointer to the function, while "function()" actually calls the function
16:56:35 <Eddi|zuHause2> but it is so rarely that you want the function pointer, they should have made a different syntax for that one
16:57:50 <Maedhros> Eddi|zuHause2: you don't want to use new, as it'll never be deleted
16:58:04 <hylje> function to refer and function() to call is pretty standard
16:58:42 <Eddi|zuHause2> hylje: it is totally useless, and cause of a lot of unnecessary errors
16:59:12 <Eddi|zuHause2> and just because everyone is trying to copy C does not mean it is actually good
16:59:25 <hylje> how would you refer to a function then?
16:59:32 <Chris82> hmmmm well my code compiled but it's not doing what I want :D
16:59:49 <Eddi|zuHause2> by a special construct?
17:00:03 <Chris82> if (_patches.town_construction_cost) {
17:00:10 <Eddi|zuHause2> i don't know exactly how they did it in pascal
17:00:16 <Chris82> does this work to check if I shall do something when the patch is enabled?
17:00:21 <Chris82> or do I need more in the brackets?
17:00:38 <Eddi|zuHause2> but they had function pointers as well, but "function" was an abbreviation for "function()"
17:00:46 <hylje> self._callback = function
17:00:53 <Maedhros> Chris82: if town_construction_cost is a bool, that's fine
17:01:04 <Chris82> hmmm ok then something else is wrong
17:01:09 <Maedhros> using == true works, but is redundant :)
17:01:42 <Chris82> can I use cost.AddCost multiple times to add several values before I return the cost?
17:01:47 <Chris82> like cost.AddCost(towncost);
17:01:54 <Chris82> and then return cost.AddCost(_price.purchase_land * 10);
17:01:59 *** Nukebuster has joined #openttd
17:02:19 <Maedhros> you should be able to AddCost more than once, but i'd be wary of returning it
17:02:26 <Maedhros> just return cost; at the end
17:02:38 <Chris82> well that return line is from trunk, I didn't change it
17:02:52 <Eddi|zuHause2> Maedhros: how and where are CommandCosts created and destroyed then?
17:02:57 <Chris82> it's from the CommandCost to buy land
17:03:20 <Chris82> in clear_cmd.cpp but if it's bad coding style I can AddCost before and just return cost; at the end
17:04:06 <Chris82> this might have been overlooked actually, when I look in other places in source AddCost is always done before the return
17:04:35 <Eddi|zuHause2> "return x.y();" should work fine
17:04:51 <Maedhros> Eddi|zuHause2: you can return entire structs, you don't need pointers to them
17:04:53 <Eddi|zuHause2> even "return x.y().y().y();"
17:05:23 <Maedhros> Chris82: it's not bad style, but i wasn't sure that AddCost wasn't a void function
17:05:29 *** |Jeroen| has joined #openttd
17:05:41 *** Ammller has joined #openttd
17:05:49 <Chris82> hmmm well I still have to figure out why my code isn't working, I hate it when the reason is not a compiler error :D
17:09:00 <dihedral> it's pretty silly of me to rsync my server to a replacement machine... forgetting to exclude the various ottd checkouts
17:10:00 <Chris82> I am just writing a new Advanced Town Handling patch
17:10:33 <dihedral> %does_not_work_either
17:10:51 <dihedral> @let_me_try_this_one
17:13:47 <peter1138> did my autosignals cause much problem?
17:14:13 <Chris82> oh I haven't checked their compatibility with Signal GUI yet, that's why I didn't put it in the IN yet
17:14:19 <Chris82> it's working fine with trunk code :)
17:14:22 *** skidd13 has joined #openttd
17:14:54 <Chris82> I am just working on two other patches that's why I didn't look at it yesterday
17:28:17 <Chris82> towncost = (cost.GetCost() * population / 300 * (30 * 1000 / (distance + 15)) / 1000);
17:28:27 <Chris82> is it possible that the result for towncost is always the same?
17:28:44 <Chris82> because it seems like it, no matter how far away from a city/town I build it always costs the same
17:28:51 <Chris82> but I see that something is added to the standard price
17:33:02 <Eddi|zuHause2> maybe wrong order of evaluation?
17:34:04 <Eddi|zuHause2> e.g. a/b*100 is something different than (a*100)/b
17:35:25 <Chris82> maybe somebody wants to do a look here :)
17:36:22 <Eddi|zuHause2> this site totally cannot handle large font sizes---
17:37:34 <Eddi|zuHause2> did you check that the if() part is actually reached?
17:37:48 <Eddi|zuHause2> try a few debug() or printf()
17:38:06 <Chris82> well the if part must be reached because it adds costs
17:38:09 <Chris82> but always the same amount
17:40:08 <Eddi|zuHause2> towncost should be int rather than CommandCost
17:41:11 <Eddi|zuHause2> and probably all those variables should be local to the if-block
17:41:43 <Eddi|zuHause2> or removed alltogether
17:41:46 <Chris82> hmmm well the variables are detected otherwise I'd get a compiler error
17:41:50 <Chris82> but I'll try making towncost Money
17:42:00 <Chris82> you can't make it int because that's not compatible with the CommandCost class
17:42:16 <Chris82> no not removed, population and distance is not defined elsewhere
17:43:08 <Darkebie> When you build a railstation near 2 industries, does it suffice to cover only 1 square of both industries to load/unload for them?
17:43:28 <Eddi|zuHause2> i mean nest them into the calculation, without temporary variables
17:43:42 <Chris82> 2>..\src\clear_cmd.cpp(447) : error C2440: '=' : cannot convert from 'CommandCost' to 'Money' :/
17:45:49 <Chris82> I just tried to make the formular really simple (cost * population) / 300 and see if another value is added then
17:45:53 <Eddi|zuHause2> which line is that?
17:46:40 <Chris82> interesting I have to pay the same value
17:47:08 <Chris82> so it doesn't add the towncost value but something else
17:48:11 <glx> Chris82: you probably need GetCost() in this line
17:48:13 <dihedral> on my way home... cu laters :-)
17:48:18 <Eddi|zuHause2> you definitely do something wrong
17:50:39 <Chris82> towncost = (cost.GetCost() * (t->population) / 300 * (30 * 1000 / (distance + 15)) / 1000);
17:52:04 <Eddi|zuHause2> okay... easy things... replace that whole line with towncost=distance
17:52:08 <Maedhros> ah! cost isn't actually used anywhere, is it?
17:52:21 <Maedhros> in which case you're multiplying the whole line by 0...
17:52:41 <Chris82> hmmm but there is something added with the changes I've done
17:52:47 <Chris82> so that can't be the problem I guess
17:53:37 <Chris82> ah bugger they close the computer rooms in 7 mins :D
17:54:03 <Eddi|zuHause2> towncost = DoCommand(tile, 0, 0, flags, CMD_LANDSCAPE_CLEAR); <- replace that by "cost"
17:54:39 *** Ammller is now known as Ammler
17:54:41 <Eddi|zuHause2> since towncost is no longer a cost
17:54:49 <Eddi|zuHause2> a CommandCost i mean
17:56:04 <Eddi|zuHause2> this piece of code is totally inconsistent...
17:57:56 <Chris82> hmmm ok I'll look at it when I am at home gotta hurry now or my bus leaves :D
18:04:38 <Maedhros> i'm not entirely sure that the advanced town handling patch should be touching CmdPurchaseLandArea at all, tbg
18:05:54 <Eddi|zuHause2> yeah, it should rather be modifying clearing land
18:06:02 <peter1138> what does "advanced town handling" mean, anyway?
18:06:25 <Eddi|zuHause2> if i read it correctly, tiles close to the town center should get more expensive
18:08:34 <Eddi|zuHause2> this piece of code is totally ugly... i would throw it away
18:19:08 *** Brianetta has joined #openttd
18:22:15 <CIA-1> OpenTTD: peter1138 * r10450 /trunk/src/video/cocoa_v.mm: -Fix (r10444): Fix search & replace errors
18:29:13 <Sacro|Laptop> anyone here good with C++
18:29:26 <Noldo> Sacro|Laptop: about what?
18:29:44 <peter1138> i hope no osx user wants to play tonight ;)
18:30:06 <Sacro|Laptop> Noldo: inheritence... virtual functions
18:31:04 <Sacro|Laptop> mmm, i'm trying to work out how to get things into scope
18:31:27 <peter1138> class fred { public: virtual void sheila() = 0; }; class jim : public fred { void sheila() { ... } };
18:32:24 <Sacro|Laptop> peter1138: how useful
18:32:43 <Sacro|Laptop> and the ..., is that so i can pass %i ?
18:32:53 <Noldo> Sacro|Laptop: into scope?
18:33:10 <Sacro|Laptop> Noldo: yes, i'd changed the class name, but not updated the relevent othery bits
18:34:17 <Noldo> won't the compiler help if you try to compile it?
18:41:43 <Sacro|Laptop> sdl is confusing me
18:42:10 <Noldo> well, that's not my area of expertice
18:42:24 <peter1138> just steal it all from ottd
18:43:19 <Sacro|Laptop> peter1138: yes...
18:45:42 <Sacro|Laptop> hmm, what is SDL_CALL
18:47:34 <Belugas> 5 letters and an underscore
18:48:28 <glx> and for most platforms it is empty
18:49:14 <Belugas> why count for duplicates?
18:50:34 <peter1138> down the back of the sofa
18:51:30 <Belugas> yeah... we spent a lot of time on that sofa you and me!
18:52:16 <peter1138> +SDT_CONDBOOL(Patches, enable_signal_gui, 70, SL_MAX_VERSION, 0, 0, false, STR_CONFIG_PATCHES_ENABLE_SIGNAL_GUI, NULL),
18:52:29 <peter1138> i somehow don't think that setting needs saving...
18:52:31 *** scrooge has joined #openttd
18:54:48 <Sacro|Laptop> would i be right in assoming that x = 0 will compile to x AND 0
18:59:29 <Eddi|zuHause2> why have a patch option for that anyway?!?
19:00:11 <Eddi|zuHause2> it should just open a new window, the default behaviour should not change...
19:05:11 <peter1138> if you don't want that window...
19:07:22 *** MarkSlap has joined #openttd
19:18:14 <Smoovious> I wouldn't always want that window
19:18:33 <Smoovious> and for that matter, I'd want the setting saved to the settings file. :P
19:19:12 <Eddi|zuHause2> well, even then, settings file != savegame
19:20:29 <Eddi|zuHause2> but still, why makea
19:20:36 <Eddi|zuHause2> a difference for this window?
19:20:51 <Eddi|zuHause2> there is no option to show the depot window, or station window
19:21:51 <Smoovious> because for those, you have to make a choice... for signals, we already are used to the keyboard shortcuts for most of our building, and a window would get in the way of speedy signal placement
19:22:11 <Smoovious> just one more thing to click that you d on't have to
19:22:23 <Eddi|zuHause2> you don't have to click on the window
19:22:34 <Eddi|zuHause2> the current shortcuts stay the same
19:23:09 *** Nickman is now known as Nickman^Away
19:23:37 <Smoovious> is there something wrong with being able to customize your interface to your liking tho?
19:24:00 <Smoovious> perhaps have the GUI as a pulldown option of the signal button, defaultitng to no GUI
19:24:53 <Smoovious> and just clicking th e button, will use thhe l ast known selection, just like track-type
19:25:13 <Smoovious> then no patch menu option is necessary
19:39:15 <stillunknown> Signal building is fine the way it is.
19:40:57 *** MarkSlap has joined #openttd
19:45:04 <Eddi|zuHause2> i actually like the signal gui
19:45:57 <Eddi|zuHause2> and it is probably newbie friendly
19:46:20 <Darkebie> im new and after reading the manual i havent had a prob with it
19:46:48 <Eddi|zuHause2> see... how many people do you know that actually read the manual?
19:47:24 <Smoovious> if people don't read the manual, it is their own fault
19:48:30 <Eddi|zuHause2> no, programs should be very self explaining
19:49:13 <Darkebie> depends on what program
19:49:41 <stillunknown> It's a shortterm vs longterm efficiency question.
19:49:44 <Smoovious> if that's the goal, then a tooltip wiith the instructions of how to use signals would be plenty
19:49:48 <stillunknown> I prefer the latter.
19:50:19 <Smoovious> personally, I find programs that insist on treating me like a clueless noob full time, irritating, and not pleasant
19:52:55 <Nukebuster> well, thats why it should be a patch option...
19:53:13 <Nukebuster> as soon as you get annoyed... you just turn it off
19:53:22 * Darkebie mumbles something about world of warcraft and tooltips :p
19:54:57 <stillunknown> Noone serious would use a signal gui to build a lot of signals, it's too inefficient.
19:56:36 <Nukebuster> how extreme is this gui thingie anyway...
19:57:12 <Nukebuster> doesn't it allow you to switch between semaphores,normal signals and distance between signals when dragged?
19:58:01 <Darkebie> I don't get the 'unload' 'load' and 'transfer' options for orders, when i do transfer between 2 endpointstations i earn 8k and my ore just piles up, when i do unload & load between them i only earn 5k and i barely get to move stuff :s
19:59:49 <Eddi|zuHause2> Darkebie: "transfer" means "leave cargo at the station to let another train pick it up"
20:00:03 <Eddi|zuHause2> it does not actually pay you anything
20:00:11 <Eddi|zuHause2> it just shows a income information
20:00:28 <Eddi|zuHause2> you get payed if you actually deliver the stuff to an industry
20:05:22 <Darkebie> another question, does it suffice for a station to cover 1 square of an industry to transfer for it?
20:05:57 <Eddi|zuHause2> deliver, not transfer
20:06:19 <glx> it depends on the industry type
20:06:20 <Eddi|zuHause2> no, you have to cover a piece that actually accept the goods
20:06:43 <Eddi|zuHause2> not all industry tiles accept everything... especially power stations and oil refineries
20:08:10 <Eddi|zuHause2> use the query tool on one of those industries
20:08:36 <Eddi|zuHause2> also, the station build window will tell you if you are near enough to deliver cargo
20:09:44 <Darkebie> true, but when there are 2 nearby industries of the same type I don't know if it works for both or not :-p
20:12:22 <Belugas> the system will dispatch based on the nearest one
20:12:44 <Darkebie> Aha so I need 2 anyway, alright tyvm :)
20:14:47 *** Eddi|zuHause has joined #openttd
20:24:01 <peter1138> "this acceleration is more realistic for maglevs (they won't go over mountains for example)"
20:24:08 <peter1138> why is that more realistic?
20:24:53 <valhallasw> then no trains should go over mountains :P
20:25:27 <peter1138> stillunknown: you should remove pointless changes
20:25:30 <Eddi|zuHause> what would prevent a maglev from going uphill?
20:25:36 <peter1138> - _disastervehicle_tick_procs[this->subtype](this);
20:25:37 <peter1138> + _disastervehicle_tick_procs[subtype](this);
20:26:13 <valhallasw> peter1138: imo this->x is more clear than x, but if the openttd coding style is that way...
20:26:18 <Eddi|zuHause> why would that STOP the maglev from going uphill?
20:26:20 <stillunknown> It seems i was wrong, will change the beheaviour.
20:26:31 * valhallasw mainly does python where self. is needed anyway
20:26:37 <peter1138> valhallasw: right... the patch removes the this-> ;)
20:28:34 <stillunknown> I think that change happened when i skipped a trunk revision.
20:29:05 <stillunknown> About the maglev, will have to look at it further, since i kind of like the fact that maglevs don't accelerate like rockets.
20:29:20 <peter1138> i'm saying it's bad
20:29:34 <peter1138> but it's not necessarily realistic (nor is the current...)
20:31:17 <peter1138> you should probably use this-> as well
20:31:52 *** MarkSlap has joined #openttd
20:32:38 <stillunknown> peter1138: the whole point of working in a class is not doing that.
20:34:08 <Noldo> stillunknown: and being able to use private members
20:34:27 <valhallasw> stillunknown: the whole point of a class is being able to instantiate
20:34:41 <valhallasw> and when you want to use the instance, it is just logical to use this->
20:37:49 <stillunknown> It's a personal preference, and more than one or two people need to express that preference before i changed a large amount of code.
20:38:32 <peter1138> it's not exactly consistent at the moment
20:39:07 <stillunknown> Openttd is strange anyway, there were no private functions in the vehicle class.
20:39:28 *** Nukebuster has left #openttd
20:39:44 <peter1138> that's because there were no classes
20:41:03 <stillunknown> peter1138: do you happen to know for fact how other devs think about this->?
20:42:51 * Belugas agrees with peter1138
20:44:50 <stillunknown> Rubidium: What's your opinion on this->?
20:46:42 <Belugas> are you going to ask each and everyone of us??
20:48:26 <Rubidium> stillunknown: what do you think? Who wrote the this-> in that diff-chunk?
20:49:32 <stillunknown> You did i guess.
20:53:58 <stillunknown> peter1138: Would you also do this for class based functions?
20:54:04 <stillunknown> this->MyFunc() ?
20:57:00 <Noldo> I never really understood private functions
21:00:19 <stillunknown> Noldo: In an ideal world a class has an outside interface like a kitchen appliance and you never touch the insides.
21:00:31 <stillunknown> The insides are private functions.
21:01:14 <peter1138> except with c++ you need to expose the interface :)
21:01:26 <Noldo> peter1138: yes, that is the idiotic part
21:02:06 <stillunknown> You always need to expose some interface.
21:02:18 <Sacro|Laptop> stillunknown: you don't even have to wiggle a knife inside once in a while?
21:02:25 <Noldo> stillunknown: but the interface of private functions
21:02:40 <Noldo> stillunknown: they are not going to be called from outside anyway
21:02:57 <Noldo> so they are basically just implementation details
21:02:59 *** NukeBuster has joined #openttd
21:03:57 <Eddi|zuHause> an outside program should not even know that there are private functions
21:04:22 <Noldo> Eddi|zuHause: well not outside programs, but outside classes
21:04:48 <Eddi|zuHause> that depends on the specific details of "private"
21:05:20 <Eddi|zuHause> some private functions are not private within the class, but within the file or compilation unit
21:05:41 <Noldo> for out side programs you will use abstract classes as an iterface anyway
21:10:35 <Eddi|zuHause> you can't only expose abstract classes, because you need to have real classes to instantiate objects
21:12:15 <NukeBuster> what's with doxygen?
21:13:31 <Eddi|zuHause> that's a serious sign for running out of arguments :p
21:15:01 <Noldo> I would need some sleep
21:15:58 <Noldo> all member functions need to be declared in the class definition which usually is in the header file
21:16:45 <Noldo> now if the class is widely used in the program many other files will depend on the header file
21:17:43 <Noldo> now the class has a nice and clean interface that is used all over the program and you are working on the dirty details on how the class is doing it's thing
21:19:25 <Noldo> you find out that hey, wouldn't it be nice to make this often used snippet of code a function, but oh, it needs to be member function because it needs access to private members and of course it wants to be private because it's just some implementation stuff
21:20:00 <Noldo> now you need to add that function to the class definition
21:20:05 <Eddi|zuHause> i know how classes work
21:20:53 <Noldo> and this forces all the other people working on the different parts of the project to recompile all parts that are dependent on that header file
21:21:08 <Rubidium> Noldo: there's another solution
21:21:35 <Noldo> but that makes private member functions completely useless
21:22:12 <Rubidium> make the public part of the class in the header and extend that class in an "internal" header and then you always instantiate such an "internal" classes.
21:23:46 <Eddi|zuHause> you mean if someone instantiates an object of the "public" class, you instantiate another object of the "private" class internally and return that one?
21:24:26 <Eddi|zuHause> i think that will horribly fail if the other program tries to inherit from your public class
21:25:20 *** ChanServ sets mode: +o orudge
21:26:10 <Rubidium> Eddi|zuHause: true, but it's a hack anyway
21:26:33 <Eddi|zuHause> C header files are a horrible concept anyway
21:29:06 <Noldo> Rubidium: wouldn't it then be easier to make tehe public part an abstract class?
21:30:10 <Eddi|zuHause> Noldo: again no, because you cannot instantiate abstract classes
21:30:18 <Rubidium> Noldo: that was kind-of what I proposed, but it won't work nicely because when you inherit, you need to inherit the "hidden" one
21:31:18 <Noldo> Rubidium: but it wouldn't give the user any false hopes about getting any functionality with the inheritance
21:31:45 <Noldo> Eddi|zuHause: you can't instantiate those public part classes either
21:32:14 <orudge> Hmm, OpenTTD doesn't compile on OS/2 any more, it can't find vswprintf
21:32:25 <Eddi|zuHause> Noldo: you have to call "new Something()"
21:32:55 <Eddi|zuHause> you cannot do that with abstract classes
21:33:21 <Noldo> but that better because the compiler will tell you you can't do that
21:33:57 <Noldo> without abstracting the public part the compiler can't warn you about the mistake you are making
21:34:07 <Rubidium> though I think you can *never* make the private functions completely invisible from anything else
21:34:30 <Rubidium> and keep the inheritance nice
21:34:47 <Rubidium> even in Java they failed in that
21:35:29 <Rubidium> the whole private/protected/public is done on compile time and nobody cares when you pass private functions as function pointers to somewhere
21:35:55 <orudge> hmm, for some reason, vswprintf is listed as "todo" in the wchar.h file
21:36:13 <Noldo> I need to get some sleep soon
21:36:21 <glx> orudge: disable unicode then
21:36:30 <orudge> it works fine otherwise
21:36:33 <orudge> it's just that one definition :/
21:36:35 <Noldo> I need to look like I'm coding tomorrow
21:36:43 <glx> unicode is disabled for win9x
21:36:44 <Eddi|zuHause> hm, but you have to export the function pointer from an internal function
21:36:48 <orudge> which for some reason doesn't appear to be defined fully
21:36:58 <orudge> glx: well, it all compiled fine up until r10389
21:37:15 <Rubidium> KUDr added some debugging stuff
21:37:17 <orudge> it's not that OS/2 doesn't support it
21:37:27 <orudge> it's just that, for some reason, this thing doen't appear to be defined properly in the header
21:37:34 <Rubidium> and I wonder whether it's actually used
21:39:41 <orudge> Hmm, this is it compiling now, but whether it'll link properly, or the headers were just out of date, I'm not sure yet
21:39:42 <KUDr> it is there just for debugger
21:39:47 <Rubidium> is it actually needed to have wide char debugging stuff?
21:40:25 <KUDr> CStrT supports both ANSI and Unicode
21:41:13 <KUDr> so orudge, please declare some dummy inline function for that elsewhere
21:41:33 <orudge> it's just the fact that, in my wchar.h file, the definition is commented out with "@todo" next to it
21:41:36 <orudge> I'm not entirely sure why.
21:41:43 <orudge> so, I'll find out what happens if I uncomment it...
21:43:53 <KUDr> orudge: in ottd we don't use wide chars i think, but CStrT is now the same as I use on other projects and i would like to keep it in sync for easier maintenance
21:44:38 <KUDr> WIDE is UTF-16 on Win32 or UTF-32 otherwise (UCS-2/UCS4)
21:45:18 <KUDr> and in ottd it is not called so linker eliminates it
21:45:24 <Rubidium> ooh, joy: the defacto "there is no standard standard"
21:45:32 <orudge> well, that's fine then
21:45:41 <orudge> as I say, it was present in the wchar.h file, just commented out
21:48:09 <Eddi|zuHause> why is there no --disable-debug?
21:48:32 <Eddi|zuHause> (have to use --enable-debug=0)
21:49:51 <orudge> Ah, there we go, it's built OK
22:06:33 <glx> Eddi|zuHause: debug is disabled by default
22:06:57 <Eddi|zuHause> yes, but if i enabled it once, i have to disable it again
22:07:15 <glx> non you just reconfigure without enabling it
22:07:39 <Eddi|zuHause> ok, next time i know that :)
22:35:46 *** DorpsGek has joined #openttd
22:35:47 *** ChanServ sets mode: +o DorpsGek
22:36:05 <Eddi|zuHause> we need a place for a short description of the server, besides the title
22:37:08 <black_Nightmare> eddi...its only like named 'Server server' in the client list and yeah the server dialog is as less helpful
22:37:12 <black_Nightmare> good idea there
22:40:51 <black_Nightmare> eddi...if you'll feel free... look up the server and just mind your jaws dropping
22:41:16 <Eddi|zuHause> i don't have a release build
22:43:31 <black_Nightmare> crazy idea: a kick vote and if over 3/4 of the players agree...bam?
22:43:51 <black_Nightmare> since this is one sick player against six normal ones otherwise
23:09:40 <black_Nightmare> either way just curious about it but anyone ever played any servers with any trainset grfs? (well aside to the obvious one daily uk grf)
23:14:27 *** Nickman^Away is now known as Nickman
23:17:44 *** Osai is now known as Osai^zZz
23:20:00 <Eddi|zuHause> i have seen several servers using newgrfs
23:20:27 <Eddi|zuHause> but i don't play online usually
23:20:56 <black_Nightmare> yeah well most of the times these seem to be clueless ones..often no sites to help on finding grfs or for what the pw is.. but then I guess there're private online player groups somewhere me think
23:25:33 *** ThePizzaKing has joined #openttd
23:26:15 *** Sacro|Laptop has joined #openttd
23:46:40 *** black_Nightmare has left #openttd
23:50:17 *** NukeBuster has joined #openttd
23:50:21 <NukeBuster> at what revision did the directory structure change?
continue to next day ⏵