IRC logs for #openttd on OFTC at 2008-07-22
⏴ go to previous day
00:00:22 *** ProfFrink is now known as Prof_Frink
00:16:43 *** izhirahider has joined #openttd
00:20:49 *** fmauNeko is now known as fmauNekAway
00:34:12 *** Eddi|zuHause3 has joined #openttd
00:35:12 *** Sacro1 is now known as Sacro
00:35:57 <dasy2k1> are thease new pbs like signals in the wiki somwhere?
00:45:59 *** Osai^zZz is now known as Osai
01:11:43 <rortom> anyone want to test the bot? :)
01:12:26 <Eddi|zuHause3> at three in the morning?
01:13:05 <fjb> Hmmmm, MB needs an OpenTTD desensitisation. Somebody should give him a prescription to play only OpenTTD for at least 6 months.
01:23:02 <Eddi|zuHause3> why? did he say anything?
01:23:54 <fjb> Just read the gernam forum. Or better don't.
01:26:52 <dasy2k1> gah, this new PBS sousent work
01:27:26 <dasy2k1> it reserves a path right into another train
01:29:06 <fjb> dasy2k1: That never happened to me. Did you apply the patch to trunk and compile it yourself or did you use one of that strange patch packs out there?
01:29:41 <Eddi|zuHause3> dasy2k1: did you mix normal and "advanced" signals?
01:29:51 <Eddi|zuHause3> or did you even hit the "ignore signal" button?
01:31:19 <rortom> got the openttd forked?
01:31:50 <dasy2k1> fjb: using the rrcp patch pack, and no mix and no ignores
01:31:51 <glx> I'm not aware of any fork
01:32:31 <Digitalfox> Wow so much hate from MB against Open :(
01:33:07 <rortom> i thought there was one ...
01:33:08 <fjb> dasy2k1: The new PBS signals are known to not work in any of that big patch packs.
01:33:15 <Digitalfox> While I used a online translator, much was nice translated, so what a hate guy..
01:33:20 <rortom> @glx: you want to continue to fix some protocol with the bot?
01:33:31 <fjb> Digitalfox: It is really sad.
01:34:32 <Eddi|zuHause3> i don't read "hate" out of his posts there...
01:34:53 <Digitalfox> fjb but I don't get why.. I mean patch isn't dead or will die because of open, also no one forces him to use it.. So why does he hets so angry about open..
01:34:59 <fjb> But he strongly dislikes the OpenTTD project.
01:35:16 <Eddi|zuHause3> he has some more or less valid arguments
01:35:18 <Digitalfox> Eddi|zuHause3 please, you know very well the feeling mb has for open
01:36:06 <Digitalfox> Eddi|zuHause3 yes he may have some valid arguments, but the way he express them, please that's ....
01:36:52 <fjb> I gues he feels betrayed. He once stated the he gave most of the ideas how to extend TTD too the TTDP team. Now OpenTTD implemented the thing he came up with.
01:36:54 <Eddi|zuHause3> it's a "which is better?" discussion... it can only be a flamewar...
01:38:06 <Eddi|zuHause3> fjb: a) you can't patent an idea, and b) TTDP is open source, everybody can take it and do what he wants with the features
01:38:19 <fjb> And OpenTTD is not implementing everything as he would like it to be implemented.
01:38:20 <dasy2k1> hmm cant repeat the crash
01:38:42 <fjb> Eddi|zuHause3: Don't tell me. MB stated that once.
01:39:13 <fjb> dasy2k1: The patchpack you are using is broken.
01:39:27 <Digitalfox> The thing is, IMHO I now see old patch artists producing graphics for open, and I guess MB never will accept that..
01:40:02 <DaleStan> dasy2k1: In whatever way is necessary to cause that behaviour.
01:40:05 <Digitalfox> It's like NewGRF is a thing of patch and open can't have NewGRF just for it..
01:40:33 <fjb> dasy2k1: YAPP (the new PBS signals) are not working as expected, and not working as trunk with only the YAPP patch.
01:40:36 <Digitalfox> So yeah I think he is more pissed than ever, because of all the stuff that has been done in Open graphics section..
01:41:16 <Digitalfox> Also Zephryis posting a set on patch graphics section that doesn't work in patch.. lol I imagine what MB must have felt..
01:41:18 <dasy2k1> well i found out what had caused my crash
01:41:42 <DaleStan> It's like NewGRF is a thing of patch and open can't have NewGRF just for it.. <-- Remind me again how many times people have tried to convince the Open devs to choose a format other than GRF/NFO?
01:41:46 <Digitalfox> But anyway this is very of topic.. So have a nice night everybody
01:42:09 <fjb> But the other artists are not working for OpenTTD alone, they are working for both projects. And even the developer teams of both projects are working together.
01:42:31 <Eddi|zuHause3> DaleStan: XML!!11!!!1einundelfzig
01:42:32 <DaleStan> Not that I ever thought it was a good idea. Nor that I ever expected it to work.
01:43:04 <dasy2k1> i had 2 signals pointing the wrong way so there was no protection for a train leaving the station as one was comming in
01:43:06 <fjb> I only say that self modifying code is a very bad idea.
01:44:05 <fjb> dasy2k1: Did you modify the signals while the trains were in that signal block?
01:44:17 <Eddi|zuHause3> fjb: you really don't want to know what some compilers could make of your code :p
01:44:19 <glx> self modifying code is nice (I used that on my TI85)
01:44:26 <Digitalfox> DaleStan IMHO if when Newgrf support was first thought if should be implemented in open and there was someone with a better idea of a new format, yes I think it could had been a good idea.. But now I don't think it would be a good idea..
01:44:45 <dasy2k1> possably i may have done, cant remember
01:45:08 <fjb> Selfmodifying code makes the construction of a compiler diffiicult.
01:45:38 <DaleStan> Digitalfox: No, it was never a good idea. Choosing a different format would have meant willfully breaking with all the existent graphics sets.
01:46:25 <DaleStan> fjb: NASM doesn't seem to have much trouble turning the TTDPatch code into object files. :p
01:46:32 <Digitalfox> DaleStan don't get me wrong I'm not saying theres a problem with NewGRF presently and how it works.. I just mean a format easier to work with..
01:46:43 <dasy2k1> BIngo repeated my crash
01:46:52 <dasy2k1> without modifying signals
01:47:28 <Eddi|zuHause3> fjb: why? in the compiler you can always choose to not use that feature
01:48:00 <Eddi|zuHause3> or only use the feature in very limited ways (in this case, variable [parameter] assignment)
01:48:00 <fjb> DaleStan: NASM is just an assambler. And I didn't speak about you assembler code, I spoke about some selfmodifying nfo actions.
01:48:19 <Eddi|zuHause3> NFO is basically an assembler
01:48:30 <glx> fjb: it's like a static variable
01:48:41 <DaleStan> Oh, never mind then.
01:48:53 <DaleStan> <Eddi|zuHause3> NFO is basically an assembler <-- If that.
01:49:34 <fjb> NFO is machine language. But the selfmodifying nature of some actions makes it harder to write a compiler for an higher level language which produces nfo code.
01:49:58 <Eddi|zuHause3> fjb: i could prove you wrong, but i have not enough time
01:50:01 <glx> you're not forced to use this action
01:51:03 <fjb> glx: How do you read the options of the grf without using selfmodifying code?
01:51:29 <Eddi|zuHause3> really, the only place you can sensefully use that action is expressions with variables, and there you can do some basic code layouts that model it
01:52:51 <fjb> Eddi|zuHause3: Ofcourse you can do things like that. But that makes making the compiler more difficult. You can do almost everything with enough time.
01:54:11 <Eddi|zuHause3> that is hardly a problem at all [when speaking of a high level language like NDL]
01:54:55 <dasy2k1> http://tinyurl.com/6o76bk shows the problem, train 1 will reach the end of the line and reverse not caring that train 2 has allready blocked the path
01:55:06 <glx> grf parameters don't need self modifying code, but they can be used when modifying other actions
01:55:20 <fjb> NDL is your language that gets translated to NFO?
01:55:42 <DaleStan> As long as it's a true compiler, as opposed to an assembler, there's no problem not with just failing to tell the compiler that action 6 exists.
01:55:54 *** Digitalfox has joined #openttd
01:56:03 <glx> dasy2k1: try with the latest YAPP version (which is not in any patch pack)
01:56:29 <Eddi|zuHause3> fjb: there's a forum thread somewhere
01:58:05 <fjb> Eddi|zuHause3: And the compiler is in a fully working state so that it can be used to develop full featured GRFs?
01:58:40 <Eddi|zuHause3> fjb: no, as explained in the thread the compiler can generate action 0 and action 1/2/3
01:58:47 <fjb> And how do you acces the GRF parameters without using action 6?
01:58:50 <glx> it's possible to have a grf working the same without action 6, it just needs more actions
01:59:03 <Eddi|zuHause3> i started to add varaction2 support, but i ran out of time
01:59:15 <glx> fjb: action 7, 9, D, varaction 2
01:59:58 <DaleStan> Varaction 2 variable 7F, specifically.
02:00:03 <Eddi|zuHause3> also, the compiler can only handle trains (feature 0), but that is rather trivial to extend
02:01:16 <fjb> Thank you. i will have a closer look to that actions.
02:01:55 <dasy2k1> is there a subversion command for regressing to a version?
02:02:13 <Eddi|zuHause3> dasy2k1: svn up -r XXXX
02:09:51 <fjb> Eddi|zuHause3: I found your thread. Who tried to convince you to use XML sytax for an programming language?
02:09:57 <rortom> what could be the reason that MP games tend to get unstable after some playing?
02:10:26 <Eddi|zuHause3> fjb: that was a preliminary statement, to not get such requests in the first place :p
02:10:45 <dasy2k1> glx: hmm, yes, the train stopps on the clean version
02:11:01 <dasy2k1> i will put it in the patchpack thread as a bug
02:11:27 <fjb> dasy2k1: That is why I'm calling the patchpack broken.
02:11:28 <glx> rortom: maybe some bugs (some fixed in 0.6.2-RC1)
02:11:37 <Eddi|zuHause3> fjb: it's a very long running and occasionally recurring discussion to use XML as a modding format instead of GRF
02:12:07 <fjb> XML is a bad idea if you have to type the code by hand...
02:12:46 <fjb> People demanding XML never for that purpose never used it.
02:12:51 <glx> better write NFO than XML :)
02:13:13 <fjb> Hm, it's almost on the same level...
02:13:28 <glx> you need to type a lot much in XML
02:13:47 <fjb> It can have strange effects on people...
02:14:33 <dasy2k1> anyway i need to go to bed!
02:14:40 <fjb> But typing to many hex codes is unhealthy.
02:16:03 <glx> with a "sane" code style NFO is not hard to read or write
02:17:39 <fjb> Surly you can get used to it when coding NFO regularly. But it is hard for somebody occasionally doing that.
02:18:32 <glx> I don't code NFO often, but I'm able to write test grfs when I need one
02:18:57 <fjb> And no bigger software project gets done typing hex codes today. At least some kind of assembler is used.
02:19:12 <DaleStan> <peter1138> there is a reason it's not in xml
02:19:12 <DaleStan> <peter1138> anyone who takes the time to fully understand the system so they can write an xml structure realises it's not worth it
02:20:10 <fjb> XML has its uses, but not as a programming language.
02:20:24 <glx> and that's true for most xxx->XML stuff
02:22:10 <fjb> I wouldn't say that. You can do really nice things with XML. But as always you have to use the right tool at the right time.
02:23:21 <glx> yes for sharing datas it's nice
02:25:44 <glx> but only for new stuff (if an old stuff uses a working "binary" format to share data, I don't see the need to "upgrade" it to xml)
02:26:10 <fjb> Or for describing documents. Or as a transfer fomat from one format into another.
02:27:21 <glx> that reminds me people suggesting to use xml for openttd savegames :)
02:28:29 <fjb> Yeah, that would make savegame hacking much easier. Updating all your vehicles without starting the game. :-)
02:29:13 <glx> yeah imagine a 2048*2048 network savegame to send to clients ;)
02:30:58 <glx> even compressed, the xml format will increase the size
02:31:30 <fjb> Oh, that is not really a problem. You can easily shorten the identifiers on the fly using XSLT...
02:32:29 <fjb> Not that that approach would be really usefull...
02:32:35 <glx> but as xml is a text format, a 32bits integer will use way more space
02:33:05 <fjb> Just express them as hex codes. :-)
02:33:34 <glx> even that way you double the size
02:34:08 <rortom> who wrote the first ottd MP code?
02:34:28 <glx> it's pre-r1 but I think TB did
02:35:10 <rortom> we are thinking of going to use raknet for RoR :\
02:38:05 <fjb> Then be sure not to put RoR under GPL...
02:43:04 <rortom> i thought the license is fine?
02:44:42 <fjb> GPL extends to everything you are linking to your prject.
02:45:31 <fjb> And raknet has its own license. That would get replaced by the GPL. I don't think the licence of raknet allows that.
02:46:25 <glx> raknet has many licences it seems :)
02:46:44 <rortom> yes the one above and a commercial one
02:47:03 <fjb> Does it also have the GPL? I didn't see that on their website.
02:47:35 <rortom> we are still searching a fitting license for RoR :/
03:35:47 *** dlunch_ has joined #openttd
03:41:56 *** dlunch_ is now known as dlunch
05:49:10 *** DJNekkid has joined #openttd
05:58:15 *** einKarl has joined #openttd
06:26:53 *** ChanServ sets mode: +v tokai
06:56:17 *** ProfFrink has joined #openttd
07:01:01 *** ProfFrink is now known as Prof_Frink
07:12:47 <blathijs> SmatZ: Or was it a registered channel?
07:29:18 <peter1138> Celestar, have you finished it yet? ;)
07:29:59 *** NukeBuster has joined #openttd
07:44:43 *** GoneWacko has joined #openttd
07:45:14 *** Brianetta has joined #openttd
08:12:48 *** stillunknown has joined #openttd
08:24:50 *** mucht_work has joined #openttd
08:39:15 *** Vikthor has joined #openttd
09:00:18 <Celestar> peter1138: finished with what?
09:00:23 <Celestar> I was sitting a stupid meeting
09:01:14 <Celestar> peter1138: just poke me when you've got time
09:17:26 *** ChanServ sets mode: +v tokai
09:24:34 *** fmauNekAway is now known as fmauNeko
09:27:30 *** De_Ghost has joined #openttd
09:38:53 <GoneWacko> A friend of mine recently mentioned something he felt was missing from OpenTTD, and I'm wondering if it's maybe already a feature or if it's in the current source tree; Basically he wonders why the Level Land tool can't make diagonal paths (i.e. through hills)
09:45:33 <GoneWacko> Well I don't really follow OpenTTD development that closely :-o
09:45:38 <GoneWacko> that's what I wanted to know
09:54:22 *** Doorslammer|BRSet has joined #openttd
09:54:33 *** Progman has joined #openttd
09:55:58 <dih> i actually thought it was amusing to point a moderator to his own forums :-P
09:57:58 <GoneWacko> The OpenTTD specific moderators do a pretty good job so I don't really need to venture there unless I'm looking for something specific
09:58:19 <GoneWacko> if I ever decide to pick up OpenTTD developing again then I'm sure I'll be more up to speed :p
10:00:41 <Celestar> peter1138: I've got a problem :P
10:06:33 *** Doorslammer|BRSet has quit IRC
10:09:59 <CIA-3> OpenTTD: truebrain * r13778 /branches/noai/ (14 files in 3 dirs): [NoAI] -Add: added AIIndustryType, allowing you industry access by type (Yexo)
10:10:16 <CIA-3> OpenTTD: truebrain * r13779 /branches/noai/projects/ (openttd_vs80.vcproj openttd_vs90.vcproj): [NoAI] -Fix r13778: MSVC projects
10:11:10 *** Doorslammer|OTTD has joined #openttd
10:19:15 <Celestar> peter1138: I'm still lacking an idea on how to deal "non-non-stop" things. but I'll just skip them for the time being
10:19:50 <Noldo> Celestar: what are you doing?
10:19:58 <peter1138> Yes, skip those for the moment, I'd say.
10:20:11 <Celestar> peter1138: basically, when orders are modified, a network is 'drawn', so each station knows what other stations can be reached by a very simple pathfinding process (Dijkstra or something)
10:20:59 <peter1138> That was what I had in mind. It may be possible to add the non-non-stop connections to that network. The network would then need to be saved, however.
10:21:15 <blathijs> Celestar: What are you discussing?
10:21:29 <Noldo> seems like passanger destinations
10:21:34 <Celestar> we can still add them later. I think for a first shot, we need no non-non-stops nor do we need different speeds (i.e. aircraft vs trains or so)
10:21:56 <peter1138> Yes, costs can be added later, I think.
10:22:34 <blathijs> Ah, passengers shouldn't want to go somewhere that's not reachable?
10:22:59 <blathijs> And adding transfers (that's what you mean by non-stop I think?) to the equation adds complexity :-)
10:23:16 <Celestar> blathijs: Transfers are instrisic :)
10:23:17 <peter1138> blathijs: non-non-stop is the stations that a train visits that are not on its schedule.
10:23:40 <peter1138> If you built up a network map directly from orders then they do not get included.
10:24:26 <Celestar> peter1138: the question is how to generate passengers. One idea of mine (for passengers/mail) was: Houses generate two types of passengers: local (same town) and non-local (per city. Amount by city distance and size). The non-local passengers are then split to the different target stations per city.
10:25:12 <ln> 13:21 < Noldo> seems like passanger destinations <-- English only
10:25:28 <Celestar> peter1138: this would result in fractional passengers, which could be rounded down ..
10:25:52 <peter1138> Hmm, if you say that larger towns receive more passengers then larger towns automatically get more local traffic than smaller towns.
10:26:15 <Celestar> peter1138: well, London has more local traffic than Nottingham, right? :)
10:26:56 <Celestar> that was the idea behind it
10:27:06 <peter1138> I don't actually know, but with that rule you get more people going to big towns than to small towns.
10:27:11 <peter1138> Which makes sense to me.
10:27:23 <Celestar> so each station has p passengers to station s, q passengers to station r, and so on
10:27:37 <Noldo> also more people going out of large towns
10:27:53 <Celestar> and towns who are better connected also produce more passengers
10:28:11 <peter1138> Noldo: that's already handled by passenger generation.
10:30:17 <Noldo> the situtation is not symmetrical if the destination is by town/city and generation is by house
10:30:39 <peter1138> Does it need to be symmetrical?
10:30:54 <Celestar> Noldo: Destination is by town/city which is by sum over houses. So it is symmetrical
10:31:00 <peter1138> Indeed, that too :)
10:31:18 <Celestar> peter1138: the question is this: when does the 'pathfinding' start: When a cargopacket is about to be boarded or when it is generated (which would need re-assessing if the network changes)
10:31:31 <Noldo> only if all houses are on some station's area
10:31:53 <Celestar> Noldo: destination is by houses in town which are in some station's area :D
10:32:08 <Celestar> each station would need to keep track of it's population. That's easy to do.
10:32:38 <peter1138> Well if there's no station in a town then don't generate passengers for there.
10:32:58 <Celestar> peter1138: I *think* by boarding would be better. Then we can merge identical packets before boarding, reducing the total number.
10:33:10 <Noldo> so destination is actually by station?
10:33:33 <Celestar> Noldo: destination is actually by station. But 'station' depends on population in station's catchment area
10:34:05 <Noldo> ok, now it's starting to work :)
10:34:22 <Noldo> only if there was a coding machine that could code as we speak
10:36:12 <Celestar> peter1138: the question is what to do with the fractional passengers we (might) generate.
10:37:10 <Celestar> we could use fixed-point arithmetic however.
10:37:29 <Noldo> are they always something like x/8
10:38:02 <Celestar> Noldo: that's the acceptance
10:39:06 <Celestar> Noldo: I'm talking about this: Say a house generates 23 passengers: how to devided them about the destinations? We could just devide the proportinally (which will result in fractions), by random number, or weighted round-robin.
10:40:17 <blathijs> peter1138: But, when a station is not on a train's schedule, it can't be guaranteed to visit it, right?
10:40:37 <Celestar> blathijs: I think we can deal with that later.
10:41:07 <blathijs> My hunch would be to not deal with that, just limit to order destinations
10:42:11 <Noldo> could there be somekind of auto add to schedule
10:42:49 <Noldo> there might be some city local tram routes that are easy to set-up with just two orders
10:43:00 <Celestar> Noldo: the auto-add is no problem. The problem is auto-remove
10:45:01 <Celestar> peter1138: ok. how do we try this: make a branch, or play in trunk? :P
10:58:31 <Celestar> peter1138: hm .. the route mapping doesn't influence anything else of the code ...
10:58:46 <Celestar> hm .. btw we have a working fixed-point data type
10:58:50 <Celestar> I just remembered :D
10:59:07 <Celestar> it's in the balance branch
11:00:55 <peter1138> I tried to figure out how to represent the network map, but I failed :(
11:02:07 <Celestar> peter1138: isn't there something usable in the stl?
11:05:08 <Celestar> we need some multi-associative thingy
11:06:04 <Celestar> we could use the BGL
11:06:33 <Noldo> you don't suffer from boost allergy then?
11:07:49 *** Brianetta has joined #openttd
11:08:28 <Celestar> I'm just reading through the documentation
11:08:46 <rortom> what has boost not? :p
11:08:51 <planetmaker> Celestar: got a link for me?
11:09:22 <rortom> is it for a tool or realtime?
11:10:08 <Celestar> peter1138: we could aslo write our on graphs
11:10:16 <rortom> i would like to see that working :D
11:10:47 <Celestar> but the BGL is pretty powerful
11:10:51 <Celestar> and it contains all the pathfinders
11:11:18 <planetmaker> Quick question: is there a heightmap of the map available or would I need to generate that, should I need one?
11:11:42 <rortom> planetmaker: waht are you doing, if i may ask?
11:11:52 <planetmaker> I try to place rivers
11:12:06 <peter1138> Well the height is stored in the map array...
11:12:30 <peter1138> TileHeight(tile) kind of thing, actually.
11:12:42 <peter1138> So you could just use the usual accessors for it.
11:12:53 <planetmaker> peter1138: yeah, for each tile. Actually what I need is a 2D array of height which I could use gradient filtering and smoothing on :)
11:13:06 * Celestar wonders where to find the BGL's license
11:13:17 <planetmaker> kinda global operations in order to get a good path.
11:13:38 <rortom> Celestar: i bet its the boost license?
11:13:38 <Celestar> BGL has an own license
11:13:39 <peter1138> Well you can generate that yourself.
11:14:03 <planetmaker> peter1138: yeah, I suppose so :). Just checking in order to not re-invent the wheel :)
11:15:05 <Celestar> so all we need to do is to include the License
11:15:30 <rortom> IIRC its a bit over BSD
11:16:02 <Celestar> it's not a showstopper, is it?
11:16:46 <planetmaker> to me it reads like "use and just tell you used it". Should be fine, eh?
11:17:40 <Celestar> how portable is the BGL?
11:17:56 <planetmaker> anyway, back to work :)
11:18:03 <Celestar> then again, paxdest will not work on your mobile for some years to come
11:18:11 * peter1138 is able to test with MSVC2008
11:18:28 <rortom> what are you going to do with BGL?
11:18:49 <Celestar> rortom: talking about paxdest
11:18:54 <peter1138> Routing of cargo packets.
11:19:16 *** Digitalfox has joined #openttd
11:19:20 * peter1138 wonders if Yapf can do the work.
11:19:57 <Celestar> peter1138: well yapf can do the pathfinding, but it needs a graph ..
11:20:29 <peter1138> Yeah, the representation is the issue.
11:20:43 <rortom> paxdest = passenger destinations?
11:21:32 <rortom> whats about the patch that is existing?
11:21:57 <Celestar> rortom: apart from the fact that you need a supercomputer to run it on a large map and that it doesn't work in MP?
11:22:11 <rortom> thats a killer argument
11:22:35 <rortom> also, is openttd now mixed c / c++?
11:23:05 <rortom> as i saw the new windowing system
11:23:07 <peter1138> Mixed, but it's all compiled as C++
11:24:06 <ln> some of it is Objective-C++
11:24:49 <peter1138> Yes, but nobody maintains that ;p
11:25:14 <DorpsGek> peter1138: bjarni was last seen in #openttd 2 weeks, 5 days, 15 hours, 17 minutes, and 21 seconds ago: <Bjarni> I didn't have any
11:26:01 <Celestar> peter1138: I could give the BGL a shot if you wish :)
11:27:22 <Celestar> hm .. we could use things like the MST to suggest network optimizations :P
11:27:51 <rortom> mhm what about the copy+paste tool patch?
11:27:59 <rortom> whats the reason its on hold?
11:28:13 <Celestar> wasn't that desyncing as well?
11:29:04 <rortom> so why does that happen if the code is for all the same?
11:29:18 <rortom> also, why has ottd no resync phase? :)
11:29:48 <Celestar> rortom: because we don'T have a client-server server
11:30:08 <Celestar> rortom: we have a system where the engines of all peers must be perfectly synchroized at any time
11:30:17 <Celestar> which includes the pnrgs
11:33:33 <rortom> so there is no way to identify the reason why something descyncs i guess?
11:34:00 <peter1138> There is; lots of testing.
11:34:15 <rortom> sure, but not direct indicators
11:35:28 <peter1138> A desync is a bug, therefore any desync should ultimately be fixed.
11:35:32 <rortom> also why are you all allergic against code documentation? :p
11:35:43 <peter1138> It documents itself ;)
11:37:13 <rortom> i tried to understand how map loading works ... :/
11:38:20 *** Singaporekid has joined #openttd
11:45:01 <peter1138> rortom, it's a basic RIFF structure ;)
11:45:14 <peter1138> There's a marker at the beginning for compression.
11:45:45 <rortom> *just* need to uncompress and then read the chunks i guess
11:45:58 <peter1138> Yes, *just* that :D
11:46:17 <peter1138> The chunks are described in their related code files.
11:47:23 <peter1138> In _*_chunk_handlers and _*_desc
11:47:47 *** ror_tom has joined #openttd
11:48:03 <ror_tom> 13:47:33| <@peter1138> In _*_chunk_handlers and _*_desc
11:48:05 <ror_tom> 13:47:34| * Disconnected
11:48:08 <ror_tom> did i miss something?
11:49:53 <peter1138> Anyway, the saveload code is very old, written before documentation existed.
11:52:57 <peter1138> Gah, bloody interest rates.
11:53:31 <bowman> hehe that got me reading about riff/aiff/iff
11:54:03 <bowman> had no idea that iff was a joint electronic arts/commodore creation
12:15:38 *** DJNekkid has joined #openttd
12:18:06 *** N1ghtCrawler has joined #openttd
12:18:54 <N1ghtCrawler> Hello, how do i "sell" the goods that the factorys produce?
12:19:14 <glx> send them to a town that accept them
12:19:26 <planetmaker> N1ghtCrawler: transport them to a station which accepts them. Towns do.
12:21:10 <N1ghtCrawler> ahh, it was just the towns near that did not accept them
12:25:02 <N1ghtCrawler> Damn good game, railtroads are tricky tho.
12:25:21 <Celestar> N1ghtCrawler: in what way
12:28:17 <Celestar> peter1138: shall I give BGL a try?
12:28:34 <N1ghtCrawler> Celestar: To co-ordinate everything, so they dont stuck
12:42:27 <Celestar> N1ghtCrawler: well. use YAPP :D
12:42:44 <CIA-3> OpenTTD: glx * r13780 /branches/noai/src/ai/api/ai_road.cpp: [NoAI] -Fix: AIRoad.AreRoadTilesConnected() returned true even if road vehicle could not go from tile_from to tile_to due to one-way road.
12:42:57 <DorpsGek> Ammler: SpComb was last seen in #openttd 15 hours and 58 seconds ago: <SpComb> ls -lahna
12:43:30 <Celestar> the boost documentation sucks a bit
12:43:42 <Ammler> SpComb: I am PMing with Oskar (alias eis_os)
12:43:50 <SpComb> <insert five pages of compiler error message templates>
12:43:54 <SpComb> Ammler: tt-forums PMs?
12:44:04 <Ammler> yes, do you understand german?
12:49:11 <Celestar> peter1138: when we store the graph in memory, do we optimize for speed or for space?
12:50:10 <Celestar> peter1138: or some compromise?
12:53:35 *** fmauNeko is now known as fmauNekAway
12:56:06 <rortom> just not sum'ed up or recorded :\
12:56:19 <rortom> still have to code recording
12:56:27 <dih> could you write those details to a sql db?
12:56:30 <rortom> was busy with the underlying python lib
12:56:38 <rortom> thats waht i woul do :)
12:56:47 <dih> and then for each run just add stats and fetch the average values
12:57:04 <peter1138> Celestar: Does it matter yet?
12:57:48 <peter1138> Hmm, what was the replacement for BindCString?
12:58:43 <Celestar> peter1138: well, not today ...
13:01:03 <dih> rortom, you have percentage of servers next to number of servers, but not for clients
13:01:08 <dih> that would still be a nice addon :-D
13:01:55 *** Prof_Frink has joined #openttd
13:03:51 <glx> peter1138: STR_RAW_STRING and SetDParamSomething (where you path the pointer)
13:04:59 <peter1138> Thanks. It just forced me to do the drop down list entry properly. :)
13:06:10 <glx> STR_JUST_RAW_STRING and SetDParamStr()
13:10:26 *** tom0004 has joined #openttd
13:11:20 *** fmauNekAway is now known as fmauNeko
13:15:22 <peter1138> Hmm, I need a better way of passing this list around :o
13:16:50 <Celestar> peter1138: what list?
13:20:00 <peter1138> A list of strings for GRF Presets.
13:20:02 <SpComb> Ammler: so what's with eis_os and german?
13:21:35 <Ammler> I asked him about using the Crawler for the GRF infos
13:21:59 <Ammler> as it is useless now, because about 40% isn't listed.
13:23:43 <peter1138> And you know whose fault that is...
13:24:44 <SpComb> there's two reasons for that
13:32:53 <Celestar> meh how do I include std::list?
13:34:34 <rortom> i built a grf crawler with those stats
13:34:43 <rortom> it should work well ...
13:35:27 <Ammler> [15:23] <peter1138> And you know whose fault that is... <-- it should become wikistyle, imo
13:35:53 <Ammler> some authors are just too lazy or don't care at all.
13:36:55 <peter1138> I have often thought of adding missing entries, but didn't because they're not mine.
13:37:32 <Ammler> yeah, and the entry belongs to you, so the owner can't alter if he likes after.
13:37:35 <peter1138> Right, that built :D
13:37:58 <peter1138> Haha, and that crashed :o
13:38:22 <Ammler> I like the way CIA does it
13:38:53 <Ammler> it is wiki style, but you can gain exclusive rights for your entries.
13:40:23 <peter1138> By "wiki style" do you actually mean "can be editted by anonymous people" ?
13:42:57 *** blathijs has joined #openttd
13:46:37 <SpComb> peter1138: you could use the tt-forums users database, just like GRFCrawler does
13:46:52 <Ammler> peter1138: well, possible but not needed, we do only allow registered users to edit, but more important is the versioning.
13:47:05 <SpComb> the second reason most GRFs are missing is because there's not a very large incentive for GRF authors to put their graphics there, not very many people will complain if they don't
13:47:30 <peter1138> Problem is GRF Crawler has not been used as a database of GRFs.
13:47:49 <peter1138> There are no separate entries for DOS vs Windows versions, for example.
13:48:14 <Ammler> there is for filename, not for download
13:48:18 * SpComb shall continue work on his GRF-downloader tonight
13:49:29 <Ammler> SpComb: they should be saved in a format not useable for single palyer :-)
13:51:13 <Yorick> are revisions 13775 and 13776 ported 0.6?
13:51:21 <Ammler> peter1138: if grfcrawler doesn't do it, we (openttdcoop) will create such repo, maybe...
13:52:29 <Ammler> or would openttd.org do it officially?
13:54:11 <peter1138> Well we've always said we won't do automatic downloading, so that's probably unlikely.
13:54:46 <SpComb> I wouldn't set that decision in stone yet, too many unresolved questions
13:55:03 <SpComb> nobody's proved that it's impossible
13:55:34 <Yorick> I don't think it's very hard to do either
13:56:11 <SpComb> well, it is, it's a complicated matter, and implementing it in a satisfactory way so that it becomes succesfull isn't trivial
13:56:59 <Yorick> we already have a list of newgrfs by server
13:57:07 <Yorick> just a search facility by md5sum
13:57:07 <planetmaker> [15:55] <Yorick> I don't think it's very hard to do either <- the most difficult part is to actually *do* it.
13:57:10 <SpComb> it's a complicated question, and any implementation is going to be pretty useless unless it's integrated into OpenTTD trunk
13:57:16 <planetmaker> Principally I could build a settlement on Mars...
13:57:18 <SpComb> Yorick: yes, that part is easy, and I've already done it, look at my screenshot
13:57:47 <SpComb> it doesn't actually download the .grfs yet, but it does get a list of URLs to them
13:58:02 <peter1138> SpComb, the reason for not doing it was not technical.
13:58:26 <peter1138> Okay, Yorick, the reason for not doing it was not technical.
13:58:27 <Ammler> peter1138: not the download repo
13:58:48 <Yorick> peter1138: no, it was at the licensing side
13:59:03 <Yorick> what if only authors that do not mind upload the grfs to the repo?
13:59:05 <SpComb> the licensing side and the opinions of the NewGRF authors
13:59:06 <peter1138> Ammler: it's fairly easy to just store every GRF ever, by GRF ID and md5sum...
13:59:12 <Celestar> planetmaker: if you do, please poke me, I'll help
13:59:54 <planetmaker> With a one-way or with a return ticket, Celestar? ;)
14:00:05 <Celestar> planetmaker: honestly? not sure yet :P
14:00:16 <Celestar> depends on whether $GF plans to join or not, I guess
14:00:34 <Ammler> peter1138: indeed, I thought about that.. (renaming all GRFs in the pack)
14:00:49 <Ammler> but I fear, some authors wouldn't like that)
14:01:17 <Celestar> do we have plans to put yapp in trunk at some point?
14:02:09 <planetmaker> Celestar: I hope :P
14:02:14 <Ammler> Yorick: I guess, he means we=devs
14:02:46 <planetmaker> I hope it was bad timing and he agreed with you, Ammler :)
14:02:49 <Yorick> Ammler: peter1138 claimed to fix & commit it after test round by (I forgot)
14:03:11 <Yorick> and I agree with Ammler
14:03:18 <Ammler> btw, you might edit the roadmap, is looks almost empty
14:03:42 <peter1138> That was kind of a joke...
14:04:02 * planetmaker thinks peter1138 is a funny guy :)
14:04:37 <Ammler> also the dynmaic engine pool could added, so you have something almost done...
14:05:12 <Celestar> > bin/openttd -snull -d routenetwork=2
14:05:14 <Celestar> dbg: [routenetwork] Vertex added to route network
14:06:09 <Ammler> you mean cargo dest :-)
14:06:34 <Ammler> but that one is too risky
14:07:23 <Yorick> hmm...I forgot what I was doing
14:07:38 <Celestar> Ammler: what is too risky?
14:07:41 * Yorick codes a company list in python
14:07:55 <Ammler> adding destination to the roadmap :-)
14:08:32 <Celestar> peter1138: I'm currently assuming that a vehicle 1) can reach all stations on its schedule and 2) does reach all stations on its schedule (i.e. no skipping by conditionals for now)
14:11:10 <peter1138> Ammler, actually we don't really care about road maps :P
14:16:42 <Ammler> well, but it would look nice for "outsiders"
14:17:25 <Ammler> not everyone is here all the time...
14:17:41 <CIA-3> OpenTTD: peter1138 * r13781 /trunk/src/ (5 files in 3 dirs): -Feature: NewGRF presets, selected by a drop down list in the NewGRF window. Presets are saved in the config file.
14:17:53 <planetmaker> [16:16] <Ammler> well, but it would look nice for "outsiders" <-- I agree
14:18:54 <planetmaker> It gives the first-hand impression of a busy community - wether you care about the roadmap or stick to it doesn't matter too much as long as there's at least some correlation
14:19:51 <Ammler> Celestar: are you still working on balancing?
14:19:58 <Ammler> isn't that a GRF issue?
14:23:14 <Ammler> you had a really nice (and working) roadmap for 0.6
14:23:52 <rortom> mh what about the grf crawler?
14:24:04 <rortom> i can built one with the stats im gathering
14:24:31 <Ammler> we spoke about the database
14:25:01 <rortom> i heard it was not working or so?
14:25:24 <Ammler> well, not ALL GRFs are listed
14:25:54 <Ammler> you can't do that automatically...
14:25:55 <rortom> mhm we can enhance the crawler with my stats info
14:26:18 <Ammler> yeah, that would be nice
14:26:20 <SpComb> rortom: do you have more info about your stats somewhere?
14:26:33 <SpComb> I gather you wrote a python script to connect to OpenTTD servers and do... stuff?
14:26:45 <Yorick> SpComb: #openttd-python
14:27:01 <SpComb> "Firefox can't find the server at www.ottdserver.de."
14:27:35 <Yorick> he wrote a script that can connect to openttd servers and do... stuff
14:28:38 *** XeryusTC was kicked by DorpsGek (Wrong channel. Retry in #openttdcoop.)
14:28:38 *** XeryusTC has joined #openttd
14:31:19 <SpComb> OpenTTD archiecture bonus question, worth 5 points... is it possible to do async network stuff in the background while the GUI's running and responding?
14:31:45 <Ammler> there should be "one" repo for all GRFs, which can make stats about amount of downloads and used (at least on servers)
14:32:07 <Yorick> SpComb: depends on what you call 'responding'
14:32:10 <Rubidium> SpComb: the download map does that, doesn't it?
14:32:26 <Ammler> I guess, that is why some prefer downloading from tt-forums, to have the stats for downloads.
14:35:21 <Ammler> we now work really much on just keeping our GRF Table up2date, I would like to share that work... and replace the wiki page with a proper database
14:39:26 <Celestar> when I have "using namespace" at some point, can I terminate that, or does that run to end-of-file?
14:44:40 <Celestar> wow that was a killer :P
14:45:02 *** Doorslammer|OTTD is now known as Doorslammer|BRSet
14:46:35 *** ProfFrink has joined #openttd
14:46:56 <rortom> Celestar: AFAIK until EOF
14:47:19 <blathijs> Celestar: perhaps you can put { using namespace foo; .... } or something
14:47:30 <blathijs> not sure if you can randomly begin a new scope at global scope, though
14:47:32 <Celestar> blathijs: yeah, or just type std:: the three times :P
14:47:47 <blathijs> Celestar: Which you should be doing in the first place :-p
14:48:48 <peter1138> using namespace considered harmful
14:48:55 *** ProfFrink is now known as Prof_Frink
14:49:53 <Celestar> peter1138: just for info. the route map will need to be saved.
14:50:38 <peter1138> Normal price £699.95
14:50:43 <peter1138> Impressive reduction...
14:51:25 <peter1138> Who makes the best LCD TVs at the moment...
14:53:09 *** fmauNeko is now known as fmauNekAway
14:53:29 <ben_goodger> peter1138: if the quality of their LCD monitors are anything to judge by, you won't go far wrong with samsung...
14:54:57 <Celestar> peter1138: doing progress
14:55:42 *** ben_goodger has joined #openttd
14:57:03 <rortom> is the grfcrawler source code lying anywhere?
14:57:13 <rortom> also, it is just a user maintained database?
14:57:19 <orudge> rortom: grfcrawler is written by Oskar
14:57:22 <orudge> it's not open source as such
14:57:31 <orudge> users can submit GRF files to it
14:57:35 <orudge> it's linked in with the forum user database
14:58:20 <rortom> and would want to integrate :)
14:58:35 <rortom> also thanks for your effort with openttd :)
14:59:11 <orudge> Integrate it with what?
14:59:20 <Celestar> I don't understand std::map
14:59:21 <orudge> there's an XML API for grfcrawler
14:59:23 <orudge> if that's what you want
14:59:30 <Celestar> StationVertexMap.insert(std::pair<StationID, Vertex>(StationID(new_order.GetDestination()), Vertex()) );
14:59:34 <Celestar> why does this fail :S
14:59:37 * orudge uses it in the new Repository
14:59:51 <Ammler> [16:59] * orudge uses it in the new Repository ?
15:00:03 <orudge> well, the new Repository is still under development
15:00:45 <rortom> what is the new repository?
15:00:46 <orudge> returns details on the GRF files with the XMLIDs (separated by spaces) there
15:00:55 <orudge> It's the new version of the Ultimate Transport Tycoon Game Repository
15:01:20 <orudge> the new version can parse TTD and OpenTTD games to produce maps, get all sorts of details and statistics, and more
15:01:29 <orudge> it's also tidier, more organised
15:01:36 <Ammler> orudge: but also not the idea to have all GRF listed?
15:01:36 <orudge> it's just not quite finished yet
15:02:05 <Celestar> hylje: I'm trying to do this properly
15:02:11 <rortom> what if i create an automated service that collects all grf infos? :|
15:02:30 <hylje> people will hate you for stealing their property
15:02:31 <CIA-3> OpenTTD: glx * r13782 /trunk/src/train.h: -Cleanup: removed a useless declaration
15:02:35 <orudge> [16:01:42] <Ammler> orudge: but also not the idea to have all GRF listed? <-- what do you mean?
15:02:48 <orudge> the UTTGR will check for GRF files used in TTDPatch and OpenTTD games
15:02:49 <rortom> @ hylje: yes, that is what i was afraid of
15:02:50 <orudge> and give a list of the ones it knows about
15:02:55 <orudge> (checking its own internal database, and the Repository)
15:03:02 <Ammler> orudge: it won't be a replacment for GRFCrawler?
15:03:03 <orudge> *GRFCrawler, not Repository
15:03:13 <orudge> saved games, scenarios, etc
15:03:22 <orudge> although, you can upload GRF files if you want
15:03:27 <orudge> and then link to those from GRFCrawler
15:03:38 <rortom> mhm i should really code that grf repository
15:03:45 <Ammler> orudge: how will you handle GRFs which aren't listed there?
15:03:56 <Yorick> get their names from the servers?
15:03:59 <orudge> Ammler: well, at the moment, it just doesn't show them. Either that or it just shows the GRFID, can't remember.
15:04:04 <orudge> Yorick: it's nothing to do with servers
15:04:08 <orudge> it operates on saved games/scenarios
15:04:17 <orudge> rortom: well, the Repository can handle GRF files, as I say
15:04:37 <orudge> although its primary purpose is saved games, etc
15:05:28 <rortom> was auto grf download a topic ever?
15:05:29 <Ammler> so you will analyze saves, which settings and GRFs are used?
15:05:30 <hylje> GRFs come implicitly through saves
15:05:41 <orudge> I sent you a preview link, Ammler, privately
15:05:47 <hylje> rortom: yes, but people will hate you for stealing your property :-(
15:05:58 <orudge> look through the browse feature
15:06:04 <orudge> it'll be a bit slow, as it's on my ADSL connection
15:06:12 <hylje> some people get strange satisfaction through making people run through hoops
15:06:45 <orudge> the Repository goes into perhaps too much detail... every industry and town in every saved game is recorded ;)
15:07:52 * Celestar is the biggest idiot of the century
15:08:23 <Celestar> type a; b = something; if (a = something_else) ....
15:10:58 <hylje> that's why assignment-expressions are awesome
15:11:03 <hylje> think of the possibilities!
15:13:30 <Celestar> dbg: [routenetwork] Attempting to add vertex to route network
15:13:30 <Celestar> dbg: [routenetwork] Vertex added to route network for station 0
15:13:30 <Celestar> dbg: [routenetwork] Attempting to add vertex to route network
15:13:30 <Celestar> dbg: [routenetwork] Vertex added to route network for station 1
15:13:30 <Celestar> dbg: [routenetwork] Attempting to add vertex to route network
15:13:32 <Celestar> dbg: [routenetwork] Reusing vertex 0 for station 0. No vertex added
15:13:38 <Celestar> I'm going home. cu tomorrow :D
15:13:57 * peter1138 needs destinations :o
15:14:05 <Celestar> peter1138: it won't be finished today.
15:14:12 <Celestar> will resume tomorrow morningish
15:18:23 *** frosch123 has joined #openttd
15:19:35 <Eddi|zuHause3> <Celestar> peter1138: when we store the graph in memory, do we optimize for speed or for space? <- i'd say on halfway modern systems, speed is the bigger issue
15:20:06 <hylje> with a slider to configure
15:20:13 <Eddi|zuHause3> unless you're talking about handheld devices or something :p
15:20:17 <frosch123> compile time slider :p
15:20:34 <hylje> some people run OTTD with obsolete hardware
15:23:05 <DJNekkid> peter1138 and Celestar: are u guys trying to implement cargo destenations?
15:23:44 * DJNekkid jumps up and down and cant wait for a proper version of such
15:24:23 <DJNekkid> now paxdest in opencoop, that will be awsome :)
15:24:33 <DJNekkid> together with the 2cc set ;)
15:24:34 <hylje> we tried it back when it was hot
15:24:46 <DJNekkid> well, that was the patch thingy?
15:24:57 <DJNekkid> not something "proper" from the devs ;)
15:42:30 <CIA-3> OpenTTD: glx * r13783 /branches/noai/src/ai/api/ (6 files): [NoAI] -Add: added AIVehicle::IsArticulated() and AIEngine::IsArticulated()
15:43:02 <Eddi|zuHause3> <hylje> some people run OTTD with obsolete hardware <- still, as long as they have something above 8MB of RAM, speed is the bigger issue :p
15:43:21 <Eddi|zuHause3> and if they really have space issues, we just tell them to play smaller maps
15:57:49 *** fmauNekAway is now known as fmauNeko
16:13:48 * SpComb wanders through the exquisite maze of OpenTTD NewGRF code
16:13:55 <CIA-3> OpenTTD: peter1138 * r13784 /trunk/src/ (autoreplace_gui.cpp build_vehicle_gui.cpp): -Codechange: Truncate vehicle names in purchase list to width of window.
16:14:04 <SpComb> didn't your mother tell you that global variables are bad?
16:15:37 * Yorick wonders what SpComb is looking at
16:16:04 <SpComb> trying to figure out how I would be able to build a separate list of NewGRFs used for network clients
16:16:18 <SpComb> the list would also need to include GRFs from cache/*.tar, not just data/*
16:16:53 <Yorick> PACKET_UDP_CLIENT_GET_NEWGRFS ?
16:17:29 <SpComb> there's a set of .grfs in data/, and a set of .grfs in cache/
16:17:52 <SpComb> I want games where openttd is acting as a network client to also load grfs from cache/, but not other kinds of games
16:19:46 <Ammler> isn't it distributing, if you download the grfs just for network gameplay?
16:20:50 <glx> it is as you can easily copy grfs from cache/
16:21:37 *** Doorslammer|OTTD has joined #openttd
16:22:02 <SpComb> Ammler: yes, it is and will always remain distributing
16:23:23 <Ammler> there will be very fast howto's in the forums for "How to copy GRFs from cache to data..."
16:23:42 <SpComb> peter1138: well, I actually added a new "CACHE_DIR" to `enum Subdirectory`, I could have stuck them in data/cache, but then that would be distributing them for non-network games
16:23:50 <Eddi|zuHause3> you can add encryption ;)
16:24:07 <SpComb> Ammler: well, yes, it's perfectly possible to copy them from cache to data, it's just a `cp`
16:24:32 <SpComb> but this is just in the form of a safe default - I presume most NewGRFs would just be downloaded normally into data/
16:24:50 <peter1138> Implement a memory file system...
16:24:57 <SpComb> Eddi|zuHause3: "encryption" isn't an option worth discussing in this case
16:25:06 <SpComb> peter1138: and download the NewGRFs every time? Ugh
16:25:10 <Yorick> peter1138: yes, for the 8MB people?
16:25:31 <Ammler> still distributing... (also memory)
16:25:58 <SpComb> but it's mostly a question of what the intention behind the distribution is
16:26:19 <SpComb> iirc, PikkaBird said "only for network play" when he gave you permission to include his .grfs in the ottd grfpack
16:26:26 <SpComb> this is mostly with things like that in mind
16:26:50 *** Doorslammer|BRSet has quit IRC
16:26:56 <SpComb> "the purpose of the site is files for multiplayer (ie, it's not just a general repository of GRFs).
16:26:57 <planetmaker> ...stupid as a restriction "only for network usage" may be... :S
16:27:12 <SpComb> so the *purpose* of this download mechanism is to do multiplayer games
16:27:29 <Eddi|zuHause3> i'll remind you again, by german law "distributing" must involve the movement of a physical object (book, dvd, etc.)
16:27:37 <Ammler> planetmaker: the problem is, you have a "proper" setup on joining a network game
16:27:56 <Ammler> if you just download the pack and load it, you might fail with setup.
16:28:00 <Eddi|zuHause3> electronic network access is "only copying"
16:28:07 <SpComb> there's nothing to stop people from making some kind of tool to just copy the stuff from cache to data, but I doubt that's going to make the NewGRF-distributing situation any worse than it already is
16:28:45 <planetmaker> Ammler: yes. My comment was more aimed at "why not allow people to just play with grf"? - however a person may define "play" for him/herself
16:29:05 <SpComb> ah, I tried to find it but missed that
16:30:04 <Eddi|zuHause3> apart from licensing issues, one of the main concerns about automatic newgrf download was the circulation of old versions
16:30:08 *** Doorslammer|OTTD has quit IRC
16:30:21 <SpComb> Eddi|zuHause3: not an issue either, with the concept of a central metadata repo
16:30:25 <planetmaker> Eddi|zuHause3: well. I guess it cannot get worse, can it?
16:30:32 <Ammler> SpComb: yeah, if you have to manually copy the files from cache to the data dir, it is like installing the grfpack...
16:30:44 <SpComb> if you store the version history in there, then you can implement things in the client that would improve the current situation drastically
16:30:56 <SpComb> like automatically checking for newer versions of the NewGRFs currently in use
16:31:13 <Eddi|zuHause3> planetmaker: the idea is that when the author wants to not support old versions, he just removes the download links for them, so over short or long, the people will use the new version
16:31:25 <Ammler> SpComb: no, not automatically update
16:31:32 <SpComb> Ammler: and then on top of that, the files in the cache are called like "6D620401-C5ACB6D5536A464FD78871D91840A35F.tar"
16:31:44 <Ammler> there might still be servers which need the old version.
16:31:51 <Eddi|zuHause3> especially server owners will have to upgrade when they get a lot of complaints about "i cannot find this version of the grf anywhere"
16:31:56 <SpComb> Ammler: well, I haven't given the implementation any thought, my point is that there's potential for improvement
16:31:58 <planetmaker> Eddi|zuHause3: I'm aware. But no single person will continuously scan the zillion download sites for each of his grf.
16:32:27 <SpComb> it could just annoy the server operator into upgrading the NewGRFs that they are using :)
16:32:28 <planetmaker> Resulting in rather more outdated grf than just checking once a central place where all grf are kept with an up to date version.
16:32:30 <Eddi|zuHause3> SpComb: nobody cares about the filename
16:32:44 <Eddi|zuHause3> the newgrf gui will show the action 8 name
16:32:59 <SpComb> yeah, yeah, I know, but my point is, it's not called "cache/dbsetxl.grf" either
16:33:15 <Rubidium> Eddi|zuHause3: except for the ones that don't have an action 8 name
16:33:17 <SpComb> not that it's going to stop anyone from copying it over
16:33:22 <Ammler> cache/GRFID.md5sum.tar
16:33:25 * SpComb ponders embedding some '\0's into the filename
16:33:38 <Eddi|zuHause3> SpComb: but cache/6D620401-C5ACB6D5536A464FD78871D91840A35F.tar/dbsetxl.grf
16:34:05 <Eddi|zuHause3> which will also void Rubidium's remark ;)
16:34:08 <SpComb> (some of the weird control chars do play havoc with the standard GNU/Linux coreutils
16:34:23 <Ammler> SpComb: what about a grfset with 2 files?
16:34:27 <SpComb> Eddi|zuHause3: yes, but it still doesn't void my reasoning behind it
16:34:34 <SpComb> Ammler: like ECS? I'm not sure yet
16:34:45 <Ammler> or dbset with ecs adapter
16:35:07 <Ammler> serbian narrow and standard gauge
16:35:15 <SpComb> it's one of those things that needs to be researched, and then develop a database model that fits those, and then figure out how to implement it all
16:35:30 <SpComb> currently I just have a (id, grfid, md5sum, url) table
16:35:59 <Ammler> well, it shouldn't be that hard for server admins to have the readmes in both tars.
16:36:41 <Ammler> how do I need to setup my server?
16:36:57 <Ammler> for the GRFs do download...
16:37:08 <SpComb> I haven't modified the server side code at all
16:37:17 <SpComb> it's all completly client-side, in the server browser
16:37:33 <Ammler> but who does distribute the GRFs?
16:37:58 <Ammler> wouldn't it be best, if the gameserver does do that?
16:38:34 <SpComb> but I think first I'll just implement a centralized download repo
16:39:09 <SpComb> getting both the (grfid, md5sum) metadata and the NewGRF data from the server might pose some issues
16:39:17 <Ammler> or the repo should be confiugreable by server...
16:39:18 <SpComb> the client would still need to look the info up in the central db
16:39:22 <Eddi|zuHause3> Ammler: that'll make the version 'control' worse... if there's a central repository, the author could flag all old versions as "not downloadable"
16:40:02 <SpComb> Ammler: yes, if that were to be implemented it would be in the form of just "optimizing" the bandwidth consumption by downloading it from the server instead of some central repo; in essence, per-server repos
16:40:03 <Ammler> how should I run a server with obsolete grfs then?
16:40:25 <Eddi|zuHause3> Ammler: update the grfs
16:40:30 <Ammler> that is the main idea behind ottdc_grfpack :-)
16:40:34 <SpComb> the entire reasoning behind this depends on there being a centralized database of metadata
16:40:54 <SpComb> and the official client would then only download NewGRFs that are listed in there
16:41:06 <SpComb> anything else poses issues
16:41:42 <Ammler> Eddi|zuHause3: you need the old grfs for old saves, too.
16:41:50 <Eddi|zuHause3> i'd favour the metadatabase, but instead of downloading automatically, you could open a browser with the download page [for people who want readmes to be read and stuff]
16:41:53 <SpComb> where the newgrf data itself is downloaded from isn't such a difficult thing though, because openttd distributes the md5sums, so you can just rely on those to be cryptographically correct
16:42:16 <SpComb> Eddi|zuHause3: that, again, is the distinction between network clients and servers/singleplayer
16:42:20 <Ammler> i.e. saves with ISR 0.5 don't work with ISA 0.7
16:42:24 <Eddi|zuHause3> Ammler: well, it could at least nag the people with a warning
16:43:17 <SpComb> Eddi|zuHause3: imo, the readme isn't as relevant for people who are just playing as network clients
16:43:45 <Eddi|zuHause3> SpComb: well, it could have some information about how to use certain vehicles
16:44:19 <SpComb> but it's not like the current system (downloading NewGRFs yourself, or via the ottdc grfpack) forces you to read any readmes
16:44:53 <hylje> that it's okay somewhere doesn't mean it's okay everywhere
16:44:56 <Eddi|zuHause3> SpComb: that's the right place to enforce such rules ;)
16:45:21 <SpComb> Ammler: and yet I used jcindstaw.grf in my recently started game without even noticing that it was obsolete
16:45:42 <SpComb> hylje: well, it's a question of what kind of standards you want to impose on new systems
16:46:00 <SpComb> if the current ones are fine, then something that improves slightly on them should be fine
16:46:45 <SpComb> forcing the user to change from OpenTTD into their browser to click around on links, hunt down .grfs or .tars or .zips and then shuffle them around makes it all completely worthless
16:48:29 <hylje> i've got the impression that people like to make others run through hoops
16:48:40 <hylje> dead simple systems are no-no
16:50:19 <planetmaker> [18:48] <hylje> i've got the impression that people like to make others run through hoops <-- make you feel the power :P
16:50:40 <SpComb> one would need to talk with the NewGRF authors
16:51:34 <planetmaker> indeed. They need to grant permission to use their grf on a however formed distribution system
16:51:37 <hylje> or just be spiteful and do it anyway
16:51:56 <hylje> make them weep when their work gets a lot of popularity
16:52:00 <Ammler> we made the GRFPack and asked AFTER :-)
16:52:07 <planetmaker> It might be an idea to make it anyway - and feed those grf into it which allow it.
16:52:21 <SpComb> currently I'm just using Michael Blunk's grfs for testing because he has an explicit license granting permission to distribute them
16:52:21 <Ammler> you need something to show
16:52:24 <planetmaker> and then poke all those authors to grant permission :)
16:52:43 <planetmaker> prod them till they cannot say anything but yes ;)
16:52:50 <Ammler> if you just talk about something, they won't give you permission.
16:52:52 <SpComb> planetmaker: indeed, and the advantage of a central metadata repo is that you can offer the NewGRF authors more control over their GRFs than they previously had
16:53:12 <hylje> when i discussed it quite some time ago a newgrf flag that allows/denies, undef=deny distribution was very undesirable
16:53:23 <planetmaker> does MB allow that? cool
16:53:25 <SpComb> hylje: yeah, because that's fundamentally flawed
16:53:32 <SpComb> Ammler: indeed... pretty graphs
16:53:55 <hylje> just as fundamentally flawed as people manually distributing them
16:54:03 <Ammler> MB has a very open "license"
16:54:27 * planetmaker probably never read that... :P
16:54:34 <DaleStan> Provided you don't modify/reuse his work.
16:54:52 <SpComb> well, if you take a newgrf flag, flip that bit, and then feed it into a system that automatically distributes the data from OpenTTD servers to clients in an autonomous fashion, I think you would be doing a lot more damage than the current state of affairs
16:54:59 <Ammler> I meant open for distribution
16:55:08 <planetmaker> and his set is a good start as it's one of the best ones around
16:55:33 <hylje> SpComb: yes, that's the cost of having something made trivial
16:55:44 <Ammler> but if you add a flag, default should be distribution allowed...
16:55:46 <hylje> SpComb: i'm certain any reasonably open system can be subverted in the way
16:55:57 <SpComb> hylje: well, a centralized metadata repo offers a lot of advantages
16:56:11 <planetmaker> [18:55] <hylje> SpComb: i'm certain any reasonably open system can be subverted in the way <-- any system, if it comes to that
16:56:13 <hylje> Ammler: nah, explicit is a must. it's about intention
16:56:24 <Ammler> else you will have GRFs never be allowed
16:56:31 <SpComb> if the official OpenTTD client always checks against that, then subverting that system takes a lot more effort - you'd need to have everyone use a patched/custom version of the OpenTTD client
16:56:35 <Ammler> because nobody does care about them...
16:56:44 <SpComb> and I think the difference there is very significant
16:57:22 <SpComb> relying on the behaviour of the official client used by normal uses vs. whatever code the server is running is really the best thing you can do
16:58:08 <SpComb> because, after all, it's the only thing that the devs really have control over
16:58:33 <Ammler> that should not be concern of devs
16:58:36 <hylje> it's not very hard to subvert *that* by providing a alternate repository (through git/hg) that patches the checks out
16:58:42 <Ammler> it belongs to the server admins...
16:58:54 <SpComb> hylje: sure, but at that point you could just as well write the whole distribution system yourself
16:59:16 <SpComb> so you can't blame the maintainers of the offical trunk for anything like that
16:59:47 <SpComb> the high-level fear here is building a system that annoys the NewGRF authors so much that they all decide to make their GRFs incompatible with OpenTTD
17:00:01 <SpComb> at least, that's the reason that I found when I read the threads
17:00:42 <Ammler> but then, we (#openttdcoop) should annoyed them already enough, not?
17:00:48 <hylje> if the grf authors want bad faith, they'll likely get it back
17:00:59 <hylje> read: hostile reverse-engineering
17:01:17 <hylje> but maybe i'm way too optimistic about it
17:03:27 <planetmaker> It again probably boils down to: present a (nearly) done open, central distribution system, where they may submit their grf and let's see how it is accepted.
17:09:38 *** frosch123 has joined #openttd
17:09:38 *** tom0004 has joined #openttd
17:09:38 *** N1ghtCrawler has joined #openttd
17:09:38 *** DJNekkid has joined #openttd
17:09:38 *** Progman has joined #openttd
17:09:38 *** De_Ghost has joined #openttd
17:09:38 *** Vikthor has joined #openttd
17:09:38 *** GoneWacko has joined #openttd
17:09:38 *** einKarl has joined #openttd
17:09:38 *** Eddi|zuHause3 has joined #openttd
17:09:38 *** izhirahider has joined #openttd
17:09:38 *** mikegrb has joined #openttd
17:09:38 *** Born_Acorn has joined #openttd
17:09:38 *** sheskar_ has joined #openttd
17:09:38 *** Belugas_Gone has joined #openttd
17:09:38 *** Ridayah has joined #openttd
17:09:39 *** svippery has joined #openttd
17:09:39 *** DaleStan has joined #openttd
17:09:39 *** Wolfensteijn has joined #openttd
17:09:39 *** Celestar has joined #openttd
17:09:39 *** charon.oftc.net sets mode: +vvoo glx tokai Belugas_Gone orudge
17:09:39 *** daspork_ has joined #openttd
17:09:39 *** charon.oftc.net sets mode: +v orudge
17:09:39 *** planetmaker has joined #openttd
17:09:39 *** ArmEagle has joined #openttd
17:09:39 *** welterde has joined #openttd
17:09:39 *** valhallasw has joined #openttd
17:09:39 *** ccfreak2k has joined #openttd
17:09:39 *** TheMask97 has joined #openttd
17:09:39 *** Phantasm has joined #openttd
17:09:42 *** ChanServ sets mode: +o Rubidium
17:09:44 <Ammler> the drawer or the coder?
17:10:30 <Ammler> so you would like to aks about 20 guys for permission about using TTRS or ECS?
17:11:03 <planetmaker> Ammler: yes, you would. Except they define a lead dev :)
17:11:09 <SpComb> I'm not really too worried about the aspect of who's going to add in the GRFs, because I suspect that if the system ever gets into trunk (with a couple of GRFs in the database already), then that problem will mostly solve itself :)
17:11:17 *** Brianetta has joined #openttd
17:11:33 <SpComb> because people will want to play with GRFs that will be automatically downloaded, so they'll want to get new GRFs added in
17:11:41 <Ammler> I would suggest a dedicated system
17:11:44 <planetmaker> or it could work similarily as the language part of OpenTTD
17:11:54 <Ammler> using GRFCrawler for info hosting
17:12:08 <Ammler> and having different servers for the GRFs itself
17:12:28 <Eddi|zuHause3> <DaleStan> Provided you don't modify/reuse his work. <- he occasionally allows that if you ask him explicitly
17:12:30 <SpComb> presumeably at first you'd just have a cabal of admins who add in NewGRFs, possibly then authorising other people to add NewGRFs, dunno
17:12:35 <planetmaker> but that's just a detail, isn't it?
17:12:48 <SpComb> but you can always remove a GRF from the database if someone objects
17:12:53 <SpComb> (or, well, blacklist it)
17:13:21 <Ammler> Eddi|zuHause3: really? then somebody should split alpine...
17:14:34 <Ammler> (removing industries...)
17:14:43 <Eddi|zuHause3> Ammler: for example richk once asked him for the snow/grass tiles from alpine to use for his snow in temperate patch
17:14:55 <SpComb> Ammler: well, I'm kind of doubtful of GRFCrawler being all that useful, depending on how you define "info hosting"
17:15:06 <SpComb> the needs of this system are very different from what GRFCrawler has
17:15:11 <Eddi|zuHause3> Ammler: also, he said he wants to do that ;)
17:15:15 <SpComb> knowing the md5sum of every .grf is a fundamental feature
17:15:28 <SpComb> you could import some stuff from GRFCrawler, but that's about it
17:16:00 <SpComb> the database structure is going to need to be able to handle multiple versions of a some GRF combo that includes multiple .grf files (like ECS)
17:16:18 <SpComb> (possibly their dependancies with eachother, to simplify loading them, or is that not an issue anymore?)
17:16:48 <Ammler> that issue depense on the grfauthor
17:17:07 <SpComb> indeed, so it's basically going to turn into a .grf package manager :)
17:17:15 <Ammler> because you do not know, how future versions will work with your set.
17:17:38 <planetmaker> kinda like the grf presets :)
17:17:47 <SpComb> you could store some kind of dependancy graph and then use that to hint at what order they should be loaded in
17:18:36 <Ammler> you can add those infos to the GRF
17:19:07 <CIA-3> OpenTTD: skidd13 * r13785 /trunk/ (Makefile.in config.lib media/openttd.desktop.in): -Add: support for freedesktop.org desktop entry files
17:22:51 <SpComb> so... anyone familiar with how the network client behaves as regard to the list of NewGRFs to use?
17:23:09 <SpComb> I'm trying to figure out when NetworkGameInfo::grfconfig is actually used
17:26:43 <peter1138> SpComb, in the server browser, I think...
17:28:37 * peter1138 goes back to his YAPP game.
17:31:04 <joachim> the new graphics (higher resolution), do they also use grf?
17:32:12 <glx> new graphics don't have higher resolution
17:34:57 <joachim> i saw a screenshot with a train that looked very detailed.. the set that only has one engine
17:35:49 <peter1138> That's not exactly a set then, is it?
17:36:22 <joachim> it has wagons for all cargos
17:39:00 <Eddi|zuHause3> no, they are not GRFs, they are plain sprite replacement PNGs
17:40:00 <Eddi|zuHause3> works also for sprites in GRFs ;)
17:41:31 <Ammler> that those 32bpp doesn't include GRF
17:41:41 <Ammler> so you could disable/enable them
17:42:10 <Ammler> but not many artists uses it...
17:42:14 <glx> you can code a grf and have 32bpp sprites for it, all in a .tar
17:42:14 <Eddi|zuHause3> you just have to bug DaleStan enough that he includes PNG support in grfcodec ;)
17:43:07 <DaleStan> I have no plans to make grfcodec support 32 bpp anything.
17:43:19 <SpComb> hrm, I guess the only thing it does with NetworkGameInfo::grfconfig is compare it against _all_grfs (via FindGRFConfigI) and then mark them good/bad according to that
17:43:20 <DaleStan> Except by way of binary includes.
17:43:58 <DaleStan> Which it already supports.
17:45:10 <Eddi|zuHause3> SpComb: isn't that enough?
17:45:26 <joachim> so they're not higher res?
17:45:32 <Eddi|zuHause3> SpComb: the actual grf loading is done with the network savegame
17:45:48 <Eddi|zuHause3> (which includes the full grf list again)
17:46:16 <SpComb> the GRF code is a bit silly, uses all kinds of global variables and whatnot :(
17:46:23 <Eddi|zuHause3> joachim: increased zoom level is currently not part of trunk
17:46:34 <Eddi|zuHause3> joachim: and is a very disputed feature overall
17:47:18 <joachim> i know and i know, trying to find the set i mean (or shots of it)
17:47:52 <Eddi|zuHause3> joachim: there's a page on the wiki
17:47:59 <joachim> might just have been 32bpp...
17:48:01 <SpComb> Eddi|zuHause3: hrm, the info transferred also includes the filename? Does it have to be the same on the server and the client? :/
17:48:13 <Eddi|zuHause3> SpComb: filename is irrelevant
17:48:28 <Eddi|zuHause3> grfs are loaded by GrfID and MD5sum
17:49:50 <Ammler> joachim: if you want, I can enable a full 32bpp pack :-)
17:50:08 <Ammler> well, it is about 3 months old
17:50:15 <joachim> what's the url to the wiki page?
17:51:27 <joachim> ah, found it, it was 32bpp with extra zoom level
18:03:46 *** HeadBeng0r has joined #openttd
18:04:05 *** HeadBeng0r has left #openttd
18:04:31 <Eddi|zuHause3> most fascinating.
18:06:33 <Ammler> Eddi|zuHause3: another command of #openttdcoop :-)
18:07:00 <Eddi|zuHause3> tell it to glx when you add such things :p
18:07:52 <Ammler> [20:07] <Ammler> !download
18:07:52 <Ammler> [20:07] <PublicServer> use !dlin, !dwin, !dosx, !dlin64, !dwinauto (Windows Auto Updater), !autostart
18:08:49 <Eddi|zuHause3> why can't you give all links instead?
18:09:00 <Ammler> well, since _42_ isn't here anymore
18:09:45 <Yexo> Ammler: that'd also kick !? for example
18:09:56 <Yexo> which could be used in normal chat
18:10:19 <Eddi|zuHause3> Yexo: no, must be at the start of the line
18:10:51 <Eddi|zuHause3> Ammler: occasionally people mistype DorpsGek's commands with ! instead of @
18:11:01 <Eddi|zuHause3> that does not really warrant such a kick
18:11:41 <Eddi|zuHause3> no, i wasn't looking at anyone in particular :p
18:12:02 <peter1138> OH GOD THE AI IS DESTROYING THE LANDSCAPE AGAIN
18:12:17 * Prof_Frink destroys peter1138
18:12:46 * planetmaker time travels and restores peter1138
18:14:47 <Yorick> planetmaker: you could just have made a new planet, with peter1138 on it
18:14:49 <Ammler> peter1138: is there already a ai, which can terraform?
18:15:10 <planetmaker> My planets are only infant planets - they don't bear life so far
18:16:09 <Yexo> Ammler: I'd like to hear any idea you have about implementing terraforming in an AI pathfinder
18:16:20 <Yorick> planetmaker: it isn't a very complex form of life :)
18:17:21 <Ammler> Yexo: watch those kids on the MP servers
18:17:36 <Ammler> one straight line on the same level from a to b
18:18:04 <Yexo> they might be used to playing with realistic acceleration off
18:18:13 <Ammler> actually, it is one of the best things your ais has
18:18:29 <planetmaker> indeed. be light on it :)
18:18:42 <Ammler> I wouldn't do that much terraforming anyway.
18:18:44 <peter1138> So we need an option to disable all terraforming...
18:18:57 <peter1138> Which would be annoying :o
18:18:58 <planetmaker> maybe make a bit small-scale tf for placing stations, but then it's ok.
18:18:59 <Yexo> Ammler: try a hilly, rough map with build on slopes off
18:19:03 <Yexo> you'll need terraforming :)
18:19:06 <planetmaker> peter1138: I have such patch :)
18:19:16 <planetmaker> per company accessible.
18:19:24 <Ammler> why should you switch that off?
18:19:27 <peter1138> Maybe only allow one point at a time. Could be abused though...
18:19:38 <Ammler> can't ai use foundations?
18:19:43 <planetmaker> I have that, too :) - wwottdgd didn't need it, though
18:19:47 <peter1138> It is not aware of them.
18:19:54 <Yexo> but Rubidium made a test scenario's for AIs with that switch off
18:21:50 <Rubidium> you'll like playing that one, especially with a no-terraforming rule
18:22:54 <Ammler> I tried you scenarios already
18:23:00 <Ammler> also those nice flooding ones
18:23:05 * planetmaker imagines a scenario with approx. 3 flat tiles and rough, hilly terrain
18:23:45 <Ammler> the ai reaches to connect 2 routes, afaik
18:24:28 <Ammler> it is quite watchable with opengfx
18:24:54 * planetmaker still has to try the toyland to Mars conversion
18:25:25 <planetmaker> hm... actually not really. Maybe I remember something wrongly, though
18:26:05 <Ammler> if you do not find something with lego, you can search for bricks or so
18:29:13 *** lobster_MB has joined #openttd
18:40:05 *** christian has joined #openttd
18:49:05 <SpComb> there, GRFs loaded from cache aren't shown in the NewGRF gui...
18:54:05 <CIA-3> OpenTTD: rubidium * r13786 /trunk/ (config.lib media/): -Fix (r13785): reconfigure gave warnings on the newly introduced options.
18:57:11 <SpComb> heh, OpenTTD asserts if you rm a .tar file after it's started up
19:00:33 <SpComb> and gah, ScanNewGRFFiles doesn't find any .grfs if they were in .tar files that were added :/
19:00:42 <SpComb> because the list of .tar files and their contents is apparently constructed at startup
19:01:04 <SpComb> so if you add a .tar file containing .grfs to your data dir, you need to restart OpenTTD to be able to use them
19:02:48 <peter1138> That could be correct.
19:03:21 <peter1138> But there should be some way of rescanning tars as well, I guess.
19:04:15 <SpComb> NewGRFAddWindow.OnClick#ANGRFW_RESCAN doesn't call that though
19:09:22 *** grumbel has joined #openttd
19:12:22 <Ammler> Rubidium: noai has also that -n bug
19:13:09 <Rubidium> wait till the bugfix gets synced into there
19:13:27 <Ammler> how many times do you sync?
19:13:43 <planetmaker> he... can we kindly ask for that sync... ?
19:14:04 <glx> <Ammler> how many times do you sync? <-- when someone thinks it's a good idea to do
19:14:26 <Ammler> planetmaker: we could apply that fix self
19:14:31 <planetmaker> because that revision has issues with joining companies. So testing vs. humans is kinda difficult.
19:15:27 <Ammler> maybe just apply the fix
19:16:06 * glx will look but he doesn't promise anything
19:16:10 <peter1138> Hmm, I ought to consilidate my routes and vehicles.
19:16:35 * planetmaker also never promises things when topic is programming :)
19:16:54 <peter1138> Building main lines in stages... have lots of local trains doing segments of the line...
19:17:35 <planetmaker> :P Die Geister, die ich rief...
19:17:42 <peter1138> Hmm, only one branch line.
19:19:02 *** Marduuhin has joined #openttd
19:19:46 <SpComb> hmm... how can I tell a window to refresh itself?
19:20:00 <SpComb> and I mean a window other than this, something I don't have a pointer to
19:21:22 <SpComb> although hrm, actually I still need to update compatible and version_compatible
19:23:28 <planetmaker> iirc you tell it to be dirty
19:26:01 <CIA-3> OpenTTD: smatz * r13787 /trunk/src/ (gfx.cpp gfx_func.h misc_gui.cpp): -Codechange: resize the red error message box if needed
19:31:03 <Ammler> but I guess, IF you sync you sync all :-)
19:31:20 <glx> Ammler: yes a sync contains everything
19:31:27 <SpComb> right, it refreshes correctly
19:31:34 <SpComb> does someone want to do some testing? :)
19:31:58 *** lobster_MB has joined #openttd
19:35:21 <Yexo> what makes a server always generete the same 'random' map?
19:36:29 <Yexo> ok, but now we have a server, that always create the same map on startup, and we want random maps
19:36:38 <Yexo> so apart from -G, what can cause it?
19:37:29 *** GoneWacko has joined #openttd
19:37:47 <peter1138> random seed in the config
19:38:09 <tom0004> if i understand correctly, just remove -G to have random maps again
19:38:16 <CIA-3> OpenTTD: glx * r13788 /branches/noai/ (30 files in 7 dirs): [NoAI] -Sync: with trunk r13734:13787
19:38:22 <tom0004> or am i jumping into middle of a convo ?
19:38:33 <Yexo> no, but you didn't understand the problem
19:41:31 <Ammler> hmm, might it be something in the noai branch?
19:45:51 <Ammler> Yexo: when will the next nightly be made?
19:46:46 <Yexo> 1 hour before the trunk nightly iirc
19:46:58 <Ammler> they are "real" nightly then, too?
19:48:38 <glx> Yexo: 2 hours before indeed
19:55:39 * SpComb wonders how to add a new library to OpenTTD's configure
19:57:11 *** ChanServ sets mode: +v tokai
20:06:22 <Ammler> omg, what a nice feature in trunk :-)
20:06:26 <SpComb> and the answer is: by copy-pasting all the *png* stuff and s/png/curl/
20:07:02 <SpComb> Ammler: do you want to test my patch?
20:10:34 <Ammler> hehe, how do I checkout hg repos?
20:11:29 * Ammler is running zypper in mercurial
20:12:52 <peter1138> Oh damn, I just made an awkward route around an industry... then it closed down.
20:13:55 <SmatZ> peter1138: report it at tt-forums.net and have a feature request, you wouldn't be the first ;)
20:14:29 <SpComb> run the client without the dbsetxl loaded, add "skrblz.fixme.fi" as a server, click the "NewGRF Download" button, and the DBSetXL should show up orange
20:14:50 <SpComb> hit "Check Available", and it should turn green - you can see the URL etc if you click on it
20:15:02 <SpComb> and then "Download Available" and it should turn blue, after which you can close the window
20:15:24 <peter1138> SmatZ, btw, why did you put a combo signal outside a depot?
20:15:28 <SpComb> the server is also using newstatsw.grf, but that isn't in the db
20:15:38 <peter1138> Or was it just an exit signal... hmm...
20:15:47 <Ammler> so ./configure --without-personal-dir
20:15:52 <SmatZ> peter1138: so trains don't leave the depot if there isn't any green exit - and other trains can enter the depot
20:16:15 <peter1138> SmatZ, ah... you know that's built in to the depot's internal signal?
20:16:37 <SpComb> oh, you might need to create a "cache" folder in bin/ - it probably doesn't know how to create it itself
20:16:52 <Ammler> peter1138: it's a "overflow" depot
20:17:05 <Ammler> it does make the entry signal green
20:17:09 <SmatZ> peter1138: yeah, but I need to have a "green" there so entry signal is green, too
20:17:15 <SmatZ> so there are no queues at station entry
20:18:06 <SmatZ> maybe it would work if there was normal signal instead of entry signal, too
20:18:44 <SmatZ> but this is how this evolved...
20:20:47 <Ammler> SpComb: now I see, why you do understand german... :-)
20:21:38 <DJNekkid> if a MU could contain mail, what would be a proper ratio? (compared to passangers)
20:22:44 * SpComb added an empty cache dir to the hg repo and added newstats to the db
20:22:57 <SpComb> my father's domain, he still lives in Germany
20:23:03 <SpComb> and indeed, I lived there for eight years as well
20:24:43 *** |Jeroen| has joined #openttd
20:26:33 <Ammler> '/home/marcel/hg/ottdgrfs-openttd.hg/src/network/newgrf_download.cpp:28:23: error: curl/curl.h: No such file or directory
20:28:53 <SpComb> Ammler: yes, you need to install libcurl-dev or whatever is the equivalent
20:29:06 <SpComb> or did you already do that?
20:30:03 <SpComb> indeed, it needs the headers to build
20:31:25 <Ammler> isn't there another way for downloading?
20:31:40 <Ammler> what does ottd use to download the map?
20:31:49 <peter1138> Hmm, is it possible to make a train turn around at a via order? :o
20:32:53 <SpComb> Ammler: well, I decided to just use curl/HTTP now, but I guess you could run some custom server as well...
20:33:08 <planetmaker> peter1138: possibly, if it is a terminus?
20:33:20 <peter1138> It's not a terminus, no.
20:33:30 <Ammler> is it possible to set a order "no loading" and "no unloading"
20:33:54 <peter1138> Ammler, no, that's handled by a via order ;)
20:34:05 <planetmaker> and then time table it to wait for 10 days :P
20:36:53 * SpComb wonders if he wants to try and cross-compile a .exe for windows
20:38:10 <SpComb> Ammler: hmm... did you hg clone it before I commited the changes to config.lib?
20:38:16 <SpComb> try hg pull && hg update
20:38:34 <SpComb> if that pulls in some changes then you'll need to ./configure again
20:39:26 <SpComb> hrm... and what does `hg parents` show?
20:42:29 <Yorick> is that dedicated server supposed to give all messages twice?
20:44:46 <Yexo> peter1138: After saving a newgrf preset, it'll still show "Custom", untill you reload the set by choosing it from the dropdown
20:45:09 <SpComb> ::ffff:84.227.12.95 skrblz.fixme.fi - [22/Jul/2008:23:44:33 +0300] "GET /~terom/ottdgrf-repo/dbsetxl.tar HTTP/1.1" 200 1146880 "-" "OpenTTD (h:88c967f)"
20:45:12 <SpComb> ::ffff:84.227.12.95 skrblz.fixme.fi - [22/Jul/2008:23:44:37 +0300] "GET /~terom/ottdgrf-repo/newstats.tar HTTP/1.1" 200 1546240 "-" "OpenTTD (h:88c967f)"
20:45:16 <SpComb> OpenTTD has it's own user-agent now :)
20:45:21 <SpComb> Ammler: were you able to join?
20:45:58 <Ammler> a loading bar for the download would be nice.
20:46:29 * Yorick is sorry, lost his bookmark
20:46:53 <SpComb> Ammler: indeed, but that's going to take a bit of work
20:47:20 <SpComb> async network stuff is always tricky
20:52:43 <CIA-3> OpenTTD: peter1138 * r13789 /trunk/src/newgrf_gui.cpp: -Fix (r13781): Saved preset was not automatically selected.
20:53:46 <Ammler> and ask authors about?
20:54:29 <Ammler> hmm, still not sure about the repo server
20:55:57 <SpComb> not today, I think, I'm going to sleep soon
20:56:32 <SpComb> Ammler: what is it about the repo? Use of HTTP?
20:57:23 <SpComb> use of a repo vs. downloading from the server?
20:57:54 <Ammler> my favorite is downloading from the server...
20:58:00 <SpComb> well, to some degree, that's just an implementation detail
20:58:36 <peter1138> Downloading from server means GRF authors will never have any control.
20:58:37 <Ammler> but repo might be better aceptted by authors
20:58:48 <SpComb> if I replace HTTP with some OpenTTD protocol, then it wouldn't be such a big leap to have it download some NewGRFs from the server directly - with the md5um, the difference is pretty small
20:59:14 <SpComb> peter1138: well, it would still check the md5sum against the master db
20:59:40 <SpComb> so it's not *that* bad, but it still makes me feel kind of uneasy
20:59:48 <planetmaker> a central repo is probably better.
21:00:05 <planetmaker> you might make a cfg entry for the repo url
21:00:15 <planetmaker> so you could in principle re-configure that
21:00:17 <Ammler> so you can use the repo as server admin
21:00:33 <Yorick> planetmaker: do we have a cfg entry for the master server url?
21:00:33 <planetmaker> exactly. but default is our repo :P
21:00:41 <Ammler> if you like to play with other grfs, you need to distrbute them the old way.
21:00:45 <planetmaker> Yorick: not that I know
21:01:01 <Yorick> isn't this a bit the same?
21:02:00 <SpComb> the address for the metadata database doesn't need to be configureable
21:02:28 <SpComb> there's nothing in the design that requires a central repo, there's a lot of flexibility in how that could be implemented
21:02:34 <planetmaker> the game still has to start w/o acces to it
21:02:36 <peter1138> Use of a repo also has the possibility of doing automatic upgrades (or at least notifying of updates) which some authors may like...
21:02:51 <planetmaker> indeed. good idea
21:02:53 <SpComb> planetmaker: of course, but you wouldn't be able to download NewGRFs in-game
21:03:42 <SpComb> peter1138: yes, as I've said earlier, having a central *metadata* database gives the authors more control over old versions
21:04:09 <SpComb> but this database only contains the md5sums and other info, the actual .grfs can then be downloaded from elsewhere
21:04:29 *** Digitalfox has joined #openttd
21:04:32 <planetmaker> the database should also IMO at least have a link to the grf
21:04:50 <peter1138> You only need a 'superseded' field ;)
21:05:11 <SpComb> yes, it would probably need an interface similar to GRFCrawler
21:05:45 <planetmaker> completely unrelated: a new *.cpp file: do I just add it to source.list ?
21:05:45 <SpComb> (hmm... if you download the data from the OpenTTD server, you'd also need to download the readmes, and you would then also need to md5sum those...)
21:06:21 <SpComb> it only checks the md5sums on the .grfs, but e.g. michael blunk's licsense requires a valid readme containing his copyright notice to be distributed as well
21:06:25 <peter1138> The accompanying text (but sometimes HTML or PDF) files are the spanner in the works, really.
21:06:27 <Ammler> SpComb: they are in the tar
21:07:18 <orudge> can you not just add an entry in some database saying "associated files", that get downloaded whenever the main GRF gets downloaded?
21:07:20 <planetmaker> that then means central repo which supplies the files
21:07:23 <Ammler> how does "default" windows handle tar?
21:07:23 <orudge> doesn't seem like it'd be much of a spanner in the works...
21:07:30 <orudge> assuming this is coming from a central database/server
21:07:41 <peter1138> orudge, problem is forcing them to be shown, as some require.
21:07:54 <peter1138> I suppose if you mandate a simple text file, that could be shown. Somehow.
21:07:56 <orudge> this is where the OpenTTD HTML renderer comes in :p
21:08:47 <Ammler> the readme could be a map with a lot of signs
21:09:20 <planetmaker> no no. A specially generated map. desert letters on green background
21:09:39 <Digitalfox> Sorry to bother you guys with an of topic question, but I'm getting really bored on some video splitting and it's going very wrong and after having download 11 applications, I'm like at the start of the task :( How please can I cut the start and the end of an anime show I have? The codec it's using is h264 inside a container mp4.. I have tried every application I could find and already had,...
21:09:39 <glx> <Ammler> how does "default" windows handle tar? <-- it just doesn't handle them
21:09:40 <Digitalfox> ...like avidemux and virtuadub, but if I don't cut on a key frame, the start of the video get's all messy and after 5 seconds it's normaly.. I wan't to avoid any recode, just cutting the start and end..
21:10:45 <planetmaker> Digitalfox: that's what key frames are about: start points
21:11:14 <planetmaker> all others are only relative information
21:11:36 <Digitalfox> planetmaker no way of cutting like 3 or 4 frames next to a key frame?
21:11:48 <planetmaker> you did it. You saw the result.
21:11:57 <Digitalfox> without screwing the start of the anime for 5 seconds..
21:12:00 <Ammler> are there windows ottd users without 7z installed?
21:12:08 <planetmaker> or de-code and re-encode
21:12:25 <Digitalfox> planetmaker so divx and xvid you can but in h264 you can't?
21:12:28 <SpComb> a .html -> .sav converter
21:12:33 <Yorick> Ammler: sure there are...
21:12:47 <SpComb> the issue I meant was that the md5sum doesn't cover the readmes
21:12:50 <Digitalfox> Ammler winrar here ;)
21:12:50 <Prof_Frink> Ammler: Just make the windows package depends: 7zip
21:12:53 <planetmaker> SpComb: the other way would also be interesting :)
21:12:56 <Yorick> SpComb: could you make me a .sav -> .html converter first
21:13:15 <SpComb> does a .html with a bunch of <img>s qualify?
21:13:15 <Ammler> Digitalfox: winrar should be able to read tar too
21:13:29 <planetmaker> Digitalfox: I don't know those in detail. But I know the concept of 'keyframe' :)
21:13:33 <Digitalfox> Ammler winrar can :)
21:14:15 <SpComb> currently I download a .tar that contains the grf and the readmes/copyright notices
21:14:25 <Ammler> [23:13] <Yorick> SpComb: could you make me a .sav -> .html converter first <-- orudge almost did :-)
21:15:03 <Prof_Frink> ttd uses .sv0/.sv1
21:16:20 <Ammler> SpComb: I would really prefer to maintain such a repo then the grfpack
21:17:30 <glx> Yorick: why do you want that?
21:18:34 <Yorick> I would like something apart from openttd that can parse savs
21:18:57 <peter1138> And do what with the data?
21:19:19 <Yorick> not figured out yet :) rortom wanted it...
21:19:36 <orudge> [22:14:31] <Ammler> [23:13] <Yorick> SpComb: could you make me a .sav -> .html converter first <-- orudge almost did :-) <-- indeed... if I could be bothered, I could basically reconstruct TTD in a web browser, of a sort.
21:19:43 <orudge> but that'd be rather a lot more effort than just doing what I'm currently doing :p
21:20:37 <ln> could the whole OpenTTD be implemented as a static html file?
21:20:56 <orudge> you could probably do a fair bit in JavaScript
21:21:00 <orudge> although I'd rather not try to implement that.
21:21:26 <orudge> although, some sort of AJAX-y OpenTTD-type thing would probably not be totally unfeasable
21:21:38 <ln> hmmm, are there a finite number of possible moves in chess?
21:22:17 <Prof_Frink> A finite, but frelling huge number.
21:22:32 <ln> so at least a chess game can be implemented as a HTML file.
21:23:20 <Prof_Frink> ln: But that file would probably require storage on a disk that contains more bits than there are atoms in the universe
21:23:50 <ln> Prof_Frink: well, in 5 years you can buy such a disk for < 100€.
21:24:22 <glx> Yorick: the duplication is strange
21:24:45 <Yorick> glx: it only happens if I have 2 ips
21:25:00 <planetmaker> ln: you know the chessboard and the number of rice grains?
21:25:48 <glx> Yorick: doesn't happen for me (I have 3 IPs)
21:26:10 <peter1138> Prof_Frink: There are a hell of a lot of atoms in the universe. You ought to cite ;)
21:26:11 <Yorick> do you have it bound to something?
21:26:45 <peter1138> Multiple IPs or multiple interfaces?
21:26:50 <Yorick> hmm...it can't start a server if it's bound to 0.0.0.0
21:27:07 <ln> but... actually, hmm. there are a finite number of possible states of the chess board, but the number of moves can be infinite, right?
21:27:25 <glx> multiple interfaces 1 real and 2 virtual (vmware)
21:27:31 <Yorick> wireless, wired, bluetooth...
21:27:53 <Sacro> finite input, finite output
21:27:55 <Yorick> it can't even start here if it's at 0.0.0.0
21:28:28 <ln> Sacro: assuming there is output.
21:28:52 <Sacro> there is a finite number of moves though
21:28:52 <Yorick> not as non-dedicated, that is
21:30:27 <planetmaker> ln: no. But you may make an infinite number of moves. But the number of unique ones is limited
21:30:33 <ln> Sacro: let's say we have a chess board in its initial state in front of us. 1) i move the horse, and you move your horse. 2) i move my horse back to its original position, and so do you. 3) goto 1. finite input, but how many moves?
21:32:00 <planetmaker> well... maybe... hm
21:32:45 <Yexo> ln: if you reach the same state three times, the game is draw
21:33:00 <ln> Yexo: never heard of such rule.
21:33:30 <Yexo> also if there are 50 consecutive moves without any pieces being taken of the board, the game is draw too
21:34:32 <DaleStan> Doesn't that 50-moves counter get reset in instances of pawn-movement and pawn-promotion?
21:35:03 <Yexo> DaleStan: even if it did: the amount of pawns is limited, and they can't be moved back
21:35:13 <Yexo> so that still makes the amount of moves finite
21:36:21 <ln> so there is some protection against infinite games by two idiot players. good.
21:42:36 *** tom0004 has joined #openttd
21:43:45 *** Belugas_Gone is now known as Belugas
21:44:35 *** ccfreak2k has joined #openttd
22:08:44 <DJNekkid> is it waggon or wagon ?
22:10:19 <dih> Belugas, hey! welcome back :-)
22:11:08 <ln> "wagon, waggon, n.", says OED.
22:12:13 <Prof_Frink> ln: Go away. peter1138 is right.
22:13:32 <DJNekkid> what would you prefer? :)
22:14:45 <ln> Prof_Frink: peter greaterthan OED?
22:15:06 <ln> not that I would have known about the gg version before checking.
22:15:08 <Prof_Frink> OED says either. peter1138 says which one to use.
22:16:02 <DJNekkid> it's prolly a color/colour thing :)
22:17:18 <ln> "The Eng. dicts. of the 18th c. have the spelling waggon, exc. Johnson, who gives wagon without remark, though all his examples have waggon. Todd 1818 prefers wagon for etymological reasons, but says that waggon is the prevailing form. Webster 1828 gives wagon, remarking that ‘the old orthography, waggon, seems to be falling into disuse’. Smart 1836 gives waggon as the current form, and wagon as ‘a disused spelling’. Stormonth 1884 and Cassell 1888 have
22:17:26 <ln> ... later dicts. wagon either alone or in the first place. In Great Britain waggon is still very commonly used; in the U.S. it is rare."
22:18:17 <SmatZ> ln: is your dictionary from 19th century?
22:18:48 <SmatZ> it doesn't site anything from 20th...
22:19:05 <ln> SmatZ: it is the online version of The Oxford English Dictionary.
22:19:53 <ln> it also has on-topic remark: "The Eng. word has been adopted in Fr. as wagon, vagon (vag{revctilde}) in the sense of ‘railway coach or carriage’, a meaning which is now obsolete in Eng. (see quot. 1847 in sense 5b). So also G. waggon (pronounced as Fr.)."
22:21:51 <CIA-3> OpenTTD: skidd13 * r13790 /trunk/config.lib: -Fix: Enable to force the creation of freedesktop.org desktop entry files
22:27:31 <peter1138> -Fix: Enable grammar
22:28:37 <DJNekkid> perhaps i'd make a parameter 0 is wagon, 1 is waggon :)
22:29:29 <DJNekkid> or change it to coach :)
22:35:03 *** ccfreak2k has joined #openttd
22:35:24 <DJNekkid> Carriage capacity: xxx passangers ?
22:35:56 <DJNekkid> <some code> "Wagon Capacity: " 8A "55 Passengers\n" 98 "Loading Speed: " 8A "Low" 00
22:36:21 <CIA-3> OpenTTD: skidd13 * r13791 /trunk/config.lib: -Fix(r13790): Don refer to variables when their value isn't set as expected
22:37:44 <peter1138> Or just ... Capacity:
22:39:44 <DJNekkid> peter1138: will be confusing i think, as this is text added to the engines, informing on how many people the carriages can take (when attached)
22:44:53 <CIA-3> OpenTTD: skidd13 * r13792 /trunk/ (config.lib configure): -Codechange: Display current values of the options in ./configre --help instead of static strings
23:07:39 <Belugas> peter1138, dih, fjb, i salute you too (or three, actually...) :)
23:10:18 <Belugas> because you did it :)
23:11:53 <CIA-3> OpenTTD: skidd13 * r13793 /trunk/config.lib: -Codechange: Unify the dir checking in config.lib
23:14:41 *** fjb is now known as Guest833
23:29:21 <CIA-3> OpenTTD: rubidium * r13794 /trunk/src/aircraft_cmd.cpp: -Fix: helicopters leaving a heliport could get stuck after processing conditional orders.
23:41:30 *** GoneWack0 has joined #openttd
23:44:45 *** Digitalfox has joined #openttd
23:46:07 <CIA-3> OpenTTD: rubidium * r13795 /trunk/src/tunnelbridge_cmd.cpp: -Change: do not require canals/rivers/seas to be empty when building a bridge over it as it is not required for roads and rails either.
continue to next day ⏵
