IRC logs for #openttd on OFTC at 2011-01-25
⏴ go to previous day
01:28:32 *** jonty-comp has joined #openttd
02:27:46 *** JOHN-SHEPARD has joined #openttd
02:44:37 *** Maedhros has joined #openttd
02:44:37 *** Chris_Booth has joined #openttd
02:44:37 *** Markavian has joined #openttd
03:06:30 *** tokai|noir has joined #openttd
03:29:42 <Eddi|zuHause> ah... furry-heating-cushion-that-makes-miau
04:17:31 *** Eddi|zuHause2 has joined #openttd
04:20:16 <z-MaTRiX_nonidentified> hey-ho
04:40:02 *** Eddi|zuHause2 has joined #openttd
05:13:24 *** Dreamxtreme has joined #openttd
05:24:01 *** roboboy has joined #openttd
05:29:19 *** Dreamxtreme has joined #openttd
05:56:18 *** Eddi|zuHause2 has joined #openttd
06:01:31 *** z-MaTRiX1nonidentified has joined #openttd
06:02:51 *** z-MaTRiX_nonidentified has quit IRC
06:06:32 *** Doorslammer has joined #openttd
07:16:22 *** Br33z4hSlut5 has joined #openttd
07:18:01 *** Kurimus has joined #openttd
07:31:36 *** Cybertinus has joined #openttd
08:13:33 *** DayDreamer has joined #openttd
08:21:32 *** TheMask96 has joined #openttd
08:21:44 *** Guest1555 has joined #openttd
08:22:26 *** Guest1555 is now known as norbert79
08:25:40 *** FauxFaux has joined #openttd
08:45:22 *** Progman has joined #openttd
08:56:22 *** valhallasw has joined #openttd
09:28:21 *** Adambean has joined #openttd
10:15:54 *** Cybertinus has joined #openttd
10:16:01 *** HerzogDeXtEr1 has joined #openttd
10:33:49 *** roboboy has joined #openttd
11:37:31 *** KenjiE20 has joined #openttd
11:42:41 *** norbert79 has left #openttd
12:57:55 *** Scuddles has joined #openttd
13:32:54 *** Wolf01 is now known as Guest1575
13:32:54 *** Wolf03 is now known as Wolf01
13:37:20 *** Chruker has joined #openttd
13:41:41 *** Eddi|zuHause2 is now known as Eddi|zuHause
14:38:50 *** Br33z4hSlut5 has joined #openttd
15:09:06 *** HalfBit has joined #openttd
15:28:12 <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:52 <peter1138> in fact the train slows down
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: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:04 <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:42:06 <peter1138> probably should be sqrt(2)/2
15:43:56 <HalfBit> Same speed, they are aligned until one train turns
15:43:59 <peter1138> yeah, that's the usual way of seeing it :)
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:35 <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:49 <HalfBit> by default graphics, you mean, the DOS/Windows TTD?
15:47:12 <peter1138> i mean graphics from ttd
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:33 <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:34 <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:27 <planetmaker> DanMacK did an excellent job on that recently
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 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: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:24 <HalfBit> It is probably some problem that the people in coop already had
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:22 <peter1138> eh, rubidium's comment is a bit
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: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:02 <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:24 <peter1138> 1/16th of a tile atm, iirc
15:59:40 <peter1138> maybe 1/256th of that is precise enough :p
16:00:05 <peter1138> i probably had a patch for that at some point :P
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:32 <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:03:07 <peter1138> Eddi|zuHause, positions are stored in map coordinates, not pixel coordinates
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: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:13 <Eddi|zuHause> i mean acceleration etc.
16:07:29 <Eddi|zuHause> but for display, it's always rounded to full grid position
16:11:35 <peter1138> hmm, advanceposition is *always* 3/4 :S
16:11:56 <peter1138> ahh GetAdvanceDistance
16:13:07 <peter1138> 256 to 271? now i don't know
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: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:34 <Eddi|zuHause> civ5 has hex grid
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 has joined #openttd
16:21:47 *** LordAro has joined #openttd
16:22:41 * ZirconiumX kicks SmatZ where it hurts
16:23:23 <SmatZ> /kick ZirconiumX does it hurt?
16:23:52 <SmatZ> I really didn't deserve being kicked :((
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: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:29 *** PhoenixII 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 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:40:33 *** thomas_ has joined #openttd
16:40:39 *** thomas_ is now known as DJNekkid
16:41:36 *** Phoenix_the_II has quit IRC
16:43:11 *** ZirconiumX has left #openttd
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: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:53:45 *** Prof_Frink has joined #openttd
16:54:56 *** rhaeder has joined #openttd
17:08:36 *** JOHN-SHEPARD has joined #openttd
18:19:14 *** Brianetta has joined #openttd
18:33:58 *** KenjiE20 has joined #openttd
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 has joined #openttd
18:59:31 *** DanMacK 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 has joined #openttd
19:03:40 *** Alberth has joined #openttd
19:03:40 *** ChanServ sets mode: +o Alberth
19:05:55 *** ZirconiumX has joined #openttd
19:14:49 *** andythenorth has joined #openttd
19:16:13 <andythenorth> industry production multiplier in advanced settings?
19:16:20 <andythenorth> I may regret this idea :P
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: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:50 <andythenorth> it might need some thought w.r.t edge cases
19:41:06 *** Chris_Booth has joined #openttd
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:59:46 <Alberth> so what do you want to do what you cannot?
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: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: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: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 has joined #openttd
20:47:28 * andythenorth should do something useful
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: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: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_ has joined #openttd
21:04:31 *** ABCRic is now known as Guest1624
21:04:31 *** ABCRic_ is now known as ABCRic
21:10:11 <andythenorth> the situation with readme / instructions for newgrfs isn't very satisfactory really
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:55 <andythenorth> or unicode friendly?
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:09 <andythenorth> meanwhile trying like crazy to fit set description, instructions + parameter info into 500 chars for bananas
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: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 has joined #openttd
21:28:51 <glx> 0x00 - 0x7F range is valid utf-8
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: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: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:35:15 <andythenorth> I should understand what that will do.
21:35:43 <Alberth> it removes those data structures from the vehicles
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: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: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:12 <planetmaker> and pdf has more security issues than openttd commits
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: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:45:16 <planetmaker> no images. Images are the grf ingame
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: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: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:28 <andythenorth> it's being updated though :)
21:54:14 <andythenorth> it's important to be aware of safety issues :P
21:59:12 *** andythenorth has left #openttd
21:59:26 <Mazur> Soft kitty, warm kitty, little ball of fur. Happy kitty, sleepy kitty, purr, purr, purr.
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:36 <Rubidium> the order before the service order seems to stay in the list indefinitely
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: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: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: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: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: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: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:30 <Rubidium> to set some magic bits when the vehicle is/was using a depot order
22:35:09 <Rubidium> it'll be somewhat messy, but I guess it's (eventually) possible
22:36:09 * fonsinchen would need to take a closer look at the code to comment on that but is too tired.
23:48:04 <Ammler> I see the next limit, which needs to be broken :-)
23:53:49 *** Chris_Booth has joined #openttd
23:55:54 <SmatZ> all limit are here to be broken!
continue to next day ⏵
