IRC logs for #openttd on OFTC at 2008-01-03
⏴ go to previous day
00:32:05 *** mindlesstux is now known as Guest1982
00:33:14 *** mindlesstux_ has joined #openttd
00:37:41 *** Aerandir has joined #openttd
00:41:49 *** Nitehawk has joined #openttd
00:43:15 <Sacro> now, shall i start by moving all signalling stuff to signalling.{c,h}
00:43:29 *** Greyscale is now known as Greysc[a]le
00:44:15 <Eddi|zuHause3> cpp i'd suggest ;)
00:44:34 <Eddi|zuHause3> and rather signal_gui and signal_cmd, like the other stuff
00:46:30 <Sacro> Progress on the AnkhSVN project is tracked by the CIA.
00:46:35 <Sacro> that sounds quite worrying
00:52:48 <Sacro> ooh, svn inbuilt into VS2005
00:59:39 <Sacro> who controls the Visual Studio build stuff?
00:59:43 <Sacro> I feel there is some stuff needing sorting
00:59:56 <Sacro> glx: why do i need unistd.h?
01:01:57 <Sacro> hmm, something tells me i need flex :\
01:02:35 <glx> you are not trying to compile openttd
01:05:32 <Sacro> its not called zlibstat.lib on windwos
01:07:45 <glx> and it is zlibstat.lib because you need useful.zip
01:08:14 <Sacro> I don't wish to have loose files around
01:08:20 <Sacro> can I not use gnuwin32 for it all?
01:08:37 <glx> zlib.lib requires zilb.dll to be present on all machines you want to use your binary
01:12:22 <Sacro> i don't see this anywhere
01:12:47 <glx> by default zlib is a dynamic library
01:15:13 <Sacro> all i have is zlib1.dll
01:15:55 <glx> that's the official zlib dll
01:16:25 <glx> "libgw32c (for developing with the Zlib library)" <-- that's the bad thing with gnuwin32
01:16:54 <glx> contains a lot of not really needed stuff
01:17:21 <Sacro> well, i don't think i need it anyway
01:17:53 <glx> you need it to compile with "their" zlib
01:18:52 <glx> dunno I don't use libs from gnuwin32
01:19:16 <glx> and when I need a lib I compile it myself
01:20:31 <Sacro> the wiki links to zlib.net
01:20:36 <Sacro> which then sends you to gnuwin32
01:25:00 <Sacro> this is so confusing and annoying
01:25:31 <Sacro> i think you don't need ZLIB_WINAPI
01:30:57 *** Eddi|zuHause2 has joined #openttd
01:32:06 <Sacro> Eddi|zuHause2: Germany :(
01:32:08 <Gonozal_VIII> germans? noooooo!
01:32:20 *** Hendikins is now known as Hendikins|Work
01:33:01 <Eddi|zuHause2> lies! he is in a valley!
01:33:13 <Sacro> glx: now thats differnet
01:33:25 <Sacro> i added /Progra~1/gnuwin32/bin to the binary file path
01:33:47 <Gonozal_VIII> but my valley is still some hundred meters higher than you are ;-)
01:35:17 <Gonozal_VIII> lowest point in my town is ~500m and highest ~3000
01:35:57 <Eddi|zuHause2> i am actually on "high flats"
01:36:08 <Eddi|zuHause2> or "high plains"
01:37:05 <Gonozal_VIII> i don't know if we even have regions that low here in austria
01:37:21 <Eddi|zuHause2> well, the "Mansfelder Hochebene" is higher than the "Leipziger Tiefland"
01:37:52 <Gonozal_VIII> hmmm lowest point seems to be ~150m
01:38:23 <Gonozal_VIII> and highest 3798
01:38:53 <Sacro> lowst point in this city is probably about -1
01:39:11 <Gonozal_VIII> you'll all drown ;-)
01:40:41 <Sacro> when global warming comes, Hull is the first city to go
01:40:59 <Sacro> glx: where are the lib names specified?
01:41:10 <Eddi|zuHause2> the village center (lowest point of the village) is 123m
01:41:23 <Eddi|zuHause2> i am somewhat higher than that
01:41:57 <Gonozal_VIII> hmm actually the lowest point here would be the bottom of our lake... that would be somewhere around 375m
01:43:25 <Gonozal_VIII> but you can't flood a lake..
01:43:38 <glx> else it is in properties/linking/input
01:43:57 <Eddi|zuHause2> chuck norris can
01:44:20 <Gonozal_VIII> i never got that chuck norris thing...
01:50:49 <Sacro> glx: i reckon I can build it without freetype using the lib from gnuwin32
02:02:03 <Sacro> glx: think i've sorted i
02:03:03 <Sacro> some kind of debug linking output would be nice though
02:03:43 <ln-> Sacro: ever been to denmark?
02:08:18 <ln-> if you ever do, go ring bjarni's doorbell and hide
02:16:39 <Sacro> i think i'll just disable freetype
02:18:15 <Gonozal_VIII> bjarnis house is the one that looks like a steam train
02:19:01 <Gonozal_VIII> can't miss it, just follow the rails
02:21:40 <Gonozal_VIII> but be careful, it's guarded by robots
02:21:45 <Gonozal_VIII> robots with lazers!
02:26:51 <Eddi|zuHause2> we've already seen the evil pirate robot with the eyepatch
02:28:45 <Sacro> what happened to all the grf files?
02:30:45 <Belugas> been merged in openttdw/d.grf
02:36:50 *** Eddi|zuHause3 has joined #openttd
02:39:32 <CIA-1> OpenTTD: belugas * r11746 /trunk/src/newgrf.cpp: -Fix(r11727): Make sure that action 0A does follow the same new ordering of shore sprites. It was not considered in the missing shore patch
02:40:32 <Belugas> mars and alpine grf are now back to duty
02:41:07 <Gonozal_VIII> newterrain and newwater?
02:41:27 *** Diabolic1Angel has quit IRC
02:43:25 <Sacro> shouldnt the binary be mvoed to the right folder?
02:45:33 * Belugas leaves the scene and heads to bed.
02:45:57 <Belugas> Sacro, i find it really convenient and logical that way
02:46:07 <Sacro> Belugas: to move it, or to not?
02:46:19 <Belugas> Sacro,m to keep it as it is
02:46:25 <Sacro> Belugas: alright, night
03:09:29 *** Nitehawk has joined #openttd
03:48:18 *** Frostregen has joined #openttd
03:56:29 *** dafsaagfgasdfsd has joined #openttd
03:56:29 *** Gonozal_VIII is now known as Guest2003
03:56:29 *** Guest2003 is now known as Guest2004
03:56:30 *** dafsaagfgasdfsd is now known as Gonozal_VIII
04:01:06 *** Tino|Home has joined #openttd
05:42:31 *** mindlesstux has joined #openttd
06:34:23 *** TrainzStoffe has joined #openttd
06:41:08 *** TrainzStoffe is now known as Stoffe
06:48:20 *** peter__ has joined #openttd
07:23:17 *** peterbrett has joined #openttd
07:46:34 *** Dark_Link- has joined #openttd
07:50:45 *** Frostregen_ has joined #openttd
07:56:24 *** Frostregen_ is now known as Frostregen
08:10:43 *** |Bastiaan| has joined #openttd
08:26:17 <peter__> hmm, overrides not working :o
08:54:16 *** peterbrett has joined #openttd
09:02:57 *** peter__ has joined #openttd
09:21:42 *** Maedhros has joined #openttd
09:29:00 *** stillunknown has joined #openttd
10:02:51 *** Deathmaker has joined #openttd
10:18:49 *** Vikthor has joined #openttd
10:26:03 *** Brianetta has joined #openttd
10:30:33 <Gonozal_VIII> no, it's late at night
10:31:02 *** Aerandir has joined #openttd
10:31:42 <Gonozal_VIII> gonos personal time
10:39:17 *** Progman has joined #openttd
10:42:29 *** roboboy has joined #openttd
10:44:53 *** Hendikins|Work is now known as Hendikins
10:44:58 <Gonozal_VIII> now i can't get that song out of my head... i'm gonna be by the proclaimers...
11:10:43 *** Tino|Home is now known as TinoM
11:18:13 <Eddi|zuHause3> good moaning indeed...
11:19:30 *** roboboy has joined #openttd
11:32:35 *** stillunknown has joined #openttd
11:53:23 *** nordenm has joined #openttd
11:54:05 <nordenm> Just came by to thank Bjarni for the excellt mac os x port and the autoreplace-function that saved me several hours today :)
11:55:58 *** |Bastiaan| has joined #openttd
12:05:58 *** Gonozal_VIII has joined #openttd
12:19:16 *** Max_ is now known as Agravain
12:30:04 *** Nitehawk has joined #openttd
12:37:56 *** Greysc[a]le is now known as Greyscale
13:05:52 *** Nitehawk has joined #openttd
13:14:49 *** skidd13 has joined #openttd
13:21:17 *** novotv6_ has joined #openttd
13:41:08 *** peterbrett has joined #openttd
13:47:00 *** Eddi|zuHause has joined #openttd
13:49:49 *** Eddi|zuHause has joined #openttd
13:50:55 *** Arbitrary has joined #openttd
13:55:42 <novotv6_> and good day to you Belugas
13:59:47 <peterbrett> what's the git clone url for the repos?
13:59:54 <Digitalfox_> Good afternoon Belugas ;)
14:00:10 *** roboboy has joined #openttd
14:04:34 <CIA-1> OpenTTD: belugas * r11747 /trunk/ (readme.txt src/misc_gui.cpp): -Change: Return of the prodigal son (or something). Little update (but highly noticed) on the OpenTTD Team
14:05:26 *** Diabolic-Angel has joined #openttd
14:21:52 <Arbitrary> hmm - shouldn't "refit train" update the total cargo details?
14:25:58 <Arbitrary> nope, I have to swap off onto a different tab and back again before the display updates
14:26:50 *** Dark_Link^ has joined #openttd
14:29:10 <Maedhros> hmm, oh yes, i have come across this one before
14:29:48 <Maedhros> the window is only refreshed if either the first vehicle is refitted, or some of the train details like total power change
14:31:00 <Maedhros> i've got it fixed in my refit patch locally, so i didn't see it this time ;)
14:33:23 <CIA-1> OpenTTD: belugas * r11748 /trunk/src/ (newgrf.cpp table/sprites.h):
14:33:23 <CIA-1> OpenTTD: -Codechange: Remove magic numbers introduced on r11746 and r11727
14:33:23 <CIA-1> OpenTTD: -Codechange: A few bad coding style inadvertendly applied too
14:37:38 *** UnderBuilder has joined #openttd
14:45:04 *** Aerandir has joined #openttd
14:50:34 *** Diabolic-Angel has quit IRC
15:00:48 *** egladil has joined #openttd
15:02:07 *** Diabolic-Angel has joined #openttd
15:20:24 *** Diabolic-Angel has quit IRC
15:23:26 *** Diabolic-Angel has joined #openttd
15:28:13 <dih> anybody here familir with supybot?
15:28:54 <skidd13> dih: what's the problem?
15:29:32 <dih> i am failing to get ChannelLogger (database version) to work
15:30:23 <skidd13> dih: Hmm, then I can't help you ;) sry
15:34:47 *** Diabolic1Angel has joined #openttd
15:37:38 *** Diabolic-Angel has quit IRC
15:42:58 *** Diabolic1Angel has quit IRC
15:52:59 *** ChanServ sets mode: +v tokai
16:03:42 *** Vikthor has joined #openttd
16:26:44 <UnderBuilder> what can I do for don't get bored while playing ottd?
16:28:07 <hylje> do you want to get bored
16:32:02 *** Rubidium has joined #openttd
16:37:08 <Belugas> I guess he means "What should I do for not getting bored while playing ottd?"
16:37:53 <Belugas> i do ot know how to answer that one... On my side, i'd code something, or bug fix ^_^
17:00:34 *** pavel1269 has joined #openttd
17:09:33 *** Diabolic-Angel has joined #openttd
17:12:36 *** nordenm has joined #openttd
17:12:59 <nordenm> is there any way to upgrade trains from electrical to monorail by using the "replace train"-thingy?
17:13:35 <Eddi|zuHause> you are too slow for this world :p
17:14:23 <Eddi|zuHause> just use a newgrf set... they usually don't have monorail at all...
17:14:40 <Eddi|zuHause> and maglev only for passengers and consumer goods
17:15:15 <nordenm> but I want to see my gorgeous train network converted to maglev :/ oh well
17:15:18 <DaleStan> And the few that do have monorail don't have maglev at all.
17:16:28 <hylje> does newgrf even support rail+elrail+mono+maglev
17:16:45 <DaleStan> newgrf does support all four types, but TTDPatch does not.
17:18:08 <DaleStan> TTDPatch will combine one or both of rail+elrail and mono+maglev into a single system.
17:26:26 *** Diabolic-Angel has quit IRC
17:47:03 *** jonisdead has joined #openttd
17:59:30 <pavel1269> yaay, my RR works :P now just GUI :o)
18:07:03 *** peter__ has joined #openttd
18:30:54 <pavel1269> Belugas: Route REsctrictions
18:31:01 <pavel1269> programmable signals
18:31:37 <pavel1269> but ... hehe ... one-way signals have bug :(
18:32:19 <Belugas> gaaa.. wanted to test something, and i forgot what :(
18:32:24 *** XeryusTC has joined #openttd
18:36:05 *** caladan has joined #openttd
18:37:27 *** Brianetta has joined #openttd
18:51:04 *** Tlustoch has joined #openttd
18:57:23 *** eQualizer has joined #openttd
19:00:07 <pavel1269> btw, anyone know what change/do to kill this:
19:00:09 <pavel1269> LINK : ..\objs\Win32\Debug\\openttd.exe not found or not built by the last incremental link; performing full link
19:01:28 *** Progman has joined #openttd
19:03:15 *** DJ_Mirage has joined #openttd
19:03:51 <glx> you don't need to kill it
19:04:06 <peter__> it's annoying if it should be able to do an incremental link though
19:04:19 <Arbitrary> is it my imagination or does visual studio have the slowest linker known to man?
19:04:40 <peter__> Arbitrary, it does a lot of optimization during linking
19:18:18 *** XeryusTC has joined #openttd
19:19:37 *** |Jeroen| has joined #openttd
19:31:10 <Eddi|zuHause> did you get further with your realistic signalling?
19:32:43 <Tekky> hi, yes, I have gotten further and I also have written some code. However, I don't want have a working version yet and I don't want to write any more code until the issues are sorted out that are discussed in these two threads:
19:34:24 <Tekky> My main concern is compatibility with traditional OpenTTD signalling.
19:36:20 <Tekky> I don't want to create a fork of OpenTTD that would split the OpenTTD community, by forcing people to only either use the traditonal signals or the new PBS signals, but not both.
19:36:59 <hylje> i'd think a better (optional) design is better than pure tradition
19:37:59 <Belugas> it's better to support both, in my opinion
19:38:12 * Sacro has been fiddling with the signals
19:38:33 <peter__> especially with something as fundamental as signals
19:38:49 <Belugas> or at least, make it so that new system emulates the old system on demand...
19:39:21 <Eddi|zuHause> if it's too much of a hassle to support a mixture, only support one version depending on (per player?) setting
19:39:51 <Belugas> it all depends on how the systems are implemented...
19:40:36 <Belugas> if it is some kind of pluggable objects, it should be fine to support 2, 3 ,a gazillion systems
19:41:16 <hylje> country support, incompatible systems >:)
19:41:19 <Eddi|zuHause> yeah, it'd be best if all current networks would be usable with the new signalling system
19:41:42 <hylje> (but a new replacement is better than nothing at all)
19:42:36 <Belugas> a new replacement.... we have an old replacemtn?
19:42:39 <Tekky> I had initally planned to offer only limited support for tradititional signals, as described in this post:
19:42:41 <Belugas> or we have nothing at all....
19:43:26 <Tekky> However, DaleStan was not happy with that idea :) He wants full support :)
19:43:37 <Belugas> he's not alone in that matter :)
19:44:17 <Tekky> Well, exotic things like priority lines will not work, but I think most layouts will still work.
19:44:26 * DaleStan has very bad memories of last time someone said "Oh, PBS will magically work, and doesn't need this complicated presignal stuff".
19:44:37 <Sacro> DaleStan: yes, it was a bit...
19:45:07 *** BCS|FrozenSnake has joined #openttd
19:46:18 <Tekky> Maybe I should just try to implement my method with limited compatibility for traditonal signalling and see whether this limited support is sufficient.
19:48:01 <Tekky> I think that most station and track layouts will work with my limited support for traditonal signalling, as described in this post
19:48:23 <peter__> DaleStan, i remember suggesting it be ripped out too ;)
19:48:39 <Noldo> is the pbs working in a pbs only environment?
19:48:58 <Belugas> pbs is only available in a ttdp environnement
19:52:19 <Tekky> Noldo: I have no working code yet, because I first need to settle how traditonal signals are to be handled.
19:53:48 <Noldo> pbs signal works like an exit signal when entering pbs and as a pre signal when leaving?
19:53:50 <Tekky> yes, my main concern right now is backward compatibility.
19:54:29 <DaleStan> Noldo: why not "PBS" and "presignal" work entirely independently?
19:55:00 <Noldo> you mean that one user can only have one or the other?
19:55:23 <hylje> the systems are hard to make work together
19:56:03 <hylje> also the benefit might not be anything special
19:57:43 <Eddi|zuHause> i agree with the above post (afaik that was even my suggestion back then)
19:58:16 <Eddi|zuHause> if you hit an exit signal, reserve another part of the track
19:59:51 <Noldo> that is basically the same as treating them like normal piece of track
20:04:50 <Tekky> the main problem is that traditional TTD signalling works with "blocks". However, my PBS signals work with individual track segments, which can be reserved by a train or not. Therefore, these two signalling types are not very compatible.
20:05:30 <Noldo> don't worry about the blocks
20:05:42 <hylje> when the fundamentals conflict
20:05:50 <hylje> the new style should override
20:06:50 <Noldo> think how in your system it is possible to make a thingie that is functionally as similar as possible to a pre signal
20:07:21 <Noldo> there is no problem with the basic signals, right?
20:07:31 <DaleStan> <Noldo> you mean that one user can only have one or the other? <-- No, I mean that there are 8 types. PBS may be added to any of the current 4 signal types, resulting in a total of 8 types, and presignal systems will continue to behave like presignal systems, regardless of the presence or absence of the PBS bit.
20:09:27 *** BCS|FrozenSnake has quit IRC
20:09:32 <DaleStan> <Tekky> Therefore, these two signalling types are not very compatible. <-- "Not compatible within a single block", you mean. Why you have some blocks that are reserved section by section, and other blocks that are "reserved" as a single unit?
20:12:09 <Tekky> DaleStan: Yes, that is possible. But my main concern is how to handle the area between the PBS- and non-PBS area, i.e. the behavior when entering and leaving a PBS area.
20:12:34 *** HerzogDeXtEr has joined #openttd
20:12:59 <DaleStan> If the signal the train is about to pass is a PBS signal, do the PBS thing. If it's a non-PBS signal, do the non-PBS thing.
20:14:14 <Noldo> Tekky: your system does only need one type of signal? (let's forget the unsafes for a little while)
20:14:14 <peter__> it's not just train behaviour
20:14:26 <peter__> there's the routines that update signal state
20:16:49 <Eddi|zuHause> i would do away with the block behaviour altogether, and then introduce "compatibility" signals, that simulate the block behaviour, and while that switch is activated, maybe disable some of the more advanced new signal behaviours (e.g. different levels of "weak reservations")
20:17:27 <DaleStan> Maybe I'm just too TTDPatch-centric, but what does PBS have to do with the signal state? Either the signal is red or the signal is green. PBS only changes whether the train will pass the signal, not what state the signal shows.
20:18:17 <Eddi|zuHause> and that is the wrong approach
20:18:33 <Eddi|zuHause> the signal should show the state that the train will obey to
20:18:42 <Eddi|zuHause> if the signal shows red, then the train must stop
20:18:49 <Eddi|zuHause> if the signal shows red, then the train goes through
20:19:19 <Eddi|zuHause> so the signal must pay attention to what train is trying to go through
20:20:07 <Eddi|zuHause> the "compatibility signal" then knows "oh, that train wants to go to X/Y/Z, whatever, i don't care"
20:20:19 <DaleStan> So change how PBS signals update. Why does this change how the non-PBS signals update? And why does this have to be fixed concurrently with implementing PBS?
20:21:32 <Eddi|zuHause> you suggest "implement the new system, let the old code handle the old system"
20:21:54 <Eddi|zuHause> i suggest "implement the new system, remove the old code, and let the new system simulate the behaviour of the old system"
20:22:13 <DaleStan> Because your solution is so much easier than mine?
20:22:18 <Noldo> and it's not even that hard
20:22:56 <peter__> why haven't you written it then? :)
20:22:58 <Eddi|zuHause> no, because it is The Right Thing(tm)
20:24:01 <DaleStan> So the The Right Thing is also to have everyone run one processor that can execute all instructions from all other processors in the world?
20:24:53 <Eddi|zuHause> noboddy said that...
20:24:57 <Noldo> pre/combo signal show green only when a path to a safe stoping signal signal has been reserved so that the path goes through an exit signal
20:26:30 <Eddi|zuHause> DaleStan: but do 64 bit processors have a 32 bit processor built inside, or rather a 32 bit emulation layer?
20:27:32 <DaleStan> But you said that having both old things and new things is bad, and the new thing should instead simulate the old thing. Therefore any new $FOO should be able to simulate all old @FOO. Why does this change when $FOO = "processor" and @FOO contains both "PPC" and "x86"?
20:29:23 <Eddi|zuHause> where do you think you have seen a "change"?
20:30:26 <DaleStan> Because there are, to my knowledge, no processors that can execute both x86 and PPC binaries, and, to my knowledge, no one who thinks that such processor should exist.
20:32:01 <Eddi|zuHause> but it is a totally different scenario, to create the appropriate analogy, you have $FOO = "new openttd signals" and @FOO = {"old openttd signals", "TTDPatch signals"}
20:32:20 <Eddi|zuHause> we should not attempt that
20:33:27 <Eddi|zuHause> if AMD creates a new generation of 64 bit processors, they are designed to run code that could run on old AMD 32 bit processors
20:33:38 <Eddi|zuHause> not some other company's PPC processors
20:34:50 <Eddi|zuHause> likewise, simulating TTDP's PBS implementation was never the question
20:34:55 <DaleStan> And you have old things and new things, and the new things that can't do what the old thing does. But you just said that new things should emulate the old things.
20:36:13 <Eddi|zuHause> AMD's 32 bit processors could not run PPC programs
20:36:23 <Eddi|zuHause> why should AMD's 64 bit processors do?
20:36:46 <Eddi|zuHause> that is NOT part of "simulate the old behaviour"
20:37:27 <Noldo> not the hacks that are possible only be relying on the details of the implementation
20:37:30 <Tekky> <DaleStan> Maybe I'm just too TTDPatch-centric, but what does PBS have to do with the signal state? Either the signal is red or the signal is green. PBS only changes whether the train will pass the signal, not what state the signal shows. <-- In my new PBS system, signals will react to trains and trains instead of vice-versa. For example, all signals will show red by default and
20:37:40 <Tekky> will only show green when a train has reserved a route past the signal.
20:37:41 *** stillunknown has joined #openttd
20:38:42 <Tekky> whoops, I made a little mistake in my last message. Here it is again: In my new PBS system, signals will react to trains instead of vice-versa. For example, all signals will show red by default and will only show green when a train has reserved a route past the signal.
20:39:03 <Eddi|zuHause> <Tekky> will only show green when a train has reserved a route past the signal. <- exactly, and you can simulate the old behaviour by reserving ALL tracks behind the signal, instead of just the ones the train is going to pass
20:39:22 <Tekky> My new signalling system is therefore train-driven and not signal-driven.
20:39:24 <DaleStan> Which can actually be done in TTDPatch, with PBS and a bit of signal programming. It's quite possible to use programmable signals to make a signal always show red. This is not obviously useful, but PBS allows a train to pass a red signal if it can find a path to its destination.
20:40:10 <Eddi|zuHause> "but PBS allows a train to pass a red signal" <- and that is wrong
20:40:21 <Eddi|zuHause> a train may never ever pass a red signal
20:41:01 <Eddi|zuHause> if i want to program a signal as always red, then i mean that track should never be used until i reprogram that signal
20:41:10 <Noldo> I don't actually see any need to simulate the old behaviour in the lets-reserve-everything way
20:41:28 <Eddi|zuHause> Noldo: i was merely stating that as a possibility
20:41:31 <DaleStan> Fine. I was hoping I could gloss over silly implemetation details like that. "But PBS allows a train to pass a signal that was red before the path reservation succeeded." Better?
20:41:41 <Noldo> it's enough that the real features of presignal system are there in the new system too
20:42:13 <Eddi|zuHause> DaleStan: that is a totally different sentence
20:42:46 <Eddi|zuHause> if a path reservation succeded, the signal should turn green
20:42:55 <Eddi|zuHause> except if i told the signal to never turn green
20:43:13 <Eddi|zuHause> (i.e. unpassable track)
20:43:44 <Eddi|zuHause> in that case, the pathfinder should not even attempt to reserve that track
20:44:26 <Eddi|zuHause> (the use of that is "trains should not pass this track, but i do not want to remove it, in case i need it later")
20:44:53 <DaleStan> <Eddi|zuHause> except if i told the signal to never turn green< -- But you didn't. Not entirely, anyway. You also told it to "behave like a PBS signal." And "behave like a PBS signal" means, "regardless of any other instructions, allow a train to pass if it can find a path." If you want an impassible signal, you have to remove "behave like a PBS signal" from the equation
20:46:32 <Eddi|zuHause> but, there is no reason for a standard game (i.e. not an ultra-traditionalist or a heavy-signal-abuse game) to even have a "behave like PBS" switch
20:46:59 <Eddi|zuHause> because that should be the natural behaviour of a signal
20:47:24 <Eddi|zuHause> together with "show red if no path is reserved"
20:51:54 <DaleStan> So signal-abuse games won't work on new versions of OpenTTD? That would be a bug, not a feature.
20:52:16 <Eddi|zuHause> i already gave the solution for that
20:52:52 <Eddi|zuHause> have a switch "use compatibility signals", which then changes the track reservation algorithm of the standard signals
20:53:45 <SmatZ> I didn't read all the text you have written - but isn't the red or green for PBS signals just a cosmetic feature?
20:54:07 <DaleStan> But what happens on MP games where some want compatibility signals and others want PBS?
20:54:34 <hylje> the server owner decides
20:54:50 <Eddi|zuHause> DaleStan: like YAPF settings, these can be player based
20:56:17 <DaleStan> SmatZ: Basically, yes. In fact, the red/green state is cosmetic for all signals. All that is really relevant is the presence or absense of a signal, and under what circumstances it would allow a train to pass. Whether it would allow a completely non-existent train to pass were it to materialize right now is uninteresting.
20:57:03 <Noldo> no it's not cosmetic in the presense of presignals
20:57:14 <DaleStan> If they are player-based, then one player chooses new, and another player joins the company and chooses compatibility.
20:57:39 <Eddi|zuHause> DaleStan: that is up to the players to fight out...
20:57:40 <Noldo> the behaviour of presignals depends on the the states of other signals
20:57:49 <DaleStan> Yes, it is. If there is no train, whether the train could pass is uninteresting, and if there is a train, then you look to see whether or not it is passing.
20:58:20 <DaleStan> Having the state displayed to the player does not change how the game works internally.
20:58:31 <SmatZ> DaleStan: that is a deep thought... we can have game without any signals when there is "working PBS" (virtual signal on each trackdir)
21:01:20 <Noldo> and the signal states in priorities are resting on imaginary trains taking paths that normal trains can't take
21:01:56 <SmatZ> Noldo: well... priorities are a bit hacky thing :) but you are right
21:03:18 <SmatZ> DaleStan: is it a problem to use different pathfinder and different signalling system for different players? based on for example _current_player and tile owner
21:03:39 <Eddi|zuHause> anyway, what i am trying to say is we should "deprecate" the old signal behaviour, and only allow it on special demand (like the disable elrail switch)
21:03:53 <ln-> who's familiar with Cocoa? (and is here)
21:04:36 <SmatZ> Eddi|zuHause: once there is working PBS... :-)
21:04:40 <Eddi|zuHause> SmatZ: pathfinder i don't know exactly, but all the yapf details (penalties etc.) are per company
21:05:44 <Eddi|zuHause> KUDr designed the system exactly because every player can use the settings that fit best their network
21:05:50 <Eddi|zuHause> and not depend on server settings
21:09:31 <SmatZ> it is not in the player struct
21:10:14 <Eddi|zuHause> i don't know how that is implemented, but it was said it does that...
21:11:26 <SmatZ> only network server can change YAPF settings
21:11:39 <SmatZ> but even if it was not implemented, it could be done...
21:13:38 <hylje> serves me right for not autosaving
21:31:42 <Tekky> <SmatZ> DaleStan: that is a deep thought... we can have game without any signals when there is "working PBS" (virtual signal on each trackdir) <--- Yes, this also exists in reality. For example, here in Germany, all trains that go beyond 160 km/h (100mph) don't obey any standard train signals. Instead, the train's maximum speed is at all times controlled by the CTC (centralized traffic control).
21:32:39 <Tekky> This could also be implemented into OpenTTD, but I think it would be boring.
21:32:48 <Tekky> I prefer real signals :)
21:36:34 <Tekky> However, such a feature would be cool to have, as a patch which can be disabled.
21:37:22 <Eddi|zuHause> "drive on sight" for trains <60km/h?
21:38:03 <Eddi|zuHause> (also limited weight)
21:39:02 <peter__> disable collision detection
21:40:13 <Tekky> hehe, I once made a patch which disabled trains from obeying signals. I made all trains think that signals show green. Before I activated the patch, I had 140 trains on my network. A minute later, I had only about 4 or 5 trains on my network :)
21:40:22 <Eddi|zuHause> yeah, only the "realism" part gets... "left on the track" (we germans say)
21:41:12 <Eddi|zuHause> Tekky: that probably beats Sacro's PBS experience ;)
21:42:27 <Tekky> hehe, what did Sacro do? :)
21:42:54 <Eddi|zuHause> i think it was Brianetta who made signal-free networks and relied on the timing of trains so they wouldn't collide
21:43:35 <Eddi|zuHause> Tekky: due to PBS's implementation, crashed trains release their reservation before they are fully cleared, causing the next train to enter and collide with the remains
21:43:46 <Brianetta> and it screwed up eventually
21:43:57 <Brianetta> and once we had timetables, it tended to screw up even faster
21:44:32 <Brianetta> OpenTTD's timetables are useless, because they can't do the one thing that timetables are really there for:
21:44:44 <Brianetta> Guaranteeing a space for the next train
21:44:56 <Brianetta> When my express arrives, I want the platform to be empty for it
21:45:07 <Brianetta> I want trains to arrive no-earlier-than
21:45:17 <Brianetta> but the timetables only work to no-later-than
21:45:26 <Eddi|zuHause> yeah, timetables need synchronisation measures
21:46:10 *** Draakon has joined #openttd
21:46:47 <Eddi|zuHause> what i found lacking was the ability to show times relative to another train, so i could not schedule "leave station when opposite train arrives"
21:47:23 <Eddi|zuHause> so the trains always locked up on the single-track sections
21:48:18 <Eddi|zuHause> timetables could have been a static solution for that
21:48:23 <Brianetta> I want timetables to have a basic "leave at <time>" capability
21:48:26 <Eddi|zuHause> but without synchronisation, it can't do that
21:48:28 <Brianetta> and there to be a pseudo-clock
21:48:58 <Brianetta> not a time relative to the last time the train fucked up / got stopped / manually reset
21:50:31 <Tekky> Once my new PBS system is running, the signalling system will be train-driven and no longer signal-driven, as it is now. Therefore, I plan to introduce programmable trains in contrast to TTDPatch's programmable signals. Programmable trains seem more meaningful than programmable signals in a network which is train-driven and not signal-driven. Maybe the timetables could be
21:50:31 <Draakon> what train set should i use for "World Scenario": UKRS, USSet, DBSet, TTDOriginal(not maglev&monorail?
21:50:44 <Tekky> implemented as programmable trains?
21:50:56 <Eddi|zuHause> "train 1 leave station A at 9:00", "train 2 leave station B at 10:00", "train 1 and train 2 meet at station C at 12:00"
21:51:18 <Brianetta> Tekky: I have no idea what you're talking about
21:51:56 <Tekky> Brianatta: Do you know TTDPatch's programmable signals?
21:51:57 <Brianetta> Draakon: PBS doesn't explain anything
21:51:57 <Eddi|zuHause> Tekky: yes, trains should choose which signal to go to, not signals choose where the train should go
21:52:21 <Brianetta> I use Linux, so I play OpenTTD
21:52:35 <Draakon> but anyway what train set should i use for "World Scenario": UKRS, USSet, DBSet, TTDOriginal(not maglev&monorail?
21:52:51 <Eddi|zuHause> Draakon: all 4 :p
21:53:29 <Eddi|zuHause> plus tropic set, australian set, japan set, ...
21:54:07 <Eddi|zuHause> and before you start, implement different namespaces for vehicle IDs for each grf
21:54:50 <Draakon> as use of multiple sets future has not been coded yet
21:55:47 <Draakon> or do you have a patch that adds that feature?
21:56:52 <Eddi|zuHause> why would i? i told you to implement it first ;)
21:58:33 <Eddi|zuHause> then you have a task, go for it ;)
22:00:27 <Draakon> i let others to do it
22:00:57 <Eddi|zuHause> that's not the way how opensource works ;)
22:01:10 <Draakon> i dont know how do code
22:01:30 <Eddi|zuHause> then what are you doing here?
22:04:53 <Draakon> are there any ways to get TTD on mobile phone?
22:05:53 <pv2b> Draakon: that'd be a very involved task. typically mobile phones only run software written in java (mobile edition)
22:06:25 <pv2b> there was a port of openttd to maemo (nokia's OS for internet tablet) at one point, but i think it's dead
22:06:37 <pv2b> maemo is based on linux and x11, so that wasn't *too* hard
22:06:55 <pv2b> also, i guess it wouldn't be impossible to port it to a platform like openmoko either, if somebody wanted to do it.
22:07:13 <peter__> nokia's internet table isn't a mobile phone, heh
22:07:35 <pv2b> peter__: no, but it's the closest thing to a mobile phone openttd has ever run on to my knowledge
22:07:45 <pv2b> unless it runs on some other kind of PDAs
22:08:06 <pv2b> speaking of that, i guess it might be portable to windows mobile, i dunno
22:08:25 <pv2b> or even to symbian, but i doubt there's SDL for any of those
22:12:30 <peter__> it runs on my pocketpc pda/phone thing
22:13:59 <Draakon> how can SVN download for example r8000 files from svn.openttd.org/trunk as there are latest revision files?
22:15:18 <pv2b> Draakon: custom http headers i guess, not sure.
22:15:23 <glx> pv2b: it should be possible to have a windows mobile build with a little work
22:15:37 <Eddi|zuHause> Draakon: svn co -r XXXX?
22:15:58 <pv2b> one thing to remember though, openttd is bound to be rather crap on mobile devices as the architecture for multiplayer works now
22:16:36 <pv2b> the entire world has to be calculated locally for all players for them to sync up, for bigger games, a small device like a handheld might not be able to keep up, and it'll certainly suck quite a bit of battery
22:17:03 <pv2b> that's also a problem that can't really be solved without some rather involved changes to openttd
22:17:11 <Draakon> Eddi: i dint ask how i can to it, i asked how it is possibile to have 11719 revisions or more files there if trunk svn folder contains only latest revison files?
22:17:48 <pv2b> Draakon: it doesn't contain only latest revision files, it *appears* to contain only latest revision files :-)
22:18:11 <Eddi|zuHause> Draakon: it will have older files if they have not been changed in between
22:18:14 <pv2b> hidden away are the diffs that you can apply backwards to get to whatever revision you can get, and the svn server will perform that for you, i guess
22:18:15 <Draakon> then how is it all possibile?
22:18:22 <pv2b> if you send the right commands to the web servder
22:18:27 <pv2b> which a simple web browser won't
22:18:58 <pv2b> remember, there's more to a http request than "get this URL for me"... you can have lots of different fields in there, i'm not sure if that's how svn specifically operates. hell, grab a packet sniffer and find out :-)
22:19:22 <Draakon> but STILL i want to know what train set should i use for "World Scenario": UKRS, USSet, DBSet, TTDOriginal(not maglev&monorail?
22:20:57 <Draakon> but what is the best?
22:21:28 <peter__> oh wait, that's special
22:21:44 <pv2b> Draakon: whatever you like the best. it's your scenario :-)
22:22:01 <UnderBuilder> openttd in java mobile edition is impossible right?
22:22:05 <Draakon> i dled off the internet :P
22:22:21 <Draakon> peter__:whats special?
22:22:35 <glx> use all grfs at the same time
22:23:22 <Eddi|zuHause> UnderBuilder: not if you find a C++ to bytecode compiler, plus some libraries
22:24:17 <pv2b> also, openttd is probably way too big for most mobile phones
22:24:40 <pv2b> at the very least in cpu power requirements
22:25:05 <Rubidium> it won't work on my mobile phone ever, that's for sure ;)
22:25:17 <Draakon> eh it does work mostly but some needed wagons are missing
22:25:19 <pv2b> Rubidium: heh, what do you have? :-)
22:25:28 <Draakon> bwt guys i asked about TTD not OpenTTD
22:25:41 <Rubidium> el-cheapo phone age 5
22:25:45 <Eddi|zuHause> cpu power is not really "required", it would just run slow... but memory is often a real limitation
22:25:53 <Draakon> are there any ways to get TTD on mobile phone?<--- that was my question
22:26:22 <Rubidium> i.e. only a few kbytes of storage for a few phone numbers
22:26:33 <pv2b> Draakon: ah, in that case, hmm... well... not really. there isn't any source code for ttd. it was written in x86 assembler. cell phones don't run x86.
22:26:59 <UnderBuilder> the DS port looks great
22:26:59 <pv2b> that'd be even harder than gettingo penttd to run
22:27:03 <Draakon> hehe we can run almost multiple sets at the time :D
22:27:14 <Eddi|zuHause> except if you could get vmware to run a virtual windows on your mobile phone :p
22:27:15 <pv2b> unless..... you could get dosbox to run on your cell phone, and even then it'll suck
22:27:20 <pv2b> Eddi|zuHause: dosbox, not vmware :-)
22:27:20 <UnderBuilder> PSP or internet table?
22:27:34 <pv2b> (does ttd run under dosbox?)
22:27:43 <Rubidium> the dos version does
22:27:48 <peter__> the nokia 9000 ran x86
22:28:01 <Eddi|zuHause> pv2b: but that'd be less a ressource hog :p
22:28:23 * Draakon start playing with multiple sets now
22:28:36 <pv2b> Eddi|zuHause: vmware won't run on a cell phone, it virtualizes. cell phones do not have x86 processors in hem.
22:28:49 <pv2b> wel, yeah, except the early nokia communicators as peter__ says
22:29:05 <pv2b> but then they had monochrome or grayscale screens at best.
22:29:24 <Eddi|zuHause> i played TTO on my monocrome laptop...
22:29:30 <Draakon> who then coded support for OpenTTD to use multiple train sets? :P
22:29:37 <UnderBuilder> I want OTTD for GB!
22:29:58 <pv2b> come on now, can't be that hard to fit into 32 kB of memory ;-)
22:30:11 <glx> and you need to convert it to z80
22:30:20 <Eddi|zuHause> it wasn't actually monochrome... it used like 4 grey levels to simulate 16
22:30:48 <UnderBuilder> no, the ultimate conversion should be: C64!
22:31:11 <Eddi|zuHause> Draakon: who is listed as "the descendant of newgrf gods"?
22:31:11 <Draakon> hmm question: if i am running 2048x2 map and save while not pause, does savegame get damaged or something while i do save on pause on the same map?
22:31:17 <pv2b> i wonder if you could hack together some kind of remote display driver for openttd, like a kind of light-weight vnc, but slightly better, with local graphics rendering from cached bitmaps
22:31:39 <ln-> Draakon: that's quite a thin map
22:31:41 <pv2b> then you could run it on practically anything
22:31:52 <UnderBuilder> what about segacd?
22:31:53 <Rubidium> Draakon: the savegame only gets damaged when the application gets killed abruptly
22:32:05 <Rubidium> (or your hardware is really broken)
22:32:39 <glx> and you can't issue 2 save commands at the same time
22:33:09 <Rubidium> because for the actual saving the game is always paused; it's only the compression and writeback to the disk that is done asynchroniously
22:33:11 <UnderBuilder> (megadrive cartridges has got 40mb limit, thats why I said segacd)
22:33:13 <Eddi|zuHause> glx: i think he meant autosave and manual save
22:35:44 <pv2b> finally, openttd should clearly be ported to the web 2.0 platform.
22:35:58 <pv2b> then you could use your cell phone web browsers to play. or something.
22:36:27 <pv2b> then you could also add some myface integration or something
22:38:02 <Draakon> dbset and us set work togheter
22:38:03 <peter__> ok, maybe a bit too many...
22:38:09 <peter__> Draakon, no they don't
22:38:15 <peter__> they just don't disable each other, heh
22:38:28 <Draakon> i have dbset and usset loaded at the same time
22:38:57 <peter__> but the vehicles will be messed up
22:40:05 <Draakon> i want to get the same effect with UKRS and DBset but fail as one only shows up
22:41:15 <Eddi|zuHause> Draakon: why do you even try if you got told it wasn't possible multiple times?
22:41:46 <SmatZ> peter__: is the NSW XP-Class using the right GRF ?
22:41:51 <Draakon> because i want, and it wasnt sayed multiple times
22:47:34 <peter__> and saveload works... without a savegame bump
22:48:22 *** peterbrett has joined #openttd
22:50:26 * pv2b is playing on a server with the latest nightly, but nobody else is :-/
22:52:07 *** Osai is now known as Osai^zZz
22:52:40 <Tekky> what is a savegame bump? Is that changing the version number of the savegame format?
23:28:31 *** Gonozal_VIII has joined #openttd
23:29:06 <Sacro> right then, what did i miss?
23:30:02 <peter__> me playing with as many vehicle sets loaded as possible?
23:30:23 <Gonozal_VIII> you missed nothing, i wasn't here so nothing could have happened
23:31:11 <peter__> Sacro, scroll back about an hour, heh
23:31:19 <Sacro> peter__: i am going through my irssi logs
23:33:08 <pv2b> Rubidium: you want to know why nobody plays the nightly online? because nobody plays the nightlies online :-/
23:33:24 <Sacro> Rubidium: cos Brianetta stopped his nightly UKRS server :(
23:33:52 <Gonozal_VIII> nobody plays the nightlies online with advertise
23:34:00 <peter__> hmm, i should set up another server some time
23:34:06 <pv2b> there's one nightly server online right now
23:34:11 <pv2b> but i'm the only person on it
23:34:16 <Sacro> peter__: yes, i did enjoy your nightly server too
23:34:22 <pv2b> Sacro: standard, tempereate.
23:35:07 <pv2b> yeah. temperate is boring compared to other climates, but still.
23:39:28 <Eddi|zuHause> they h4xx0r3d y00
23:41:06 <Sacro> pv2b: i was reading them
23:41:13 <Sacro> and when i closed the window, irssi lost them :(
23:41:43 <Eddi|zuHause> cat /wherever/your/logfiles/are/stored.log?
23:42:35 <Eddi|zuHause> i am sure he could find the logs if he really wanted to :p
23:43:03 <Sacro> Eddi|zuHause: yes, cat sucks though
23:43:10 <Arbitrary> train timetabling - how about "synchronous" orders, like shared orders but only one vehicle is allowed to occupy one order on the list at once, they all swap orders at the same time when they're all ready? hmm
23:43:21 <pv2b> Sacro: they're not complete though
23:43:47 <pv2b> Arbitrary: that'd be awesome, but it's already implementable if you have a dedicated line for those two trais
23:43:52 <Eddi|zuHause> Arbitrary: that is quite stupid...
23:44:21 <pv2b> really, i think timetabling should more generally be able to enforce consistent spacing between vehicles
23:44:27 <pv2b> there was this patch on the forams that did that i think
23:44:46 <Brianetta> timetabling absolutely positively definitely needs one thing
23:44:52 <Brianetta> at the moment, all we have is a table.
23:45:30 <Brianetta> So, is the 17:15 from Pruntingville running latE?
23:45:50 <pv2b> click it and find out. you won't know it was late until it arrives though :-)
23:45:59 <Arbitrary> pv2b - now do it with busses :)
23:46:02 <Brianetta> The time should pass at one minute per day.
23:46:06 <Prof_Frink> Schoedinger's train.
23:46:10 <Brianetta> There should be a 123 hour clock.
23:46:40 <pv2b> simutrans does 24 hours per month
23:46:43 <Brianetta> and an order should have a time associated with it, and a repetition interval.
23:46:50 <pv2b> so the current time is something like 12:00 March 1959
23:47:00 <Brianetta> pv2b: That's the idea, yes
23:47:08 <Sacro> Eddi|zuHause: DAMN YOU FOR MENTIONING MY PBS "ISSUES"
23:47:10 <Brianetta> and I've notplayed Simutrans since it was a shite alpha
23:47:18 <pv2b> is simutrans nonshite yet?
23:47:22 <Eddi|zuHause> Sacro: i knew that'd come sooner or later :p
23:47:23 <pv2b> i dunno since it won't run on my ppc mac
23:47:35 <Brianetta> I disliked it for putting too much track down at junctions
23:47:36 <pv2b> it has some cool concepts though
23:47:41 <Brianetta> You can't just have a fork, oh no
23:47:41 <pv2b> at least when i last checked it out
23:47:43 <Sacro> and curses to Brianetta for bringing it up in the forums and irc :p
23:47:45 <Brianetta> got to be a three-way
23:48:11 <pv2b> i liked cargo destinations in simutrans.
23:48:13 <Brianetta> Sacro: You'd even settle for a fork
23:48:28 <pv2b> i dislike the fact that hajo seems to be too insecure to release it as open source :-/
23:48:31 <Sacro> Brianetta: depends what is on the prongs
23:49:59 <Sacro> yes, a crashed train released the track when the front engine got clearerd
23:50:10 <Sacro> but when there is still all the wagons on the line
23:50:19 <Sacro> RIP all 8 trains :( t'was a sad day
23:50:28 <Sacro> I think Brianetta found it quite amusing
23:51:23 <CIA-1> OpenTTD: glx * r11749 /trunk/src/ (7 files): -Fix (r11352): when a bankrupted company is bought, reset vehicle color mapping so the vehicles use the new owner color
23:52:09 <Gonozal_VIII> sacro... easy fix: let the wagons be removed first and engine last
23:52:39 <Sacro> Gonozal_VIII: or not clear the TC until everything has gone
23:52:47 <Eddi|zuHause> hm... does the tropic renewal set not enforce being in tropic climate or is there something wrong with the "activate compatible grfs" routine?
23:53:33 <Brianetta> I just checked. Simutrans still has over-simplified track laying, meaning no simple forks. Therefore, it is still shite.
23:53:35 <Gonozal_VIII> but i guess that's not so easy because the reservation depends on the engine id?
23:53:43 <Eddi|zuHause> i have an old dbset/alpine game which had tropic renewal set in the list (inactive), and when i load that game, the mail wagons of the dbset get overriden
23:54:35 <CIA-1> OpenTTD: glx * r11750 /trunk/src/ (6 files): -Revert (r11749): commited too much
23:58:38 * pv2b curiously investigates what glx committed by mistake :-)
continue to next day ⏵
