IRC logs for #openttd on OFTC at 2011-01-05
⏴ go to previous day
00:00:23 <fonsinchen> most of the time there's enough space to fill 3 rows
00:01:00 <fonsinchen> Mind that I'm not really filling rows. I still order the stuff from top to bottom and then switch to the next column
00:01:12 <fonsinchen> but I try to keep all columns equally long
00:01:39 <fonsinchen> it doesn't matter at all I guess
00:02:02 <Terkhen> I'll give it a look tomorrow
00:02:07 <Terkhen> I'm specially interested on unification
00:02:10 <fonsinchen> I could just make GetMaxNumberRowsLegend and GetNumberRowsLegend the same and do it like you do
00:02:23 <Terkhen> as the smallmap code is kind of hacky at some parts
00:02:51 <fonsinchen> It is not particularly nice even with my changes, but I tried to avoid code duplication.
00:05:59 <Terkhen> SMT_LINKSTATS also has a list of toggleable legend entries?
00:13:06 <fonsinchen> btw, that patch was the wrong one. I have updated once more
00:13:36 <Terkhen> I'll check it further tomorrow
00:13:37 <fonsinchen> in SMT_LINKSTATS you can choose for what cargos you want to see stats
00:59:29 *** supermop has joined #openttd
01:13:54 *** roboboy has joined #openttd
01:24:53 *** Xaroth_ has joined #openttd
01:29:54 *** Xaroth__ has joined #openttd
02:32:55 *** Eddi|zuHause has joined #openttd
02:34:05 <Eddi|zuHause> hm... it's totally weird... it detected the drives correctly on install, but it doesn't boot...
02:36:52 <Wolf01> I'm trying to move my win7 installation to another hdd, I tried for 2 hours with various disk backup softwares (acronis, ghost...) then I started to create a system image with windows itself, I'll restore that on the other drive
03:17:22 *** Eddi|zuHause2 has joined #openttd
03:22:44 *** Eddi|zuHause3 has joined #openttd
03:25:42 *** Eddi|zuHause3 has joined #openttd
03:27:57 *** Eddi|zuHause3 has joined #openttd
03:35:28 *** Eddi|zuHause4 has joined #openttd
04:04:06 *** Eddi|zuHause4 has joined #openttd
05:22:32 *** George|2 has joined #openttd
05:22:37 *** George is now known as Guest3337
05:22:37 *** George|2 is now known as George
05:37:10 *** DJNekkid has joined #openttd
05:56:18 *** Eddi|zuHause4 has joined #openttd
06:38:50 *** [alt]buster has joined #openttd
06:39:19 *** [alt]buster is now known as [com]buster
06:53:00 *** Xaroth_ has joined #openttd
06:58:58 *** Xaroth__ has joined #openttd
07:10:07 *** Xaroth_ has joined #openttd
07:13:58 *** andythenorth has joined #openttd
07:18:45 <kamnet> Good mornign andythenorth
07:23:11 *** Xaroth_ has joined #openttd
07:27:40 *** DayDreamer has joined #openttd
07:29:04 *** Cybertinus has joined #openttd
07:37:54 *** LordAro has joined #openttd
07:41:33 *** rhaeder has joined #openttd
07:54:00 *** andythenorth has joined #openttd
07:54:25 <andythenorth> planetmaker: I patched nforenum and removed ~/.nforenum
07:54:36 <andythenorth> still got a linter failure (and no openttd.grf)
07:55:36 <planetmaker> andythenorth: still same error?
07:55:37 <planetmaker> good morning also :-)
07:55:40 <Rubidium> sounds like there's a second nforenum somewhere hiding
07:56:23 <planetmaker> well. the problem is that nforenum and grfcodec produce the same error message for missing nforenum as well as for too old one
07:56:38 <planetmaker> could it be correct the message this time?
07:57:35 <CIA-2> OpenTTD: rubidium * r21731 /trunk/src/ (company_cmd.cpp saveload/saveload.cpp): -Fix (r21728): don't forget to update the saveload version, or to check for MSVC warnings
07:57:53 <kamnet> Just curious, can a road tile detect what NewGRF station tile it is next to?
07:58:09 <andythenorth> yay. openttd.grf builds
08:00:46 <kamnet> Toying with the idea of releasing a roadset based on Industrial Station Renewal. Indecisive on how I want to style the roads
08:00:56 <planetmaker> a road tile cannot check anything. It can merely exist
08:01:12 <planetmaker> that'd need rail types
08:01:27 <planetmaker> but even then: railtypes also don't allow to check for adjacent tiles
08:01:37 <planetmaker> simple reason: too computationally expensive
08:01:42 <planetmaker> same would go for roads
08:03:44 <andythenorth> kamnet: the problem is that ISR roads aren't that nice ;)
08:03:55 <andythenorth> huh, did I say that out loud?
08:04:37 <planetmaker> they're missing the footwalk
08:04:45 <andythenorth> ISR needs a revamp
08:05:11 *** Progman has joined #openttd
08:05:24 * roboboy ponders creating an Australian town names set
08:06:02 <roboboy> mixing both Aboriginal names and english name
08:06:32 <kamnet> It does, that's why I'm starting off with the roads. Players need roads they can drive on.
08:07:11 <andythenorth> I think ISR needs its tiles changinge
08:07:19 <andythenorth> they're dour, in all climates
08:07:23 <kamnet> Yep, they're intentionally missing the footwalks. They're industrial
08:08:39 <kamnet> I may create the footwalks for the roads that get upgraded in-town.
08:08:53 <planetmaker> kamnet: yes. that's why currently, without road types, a road set of those tiles only is not that nice in many places, as you'll have it everywhere
08:10:03 * andythenorth suggests working on road types :)
08:11:26 <kamnet> That would be a nice thing, though - if the road detects it's near a home or is in-city, builds a foot path. if it detects it is next to ISR tile, then remove it and extend the asphalt.
08:13:25 <planetmaker> kamnet: yes. But as said before:
08:13:28 <planetmaker> [09:01] <planetmaker> but even then: railtypes also don't allow to check for adjacent tiles
08:13:29 <planetmaker> [09:01] <planetmaker> simple reason: too computationally expensive
08:14:05 <kamnet> I know, just daydreaming :D
08:14:29 <andythenorth> planetmaker: wrt the PBS reservations, I wonder about just adding 6 more sprites to base set
08:14:38 <andythenorth> there would be some duplication, but....it's simple
08:14:54 <andythenorth> it also allows (in future) to have sprites specific to PBS if desired
08:14:54 <planetmaker> why not use the existing ones?
08:15:08 <andythenorth> maglev is fundamentally not going to work
08:15:34 <andythenorth> special case for maglev just seems a bit fragile
08:15:52 <andythenorth> my experience trying to read industry_cmd.cpp is that many special cases hurts my head
08:17:19 <planetmaker> well. it's one for the default maglev. Not more
08:17:52 <planetmaker> but I won't stop you giving the other approach a shot, too.
08:17:57 <andythenorth> I'll fix the monorail sprite meanwhile
08:17:58 <planetmaker> having less cases may be worth it
08:18:07 <planetmaker> I just don't know now.
08:18:10 <andythenorth> and I'll fix the screaming baby :P
08:20:05 <planetmaker> yeah... it's important to start with drugs early :-P
08:21:11 <andythenorth> and I'm back to one handed typing
08:22:43 <kamnet> Very cool. It's a wonder you've been able to turn out any work at all ;-)
08:23:04 <kamnet> I'm just kidding. Wait until they start walking and crawl under the desk to yank out your power cords
08:23:32 <andythenorth> ach, nfo is quite easy with one hand
08:23:39 <andythenorth> just the numbers and A-F
08:23:53 <andythenorth> no way I'm switching to nml, I'll need shift for the brackets and stuff
08:24:00 <andythenorth> nml is not baby compatible
08:26:17 <andythenorth> planetmaker: I found a problem :)
08:27:12 <andythenorth> I guess a check is needed for sprite replacement
08:27:16 <andythenorth> dunno how that's done
08:27:41 <planetmaker> they're using the crossing sprite
08:27:45 <andythenorth> this is with canset / ng rails
08:28:26 <andythenorth> I'm then drawing maglev over the top of their track sprite :P
08:29:36 * andythenorth wonders whether to adopt despondency or determination :)
08:30:34 <andythenorth> am I allowed to just break old newgrfs?
08:32:13 <planetmaker> might not be too good. It'd be good to find a way to detect whether the sprite is replaced by actionA
08:33:17 <planetmaker> though canset should be smarter than to use this old-fashioned method ;-)
08:33:34 <CIA-2> OpenTTD: rubidium * r21732 /trunk/src/terraform_cmd.cpp: -Fix (r21728): show the "proper" error that the landscaping limit is reached instead of "already flat"
08:36:25 *** Kurimus has joined #openttd
08:38:48 <andythenorth> I think this patch just died on the vine :P
08:39:23 <andythenorth> I had a feeling that newgrf support might kill it
08:40:53 <andythenorth> because I've extended the base set, there's just no way to work with old sets that don't know the base set is changed
08:41:30 <peter1138> this is trams without roads on level crossings?
08:42:34 <peter1138> it's something that roadtypes would support anyway
08:42:44 <peter1138> in a newgrftactular manner
08:42:59 <andythenorth> I figure the case with roadtypes is much easier
08:43:11 <andythenorth> would have been nice to improve the default case though
08:43:25 <andythenorth> I think roadtypes isn't possible without doing this
08:43:43 <andythenorth> or at least, road types will require also that players use a railtype newgrf
08:44:31 <andythenorth> or that road type grfs also provide level crossings
08:45:47 <andythenorth> without a rail overlay in the base set for rail / monorail / maglev, there's no sane way to construct a level crossing
08:45:55 <andythenorth> everything else has the potential to look gash
08:46:40 <andythenorth> roadtypes are going to break canset crossings anyway
08:49:41 <andythenorth> how about just breaking old grfs?
09:00:06 <LordAro> hmmm - if you comment out roadveh_cmd.cpp:771, interesting things happen if an articulated vehicle attempts to overtake another...
09:00:45 <LordAro> - only the front part of the vehicle moves to the other side of the road...
09:01:12 <LordAro> now, how to include the articulated part in the overtaking checks...
09:01:51 *** Dreamxtreme has joined #openttd
09:02:31 <Terkhen> that is something which requires a complete revamp IMO
09:02:43 <planetmaker> well. I think with road types something like this will have to be found anyway. IMHO it makes sense also independent
09:03:16 <andythenorth> is newgrf backwards compatibility absolute?
09:03:42 <planetmaker> absolute is a harsh word ;-)
09:03:47 <andythenorth> for a set that relies on replacing base set sprites....
09:03:51 <Rubidium> andythenorth: more like "preventing breakage if possible"
09:04:16 <Rubidium> does it actually replace all the GUI sprites?
09:04:30 <Rubidium> especially the "autorail" sprite
09:04:51 <andythenorth> canset 3d does replace the autorail sprite for maglev yes
09:04:58 <andythenorth> and all the GUI sprites I can see
09:05:28 <andythenorth> canset ng breaks with rail type
09:05:36 <andythenorth> or at least, it's not compatible with nutracks
09:05:55 <planetmaker> I'd not expect anything bad
09:06:11 <andythenorth> no it does work - my mistake
09:06:45 <andythenorth> can I detect that sprites are being replaced?
09:07:07 <Rubidium> I see no reason you can't
09:07:34 <LordAro> it would force DanMacK (or whoever) to finally update the grf ;)
09:07:50 <andythenorth> probably best we dont discuss that ;P
09:07:50 <Rubidium> although you might want to focus specifically on the existing "overlay" sprites
09:08:16 <andythenorth> ignoring my cute patch for trams...
09:08:28 <andythenorth> ..I can't see how road types can work with crossings when an old-style rail set expects certain crossing sprites
09:08:29 <Rubidium> as the non-overlay sprites get messed up with those no-grid NewGRFs
09:08:33 <LordAro> Terkhen: you're probably right, the whole file is full of goto's (which are bad, IMO)
09:09:22 <andythenorth> because the crossing sprite contains both road and rail composited, backwards compatibility *has* to break somewhere if we want both road and rail types
09:09:28 <Terkhen> sometimes gotos can be acceptable, the problem is that the overtaking code looks too much like a hack
09:09:44 <Terkhen> but there is no obvious "nice" way of dealing with them either
09:11:01 <LordAro> can't be that difficult to shift the sprite drawing down by about 7(?) pixels...
09:11:29 <LordAro> or perhaps just locally 'switch' driving side for that vehicle :s
09:11:40 <Rubidium> LordAro: just set the overtake bit
09:12:31 <andythenorth> if I need to check for a base sprite being replace, where should I start looking...
09:14:14 <LordAro> Rubidium: or that :) i guess it needs including into the articulated vehicles struct or whatever (this _must_ show that i have no idea what i'm doing :) )
09:15:42 <Terkhen> LordAro: each Vehicle has a pointer to the next Vehicle in the chain
09:16:56 <Rubidium> andythenorth: the action A code?
09:16:56 <Terkhen> to get an idea check Vehicle::GetNext() and Train::GetNextArticPart()
09:17:35 <LordAro> that (should) make life easier...:)
09:23:30 <Terkhen> be sure to check if the overtaking code takes into account the whole lenght of the vehicle and not only the first part
09:24:17 <LordAro> i'd use a for loop to go through each part :)
09:24:45 <LordAro> btw, i can't find Vehicle::GetNext(), am looking at the other though
09:26:24 *** Adambean has joined #openttd
09:27:12 <Terkhen> it must be called Next or something like that then
09:28:22 * LordAro does realise that he uses too many smileys... ( :D )
09:28:40 <andythenorth> ok so take this case....
09:29:03 <andythenorth> player has a road type newgrf, and an old rail set doing base set replacement
09:29:15 <andythenorth> player builds a level crossing for trams
09:29:27 <andythenorth> (forget the visual appearance, not important in this case)
09:29:33 <andythenorth> should road bits be set or not?
09:29:52 <planetmaker> for a road type: no
09:29:59 <planetmaker> you only draw the type which is there
09:30:06 <andythenorth> but the base set will draw road anyway
09:30:21 <andythenorth> so now we have bug reports about crossings where road vehicles can't drive
09:30:27 <andythenorth> because there's no road bit set for the tile
09:30:48 <andythenorth> (i.e. canset will continue drawing road, but the map thinks there's no road on the tile)
09:31:02 <andythenorth> so the game is broken in that case
09:31:04 <planetmaker> you said a road type with trams was only crossing
09:31:20 <planetmaker> then it's part of the road type code to make sure they can still drive
09:31:45 <planetmaker> the problematic part I see is an old rail newgrf and no road type
09:31:54 <planetmaker> There you wanted to introduce the new code.
09:31:59 <andythenorth> old rail grf and road type is a problem
09:32:17 <planetmaker> Don't you have some overlays there, too?
09:32:39 <andythenorth> no / yes / maybe
09:32:41 <andythenorth> all of the above ;)
09:32:50 <andythenorth> yes we could just draw normal track, is does look gash
09:33:09 <andythenorth> basically we could just composite crossings use rail_x / rail_y pieces
09:33:24 <andythenorth> but less crappy than drawing monorail over ng track
09:33:53 <planetmaker> well. Also IMHO: old railtype and new road type: no problem if the level crossing uses the railtype's actionA sprite.
09:34:11 <planetmaker> after all you could use a new(er) newgrf.
09:34:13 <andythenorth> how do you provide the new road surface?
09:34:26 <andythenorth> so what road type is that?
09:34:32 <planetmaker> But it's the fault of the rail replacement
09:34:40 <andythenorth> but players will report bugs :)
09:35:18 <planetmaker> that's why I proposed to (mis)use the pbs sprites
09:35:23 <planetmaker> not nice, but better visible
09:35:24 <andythenorth> there are no pbs sprites
09:35:26 <andythenorth> they don't exist
09:35:37 <andythenorth> there is no overlay ;)
09:35:44 <andythenorth> it's just rail_x, rail_y
09:35:53 <andythenorth> well, depends on definition of overlay :D
09:36:04 <andythenorth> I think it could be the best compromise
09:36:16 <andythenorth> crossings will look bad, but won't produce bug reports
09:36:20 <andythenorth> most people won't notice
09:36:36 <andythenorth> I am increasingly convinced by this route
09:37:25 <andythenorth> it still leaves a maglev issue, and because canset uses maglev, that will be broken
09:37:56 <andythenorth> if we want road types, canset and similar old rail grfs break
09:38:28 <andythenorth> do we want road types?
09:38:45 * roboboy wonders if canset reads TTDP's unifiedmaglev setting
09:39:09 <andythenorth> planetmaker: yes that's what I understood you to mean
09:39:17 <andythenorth> they look bad at crossings due to the sleepers
09:39:22 <andythenorth> but it's the least bad route
09:39:35 <andythenorth> planetmaker: can you find the maglev version of that sprite?
09:40:00 *** Markavian has joined #openttd
09:41:01 <roboboy> if it does and OpenTTD was to report monorail, would that help or cause other issues?
09:41:29 <LordAro> Terkhen: there is no *documented* function called Next() and, despite many [references to/uses of] it, many searches have not found it's actual declaration. could you point me in the right direction (file)?
09:41:39 <andythenorth> roboboy: I think it might slightly help
09:42:20 <roboboy> again it's not the best way to fix your issue though
09:44:37 <Terkhen> LordAro: grep Next src/*
09:47:40 <Terkhen> probably vehicle_base
09:51:28 <SmatZ> LordAro: it's in SpecializedVehicle
09:52:17 <andythenorth> planetmaker: certain issue there with overlaying that over a road piece ;)
09:53:25 <andythenorth> well, I'm stuck for now
09:55:01 <andythenorth> even detecting that an old rail newgrf is replacing base sprites doesn't solve this
09:55:07 <planetmaker> andythenorth, introduce action5 sprites for that...
09:55:19 <andythenorth> I think I did already :)
09:55:35 <andythenorth> but my patch can't go and update all old newgrfs :o
09:56:08 <planetmaker> well. if they replace the rail, they also replace the overlay.
09:56:34 <peter1138> did anyone protest at it being called "terraforming" limit?
09:56:38 <planetmaker> if they don't: newgrf bug
09:56:56 <andythenorth> that's the only answer that's going to make road types possible
09:57:16 <planetmaker> andythenorth, also honestly: you cannot replace a track sprite and not handle the overlay.
09:57:29 <andythenorth> I do handle the overlay - check the code ;)
09:57:35 <andythenorth> I have all that worked out and working
09:57:37 <planetmaker> not you. A newgrf author
09:57:49 <planetmaker> the other you ;-)
09:57:55 <planetmaker> English is there a very inaccurate language
09:58:14 <andythenorth> but I / we am changing the spec, and some of these grfs are like 3/4 years old
09:58:21 <andythenorth> there will be whining
09:58:27 <andythenorth> it will be a 'misfeature'
09:58:32 <andythenorth> various people will sulk
09:58:45 <peter1138> what's the problem again?
09:58:46 <andythenorth> players will ask for yet another advanced option
09:59:18 <SmatZ> - Change: Changed 'terraforming' to 'landscaping'
09:59:20 <andythenorth> peter1138: the cause of the problem is newgrfs replacing rail without using rail types
09:59:27 <SmatZ> from changelog for 0.3.4
09:59:33 <peter1138> why is that a problem?
09:59:46 <andythenorth> for as long as they depend on the combined crossing / road sprite, there's no sane way to draw road type level crossings
10:00:23 <peter1138> andythenorth, there is, but it might not look as good
10:00:33 <andythenorth> I could live with that
10:00:34 <planetmaker> andythenorth, indeed. I don't see the problem either ;-)
10:00:37 <peter1138> railtypes introduces the crossing overlays
10:00:37 <SmatZ> peter1138: I thought you don't like the term "terraforming" in english.txt
10:00:42 <planetmaker> just stick with the frigging overlay. Done
10:00:49 <andythenorth> go look at the monorail overlay again :P
10:00:52 <peter1138> SmatZ, multiple conversations :)
10:01:01 <andythenorth> where's the track in the monorail overlay?
10:01:05 <andythenorth> it ain't there :D
10:01:09 <andythenorth> it's in the ground sprite
10:01:19 <andythenorth> ergo, no monorail track at crossings
10:01:27 <peter1138> andythenorth, you draw a base road tile
10:01:31 <andythenorth> hey, I'll patch for it and we can decide :)
10:01:40 <peter1138> andythenorth, and then draw a single track overlay piece (the overlays that have always been there)
10:01:52 <peter1138> andythenorth, ugly as fuck, but possibly okay
10:02:05 <andythenorth> monorail overlay will look dumb :)
10:02:11 <peter1138> i'd just rather it wasn't hacked in now before roadtypes
10:02:32 <peter1138> andythenorth, monorail always looks dumb
10:02:58 <andythenorth> peter1138: I'm trying to do this in a way that supports road types ;)
10:03:22 <andythenorth> in fact, I already had that patch
10:03:32 <andythenorth> look at the tram track crossing on maglev
10:03:34 <andythenorth> ignore the others
10:03:42 <andythenorth> that uses the overlay
10:03:56 <andythenorth> that was one of my earlier attempts before dicking around with extending base set
10:04:05 <LordAro> peter1138: how far away is roadtypes then :p#
10:04:18 <peter1138> LordAro, a fair way off
10:04:25 <peter1138> LordAro, but adding hacks ontop of hacks is always a hassle
10:04:36 <andythenorth> LordAro: if I keep working on it, I think it's about two years
10:05:11 <andythenorth> peter1138: I don't want to add hacks. they smell
10:05:12 *** planetmaker has left #openttd
10:05:20 *** planetmaker has joined #openttd
10:05:20 *** ChanServ sets mode: +o planetmaker
10:05:31 <andythenorth> I want to break old newgrfs :P
10:05:51 <andythenorth> either of those are preferable to some special case badness
10:07:32 <andythenorth> how about....just ditch the built in types + base set sprites, and ship road type / rail type newgrfs properly in openttd.grf?
10:07:37 <andythenorth> then delete the legacy stuff?
10:08:07 <andythenorth> i.e. move rail / elrail / monorail / maglev / default roads to newgrf
10:08:24 <andythenorth> no special cases
10:08:25 <planetmaker> andythenorth, that breaks _all_ old rail newgrfs (and road newgrfs) 100%
10:08:46 <andythenorth> probably not popular
10:08:48 *** tokai|mdlx has joined #openttd
10:09:01 <planetmaker> no. Don't underestimate the time constants in grf usage
10:09:08 <planetmaker> those old rail newgrfs are still used
10:09:47 <roboboy> couldn't you somehow add a parameter to openttd.grf to chose? TTDP does with TTDPbase(ww).grf
10:10:14 <planetmaker> that's a pain :-)
10:10:39 <peter1138> andythenorth, maglev crossings suck anyway
10:10:42 <planetmaker> (referring to roboboy's suggestion)
10:10:46 <andythenorth> that's what happens if we (a) stop setting road bits for trams (b) draw overlays instead of relying on crossing sprite alone
10:11:14 <andythenorth> actually that image probably has nothing to do with road bits, but that's an implementation detail
10:11:14 <planetmaker> that looks acceptable
10:11:19 <peter1138> or just leave it as is
10:11:21 <roboboy> Ok (TTDP uses the parameters for non game changing things like foundation colours/styles)
10:11:26 <peter1138> is that bit of road really that annoying?
10:11:33 <andythenorth> peter1138: leave it as is means no road types
10:12:16 <andythenorth> forget the appearance, it comes down to this: set road bits at tram-only crossings yes / no?
10:12:26 <andythenorth> if road bits are set, what road type should be drawn?
10:12:31 <planetmaker> for a road type implementation: no
10:12:33 <peter1138> andythenorth, no it doesn't
10:12:55 <andythenorth> what have I missed :)
10:13:30 <andythenorth> planetmaker: if road bits aren't set, you have road graphics in game that road vehicles can't drive on
10:13:58 <andythenorth> live with the bug?
10:14:09 <peter1138> for road types without rail types: draw straight rail piece, overlay road crossing graphics
10:14:40 <planetmaker> peter1138, I'd do it vice versa
10:14:54 <planetmaker> oh uhm. with rail types
10:15:06 <andythenorth> so road types need to provide crossing graphics?
10:15:09 <peter1138> planetmaker, with road types and _with_ rail types, yes
10:15:29 <planetmaker> andythenorth, not sure, but they well might
10:15:45 <planetmaker> no loss there, if they do and authors use the same sprite as for normal road
10:16:03 <andythenorth> they have to contain a gap for the track
10:16:07 <andythenorth> how wide should that be?
10:16:15 <planetmaker> they don't need a gap
10:16:25 <planetmaker> they just might want to provide a different side walk or alike
10:16:30 <planetmaker> or different tarmac
10:16:34 <andythenorth> we're drawing them over the rail in this version, how do we see the rail? :o
10:16:44 <planetmaker> we draw them under the rail
10:16:51 <planetmaker> changing that breaks railtypes
10:16:55 <peter1138> andythenorth, it's newgrf, they'll be able to check the railtype and provide different graphics if need be
10:17:04 <andythenorth> ooh, that's evil
10:17:16 <planetmaker> peter1138, road types should be _under_ the rail. Makes IMHO much more sense
10:17:24 <planetmaker> much better compatible
10:17:41 <peter1138> planetmaker, yes, that would be the normal case
10:17:46 * roboboy forgets which extra sprites andy's patch adds
10:18:00 <peter1138> i'm just talking about a specific case for road types on oldrails
10:18:06 <planetmaker> that's what andy talked about in the last "paragraph"
10:18:22 *** Brianetta has joined #openttd
10:18:25 <andythenorth> I thought we wanted to eliminate the special case?
10:18:32 <andythenorth> i.e. 'leave it as is' ?
10:18:38 <peter1138> planetmaker, problem with "road then rail overlay" is maglev in road-rail-crossing-3.png :)
10:18:49 * andythenorth wants to be rude about maglev
10:19:13 <andythenorth> ok imagine some rudeness ;P
10:19:20 <planetmaker> peter1138, that's a border case. Not sure it needs much attention
10:19:30 <peter1138> planetmaker, probably not, but stil
10:19:33 * roboboy prefers it over monorail but can live with uglyness
10:19:52 <planetmaker> roboboy, that's what things like OpenGFX+Rails or so kick in ;-)
10:19:57 <peter1138> quite simple to just make a newgrf that provides railtypes for the standard tracks
10:19:57 <planetmaker> solving those uglyness'es
10:20:21 <andythenorth> just ship the grf, use opengfx sprites for maglev / monorail
10:20:23 <planetmaker> someone just has to provide the sprites best in the format I used for SER and I'll do that
10:20:23 <peter1138> anyway, i want motorways
10:20:35 <andythenorth> yeah well that's easy
10:20:40 <andythenorth> no crossings for motorways :P
10:20:41 <peter1138> so that, come late 20th century, i can rip up the rails and transport everything by road
10:20:50 <peter1138> and suffer massive congestion :D
10:20:59 <andythenorth> what got decided here?
10:21:07 <andythenorth> use the existing overlay sprites
10:21:13 <andythenorth> live with slightly bad appearance
10:21:19 <andythenorth> don't break old newgrfs (much)
10:21:21 <peter1138> andythenorth, road-rail-crossing-3, i think
10:21:34 <peter1138> andythenorth, but i don't really see the need to avoid having road on tram crossings at the moment
10:21:55 <andythenorth> you know more than me....but the issue was really about road bits at crossings
10:22:00 <andythenorth> I wanted to stop setting them
10:22:05 <roboboy> I like what the others said
10:22:07 <andythenorth> for tram-only crossings
10:22:18 <andythenorth> the piece of road I don't care about either way
10:22:47 <andythenorth> I guess when building the road & rail type could be checked, and the bits set / not set accordingly
10:22:53 <andythenorth> seems a bit complex
10:23:11 <roboboy> and then patch it all up with a shipped railtypes grf
10:23:38 <andythenorth> if rail type....don't set bits
10:23:47 <roboboy> are the rails in OpenGFX the same coul as Default?
10:24:19 <planetmaker> no idea. probably not. But does it matter?
10:24:33 <roboboy> not that it would be noticeable realy
10:24:50 <andythenorth> how would bits be set for road type
10:25:04 <andythenorth> if road type && rail type, don't set bits for trams
10:25:07 <planetmaker> roboboy, openttd.grf and ogfxe_extra.grf are equivalent. E.g. if you can fix it with openttd.grf, OpenGFX can fix it the same way. No issue
10:25:09 <peter1138> whatever bits are necessary
10:25:37 <peter1138> can be done with 8 bits
10:25:51 <planetmaker> openttd.grf is 'just' part of the in-built support for the TTD base set
10:26:31 <andythenorth> we only need the ROADTYPE_ROAD bit set at tram crossings if there's no rail type in use
10:26:56 <peter1138> no rail type on level crossings? that'll be novel
10:27:20 <andythenorth> rail type newgrf providing overlay (I should have said)
10:27:53 <peter1138> whether railtypes or roadtypes are in use or not, the map bits will be used in the same way
10:28:20 <peter1138> i mean, rail types always exist, just not "railtypes", heh
10:28:33 <peter1138> and thus road types will always exist, just not "roadtypes"... pom te pom
10:28:51 <peter1138> (that's what you get for trying to avoid calling it "new...")
10:30:14 <andythenorth> there would still effectively be ROADTYPE_ROAD and ROADTYPE_TRAM?
10:30:23 <andythenorth> or do I have epic misunderstanding?
10:30:48 <peter1138> just like there are 16 rail types, there'd be 16 road types
10:31:12 <andythenorth> that's what I mean
10:31:18 <andythenorth> basically, 'draw this one over that one'
10:31:23 <andythenorth> which rail types don't do
10:31:27 <peter1138> map bit usage is increased
10:31:42 <peter1138> because you need to store both road types as well as road bits
10:32:02 <peter1138> needs 8 bits to store both road types
10:33:16 <peter1138> damn it, you're making me discuss this and thus making me want to finish it :s
10:33:29 <andythenorth> I just wanted to start it:)
10:33:49 <andythenorth> when I read stuff, crossings looked a bit fiddly, so I thought I'd start there
10:34:34 <peter1138> road types is already started
10:35:08 <andythenorth> what about roadtypes?
10:35:14 <peter1138> IOGHRIerhgohrgerwgre
10:35:16 <peter1138> roadtypes is already started
10:35:32 <andythenorth> I think that's going to become annoying...
10:35:45 <andythenorth> especially if I spend the next two years making that mistake
10:35:52 <andythenorth> can't we just rename the damn thing?
10:36:23 <peter1138> let's see how many conflicts there are...
10:37:07 <andythenorth> give or take some capitalisation
10:37:42 <peter1138> everyone used to complain that everything is new this, new that...
10:38:38 <andythenorth> well they're not offering to work on it :P
10:39:31 *** Eddi|zuHause4 is now known as Eddi|zuHause
10:52:09 <andythenorth> too many versions of my patch :P
10:55:55 <Terkhen> good morning dihedral
10:58:09 <Eddi|zuHause> <andythenorth> can I detect that sprites are being replaced? <-- the shore sprite code has a check whether they were replaced with Action A or Action 5, and does different things.
10:58:21 <andythenorth> Eddi|zuHause: thanks
10:58:26 <andythenorth> might not though
11:00:36 <LordAro> peter1138: is there any version of roadtypes published anywhere? a quick search doesn't reveal anything...
11:00:59 <roboboy> somwhere on fuzzle.org?
11:03:50 <Eddi|zuHause> @openttd commit 11973
11:03:50 <DorpsGek> Eddi|zuHause: Commit by frosch :: r11973 /trunk/src (newgrf.cpp newgrf.h) (2008-01-24 14:49:40 UTC)
11:03:51 <DorpsGek> Eddi|zuHause: -Fix (r11726, r11947)[FS#1683]: Use grass tiles for corner shores, if shores got replaced by ActionA.
11:04:04 <dihedral> Rubidium, i do not understand why the burst and per 64k frames values default to such high numbers
11:04:44 <CIA-2> OpenTTD: terkhen * r21733 /trunk/src/ (company_cmd.cpp misc.cpp smallmap_gui.cpp):
11:04:44 <CIA-2> OpenTTD: -Codechange: Clarify the update owner legend code.
11:04:44 <CIA-2> OpenTTD: -Fix: Prevent crashes caused by deleted companies.
11:08:35 *** Ylioppilas has joined #openttd
11:08:53 *** Devroush has joined #openttd
11:09:42 <Ylioppilas> I see there's a OS X port available of 1.10-beta. Have the project solved its problems with OS X porting and is there going to be stable versions for OS X again?
11:11:35 <dihedral> Rubidium, if you change any of those values on a network servers, existing companies are not updated - new ones of course are
11:12:24 <__ln___> Ylioppilas: No and no.
11:13:00 <dihedral> __ln___, where does that second no come from?
11:15:14 <Chrill> ok, so I'm playing 1.1.0-beta2 and just had the game crash on me when I was doing nothing ingame. Therefore, the crash was not caused by something I directly did. However, the game has seen a NewGRF added (LongVehicles 4) since its start. Is it without purpose to send the bug report and similar to the devs if I've used "set scenario_developer true"?
11:16:24 <dihedral> Chrill, has it not been made quite clear that mucking about with newgrfs in-game is not supported?
11:16:33 <Chrill> It has been, which is why I'm asking :P
11:16:40 <SmatZ> Chrill: if you haven't changes the grf config, or only added vehicle newgrfs with Engine Pool enabled, it should be ok
11:16:50 <SmatZ> ok, it seems you DID change it :)
11:16:58 <Chrill> SmatZ: Well, I've only added that one newGRF
11:17:19 <dihedral> why on earth do people - no matter what you say - still try to find ways around it
11:17:50 <SmatZ> Chrill: if you are unsure, open a bugreport, it might be closed as invalid, and then you will have more experience for the next time :)
11:17:51 <Chrill> dihedral: why do you get upset when, instead of going "OMG BUG", I ask "doing what I did is the reason, right?"
11:18:13 <Chrill> SmatZ: thank you, will do
11:18:14 <Terkhen> Ylioppilas: some of them have been corrected | getting feedback and bug reports about the OS X port will help on resuming stable versions for OS X
11:18:45 <planetmaker> Chrill, because if you change newgrf on a running game the likelyhood of finding a bug instead of having messed up the savegame is very very slim
11:19:03 <planetmaker> having an invalid savegame is the number one thing you need to mention when you deal with such broken savegame
11:19:04 <dihedral> Chrill, because you do something that is not supported and ask for support? want to report an issue on something previously announced not supported
11:19:17 <Chrill> I did not ask for support, I asked for confirmation
11:19:18 <dihedral> something deliberately disabled under standard conditions
11:20:14 <dihedral> it just does not make sense to report a bug on a tampered with game
11:20:33 <dihedral> "hey i edited my save game with a hex editor and now i experienced a crash - i did nothing though"
11:20:38 <planetmaker> <SmatZ> Chrill: if you haven't changes the grf config, or only added vehicle newgrfs with Engine Pool enabled, it should be ok <-- SmatZ give me 10 minutes and I give you a newgrf which breaks that assumption
11:21:02 <Chrill> and that was all I was asking, and SmatZ made it very clear to me in a proper and friendly manner
11:21:12 <SmatZ> we are all wasting time by trying to find out what happened
11:21:13 <dihedral> Chrill, do you still have a save game of before you changed newgrf settings?
11:21:17 <planetmaker> he obviously gave - sorry SmatZ - wrong information
11:21:19 <dihedral> e.g. autosave perhaps
11:21:30 <Chrill> dihedral: well I have the original scenario
11:21:31 <SmatZ> if Chrill opens a bugreport, it will be clear immediatelly
11:21:34 <planetmaker> it's not save to add newgrfs. It works often. But definitely not always
11:22:02 <peter1138> i remember, back in the day
11:22:12 <peter1138> when it was our goal to support adding/remove grfs as much as possible
11:22:14 <dihedral> Chrill, it would be interesting to find out if something else was broken but i guess reproducing that will be difficult
11:22:21 <peter1138> there's a load of code relating to stations to support it
11:22:31 <Chrill> dihedral: lemme check if the first save is with or without longvehicles ;)
11:22:39 <peter1138> vehicles were always a spanner in the works though
11:22:51 <planetmaker> peter1138, you can still do that. But OpenTTD has no way to stop a newgrf not playing save in that respect
11:22:59 <planetmaker> Even without bad intentions from the newgrf author's side
11:23:08 <Eddi|zuHause> <peter1138> there's a load of code relating to stations to support it <-- but yet it still fails horribly
11:23:13 <planetmaker> thus it's for SE developers and newgrf developers only
11:23:17 <peter1138> Eddi|zuHause, it didn't crash :D
11:23:28 <planetmaker> peter1138, also a station newgrf can crash your game
11:23:35 <planetmaker> ISR, the most used one, is the best example
11:23:35 <dihedral> Chrill, i do not know if you have autosave settings defined, but if so that could be a good place to check ;-)
11:23:42 <peter1138> it was the non-passable station bit that caused problems :D
11:23:49 <planetmaker> updating ISR made me crash OpenTTD countless times when loading old savegames
11:23:58 <peter1138> that would've been stored on the map eventually
11:24:22 <Chrill> dihedral: heh, they apparently save monthly and so I can only go 15 months back. sorry, no save from before adding it since I did so within a few months of starting the game. I had no roadvehicles, wanted a bus, added LV4
11:24:29 <SmatZ> storing that bit in the map array could make pathfinders faster
11:25:07 <planetmaker> at least two bits, eh? Direction is also needed
11:25:14 <dihedral> Chrill, then it could quite likely be due to the newgrf - at least it would be very hard to find out, as the result can take ages to show
11:25:48 <planetmaker> what happens if I change the passable direction, peter1138 ? Or make it unpassable?
11:25:57 <Chrill> dihedral: yeah I figured it'd almost certainly be down to adding said newgrf, but I figured since I was running the testing, I'd at least mention it here in case the devs were interested
11:26:00 <planetmaker> that's like three states which require two bits
11:26:03 <peter1138> planetmaker, direction is already stored
11:26:22 <SmatZ> it applies to other station types than rail station?
11:26:34 <peter1138> newstations is only about rail stations
11:26:38 <peter1138> (unless that got changed)
11:27:01 <SmatZ> ok, I got a bit confused by pm :)
11:27:48 *** planetmaker is now known as TheGreatConfusor
11:29:27 <SmatZ> not that great actually :)
11:29:39 *** TheGreatConfusor is now known as planetmaker
11:29:53 <planetmaker> well, then I create the planet of confusion ;-)
11:30:02 <planetmaker> if needed it can be ejected into deep space and be gone
11:30:39 <planetmaker> dihedral, I'd not count on that within a finite time ;-)
11:31:13 <SmatZ> (is that still in openttd code?)
11:31:52 <SmatZ> static const int INF = 1000;
11:31:56 <SmatZ> no longer as define though :)
11:31:58 <dihedral> planetmaker, i never said i'd be around for that :-P
11:33:54 *** Eddi|zuHause2 has joined #openttd
11:34:45 <dihedral> i fail to entirely grasp the what and how
11:35:23 <dihedral> i am missing an update of some sort - or at least i fail to see where it happens, and i miss an update to companies when the setting changes on a network server - however that may very well be intended
11:35:57 <dihedral> and codewise i fail to understand the difference between the burst and the per 64k frames
11:37:34 <SmatZ> c->clear_limit = min(c->clear_limit + _settings_game.construction.clear_per_64k_frames,
11:37:47 <SmatZ> _settings_game.construction.clear_frame_burst << 16);
11:38:10 <dihedral> yes - now tell me the difference :-P
11:38:27 <SmatZ> I was wondering if it can overflow
11:38:32 <SmatZ> but it can't so fine :)
11:39:29 * dihedral pats SmatZ on the head
11:40:29 <dihedral> my gut feeling tells me it is a nice thing :-P
11:40:52 <dihedral> but i would not mind grasping it's full potential :-P
11:41:43 <dihedral> e.g. why is the default of terraform_per_64k_frames already a << 16 value, and terraform_frame_burst will be << 16 in game
11:42:45 <dihedral> looking at that line you posted SmatZ i have the impression the 'burst' value is merely a clamp to accumulated limits
11:43:11 <SmatZ> terraform_frame_burst limits number of tiles terraformed in one frame
11:43:36 <SmatZ> terraform_per_64k_frames limits the average number of tiles terraformed over 65536 frames
11:43:55 <dihedral> SmatZ, that is what i would have guessed, but i fail to see that code wise
11:45:25 <SmatZ> well, it seems to be visible from that diff
11:45:44 <SmatZ> terraform_per_64k_frames is added to c->terraform_limit
11:46:17 <dihedral> but the constructor does:
11:46:18 <dihedral> this->terraform_limit = _settings_game.construction.terraform_frame_burst << 16;
11:46:36 <dihedral> and in the update function:
11:46:37 <dihedral> this->terraform_limit = _settings_game.construction.terraform_frame_burst << 16;
11:46:44 <dihedral> c->terraform_limit = min(c->terraform_limit + _settings_game.construction.terraform_per_64k_frames, _settings_game.construction.terraform_frame_burst << 16);
11:46:47 <SmatZ> that loads the maximum value
11:47:03 <SmatZ> terraform_frame_burst is the maximum average value
11:47:16 <SmatZ> terraform_per_64k_frames is the speed at which ...
11:47:26 <SmatZ> well, it's not that easy to explain :)
11:47:35 <dihedral> and now where do this 64k frames come from :-P
11:47:38 <SmatZ> I feel somehow tired today
11:48:46 <dihedral> so if i define a burst of 0 nobody will ever terraform anything
11:49:04 <dihedral> if i define a burst of 1, 65k is the limit
11:49:22 <dihedral> terraforming 65k tiles is not a small amount
11:49:37 <dihedral> or is that tile corners? but then it's still quite some amount
11:50:02 <dihedral> seeing as the burst defaults to 4096 << 16 ....
11:50:26 <SmatZ> 4096 tiles it 64x64 tiles
11:50:47 <dihedral> what what is that << 16 ?
11:51:06 <dihedral> the burst value is always << 16 - which is quite a large number
11:51:24 <dihedral> still a 64x64 tile area is not small
11:51:53 <SmatZ> terraform_frame_burst says how many tiles can be terraformed in one frame
11:52:12 <SmatZ> terraform_per_64k_frames is how many you regain from that limit each frame
11:53:21 <SmatZ> or better, if you terraform 4000 tiles, you have only 96 tiles left
11:53:44 <SmatZ> next frame, terraform_per_64k_frames >> 16 is added to that limit
11:54:03 *** KenjiE20 has joined #openttd
11:54:03 <SmatZ> so, say, you can terraform another 64 tiles
11:54:41 <dihedral> where did you get that >> 16 from?
11:55:01 <SmatZ> well, the limit is << 16
11:55:13 <SmatZ> it's better to talk about values >>16 instead :)
11:55:31 <dihedral> GB(c->clear_limit, 16, 16) <- gets the upper 16 bits, the burst?
11:56:37 <SmatZ> maybe those values are <<16 to allow numbers like 0.5 terraformed tiles in average
11:56:40 <dihedral> now one last question :-)
11:56:54 <dihedral> what defines the 'per 64k frames'
11:57:04 <dihedral> is there a loop that is only run ones every 64k frames?
11:57:58 * andythenorth wants to finish a crossings patch
11:58:00 <dihedral> e.g. the main loop in openttd.cpp
11:58:04 <andythenorth> the baby doesn't share my goal :(
11:59:22 <SmatZ> the cost of each terraform is 1<<16
11:59:45 <SmatZ> terraform_per_64k_frames is added to c->terraform_limit each frame
12:00:02 <SmatZ> up to the limit of construction.terraform_frame_burst
12:00:43 <dihedral> so if i set the per_64k_frames to 1 every day someone may terraform / clear 74 tiles more
12:01:29 <dihedral> then why is one config value always << 16 in game and the other already defined <<16 in the config file
12:01:58 <SmatZ> probably to allow unrounded values
12:02:17 <dihedral> but makes it harder to understand :-P
12:03:34 *** Eddi|zuHause2 is now known as Eddi|zuHause
12:07:27 <SmatZ> it should read "at most 64k frames"
12:08:25 <SmatZ> because if the "burst" limit is 4 tiles, and "64k limit" is 2<<16, and you landscape 3 tiles every frame, you get out of the limit in 3 frames
12:08:53 <SmatZ> peter1138: you have abilities to fix that :) including any other abuse of English in OpenTTD :)
12:09:10 <peter1138> i can't, i'm over my commit quota
12:09:12 <dihedral> SmatZ, then you have to live with a frame without terraforming
12:09:21 <dihedral> which is not too hard as frames are pretty quick :-P
12:09:55 <dihedral> show me a (human) player who would complain :-P
12:09:57 <peter1138> does it affect AIs too?
12:10:14 * peter1138 wonders if it would upset their algorithms
12:10:43 <dihedral> how many ai's actually terraform or clear land?
12:11:15 <Eddi|zuHause> i think admiralai does some terraforming around stations
12:11:18 <peter1138> well, if the old ai is anything to judge... :D
12:12:00 <dihedral> we should run admiral ai, with nasty limits and see what it does :-P
12:27:27 *** Kurimus has joined #openttd
12:40:15 <CIA-2> OpenTTD: smatz * r21734 /trunk/src/lang/english.txt: -Change: use 'landscaping' instead of 'terraforming' in the English lang file (peter1138)
12:41:37 <SmatZ> wow, I can buy a Kendra Wilkinson Sex Tape thanks to a link at tt-forums :)
12:43:24 <kamnet> She is quite hot though
12:45:36 <SmatZ> there are tons of free porn online, I wonder why I should pay for that one..
12:49:21 <__ln___> and why would you want that on tape
12:50:13 <SmatZ> I am not even sure I have a VCR connected to TV
12:50:59 <Eddi|zuHause> i'm fairly certain you wouldn't even get anything related to tape or porn when replying to that link :p
12:51:49 <__ln___> Eddi|zuHause: at least you didn't?
13:03:59 <andythenorth> if I no longer want the patches in my queue....
13:04:28 <Eddi|zuHause> i love how a newbie with first post says "im going to develop this [already marked as impossible] patch", and the next sentence is "whoa, there are soooo many source files"
13:04:43 *** Cybertinus has joined #openttd
13:05:19 <andythenorth> omg, there are a *lot* of source files
13:13:27 <andythenorth> this version leaves road bits set at tram-only crossings
13:13:42 <andythenorth> I want to fix that...
13:15:44 <andythenorth> peter1138: does it harm roadtypes to get rid of this stuff: /* Always add road to the roadtypes (can't draw without it) */
13:15:53 <andythenorth> in road_cmd.cpp and similar in rail_cmd.cpp
13:16:18 <andythenorth> it's the 'must be road at crossings' thing
13:17:10 <andythenorth> l583 in road_cmd.cpp
13:21:09 <andythenorth> I don't mean delete the comment, I mean stop setting unnecessary road bits
13:25:57 <Eddi|zuHause> andythenorth: it really should be removed independet from roadtypes
13:28:16 <andythenorth> but peter said he'd rather not have random hacking at the code
13:29:07 <andythenorth> to me it looks like cruft
13:29:38 <andythenorth> I think I already found and tested the places where it needs to be removed
13:31:19 * andythenorth finds patching trunk a little baffling :)
13:31:24 <andythenorth> who's in charge? :o
13:31:35 <andythenorth> with newgrfs....I'm in charge :D
13:37:40 <peter1138> i took charge of newgrf
13:38:33 <peter1138> Spiritual descendant from newGRF gods
13:38:33 <peter1138> Spiritual descendant from newGRF gods
13:38:34 <andythenorth> I've got another little patch that will hide road base if ROADTYPE_ROAD is not on the tile
13:38:47 <andythenorth> currently all crossing tiles do get ROADTYPE_ROAD
13:38:55 <andythenorth> but I have save game where they don't :P
13:39:12 <peter1138> with roadtypes, ROADTYPE_ROAD doesn't mean anything
13:39:21 <andythenorth> that's interesting
13:40:56 <andythenorth> so there'd be some other way to check? road = 0, tram = 1
13:41:35 <andythenorth> on construction can a roadtype provide both road and tram?
13:41:43 <andythenorth> can't see any reason why not
13:42:28 <andythenorth> it has to be one or the other?
13:42:45 <andythenorth> it's a nice guessing game this :)
13:42:58 <peter1138> does a railtype provide both monorail and maglev?
13:43:08 <andythenorth> there's only one railtype per tile though
13:43:38 <peter1138> and there can be two roadtypes per tile
13:44:44 <andythenorth> and each of those can only be road (0) or tram (1)
13:44:58 <andythenorth> one must be road, one must be tram?
13:45:34 * andythenorth runs out of silly questions :(
13:46:03 <peter1138> think of the case of a road crossing a dirt track
13:46:24 <andythenorth> that's why mr planetmaker suggested three roadtypes per tile...
13:46:33 <andythenorth> dunno if that's possible
13:46:40 <andythenorth> but only two in any given direction
13:46:48 <peter1138> probably not without making the map array bigger
13:47:34 <andythenorth> that's going to make for some interesting routing problems :)
13:47:36 <peter1138> so yeah, roadtypes could be road, tram, dirt track, scalextric...
13:47:48 <andythenorth> trams already are scalextric aren't they?
13:47:53 <peter1138> no reason to assume that you'll have road & tram
13:48:14 <andythenorth> when I say 'tram' I mean that tram vehicles have specific limitations wrt to vehicle movement
13:48:34 <andythenorth> I don't care what it looks like - but they behave differently
13:49:16 <andythenorth> where did I start this?
13:49:47 <andythenorth> those pesky bits set at crossings
13:50:08 <andythenorth> maybe I just leave them alone for now
13:50:23 <andythenorth> they're not needed for current railtype overlay implementation of crossings - I tested
13:50:39 <andythenorth> they're only needed for the legacy version using the base set crossing sprite
13:53:46 *** frosch123 has joined #openttd
13:57:50 *** Eddi|zuHause has joined #openttd
13:58:45 <planetmaker> did I suggest three per tile?!
14:01:27 <andythenorth> well we talked about different ways
14:01:29 <frosch123> afternoon everyone :)
14:01:33 * frosch123 almost typed morning
14:01:41 <andythenorth> if three don't fit in the map, they don't fit I guess
14:01:49 <andythenorth> it will mean a lot of bridges :P
14:11:31 <Eddi|zuHause> it should be: three road types, or two road types and a railtype on crossings
14:12:37 <Eddi|zuHause> imagine: cobble road with tram crossing a dirt road. or road with electrified tram crossing road with unelectrified tram
14:12:59 <Eddi|zuHause> or road with tram crossing road with trolleybus
14:13:17 <andythenorth> tram / non electrified tram + road is an interesting case
14:13:44 <andythenorth> I would rather have three available
14:13:59 <andythenorth> but I'm just a sprite hacker, the map scares me still
14:14:16 <Eddi|zuHause> well, it needs 8 bits.
14:15:26 <Terkhen> heh, MS office suggests UNIX instead of Unix
14:15:36 <peter1138> each road type requires 8 bits
14:15:57 <peter1138> on level crossings each road type requires 4 bits
14:16:27 <Eddi|zuHause> 4 for the id, 1 whether road bit is present?
14:16:45 <peter1138> you can cheat and set the unused types to be the same as the primary type
14:17:01 <peter1138> a bit hacky but saves space
14:17:36 <Eddi|zuHause> but more than two roadtypes on rail crossing sounds improbable...
14:18:00 <Eddi|zuHause> you could argue for road+trolleybus+tram
14:18:44 <Rubidium> dihedral: actually, lowering the burst should have an near immediate effect on companies as well; their limits get clamped to the burst value in any case
14:19:16 <Eddi|zuHause> on the current landscape_grid.html, road has m4 (8bit) free, but i don't know how far you have used that already for roadtypes
14:20:16 <peter1138> they'll all be used
14:20:24 <peter1138> to specify the 2 road types
14:20:35 <peter1138> would need another 8 bits to add the 3rd
14:21:09 <Eddi|zuHause> it's problematic, but i really think it's necessary for any kind of flexibility
14:21:22 <Rubidium> I count 4 bits for road type, 4 bits for road bits, 4 bits for owner
14:21:43 <peter1138> would need another 12 bits to add the 3rd
14:21:56 <Eddi|zuHause> Rubidium: but we already have 3 owners per tile?
14:22:07 <Eddi|zuHause> road, tram, station?
14:22:33 <Eddi|zuHause> means on 3-type roads, stations would be disallowed
14:22:33 <Rubidium> but those have no 3x4 road bits, just 1 bit for the direction
14:23:05 <Rubidium> so they use way less bits than you'd need for fully flexible roads
14:25:44 <Eddi|zuHause> is there a part in the spec that defines which road types cannot occupy the same road bit?
14:26:17 <Eddi|zuHause> like, you can't have unelectrified tram along the electrified tram
14:26:22 <Rubidium> dihedral: the 64k_frames number is the number of terraforms that you may do in 64k frames (or rather 65536 frames), on average (ignoring the burst)
14:26:59 <dihedral> i did not see where that number got reset after 64k frames
14:27:19 <Rubidium> dihedral: now the limit value in company is a fixed point (>>16) value, so when that value is more than 65536 you may build
14:27:58 <Rubidium> dihedral: it isn't reset, each tick you just add 1/65536*64k_frames to the "current" limit
14:28:53 <dihedral> so a high burst and a low 64k limit, rewards those who do not use it for a long period of time
14:29:09 <Rubidium> so if burst = 10 and you may do one terraform per frame, then doing 10 terraform at time 20 means it will take till time 30 till the terraform is back at limit
14:29:58 <Rubidium> and low burst, high 64k limit prevents terraforming large bits at once but allows it to be done in smaller chunks
14:30:03 <dihedral> also, why is the config value for the 64k limit a << 16 value in the config file and the burst is not
14:30:40 <Rubidium> dihedral: it's the amount of tile (heights) you may terraform over 65536 frames
14:31:06 <Rubidium> so if you want an average of 1 tile height terraformed per frame, it has to be 65536, which is 1 << 16
14:31:29 <dihedral> yes, but why not let the user specify 1 in the config file rather than 65536
14:31:33 <Rubidium> it's just to "cancel" out the "per 64k frames" to a per frame in settings.h
14:31:39 <dihedral> or is that so i can also average at half a tile
14:31:48 <Belugas> peter1138: new map array = :) not :(
14:32:14 <Rubidium> then 2294 terraformed tile heights per month would be the minimum
14:32:32 <Rubidium> which is IMHO somewhat large to be really limiting in games
14:32:44 <DorpsGek> Rubidium: 885.621621622
14:33:02 <dihedral> which also does not really impose a limit :-P
14:33:18 <Rubidium> now the limit is one terraformed tile height per 885 days, which does allow to impose some limits
14:33:19 <dihedral> but enough to stop people from flooding large maps
14:34:42 <Rubidium> so the range is from 16384 tile heights per frame to 1 tile height ever 65536 frames
14:35:14 <dihedral> but the 64k limit defaults to 64 << 16
14:35:27 <dihedral> which means 64 tiles in 885 days
14:36:27 <dihedral> and that burst will allow me to level quite a large area after 2.3 years
14:36:48 <dihedral> which is the time i need to get the amount of cache to actually perform such an action
14:37:38 <dihedral> so a lower burst would be better, would it not? as it would limit a single landscaping action to be put into smaller chunks
14:39:14 <Eddi|zuHause> yes, low burst is the more important limit.
14:40:41 <dihedral> so after a certain period of time the limit is clamped to the burst
14:41:27 <dihedral> using that would mean one has to way another 885 days before one can use the full burst again
14:42:47 <dihedral> Rubidium, for the sake of configuring that beast, would it not make sense to have the setting for the per_64k_frames be a decimal value?
14:44:12 <Eddi|zuHause> dihedral: sure, just introduce regexp to parse a decimal value
14:44:43 *** glevans2 has joined #openttd
14:46:25 <dihedral> wow - i only just realized that we have no floats in the config
14:47:46 <Rubidium> dihedral: no, 64<<16 means 64 per day, or 64*65536 per 65536 days
14:47:54 <Rubidium> also, the configuration file is decimal
14:48:05 <Rubidium> the << 16 is only for source code file
14:50:25 <dihedral> per day? i thought things were added per frame :-P
14:51:16 <Rubidium> yeah... s/day/frame/
14:51:39 <dihedral> so 64 per frame or 64/74 per frame ^^
14:53:00 <Rubidium> 64<<16 means 64 per frame
14:53:07 <Rubidium> but you can't use 64<<16 in the config file
14:53:17 <Rubidium> you'll have to use the decimal value in the config file
14:53:21 <Rubidium> so you'll have to use:
14:53:55 <dihedral> bu then 64 tile heights / tiles per frame is a huge value over the course of time
14:54:18 <dihedral> yet if the burst is 128, then it clamps at 2 frames
14:55:12 <Rubidium> it's a limit; it's not a quota you must reach
14:55:29 <Rubidium> and the default limits are meant to be (almost) never reached by normal gameplay
14:58:07 <dihedral> but to make it somewhat more challenging, setting the 64k limit to 1 tile per day (not per frame) it will take a while until someone can do something
15:08:22 <Rubidium> then set 64k_frames to 885
15:09:41 <DorpsGek> Rubidium: 1.00070239731
15:10:27 <Rubidium> so it will be 1 tile every 1.0007 days ;)
15:10:42 <dihedral> or tiles, (clear land)
15:11:24 <dihedral> which in essense is still not a bad value
15:16:08 <Eddi|zuHause> that boils down to 1 piece of rail/road/station per day, which might be too limiting
15:16:19 <Eddi|zuHause> or is there a different weight for clearing and terraforming?
15:16:37 <Rubidium> they're somewhat unrelated
15:16:55 <Rubidium> you can limit terraforming to 1 tile a year and still clear 500 tiles a frame
15:17:38 <Eddi|zuHause> yes, that makes sense
15:18:06 <dihedral> can companies start off with burst?
15:18:21 * peter1138 freezes dihedral's water pipes
15:18:50 <dihedral> or a separate (configurable) start value
15:19:32 <dihedral> but a moderate start value, and a low per_64k_frames value would compensate for a decent start, yet be a good limit
15:20:10 <Rubidium> dihedral: yes, they get the "burst" as free bonus upon inauguration
15:23:10 <andythenorth> how many bits does catenary occupy?
15:24:26 <SmatZ> it's defined in railtype
15:25:50 <andythenorth> that's the end of a cunning plan :P
15:27:04 <andythenorth> does limiting to 8 road types save any bits?
15:28:20 <andythenorth> 4 roadtypes is only 2 bits per type?
15:29:08 <SmatZ> 4 roadtypes would need only 2 bits, yes
15:29:21 <SmatZ> to identify one of them
15:29:25 <peter1138> and 8 road types would need 3 bits
15:30:01 <andythenorth> and 8 doesn't save enough bits
15:31:23 <SmatZ> if there could be only 8 road types and 8 tram types, you would need only 3 bits for each
15:31:43 <peter1138> then it's not very flexible
15:31:54 <andythenorth> 8 of each? plenty flexible
15:31:58 <andythenorth> 8 in total would be enough
15:32:06 <andythenorth> I guess I don't play crazy multi-player games :P
15:32:21 <andythenorth> 8 of each is plenty
15:32:41 <SmatZ> maybe there is a bit indicating "this tile has road" and "this tile has tram"
15:32:48 <SmatZ> I think there is, actually
15:32:58 <andythenorth> don't you need two bits for that?
15:33:11 <SmatZ> you only need 4 bits for road/tram bits
15:33:40 <SmatZ> m7 bits 7..6: present road types
15:34:01 <SmatZ> so you can save those two types and use "getroadbits() != 0" instead
15:34:15 <SmatZ> at the cost of some performance penatly
15:35:43 <SmatZ> [16:34:36] <SmatZ> so you can save those two types <== bits
15:35:56 <SmatZ> not that it was the only typo...
15:36:29 <dihedral> you are forgiven :-P
15:44:39 <andythenorth> how do two current road types + one railtype fit into a tile?
15:44:48 <andythenorth> I don't even want to ask about bridges :P
15:45:39 <peter1138> i worked it all out once...
15:45:43 <Wolf01> road + tram already have common bridges IIRC
15:53:35 <dihedral> heh - so if per_64k_frames = 0 and burst = 4096, a company can at max level that many hights in the cause of the entire game
15:54:41 <dihedral> however, i would really think it could be a good idea of connected bots to have an influence on these values on a per company basis
15:55:01 <dihedral> or via console command
15:55:48 <dihedral> that way one could implement other algorithms based on e.g. the age of the company, their value, etc.
15:57:29 *** heffer_ has joined #openttd
16:03:48 *** heffer_ is now known as heffer
16:03:58 <Rubidium> dihedral: that's getting really complex
16:04:32 <Rubidium> as you basically need to write a load of commands to get all those things executed at the right time and such
16:06:19 <andythenorth> so if two roadtypes uses 8 bits...
16:06:27 <andythenorth> for 16 allowed types
16:06:36 <andythenorth> can't we just have 4x road and 4x tram
16:06:53 <andythenorth> two bits for road, two bits for tram
16:07:15 <andythenorth> up to three per tile, 2 bits spare for magic
16:08:37 <Eddi|zuHause> if you strictly separate road and tram, then you need to allow two each
16:09:02 <andythenorth> that's what my maths does...
16:09:03 <Eddi|zuHause> plus, you only reduced the ids, the bits and the owners still need saving
16:09:22 <andythenorth> can we make bits bigger :P
16:09:28 <andythenorth> give them spin or something
16:09:38 <Eddi|zuHause> i meant "road bits", as in the 4 directions on the tile
16:16:37 *** HerzogDeXtEr has joined #openttd
16:18:46 *** OTTDmaster has joined #openttd
16:27:28 *** andythenorth is now known as anyone
16:28:02 <OTTDmaster> hello anyone AKA andythenorth
16:28:37 <OTTDmaster> how's your patch going?
16:29:12 <OTTDmaster> have you visited the pub recently?!?
16:32:13 <dihedral> can i not set a limit for a company without having to do that every frame?
16:32:30 <dihedral> i.e. set the burst to x and set the per_64k_frames to 0
16:32:37 <dihedral> and tamper with the per company limit
16:33:16 *** Biolunar has joined #openttd
16:33:36 <dihedral> and include those values in company update packets
16:33:40 <dihedral> and company info of course
16:33:57 <SpComb> I liked the idea of having to balance your landscaping out across raise/lower
16:34:16 <SpComb> if you lower land somewhere you have to raise it somewhere else, and vv. :)
16:34:44 <peter1138> does placing tracks count as clearing land?
16:37:37 <Eddi|zuHause> placing on previously unowned land
16:37:41 <dihedral> clearing land and landscaping are handled separately
16:38:24 <SmatZ> raising one corner clears 4 tiles, right?
16:38:47 *** anyone is now known as andythenorth
16:39:30 * OTTDmaster kicks andythenorth
16:39:43 <Eddi|zuHause> i hope the clearing count does not count clearing clear land
16:40:12 <SpComb> is this a feature already in trunk?
16:42:08 <andythenorth> roujin had a basic patch which put trails into the unused (HWAY) slot
16:42:15 <andythenorth> I guess he didn't need labels though
16:44:54 <SpComb> tsk, technical measures to fix social issues
16:45:01 <SpComb> although I guess it also goes to enforce style
16:45:28 <andythenorth> surely there's some trickery with the direction bits
16:50:08 <andythenorth> if there was a way to get three roadtypes on a tile, how could they cross
16:50:21 *** supermop has joined #openttd
16:50:28 <andythenorth> what about overlappin L shapes (best way I can describe it)
16:55:18 <SpComb> so who's got a server up with a zero terraform limit
16:56:47 <reaven> Im having a bit of trouble with a train network I made
16:57:02 <reaven> sometimes trains get through stations they shouldnt
16:57:16 <reaven> and I think its because the ywant to get to a nearby depot...
16:58:08 <ABCRic> 1. place depots better; 2. waypoints
16:58:11 <OTTDmaster> have a depot before the station or tell the train to service after the station
16:58:27 <SpComb> simple way: disable servicing (turn off breakdowns and enable the 'no servicing without breakdowns' option or somesuch)
16:59:21 <ABCRic> 3. what SpComb said (best solution of all :D)
16:59:43 *** [com]buster has joined #openttd
17:00:18 <reaven> you mean disabling trains breaking at all?
17:00:53 <OTTDmaster> braking *down* you meaan?
17:01:05 <OTTDmaster> braking is a different thing
17:05:10 *** heffer_ has joined #openttd
17:06:08 <reaven> this is the firts somewhat complex network I made so I wasnt expecting depots to be a problem like this
17:06:08 *** heffer_ is now known as heffer
17:06:36 <SpComb> trains heading for servicing is a force to be reckoned with :P
17:06:38 <OTTDmaster> It's happened to the best of us!
17:06:41 <SpComb> if you want to use servicing, then use servicing orders
17:07:05 <dihedral> how can brakedowns be improved?
17:07:09 <reaven> yeah I guess I will have to order the servicing at precise depots
17:07:37 <OTTDmaster> do yu use servicing centres?
17:09:48 <reaven> me? right now I have a depot near every station so before loading they will service
17:10:25 <OTTDmaster> You can force service it
17:11:18 <reaven> but its funny because sometimes when they went to service to a depot that goes by a station they shouldnt go they even started to load cargo there...
17:11:40 <OTTDmaster> force servicing is a lot easier
17:11:58 <OTTDmaster> no order changes required
17:12:25 <SpComb> OTTDmaster: severely outdated
17:13:21 <SpComb> reaven: that's how orders work by default, trains will stop at stations
17:13:50 <reaven> yeah but they dont have an order to stop there
17:14:12 <SpComb> I mean, they'll stop at stations along the route between two orders
17:14:15 <reaven> they shouldnt even get to that section of the network
17:14:43 <SpComb> which is a rather silly piece of legacy imo, but I guess some people use it for long linear routes
17:14:45 <dihedral> ABCRic, i am aware of the existing approach ;-)
17:15:08 <OTTDmaster> is that enough in date?
17:15:14 <ABCRic> dihedral: you asked how they could be improved...
17:15:16 <reaven> I made it so that a train only has to pass between the two stations he should, but since they went to the nearest depot they found...
17:15:24 <reaven> thats where the problem began
17:15:31 <dihedral> ABCRic, yeah - but i was not after any implementation
17:15:39 <dihedral> but a decent one, one that could be of interest of trunk
17:15:50 <ABCRic> still, it has some ideas :)
17:16:07 <OTTDmaster> also have you done shared orders?
17:16:17 <reaven> I will look into teh force service
17:18:06 <andythenorth> because there can only be two types for any given direction, my brain says that we should be able to get all direction information into 8 bits
17:18:12 <andythenorth> but my fingers can't write down how :P
17:20:51 <reaven> I have a hard time getting a rating over 70% on industries
17:21:08 <andythenorth> there is a way to do it
17:21:21 <andythenorth> it's probably a performance pig though
17:22:25 <reaven> I think I read on the forums you need two stations getting from the industry or something like that?
17:24:05 <fjb> reaven: Have a vehicle always waiting at the station, buy new vehicles, buy fast vehicles, build a statue.
17:25:27 <reaven> yeah I try to keep a vehicle always loading
17:25:49 <reaven> I guess I should renew most trains tho
17:27:27 <reaven> I forgot to turn off AI and they are filling the whole map with truck stealing all my coal D:
17:28:03 <andythenorth> if there are 3 roadtypes on a tile, must be 1road and 2 tram, or 2 road and 1 tram
17:28:11 <andythenorth> so for direction
17:28:42 <andythenorth> 1 1 flips to second tram or road
17:29:01 <andythenorth> which means direction can be done in eight bits
17:29:35 <fjb> reaven: It is not your coal.
17:29:42 *** Chruker has joined #openttd
17:30:46 <andythenorth> owner I'm baffled by
17:30:59 <andythenorth> how many bits are free? :P
17:33:09 *** Prof_Frink has joined #openttd
17:41:24 <andythenorth> the tile already has two lots of bits for owners of tram / road
17:41:47 <andythenorth> can't we nick the level crossing bits in this case?
17:42:04 *** HalfBit has joined #openttd
17:55:39 <andythenorth> why does 'owner road' take 5 bits, but 'owner tram' takes 4?
17:55:39 <andythenorth> m1 bits 4..0: owner of the road type 0 (normal road)
17:55:49 <andythenorth> m3 bits 7..4: owner of road type 1 (tram); OWNER_NONE (10) is stored as OWNER_TOWN (0F)
17:58:47 *** Eddi|zuHause has joined #openttd
17:59:15 <Eddi|zuHause> err... stuff gets more and more weird the more you try to fix them...
17:59:48 <andythenorth> these look a bit dangerous: m5 bits 5..4: bits to disallow vehicles to go a specific direction
17:59:56 <andythenorth> as in, they might need more bits...
18:00:41 <andythenorth> Eddi|zuHause: what do you reckon to repurposing level crossing bits if there's no crossing?
18:01:02 <Eddi|zuHause> andythenorth: i believe that is already done
18:01:14 <frosch123> andythenorth: there are 16 possible owners for tram, but 17 for roads
18:01:22 <frosch123> towns can own road, but not tram
18:01:27 <andythenorth> towns don't build roads
18:01:50 <Eddi|zuHause> frosch123: but in the future towns may own various road types?
18:02:02 <andythenorth> so for roads, 5 bits are needed per roadtype, not 4
18:02:22 <frosch123> Eddi|zuHause: depends what you consider a roadtype
18:02:30 <frosch123> i did not follow your discussion btw :)
18:02:48 <andythenorth> the crossing bits are already repurposed :(
18:03:33 <andythenorth> so for 3 roadtypes per tile, 15 bits needed just for owners :(
18:03:36 <frosch123> but my historically-grown impression about the topic is: more than two roadtypes on one tile make no sense. there are road-like roadtypes and tram-like roadtypes (wrt. reversing and such)
18:03:40 <Eddi|zuHause> frosch123: i had a suggestion about that like a year ago. like there are road types allowed to be built by towns, road types not allowed to be built by towns, and road types which towns do not grow along
18:04:02 <frosch123> so you could have one of many road-like roadtypes on one tile and in addition one tram-like roadtype on a tile
18:04:17 <andythenorth> the issue is more interesting if you think about crossing
18:04:34 <andythenorth> e.g. electrified tram, road, non-electrified tram
18:04:38 <Eddi|zuHause> so early towns may build cobblestone road, later towns may build asphalt roads, but no town will build highway
18:04:54 <andythenorth> the tram issue is bogus
18:05:06 <andythenorth> just run the electrified tram one extra tile off the junction
18:05:26 <andythenorth> the trolleybus example would be bogus as well if there was a way to say 'there is power on this tile'
18:05:42 <Eddi|zuHause> tricky gets the part: towns may "consume" a land-road, turning it into a town road, but not a highway-road
18:06:31 * andythenorth wonders if there is a way to just have two roadtypes and still have crossing flexibility
18:07:28 <Eddi|zuHause> frosch123: so you suggest to limit it to one road-like type and one tram-like type per tile? never two road-like types?
18:07:30 <frosch123> andythenorth: you have the same issue for rails
18:07:48 <andythenorth> I was thinking that
18:08:00 <andythenorth> but we are used to rail / monorail / maglev not overlapping
18:08:04 <frosch123> if you have a crossing of normal rail and el-rail, the crossing is el-rail, but afaik it will not draw the wires in the other direction due to the adjacent tiles
18:08:19 <andythenorth> some point of roads is...they are not rails
18:08:35 * andythenorth wonders if there's a way to special case for junctions
18:10:17 <andythenorth> I was counting bits that could be free, and bits needed to see if three types fit
18:10:24 <andythenorth> but I probably don't know enough to do that :P
18:15:09 <andythenorth> having junctions check adjacent tiles is bad for 99 reasons
18:16:27 *** Eddi|zuHause has joined #openttd
18:16:49 <supermop> but a tram ain't one?
18:17:21 <Eddi|zuHause> frosch123: but if you now limit it to one of each type, the "ID"-space doesn't need to be shared anymore, so you can reduce the IDs
18:17:49 <andythenorth> can't be one of each type
18:17:49 <Eddi|zuHause> so like 8 road-types and 8 tram-types
18:17:55 <andythenorth> that's very broken
18:18:01 <Eddi|zuHause> andythenorth: why not?
18:18:22 <andythenorth> limiting number of types to 8 would be fine (or even 7 - I had an idea)
18:18:35 <andythenorth> but preventing roadtype roads crossing each is painful
18:18:41 <andythenorth> dirt tracks couldn't cross road, etc
18:18:53 <frosch123> Eddi|zuHause: afaik there is enough space for 16 road-types and 16 tram-types
18:18:59 <andythenorth> if we limit to 7 of each type
18:19:10 <andythenorth> then that's just three bits
18:19:12 <Eddi|zuHause> andythenorth: so you would end up with a stub of asphalt road at the end of a dirt road, which is not entirely unrealistic
18:19:30 <andythenorth> Eddi|zuHause: sounds like you are thinking similar idea to me?
18:19:30 <frosch123> andythenorth: what is the effect of dirt roads crossing road?
18:19:36 <Eddi|zuHause> andythenorth: 8 is also three bits (0 to 7)
18:19:46 <frosch123> imo that makes no sense, there is either dirt in the middle, or not
18:19:49 <andythenorth> you need 00 free
18:20:01 <andythenorth> to say 'no type defined'
18:20:22 <andythenorth> how else do you know a type is present?
18:20:28 <andythenorth> you have to use another bit
18:20:31 <Eddi|zuHause> andythenorth: from the road bits
18:20:36 <andythenorth> scrap the road bits :P
18:20:55 <Eddi|zuHause> you can't scrap the road bits
18:20:57 <andythenorth> it's easy for me to say, I have no idea what I"m talking about :)
18:21:25 <andythenorth> I think direction for three types can be done with 8 bits
18:21:32 <andythenorth> but probably very slow
18:21:35 <supermop> are the light/gate sprites separate from the road sprite?
18:21:49 <andythenorth> supermop: you'd need to ask a more precise question
18:22:26 <andythenorth> Eddi|zuHause: frosch123 what if there was a special case for road roadtypes
18:22:35 <andythenorth> and all junctions are just defined as a 'super' road
18:22:40 <andythenorth> which all vehicles may travel on
18:22:51 <andythenorth> this is provided by the game as part of openttd.grf
18:23:10 <Eddi|zuHause> the game will only ever provide the default roads
18:23:48 <Rubidium> dihedral: because if you start with this limitation you'll have to start with other settings as well
18:24:04 <Rubidium> and you'll need to add a whole new class of settings: company settings forced by the server
18:24:21 <andythenorth> if road junctions were special cased, vehicles could be told to ignore the roadtype label
18:24:32 <andythenorth> solves the crossing problem
18:24:39 <andythenorth> dunno what sprites get drawn though
18:24:40 <Rubidium> and it sounded like you wanted to manipulate the actual "current" limits of companies as well
18:24:43 *** Eddi|zuHause has joined #openttd
18:25:01 <andythenorth> Eddi|zuHause: if road junctions were special cased, vehicles could be told to ignore the roadtype label
18:25:09 <dihedral> are they not only used server side Rubidium ?
18:25:23 <Eddi|zuHause> andythenorth: i see no sensible application of that
18:25:33 <andythenorth> rvs could drive through any road junction
18:25:35 <supermop> Ok, can we already arbitrary provide lights independent of crossing sprites and vis-versa
18:25:39 <Rubidium> dihedral: the checks and such happen at command execution time, i.e. at both the server and client
18:25:47 <Eddi|zuHause> andythenorth: either your vehicles are allowed to cross the asphalt road, or they aren't
18:25:49 <andythenorth> supermop: if your doing a railtypes newgrf yes
18:26:24 <Eddi|zuHause> andythenorth: you can always provide such a "super-road-type" in your grf
18:26:29 <andythenorth> Eddi|zuHause: what about we just take the first of those options every time
18:26:40 <andythenorth> vehicles are always allowed to *cross* another road type
18:26:44 <andythenorth> compatible or not
18:26:56 <Rubidium> dihedral: as you need to physically execute the terraforming to know how much you could actually terraform
18:27:06 <andythenorth> yeah, so dump trucks could cross motorways
18:27:06 <Eddi|zuHause> andythenorth: that doesn't sound right
18:27:10 <andythenorth> there are problems with it
18:27:19 <andythenorth> shall we count bits?
18:27:30 <dihedral> so when i change the setting in the middle of the game, how does this setting get sent to the clients in order for them to update their local values too?
18:27:32 <andythenorth> 9 bits already for owners
18:27:50 <Rubidium> dihedral: like any other setting is updated to the client
18:27:51 <Eddi|zuHause> andythenorth: hä?
18:28:30 <dihedral> shame - i thought this was executed on the server :-P
18:28:42 <dihedral> e.g. server side only - in a mp game at least
18:29:03 <Rubidium> dihedral: that's be way too difficult
18:29:12 <andythenorth> if road vehicles are not allowed to cross all road types, there's a significant griefing opportunity
18:29:26 <Rubidium> as you need to split up the clear/landscaping commands into multiple commands to get the right area cleared/terraformed
18:30:07 <andythenorth> all I have to do is build a highway piece across your dirt road, your dump trucks all stop
18:30:28 <dihedral> so the clients actually have that information for every company
18:30:54 <dihedral> so they get a desync if they tamper with it
18:30:57 <Eddi|zuHause> the "road" type needs 4 road bits, 5 owner bits, 4 id bits (=13), the "tram" type needs 4 road bits, 4 owner bits, 4 id bits (=12), makes together 25. plus owner of the station makes 29, plus bit whether it's a rail crossing is 30, plus desert/grass/snow/pavement/..., plus bridge above
18:31:13 <Eddi|zuHause> how many bits do we have per tile? 40?
18:31:17 <Rubidium> like they'll desync if they tamper with a lot of other things
18:31:30 <andythenorth> Eddi|zuHause: you need to allow for two road types, so an extra id bit
18:31:34 <Eddi|zuHause> it's getting awfully close
18:31:50 <dihedral> i just thought i could hop in there and set limits for company 0 after it has existed for x years
18:31:58 <Rubidium> Eddi|zuHause: station tiles and road tiles are distinct
18:32:14 <Rubidium> Eddi|zuHause: also, stations only need to know the axis and available road types
18:32:31 <Rubidium> likewise rail crossings only need axis and available road types and the used rail type
18:32:32 <dihedral> i'll catch you guys later ;-)
18:32:34 <Eddi|zuHause> yes, that's 3 bits less in the above calculations
18:33:10 <Eddi|zuHause> Rubidium: yes, but they need to store other stuff, like station type or rail type
18:33:31 <Rubidium> then there's the stuff like town owner of the road, the road works, one wayness, and the "pavement" type
18:34:18 <Eddi|zuHause> "owner town" is the 5th bit of the owner, i thought
18:34:25 <Eddi|zuHause> or do you mean "which town"?
18:34:32 <Rubidium> Eddi|zuHause: the latter
18:35:05 <Eddi|zuHause> but isn't a town id like 16 bit?
18:36:23 <Rubidium> station could easily get a third type
18:37:06 <Rubidium> custom bridge types + a third road type is not going to work
18:37:13 <Eddi|zuHause> but then... can't there be bit-hackery so you use 1 bit for whether the owner is town or company, and then use the 16 bits for town or owner id?
18:37:16 <Rubidium> (without expanding the map array that is)
18:37:27 <Eddi|zuHause> so first owner has 17 bits
18:37:44 <Rubidium> Eddi|zuHause: how does that help anything?
18:38:02 <Wolf01> ooook, now I'm reinstalling VC80 so I can compile again my projects and OTTD, now I have 115GB of free space :D
18:38:11 <andythenorth> can I overbuild road where another company already has road?
18:38:25 <Rubidium> and what do you want with the extra road type?
18:38:33 <Eddi|zuHause> Rubidium: you don't need space for a company-id if the owner is a town, and you don't need space for a town-id if the owner is a company
18:39:17 <andythenorth> Rubidium: the extra type is needed for roads that cross
18:39:35 <Rubidium> then you want to add a fourth type as well
18:39:48 <Rubidium> after all, 2 road types that cross 2 other road types
18:39:53 <andythenorth> there is that logic
18:39:57 <andythenorth> but we could ignore it :P
18:40:11 <andythenorth> or we could follow it the other way, and limit to two types per tile
18:40:11 <Rubidium> but then... you can have 4 road types on a tile, so you want 4 road types crossing 4 other road types
18:40:35 <andythenorth> only two in any direction :P
18:40:49 <andythenorth> aren't the example cases for this bogus?
18:41:14 <andythenorth> trolleybus crossing road + tram
18:41:19 <Rubidium> normal road + tram + trolley bus crossing a dirt road?
18:41:42 <Wolf01> normal road should override dirt road
18:42:08 <andythenorth> this is down to the sanity of newgrf authors
18:42:29 <andythenorth> anyone defining trolley bus should make it compatible with 'road' so that ordinary road vehicles also use it
18:42:34 <andythenorth> then road isn't needed on that tile
18:42:48 <andythenorth> we're just at 'trolley bus' + 'tram'
18:43:12 <andythenorth> you need dirt road crossing tram + road?
18:43:18 <Rubidium> but then what to do with the catenary when a normal road crosses a trolley bus road?
18:43:30 <andythenorth> draw whichever has the higher id in the table
18:43:36 <Rubidium> should you get a junction in the catenary?
18:43:41 <andythenorth> it's just a game
18:43:49 <andythenorth> or just draw both sets of catenary
18:43:50 <supermop> i think you could jut draw cat for the whole tile
18:44:11 <andythenorth> drawing n sets of catenary would be bobbins :P
18:44:21 <Wolf01> you'll end up with a large gray square
18:44:28 <andythenorth> could just have a bit for 'catenary is on this tile'
18:44:37 <supermop> can we get a bumpercar type of caternary?
18:44:38 <andythenorth> but I suppose that unpicks all of the 'power' stuff
18:44:39 <Rubidium> but drawing catenary on the whole tile might make people think that the trolley bus can turn at that tile while you may not want that
18:45:01 <andythenorth> if you follow that logic, you end up deciding road types is a bad idea :)
18:45:14 <supermop> steel mesh roof over the whole road,
18:45:15 <andythenorth> is roadtypes a bad idea?
18:45:29 <supermop> bumper cars carrying one passenger each
18:45:50 <Rubidium> andythenorth: not bad, but it allows you to make a lot of "bad" decisions w.r.t. what users expect
18:46:12 <CIA-2> OpenTTD: translators * r21735 /trunk/src/lang/ (13 files): (log message trimmed)
18:46:12 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
18:46:12 <CIA-2> OpenTTD: croatian - 7 changes by VoyagerOne
18:46:12 <CIA-2> OpenTTD: dutch - 7 changes by Hyronymus, habell
18:46:12 <CIA-2> OpenTTD: english_US - 7 changes by Rubidium
18:46:13 <CIA-2> OpenTTD: estonian - 42 changes by notAbot
18:46:13 <CIA-2> OpenTTD: finnish - 7 changes by jpx_
18:46:15 <Wolf01> I think is better to implement different diagonal railtypes on the same tile, then diagonal roads, then roadtypes ;)
18:46:21 <andythenorth> Rubidium: so does industry newgrf spec :P
18:46:29 <Eddi|zuHause> Rubidium: i don't understand your question. the "road" bits know they have no catenary, and the "trolley" bits know they have catenary. so you can just calculate where to draw catenary
18:46:43 <Eddi|zuHause> it's no different than current behaviour with tram on road
18:47:05 <andythenorth> wasn't he replying to the 'draw for the whole tile' suggestion?
18:47:21 <Eddi|zuHause> no, that was later ;)
18:47:30 <Rubidium> Eddi|zuHause: not when you stick with the "draw the best" road type
18:47:38 <andythenorth> diagonal roads - not enough bits. so no diagonal roads, thanks
18:48:11 <Rubidium> i.e. road and trolley bus road are considerd "the same" class and only one of the two is allowed on a tile
18:48:36 <andythenorth> nearly as much fun as cargo classes!
18:49:17 <andythenorth> the current labels spec scares me slightly as an rv set author
18:49:29 <Rubidium> and yes, I've thought about splitting "has catenary" into the third road type a long time ago
18:49:30 <andythenorth> I have to keep track of every label authors choose to invent
18:50:03 <andythenorth> Rubidium: what would be the downsides of 'has catenary' being a simple bit on the tile?
18:50:07 <Rubidium> so you can mix stuff to get road with catenary and trams without catenary, but it felt a bit pointless
18:50:22 <Eddi|zuHause> Rubidium: i'm sorry, i can't follow you.
18:50:27 <Rubidium> andythenorth: that you still have no clue where it's meant to be
18:50:32 <Eddi|zuHause> Rubidium: you seem to be jumping around arguments
18:50:57 *** |Jeroen| has joined #openttd
18:51:36 <andythenorth> Rubidium: you look in each roadtype present to see if it (a) sets powered, then (b) check its direction bits?
18:51:38 <Eddi|zuHause> Wolf01: yes, those exist
18:51:48 <andythenorth> add those up to 'draw catenary for these directions
18:51:49 <Eddi|zuHause> Wolf01: also, horse trams
18:51:59 <Rubidium> as I would dislike to get a full "junction" of catenary to be shown for when an electrified tram crosses a normal road
18:52:24 <Wolf01> I know about horse and steam trams, but I thought they replaced all with electric ones :)
18:52:25 <Rubidium> unless you're claiming we should go for the electrified rail way of guessing what the user meant by looking at the other tiles
18:52:40 <andythenorth> no need, just look at the direction bits? :o
18:53:58 <andythenorth> Eddi|zuHause: we're pretty much stuck with 2 types per tile?
18:54:09 <Eddi|zuHause> what i *think* that andythenorth meant was when two types clash, you draw only one of them: like when two road-types are on a tile, only draw one road surface. if two catenary types are on one tile, choose only one catenary type to draw
18:54:09 <andythenorth> I reckon we can get all the direction bits for 3 types into 8 bits
18:54:58 <peter1138> good luck with that
18:55:09 <andythenorth> for three types, each direction only needs two byes
18:55:12 <Eddi|zuHause> so when normal road and trolley road cross, draw the normal road over the trolley road, but draw trolley catenary only on the trolley road, not the normal road
18:55:14 * peter1138 remembers hackykid's pbs include a "track bit compression" scheme
18:55:26 <andythenorth> sounds like the thing I'm inventing :P
18:55:38 <andythenorth> 0 0 = no type in this direction
18:55:54 <peter1138> there are 4 road bits
18:55:58 <andythenorth> yeah, it's not at all how it currently works :P
18:56:16 <andythenorth> probably won't catch any good fish
18:56:50 <andythenorth> I can't find a better word for direction
18:56:50 <Rubidium> Eddi|zuHause: but then you'd be drawing pavement over the trolley road, wouldn't you?
18:57:06 <andythenorth> there are 4 places where half a tile of road can be drawn
18:57:35 <Eddi|zuHause> Rubidium: suppose there are 2 road bits along the X axis, and 2 trolley bits along the Y axis
18:57:48 <Eddi|zuHause> Rubidium: then you draw the road as if it were all 4 road bits
18:57:50 <Rubidium> Eddi|zuHause: you're drawing the / of the trolley bus' track, then the \ of the road (possibly with pavement)
18:57:59 <Eddi|zuHause> Rubidium: and the catenary as if you have only the Y axis
18:58:21 <Rubidium> Eddi|zuHause: but then you need to know that the trolley bus track has the same "road" surface
18:58:39 <Eddi|zuHause> Rubidium: so "road surface" is "unification over all road-like types"
18:58:57 <Eddi|zuHause> Rubidium: no, you just take one of the road types at "random"
18:59:18 <andythenorth> you default to using the 'super' road type supplied by openttd.grf :P
18:59:29 <andythenorth> which I will draw to look nice in all places :P
18:59:39 <Rubidium> Eddi|zuHause: but won't you be getting stuff like a dirt junction on a highway?
18:59:45 <Eddi|zuHause> so depending which type has the lower/higher ID, you choose to draw all "road" road, or all "trolley" road
19:00:00 <Eddi|zuHause> Rubidium: yes, but that is the user's fault ;)
19:00:29 <andythenorth> we can live without the dirt junction
19:00:36 <andythenorth> there'll be a junction at the tile border :P
19:00:41 <andythenorth> it will be quite....defined
19:01:10 <Eddi|zuHause> Rubidium: i can't see a sensible way to graphically mix two road types together. they must bring own methods to "blend", which is only possible if the two types come from the same grf
19:01:30 <Rubidium> Eddi|zuHause: but then you'd (much earlier) need tunnels and bridges to go over/under dirt roads of a competitor
19:01:57 <andythenorth> can you create junctions with competitors roads currently?
19:02:12 <andythenorth> (same would apply to town roads anyway)
19:02:15 <Eddi|zuHause> andythenorth: yes, but the whole junction will be owned by the competitor
19:02:53 *** LordAro has joined #openttd
19:03:14 <Rubidium> so in the end I'd say you end up with N road (surface) types and M tram types (possibly with catenary)
19:03:14 <andythenorth> or a hierarchy depending on a translation table
19:03:20 <Eddi|zuHause> Rubidium: but you can come up with similarly silly situations when you only allow one road type and one tram type per tile
19:03:36 <supermop> I'm off to lunch, love to hear where this discussion ends up going
19:04:08 <Rubidium> Eddi|zuHause: but there it's quite clear: trams will always be drawn as tracks over road (if there is road)
19:04:21 <Eddi|zuHause> Rubidium: like that way, if you define "trolley" as "road with catenary", you can't build trolley/road crossings at all, the tile would be all-trolley or all-road
19:05:03 <Eddi|zuHause> which brings you back to catenary-in-all-directions
19:05:24 <Eddi|zuHause> plus, you still have to solve the clash between catenary of the road type, and catenary of the tram type
19:05:30 <Rubidium> which is annoying, and it means we basically need a third set of bits/owner information for the catenary
19:05:32 <Eddi|zuHause> you can't really draw both of them either
19:05:40 <andythenorth> have the game provide catenary in the base set
19:06:03 <andythenorth> make it an option - electrify this route or not
19:06:05 <Rubidium> Eddi|zuHause: true, you can't draw different catenaries. But we could enforce all road related catenary to be the same through the whole game
19:06:05 <Eddi|zuHause> there is catenary in the base set, but it's ugly
19:06:12 <andythenorth> ach that's just sprites
19:06:19 <andythenorth> use 4 more bits for the catenary direction
19:06:27 <andythenorth> make it a thing players can explicitly build
19:06:32 <Rubidium> but then you'll end up with shit for the elevated hanging road vehicles
19:06:42 <andythenorth> they're broken anyway
19:06:53 <andythenorth> it's a clever hack by Zephyris that's never going to work
19:07:35 <Eddi|zuHause> Rubidium: afair catenary can be defined on a per-railtype basis, why disable that for roadtypes?
19:07:43 <Rubidium> which brings us, basically back, to the whole root problem: having trams
19:08:27 <Rubidium> as without having trams, and thus no catenary on roads it'd all be much easier
19:09:04 <Eddi|zuHause> Rubidium: but trams were really one of the most important features missing from TTD
19:09:34 <Eddi|zuHause> SmatZ: even more than those
19:09:45 <SmatZ> I never missed trams :)
19:09:56 <Rubidium> I'd miss all the draggable building stuff way more than trams
19:10:02 <SmatZ> maybe that's because I am playing mostly only train games
19:10:18 <SmatZ> non-uniform stations and station joining
19:10:28 <Eddi|zuHause> i haven't played a game without trams ever since they got introduced
19:10:41 <SmatZ> everyone has his own preferences :)
19:10:53 <Rubidium> I barely played a game with trams
19:11:03 <Rubidium> but then, I barely played a game at all
19:11:09 <Terkhen> they are quite fun sometimes
19:11:28 <Rubidium> the San Francisco ones are especially fun
19:11:35 <Eddi|zuHause> they are really essential with cargodist
19:11:38 <SmatZ> then I played only #coop games :)
19:11:41 <Rubidium> when they "lose" their connection with the cateneray
19:11:42 <Eddi|zuHause> busses have so low capacity
19:12:15 <Terkhen> not only with cargodist; with large cities I need a tram network to get more passengers
19:12:25 <Eddi|zuHause> Rubidium: you mean the san francisco cable cars or the san francisco trams?
19:12:45 <Eddi|zuHause> (those are different things)
19:12:58 <Terkhen> but that was until I recently discovered the metro trains
19:13:08 <andythenorth> the catenary is a distraction from the 2 types / 3 types question
19:13:14 <Rubidium> Eddi|zuHause: the tram
19:13:20 <andythenorth> but the answer has to be 2 types?
19:13:24 <__ln___> and there are at least two kinds of trams in SF
19:13:27 <Rubidium> then thing that goes *around* the hills instead of *over* the hills
19:13:35 <Eddi|zuHause> Terkhen: problem with (metro) trains is that you need to destroy half the city
19:14:02 <andythenorth> so limit of 2 roadtypes per tile
19:14:14 <Terkhen> you can do small metro stations around it and get the passengers with trams / distant stations
19:14:27 <andythenorth> but do they have to be orthogonal if it's 2 x tram / 2 x road?
19:14:30 <andythenorth> or can they be parallel
19:15:36 <andythenorth> e.g. can I have dirt road running NE-SW and road running NE-SW
19:15:44 <andythenorth> forget the graphics, I don't care about that right now
19:15:47 <Ammler> if you changed the release procedure from branch to tags, you could add the tags to the hg repos too
19:16:25 <andythenorth> why do we need 4 bits for roadtype at all?
19:16:46 * andythenorth forgot byte / bit
19:17:35 *** fjb is now known as Guest3402
19:24:18 <andythenorth> if trams didn't exist
19:24:24 <andythenorth> how many roadtypes per tile?
19:26:05 <peter1138> then you can save space
19:26:10 <peter1138> cos you only need to store the bits :p
19:26:29 <andythenorth> what - they match locations in the type table?
19:26:50 <andythenorth> and how do you draw them?
19:27:23 <andythenorth> what happens if I have type A on the tile, compatible with my donkey cart
19:27:39 <andythenorth> then player 2 builds type B on the tile, incompatible with my donkey cart
19:27:52 * andythenorth may have misunderstood compatibility so far
19:28:14 * andythenorth has misunderstood compatibility
19:28:30 <andythenorth> there's no 'incompatible' property?
19:28:37 <andythenorth> just an absence of compatibility?
19:29:49 <andythenorth> so no griefing opportunity / ability to fuck up routes by overbuilding some type
19:31:50 <ABCRic> wait, no ability to wreak havoc?
19:47:05 *** JVassie has joined #openttd
19:53:35 <DJNekkid> is it possible for a railtype newgrf to move the mono/maglev tracktypes to the bottom?
19:54:22 *** supermop has joined #openttd
19:56:47 <peter1138> DJNekkid, a facility to reorder the list could be added
19:57:33 <andythenorth> peter1138: hows about
19:57:44 <andythenorth> *one* road roadtype and *one* tram roadtype per tile
19:57:52 <DJNekkid> that would be awsome... as it "splits" up the different track-speeds
19:58:06 *** JVassie has joined #openttd
19:58:19 <andythenorth> if player has a routing problem at junctions, player needs to find a better newgrf
19:58:27 <Wolf01> mmmh I can't install the microsoft windows sdk
19:58:48 <peter1138> andythenorth, what's the advantage?
19:59:08 <andythenorth> conceptually simpler?
19:59:22 <andythenorth> knocks on the head debates like 'what about tram + trolley bus which implies road'
19:59:27 <peter1138> you still need to store the road types and the road bits
19:59:38 <andythenorth> so if you have two roadtypes on a tile
19:59:47 <andythenorth> can they go parallel, or do they have to be orthogonal?
20:00:11 <supermop> any progress on road/tram discussion?
20:00:22 <peter1138> each gets 4 road bits
20:00:23 <Wolf01> I get -> Error 1 error C2065: 'AI_ADDRCONFIG' : undeclared identifier d:\projects\openttd\trunk\src\network\core\address.cpp 105 which means I forgot to add a library or header, but which one?
20:00:32 <andythenorth> so they can go parallelt
20:00:52 *** fonsinchen has joined #openttd
20:01:10 <DJNekkid> peter1138: is this something in the pipeline? im about to update NuTracks, but if they cant be moved im tempted to let the mag/monotypes be normal rails, and make a new one for maglev (transrapid tracks or something like that)
20:01:28 <andythenorth> can't cross that road with a tram
20:01:32 <andythenorth> but bridges exist
20:02:16 <andythenorth> if you had e.g. two road roadtypes on a tile, trams can't be built there
20:02:22 <andythenorth> but player can use a bridge
20:02:28 <supermop> DJNekkid, do you need mon/mag graphics?
20:02:31 <andythenorth> so make them use a bridge, end of story?
20:02:47 <supermop> i am drawing some lately, you are welcome to them
20:02:48 <andythenorth> yeah works for me
20:02:56 <andythenorth> why is this so confusing? It seems easy
20:03:05 <andythenorth> two types allowed per tile, 4 road bits per type
20:03:11 <peter1138> andythenorth, it's not, you're just trying to complicate it
20:03:22 <andythenorth> I think I had some help there :)
20:03:26 <peter1138> andythenorth, your way forces you to only ever have 1 "road" road type on a tile
20:03:39 <andythenorth> if three types per tile is simply impossible, then that's the end of that debate
20:03:51 <peter1138> on the basis that you'll always want to be able to have 1 "tram" road type
20:04:05 <DJNekkid> supermop: not really, i can just reuse opengfx
20:04:10 <peter1138> correct, it's not better :)
20:04:19 <supermop> ok i am going to make everyone mad here;
20:04:23 <peter1138> my way you can have road & tram of, course, but also road & road
20:04:36 <peter1138> of course, i don't like to think of them as road & road, cos that's silly
20:04:50 <supermop> cannot 'highway' be an overlay for road, like caternary?
20:04:52 <andythenorth> and the issue with pavements on road type A blocking road type B? Is that a non-issue?
20:05:08 <andythenorth> it helps somewhat to read the code :)
20:05:12 <peter1138> andythenorth, just to confuse you, it'll be possible to have a road type that is compatible with both vehicles that travel on ROAD and TRAM
20:05:19 <andythenorth> that doesn't confuse me
20:05:23 <peter1138> same as you can make a rail type that lets everything run on it
20:06:13 <andythenorth> how is a road type determined to be road / tram / both?
20:06:20 <andythenorth> by compatibility via labels?
20:06:21 <peter1138> yeah, it's the "xx" properties of action 0 feature 11
20:06:42 <peter1138> there'll be no road/tram/both
20:06:55 <peter1138> there'll be vehicles capable of running on ROAD
20:06:59 <peter1138> and vehicles capable of running on TRAM
20:07:09 <peter1138> (by caps, i'm writing it as a road type label)
20:07:40 <peter1138> the road or tram *behaviour* of a road vehicle is another matter
20:07:55 <andythenorth> so that's a property for the vehicle action 0 as now?
20:08:37 <peter1138> it'll still be a property of the road type
20:08:46 <peter1138> but it'll apply to vehicles of that road type, rather than to the road itself
20:09:07 <andythenorth> so shall we code it? :P
20:09:31 <peter1138> like acceleration model setting for railtypes
20:09:38 <peter1138> clearly rails themselves don't accelerate :D
20:09:54 <andythenorth> they probably do a bit
20:10:08 *** KenjiE20 has joined #openttd
20:10:09 <andythenorth> my lego train tracks tend to move the opposite direction to the train
20:11:12 <Wolf01> thank you, solved, I forgot to add the SDK resources
20:11:40 <andythenorth> do you have code that builds?
20:15:43 <Wolf01> good, head revision built without problems
20:28:59 <fonsinchen> Rubidium: most of those trailing whitespaces are the ones patch generates on empty lines
20:29:11 <fonsinchen> They're not actually in the code
20:29:21 <fonsinchen> But there are some real ones, you're right
20:32:41 <Rubidium> fonsinchen: hmm, that's annoying when looking at the patches themselves :(
20:34:56 <fonsinchen> maybe you should fix your trailing-whitespace-detection to allow single whitespace on a line for that case
20:42:24 <andythenorth> I have built today's lego
20:42:46 <andythenorth> I'm bored of newgrfs
20:43:01 <andythenorth> my patch is done as much as can be done for now
20:46:37 <ABCRic> andythenorth: when all esle is done, play :D
20:52:00 <andythenorth> I've played openttd once or twice
20:53:36 <Terkhen> start your third game :)
20:53:46 <andythenorth> it's not that entertaining
20:53:56 * andythenorth ventures into multiplayer
20:55:08 <fonsinchen> I actually like using "else", even if there is a return in the "if" block if the code is structured around that alternative.
20:55:12 <fonsinchen> Makes it easier to read.
20:57:04 <Terkhen> andythenorth: what new properties and callbacks would that need?
20:57:22 <andythenorth> that is a good question
20:58:30 <Eddi|zuHause> [05.01.2011 20:59] <andythenorth> can they go parallel, or do they have to be orthogonal? <-- imho there needs to be a newgrf flag "incompatible with any other road type", so you can have e.g. low-speed tram rails that you can build on roads, and high-speed tram rails that you cannot put on roads
20:58:53 <andythenorth> Eddi|zuHause: I defer to peter1138 on this :P
20:59:13 <andythenorth> I worry about griefing
20:59:27 <andythenorth> I thought there'd be an 'incompatible' flag somewhere, but there isn't in the current spec
20:59:29 <fonsinchen> The sad thing about the "{" on new line is that I was using the other style when starting to write cargodist and later switched.
20:59:31 <andythenorth> maybe for a good reason
20:59:41 <andythenorth> Terkhen: I guess we look first at trains?
20:59:46 <fonsinchen> I've been looking for those for quite a while, but the code base is huge ...
20:59:59 <Terkhen> andythenorth: yes, it should mirror train behaviour as much as possible
21:00:00 <andythenorth> Terkhen there are probably some cbs like 'can wagon be attached'
21:00:28 <Eddi|zuHause> andythenorth: "dirt road" needs the same flag, like "road on dirt road" or "tram on dirt road" doesn't make any sense
21:00:58 <andythenorth> Eddi|zuHause: I can't see how you'd do that without either a cb for the newgrf author, passing the label
21:01:13 <andythenorth> or an equivalent of the vehicle cargo OR / XOR class madness
21:01:20 <Eddi|zuHause> andythenorth: i mean like "incompatible with any type ever invented"
21:01:37 <Eddi|zuHause> "incompatible" as in "may not be on the same road bit"
21:01:38 <Terkhen> andythenorth: IMO the only big difference should be "wagon can be attached" behaviour... I reckon that for train wagons the behaviour is "can be attached to any engine", whereas for rvs it should be "can only be attached to specified engines"
21:01:50 <andythenorth> Eddi|zuHause: cb on construction
21:02:01 <andythenorth> return 'can be overbuilt' or not
21:02:17 <andythenorth> Terkhen: train wagons already check that IIRC
21:02:23 <Eddi|zuHause> andythenorth: i don't see a need for a callback, but maybe...
21:03:47 <Terkhen> hmm... or we can just make it as similar to trains at possible and let the NewGRF authors take care of not allowing stupid combinations
21:04:07 <Terkhen> there is another issue... trains allow to put more than a single engine in the same consist
21:04:23 <Terkhen> that would look quite ridiculous with many road vehicles
21:05:32 <Rubidium> fonsinchen: "easier to read" is probably quite subjective; as in your current case you could easily mistake a piece of code for being executed for both branches of the if
21:05:40 <andythenorth> Terkhen again I think that can be handled with cb
21:05:47 <andythenorth> I haven't checked though
21:05:59 * andythenorth wonders about some kind of vehicle classes for RVs
21:06:00 <Terkhen> yes, but by default the train behaviour is "allow any combination"
21:06:13 <Terkhen> what do you mean with vehicle classes?
21:06:39 <fonsinchen> Yes, for that particular case I've found a better solution without else now, but in general I like using else for clarification.
21:06:43 <andythenorth> would be a way of allowing newgrfs to tell each other how vehicles could be combined
21:06:48 <andythenorth> probably a bad idea :P
21:08:34 <fonsinchen> What is the policy with '///<' documentation of class members? End with a period or not?
21:10:06 <Terkhen> currently trains with no power are wagons... that would be fun with eGRVTS horse carriages
21:10:21 <andythenorth> horses are a good test case
21:10:34 <andythenorth> do they get built as an articulated vehicle, or do you buy n horses?
21:10:41 <andythenorth> ach, I was about to paste that one :P
21:10:49 <Terkhen> I suspect that if no callback is provided, you can attach any wagon to any train engine
21:11:05 <andythenorth> it's up to the newgrf author to do the checks
21:11:32 <Terkhen> yes, but you can't use that as default behaviour for standard road vehicles
21:11:48 <Terkhen> nor for existing road vehicle sets, as you would break them all
21:12:05 <andythenorth> new property: can be attached to other vehicles
21:12:08 <Terkhen> therefore the default behaviour must be "I'm not a wagon and nothing can be attached to me"
21:12:37 <Terkhen> in trains that's done by setting power to zero, but IMO some kind of action 0 flag would be more correct for road vehicles
21:14:01 <Terkhen> there is a lot of space in Miscellaneous Flags for road vehicles
21:14:02 <Rubidium> fonsinchen: generally with period
21:14:23 <Terkhen> hmm... or maybe a callback flag would be more appropiate
21:14:46 <andythenorth> if the cb flag isn't set, never attach
21:14:55 <andythenorth> if the cb flag is set, use the cb to decide attaching?
21:16:45 <Terkhen> what to do about "multiple engines"? IMO that is a different feature
21:19:06 <andythenorth> sometimes it's nice to have multiple properties
21:19:16 <andythenorth> sometimes it's easier to just have a cb and lots of varaction 2
21:20:07 <andythenorth> rv acceleration is currently very tied to the lead vehicle?
21:20:14 <andythenorth> e.g. weight, power etc
21:20:23 <DJNekkid> peter1138: regarding my question earlier, could it be so easy that the list is sorted after the ID of the particular railset?
21:22:45 <Terkhen> only the lead vehicle is taken into account
21:23:00 <Terkhen> only the weight of the cargo is taken from the rest of the vehicle
21:23:56 <andythenorth> are there good enough reasons to have multiple rv-engines?
21:24:48 <andythenorth> there are a very few cases where it would be useful
21:24:51 <Terkhen> I can understand it for trains, which are very customizable, but rv-wagons should be more limited
21:26:00 <Terkhen> but my point is: it is a separate feature or should it be considered now?
21:31:55 <andythenorth> given the constraints on acceleration properties, I think RVs can have one engine, and it has to be the lead
21:32:43 <Terkhen> IIRC it was like that for trains in TTD
21:32:56 <Terkhen> but I'm not sure about that
21:33:53 <andythenorth> lets do it that way, and figure out all the wagon attachment stuff
21:33:59 <andythenorth> keep the scope limited
21:34:12 <andythenorth> unless it's more work to prevent attachment
21:35:01 <ABCRic> if we're using houses as cargo, we're gonna need more than one engine! :P
21:36:42 <andythenorth> prop 05 - needed?
21:36:57 <andythenorth> (for rv-wagons) - no
21:37:09 <ABCRic> hmm... houses as cargo would be interesting
21:37:14 <Terkhen> once we have a draft of NewGRF specs, we can start the code with "empty" properties and callbacks
21:37:47 <ABCRic> we'd transport them to cities and watch the cities grow fast...
21:37:54 <andythenorth> what does a draft look like to you? a list of props and cbs, or a description of what player should be able to do?
21:38:03 <Terkhen> ABCRic: it is called construction materials
21:38:21 <Terkhen> andythenorth: the former, but it should give you a good idea bout the latter
21:38:39 <andythenorth> good - we agree :)
21:39:03 <andythenorth> 1B looks...interesting
21:39:48 <Terkhen> IMO that is an additional feature
21:39:49 <andythenorth> we need to think about livery refits
21:39:56 <andythenorth> which I have never used nor understood
21:40:02 <Terkhen> but the road vehicle already has placeholder functions for that
21:40:10 <Terkhen> (see RoadVehicle::GetPoweredPartPower)
21:40:17 <Terkhen> so it should be easy to add after rv-wagons
21:40:29 <Terkhen> I have never understood livery refits either
21:40:54 <Terkhen> IIRC OpenGFX+ Trains has some already, I could use that as an example to try to understand them
21:41:02 <andythenorth> I think livery refit is something else - using the cargo subtype
21:41:25 <Terkhen> for me, anything more complicated than action 0 in nfo is still barely understandable
21:41:28 <andythenorth> livery over-ride would have applicability for RVs
21:41:50 <Terkhen> oh, I have seen this in the spain set
21:42:16 <andythenorth> there are much longer varaction 2 ways to do a similar thing I think. probably
21:42:36 <Terkhen> or maybe it was 2cc... I don't remember which one
21:42:56 <peter1138> hmm, i need a pathfinder
21:43:03 <peter1138> of a sort of 3d variety
21:43:11 <peter1138> although i should follow a surface
21:43:23 <Terkhen> I'm starting to realize that I'll need to understand all of this in NFO to be able to code rv-wagons :P
21:43:40 * Terkhen is suddenly uninterested
21:44:05 <Terkhen> I'll have to understand it sooner or later anyways
21:44:14 * andythenorth suspects peter1138 of either (a) rivers or (b) some kind of minecraft madness
21:44:27 <andythenorth> unless roadtypes needs a pathfinder? :o
21:45:17 <Terkhen> this livery refit stuff looks again like something that it is not part of the "core" feature
21:45:46 <andythenorth> fortunately for you, I understand most of the rv nfo code
21:45:58 <andythenorth> unfortunately for me, I'm starting to understand trunk :(
21:46:30 <Terkhen> I'm in the opposite situation :)
21:47:44 <fonsinchen> Initializers in constructors between function name and body: indent by one or two tabs?
21:49:35 <andythenorth> Terkhen: I think all of the other train action 0 props are non-relevant to rv-wagons
21:49:38 <andythenorth> I'll read cbs again
21:50:19 <andythenorth> dunno what train prop 25 does
21:51:21 <Terkhen> CB10 must be already present in some way for RVs, right? it is an extra anyways
21:52:07 <andythenorth> believe it's present (maybe since r21238)
21:52:50 <andythenorth> it exists for RVs
21:53:20 * Terkhen is just searching wagon
21:53:25 <andythenorth> not sure how current articulated vehicle handling might need to change
21:53:35 <andythenorth> where's frosch? :P
21:53:48 <SmatZ> I think he was going to cook some food
21:54:07 * andythenorth sees my old friends 28 and 2F
21:54:13 <andythenorth> I have used them *a lot*
21:54:48 <andythenorth> there might be some autoreplace issues
21:55:01 <andythenorth> depends how much train code works for rvs
21:55:14 <Terkhen> heh, I was not taking that into account at all :(
21:55:32 <peter1138> might just try the "point in direction and walk forward" method :s
21:55:37 <andythenorth> Terkhen: 1D is the only one that stands out as interesting
21:56:00 <Terkhen> indeed, I think that the initial feature should only take into account callback 1D
21:56:55 * andythenorth clones yet another openttd repo
22:12:00 <andythenorth> but they're already available for RVs
22:13:00 <andythenorth> DA I've never used
22:13:15 <andythenorth> there's no indication that it's train only
22:13:36 <Terkhen> it seems very wagon specific to me; in normal articulated vehicles the next vehicle is fixed
22:14:38 <andythenorth> I'd have to check the code I guess
22:14:48 <andythenorth> it might be one of those things that just works
22:16:49 <Terkhen> we are going to need a lot of testing cases :)
22:19:29 <andythenorth> it's a big project :)
22:20:41 <andythenorth> is 'articulated road vehicle' a special thing?
22:21:14 <andythenorth> are we going to be able to use current articulated vehicle consists for pathfinding etc, and just extend how they can be created?
22:24:28 <Terkhen> hmm... I'm not sure of what you mean, but for those things probably only the first vehicle is taken into account already
22:25:04 <andythenorth> I think I have the answer - rvs use articulated_vehicles.cpp
22:25:14 <andythenorth> they're not some special strange case
22:25:52 <Terkhen> yes, everything related to articulated vehicles should work already
22:25:55 <Terkhen> good night andythenorth
22:26:03 <SmatZ> good night andythenorth
22:26:18 *** andythenorth has left #openttd
22:37:08 *** ProfFrink has joined #openttd
22:43:31 *** Chillosophy has joined #openttd
22:43:34 *** ProfFrink is now known as Prof_Frink
22:52:13 <Zuu> planetmaker: Cleening up OpenTTD files sounds like a good idea ^^
continue to next day ⏵
