IRC logs for #openttd on OFTC at 2010-08-08
⏴ go to previous day
00:41:34 *** theholyduck has joined #openttd
00:44:26 *** DanMacK has joined #openttd
01:17:53 *** cow_png_wnt_nkl has quit IRC
01:53:46 *** cwo_ngajak_Nonton has quit IRC
04:46:08 *** devilsadvocate has quit IRC
05:00:45 <Dewin> Hmm. I have a (ridiculously) long route that's shared by both slow and fast trains... and I'm trying to find the best way to make a passing lane.
05:03:44 <Rubidium> depends on how much work you want to put it
05:03:59 <Dewin> I've tried a few things but the pathfinder ends up just making trains zigzag around and never get ahead at all
05:04:28 <Dewin> granted, I'm using PBS almost exclusively out of laziness.
05:05:06 <Rubidium> although the simple one is a normally signalled "main" rail and a piece with much less signals to pass the other train
05:05:47 <Rubidium> although you need a bit of testing how long the lane should be for the slower trains not to cause trouble in that situation
05:05:56 <Dewin> Yeah, if I do just one huge rail with nothing but a signal at the end of it that works.
05:06:07 <Dewin> But that only works if the faster train decides to use the passing lane.
05:06:47 <Rubidium> true, which could be accomplished with waypoints
05:07:10 <Dewin> I'd do that, except I read somewhere that waypoints breaks automatic timetable separation, so I'm avoiding them
05:07:36 <Rubidium> although *if* your network is completely timetabled you could make a piece of track where the slow train has to wait a while at a station
05:10:51 <Dewin> hmm, simplifying it made it start working much better than it was before. I think I'll just stick with this, which is still using nothing but PBS
05:14:56 *** junky[\[a] has joined #openttd
05:56:03 *** ^C0-KerjaJKT has joined #openttd
06:03:25 *** CO_CR_CWe has joined #openttd
06:37:32 *** ^Spike^ has joined #openttd
06:37:59 <andythenorth> Rubidium: how do I configure my build to use 8bpp instead of 32bpp?
06:43:08 * andythenorth stares at configure options
06:55:48 *** ChanServ sets mode: +v tokai
07:02:09 *** Alberth has joined #openttd
07:03:28 <Rubidium> andythenorth: select one of the 8bpp blitters (see openttd -h)
07:06:39 *** om_cr_ce_JKT has joined #openttd
07:08:01 *** Gamacca02 has joined #openttd
07:08:55 *** co_mau_tete_gd has joined #openttd
07:09:02 *** ce_tomboy_penempuh_rimba has joined #openttd
07:09:04 *** co_fs_fb_ym has joined #openttd
07:09:08 *** Co_Shot has joined #openttd
07:09:41 * andythenorth has an exciting looking blitter :P
07:10:34 <andythenorth> Rubidium: 8bpp blitters appear to fail for me
07:10:44 <andythenorth> do I need to change the video driver, or do I file a bug report?
07:12:34 <andythenorth> fail == colour shifts for everything except blue
07:23:50 *** Kurimus has joined #openttd
07:25:17 *** roboboy has joined #openttd
07:33:22 <andythenorth> so with 8bpp-simple or 8bpp-optiimized, OS X game starts with colours shifted
07:34:47 <andythenorth> I've found two ways to flip it to correct palette
07:34:55 <andythenorth> (i) load savegame
07:35:14 <andythenorth> (ii) start / end games (may be required several times)
07:35:54 <andythenorth> I assume it continues to use the 8bpp blitter and isn't simply switching blitter somehow
07:36:49 <andythenorth> OpenTTD CPU use is ~20% with 8bpp blitter.....normally it's ~45% with 32bpp
07:37:37 * andythenorth plays game a bit to look for bugs
07:41:14 <Rubidium> andythenorth: that's a known feature of the operating sysem you're using
07:41:42 <andythenorth> it's not a documented FS bug though....or have I missed it?
07:42:17 <Rubidium> the closed bug, but you may reopen it if that pleases you
07:45:55 <andythenorth> I can't find a closed bug matching these issues?
07:46:09 <DorpsGek> Rubidium: Commit by bjarni :: r13584 trunk/src/blitter/factory.hpp (2008-06-19 17:54:23 UTC)
07:46:10 <DorpsGek> Rubidium: -Fix: [OSX] Fixed issue where 10.5 failed to switch to fullscreen
07:46:11 <DorpsGek> Rubidium: This is done by selecting the 32bpp-anim blitter by default as it seems Apple removed some 8bpp support
07:46:12 <DorpsGek> Rubidium: Since this is done at runtime the same binary will still select 8bpp on 10.3 and 10.4
07:46:25 <DorpsGek> Rubidium: Commit by rubidium :: r19003 trunk/src/video/cocoa/fullscreen.mm (2010-02-04 14:32:12 UTC)
07:46:26 <DorpsGek> Rubidium: -Fix [FS#3194]: [OSX] OS X 10.5+ does not (always?) handle 8bpp graphics in a suitable manner. This is actually not a fix but a nasty work around; you can still easily trigger the bug/issue by overriding the 'default' blitter choice (Brad Oliver). I can/have not test(ed) (including compiling) this fix.
07:46:27 <DorpsGek> Rubidium: Bjarni once suggested that 8bpp works for him on 10.5, so apparantly not all 10.5+ does not handle 8bpp graphics. Nevertheless, it seemed that for some systems the already existing 'does this support 8bpp' did not work, i.e. the OS API seemed to suggest that 8bpp worked when it actually did not. So, I don't know what is going on precisely here but it's definitely not nice to suggest that it supports 8bpp when (1 more message)
07:46:35 <DorpsGek> Rubidium: it doesn't. So just ditch 8bpp support for anything that we suspect might not support 8bpp...
07:48:23 <Rubidium> can't find the bug report, but... I definitely can find lots of references saying it's known to not work
07:49:11 <Rubidium> in any case... as you can see above, we can't reliably detect whether OSX supports 8bpp or not. It will always say it does, even when it doesn't
07:49:30 <andythenorth> I'll post this issue as a new bug. it's different to the ones I can find. If anyone finds a duplicate they can close it...
07:49:47 <Rubidium> andythenorth: it can't be fixed in any case
07:50:24 <peter1138> ffs, recv has blocked for 2 hours now :(
07:51:30 <Rubidium> andythenorth: the only thing we can do for you is totally disable the 8bpp blitter for 10.5 and higher, but... that breaks people where 8bpp is (for some magic reason) still supported
07:51:33 *** lasershock has joined #openttd
07:51:59 <Rubidium> andythenorth: in any case you won't gain a thing with it... well unless you switch OS!
07:52:06 <andythenorth> Rubidium: I'm fine with it. I'm only looking because you mentioned it in the OS X thread
07:52:09 <Rubidium> but then you don't need to file the Mac OS X bug
07:52:37 <Rubidium> andythenorth: then the "quoted" commits above should be more than enough "reason"
07:53:23 <andythenorth> So the case is that 8bpp is unusable, but 32bpp will always be considered a bug for some users. Therefore even with a maintainer, OS X will not be supported?
07:53:44 <andythenorth> Time to remove OS X from flyspray?
07:54:03 <Rubidium> is it an open bug report?
07:55:21 <Rubidium> no? Then I don't care about it; it works out-of-the-box for everyone, it just might be some 200-250% slower (I seem to remember someone saying that)
07:58:34 <Rubidium> because users will report them again
07:59:08 <Rubidium> the "slowness" isn't something that Mac users will really notice as it's been that way for very long already
07:59:20 <Rubidium> and not using 8bpp is something they really don't notice
07:59:23 <andythenorth> I hadn't noticed it...
08:00:14 <Rubidium> and the former I can just close as being a duplicate
08:02:20 *** Hot_Date has joined #openttd
08:02:29 <peter1138> apparently everything should be using opengl these days
08:03:03 <peter1138> in which case, SDL should be handling it
08:04:12 <andythenorth> looks like SDL is a cluster fuck on OS X though?
08:04:35 <Rubidium> yep... they seem to have the same issues we're having
08:04:50 <Rubidium> i.e. noone really cares about it
08:08:41 <peter1138> is 32bpp sdl fine on os x?
08:09:37 *** frosch123 has joined #openttd
08:10:32 <peter1138> there must be some sdl-using games that work fine on os-x...
08:10:34 <Rubidium> peter1138: yes... until we start to actually draw stuff on it. Then it might actually push zillions of warnings onto the console and crash
08:12:06 *** aWan9_2 has joined #openttd
08:17:46 * peter1138 wonders how long this recv() is going to block :s
08:20:20 *** Progman has joined #openttd
08:24:58 <peter1138> 2 hours 3 minutes now
08:25:04 <peter1138> isn't that longer than the TCP timeout?
08:26:31 <andythenorth> Sawmills on slopes?
08:28:21 <frosch123> andythenorth: if you add custom foundation graphics with stairs between the levels, and limit the number of levelchanges you can allow every processing industry one slopes
08:28:52 <andythenorth> frosch123: I'd have to redraw a lot of sprites
08:29:04 <andythenorth> or use a lot more tiles
08:29:17 <andythenorth> or write some really horrible nfo :P
08:29:24 <frosch123> my bet would be that coding takes longer than drawing :p
08:29:58 <frosch123> but the default foundation walls inside industries look ugly
08:29:59 <Wolf01> hey, already awake and coding at this hour of sunday?
08:30:12 <frosch123> they already look ugly even if they are only at the border of the industry
08:30:24 <andythenorth> frosch123: replacing the foundations is plausible
08:30:43 <andythenorth> but for some industries, not using foundations would be better (make graphics follow slope, like fields)
08:30:52 <andythenorth> did I mention fields :P
08:31:21 <andythenorth> frosch123: I'm prepared to spend today making industries look better on slopes :)
08:31:30 <andythenorth> but I'll need repeated help with var 60
08:31:39 <andythenorth> and I may swear a little
08:31:59 <Wolf01> imho industry foundations look well using the brick foundations, current foundations look well for farms as they look rocky
08:32:19 <frosch123> that does not work :(
08:33:37 *** TomyLobo has joined #openttd
08:34:39 <andythenorth> sawmills look ok on slopes
08:34:42 <frosch123> though of course one could also link to the last thread about that :p
08:37:06 <andythenorth> default steelmill has 1 sprite covering 2 tiles
08:37:12 <andythenorth> so no steel mills on slopes :(
08:37:31 <andythenorth> junkyard on slopes could be good...
08:38:45 <TomyLobo> frosch123 someone was developing a patch for that i think
08:39:04 <TomyLobo> he came here a few weeks ago. dont know where he posted it though
08:39:49 <frosch123> TomyLobo: many tried, usually they abondon it when they understand how it really works
08:39:57 * andythenorth can't decide if junkyard looks good on slopes
08:40:05 <TomyLobo> well it's just a rectangular area
08:40:10 <TomyLobo> one could just draw a box
08:40:23 <frosch123> TomyLobo: and that is wrong for supply :)
08:40:49 <TomyLobo> btw, the city could build roads across those rails, which means you get penalty for tearing them down
08:41:28 <TomyLobo> frosch123 yeah, it's a bit harder there. would be a polygon
08:41:55 <frosch123> even that is not enough
08:42:52 <TomyLobo> it looks for a station around the industries
08:43:08 <TomyLobo> in the end it'd be as simple as checking every single square :)
08:43:41 <frosch123> no, because there are tiles which add "supply" to a station, while there is no industry at all on the tile
08:43:56 <andythenorth> any acceptance supply GUI is just going to reveal the conceptual weirdness of how it actually works
08:44:08 <andythenorth> players will just be confused
08:44:44 <frosch123> the only reasn why there is no such thing is that it is so wrong and inconsistent that everyone would notice
08:45:22 <TomyLobo> i.e. hide the obvious? :)
08:45:28 <andythenorth> we should just implement supply and demand for every cargo on every tile like RT3
08:45:36 <andythenorth> then the catchment area thing changes radically :P
08:45:49 <andythenorth> meanwhile, opinions on junk yards? ^^
08:46:07 <frosch123> industries with more than 2 foundations are ugly :)
08:46:08 <TomyLobo> but really, there should be a registering mechanism for that
08:46:29 <TomyLobo> i'd like to have more than 1 found ation for a start :)
08:47:08 *** DarkNemesis has joined #openttd
08:47:25 <TomyLobo> i like my tracks flat and sometimes industry gets in the way
08:47:57 <TomyLobo> i'd like to tower them up on a large pile of foundations :)
08:48:56 <frosch123> the industries or the track? :p
08:49:46 <TomyLobo> it'd probably mean putting foundations under mountains :D
08:50:21 * andythenorth enables steep slopes for junkyards
08:51:26 <andythenorth> frosch123: the varact 2 chains I showed yesterday with invalid termination.....I need to fix those
08:51:30 <andythenorth> I'm not sure of best way
08:51:55 <TomyLobo> what i'd love to see is ISR maintenance yards with real switches
08:52:10 <TomyLobo> i.e. plain track, not station tiles
08:52:41 <TomyLobo> stylable plain track
08:53:11 <CIA-2> OpenTTD: frosch * r20408 /trunk/src/rail_cmd.cpp: -Fix [FS#4013]: PBS reservations were always displayed on halftile foundations if the railtype uses overlays.
08:55:07 <andythenorth> frosch123: I found some legacy code from last time I faced similar with adding cb to default tiles....it uses action 2 ID FF FF....is that a 'magic' value?
08:55:08 <frosch123> andythenorth: i cannot think of any way, which keeps drawing default graphics
08:55:22 <andythenorth> I could just suppress the renum errors locally :P
08:55:39 <frosch123> FFFF means callback result FF
08:55:55 <frosch123> which is wrong, as it returns FF for all callbacks unknown to the grf
08:56:04 <frosch123> so, that would be a real bug :)
08:56:19 * andythenorth favours suppressing renum errors
08:56:51 <frosch123> anyway you have to make sure that you do not define the action2 id somewhere else :)
08:57:15 <andythenorth> that is also a bit tricky
08:57:36 <frosch123> you could also try to add a vehicle-like action2 at the end
08:57:43 <andythenorth> I don't want to have to reimplement all layouts and tiles for default industries :o
08:58:01 <andythenorth> how would the vehicle-like thing work?
08:59:18 <frosch123> hmm, no, that does not work
09:00:00 * andythenorth can see a future that holds reimplementing default industry tiles/layouts
09:01:18 <frosch123> maybe you can steal from other grfs :)
09:01:54 <frosch123> maybe pbi uses default graphics for powerplant while starting/stopping the smoke only when there is production
09:02:02 <andythenorth> think George has code for this
09:02:24 <frosch123> but i am not sure whether it was pbi, and whether it were default graphics :)
09:02:49 <andythenorth> I might have to face up to it sometime
09:03:03 <andythenorth> current 'broken' implementation doesn't seem to blow anything up
09:03:23 <frosch123> it might crash ttdp :)
09:03:32 <andythenorth> I'll take those odds
09:04:53 *** om_tajir_cari_simpanan has joined #openttd
09:06:34 <TomyLobo> frosch123 supply area is simply each individual station part's radius as shown in the preview, right?
09:07:42 <frosch123> yes, but you need to intersect that area with the rectangle around industires. so for non-rectangular industries you can get supply without having an industrytile in your area
09:07:53 <CIA-2> OpenTTD: rubidium * r20409 /trunk/src/ (newgrf.h newgrf_debug.h town_cmd.cpp): -Codechange: reduce the number of includes needed by newgrf.h
09:08:25 <TomyLobo> frosch123 you mean you can get supply from that missing corner in an oil ref, for instance?
09:08:45 <andythenorth> TomyLobo: try it....forest with missing corner for example
09:08:48 <TomyLobo> in the more square one, yes
09:08:52 <frosch123> yes, even more noticeable with those very non-rectangular industires in firs
09:09:23 <TomyLobo> hmm well you'd have to tell the people that :)
09:09:51 <TomyLobo> or, since you know the industries are there, just mark them as supplied
09:10:13 <TomyLobo> extend the box around them
09:10:56 *** fonsinchen has joined #openttd
09:11:46 <frosch123> TomyLobo: still, even having two areas to display is just ugly
09:12:10 <andythenorth> two areas displayed is unacceptable and confusing :)
09:12:24 <TomyLobo> you mean supply+accept?
09:12:32 <TomyLobo> you could switch between them
09:12:42 <frosch123> no, someone should change how supply and acceptance works, while keeping performance :)
09:12:51 <andythenorth> there would be a zillion bug reports if there were two overlays
09:12:54 <TomyLobo> frosch123 registering!
09:12:55 <andythenorth> or questions at least
09:13:10 <TomyLobo> andythenorth big red hint box
09:13:21 <andythenorth> plus two overlays is work to support something that's known broken
09:13:33 <TomyLobo> "this is NOT the accept/supply coverage" in supply/accept coverage display
09:14:09 <TomyLobo> is supply broken or is accept?
09:14:33 <andythenorth> depends on what spec is supposed to be?
09:15:01 <TomyLobo> i'd say 2 corner stations shouldnt make it accept anything in the middle :)
09:15:08 <TomyLobo> so supply is the one less broken
09:15:30 <TomyLobo> the industry corner thing is odd though
09:15:58 <TomyLobo> could be fixed though, by simply checking back after finding a station
09:16:26 <TomyLobo> i.e. if the station is in range of any actual industry tile
09:16:46 <TomyLobo> O(industries*stations) extra effort
09:17:08 <frosch123> andythenorth: fine :)
09:18:25 <TomyLobo> O(industries*stations*radius²) actually, but some creative coding could get that down to O(industries*stations)
09:19:27 <frosch123> iirc smatz already added some caching around acceptance
09:19:49 <frosch123> IndustryVector industries_near; ///< Cached list of industries near the station that can accept cargo, @see DeliverGoodsToIndustry()
09:20:09 <TomyLobo> so, why is performance an issue then?
09:20:15 <TomyLobo> if it's cached anyway
09:20:37 <frosch123> now do the same for acceptance :)
09:20:53 <frosch123> well, even supply from houses
09:21:44 <TomyLobo> do all houses supply at the same time?
09:22:05 <frosch123> i guess they supply during the tileloop
09:22:05 <andythenorth> houses can turn acceptance on/off
09:22:15 <TomyLobo> then make them register with all surrounding stations when they are built and have the stations trigger the supply check, not the houses
09:22:32 <TomyLobo> that would even SAVE cpu time
09:22:47 * andythenorth doesn't know what registers are
09:22:58 * andythenorth wonders if they're a bit like ZCatalog
09:23:11 * TomyLobo wonders what ZCatalog is
09:23:38 <andythenorth> TomyLobo: basically, don't get waking up n objects to look if they have a value
09:24:15 <andythenorth> instead, when the object saves the value, have it update an index that can be scanned quickly
09:24:15 <TomyLobo> that didnt parse, sorry
09:24:24 <andythenorth> it's a python thing :P
09:25:13 <TomyLobo> is the passenger amount related to city rating?
09:26:42 <andythenorth> TomyLobo: so this way, when a house turns on/off acceptance, it has to search for all neighbouring stations, then check all their catchments, then push onto the station's index / register / cache (whatever)
09:27:00 * andythenorth is not a very good coder so could be wrong
09:27:17 <TomyLobo> what do you mean turns on/off?
09:27:35 <TomyLobo> doesn't that only ever happen when it's built/destroyed?
09:27:40 <andythenorth> IIRC, house cargos can be dynamic, same as industries
09:27:52 <TomyLobo> but not in acceptance
09:28:14 <TomyLobo> they always accept all the stuff you give them :)
09:30:26 <andythenorth> frosch123: could I have a var 60 cookie please? :P
09:30:45 <TomyLobo> what i always wanted to know: newgrfs contain some kind of code, right?
09:30:54 <TomyLobo> is it sandboxed or something or can it be dangerous?
09:31:33 <Alberth> at least as dangerous as crashing OpenTTD
09:32:34 <frosch123> TomyLobo: newgrfs provide decision trees, no machine code
09:33:04 <frosch123> andythenorth: what kind of cookie?
09:33:41 <TomyLobo> Alberth that is fine :) at least it's not something silly like machine code :D
09:34:26 <frosch123> so, not turing complete :)
09:35:27 <andythenorth> frosch123: the shift / mask to get bit 4 from ss?
09:35:44 <TomyLobo> it's only turing complete if you can freeze your machine with it :)
09:35:55 *** |Jeroen| has joined #openttd
09:36:08 <Alberth> andythenorth: >> 4, & 1 ?
09:36:24 <frosch123> 60 <parameter> (maybe 20)+04 (\b or \w or \d)1
09:36:48 <Alberth> TomyLobo: worse, it can make the OpenTTD task disappear
09:36:51 <frosch123> i.e. in the varadjust: shift = 4, andmask = 1
09:37:11 <TomyLobo> Alberth sure, but that'd just mean it returned a wrong value which openttd didnt like
09:37:38 <andythenorth> frosch123: value of bit 4 will be 0 or 1?
09:37:46 <andythenorth> (just checking the obvious)
09:38:00 * andythenorth is out of practice with nfo
09:38:13 * andythenorth is now pretty good at changing nappies though
09:39:04 <frosch123> someone likely appreciates that :)
09:47:09 <TomyLobo> btw, talking about non-turing-complete: those images i post are made with excel
09:47:23 <TomyLobo> it's just a simple conditional format, not turing complete either
09:57:20 *** Brianetta has joined #openttd
09:59:22 *** NukeBuster has joined #openttd
10:02:03 <frosch123> you are missing <parameter>
10:03:10 <andythenorth> that takes care of the linter failures :)
10:05:09 *** cow_suka_cow has joined #openttd
10:05:10 *** co_cari_ce_BISPAK_jakarta has joined #openttd
10:16:31 *** JVassie has joined #openttd
10:30:42 <andythenorth> frosch123: so how should industry foundations appear?
10:32:03 <frosch123> with a fitting texture and stairs?
10:33:06 <andythenorth> so lets discuss two types: one for forests / farms / plantation
10:33:17 <andythenorth> and one for more 'built' industries
10:33:33 <frosch123> forests should not have any foundations :)
10:37:17 <andythenorth> frosch123: farm buildings should have foundations :P
10:37:25 <andythenorth> farm fields should be handled differently anyway
10:37:44 <frosch123> small building should not have foundations, they should build into the hilll
10:40:51 <andythenorth> offset down and draw the foundation at the back?
10:41:19 <frosch123> no foundation, just offset down
10:41:28 <frosch123> sloped hedges and so
10:41:35 <andythenorth> there'll be a sprite gap at the rear?
10:42:01 <frosch123> no, i mean use the normal sloped ground tiles
10:43:23 <andythenorth> so draw variations of small building cut to match hill?
10:43:48 <frosch123> maybe if they are small enough they do not need cutting
10:44:08 <andythenorth> I think they will, or they'll appear to float
10:45:43 <frosch123> foundations at the border or generally more acceptable :)
10:47:23 <CIA-2> OpenTTD: alberth * r20410 /trunk/src/smallmap_gui.cpp: -Codechange: Move smallmap map-type switching to a function.
10:47:24 <andythenorth> I am just wondering whether to prevent e.g. farms from building on coast tiles
10:47:35 <andythenorth> interestingly, player can lower land to get same effect anyway
10:47:58 <frosch123> farm at coast is fine
10:48:57 <andythenorth> so for forest, fruit plantation, I need to....
10:49:14 <andythenorth> - detect slope, then use climate-dependent ground tiles from base set to draw ground
10:49:22 <andythenorth> - then draw trees on top
10:54:01 <frosch123> though the plantation would likely not look so nice, if the hill would be in the other direction
10:54:34 <frosch123> i.e. the dark paths between the plants look like foujndations somehow
10:56:29 <andythenorth> going to redraw plantations some time anyway
10:57:11 <andythenorth> I thought of maybe drawing earth / grass banks to use as custom foundations for forest / plantation
10:57:18 <andythenorth> I'd have to do them for every terrain type though
10:58:19 <frosch123> not really, you do not need for the sandpit either, do you?
10:58:24 <Ammler> foundations on those industries are ugly
10:58:31 <frosch123> only snow/desert vs. normal
10:58:53 <andythenorth> frosch123: if I matched the grass colour, I'd need 3x terrain
10:59:02 <andythenorth> I could ignore that though
10:59:10 <frosch123> but you centainly need some templating there :)
10:59:24 <andythenorth> Ammler: unfortunately this is a case where opengfx is uglier than original
10:59:28 <frosch123> andythenorth: if you use the defaultgroundtiles, you do not need to match, as they are in the same position
10:59:41 <frosch123> and if you do not use the defaultgrass, it does not fit with other groundtiles anyway
10:59:46 <CIA-2> OpenTTD: rubidium * r20411 /trunk/ (105 files in 9 dirs): -Codechange: rename unmovables as quite a lot of them are actually movable; e.g. HQ and owned land are pretty movable.
10:59:50 <andythenorth> original foundations look ok - for temperate. Not so good for tropic :P
11:01:11 <andythenorth> I think it looks....ok, ish
11:03:12 <CIA-2> OpenTTD: alberth * r20412 /trunk/src/industry_gui.cpp: -Codechange: Replace an if by a switch in IndustryCargoesWindow::OnClick.
11:03:37 <Ammler> building on slopes should be without slopes
11:03:55 *** KenjiE20 has joined #openttd
11:04:43 <andythenorth> Ammler: that's nice to say, harder to implement :P
11:05:06 <Ammler> for you or frosch? :-)
11:05:33 <andythenorth> well unless frosch123 has started drawing pixels....me
11:05:58 <Ammler> so openttd would support it without foundations?
11:06:08 <frosch123> i can draw pixels, just tell be which colour at which positions :p
11:07:06 <andythenorth> Ammler: the nfo is also long (although it is trivial...just a lot of work + testing) :P
11:07:35 <andythenorth> and not every tile even supports slopes
11:10:23 <andythenorth> I count 19 possible slope variations in tileh.png
11:12:47 <CIA-2> OpenTTD: rubidium * r20413 /trunk/src/object_type.h: -Fix (r20326): some comments got a bit outdated
11:13:06 <Ammler> andythenorth: you like industries with foundations more than terraforming before building the industry?
11:17:27 <CIA-2> OpenTTD: alberth * r20414 /trunk/src/ (industry_gui.cpp lang/english.txt smallmap_gui.cpp): -Feature: Enable industries in the smallmap displayed in the industry chain window.
11:18:08 <andythenorth> Ammler: industries with foundations are fine in certain cases
11:18:38 <Ammler> yes, if the industry suppots it :-)
11:21:36 <CIA-2> OpenTTD: alberth * r20415 /trunk/src/ (industry_gui.cpp smallmap_gui.cpp): -Add: Clicking at the smallmap disables updates from the industry chain window.
11:21:42 <andythenorth> frosch123: fields will be fully slope aware?
11:22:36 <frosch123> just the same as industrytiles
11:23:40 <andythenorth> just checking before I do work that will be thrown away later :)
11:24:03 <frosch123> well, the slopechecking is still undecided though
11:25:15 <andythenorth> next problem. I need some tree sprites :P
11:26:02 <TomyLobo> frosch123 do you just turn slopes into terraces?
11:26:24 <TomyLobo> i.e. green foundations?
11:26:42 <frosch123> i do not draw pixels :)
11:26:46 *** Adambean has joined #openttd
11:27:08 <Rubidium> frosch123: but drawing pixels is easy!
11:27:33 <andythenorth> fill 1,0, 255,255,255
11:27:35 <Rubidium> making a set of drawn pixels look good... that's something you need some skill for, but just colouring the pixels.. .nah :)
11:28:11 <TomyLobo> just remove all red and blue parts of the foundation sprites :D
11:28:16 * andythenorth thinks opengfx trees will suit FIRS forests
11:28:52 <frosch123> andythenorth: then you could also use the default trees, so they adapt to stolentrees or whatever
11:29:17 <andythenorth> I can use extend tile action 2 to render a lot of layered sprites?
11:29:22 <andythenorth> I didn't think of that
11:29:26 <frosch123> hmm, though you cannot access the snowy action5 trees, which are irrc not supported by ottd anyway
11:29:43 <andythenorth> if it's a sprite in the base set, I can usually get to it
11:29:58 <andythenorth> or are they switched in/out by the action 5?
11:30:19 <frosch123> the default trees you can get
11:30:54 <frosch123> but not the additional snowy temperate trees (not supported in ottd)
11:31:47 <Ammler> well, if you make them, we could include it...
11:32:18 <frosch123> Ammler: we have no snow in temperate :)
11:32:52 <Ammler> maybe that feature will ever revive :-)
11:33:18 <frosch123> well, if it would be done, then likely not as in ttdp
11:33:20 <Ammler> at least the missing sprites wouldn't be a excuse :-P
11:34:21 <Rubidium> can NewGRFs read the disaster setting? If so, a forest fire would be fun :)
11:34:26 <frosch123> btw. there are still no good sprites for vehicle profit
11:34:38 <TomyLobo> uh is there a delivery graph for FIRS somewhere? :D
11:34:39 <andythenorth> I gave up on those
11:34:52 <andythenorth> I thought vehicle profit was a bad brief :P
11:35:02 <andythenorth> almost impossible to solve
11:35:31 <andythenorth> TomyLobo: various graphs were made
11:35:42 <andythenorth> the best one is by Alberth :D
11:36:32 <TomyLobo> i also wonder how machine shop works. how does it determine what to produce?
11:36:33 <Alberth> and I didn't even draw a single pixel :)
11:36:41 <andythenorth> no way to create a custom disaster
11:36:56 <andythenorth> TomyLobo: you put in what it needs, it puts stuff out :P
11:37:10 <TomyLobo> yeah but it produces several stuffs
11:37:16 <andythenorth> equal amounts of both
11:37:29 <Alberth> TomyLobo: just try it
11:37:38 *** Eddi|zuHause has joined #openttd
11:37:41 <frosch123> andythenorth: you can close industries with the message "burned down"
11:37:47 <andythenorth> where FIRS produces two cargos, they're always balanced
11:37:56 <andythenorth> frosch123: probably
11:38:21 <andythenorth> use production change cb to burn the industry in one month, close it the next month...
11:38:46 <Alberth> fire trucks around it, people with hoses :)
11:40:08 <andythenorth> hi Eddi|zuHause :)
11:40:16 <Rubidium> and if you don't deliver 100.000l of water that month, the fire won't be put out! :)
11:40:25 <andythenorth> micro-management :)
11:40:57 <andythenorth> would provide a use for planes
11:41:17 <__ln__> that reminds me, is the capacity of water wagons still only 2500 litres?
11:41:27 <Rubidium> hahah... helicopters ofcourse! :)
11:41:31 <andythenorth> we'd need a new airport on water, with a state machine to allow loading while flying
11:42:34 <Alberth> unloading is more difficult
11:43:13 <Alberth> hmm, an 'airport' in the sky?
11:43:38 <Rubidium> hmm, would be fun that when a forest is placed on a sleep-ish slope near the water that there's a helicopter (or multiple) flying around picking up trees and dropping them in the water after which they flow to the place where the wood can be picket up. Either by truck/train or by log raft :)
11:44:04 <Rubidium> (those helicopters aren't real player controlled helicopters ofcourse)
11:44:35 <Alberth> bummer, no mini-game :(
11:47:22 <andythenorth> Rubidium: I'm planning to just implement helicopter logging as vehicles :)
11:47:34 <Eddi|zuHause> hm... apparently i joined at 13:37
11:47:35 <andythenorth> although you're suggestion is good
11:47:53 <TomyLobo> just add freight helicopters and make it an "industry station
11:48:22 <andythenorth> I imagine that having a helicopter animated might cause some horrible offset / bounding box headaches
11:49:10 <andythenorth> should FIRS forests be plantation (fir trees), or 'natural' ?
11:49:45 <Eddi|zuHause> what's the difference?
11:50:15 <andythenorth> one uses the pine tree sprites, the other deciduous tree sprites
11:50:23 <andythenorth> needles vs. leaves basically :P
11:58:54 *** cwoq_cri has joined #openttd
12:00:17 <Rubidium> Eddi|zuHause: yes, you're so 1337 that you don't need to register your nick and identify yourself :)
12:00:42 <Eddi|zuHause> Rubidium: exactly :)
12:22:07 *** ajmiles has joined #openttd
12:36:25 *** Wolf01 is now known as Guest1257
12:36:26 *** Wolf02 is now known as Wolf01
12:38:02 <Wolf01> I succeeded to crash my pc compiling ottd
12:48:20 <Wolf01> gah... I'm trying to rewrite my roadstops on slopes patch... it's changed too much :P
12:57:37 *** impalass has joined #openttd
12:59:01 *** mathieu24 has joined #openttd
13:02:56 *** CUTEESGIRL has joined #openttd
13:05:49 *** adItyA_mO_ce_sMa_bAyRn has joined #openttd
13:17:59 <Eddi|zuHause> hm... i got a spam...
13:32:26 *** Wolf01 is now known as Guest1260
13:32:26 *** Wolf02 is now known as Wolf01
13:36:51 *** Wolf01 is now known as Guest1261
13:36:51 *** Wolf02 is now known as Wolf01
13:45:15 <Aali> I just crashed r20279 :/
14:09:36 <andythenorth> is there a fast way to see all the default tile sprites?
14:09:39 <andythenorth> (other than in game)
14:12:44 <frosch123> take a look at ogfx source?
14:28:23 *** Eddi|zuHause2 has joined #openttd
14:34:31 <andythenorth> frosch123: I'll just use the sprite picker ;)
14:35:19 *** devilsadvocate has joined #openttd
14:48:32 *** HerzogDeXtEr has joined #openttd
14:51:22 <andythenorth> if these don't look good as forest ground tiles, I shall be sad :o
14:51:34 *** welterde has joined #openttd
14:52:27 <frosch123> looks nice, indeed :)
14:54:38 <andythenorth> Ammler: how? It's a composite of two screenshots...is that the reason?
14:55:43 <Ammler> don't think so, it is like the tile 2972 just other direction
15:14:26 * andythenorth needs a volunteer :P
15:15:21 *** welterde has joined #openttd
15:22:17 <andythenorth> with slope aware forest tiles, terraforming will move the trees up and down :o
15:26:26 <frosch123> maybe you cannot even disallow terraforming, maybe you can reset some animationstage and replace the trees with small ones
15:31:01 <frosch123> hmm, no you can only change persistent storage, not suitable for tiles
15:36:03 <andythenorth> tiles can access industry persistent storage though - related object...?
15:36:40 <frosch123> [17:36] <andythenorth> tiles can access industry persistent storage though - related object...? <- yes
15:36:56 <andythenorth> the coast is a bigger issue
15:37:20 <frosch123> check landscape class of nearby tiles
15:37:47 <andythenorth> this could happen to any forest at height level 0
15:37:58 <andythenorth> disallowing height level 0 is a solution, but a bit drastic
15:39:16 <frosch123> one that tile you likely have to forbid planting :)
15:41:51 <andythenorth> what does this cb actually do?
15:42:36 <frosch123> it is called for every tile affected by terraforming
15:43:06 <frosch123> you can then forbid terraforming, but you cannot check what is actually about to be terraformed (i.e. resulting slope)
15:45:03 <andythenorth> so I could solve the forest coast problem by preventing terraforming on these tiles?
15:47:02 *** JVassie has joined #openttd
15:47:33 <frosch123> you can use cb 3c to disallow terraforming of forrest tiles, so the trees do not fall down. you can use cb 2f to disallow planting of forrests on "half-water"-coast tiles (forest_coast2.png), and you can use var60 to detect water on neighboured tiles to draw coast groundtiles
15:47:46 <frosch123> alternatively you can just forbit forests at sea level :)
15:47:57 <andythenorth> the problem with using 2f is that players can 'walk' the sea in
15:48:03 <andythenorth> and forbidding is confusing
15:48:16 <andythenorth> var 60 is possible, but just....more work :P
15:48:39 <frosch123> not more work than snow :p
15:49:30 <andythenorth> I need to do a 2f check for coast as well
15:49:56 <andythenorth> 3C is a bit annoying to players, but better than the alternative
15:51:55 <andythenorth> frosch123: I need to check bit 1 of bb for var 60
15:52:04 <andythenorth> how many to shift?
15:52:40 * andythenorth may be confusing shift and mask
15:53:05 <frosch123> why do you need that bit?
15:53:38 <andythenorth> prevent forest being constructed on coast
15:53:52 <frosch123> but players can still flood to that position
15:54:17 <andythenorth> they won't be able to terraform sufficiently around the forest
15:54:20 <frosch123> hmm, ok, but might work in 99% of cases :)
15:54:45 <andythenorth> I can't terraform that far anyway
15:54:58 <andythenorth> in a scenario it might fail, but in default game should be fine
15:55:04 <frosch123> so 8 bits for bb, 1 for ss -> shift 9
15:55:10 <frosch123> one bit to test -> and 1
15:59:09 <andythenorth> frosch123: thanks
16:03:04 *** fonsinchen has joined #openttd
16:03:37 *** JVassie has joined #openttd
16:12:17 <andythenorth> my new forest introduces a gazillion renum errors :P
16:12:54 <andythenorth> /!!Warning (80): Offset 43: Value of <yoff+yextent> must not exceed 0Fh.
16:13:05 <andythenorth> extended tile action 2 has some pitfalls
16:13:44 <frosch123> hmm, that warning is wrong :) it must not exceed 10h
16:14:20 <frosch123> well, 0 <= yoff <= 0fh, yoff + yextent <= 10h
16:14:47 <frosch123> hmm, though yoff = 10h, yextent = 0 might also work somewhat
16:26:17 <Sacro> oh god that sounds like yacc
16:34:57 <andythenorth> frosch123: that's useful info
16:35:11 <andythenorth> I wasn't sure how anything would fit into 0Fh
16:35:39 * andythenorth wikis for yextent
16:43:01 *** Cwok_25th_4tante has joined #openttd
16:47:47 <andythenorth> bounding boxes are brain ache
16:47:53 * andythenorth afk for an hour or two
16:48:09 <andythenorth> currently bounding boxes for forest look...weird
16:48:18 <andythenorth> I expect sprite sorting issues :(
16:48:44 *** Laila^18 has joined #openttd
17:41:15 *** devilsadvocate has quit IRC
17:44:54 *** meebbyt has joined #openttd
17:45:40 <CIA-2> OpenTTD: translators * r20416 /trunk/src/lang/ (finnish.txt german.txt italian.txt romanian.txt):
17:45:40 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:40 <CIA-2> OpenTTD: finnish - 3 changes by jpx_
17:45:40 <CIA-2> OpenTTD: german - 1 changes by BRFBlake
17:45:40 <CIA-2> OpenTTD: italian - 8 changes by lorenzodv
17:45:41 <CIA-2> OpenTTD: romanian - 2 changes by tonny
17:47:18 <meebbyt> linuxgeneric runs fine with my win32-downloaded content
17:48:01 <meebbyt> except for that linux does not know how to fix palettes broken by old/bogstandard screen modes
17:49:24 *** Hanap_GF has joined #openttd
17:51:46 <Alberth> afaik you can set the palette of a NewGRF
18:01:49 *** Eddi|zuHause2 is now known as Eddi|zuHause
18:11:14 *** Devroush has joined #openttd
18:34:44 <Dewin1> So, I can understand how livestock vans might have a low speed limit since cows being accelerated to high speeds is probably a bad idea. What I don't quite understand is why they still have a speed limit when empty.
18:36:38 *** Dewin1 is now known as Dewin
18:36:48 *** frosch123 has joined #openttd
18:39:37 <Alberth> it is a not-so-good truck, ie it cannot go faster, load has nothing to do with it
18:40:10 <Dewin> It's a carriage on a train. What happens if it goes faster, the wheels fall off?
18:40:34 <Alberth> are you talking about speed limit, or speed of acceleration?
18:41:22 <Alberth> is it correct, w.r.t. the specs of the engine and the wagons?
18:41:49 <Dewin> programmatically correct, common sensically... I'm not entirely certain
18:42:19 <Dewin> 93 mph engine. 45 mph livestock van. I'm trying to ask if there's any real reason the livestock van should be incapable of faster speeds while empty.
18:42:39 <Dewin> (so it'd be slow one way, fast on the return trip)
18:43:37 <Alberth> oh, you are using a NewGRF set
18:43:44 <Dewin> Yes, I probably should have specified that.
18:43:51 <Alberth> (default livestock van does not have a limit)
18:44:08 <Alberth> well, it works as intended by the NewGRF set author.
18:44:17 <Dewin> I like the speed limits, it makes things more interesting.
18:44:30 <Dewin> and I'm not trying to say it's not working as intended.
18:44:38 <Alberth> there is a setting to disable wagon speed limits
18:44:49 <Alberth> otherwise, find another wagon, or another set
18:45:05 <Dewin> I guess the real question is: Can newGRFs specify separate loaded/unloaded speed limits? And if not, why not?
18:45:07 <Alberth> or perhaps you'll get a new one latyer in the game
18:46:09 <Dewin> because in some cases being limited in speed makes sense while loaded (you have a bunch of cattle who aren't really secured, or an open car carrying coal and don't want it flying out) but when the car's empty there's no good reason to not go at full speed.
18:46:35 <Dewin> of course, the UK set + FIRS somehow lets me refit tankers to hold livestock, which seems silly so I don't do it.
18:46:57 <Alberth> the weight does change, and is taken into account
18:47:11 <Alberth> but that is only acceleration i think
18:47:23 <Dewin> And it's not weight, it's more... logistical things.
18:48:07 <Dewin> You can run full speed with an empty glass, but fill it with water and try to run full speed without spilling it. Has nothing to do with the weight of the contents.
18:48:51 *** trebuchet has joined #openttd
18:51:57 <Dewin> Yeah, maybe I'll toss a post up on there.
19:10:17 *** devilsadvocate has joined #openttd
19:10:40 *** JakeGrimshaw has joined #openttd
19:27:19 <AC6000> well, good to see this place is full as always :P
19:27:19 <frosch123> Alberth: actually ttdp ignores the speedlimit for empty wagons :)
19:27:36 <frosch123> it is ottd who decided that is crappy unrealisitc
19:28:05 <frosch123> and inconsistent with engines
19:28:24 <Alberth> ha ha, and now Dewin complains about realism :p
19:29:00 <frosch123> yesterday andy concluded that the realistic catchment areas are less realistic than the normal ones
19:31:25 <Alberth> realism is always used as argument if it behaves unexpected. You never hear people complain when the realism built in the game acts in their advantage :D
19:39:17 <frosch123> isn't that even written there?
19:39:53 <andythenorth> I've just invented a way to actually implement 'maintenance'
19:40:11 <andythenorth> it's a hack, but it could be fun
19:40:17 <andythenorth> or really tiresome micromanagement :P
19:43:42 <andythenorth> I create a cargo 'maintenance'. When 'normal' cargos are delivered to a station, cb 39 checks when 'maintenance' was last delivered to that station. If it's too long, no profit
19:44:11 <andythenorth> meanwhile player runs trains carrying 'maintenance', serving each station every so many days (timetables may actually be useful here).
19:44:58 <andythenorth> maintenance has two options: costs a lot of money (to help with the too much money problem), or breaks even (to prevent loss-making vehicle problem)
19:46:06 <andythenorth> this would apply to rail and road stations, maybe docks, not airports
19:46:51 <andythenorth> 'exciting' vehicles would be provided to carry 'maintenance'
19:47:22 <andythenorth> 'maintenance' cargo would come from a specific industry type. This could either just produce (as primary), or require supplies.
19:48:05 <Eddi|zuHause> sounds very silly :p
19:48:16 <andythenorth> Maintenance would not be accepted anywhere, just unload it and reload it on stations (so var 63 sees it)
19:48:24 <frosch123> damn why are so many people asking "how long is a day", "how long is a year" ?
19:48:35 <wouter> anything known about the scenario editor and trying to set a start date?
19:48:43 *** wouter is now known as Guest1292
19:48:47 <frosch123> what the heck is so interesting about that (despite of they could just measure it themself)
19:49:23 *** Guest1292 is now known as w123
19:49:43 <frosch123> w123: what is the problem with that?
19:49:47 <w123> I'm having a really hard time setting the start date for my scenario
19:50:21 <CIA-2> OpenTTD: rubidium * r20417 /trunk/src/object_cmd.cpp: -Fix (r20345) [FS#4018]: the offset stored for objects shouldn't be substracted immediately from the TileIndex as that doesn't quite do the right thing
19:50:24 <w123> everytime it resets to the value set when starting a game
19:50:44 <w123> and when loading a scenario, it sets it back to the start date saved...
19:50:57 <w123> but every time i change it... it doesn't seem to save.
19:51:13 <frosch123> create a task at bugs.openttd.org
19:52:14 <andythenorth> so 'maintenance'....winner or loser? :P
19:54:00 <Ammler> w123: newgame_setting and saveconfig
19:55:38 <Eddi|zuHause> andythenorth: i vote: nay...
20:01:48 *** Chillosophy has joined #openttd
20:03:54 *** Devroush has joined #openttd
20:54:29 <Eddi|zuHause> andythenorth: it's not about the mainline. it's about the horrible micromanagement involved...
20:55:13 <andythenorth> yeah, it could be a failed idea in reality. Especially if every road stop etc had to be visited
20:55:21 <andythenorth> sounds like a job for an AI :P
21:07:44 *** ino_crz36 has joined #openttd
21:10:24 *** ly^ndsie has joined #openttd
21:18:30 *** devilsadvocate has quit IRC
21:27:23 *** devilsadvocate has joined #openttd
21:28:45 *** ChanServ sets mode: +v tokai
21:29:42 *** lafille has joined #openttd
21:34:32 <CIA-2> OpenTTD: frosch * r20418 /trunk/src/newgrf_commons.cpp: -Fix [FS#4017](r20125): During world generation the snow-mapbits are not yet available, so test the snowline variable directly (as before).
21:42:41 *** devilsadvocate has quit IRC
21:51:21 *** devilsadvocate has joined #openttd
21:56:33 *** Chris_Booth has joined #openttd
22:03:14 *** Bluelight has joined #openttd
22:09:24 *** male_30 has joined #openttd
22:10:38 *** Dignity has joined #openttd
22:10:39 *** Tueur_Vagin has joined #openttd
22:11:25 *** michi_cc has joined #openttd
22:11:25 *** ChanServ sets mode: +v michi_cc
22:20:12 *** CHN-CO-NICE has joined #openttd
22:57:51 *** JVassie_ has joined #openttd
22:59:20 <DorpsGek> VVG: Commit by michi_cc :: r19896 trunk/src/pathfinder/yapf/yapf_costrail.hpp (2010-05-26 05:24:58 UTC)
22:59:21 <DorpsGek> VVG: -Fix [FS#3803] (r18648): [YAPP] Inform the pathfinder as well about the fact that the backside of an one-way path signal can be a safe waiting point.
23:01:54 *** Brianetta has joined #openttd
23:02:17 *** rhaeder has joined #openttd
23:07:45 <V453000> the backside of an one-way path signal can be a safe <- how could this ever be safe?
23:15:26 *** JVassie has joined #openttd
23:46:21 *** ProfFrink has joined #openttd
23:52:32 *** ProfFrink is now known as Prof_Frink
23:59:33 *** SirSquidness has joined #openttd
continue to next day ⏵
