IRC logs for #openttd on OFTC at 2010-09-01
⏴ go to previous day
00:15:33 *** roboboy has joined #openttd
01:05:51 *** roboboy has joined #openttd
01:06:35 *** ChanServ sets mode: +v tokai
01:42:51 *** De_Ghosty has joined #openttd
02:44:10 *** Prof_Frink has joined #openttd
03:28:09 *** roboboy has joined #openttd
04:13:44 *** HerzogDeXtEr has joined #openttd
04:27:05 *** robotboy has joined #openttd
04:56:36 *** Eddi|zuHause has joined #openttd
04:58:59 *** [com]buster has joined #openttd
04:59:03 *** [com]buster is now known as Combuster
05:46:01 *** Kurimus has joined #openttd
06:15:15 *** George is now known as Guest225
06:15:50 <CIA-2> OpenTTD: rubidium * r20708 /trunk/src/ (object_cmd.cpp saveload/object_sl.cpp): -Fix [FS#4101]: upon company bankruptcy some objects weren't removed properly
06:29:36 *** Cybertinus has joined #openttd
06:38:23 *** ^Spike^ has joined #openttd
06:40:10 *** TomyLobo has joined #openttd
07:10:53 *** Br33z4hSlut5 has joined #openttd
07:12:50 *** George is now known as Guest234
07:13:47 *** robotboy has joined #openttd
07:21:37 *** JVassie has joined #openttd
08:13:18 *** Combuster has joined #openttd
08:16:56 *** De_Ghosty has joined #openttd
08:28:00 *** lordaro has joined #openttd
08:39:46 *** Progman has joined #openttd
09:09:22 *** ChanServ sets mode: +v tokai
09:36:43 *** ClampyLubsClarey has joined #openttd
09:41:31 *** JVassie_ has joined #openttd
09:42:44 *** Adambean has joined #openttd
09:52:07 <Vitus> Rubidium: The old (corrupted) savegames with object_map.h assertion error load just fine in r20708. Thank you :)
10:07:04 *** fjb is now known as Guest247
10:12:24 *** Br33z4hSlut5 has joined #openttd
10:17:00 *** eQualizer has joined #openttd
10:21:56 *** wollollo has joined #openttd
10:28:13 *** lasershock has joined #openttd
10:29:00 *** norbert79 has joined #openttd
10:31:54 *** robotboy has joined #openttd
10:33:10 *** Sacro is now known as Guest249
10:35:27 <norbert79> Hah, some fake Sacro?
10:35:54 <norbert79> Sacro changed his name to Guest249, then the ID got disconnected
10:36:53 <Sacro> that was me reconnecting my wifi
10:37:01 <Sacro> trying to work out why i can only use https sites
10:37:17 <norbert79> Do you have QoS running?
10:37:49 <norbert79> Btw HTTP is port 80 on outgoing connections, HTTPS 443, IRC is 6667
10:37:57 <norbert79> might be ralted to ports probably
10:38:04 <Sacro> it's the university connection
10:38:10 <Sacro> They seem to have fubar'd it
10:50:55 *** Sacro is now known as Guest250
10:52:57 *** KenjiE20 has joined #openttd
10:56:02 *** ChanServ sets mode: +v tokai
11:00:38 *** Sacro is now known as Guest251
11:01:01 *** norbert79 has left #openttd
11:10:53 * peter1138 ponders building a 5.1 system that, while isn't excellent, is a damn sight better than the one-piece crap you can buy...
11:16:15 *** ClampyLubsClarey has quit IRC
11:19:04 *** norbert79 has joined #openttd
11:21:31 *** lewymati has joined #openttd
11:28:21 *** eQualizer has joined #openttd
11:40:53 *** robotboy has joined #openttd
11:48:34 <Adambean> compiled r20708, copied the binaries and lang across
11:48:49 <Adambean> 'No available language packs'
11:49:42 <Eddi|zuHause> then your copy was not complete
11:49:44 <planetmaker> cp -Rf bundle/* autopilot?
11:50:29 <Adambean> i'll delete the lang folder from the bin output
11:50:29 <planetmaker> oh. he. nickname miss-match :-P
11:50:41 <planetmaker> same colour. Same initial :-)
11:51:00 <planetmaker> anyway: use "make bundle" and copy the whole bundle folder
11:51:17 <planetmaker> you can make a bundle anyway
11:51:47 <Adambean> gonna recompile the whole solution
11:53:45 <norbert79> planetmaker: You are so rude ;-)
11:54:13 <norbert79> Adambean: Just replied him based on a Forum reply :)
11:55:24 <Adambean> takes damn ages to build the library :p
11:56:39 <Adambean> owait isee what i've done
11:56:48 <planetmaker> norbert79, what is rude about the fact that "if you're interested in a feature, work for it or it won't happen"?
11:56:52 <Adambean> forgot to change the output exe location, looks like i've been copying a very old binary
11:57:12 <planetmaker> it's the simple reality
11:57:25 <planetmaker> Besides the question has been rised a dozen times before at least
11:57:26 <Adambean> nothing, especially if it's for free
11:57:41 <norbert79> planetmaker: That way more like meant as a joke, but anyway, I feel a bit uncomfortable, since it's not me who is the best with coding, you guys are...
11:58:06 <norbert79> planetmaker: Which also shows people would really be happy having it
11:58:29 <planetmaker> but I spend my time on those things which I see a gain in.
11:58:57 <planetmaker> and such conversion has more than just one problematic point
11:59:13 <planetmaker> and many of those I see no sane way to solve them
11:59:14 <norbert79> planetmaker: Same for me, like my wife, son... :) But anyway, I really love the game, and would be happy to see some new features, thats all, I am still thinking about the methodology of the solution first...
12:00:09 <planetmaker> The simple solution is even the realistic one: send everything to a depot. Convert tracks. Make new trains and have them share the orders with the old
12:00:10 <norbert79> Well, one plain solution would be not making differences between depots, but having a flag only for which types of rails the depot has been attached to
12:00:20 <planetmaker> A replacement of trains cannot work
12:00:29 <norbert79> the part "make new trains" is the most painful one to be honest
12:00:44 <norbert79> like when you have more, than 40-50 trains
12:00:57 <norbert79> the second part is ok, same like I do
12:01:11 <planetmaker> You don't have 40-50 different routes?
12:01:20 <norbert79> Making changes to depots, and not making differences between railtypes depots
12:01:32 <planetmaker> The number of trains doesn't matter. The number of different sets of orders matters
12:01:36 <norbert79> but to only allow vehicles which can be run on that specific railtype
12:01:47 <norbert79> you don't remove a depot in real life neither when you have something new
12:01:56 <norbert79> you renew the old, thats it
12:02:08 <planetmaker> yes. And sell the old vehicles before. And buy new ones
12:02:15 <norbert79> or you convert them
12:02:21 <planetmaker> Congratulations. You found out what works exactly like reality in OpneTTD
12:02:38 <planetmaker> If there's no vehicle in the depot
12:02:53 <norbert79> you have to remove all the trains first before transforming the depot
12:02:56 <planetmaker> And in reality you don't change the track type in a depot from rail to maglev while there's a dozen trains in it
12:03:11 <norbert79> ever seen depots with different types of rails?
12:03:19 <norbert79> Even if you say no, it's not impossible
12:03:41 <planetmaker> It's not impossible. But so it's not impossible to build two adjacent in OpenTTD.
12:04:03 <planetmaker> The argument with realism supports how it works now, mate :-)
12:04:51 <planetmaker> Even though realism is no argument for a game. But fun is
12:04:52 <norbert79> Not really, it might be the case for western countries, but I have seen some very unique solutions, and allowing support for different railtypes for the same depot is one of those solutions which a western country would never consider :)
12:04:59 <planetmaker> But personally I never have the need to upgrade
12:05:10 <norbert79> With this logic no NewGRF'sa could've been possible mate ;-)
12:05:31 <planetmaker> That analogy eludes me
12:05:52 <planetmaker> what you want exactly fails _because_ of newgrf
12:06:45 <norbert79> planetmaker: I just think we are on way different mindests and experience, I agree, fact is, that the game is fun, but for depots I could imagine a bit more flexibility, thats all.
12:06:48 <planetmaker> then you have your orders, replace all trains to maglev... oh.um... we only have passenger+mail maglev. What do we do about the 90% cargo trains running around?
12:07:38 <norbert79> And why do you feel offended by this question? This riddles me most, but whatever...
12:07:39 <planetmaker> so... as long as there is a) no working concept and b) no one willing to work for it... you're exactly at where my reply points you to in all brevity
12:07:59 <norbert79> Besides Maglevs do have other cargo types of wagons
12:08:07 <planetmaker> they don't... if you use newgrf
12:08:07 <norbert79> So you're wrong at that point
12:08:16 <norbert79> depends what NewGRF you use
12:08:19 <planetmaker> with newgrf you might not have any maglev wagon
12:08:39 <Rubidium> being able to have steam trains in a maglev depot implies you can build steam trains in a maglev depot as well
12:08:39 <norbert79> Which proves you wrong, I never said I would replace all the trains
12:08:45 <Rubidium> does that make sense?
12:08:54 <norbert79> Rubidium: Ever seen Back to the Future 3? :D
12:09:38 <planetmaker> norbert79, but you still didn't answer the question: what rule do you want to use when and under which conditions things shall get and be allowed to be replaced
12:09:40 <Rubidium> in any case, if you want to mass replace to maglev the moment it arrives, might it not be better to just start when maglevs arrive?
12:09:44 <norbert79> No, I am just saying like a depot could allow any type of vehicles, but would only list those, which are relevant to the tracktype which the depot is connected to
12:10:46 <norbert79> like when a depot is connected to a normal railway it would allow only railroad types, when both to monorail and railway, then both, but only for those tracks which are capable of running the specific tracks
12:10:46 <planetmaker> which will always be the track type the trains are currently running on ;-)
12:11:04 <planetmaker> a depot is always connected to _one_ track type only
12:11:11 <planetmaker> there is no more possibilities
12:11:11 <Yexo> norbert79: so a steam train can enter/leave a maglev depot, would it also be serviced there? and can it autorenew? you just said you can't buy new steam trains in that depot
12:11:14 <norbert79> yeah, but this way you could just turn a plain one to a monorail one without rtemoving the train, and transforming the depot
12:12:06 <planetmaker> norbert79, but as the train can't run on monorail anyway: what would be the advantage?
12:12:22 <norbert79> Yexo: Ok, let me explain it like this: A depot would be a bit more larger, allowing more entrance, than one. It would allow connecting a monorail and a maglev for example. Old train enters on monorail, you replace, (renew), and it would exit on the maglev one, since that new one only supports maglev
12:12:38 <planetmaker> having a monorail depot just next to it does serve the same what you argue now
12:12:57 <Rubidium> he's just arguing for multi-tile depots :)
12:12:58 <norbert79> planetmaker: No, you still have to remove the train, buy a new one, nut just simply replacing it
12:13:10 <norbert79> Rubidium: Exactly, thank you, that was the word I was looking for
12:13:20 <Yexo> norbert79: this is the first time I hear you mentioning that a depot should be multiple times
12:13:25 <Rubidium> well, it's been suggested before and nobody has bothered to implement it
12:13:35 <Rubidium> so consider it "not likely to happen any time soon"
12:14:02 <planetmaker> before I consider these, there's a multitude of steps there, each a large one:
12:14:02 <norbert79> Rubidium: The idea would be like with stations, I often used multi-type railtypes on stations too
12:14:22 <planetmaker> a) allow arbitrary replacements, not just one engine or wagon vs. another. Allow to replace a whole consist by another
12:14:32 <planetmaker> b) allow multi-tile depots
12:14:39 <planetmaker> c) allow multi-tracktype depots
12:15:07 <norbert79> planetmaker: Stations do already allow this, what makes it so different? I am not that expeerienced in the programming side, thats why I am asking
12:15:45 <Rubidium> they are totally different entities in the game
12:15:47 <planetmaker> it currently is just quite different.
12:16:11 <Rubidium> same way houses and industries are different entities, though both generate/accept cargo
12:16:15 <Yexo> norbert79: first you were arguing for multiple rail types in a single depot tile, later you said you ment multi-tile depots
12:16:25 <Yexo> that changes at least my opinion on the feature
12:16:32 <planetmaker> Yexo, he means all of my a...c ) ;-)
12:16:33 <norbert79> Yexo: Hard to express yourself when you are always looking for the right wording :)
12:16:48 <Yexo> I can understand that :)
12:17:23 <Yexo> I'm not against multi-tile depots, what that needs most is a good way to identify different depots
12:18:07 <Yexo> oh, and a way to prevent teleporting trains by having multiple exits at completely different locations
12:18:20 <Yexo> maybe some builtin delay before exiting on another tile
12:18:21 <norbert79> My idea came from the fact, that I am also forced creating a different depot for trams and one for trucks/buses, where her ein hungary the same were used for both in many cases
12:19:05 <norbert79> at least for servicing...
12:19:48 <planetmaker> norbert79, but placing two such things adjacent would be basically the same you argue ;-)
12:21:01 <Eddi|zuHause> i think it needs to get rid of the concept of automatically teleporting. the way i see multi-tile depots is: each depot tile has a fixed number of tracks (like 2 or 3). the player can move vehicles between tracks in the depot window, but the trains themselves cannot do this. as a side effect, one cannot make trains longer than the longest track in the depot
12:22:36 <norbert79> Eddi|zuHause: My idea might sound complicated a bit, but what about the need of additional parking-tracks, like in real life? Like when you send a train to a depot for servicing you don't take the wagons too
12:22:59 <planetmaker> that's a further complication
12:23:02 <norbert79> But I guess that would require more resource just to develop the idea itself
12:23:08 <Eddi|zuHause> i don't play with servicing, i have no opinion about that
12:23:08 <planetmaker> and wagons need servicing, too
12:23:17 <norbert79> planetmaker: Indeed...
12:23:50 <Eddi|zuHause> and and "leave the wagons behind when servicing" needs shunting, which is a whole different shoe...
12:24:27 <norbert79> yet you could make use of the trains finally, which exactly do that in real life as well :)
12:24:41 <norbert79> Just kidding, I know, it would take huge work
12:26:15 <norbert79> Well for the simplicity I also agree with you guys, yet I will still think this further, because I am sure, that it is possible somehow without hurting playbility
12:28:21 <norbert79> ...and I love riddles :)
12:36:32 <planetmaker> <norbert79> ...and I love riddles :) <-- then get to work :-P
12:37:43 <norbert79> It's easy when you don't have to work... :)
12:38:25 <planetmaker> But you get to understand the problems involved much deeper when dealing with it first-hand ;-)
12:38:41 <planetmaker> That's how I started with OpenTTD... I just wanted *this* to happen. So I worked for it
12:39:12 <planetmaker> where *this* was a massive-multiplayer event on a single map. In those days when there were max 11 clients ;-)
12:39:43 <planetmaker> it was hackish. Very hackish. But it worked out and was great fun
12:39:48 <norbert79> :) Well, I also had fun years ago too, then I found one, had a son, strated playing games rarely...
12:39:58 <norbert79> But still kept in touch with OpenTTD
12:40:18 <norbert79> I even bought the original Windows version too, yet I don't use it :)
12:41:03 <norbert79> I also bought some older greate names also in original case, like Duke Nukem 3D, got the registered version and plutonium pack too
12:41:24 <norbert79> So I stayed in touch, and infected my son too :)
12:44:58 <planetmaker> hehe. You're not the only one doing so
13:03:42 <norbert79> planetmaker: Got a child too?
13:04:12 <Belugas> salutations, mister norbert79
13:04:28 <norbert79> How are you doing this morning/afternoon?
13:06:51 *** Biolunar has joined #openttd
13:12:38 <norbert79> Btw, is the master server hard-coded in the code (the one, which collects all open internet games), or can it be changed?
13:14:13 <Rubidium> it can be changed by spoofing the dns
13:14:51 <norbert79> Rubidium: Other, than that, like modifying the cfg file
13:15:01 <Eddi|zuHause> norbert79: no. only in source code
13:15:11 *** fjb is now known as Guest259
13:18:11 <Belugas> norbert79, i'm fine in this morning, thank you. I'm buzy replying to a tester who tries to induce all in error about my product, hiding a misbehaviour of his as a bug of mine
13:18:22 <Belugas> he picked the wrong guy./...
13:18:48 <norbert79> Yeah, happens to me also often, yet I am the one often who tells the other one what his/her job is
13:18:55 <norbert79> since I am advising them :)
13:20:25 <Belugas> someone did exposed the master server address in a config file, i believe it was yorick
13:20:42 <Belugas> but... of course, it was not accepted.
13:21:41 <norbert79> Belugas: Pity, since what if the master servers goes down, and some day the master server will disappear? It would be nice being able making any cxlient as a master one, where explicitly needed
13:22:02 <norbert79> I am just always thinking ahead, not wanting to change anything
13:22:33 <planetmaker> norbert79, when the master server goes down (permanently) then OpenTTD is kinda dead
13:22:54 <planetmaker> the project. not the programme on your machine
13:23:00 <norbert79> but what if someone else wants to take over? Ok, I know, the code can be changed any time
13:23:03 <Rubidium> I fear the "person with no clue has accidentally changed that settings and now we have to debug that"-scenario way more
13:23:31 <norbert79> I just find nice of being able to change the value any time :)
13:23:37 <planetmaker> norbert79, exactly. The code can be changed any time
13:23:49 <Rubidium> in any case, it's a DNS so it can be changed at any time
13:24:24 <planetmaker> install special routing rules for the name server
13:24:24 <glx> yes openttd doesn't know the IP of master server
13:24:27 <norbert79> I don't want to come up with examples, it's like with Sauerbraten, where you can also modify the matser server's address
13:24:50 <planetmaker> I do eat Sauerbraten. I didn't know it had an IP address, though :-P
13:25:41 <Rubidium> still with the amount of people having trouble getting their server online or finding servers online NOT having the ability to configure that makes debugging that task considerably easier
13:26:15 <norbert79> Rubidium: True... But normal users also do not tend to hastle through config files, just using the GUI, thats it :)
13:26:28 <Rubidium> even then... adding the master server code to clients isn't a good idea as you'd link OpenTTD to MySQL in that case
13:26:50 <norbert79> That wasn't my intention, to be honest I had no intention at all, I was just curious :)
13:26:53 <Rubidium> norbert79: but if things don't work they are capable of everything, which is exactly my point
13:27:26 <Rubidium> especially in the case things don't work they resort to other stuff like the configuration file
13:27:56 <planetmaker> there's sufficient people around who change a lot of things but fail to setup their router in the first place
13:27:58 <norbert79> I prefer editing the cfg file normally, I am way too be used doing so
13:28:13 <Rubidium> because they somewhere found on the forum that you need to change the master server address to example.com even though that was in a thread about Example's special server
13:28:40 <norbert79> You guys had way too much bad experience I guess :)
13:28:55 <planetmaker> no kidding. The extra support your suggestion would require outweighs any advantage several orders of magnitudes
13:29:42 <planetmaker> if certain things can't go wrong, it's always a bonus :-)
13:30:32 <planetmaker> Bad experiences is relative. It's how things work
13:31:27 <Eddi|zuHause> norbert79: when the project dies and the masterserver is not reachable anymore, all that is needed is either someone taking over the openttd.org domain and running a new masterserver there, or making a new release with a changed masterserver address
13:32:29 <norbert79> Eddi|zuHause: I know, I know...
13:32:43 <norbert79> Thanks though, and I also hope, that the project will stay alive for a very long time
13:32:46 <planetmaker> what's the point of making it user-configurable then?
13:33:05 <planetmaker> "just because"? :-P
13:33:24 <planetmaker> (which is indeed quite often a motivation
13:33:29 <glx> it is configurable, in hosts ;)
13:33:37 *** [com]buster has joined #openttd
13:33:57 <Eddi|zuHause> i really don't see a need for it... it would only cause harm to the community by not making the servers visible...
13:34:02 <norbert79> glx: Only if you use Windows, and there is also the changing of the routing table, etc etc :)
13:34:02 <Br33z4hSlut5> the master server is only needed to publish the game, right?
13:34:24 *** [com]buster has joined #openttd
13:34:26 <planetmaker> Br33z4hSlut5, "only"
13:34:49 <planetmaker> you'd find no server without except if you explicitly give the IP
13:35:14 <Eddi|zuHause> LAN games can be found without masterserver
13:35:23 <Br33z4hSlut5> you would still be able to play with friends then
13:35:34 <Br33z4hSlut5> and you could publish the address of the server in many ways
13:35:58 <norbert79> Oh god, I have let loose a monster :D
13:36:07 <norbert79> Next time I will be just silent :D
13:37:21 <Eddi|zuHause> i originally wanted to say something, but now i forgot what...
13:39:04 <Rubidium> Eddi|zuHause: that you finished you "capital usage in src/lang/english.txt" review?
13:39:20 *** [com]buster is now known as Combuster
13:40:49 <Eddi|zuHause> Rubidium: haha ;)
13:41:16 <planetmaker> no, but you finished the rivers, right?
13:42:14 <Eddi|zuHause> no, i remember now: why does the "signal side on driving side" setting not work like "xor" with the driving side? i.e. "driving side = left" and "signal side = not on driving side" result in "signal side = right"?
13:44:09 <planetmaker> historic raisins (shamelessly stolen pun, I know)
13:44:26 <Eddi|zuHause> that's called hysterical raisins
13:45:03 <planetmaker> Besides the failed pun: I do agree that the current way it works is... less than optimal
13:45:15 <planetmaker> Though my guess is also that changing the current way will break some NewGRF
13:45:37 <Eddi|zuHause> i once was on a multiplayer server with driving on left, and there was no way i could switch the signals to right side...
13:45:45 <planetmaker> how many those are and how strong the impact is... no idea
13:46:20 <Eddi|zuHause> i don't think newgrfs can check the signal side
13:46:43 <planetmaker> They can check driving side
13:46:52 <planetmaker> And they need to know the signal side for drawing them
13:47:03 <planetmaker> as such they should be able to access that, too
13:47:05 <Eddi|zuHause> no, that's not how newgrf-signals work
13:47:22 <planetmaker> FeatureE just has no action0
13:47:24 <Eddi|zuHause> you can only provide all signal graphics, or none
13:47:30 <planetmaker> But you can apply varaction2 chains there as well
13:47:33 <Eddi|zuHause> it's an action A or so
13:47:54 <planetmaker> It's usually actionA, though. But you can do fancy stuff
13:48:34 <planetmaker> I'd wonder if mb hasn't used all of that :-P
13:48:55 <Eddi|zuHause> not in any release since the last 5 years :p
13:49:07 <planetmaker> nor in the next 5
14:26:28 <Vitus> Hello, I've been tooling with wallyweb's dam NewGRF. According to his .nfo, it should be buildable on water (and do not flood). Yet it does flood in OpenTTD.
14:26:35 <Vitus> Probably question for Rubidium :)
14:28:52 *** Sacro1 is now known as Sacro
14:30:27 <Eddi|zuHause> the damn newgrf, aye ;)
14:33:27 <Ammler> Vitus: maybe that grf is from "before" spe changes
14:33:47 <Vitus> r2339, should be with the new specs
14:38:01 *** norbert791 has joined #openttd
14:38:02 <robotboy> I think you will find r2339 when comming from wallyweb is the TTDP svn revision
14:41:38 * robotboy wonders how to solve the zlib issue when using MinGW
14:42:15 <Vitus> robotboy: I know, it's the revision that includes the new NewObject specs
14:48:34 <Eddi|zuHause> ... i shouldn't have started compiling wine during the day...
14:51:17 * robotboy leavs compiling alone
14:51:40 <Eddi|zuHause> planetmaker: doesn't look very conclusive
14:52:08 <Eddi|zuHause> robotboy: i had to work around a few regressions
14:55:16 * robotboy ponders looking at the windows port of DJGPP
14:56:27 *** norbert79 has joined #openttd
14:56:42 <planetmaker> Eddi|zuHause, conclusive in what way?
14:56:58 <planetmaker> That's definitely a number where the statistics can be trusted
14:57:03 <Eddi|zuHause> planetmaker: as in "representative", "stable", ...
14:57:04 *** norbert79 is now known as Guest271
14:57:20 *** Guest271 is now known as norbert79
14:57:41 <Eddi|zuHause> i mean to extrapolate a picture of the current or future community
14:57:55 <planetmaker> I don't mean to set a trend, no
14:58:05 <planetmaker> That's something one can NOT draw from it :-)
14:58:58 <planetmaker> Number Reports also should rather read "number of unique users whom I could attribute a base set to"
14:59:42 <planetmaker> number of bug reports is by ~50% at least higher
15:01:03 <DorpsGek> planetmaker: 7.87400787401
15:01:16 <planetmaker> hm, yes. And the statistical error is about 8%
15:01:32 <planetmaker> (as it's 100 entries)
15:06:15 <planetmaker> hm... I should | sort | uniq the total list... That looks *very much* different
15:06:26 <planetmaker> unless I did an error
15:09:25 <planetmaker> Unique | 85 | 37 ( 44%) | 48 ( 56%)
15:16:03 *** Combuster has joined #openttd
15:19:21 * norbert79 is leaving for today... See you then!
15:26:17 *** FloSoft has joined #openttd
15:56:41 *** lobstar has joined #openttd
16:25:33 *** frosch123 has joined #openttd
17:03:17 *** ClampyLubsClarey has joined #openttd
17:04:12 *** [com]buster has joined #openttd
17:10:08 *** [com]buster is now known as Combuster
17:16:06 <Eddi|zuHause> ... wine still compiling...
17:18:37 <dihedral> You downloaded the source?with your slow connection?
17:21:57 <Eddi|zuHause> i type "git fetch" and do something else...
17:25:38 <dihedral> Belugas: beer fetch? :P
17:26:19 <Belugas> avdg, I hope you'll stay with us a very long time, now
17:26:43 *** |Jeroen| has joined #openttd
17:27:16 *** Combuster has joined #openttd
17:28:15 <Eddi|zuHause> Belugas: so at your place that is customary during work hours? ;)
17:29:03 <Belugas> here, it's rather: coffee fetch
17:29:10 <Eddi|zuHause> i haven't experienced that first hand, but it is said if you work in bavaria, you are entitled to one beer during lunch break
17:29:11 <Belugas> sudo apt-get cooffe-mug
17:29:34 *** George is now known as Guest287
17:31:17 <avdg> far from annoying *uhum*
17:38:45 *** TheMask96 has joined #openttd
17:45:30 <CIA-2> OpenTTD: translators * r20709 /trunk/src/lang/irish.txt:
17:45:30 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:30 <CIA-2> OpenTTD: irish - 28 changes by tem
17:46:49 <Belugas> so... some Bloody Time Zones music, for a change
17:47:00 <Belugas> yeah, I know... advertizing...
17:47:29 <peter1138> they're quite good, them ;)
17:49:16 <Belugas> i've been told they are, indeed :)
17:50:40 <Belugas> ho... look... an URL...
17:51:49 <peter1138> they should do a second album i reckon
17:55:01 <Belugas> i think they have enough stuff done for that, already
17:55:27 <Belugas> ho.. strange... you and I are the only listeners of the band :)
18:03:45 *** ajmiles has joined #openttd
18:09:03 <Eddi|zuHause> is that a promise or a threat?
18:09:58 *** Adambean` has joined #openttd
18:18:48 *** ClampyLubsClarey has quit IRC
18:25:27 <frosch123> he did not say "i'll be back"
18:32:16 *** JVassie has joined #openttd
18:35:59 *** fonsinchen has joined #openttd
18:48:40 *** lobstar has joined #openttd
18:52:54 <CIA-2> OpenTTD: terkhen * r20710 /trunk/src/town_cmd.cpp: -Codechange: Clarify the name of some town generation variables.
19:00:59 <CIA-2> OpenTTD: terkhen * r20711 /trunk/src/town_cmd.cpp: -Fix [FS#4094]: Do not use new game settings when creating many random towns at the scenario editor.
19:03:30 <Eddi|zuHause> gnah... :( updating wine fixed the crash at startup like the bug report told, but now this crashes midgame :(
19:04:18 <CIA-2> OpenTTD: terkhen * r20712 /trunk/src/industry_cmd.cpp: -Fix [FS#4094]: Do not use new game settings when creating many random industries in the scenario editor.
19:05:38 <Eddi|zuHause> it lacks a commit: "-Feature: Allow creating many random industries of one type"
19:06:22 <Eddi|zuHause> and: "-Feature: Allow mass removal of industries"
19:06:42 <Terkhen> I'll consider doing features once I have time for something bigger than small fixes :P
19:24:41 <ABCRic> But small fixes are important!
19:26:34 <ABCRic> Imagine if OpenTTD never had any small fixes applied...
19:35:29 <Lakie> Ah that didn't help me much, loading my object test grf into openttd caused an instant crash (nightly)
19:35:51 *** [hta]specx has joined #openttd
19:40:29 <Rubidium> booh... what did you do :)
19:40:53 <Lakie> Just try loading my test objects grf, clicking apply changes instakilled it
19:41:51 <Rubidium> so, how do I reproduce that?
19:41:58 <Lakie> Ah, probably down to a small spec change
19:42:06 <peter1138> mid-game or main menu?
19:42:47 <Lakie> Which is how I implemented it in TTDPatch
19:43:31 <Rubidium> then that's wrong :)
19:43:32 <Lakie> But judging from the wiki / renum post, you changed it to a word in openttd
19:43:45 <Rubidium> yeah, copied it's behaviour from something :)
19:43:50 <Lakie> That was around before the wiki got updated. ;)
19:44:08 <Lakie> Easy enough to fix though
19:46:02 <CIA-2> OpenTTD: rubidium * r20713 /trunk/src/newgrf.cpp: -Fix (r20654): when ignoring action0 object properties, ignore property 13 correctly
19:48:27 <Lakie> Also I think the wiki entry for var64 might be a little wrong?
19:48:52 <Lakie> So should I update TTDPatch to use a word for property 13, Rubidium?
19:50:26 <Rubidium> Lakie: in what way is 64 wrong?
19:50:59 <Lakie> it says offset from current tile, but from my understand of the var its based off, it takes the 'setid' through the parameter
19:51:18 <peter1138> who wrote this spec? :p
19:51:41 <Lakie> The added parts, Rubidium? ...
19:52:33 <Rubidium> Lakie: s/offset/distance/?
19:53:14 <Rubidium> like the updated page
19:55:40 <Lakie> I think so, I'll check over it after getting this commit done
19:57:07 <Lakie> Yeah, rest seems correct.
19:58:46 *** JVassie_ has joined #openttd
20:02:31 <Rubidium> Lakie: shouldn't uvarb change to uvarw?
20:05:56 <Lakie> Um, found a small issue with OpenTTD's implementation Rubidium, bit 9 implicitly implies bit 3...
20:06:16 <Lakie> (ie. setting bit 9 automatically enables the behaviour of bit 3)
20:07:22 <Lakie> Otherwise seems to be working fine
20:07:34 <Rubidium> you mean it isn't setting the bit? Or that it is setting it?
20:07:53 <Lakie> Well, I just mask both for that behaviour
20:08:18 <Lakie> if either is set, then it allows construction on water
20:08:47 <ABCRic> Talk about construction on water...
20:08:53 *** Combuster has joined #openttd
20:09:26 <CIA-2> OpenTTD: rubidium * r20714 /trunk/src/object_cmd.cpp: -Fix: bit 9 of object's flags implies bit 3 is set, so just test for either of the bits being set
20:09:50 <ABCRic> Building railroad starting at a station tile spawns an error message saying "...can't build on water"
20:11:14 <Rubidium> well, file a bug report :)
20:17:37 <CIA-2> OpenTTD: frosch * r20715 /trunk/Makefile.grf.in: -Fix: Recent nforenum does not know '-?'.
20:25:15 *** Brianetta has joined #openttd
20:27:17 <avdg> hmm.. I can reproduce that
20:34:49 <ABCRic> I could look at the code...
20:35:11 <ABCRic> Then again, I don't even know what an object is...
20:35:34 * avdg doesn't know the location of the tools
20:36:43 * ABCRic 's knowledge of C++ only goes as far as multiple file programs
20:37:44 <ABCRic> 'cos who needs multiple files if not for functions
20:37:58 <Lakie> Class and objects are pretty fundimental in C++...
20:38:22 <Lakie> Sure you don't mean just plain C?
20:38:29 <ABCRic> *'cos why would I need multiple files if not for functions
20:39:08 <ABCRic> I'm following a manual on C++, but I haven't gotten to the classes and objects part yet.
20:39:28 <Terkhen> start looking in rail_cmd.cpp, I'm fairly sure that the bug is not in an object :P
20:39:45 <Lakie> Well, one reason for mutliple files (headers and source) is maintainability
20:41:08 <ABCRic> Having 10 million lines of code in just one file doesn't sound very readable...
20:52:34 *** wollollo has joined #openttd
20:59:41 *** asnoehu has joined #openttd
21:03:54 <avdg> just did a quick check in the language files and located the constant and tried to confirm it was that rule that has been executed
21:04:28 <avdg> indeed it was in rail_cmd.cpp
21:04:42 <Terkhen> avdg: feel free to submit a diff for fixing the issue to the FS task :)
21:04:51 <ABCRic> so let me see if I got this...
21:05:12 <avdg> I just found why it display the error, not the cause of it
21:05:38 <avdg> uh, I know whats triggered :p
21:05:52 <ABCRic> no, I didn't get this. :P
21:06:09 <avdg> it just call that line, why, I don't know :p
21:06:35 <ABCRic> I have no idea what ((~_valid_tracks_on_leveled_foundation[tileh] & (rail_bits | existing)) != 0) means...
21:07:56 <avdg> but it worked on the stable
21:08:21 <avdg> so its caused due a codechange
21:08:41 <Terkhen> avdg: you can use annotate or blame to find the revision which caused the bug
21:09:18 <avdg> and ofcourse: trac won't cooperate :p
21:10:26 <Terkhen> praise sounds nicer than blame :P
21:11:15 <glx> depends on why you search
21:13:37 <avdg> that rule was edited 17 months ago
21:14:31 <avdg> its the callstructure that has been changed
21:14:32 <ABCRic> And if it's not, it should be a call to the function.
21:15:34 <avdg> hmm… I have 1 thing left from the test what can be useable :p
21:15:40 <ABCRic> Keep watching to find out. Now, a word from our sponsors!
21:15:48 <avdg> accidently crashed the binary while editing *shames*
21:16:04 *** theholyduck has joined #openttd
21:16:54 <ABCRic> So now we gotta search for calls to CheckRailSlope.
21:18:09 <Terkhen> I'd start bisecting then
21:18:34 * avdg wants to learn how to use grep :p
21:22:02 <ABCRic> There are only 4 matches for for CheckRailSlope, all in rail_cmd.cpp
21:22:22 <ABCRic> and none has been changed since r20261 (aka 1.0.3)
21:22:42 <avdg> you have to look at 1.0 I think
21:23:45 <Terkhen> I mean: 1.0.0 was branched long before that
21:23:51 <avdg> the branche 1.0 receives only patches
21:24:56 <avdg> you should look since the start of the 1.0 branche
21:25:52 <ABCRic> but the problem doesn't happen on 1.0.3, so the problem should be in some change after that...
21:26:27 <avdg> yes, but the bug can already triggered after the branche 1.0
21:26:41 <avdg> because that branche only receives fixes
21:27:03 <avdg> while the trunk can get new codechanges and features
21:28:31 <avdg> I think that image at "branch or svn branch" explains much
21:29:49 <ABCRic> The problem was likely caused by a codechange present in trunk but not merged with stable.
21:30:25 <ABCRic> I was getting really confused :P
21:30:59 <avdg> hmm… how do I look it up quickly?
21:31:48 <avdg> when that branche was created
21:32:36 <ABCRic> I think TortoiseSVN can do it
21:33:13 <ABCRic> The Revision Graph shows splits, merges, tags and such
21:33:51 <avdg> except that it is slow :p
21:34:10 <ABCRic> Yeah, OpenTTD has a lot of revisions...
21:34:37 <ABCRic> And my internet connection malfunctions a lot.
21:34:40 <Rubidium> nah, it's more that SVN has to fetch data from the server
21:34:58 <Rubidium> whereas with mercurial (i.e. HG) you don't have that problem
21:35:34 <Rubidium> avdg: you made a clone of the whole SVN repository and made a checkout from there?
21:35:57 <ABCRic> It's done, now let's see where the split is...
21:36:11 <avdg> I have a git checkout, but it has no tags :p
21:36:12 <Rubidium> cloned implies using HG or git
21:37:47 <ABCRic> Revision 19142 by Rubidium
21:37:49 <ABCRic> "[1.0] -Branch: the 1.0 series"
21:38:14 <ABCRic> Let's try and blame it again...
21:38:46 <avdg> more then 50 commits for rail_cmd.cpp since the 1.0 series
21:39:00 <Terkhen> bisecting is always fun :)
21:39:28 <avdg> so we have all reasons to blame that file :)
21:39:40 <ABCRic> Check for changes to lines 326, 384, 460 and 2793
21:40:32 <ABCRic> line 329 was changed, it's right before the line spawning the message
21:41:55 <ABCRic> Was changed at r20110 by alberth
21:42:00 <ABCRic> with message "-Fix [FS#3695]: Do not allow building a rail track to the water using a tree-tile."
21:42:50 <ABCRic> Nah, I don't think that helps.
21:43:01 <ABCRic> It's a fix, so I suppose it's present on stable.
21:43:28 <Terkhen> not all fixes are backported
21:43:36 <ABCRic> In any case, trac is really useful.
21:43:58 <ABCRic> Terkhen: I know, I'm checking if it was backported now
21:46:37 <ABCRic> How can I check when was the last time a specific line was changed?
21:46:52 <ABCRic> it might have been backported after 1.0.3...
21:47:13 <avdg> well, I think the fastest way to find out is by testing
21:47:23 <avdg> we have lets say < 60 patches
21:47:47 <avdg> and we know the bug is introduced somewhere between it
21:48:13 <avdg> thats how to test without looking in the source :p
21:50:00 <ABCRic> or I could checkout the file from the branch and look at the log.
21:50:16 <avdg> the error isn't in the branche
21:50:28 <avdg> else the error would been there too
21:51:17 <ABCRic> now I've completely lost my train of thought...
21:52:49 <avdg> never used git at full capacity
21:53:00 <ABCRic> regained control, regained control.
21:53:33 <ABCRic> what I'm saying is: the fix could have been backported after 1.0.3 was released
21:53:40 <Rubidium> @calc log(20715-19142)/log(2)
21:53:40 <DorpsGek> Rubidium: 10.6193029554
21:53:59 <avdg> :p my math isn't that good anymore
21:54:01 <Rubidium> should give 11 test cases and then you've nailed it to a single commit
21:55:16 <ABCRic> If so, the bug is not present in 1.0.3 but might be in a future stable...
21:55:33 <avdg> rubidium: you blowed me away again :p
22:02:56 <avdg> hmm.. is too afraid to test it
22:05:07 <ABCRic> Done checkingout, now blame the file since 1.0.3...
22:06:54 * avdg still has to find the git commit to start with
22:07:53 <Rubidium> although if you've reduced the number of suspects to 60...
22:07:56 * avdg hatest git - at least because it doesn't support revision numbers
22:08:02 <Rubidium> @calc log(60)/log(2)
22:08:02 <DorpsGek> Rubidium: 5.90689059561
22:08:09 <Rubidium> only 6 tests are needed
22:10:23 <ABCRic> - Fix: Do not allow building a rail track to the water using a tree-tile [FS#3695] (r20110)
22:10:25 <ABCRic> Backported at r20148...
22:10:26 <ABCRic> Which means it is present in 1.0.3.
22:10:38 <ABCRic> back to the drawing board...
22:11:01 <avdg> I tested it in the latest branche release
22:11:20 <avdg> so I bet it isn't in the stable
22:12:39 <avdg> I tested it in 1.0.4-rc1
22:12:54 * ABCRic 's brain is probably on fire
22:13:30 <ABCRic> What I meant was that the code was present it 1.0.3, not the bug
22:14:08 * Rubidium ponders taking a stab at it
22:14:09 <avdg> -_- *hits hisself with a big trout*
22:15:09 <avdg> hmm.. git commits doesn't include the revision number -_-
22:15:16 <ABCRic> Which means that the fix has nothing to do with the bug.
22:15:29 <ABCRic> And, as such, we're back to where we started...
22:16:07 <avdg> just give me the damm hash and I'll find it :p
22:16:59 <ABCRic> Meh... I'm going back to the game I was workin' on... managing some trains for a change...
22:17:12 <ABCRic> I mostly use road vehicles...
22:21:20 <avdg> I was already thinking at it
22:21:28 <Rubidium> now... how long will it take before you know what revision caused it
22:21:53 * avdg blames hisself being slower then a turtle
22:22:21 <Rubidium> there, know the revision now as well :)
22:24:02 * avdg has to learn a lot more scm commands -_-
22:28:55 <avdg> :p I'm now at my first step
22:32:25 *** Brianetta has joined #openttd
22:46:15 <ABCRic> Let there be many cargo on your vehicles.
22:47:12 <michi_cc> avdg: try "git gui blame src/rail_cmd.cpp", very nice tool.
22:47:14 <ABCRic> more cargo means more profit!
22:47:49 <ABCRic> or, well, more revenue.
22:47:55 <avdg> I know already of the gui, but didn't know that I could go deeper
22:48:01 <ABCRic> which *usually* means more profit.
22:52:09 <michi_cc> avdg: Clicking on the revision on the left let's you see the file at that rev. If you think that revision wasn
22:52:39 <michi_cc> 't the culprit, right click and do blame parent to get the earlier changes for the part in question.
22:54:25 <Rubidium> this bug is (way) easier to find if you've got a clue what recently changed *or* when you use bisect
22:54:31 <Rubidium> as it's not in rail_cmd.cpp
22:54:32 <avdg> git bisect was the best option here
22:55:35 <michi_cc> Of course, blame can do much, but certainly not everything :)
22:56:28 <avdg> well, testing is more fun (—without-compile)
22:57:22 <Rubidium> avdg: then you need to know what recently changed
22:58:22 <Yexo> oh, if you're also looking at FS#4103 then I'm doing double work
22:58:50 <Rubidium> Yexo: I'm not spoiling his pleasure in trying to find the bug
22:59:00 <Yexo> then I'll not do that either :)
22:59:11 <Rubidium> Yexo: you've found it already?
22:59:58 * avdg hates that gcc isn't using its cache
23:02:13 <avdg> well, it doesn't always compile the 3th party files
23:03:13 <Rubidium> that's just make determining what has dependencies that changed
23:08:10 * avdg wants a more powerfull cpu...
23:09:11 <Rubidium> nah, you just need a fast GPU and use CUDA or something like that :)
23:14:39 <CIA-2> OpenTTD: yexo * r20716 /trunk/src/ (5 files in 2 dirs): -Feature: add airport class and airport name to the land info tool
23:15:10 <avdg> hmm.. so the code is getting more and more oop?
23:15:48 <Yexo> only in those places where it makes sense
23:16:30 <avdg> where things are getting too complicated… I see
23:22:39 * Rubidium says good night and good luck committing the fix :)
23:26:39 <Eddi|zuHause> i see... the channel splurts over from ... "competence" today
23:27:06 <SmatZ> hmmm... the LTO problem...
23:29:11 <SmatZ> ... reminds me of my gf, while she was laughing a lot ...
23:41:04 <Yexo> avdg: do you want to keep looking for the bug? I have a fix ready I can commit now, but if you want to keep looking I'll commit it tomorrow instead
23:41:53 <avdg> I think I got the commit but I keep the tests running
23:42:09 <CIA-2> OpenTTD: yexo * r20717 /trunk/src/ (saveload/afterload.cpp station_map.h): -Fix [FS#4103]: water class was not set for stations
23:42:16 <Yexo> the wrong commit was r20446
23:42:51 <Yexo> and now it's also for me time to sleep
continue to next day ⏵