Config
Log for #openttd on 25th January 2011:
Times are UTC Toggle Colours
00:03:18  *** Zuu [~Zuu@h-114-141.A98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds]
00:04:12  *** goblin [~goblin@krlh-5f72ede3.pool.mediaWays.net] has quit [Quit: leaving]
00:14:51  *** jonty-comp [~jonty@borealis.jontysewell.net] has quit [Ping timeout: 480 seconds]
00:20:53  *** rhaeder [~quix0r@dslb-188-100-223-233.pools.arcor-ip.net] has quit [Quit: Leaving.]
00:25:03  *** Progman [~progman@p57A1B1C4.dip.t-dialin.net] has quit [Remote host closed the connection]
00:39:09  *** DJNekkid [~thomas@static128-249.mimer.net] has quit [Ping timeout: 480 seconds]
00:44:51  *** xiong [~xiong@netblock-68-183-230-152.dslextreme.com] has quit [Ping timeout: 480 seconds]
00:57:26  *** Chruker [~no@87-104-39-161-dynamic-customer.profibernet.dk] has quit []
01:04:09  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has quit [Quit: TschÌß]
01:04:17  *** pugi [~pugi@p4FCC5E24.dip.t-dialin.net] has quit [Quit: I reject your reality and substitute my own]
01:22:59  *** KenjiE20 [~KenjiE20@92.11.14.158] has quit [Quit: WeeChat 0.3.4]
01:28:32  *** jonty-comp [~jonty@borealis.jontysewell.net] has joined #openttd
01:56:12  *** Lakie [~Lakie@91.84.251.149] has quit [Quit: Sleep.]
02:04:40  *** KritiK [~Maxim@95-26-101-109.broadband.corbina.ru] has quit [Quit: Leaving]
02:17:18  *** JOHN-SHEPARD [~JOHN-SHEP@ALyon-158-1-162-193.w86-209.abo.wanadoo.fr] has quit [Ping timeout: 480 seconds]
02:25:21  *** glx [glx@2a01:e35:2f59:c7c0:588f:3f59:3fb3:d814] has quit [Quit: bye]
02:27:46  *** JOHN-SHEPARD [~JOHN-SHEP@ALyon-158-1-63-138.w90-29.abo.wanadoo.fr] has joined #openttd
02:43:56  *** Netsplit charon.oftc.net <-> kilo.oftc.net quits: Fuco, Maedhros, Markavian, Chris_Booth
02:44:43  *** Netsplit over, joins: Fuco, Maedhros, Chris_Booth, Markavian
02:59:35  *** Fuco [~dota.keys@fntb.sks3.muni.cz] has quit [Ping timeout: 480 seconds]
03:06:30  *** tokai|noir [~tokai@port-92-195-176-95.dynamic.qsc.de] has joined #openttd
03:12:46  *** tokai|mdlx [~tokai@port-92-195-191-44.dynamic.qsc.de] has quit [Ping timeout: 480 seconds]
03:29:42  <Eddi|zuHause> ah... furry-heating-cushion-that-makes-miau
04:17:31  *** Eddi|zuHause2 [~johekr@p54B76BC3.dip.t-dialin.net] has joined #openttd
04:17:31  *** Eddi|zuHause [~johekr@p54B76BC3.dip.t-dialin.net] has quit [Read error: Connection reset by peer]
04:20:16  <z-MaTRiX_nonidentified> hey-ho
04:39:35  *** Eddi|zuHause2 [~johekr@p54B76BC3.dip.t-dialin.net] has quit [Remote host closed the connection]
04:40:02  *** Eddi|zuHause2 [~johekr@p54B76BC3.dip.t-dialin.net] has joined #openttd
05:13:15  *** Dreamxtreme [~Dre@92.30.96.65] has quit [Read error: Connection reset by peer]
05:13:24  *** Dreamxtreme [~Dre@92.30.96.65] has joined #openttd
05:13:28  *** Dreamxtreme [~Dre@92.30.96.65] has quit []
05:20:41  *** ar3k [~ident@87-239-75-101.internetia.net.pl] has quit [Read error: Connection reset by peer]
05:21:23  *** ar3k [~ident@87-239-75-101.internetia.net.pl] has joined #openttd
05:24:01  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd
05:29:19  *** Dreamxtreme [~Dre@92.30.96.65] has joined #openttd
05:56:02  *** Eddi|zuHause2 [~johekr@p54B76BC3.dip.t-dialin.net] has quit [Remote host closed the connection]
05:56:18  *** Eddi|zuHause2 [~johekr@p54B77DC9.dip.t-dialin.net] has joined #openttd
06:01:31  *** z-MaTRiX1nonidentified [~matrix@coming.soon.it] has joined #openttd
06:02:51  *** z-MaTRiX_nonidentified [~matrix@coming.soon.it] has quit [Ping timeout: 480 seconds]
06:06:32  *** Doorslammer [770b12ca@ircip3.mibbit.com] has joined #openttd
06:10:15  *** Doorslammer [770b12ca@ircip3.mibbit.com] has quit []
07:11:03  *** Zuu [~Zuu@h-114-141.A98.priv.bahnhof.se] has joined #openttd
07:11:52  *** xiong [~xiong@netblock-68-183-230-172.dslextreme.com] has joined #openttd
07:15:38  *** Prof_Frink [~proffrink@5e06ec12.bb.sky.com] has quit [Ping timeout: 480 seconds]
07:16:22  *** Br33z4hSlut5 [~static.kp@92.68.154.34] has joined #openttd
07:18:01  *** Kurimus [Kurimus@dsl-tkubrasgw1-fe86de00-46.dhcp.inet.fi] has joined #openttd
07:23:11  *** xiong [~xiong@netblock-68-183-230-172.dslextreme.com] has quit [Quit: Leaving]
07:24:51  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds]
07:31:35  *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd
07:35:48  *** goblin [~goblin@krlh-4d0352e3.pool.mediaWays.net] has joined #openttd
07:44:59  *** goblin [~goblin@krlh-4d0352e3.pool.mediaWays.net] has quit [Quit: leaving]
07:45:46  <Terkhen> good morning
07:52:03  *** Zuu [~Zuu@h-114-141.A98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds]
08:02:21  *** FauxFaux [faux@compsoc.sunion.warwick.ac.uk] has quit [Ping timeout: 480 seconds]
08:06:32  *** goblin [~goblin@krlh-4d0352e3.pool.mediaWays.net] has joined #openttd
08:09:37  <planetmaker> moin
08:13:33  *** DayDreamer [~DayDreame@94.142.234.1] has joined #openttd
08:13:53  *** TheMask96 [martijn@sirius.ne2000.nl] has quit [Ping timeout: 480 seconds]
08:20:53  *** Pulec [~pulec@static-cl093181068250.unet.cz] has quit []
08:21:32  *** TheMask96 [martijn@wrath.vhost.ne2000.nl] has joined #openttd
08:21:44  *** Guest1555 [~Norbi@deibp9eh1--blueice1n2.emea.ibm.com] has joined #openttd
08:22:26  *** Guest1555 is now known as norbert79
08:22:31  <norbert79> Good morning
08:25:40  *** FauxFaux [~faux@compsoc.sunion.warwick.ac.uk] has joined #openttd
08:27:17  *** bartavelle [~bartavell@bigbox.banquise.net] has quit [Remote host closed the connection]
08:33:36  *** Chrill [Chrill@ip68-8-120-178.sd.sd.cox.net] has joined #openttd
08:45:21  *** Progman [~progman@p57A1B064.dip.t-dialin.net] has joined #openttd
08:46:53  *** heffer [~felix@hyperion.fetzig.org] has joined #openttd
08:56:22  *** valhallasw [~valhallas@s55978e11.adsl.wanadoo.nl] has joined #openttd
09:17:04  *** goblin [~goblin@krlh-4d0352e3.pool.mediaWays.net] has quit [Quit: leaving]
09:28:21  *** Adambean [AdamR@82.hosts.reece-eu.net] has joined #openttd
09:38:09  *** perk11 [~perk11@81.17.157.195] has joined #openttd
09:38:50  *** Chrill [Chrill@ip68-8-120-178.sd.sd.cox.net] has quit [Ping timeout: 480 seconds]
09:39:36  *** perk11 [~perk11@81.17.157.195] has quit []
10:15:49  *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Quit: ENOIRC]
10:15:54  *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has joined #openttd
10:16:01  *** HerzogDeXtEr1 [~Flex@88.130.168.87] has joined #openttd
10:21:53  *** HerzogDeXtEr [~Flex@i59F6BF96.versanet.de] has quit [Ping timeout: 480 seconds]
10:33:49  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has joined #openttd
10:55:33  *** JOHN-SHEPARD [~JOHN-SHEP@ALyon-158-1-63-138.w90-29.abo.wanadoo.fr] has quit [Quit: Quitte]
11:28:37  *** KouDy [~koudy@118.100.112.42] has joined #openttd
11:30:36  *** fjb [~frank@p5DDFD27D.dip.t-dialin.net] has joined #openttd
11:37:31  *** KenjiE20 [~KenjiE20@92.11.14.158] has joined #openttd
11:42:41  *** norbert79 [~Norbi@deibp9eh1--blueice1n2.emea.ibm.com] has left #openttd []
12:18:53  *** valhallasw [~valhallas@s55978e11.adsl.wanadoo.nl] has quit [Ping timeout: 480 seconds]
12:24:37  *** KouDy [~koudy@118.100.112.42] has quit [Quit: Leaving.]
12:28:47  *** KouDy [~KouDy@118.100.112.42] has joined #openttd
12:40:28  *** goblin [~goblin@krlh-4d0352e3.pool.mediaWays.net] has joined #openttd
12:55:47  *** Fuco [~dota.keys@fuco.sks3.muni.cz] has joined #openttd
12:57:55  *** Scuddles [~notme@cm104.epsilon84.maxonline.com.sg] has joined #openttd
13:04:00  *** Wolf01 [~wolf01@host190-236-dynamic.9-87-r.retail.telecomitalia.it] has joined #openttd
13:04:05  <Wolf01> hello
13:05:54  *** glx [glx@2a01:e35:2f59:c7c0:f11f:2d7f:d2c8:e794] has joined #openttd
13:05:57  *** mode/#openttd [+v glx] by ChanServ
13:32:53  *** Wolf03 [~wolf01@host78-160-dynamic.56-82-r.retail.telecomitalia.it] has joined #openttd
13:32:53  *** Wolf01 is now known as Guest1575
13:32:54  *** Wolf03 is now known as Wolf01
13:32:54  *** Guest1575 [~wolf01@host190-236-dynamic.9-87-r.retail.telecomitalia.it] has quit [Read error: Connection reset by peer]
13:37:20  *** Chruker [~no@87-104-39-161-dynamic-customer.profibernet.dk] has joined #openttd
13:41:41  *** Eddi|zuHause2 is now known as Eddi|zuHause
13:43:53  *** dfox [~dfox@ip-94-113-89-201.net.upcbroadband.cz] has joined #openttd
14:00:52  *** Br33z4hSlut5 [~static.kp@92.68.154.34] has quit [Remote host closed the connection]
14:02:38  *** Pulec [~pulec@static-cl093181068250.unet.cz] has joined #openttd
14:03:04  <Belugas> hello
14:16:02  <Wolf01> hello Belugas
14:38:50  *** Br33z4hSlut5 [~static.kp@92.68.154.34] has joined #openttd
14:51:40  *** maddy_ [~plaiho@182.21.240.77.static.louhi.net] has joined #openttd
14:52:25  <maddy_> hi guys
15:09:06  *** HalfBit [~hb@201-43-242-125.dsl.telesp.net.br] has joined #openttd
15:12:33  *** roboboy [~robotboy@CPE-58-173-41-16.nxzp1.ken.bigpond.net.au] has quit [Ping timeout: 480 seconds]
15:28:11  <HalfBit> How exactly is train length and speed calculated when they are in diagonal tracks?
15:28:37  <HalfBit> I'm trying to figure out, but it doesn't seem to follow the Pythagorean theorem
15:30:20  <Rubidium> take a look at TrainLocoHandler; don't know the stuff by heart, but there's definitely no square (root) involved in the calculations
15:31:41  <peter1138> badly :)
15:31:52  <peter1138> in fact the train slows down
15:32:19  <Wolf01> but they are longer
15:32:27  <HalfBit> Yeah... It seems that happens
15:32:51  <HalfBit> they stay in the same "speed", yet, they slow down in reality
15:33:01  <HalfBit> weird
15:34:42  <peter1138> yeah
15:35:09  <planetmaker> fix it ;-)
15:35:12  <peter1138> in fact the graphics (original graphics, anyway) are set up for the wagons to be placed closer together
15:35:44  <peter1138> wolf is correct, the train gets longer, rather than slowing down
15:36:03  <peter1138> if the wagons were correctly positioned it wouldn't get longer
15:36:25  <peter1138> of course it would totally mess up new graphics :p
15:37:22  <HalfBit> That totally explains why my trains were not summing up correctly in my game
15:39:06  <peter1138> hmm, i guess both are correct
15:39:17  <peter1138> if it gets longer while moving then the back end must be slowing down :)
15:40:48  <Rubidium> welcome to the world of time dilation fields ;)
15:41:17  <peter1138> there's a 3/4 factor in there as well mind you
15:41:18  <peter1138> hmm :p
15:42:06  <peter1138> probably should be sqrt(2)/2
15:42:13  <peter1138> 1/sqrt(2) ?
15:42:19  <peter1138> 0.7071 anyway
15:43:21  <HalfBit> This: http://i.imgur.com/1Nfp8.png
15:43:56  <HalfBit> Same speed, they are aligned until one train turns
15:43:58  <peter1138> yeah, that's the usual way of seeing it :)
15:44:10  *** Fast2 [~Fast2@p57AF8ACA.dip0.t-ipconnect.de] has joined #openttd
15:44:18  <peter1138> you should try that with the default graphics
15:44:19  <Eddi|zuHause> 1/sqrt(2) and sqrt(2)/2 are the same thing
15:44:34  <HalfBit> Then they keep the same speed, but the train that runs gets behind the train that goes straight
15:44:37  <peter1138> you'll see that that the original lengths have big spaces, which could've been used tof ix the problem
15:44:44  <peter1138> but the newgrf went along and removed the spaces
15:44:53  <peter1138> Eddi|zuHause, yes, but one of them is the correct way of getting there ;)
15:46:11  <peter1138> i don't remember if opengfx uses original sizes or newgrf sizes
15:46:48  <HalfBit> by default graphics, you mean, the DOS/Windows TTD?
15:47:11  <peter1138> i mean graphics from ttd
15:47:14  <peter1138> yeah
15:47:33  <Eddi|zuHause> i have never used opengfx
15:47:53  <HalfBit> No good, I don't have them
15:48:05  <peter1138> hmm, yeah, opengfx uses a mix
15:48:32  <peter1138> longer lengths in general
15:48:57  <peter1138> but on the intro screen the monorail wagons are shorter vertically
15:50:44  <planetmaker> OpenGFX has fixed graphics for all rail wagons. But the maintainer is a bit short on time currently :-P
15:50:56  <Ammler> HalfBit: this is a unresolveable bug, as the waggons "grow" in the horizontal view, so the waggons in the diagonal view got slower
15:51:12  <peter1138> planetmaker, fixed in what way?
15:51:17  <peter1138> made shorter?
15:51:20  *** blathijs [matthijs@drsnuggles.stderr.nl] has quit [Read error: Connection reset by peer]
15:51:33  <peter1138> Ammler, it's fixable, but you'll get glitches with newgrfs
15:51:44  <Eddi|zuHause> Ammler: the problem is newgrfs expanded the wagons to 32px from 28px.
15:51:59  <Ammler> peter1138: fixeable with remaking every waggon graphic
15:52:12  <planetmaker> peter1138, I have wagon graphics with 28px length for all rail vehicles
15:52:16  <Ammler> Eddi|zuHause: the "bug" is not just with newgrfs
15:52:21  <HalfBit> Ammler: not a problem :-)
15:52:24  <peter1138> Ammler, it is
15:52:27  <planetmaker> DanMacK did an excellent job on that recently
15:52:31  <peter1138> well, ish
15:52:48  <Eddi|zuHause> Ammler: not the "bug", but the "blocker" for the "solution"
15:52:49  <peter1138> i think dbsetxl would probably work okay ;)
15:52:51  <Ammler> we reported that on FS, the ticket got rejected because remaking every graphic would be too much work
15:52:57  <planetmaker> With those new sprites OpenGFX wagon lengths will be like the TTD sprites.
15:53:17  *** blathijs [matthijs@drsnuggles.stderr.nl] has joined #openttd
15:53:29  <peter1138> well would fix it allow the glitches to happen
15:53:39  <peter1138> revert all the 32px depot code :D
15:53:48  <planetmaker> :-D
15:53:50  <HalfBit> For context I'm trying to make two trains that leave one station at the same time to join a single line without blocking, making with a curve, and I was wondering why my calculations were going so wrong
15:54:22  <peter1138> wtf
15:54:24  <HalfBit> It is probably some problem that the people in coop already had
15:54:27  <Ammler> http://bugs.openttd.org/task/1063
15:54:27  <peter1138> well we could fix it and allow the glitches to happen
15:55:01  <Ammler> HalfBit: sometimes we doubled the lines before a direction change
15:55:13  <Ammler> like double bridge
15:55:22  <peter1138> eh, rubidium's comment is a bit
15:55:23  <peter1138> wrong
15:55:33  <peter1138> because the original graphics *were* designed shorter already
15:56:16  <Ammler> peter1138: I guess, the problem might be that it might be impossible to find right length and speed to make it similar in horizontal and diagonal
15:56:38  <peter1138> Ammler, no, it's simple mathmatics
15:56:56  <Ammler> yes, but maybe it would need "half pixels" :-)
15:57:02  <peter1138> as i said, 0.7071
15:57:28  <Eddi|zuHause> Ammler: it's fairly simple to round half-pixels, but being 4 pixels off is more of a problem.
15:57:39  <peter1138> 0.7071067811865475244008443621048490392848 being a bit more ... precise ...
15:57:58  <Ammler> Eddi|zuHause: yes, in such newgrfs, the issue is just more verbose :-)
15:58:01  <V453000> just leave the bug alone and play with it as it is :P
15:58:52  <V453000> there still is a maximum throughput, you just have to count with the curves :)
15:59:07  <peter1138> you'd probably want to add a sub-"unit" for x & y coordinates
15:59:23  <peter1138> 1/16th of a tile atm, iirc
15:59:40  <peter1138> maybe 1/256th of that is precise enough :p
15:59:53  <peter1138> btw
16:00:05  <peter1138> i probably had a patch for that at some point :P
16:00:20  <HalfBit> heh
16:01:09  <Eddi|zuHause> you have a 16x16 grid on a tile, a vehicle is 8 grid-positions (1 down, 2 left), diagonal grid-positions are 1.4 times wider (4 left), so you need 8/1.4 = 5.6 grid positions, which translates to around 22px
16:01:53  <Ammler> planetmaker: at least that is now a good reason, why the opengfx waggons should have same length as ttd
16:02:15  <V453000> Ammler: they dont? :O
16:02:31  <HalfBit> But... if cars become shorter on diagonals, that would mess with signal placement, right?
16:02:41  <Ammler> they had 32px, but some are already shorter
16:02:57  <Ammler> but the reason was just the depot view yet
16:02:58  <V453000> HalfBit: yes
16:03:07  <peter1138> Eddi|zuHause, positions are stored in map coordinates, not pixel coordinates
16:03:16  <Eddi|zuHause> peter1138: yes
16:03:51  <HalfBit> Really, a difficult problem...
16:04:10  <peter1138> i'm not sure where you get 1.4 from in that context
16:04:21  <Eddi|zuHause> 1.4 ~ sqrt(2)
16:04:42  <Eddi|zuHause> i thought that was obvious ;)
16:04:44  <peter1138> that's a big error :p
16:05:23  <Eddi|zuHause> peter1138: if you have to round to whole grid positions, it's probably negligible ;)
16:06:47  <peter1138> that's why i'm saying add a subposition
16:06:53  <Eddi|zuHause> i think the vehicle movement code already has some kind of sub-grid-postion
16:06:56  <peter1138> you can't do it if you don't
16:07:09  <peter1138> hm
16:07:12  <Eddi|zuHause> i mean acceleration etc.
16:07:29  <Eddi|zuHause> but for display, it's always rounded to full grid position
16:07:30  *** KouDy [~KouDy@118.100.112.42] has quit [Read error: Connection reset by peer]
16:07:31  <peter1138> yeah
16:10:29  <peter1138> progress
16:11:35  <peter1138> hmm, advanceposition is *always* 3/4 :S
16:11:56  <peter1138> ahh GetAdvanceDistance
16:12:11  <peter1138> 192 & 256
16:12:22  <peter1138> change that to 181
16:12:40  <peter1138> i think
16:12:48  <peter1138> or maybe
16:13:07  <peter1138> 256 to 271? now i don't know
16:13:41  <peter1138> yeah
16:14:13  <peter1138> no
16:14:14  <peter1138> lol
16:14:28  <peter1138> yeah!
16:14:29  <peter1138> fuck it
16:14:34  * peter1138 gives up
16:17:16  <peter1138> of course, making the whole thing move correctly is another matter
16:17:24  <HalfBit> I can't follow what is happening :-P
16:17:49  <peter1138> the train following code would need to be modified to getadvnacedistance for each wagon, not just the head
16:18:00  <peter1138> that's what makes it slow down
16:18:23  <peter1138> then you'd probably end up with disconnecting trains everywhere :D
16:18:29  <Eddi|zuHause> we should convert to a hex-grid, makes the problems less apparent ;)
16:18:32  <HalfBit> LOL
16:19:00  <Eddi|zuHause> well, it worked fine for civ ;)
16:19:14  <Eddi|zuHause> and it always worked in Siedler ;)
16:19:17  <peter1138> Civ never had 'improved' acceleration ;)
16:19:17  <SmatZ> :)
16:19:24  <SmatZ> civ had hex grid?
16:19:34  <Eddi|zuHause> civ5 has hex grid
16:19:38  <SmatZ> ok :)
16:19:50  <SmatZ> homam had it too, during battles
16:20:10  <peter1138> pfft, hex grid is just a square grid with a slight offset and some stretching
16:20:17  <Ammler> so what first hex grid or 3dmap?
16:20:29  <HalfBit> hex grid is good to make round things rounder (like attack ranges)
16:20:47  <HalfBit> Dunno if it would be useful for something like ttd
16:21:04  <SmatZ> peter1138: indeed :) but imagine trains jumping on that hex-grid transformed to square-grid :)
16:21:18  *** ZirconiumX [561b9bc6@ircip1.mibbit.com] has joined #openttd
16:21:47  *** LordAro [~kvirc@host86-167-85-11.range86-167.btcentralplus.com] has joined #openttd
16:21:52  <ZirconiumX> LOL
16:22:01  <ZirconiumX> hello LordAro
16:22:13  <SmatZ> he's stalking you
16:22:26  <LordAro> hello ZirconiumX :)
16:22:31  *** Br33z4hSlut5 [~static.kp@92.68.154.34] has quit [Remote host closed the connection]
16:22:41  * ZirconiumX kicks SmatZ where it hurts
16:23:23  <SmatZ> /kick ZirconiumX does it hurt?
16:23:50  <ZirconiumX> Ow!
16:23:52  <SmatZ> I really didn't deserve being kicked :((
16:24:32  <LordAro> i lol'd
16:24:47  <Eddi|zuHause> peter1138: hex-grid has the advantage that you don't need all the sqrt(2) magic
16:25:23  <peter1138> good luck with that
16:27:48  <peter1138> reimplementing pretty much... everything ;)
16:27:58  <SmatZ> well, Eddi|zuHause has a point, but it's probably unrealistic for openttd to change...
16:27:59  <peter1138> you might as well add smooth sweeping curves if you do that :D
16:31:40  <peter1138> or allow all freeform movement
16:32:02  <SmatZ> :)
16:32:09  <peter1138> then you'll be doing things based on angle
16:32:34  <peter1138> though you might need to find some fast algorithms that work in fixed point maths to avoid desyncs
16:34:33  <HalfBit> Reimplement everything in OpenGL, allow tracks in all directions, smooth curves, smooth terraforming, realistic grid size/vehicle speed ratios, etc...
16:34:44  <peter1138> yeah! and call it transport empire!
16:34:56  <HalfBit> Leave it to me, I'll do that (someday) ;-)
16:35:08  <SmatZ> :)
16:35:29  *** PhoenixII [~ralph@home.deboom.biz] has joined #openttd
16:35:52  <peter1138> or call it openbve...?
16:36:03  <peter1138> no landscaping there mind
16:36:43  <peter1138> simulating bogies eh?
16:37:19  <HalfBit> good, I didn't know about openbve
16:38:08  <HalfBit> I saw a demonstration on youtube the other day, that allowed to do draw bridges freely
16:38:20  <HalfBit> (any direction, curves, and from different heights)
16:38:41  *** Devroush [~dennis@178-119-81-33.access.telenet.be] has joined #openttd
16:38:55  <HalfBit> If we had at least diagonal bridges and tunnels in OpenTTD oh my, that would be great
16:39:14  <SmatZ> oh you!
16:40:33  *** thomas_ [~thomas@static128-249.mimer.net] has joined #openttd
16:40:39  *** thomas_ is now known as DJNekkid
16:41:36  *** Phoenix_the_II [~ralph@home.deboom.biz] has quit [Ping timeout: 480 seconds]
16:43:11  *** ZirconiumX [561b9bc6@ircip1.mibbit.com] has left #openttd []
16:44:19  <HalfBit> This: http://www.youtube.com/watch?v=jOLhnwllpgs
16:45:27  <SmatZ> I don't think I would want to spend hours building tracks in openttd
16:45:44  <SmatZ> but yeah, it looks nice
16:45:45  <peter1138> some people do
16:45:55  <HalfBit> ??!
16:46:10  <peter1138> i play it for making a transport network
16:46:12  <SmatZ> people have various attitudes when playing openttd, indeed :)
16:46:14  <peter1138> not for making money :)
16:46:18  <HalfBit> I think that most players spend hours building tracks in openttd
16:46:23  <SmatZ> I am a megalomaniac, so I like coop games
16:46:57  <SmatZ> but having to build tracks like in that video, it would take much more time
16:47:34  <peter1138> heh, and one of the related videos is from rigs of rods
16:47:44  <SmatZ> :)
16:51:41  *** Lakie [~Lakie@91.84.251.149] has joined #openttd
16:53:08  *** Zuu [~Zuu@h-114-141.A98.priv.bahnhof.se] has joined #openttd
16:53:45  *** Prof_Frink [~proffrink@5e06ec12.bb.sky.com] has joined #openttd
16:54:56  *** rhaeder [~quix0r@dslb-188-100-223-233.pools.arcor-ip.net] has joined #openttd
16:55:44  *** Tennel [~Tennel@farafin-gate.cs.uni-magdeburg.de] has joined #openttd
17:08:36  *** JOHN-SHEPARD [~JOHN-SHEP@ALyon-158-1-63-138.w90-29.abo.wanadoo.fr] has joined #openttd
17:39:20  *** Scuddles [~notme@cm104.epsilon84.maxonline.com.sg] has quit [Quit: oh]
17:47:18  *** Progman [~progman@p57A1B064.dip.t-dialin.net] has quit [Remote host closed the connection]
17:55:07  *** Tennel [~Tennel@farafin-gate.cs.uni-magdeburg.de] has quit [Quit: Verlassend]
18:19:14  *** Brianetta [~brian@188-220-91-30.zone11.bethere.co.uk] has joined #openttd
18:33:08  *** KenjiE20 [~KenjiE20@92.11.14.158] has quit [Remote host closed the connection]
18:33:58  *** KenjiE20 [~KenjiE20@92.11.14.158] has joined #openttd
18:41:39  *** Fast2 [~Fast2@p57AF8ACA.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
18:45:41  <CIA-1> OpenTTD: translators * r21908 /trunk/src/lang/ (brazilian_portuguese.txt german.txt ukrainian.txt):
18:45:41  <CIA-1> OpenTTD: -Update from WebTranslator v3.0:
18:45:41  <CIA-1> OpenTTD: german - 2 changes by dihedral
18:45:41  <CIA-1> OpenTTD: brazilian_portuguese - 36 changes by Luis_Mizuchiro
18:45:41  <CIA-1> OpenTTD: ukrainian - 3 changes by Fixer
18:51:06  *** Progman [~progman@p57A1B064.dip.t-dialin.net] has joined #openttd
18:52:55  *** ABCRic [~ABCRic@239.212.189.46.rev.vodafone.pt] has joined #openttd
18:59:31  *** DanMacK [~DanMacK@206.191.69.149] has joined #openttd
19:00:11  <maddy_> I need help on making a station where all exiting trains can select between 2 tracks
19:00:55  *** fonsinchen [~fonsinche@brln-4dbc0acb.pool.mediaWays.net] has joined #openttd
19:02:09  *** Chris_Booth [~chatzilla@cpc7-newt30-2-0-cust37.newt.cable.virginmedia.com] has quit [Quit: ChatZilla 0.9.86 [Firefox 3.6.13/20101203075014]]
19:03:40  *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has joined #openttd
19:03:43  *** mode/#openttd [+o Alberth] by ChanServ
19:05:54  *** ZirconiumX [561b9bc6@ircip2.mibbit.com] has joined #openttd
19:07:45  <DanMacK> Hey all
19:07:57  <Markk> Oi
19:10:08  *** dfox [~dfox@ip-94-113-89-201.net.upcbroadband.cz] has quit [Ping timeout: 480 seconds]
19:14:49  *** andythenorth [~andy@87.112.184.144] has joined #openttd
19:16:03  * andythenorth ponders
19:16:13  <andythenorth> industry production multiplier in advanced settings?
19:16:19  <andythenorth> I may regret this idea :P
19:17:15  <ABCRic> sounds kewl
19:18:32  <maddy_> so can anyone give me some tips regarding station exit balancing? I'm trying to look at wikis
19:18:41  <Alberth> industry production multiplier in the newgrf parameters?
19:19:00  <Alberth> hai Andy :)
19:25:25  <andythenorth> hai
19:25:41  <andythenorth> I can code it in newgrf
19:25:45  <andythenorth> or it could be in trunk
19:26:21  <andythenorth> industry code is (in places) disgusting to work with....
19:26:29  <andythenorth> ...but this is probably not a contender for world's hardest patch
19:26:47  *** ZirconiumX [561b9bc6@ircip2.mibbit.com] has quit [Quit: http://www.mibbit.com ajax IRC Client]
19:26:49  <andythenorth> it might need some thought w.r.t edge cases
19:28:56  *** Mucht [~Martin@chello084115143107.3.graz.surfer.at] has joined #openttd
19:33:21  *** pugi [~pugi@p4FCC577E.dip.t-dialin.net] has joined #openttd
19:34:59  *** fonsinchen [~fonsinche@brln-4dbc0acb.pool.mediaWays.net] has quit [Ping timeout: 480 seconds]
19:36:55  *** Fast2 [~Fast2@p57AF8ACA.dip0.t-ipconnect.de] has joined #openttd
19:41:06  *** Chris_Booth [~chatzilla@cpc7-newt30-2-0-cust37.newt.cable.virginmedia.com] has joined #openttd
19:41:50  <Alberth> maddy_: http://wiki.openttdcoop.org/Main_Page    are the professionals with some insane (in a good way) ideas
19:43:29  *** Chris_Booth [~chatzilla@cpc7-newt30-2-0-cust37.newt.cable.virginmedia.com] has quit []
19:44:11  *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has quit [Quit: Leaving]
19:47:19  <maddy_> Alberth: I looked at that, I just realized how signals work in openttd I can't probably do what I wanted
19:48:13  <Alberth> you can always ask at the forums if somebody knows
19:49:18  <Alberth> I never had the need to balance exits much, my games are not that big.
19:50:33  <Ammler> maddy_: basically everything is possible somehow
19:52:25  <Ammler> what you are looking for is quite easy to to do...
19:56:20  *** DanM [~DanMacK@206.191.69.149] has joined #openttd
19:59:46  <Alberth> so what do you want to do what you cannot?
20:01:58  *** perk11 [~perk11@81.17.157.195] has joined #openttd
20:03:41  *** DanMacK [~DanMacK@206.191.69.149] has quit [Ping timeout: 480 seconds]
20:04:00  *** DanM is now known as DanMacK
20:27:34  <Belugas> mmh... building a hierarchy of objects AFTER the first object was completed is a good exercise to improve mess
20:28:21  <Belugas> 1st object puts all common methods in new base, and new child fools around
20:28:51  <Belugas> and usually, at the end, it does not look sane at all and becomes a big spaguetti mess
20:33:44  <Alberth> spaghetti is jummy!
20:34:14  <Alberth> but some chopping and moving is useful when the spaghetti is in code :)
20:34:50  * Alberth hands a knife and fork (or do you need something with a bigger impact?)
20:35:34  <Belugas> dynamite :)
20:35:57  <Belugas> a soldering iron would be good too :)
20:36:50  <Alberth> a clean plate perhaps? I got two new ones from my xmas presents
20:37:05  *** KritiK [~Maxim@89-178-17-128.broadband.corbina.ru] has joined #openttd
20:38:42  <Alberth> it really helps, a colleaque of mine is building a piece of software for the second time, and he thinks it is much easier now :)
20:39:31  <andythenorth> lets do ottd again :)
20:40:20  <Alberth> let's call it P2sim :)
20:42:04  <andythenorth> what would be different?
20:43:19  <Alberth> everything of course, it will do all that openttd doesn't. I will first need to build a CMS to host all the ideas.
20:44:31  <andythenorth> and a project management system
20:44:38  <andythenorth> and a voting system
20:44:48  <andythenorth> and maybe a new language to author in?
20:45:13  <andythenorth> perhaps we can use an existing language, but build a big meta-framework to feed the compiler with?
20:45:23  <andythenorth> we could just define everything with xml
20:45:44  <andythenorth> and the meta-framework would build classes, enums etc for us from that
20:45:55  <andythenorth> it will take years, but think of the time saved!
20:46:23  <Alberth> I was thinking, perhaps we should make a 3D website, to really appreciate all the features.
20:46:52  <andythenorth> we could make ottd browser based
20:47:02  <andythenorth> but we might first want to define a new plugin standard
20:47:11  * andythenorth is fooling instead of writing code :P
20:47:22  *** fonsinchen [~fonsinche@brln-4dbc0acb.pool.mediaWays.net] has joined #openttd
20:47:28  * andythenorth should do something useful
20:47:52  <Alberth> but not too much :)
20:49:19  <andythenorth> Alberth: how is your thinking going on groups?
20:50:17  <Alberth> very good, I found a someone :)
20:50:38  <andythenorth> is there any thing like a spec?
20:51:20  <Alberth> and in the mean time, I try to shuffle trunk into a better shape for both groups and your rv-pony
20:51:33  <andythenorth> pony-wagons
20:51:55  * andythenorth wonders what version of OTTD is needed for HEQS
20:51:57  <andythenorth> I have no idea :P
20:52:44  <Alberth> a spec? what I posted in the suggestion thread comes closest to a spec, I think. I also added some other forum links to your wiki page
20:53:01  <Alberth> 'trunk' is always a good version :)
20:57:34  <Alberth> do you have something else in mind?
21:00:36  <Belugas> Alberth, a clean plate means going back 3 years
21:00:51  <Belugas> and thousands of customers with no more support until the new stuff is done
21:00:54  <Belugas> i'd say...
21:00:57  <Belugas> no
21:01:12  <Belugas> but thanks for the suggestion ;)
21:02:07  <Alberth> so that's going to be a lot of refactoring
21:04:31  *** ABCRic_ [~ABCRic@6.153.54.77.rev.vodafone.pt] has joined #openttd
21:04:31  *** ABCRic is now known as Guest1624
21:04:31  *** ABCRic_ is now known as ABCRic
21:09:14  *** Guest1624 [~ABCRic@239.212.189.46.rev.vodafone.pt] has quit [Ping timeout: 480 seconds]
21:09:55  <andythenorth> hmm
21:10:01  *** maddy_ [~plaiho@182.21.240.77.static.louhi.net] has quit [Quit: leaving]
21:10:05  <DanMacK> hmmm?
21:10:11  <andythenorth> the situation with readme / instructions for newgrfs isn't very satisfactory really
21:10:28  <andythenorth> wrt to bananas
21:10:39  <andythenorth> I'm not sure how to improve it though
21:12:11  <Alberth> simplest solution would be to add a 'README' button that opens a new window with the readme text of the tar file
21:13:08  <andythenorth> I figured something like that
21:13:08  <Alberth> s/text/file contents/
21:13:41  <andythenorth> with a scrollbar on the window...
21:14:08  <Alberth> yep, eg like the message history window ;)
21:14:37  <Alberth> or the industry directory window
21:14:51  <andythenorth> ascii only
21:14:55  <andythenorth> or unicode friendly?
21:15:12  <Terkhen> it should be unicode
21:15:28  <Alberth> if possible, unicode, but no idea how to do that
21:15:54  <Alberth> it implies the readme file has a known encoding
21:16:13  <Rubidium> utf8 should be, or rather is, fine
21:16:13  <Alberth> perhaps some mark at the first line or so?
21:16:55  <andythenorth> enforced 80 char line limit, or wrap?
21:17:04  <Alberth> or by a unanymous vote assume it is utf8 :)
21:17:40  <Alberth> chop off anything at the right, enforcing will happen by itself then :)
21:17:46  <Rubidium> though ASCII is safer
21:18:18  <Rubidium> as everyone should have an ASCII capable font
21:18:29  <Rubidium> like using Cyrillic might not give the best results for the readme
21:19:01  <Alberth> it won't be much worse compared to the current situation either
21:19:46  <andythenorth> the current situation involves writing readmes that aren't read
21:20:00  <Alberth> lies!
21:20:09  <andythenorth> meanwhile trying like crazy to fit set description, instructions + parameter info into 500 chars for bananas
21:20:56  *** Dreamxtreme [~Dre@92.30.96.65] has quit [Ping timeout: 480 seconds]
21:22:06  <Rubidium> parameter stuff belongs in action 14 ;)
21:23:40  <planetmaker> [22:15]	<Alberth>	it implies the readme file has a known encoding <-- that IMHO can be just made a requirement: if you want the readme readable from ingame, use utf-8 encoding. Done
21:25:36  <glx> planetmaker: so ASCII is good enough :)
21:26:01  <planetmaker> from my POV, too, yes. But utf-8 would allow basically most languages
21:26:15  <glx> ASCII is utf-8
21:26:21  <glx> a subset
21:26:21  <planetmaker> oh :-)
21:26:25  <planetmaker> well. yes
21:26:33  <planetmaker> good, then I wasn't wrong ;-)
21:27:29  <Alberth> isn't utf-7 for staying within the 128 characters defined by ASCII?
21:28:27  *** Dreamxtreme [~Dre@92.30.197.143] has joined #openttd
21:28:51  <glx> 0x00 - 0x7F range is valid utf-8
21:29:17  <glx> with only 1 byte
21:30:18  <andythenorth> Alberth: this somewhat has the advantage that you know you're way around the newgrf gui code :)
21:32:02  <planetmaker> for displaying the readme you don't need knowledge of newgrfs ;-)
21:32:09  <Alberth> 'this'?    and    s/you're/your/?    /me thinks andy has some evil plans
21:32:37  <andythenorth> your /s
21:32:44  <andythenorth> as in 'Alberth'
21:32:45  <Alberth> but it's ok if we swap problems, fancy introducing consists into the game?
21:33:05  <andythenorth> I think they're an over-rated concept at the moment
21:33:07  <Alberth> I'd be more than happy to add a window
21:33:23  <andythenorth> all my most-fun games are on islands, with just one or trains per route
21:33:31  <andythenorth> consists are overkill :D
21:33:33  <Alberth> oh, consists with far less functionality than you think
21:33:41  <andythenorth> he
21:33:54  <andythenorth> well...I am busy updating a PDF readme for HEQS that will never be read :P
21:33:58  <Alberth> just a list of data structs, one for each first vehicle
21:34:29  <Alberth> with 'per consist' data in it, like caches and orders
21:34:34  <Alberth> that's all :p
21:34:51  <andythenorth> hmm
21:35:15  <andythenorth> I should understand what that will do.
21:35:19  <andythenorth> but I don't :|
21:35:43  <Alberth> it removes those data structures from the vehicles
21:36:01  <andythenorth> makes sense
21:36:15  <andythenorth> so vehicles can then be replaced in the consist
21:36:31  <andythenorth> without having to shuffle data off to some kind of fake vehicles in between?
21:36:36  <Alberth> eventually, many moons later, that might happen
21:36:57  <andythenorth> how interesting :)
21:38:00  <Alberth> I don't think it is very useful to think about consist-based replacing (or anything else consist-based) at this time
21:38:14  <planetmaker> andythenorth: write it as ascii ;-)
21:38:14  <Alberth> too complex :p
21:38:32  <Alberth> uisng only ASCII C++ code :)
21:38:44  <andythenorth> planetmaker: ascii pictures are somewhat limited
21:39:00  <planetmaker> andythenorth: but pdf display will never be supported ingame ;-)
21:39:09  <planetmaker> ascii is... likely
21:39:10  * SmatZ uses ANSI C :)
21:39:40  * andythenorth proposes writing a PDF renderer
21:39:47  <andythenorth> or more likely...not
21:41:44  <planetmaker> andythenorth: pdf is like avi. Both are ugly container formats
21:42:09  <glx> make it in flash ;)
21:42:12  <planetmaker> and pdf has more security issues than openttd commits
21:42:25  <SmatZ> ::P
21:42:44  <glx> the reader, not the format
21:43:11  <andythenorth> planetmaker: eps renderer :P
21:43:30  * DanMacK is heading out, later all :D
21:43:34  <planetmaker> glx: sure. But... given the complexity of the format...
21:43:34  <andythenorth> or - and this is the current pain for someone I work with - rtf with inlined images
21:43:41  <planetmaker> laters, DanMacK :-)
21:43:48  <andythenorth> bye DanMacK
21:44:09  <glx> rtf is not nice either
21:44:25  <planetmaker> no. But plain ascii is fine enough. I don't find our readme ugly
21:44:32  * andythenorth wants pictues :P
21:44:36  <andythenorth> pictures even :P
21:44:39  <glx> ascii art
21:44:47  <planetmaker> :-)
21:44:53  <andythenorth> thumbnails?
21:45:03  <andythenorth> bandwidth :(
21:45:14  *** DanMacK [~DanMacK@206.191.69.149] has quit [Read error: Connection reset by peer]
21:45:16  <planetmaker> no images. Images are the grf ingame
21:45:25  <andythenorth> true
21:45:57  * andythenorth has an evil idea
21:46:18  <andythenorth> the grf already has nearly everything you could want to know about a vehicle?
21:46:26  <andythenorth> and pictures of it :P
21:47:01  <andythenorth> how about a 'preview' that basically just renders the buy menu - but in newgrf window
21:47:27  <Alberth> andythenorth: a RESt renderer?
21:47:51  <andythenorth> restructured text?
21:47:59  <Alberth> yes
21:48:07  <andythenorth> urch
21:48:23  <Alberth> andythenorth: there are no industry buy pics
21:48:27  <andythenorth> I have a problem with formats like that: to me they look like broken html
21:48:53  <andythenorth> Alberth: nearly the same: use first industry layout
21:49:18  <Alberth> and you cannot explain which other grfs are recommended to be used
21:49:29  <andythenorth> for that the readme is still needed
21:49:41  <andythenorth> I was thinking ahead to 'preview'
21:50:16  <andythenorth> Alberth: basically I have been updating this, which prompted my thoughts:
21:50:17  <andythenorth> http://www.tt-forums.net/download/file.php?id=103700
21:51:41  <Alberth> nice!
21:52:06  <andythenorth> yeah, but hard to distribute
21:52:21  <andythenorth> not bananas friendly
21:52:25  <andythenorth> pretty much tied to the forums
21:52:50  <Alberth> any particular reason Zephyris is mentioned with full name (and the others are not?)
21:53:22  <andythenorth> can't remember
21:53:28  <andythenorth> it's being updated though :)
21:53:53  <Mazur> Heavy pixels may fall.
21:54:14  <andythenorth> it's important to be aware of safety issues :P
21:55:06  <Alberth> good night
21:55:15  <SmatZ> good night Alberth
21:55:17  <andythenorth> night
21:55:42  *** Alberth [~hat@a82-95-164-127.adsl.xs4all.nl] has left #openttd []
21:59:11  <andythenorth> bye
21:59:12  *** andythenorth [~andy@87.112.184.144] has left #openttd []
21:59:26  <Mazur> Soft kitty, warm kitty, little ball of fur.  Happy kitty, sleepy kitty, purr, purr, purr.
22:00:23  *** DayDreamer [~DayDreame@94.142.234.1] has quit [Read error: Connection reset by peer]
22:00:42  <SmatZ> our poemist Mazur :)
22:00:44  *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd
22:00:48  *** DJNekkid [~thomas@static128-249.mimer.net] has quit [Ping timeout: 480 seconds]
22:01:03  <Mazur> Just quoting, SmatZ.
22:01:15  <Mazur> The Big Bang Theory.
22:01:24  <Mazur> Best sitcom ever.
22:01:40  <Rubidium> fonsinchen: any suggestions/ideas for FS#4440?
22:02:47  <Rubidium> to me it looks somewhat tricky at best, if not (sadly enough) impossible to solve
22:03:32  <fonsinchen> What is the problem about having duplicate auto-orders for some time?
22:06:17  <fonsinchen> OK, I think I don't quite get it. I'll check the savegame
22:09:05  *** Adambean [AdamR@82.hosts.reece-eu.net] has quit [Quit: Gone fishing]
22:09:36  <Rubidium> the order before the service order seems to stay in the list indefinitely
22:10:34  *** Fast2 [~Fast2@p57AF8ACA.dip0.t-ipconnect.de] has quit [Ping timeout: 480 seconds]
22:11:05  <fonsinchen> That's a point. We should remove unreached auto orders when skipping a maintenance order.
22:12:00  <Rubidium> though, when you implement that you'll create a situation where:
22:12:23  <Rubidium> * autoservice happens, so Rocca before the service order
22:12:40  <Rubidium> * arrives in Mezza, so Rocca after service order gets removed
22:13:10  <Rubidium> * goes on and arrives at Arezzo, processes service order and skips it removing the stub order for Rocca
22:13:24  <Rubidium> s/stub/automatic/
22:13:46  <fonsinchen> Yes, the service order will show up in different places from time to time.
22:13:47  <Rubidium> leaving you with an order list without Rocca that'd mess up the link graph
22:14:37  <fonsinchen> That's the same as having nondeterministic conditional orders. We can't do a lot about that.
22:15:40  <Terkhen> good night
22:16:11  <fonsinchen> Does it really mess up the link graph? I mean every time it gets to Arezzo it will know that Rocca is the next station.
22:16:26  <fonsinchen> As in some way it has visited Rocca in the last turn.
22:17:00  <Rubidium> true, but what if I add a station between Arezzo and Rocca?
22:17:41  <fonsinchen> The same. It will keep a pair of auto-orders where there is one now.
22:19:10  <fonsinchen> (provided that we remove auto-orders on skipping maintenance)
22:20:03  *** ABCRic is now known as Guest1635
22:20:04  *** ABCRic [~ABCRic@93.196.189.46.rev.vodafone.pt] has joined #openttd
22:20:48  <Rubidium> http://rbijker.net/openttd/poc.sav <- on autoservice run. When reaching Mezza it will remove some automatic orders to both Roccas, after Arezzo it would/should remove the auto orders before the service order. Leaving you without the automatic orders for both Rocca, which means the last Rocca isn't in the order list when the first Rocca is reached
22:23:31  <Rubidium> though I don't really see a solution to that problem that's simple and/or elegant
22:24:19  <Rubidium> you could move automatic orders over the border of service orders, but that'll probably be messy with things
22:24:28  <fonsinchen> We can just say: You created nondeterministic behaviour as we don't know if the stations will be visited before or after the maintenance order.
22:25:05  <fonsinchen> Nondeterministic behaviour leads to cargodist doing strange things.
22:25:19  *** Guest1635 [~ABCRic@6.153.54.77.rev.vodafone.pt] has quit [Ping timeout: 480 seconds]
22:25:25  <Rubidium> unless... you increment the current order index when processing the service order
22:25:47  <Rubidium> then it'll just add automatic orders always after service orders and it's not (that) non-deterministic
22:26:03  <fonsinchen> but confusing
22:26:07  <Rubidium> but given the complexity of the order system there has to be a catch somewhere
22:26:20  <fonsinchen> orders are processed in a different order then shown then.
22:27:48  <Rubidium> hmm, for loading stuff orders are used and then you basically "rebuild" the current order
22:29:06  <Rubidium> I guess that leaves fixing the removal of orders for the service order and a bit of known-bugs.txt about non-determinism and the automatic orders not working "right" in that situation
22:30:49  <fonsinchen> So, either we do the current_order incrementation when processing a maintenance order - then we don't need to remove auto-orders when processing a maintenance order.
22:30:55  <fonsinchen> or we do it the other way round
22:31:07  <fonsinchen> In the first case the order list looks pretty.
22:31:35  <fonsinchen> In the second case we create determinism in that case and it works better.
22:33:29  *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has quit [Quit: Leaving]
22:33:33  <fonsinchen> In any case I won't do it today. Let's decide about that tomorrow.
22:33:35  <Rubidium> I fear the first case might not work unless we'd be using some magic
22:33:54  <Rubidium> in the BeginLoading / EndLoading code
22:34:22  <fonsinchen> Of course we have to suppress incrementing the order index at the next order then, yes.
22:34:27  <fonsinchen> Probably messy.
22:34:30  <Rubidium> to set some magic bits when the vehicle is/was using a depot order
22:35:05  *** a1270 [~a1270@72-24-233-98.cpe.cableone.net] has joined #openttd
22:35:09  <Rubidium> it'll be somewhat messy, but I guess it's (eventually) possible
22:35:59  *** ABCRic [~ABCRic@93.196.189.46.rev.vodafone.pt] has quit [Quit: The bad thing about quit messages is that you never know how people react to them.]
22:36:09  * fonsinchen would need to take a closer look at the code to comment on that but is too tired.
22:36:16  <fonsinchen> good night.
22:36:40  *** fonsinchen [~fonsinche@brln-4dbc0acb.pool.mediaWays.net] has quit [Remote host closed the connection]
22:36:41  *** Kurimus [Kurimus@dsl-tkubrasgw1-fe86de00-46.dhcp.inet.fi] has quit []
22:39:46  <Wolf01> 'night
22:39:52  *** Wolf01 [~wolf01@host78-160-dynamic.56-82-r.retail.telecomitalia.it] has quit [Quit: Once again the world is quick to bury me.]
23:14:27  *** goblin [~goblin@krlh-4d0352e3.pool.mediaWays.net] has quit [Quit: leaving]
23:23:57  *** dfox [~dfox@ip-94-113-89-201.net.upcbroadband.cz] has joined #openttd
23:39:41  *** LordAro [~kvirc@host86-167-85-11.range86-167.btcentralplus.com] has quit [Read error: Connection reset by peer]
23:43:19  *** Zuu [~Zuu@h-114-141.A98.priv.bahnhof.se] has quit [Ping timeout: 480 seconds]
23:48:05  <Ammler> I see the next limit, which needs to be broken :-)
23:52:00  <Rubidium> like?
23:53:44  *** Progman [~progman@p57A1B064.dip.t-dialin.net] has quit [Remote host closed the connection]
23:53:49  *** Chris_Booth [~chatzilla@cpc7-newt30-2-0-cust37.newt.cable.virginmedia.com] has joined #openttd
23:55:54  <SmatZ> all limit are here to be broken!
23:56:01  <SmatZ> limits, too
23:56:36  <Chris_Booth> hi all
23:56:56  <SmatZ> hello Chris_Booth
23:57:06  <Chris_Booth> hi SmatZ
23:59:34  *** Cybertinus [~Cybertinu@tunnel3304.ipv6.xs4all.nl] has quit [Remote host closed the connection]

Powered by YARRSTE version: svn-trunk