IRC logs for #openttd on OFTC at 2013-12-08
⏴ go to previous day
00:15:38 *** FLHerne has joined #openttd
00:39:26 <Eddi|zuHause> Sacro: i rather doubt that is my area of expertise
00:39:44 <Eddi|zuHause> besides, i'm not a dev
00:47:04 *** treaki__ has joined #openttd
00:55:16 <Sacro> you've been here longer than me
00:55:33 <Eddi|zuHause> yeah. but i don't actually do anything
00:55:47 <Eddi|zuHause> i haven't played the game in two years now
00:56:55 <Eddi|zuHause> "german federal patent court invalidates microsoft-fat-patent"
00:57:43 <Eddi|zuHause> "ruling is not final and may be appealed"
00:58:01 <Hazzard> I never understand anything people here say
00:58:24 <Eddi|zuHause> maybe you should learn the language people speak :p
00:59:54 <Eddi|zuHause> apparently microsoft holds a fat-with-long-filenames patent, and google challenged it, presenting, amongst others, a post by linus torvalds as "prior art"
01:02:22 <Eddi|zuHause> as a side note: nowadays, patents are not "protecting the small inventors" anymore, but big corporations send a team of lawyers, then they hold a stack of patents against each others, and whoever has the smaller stack has to pay royalty fees
01:06:06 *** Supercheese has joined #openttd
01:28:17 *** montalvo has joined #openttd
01:44:56 <Supercheese> Forums in backup mode again
01:48:22 <LordAro> Supercheese: they're backing up, like they do every night at about this time
01:48:40 <Supercheese> It's been that way for at least 15 minutes
01:49:00 <Supercheese> I suppose it may just be taking longer than usual
02:19:01 <LordAro> meh, there's nothing interesting on the forums anyway :p
03:09:20 <Supercheese> same problem as before, it seems
03:10:44 <Supercheese> Brrr, very cold here
03:10:47 <Supercheese> @convert 4 F to C
03:10:47 <DorpsGek> Supercheese: -15.5555555556
03:15:54 *** Myhorta has joined #openttd
03:36:30 *** DanMacK has joined #openttd
03:37:12 <DanMacK> Have the backups for the forums been extremely long lately or is it just me?
03:37:41 <DanMacK> it's been backing up for hours
03:38:21 <DanMacK> was like that yesterday too
03:41:51 <Supercheese> not sure what's happening, but something's gone wrong
04:22:15 *** DarkAce-Z has joined #openttd
04:31:13 *** Hazzard has joined #openttd
04:40:36 *** DarkAce-Z is now known as DarkAceZ
05:02:26 *** Hazzard is now known as Guest8485
05:02:26 *** hazzard has joined #openttd
05:02:43 *** hazzard is now known as Hazzard
05:48:55 *** Super_Random has joined #openttd
05:56:16 *** Eddi|zuHause has joined #openttd
06:45:44 *** sla_ro|master has joined #openttd
06:50:36 *** andythenorth has joined #openttd
07:16:04 <Eddi|zuHause> orudge: still in backup mode
07:16:40 <Eddi|zuHause> i'm sure it's the winter theme's fault :p
07:16:58 <Eddi|zuHause> (correlation vs. causality :p)
07:20:48 *** andythenorth has joined #openttd
07:29:14 *** Tom_Soft2 has joined #openttd
08:55:33 *** Pensacola has joined #openttd
09:34:33 *** GriffinOneTwo has joined #openttd
09:57:50 *** Alberth has joined #openttd
09:57:50 *** ChanServ sets mode: +o Alberth
09:59:10 <planetmaker> ui, all wake up. moin moin all along :D
10:10:14 * Alberth makes breakfast for all
10:12:35 *** Ristovski has joined #openttd
10:14:02 *** valhallasw has joined #openttd
10:16:55 * LordAro is not surprised by V453000's breakfast choices
10:16:59 <fonsinchen> V453000: ever tried beer-flavoured coffee?
10:17:46 <V453000> I dont really drink coffee much
10:18:00 <V453000> waste of time as you could be drinking beer in the meantime
10:21:15 *** Progman has joined #openttd
10:21:30 <Taede> could make it an irish coffee
10:24:50 *** zeknurn has joined #openttd
10:25:57 <V453000> yeah and if you put away the coffee, its perfect :P
10:28:39 *** Midnightmyth has joined #openttd
10:32:42 *** montalvo has joined #openttd
10:40:30 *** tokai|mdlx has joined #openttd
10:43:58 *** HerzogDeXtEr has joined #openttd
10:57:16 *** Gethiox3 has joined #openttd
11:06:04 *** oskari89 has joined #openttd
11:08:45 *** frosch123 has joined #openttd
11:30:33 *** Devroush has joined #openttd
11:44:36 *** andythenorth has joined #openttd
11:46:27 *** gelignite has joined #openttd
11:47:09 <NGC3982> If i have two adjacent industries that both accept Engineering Supplies
11:47:52 <NGC3982> And deliver Eng. Supplies to a station that is connected to both of them. Does the industry with >0% transported goods be the one that uses it?
11:49:38 <andythenorth> AIUI, the industry with it's north tile closest to station sign gets it
11:49:45 <andythenorth> might be wrong though, stations are weird
11:51:54 * andythenorth looks for road docs
11:52:41 <andythenorth> so do roads have a specific bit for catenary?
11:52:51 <andythenorth> or is it just automatically drawn for trams
11:53:19 <andythenorth> looks like there's a bit free anyway
11:53:42 <V453000> ASPHALT_RAIL and ASPHALT_ELRL? :P
11:58:28 * andythenorth proposes roads-with-and-without-catenary and trams-with-and-without-catenary
11:59:30 <planetmaker> andythenorth, there's two road types, road and tram tracks. Tram tracks have catenary
11:59:46 * MNIM proposes to actually implement roadtypes some time.
12:00:19 <andythenorth> you and a lot of other people have proposed that ;)
12:00:48 <andythenorth> I am -1 to roadtypes these days
12:01:05 <V453000> railtypes solve everything XD
12:01:06 <andythenorth> a *lot* of work for minimal gameplay benefit
12:01:12 <MNIM> andythenorth: for years.
12:01:19 <andythenorth> and loads more fiddly compatibility crap to deal with
12:01:28 <andythenorth> roadtypes have some thorny problems
12:01:31 <planetmaker> it would follow the existing concept
12:01:50 <planetmaker> the only really thorny problem is town growth wrt road types :)
12:01:52 <andythenorth> there aren't enough bits to write a spec for roadtypes that will get accepted
12:02:02 <planetmaker> thorny problem in design that is :)
12:02:09 <andythenorth> there are problems with MP and ownership
12:02:13 <planetmaker> yeah, space there is an issue
12:02:26 <andythenorth> there is some boring work to handle rail crossings
12:03:14 <planetmaker> they are handled by railtypes
12:03:34 <planetmaker> with railtypes present it currently works like
12:03:37 <planetmaker> *draw normal road
12:03:45 <planetmaker> *draw rail crossing sprite
12:03:57 <planetmaker> *draw possibly rail crossing lights
12:05:02 <planetmaker> I don't see a need to change that for other road types
12:05:16 <Eddi|zuHause> <planetmaker> the only really thorny problem is town growth wrt road types :) <-- why? a simple "towns may grow along this type" property should suffice
12:05:32 <planetmaker> it would, Eddi|zuHause, yes
12:05:39 <andythenorth> didn't we discover that only two road types can be present on a tile?
12:05:53 <andythenorth> and that there would be lots of fiddly messaging to player about what can be built or not
12:05:54 <planetmaker> andythenorth, yes. but so?
12:06:16 <planetmaker> ah, you mean which two. yeah. that's the... big problem I guess. you're right
12:06:21 <Eddi|zuHause> michi_cc's map stuff may allow an arbitrary number of roadtypes
12:06:47 <Eddi|zuHause> i do certainly see situation where i'd need 3
12:07:34 <planetmaker> we don't need the jack-of-all-trades roadtype combinatoric solution
12:08:45 <planetmaker> where would you need three, Eddi|zuHause ?
12:08:45 <MNIM> Why would we not need them?
12:09:30 <planetmaker> MNIM, jack-of-all-trades is the enemy of a viable and possible solution
12:09:31 <Eddi|zuHause> planetmaker: imagine a route that has both trolley bus and tram lines. then the tram line goes straight on, the trolley bus turns to the left, and a normal road to the right
12:10:02 <Eddi|zuHause> how to make it so there isn't a catenary stump to the right?
12:10:04 <planetmaker> Eddi|zuHause, two are sufficient, if trolley is compatible to tram
12:11:05 <MNIM> road+rail+cat. - road+rail. - road+cat. - road. - rail+cat. rail.
12:11:31 <MNIM> (assuming some trams run without catenary, as steam trams are prone to do)
12:12:07 <Eddi|zuHause> MNIM: that's 4 roadtypes and combinations
12:12:11 <MNIM> and that's before even considering different roadtypes like dirt road, city road, normal road and highway.
12:12:12 <planetmaker> MNIM, don't confuse 'all road types thinkable' with 'needed on one tile'
12:12:34 <andythenorth> Eddi|zuHause last time I saw this discussion you proved we don't have enough bits
12:12:43 <MNIM> Oh, wait, you mean properties, not types.
12:12:43 <andythenorth> there are also the problems like dirt road crossing tram
12:12:55 <andythenorth> i.e. the requirement to define some types as incompatible
12:13:02 <andythenorth> it also makes for trivial griefing
12:13:09 <andythenorth> although the answer to that is well known
12:13:43 <Eddi|zuHause> that's a problem that is never solved by technical means
12:14:23 <Alberth> don't make things incompatible would be saner, imho
12:15:07 <planetmaker> so roads need an underlay, and an overlay
12:15:18 <Eddi|zuHause> Alberth: but a "Stadtbahn" tram type that cannot be placed on road but has increased speed limit may provide additional gameplay value
12:15:18 <planetmaker> only one underlay is drawn, then two overlays
12:15:32 <planetmaker> but we need a way to define upper and lower roadtype
12:15:51 <planetmaker> or a sort-of priority
12:16:25 <Eddi|zuHause> "placed on" means "occupy the same road bit", there would still be crossings allowed
12:17:06 <MNIM> so then you would need to make sure it can recognize the difference between crossing and running along.
12:17:30 <Eddi|zuHause> i don't think that's a difficult problem
12:18:22 <fonsinchen> The question is how to rephrase that "Accepts:" string to tell people what that actually means...
12:18:47 <MNIM> you're the coder, but either way I think the compatibility part of it can be delayed until the basic roadtypes feature is actually implemented (and proven)
12:19:29 <MNIM> It is, at the very least something that cannot be made without doing the basic feature first, anyway.
12:19:48 <planetmaker> MNIM there first should be a sensible design which allows extension
12:20:26 <Eddi|zuHause> MNIM: since we're in the design phase and not the implementation phase, that's no good argument at all
12:20:51 <MNIM> unless said sensible design is really convoluted in the first place, that property should remain true regardless
12:21:01 <frosch123> fonsinchen: i thought about using "coal (low), steel (medium), wood (high)"
12:21:35 <fonsinchen> Well, try the patch and see what strange numbers the default industries produce already
12:21:55 <fonsinchen> That high/medium/low threshold would have to be defined per cargo
12:22:11 *** retro|cz has joined #openttd
12:22:17 <frosch123> how do i get a proper raw diff from github?
12:23:32 <fonsinchen> It used to be easy - you just had to add "raw" somewhere in the URL ... seems they've removed it
12:23:40 <LordAro> frosch123: add ".diff" to the url
12:23:47 <LordAro> google always knows ;)
12:23:50 <frosch123> excellent interface :)
12:24:04 <LordAro> well, stackoverflow knows often too :p
12:24:57 <LordAro> frosch123: afaik, it's because you're supposed to use pull requests, not raw diffs
12:25:23 <planetmaker> LordAro, but you want to know what to pull :)
12:25:47 <LordAro> ah, but git[hub] handles that for you
12:25:48 <frosch123> LordAro: fine for them, i just file it under crap
12:26:23 <LordAro> funnily enough, github is focused on git -> git actions, not git -> svn
12:26:53 <LordAro> a bit of an odd style choice i grant you, but at least they made it "easy" to get anyway
12:27:01 <LordAro> even if there isn't a nice button to press
12:27:49 <Eddi|zuHause> that is such a stupidity, that i can't even find a good analogy how stupid it is
12:27:52 <planetmaker> LordAro, raw diffs are not exactly odd for *any* vcs' review process
12:28:31 <LordAro> ah yes, but you've got the diff in front of you, in a funny format, if you just pull this changeset, why would you need the raw diff?
12:29:44 <fonsinchen> Let's not get into the vcs flamewar, please.
12:29:48 <frosch123> so, some industries only accept with one tile
12:30:05 <LordAro> fonsinchen: spoil sport :p
12:30:08 <frosch123> while the factory does with 12
12:30:25 * andythenorth found an old roadtypes spec
12:30:31 <fonsinchen> steel works can have ridiculous numbers, too
12:31:24 <frosch123> let's check toyland
12:31:29 <frosch123> usually it is more well designed
12:31:42 *** Supercheese has joined #openttd
12:32:31 <frosch123> in toyland the processing industries seem to consistently accept with all tiles
12:32:41 <frosch123> no fancy "only one tile accepts" stuff
12:33:51 <fonsinchen> There still are industries with 4 tiles and others with 12, though
12:34:12 <frosch123> yeah, that's the argument we had about firs yesterday
12:34:49 <fonsinchen> In principle that's no problem for cargodist, nor is it a problem for grf authors if they can demands > 8 per tile
12:34:58 <fonsinchen> However, it's a UI problem.
12:35:23 *** tokai|noir has joined #openttd
12:35:23 *** ChanServ sets mode: +v tokai|noir
12:35:28 <fonsinchen> ^... specify demands ...
12:35:30 <frosch123> it is a problem if you mix stuff, it is also a problem for ais
12:35:45 <andythenorth> roadtypes stuff ^
12:36:03 <andythenorth> that's from April 2012
12:36:13 <andythenorth> best we could get at the time
12:36:24 <frosch123> so, i would claim that all tiles accepting 8/8 is the normal case
12:36:33 <andythenorth> I might be wrong, but pikka I think had a simpler alternative solution, which was rejected
12:36:35 <fonsinchen> What problem would AIs have with that?
12:36:37 <frosch123> it is also the easier case for gameplay
12:36:45 <fonsinchen> Towns accept less than 8/8
12:36:53 <andythenorth> all tiles accepting 8/8 is the only sane solution for industries :P
12:37:03 <frosch123> fonsinchen: for ais it's the same as the gui
12:37:16 <fonsinchen> can't you accept 15/8 to increase demand?
12:37:23 <andythenorth> dicking around with station locations to add up tile acceptance is really boring gameplay
12:37:30 <andythenorth> so less than 8/8 is just doing it wrong
12:37:40 <fonsinchen> What about more than 8/8?
12:37:56 <andythenorth> more than 8/8 never made sense - until now
12:38:05 <frosch123> well, i think the only solution is to make it depend on the industry size or so
12:38:23 <frosch123> or rather, first the gameplay question:
12:38:25 <planetmaker> I read specs to be valid 0-8 only so far :)
12:38:32 <frosch123> shall demand depend on the amount of tiles you cover?
12:38:41 <fonsinchen> Well it can be easily extended to 0-15
12:38:46 <fonsinchen> we already have the bits
12:38:58 <frosch123> i think we should ignore the specs details, until we know what the gameplay shall be like
12:39:06 <andythenorth> no, demand should depend on coverage of any tile of industry
12:39:15 <andythenorth> industry demand is specific to industry as a whole, not it's tiles
12:39:19 <andythenorth> (is my proposal) :)
12:39:28 <frosch123> yeah, i would also think so :p
12:39:59 <andythenorth> industry has its own internal transport :P You don't need to provide that :P
12:41:08 <fonsinchen> I'm just saying that with very moderate changes we could make the demands accessible to GRFs
12:41:36 <fonsinchen> There's almost no work involved and it looks ok to me as everything else in that area works based on tiles.
12:41:58 <Eddi|zuHause> <andythenorth> I might be wrong, but pikka I think had a simpler alternative solution, which was rejected <-- pikka's "one roadtype per tile" solution suffers from combinatoric explosion when you want to provide anything more than trivial choices
12:42:15 <andythenorth> fonsinchen: I am +1 to this idea, if I've understood correctly
12:42:20 <andythenorth> at least we can test it :)
12:42:47 <andythenorth> Eddi|zuHause: so only provide trivial choices...?
12:42:58 <andythenorth> how interesting are roadtypes anyway?
12:43:27 <peter1138> Not enough for me to do it yet.
12:43:36 <frosch123> the question to make demeand accessible to newgrf is independent
12:43:55 <frosch123> i still want to stress the gameplay: shall demand depend on the number of tiles a station convers?
12:44:24 <frosch123> it makes sense for houses, but feels wrong for industries
12:44:45 <andythenorth> yes is ambiguous answer, sorry :P
12:44:51 <andythenorth> I agree that it's wrong for industries
12:44:57 <planetmaker> though actually for houses, they could be considered monolithic, too
12:45:08 <planetmaker> then it would be the same everywhere: cover one tile, get it all
12:45:09 <frosch123> you both make no sense
12:45:15 <andythenorth> even if that makes the implementation easy, doing it on tiles covered is not optimal
12:45:16 <Eddi|zuHause> each house is a "monolith"
12:45:41 <Eddi|zuHause> if you cover a 2x2 house on one tile, you cover the demand of the entire house
12:46:03 <andythenorth> ok so covering a tile covers it's parent object?
12:46:42 <frosch123> andythenorth: planetmaker: just to make it clear. if you have two factories with a station each. one station covers 12 tiles of the industry, the other station 6 tiles of the other industry. should the 12 tile station get twice the cargo routed than the 6 tile one?
12:47:26 <planetmaker> hu? no. Station size and covered size of any item should not matter. Cover one tile, get all output
12:48:17 * Alberth imagines the fights for the optimal delivery spot in competition play :p
12:48:27 <fonsinchen> actually houses are not monolithic, nor atomic in that sense
12:48:30 <frosch123> there is no competition
12:48:42 <frosch123> you only control the weights in your own network
12:48:51 <Eddi|zuHause> fonsinchen: but they should be :)
12:49:06 <frosch123> there is nothing unfair about it, it's just an insanely complex game mechanic
12:49:15 <Eddi|zuHause> frosch123: that concept feels totally wrong
12:49:25 <planetmaker> Also for input. Or using station-walk is required by gameplay
12:50:04 <fonsinchen> The whole thing only comes into play if you want to influence the distribution algorithm on a fine grained level
12:50:15 <frosch123> planetmaker: it does not affect the total amount in the network, only the distribution within your network
12:50:17 <fonsinchen> It's not really an everyday problem.
12:50:40 <frosch123> fonsinchen: the problem is that most people do not want to influence the distribution algorithm
12:50:55 <frosch123> but will rather be completely confused why some industries get no cargo
12:50:58 <frosch123> while others are flooded
12:51:09 <Eddi|zuHause> fonsinchen: but people not aware of the mechanic will wonder why one industry gets 90% of the cargo and the trains to the other industry are empty, clogging up the pickup station
12:52:24 <andythenorth> that happens currently with cdist anyway
12:52:27 <andythenorth> my game has that
12:52:47 <andythenorth> so I'd suggest it's a non-issue ;)
12:52:47 <Eddi|zuHause> andythenorth: that's mostly the distance
12:52:55 <andythenorth> I've turned distance off some years ago
12:54:05 <Eddi|zuHause> frosch123, fonsinchen: if you really want to allow the player to fine tune it, let them assign a weight to the station manually
12:54:17 <andythenorth> I do wonder if manual is easiest solution
12:54:41 <fonsinchen> Maybe I should just ignore the numbers and only check for >0 in the demands calculation after all.
12:54:52 <andythenorth> I was yesterday trying to work out how a newgrf industry would increase or decrease demand
12:54:58 <fonsinchen> andythenorth: can I see one of your games?
12:55:00 <frosch123> fonsinchen: you mean ">= 8" ?
12:55:12 <andythenorth> fonsinchen: yes - later :) Got to go do chores
12:55:18 <fonsinchen> frosch123: depends on what number you get as input
12:55:22 <andythenorth> I'll have to give you some newgrfs as well
12:56:11 <planetmaker> fonsinchen, I don't find the numbers I get with your patch with default industries that bad
12:56:33 <planetmaker> especially for towns the display of actual numbers is nice to see best place to put a station
12:57:00 <fonsinchen> Imagine someone covering one tile of a steel works with a station and all 12 tiles with another station
12:57:09 <fonsinchen> The second station will get 12 times as much cargo.
12:57:22 <fonsinchen> And the player won't understand that.
12:57:35 <planetmaker> they won't without any indicator
12:57:46 <planetmaker> they will, if station acceptance quantity is shown
12:58:26 <fonsinchen> True, that's why I wrote that patch. However, how do you translate those numbers for people who have no idea what we're talking about here?
12:58:42 <Eddi|zuHause> they won't if they load an older savegame and their network breaks down for no reason
12:59:01 <fonsinchen> If they load an older savegame cargodist is off. Problem solved.
12:59:12 <Alberth> fonsinchen: as percentage of total acceptance for all tiles?
12:59:27 <fonsinchen> what is "all tiles"?
13:00:39 <Alberth> all tiles belonging to an entity which you have covered by at least one tile
13:00:48 <Alberth> but I am not sure it's a good measure
13:01:17 <Alberth> otoh, I don't know a better one currently
13:01:46 <fonsinchen> The whole point of it is that newGRF authors could dynamically change acceptance levels. Then the percentage doesn't help
13:02:56 <Eddi|zuHause> fonsinchen: if you want newgrf authors to take influence, you should provide a new property/callback, and not hack it into some unrelated/unprepared old property
13:03:07 <Alberth> percentage of theoretical max accepted cargo for all tiles with non-zero acceptance?
13:04:15 *** LordAro has joined #openttd
13:04:15 <fonsinchen> Eddi|zuHause: "acceptance" and "demand" are basically the same thing, aren't they?
13:05:26 <Eddi|zuHause> fonsinchen: a small medieval smith may accept metal and produce tools, the "acceptance" would be the same as a modern factory, but the "demand" would be much lower
13:06:13 <fonsinchen> Acceptance is thus defined as (demand > 0) ? true : false
13:06:27 <fonsinchen> This is what I mean as basically the same.
13:07:12 <Eddi|zuHause> fonsinchen: which brings us back to the original problem: "acceptance" is currenty a property if industrytiles, while "demand" should be a property of industry (as a whole)
13:08:11 <fonsinchen> I think we're stuck here. I will think about it some more.
13:09:57 *** zeknurn has joined #openttd
13:10:44 *** tycoondemon has joined #openttd
13:15:21 *** Phreeze has joined #openttd
13:20:09 <Phreeze> hiho, is there an expert in NML ? getting a NewGRF error when clicking on the refit button of my train (but only once, the very first time trying to refit from 3 to 4 cars)
13:21:29 <planetmaker> that's rather unspecific, Phreeze
13:21:47 <Phreeze> it's an error about cargo_subtype 0x19
13:21:48 <Eddi|zuHause> might be better suited for the forum, where you can give a more elaborate explanation/example
13:21:54 <planetmaker> also mind, that a refit cannot change the number of vehicles in a consist
13:22:04 <planetmaker> it can only change the looks of them
13:22:14 <Phreeze> yeah, it's a pseudo refit ;) from the tutorial
13:22:32 <Phreeze> shortens 1 waggon to 7/8 + 1/8 invis
13:23:01 <Phreeze> is it normal that i only get the error once ? if i sell the train and rebuild it, i dont get the same error again
13:23:28 <planetmaker> you can only do this refit in a depot, mind that
13:23:47 <Eddi|zuHause> maybe it uses cached results after that
13:24:07 <Eddi|zuHause> but really, without any details nobody can tell what your problem is
13:24:14 <Alberth> or it suppresses more reports
13:25:17 *** Superuser has joined #openttd
13:25:38 <frosch123> Phreeze: you say you get an error
13:26:26 <Phreeze> Newgrf (myset) has errors:
13:26:41 <Phreeze> Callback 0x19 returned unknown/invalid result 0x7fff
13:26:53 <Phreeze> 7fff in decimal is about 32757 or so
13:27:10 <Eddi|zuHause> 7fff is the maximum that can be returned
13:27:12 <frosch123> these newgrf errors are only reported once
13:27:17 <Phreeze> got this in a red error box after clicking on the refit button on my newly build train
13:27:25 <frosch123> then ottd suppresses them to not annoy the player about broken grf
13:27:42 <frosch123> and yes, 7ffff is an invalid result
13:27:46 <Eddi|zuHause> often meaning "invalid"
13:27:52 <Phreeze> k...i doublechecked my switches that have the cargo_subtype in them
13:28:11 <frosch123> you shoudl returns 0x400 or a string
13:28:19 <Eddi|zuHause> can you paste the code?
13:28:31 <Phreeze> i paste the code on pastebin or so, wait a sec
13:29:05 <frosch123> paste.openttdcoop.org is faster most of the times
13:29:40 <Phreeze> oh i didn't know that paste-link
13:30:16 <frosch123> return CB_RESULT_NO_MORE_ARTICULATED_PARTS; <- that's wrong
13:31:15 <frosch123> it should be CB_RESULT_NO_TEXT
13:31:16 <Phreeze> should i just leave that line away ?
13:31:57 <frosch123> the callback is about subtypes, not articulated parts :)
13:32:01 <Phreeze> i just analysed the "whole code" from the tutorial
13:32:18 <Phreeze> on the last page of the train tutorial, and it shows other parts than before
13:32:27 <Phreeze> in the complete code it says return 0xFF
13:32:42 <Phreeze> in the tutorial pages back, it said the NO_MORE_ART....
13:32:52 <frosch123> 0xFF may have worked in nml 0.2, but is wrong now
13:33:05 <frosch123> can you give a link to those pages?
13:33:50 <Phreeze> this part has an 0xFF too: /* --- Articulated part callback --- */ switch(FEAT_TRAINS, SELF, sw_icm_articulated_part, extra_callback_info1) { /* Add three articulated parts, for a total of four */ 1 .. 3: return item_icm; return 0xFF;
13:34:02 <Phreeze> and the start stop callback too
13:34:15 <Phreeze> these 3 are the only ones
13:36:03 <Phreeze> Error is gone, many thx for the help :)
13:36:25 <Phreeze> getting to understand the mechanics more and more
13:41:19 <frosch123> fixed those two pages, at least i hope so :)
13:46:28 <planetmaker> tutorials get old :S
13:55:38 *** andythenorth has joined #openttd
13:56:55 <planetmaker> it was no argument of mine against tutorials :)
14:07:57 <andythenorth> so I had to drive for a couple of hours yesterday, and spent some time thinking about how industries would want to adjust demand
14:08:13 <andythenorth> and I couldn't find a good answer without specifying actual quantities
14:08:23 <andythenorth> it looks nice and neat to use scale-free (relative) demands
14:08:32 <andythenorth> but thats not how something like FIRS works :(
14:08:47 <andythenorth> for which I would apologise, except it's the result of endless discussion and *lots* of testing :)
14:18:38 *** Virtual- has joined #openttd
14:49:52 <DorpsGek> Commit by frosch :: r26147 /trunk/bin/baseset (6 files) (2013-12-08 14:49:47 UTC)
14:49:53 <DorpsGek> -Update: Baseset translations
15:13:12 <DorpsGek> Commit by frosch :: r26148 trunk/src/script/api/script_order.cpp (2013-12-08 15:13:06 UTC)
15:13:13 <DorpsGek> -Fix [FS#5824] (r25735): Script API failed for vehicles with only implicit orders.
15:16:58 *** montalvo has joined #openttd
15:22:57 *** Tom_Soft2 has joined #openttd
15:28:55 *** onezero has joined #openttd
15:44:15 <DorpsGek> Commit by frosch :: r26149 /trunk/src/script/api (6 files) (2013-12-08 15:44:09 UTC)
15:44:16 <DorpsGek> -Fix [FS#5825]: [Script] Various API functions did not check whether ScrtipRoad::SetCurrentRoadType was called appropiately.
15:46:40 *** spectator is now known as jrambo
15:50:18 *** Myhorta has joined #openttd
15:51:18 *** andythenorth has joined #openttd
16:06:08 <andythenorth> maybe I can loop over preceeding vehicles until I find one with ID of lead unit
16:06:18 <andythenorth> then I know what position current vehicle is in
16:06:36 <andythenorth> that switch will need generating :P
16:08:54 <planetmaker> position_in_consist and position_in_vehid_chain are not enough?
16:12:14 <frosch123> andy wants position in consist of consecutive articulated vehicles with same front vehicle id, while ignoreing ids of articulated parts, which differ
16:12:20 <frosch123> or something like that :p
16:12:56 <frosch123> we could add a new var, which skipps artic parts
16:13:30 <andythenorth> I need to know position within articulated vehicle
16:13:39 <andythenorth> I don't mind figuring it out compile side
16:14:25 <frosch123> meanwhile, not asking V: is it ok to remove rv from the game? :p
16:14:32 <frosch123> the movement code is too cryptic
16:14:42 <andythenorth> I am -0.3 to that :P
16:15:01 <andythenorth> although some parts of the idea are appealing :)
16:15:52 <planetmaker> roads are just rails without rails :P
16:16:05 <andythenorth> frosch123: can you list any downsides to your plan? o_O
16:16:30 <frosch123> andythenorth: worst part is to acknowledge V
16:16:31 <andythenorth> we could just weigh positives and negatives, whichever wins, wins
16:16:41 <andythenorth> that is a pretty big downside actually
16:16:50 <andythenorth> that's about -255 or so
16:17:07 <andythenorth> still...the game needs more features
16:17:15 <andythenorth> feature: fewer transport types
16:17:37 <planetmaker> isn't that called 'streamlining'?
16:18:00 <planetmaker> or profile sharpening
16:18:48 <andythenorth> pruning dead code?
16:19:04 <andythenorth> also it would have performance benefits
16:19:06 <planetmaker> that has again negative connotation ;) Euphemisms rule
16:19:13 <andythenorth> and we could modernise the newgrf spec
16:20:03 <andythenorth> frosch123: by any chance you're reading the tram code?
16:20:15 <andythenorth> and the stuff that moves it around sharp or not-sharp curves?
16:20:29 <andythenorth> and the stuff iirc that attempts to stop trams getting stuck (that does't work)
16:21:05 <Eddi|zuHause> <frosch123> the movement code is too cryptic <-- move it to the new NewGRF-able airport state machine specs :)
16:23:09 <Eddi|zuHause> the way i imagined it could work: the state machine controls the position of the lead vehicle, the vehicle stores the last 8 (-shorter_vehicle) positions, and on movement it pushes the last value into the next following vehicle in the chain
16:23:29 <Eddi|zuHause> i.e. following vehicles will just move along the same path the lead vehicle took
16:24:38 <frosch123> andythenorth: no, rb experimentally removed some code which obviously made no sense
16:24:49 <frosch123> now there is a fs task, and if i readd that code, it works :p
16:25:00 <Eddi|zuHause> then one could start designing (hardcoded) state machines for the road tiles, which include overtaking and balancing two lanes in the same direction
16:25:27 <frosch123> now i removed the code that makes no sense in a different way, and it also seems to work
16:27:40 <George> What is the right way to get the year vehicle at position was build?
16:27:40 <George> checking var C4 would be enough?
16:27:40 <George> or it has value 00 for 1920 and does not allow to check years before 1920 and after 2175?
16:28:20 <frosch123> all 80+x only work 1920-2175
16:29:17 <NGC3982> I'ma build a got damn slave cart for year 1 to 1810.
16:30:46 <NGC3982> Although, i would not really want to transport coal with that.
16:31:31 <frosch123> yeah, tenders are a problem with rocket cars
16:32:06 <planetmaker> :) you need to invent push service for those
16:32:08 <NGC3982> Slaves > Rocket cars.
16:34:53 *** treaki_ has joined #openttd
16:44:56 *** Hazzard has joined #openttd
16:47:40 *** Hazzard has joined #openttd
17:03:11 *** Phoenix_the_II has joined #openttd
17:20:32 <alluke> is is possible to write a grf that removes maglev bridges from tbrs?
17:22:05 <Eddi|zuHause> no, you can only modify that grf directly to not add them
17:27:44 <alluke> but there are other grfs that mod others
17:27:51 <alluke> like ecs/firs extensions for trainsets
17:28:43 <V453000> which add things, not remove
17:30:31 <alluke> what about a grf that replaces the maglev bridges with new ones?
17:37:50 <fonsinchen> +1 to removing rv - at the same time allow rails on top of any kind of road.
17:38:19 <fonsinchen> Instantly solves the "I have to bulldoze half the town to place a station" problem
17:38:32 <andythenorth> just remove road
17:39:08 <fonsinchen> Also a fun idea. But implies a new town growth algorithm
17:41:28 <Eddi|zuHause> the RRT way: towns move out of the way when you build rails
17:41:42 <andythenorth> grow along tracks
17:41:50 <andythenorth> also rivers suck
17:41:52 <andythenorth> remove those too
17:42:04 <Eddi|zuHause> remove the game, start over!
17:42:34 <fonsinchen> What is the last trunk revision you can cleanly rebase YACD onto? 24990?
17:42:59 <Eddi|zuHause> i think there's a patch around for that
17:44:34 <Eddi|zuHause> alluke: use SMITS instead of these silly "optical illusion" tracks
17:45:03 <alluke> i dont like how they look
17:45:53 <Eddi|zuHause> the whole game is "clean and bright"
18:04:54 *** Super_Random has joined #openttd
18:20:20 <DorpsGek> Commit by frosch :: r26150 trunk/src/script/api/script_company.cpp (2013-12-08 18:20:14 UTC)
18:20:21 <DorpsGek> -Revert (r26120): EnforcePrecondition alters the last-error status and is only meant for commands.
18:27:53 *** abchirk_ has joined #openttd
18:45:22 <DorpsGek> Commit by translators :: r26151 /trunk/src/lang (luxembourgish.txt turkish.txt) (2013-12-08 18:45:14 UTC)
18:45:23 <DorpsGek> -Update from WebTranslator v3.0:
18:45:24 <DorpsGek> luxembourgish - 37 changes by Phreeze
18:45:25 <DorpsGek> turkish - 40 changes by wakeup
18:56:17 *** DarkAce-Z has joined #openttd
19:13:06 *** Midnightmyth has joined #openttd
19:22:44 *** bdavenport has joined #openttd
19:28:46 *** jjavaholic_ has joined #openttd
19:31:48 <andythenorth> be nice if I could just zip a game + it's newgrf deps :P
19:31:55 <andythenorth> I guess that would have....issues :(
19:32:46 <NGC3982> I really love running.
19:43:35 *** Gethiox has joined #openttd
19:45:25 *** DarkAce-Z is now known as DarkAceZ
20:07:41 <alluke> is there any tutorial for making ng tracks from bg?
20:08:26 <Eddi|zuHause> drawing or coding?
20:08:45 <alluke> the I directions are easy to do
20:08:52 <Alberth> alluke: I have that problem with abbreviations like "ng" or "bg"
20:09:06 <alluke> narrow gauge / broad gauge
20:09:30 <Eddi|zuHause> MB had some opinions on how wide the tracks should be
20:09:56 <Alberth> less than a tile would be fine, imho
20:10:00 *** valhallasw has joined #openttd
20:10:01 <alluke> i had in mind that i halven the gauge
20:11:52 *** Virtual- has joined #openttd
21:20:38 <juzza1> those graphics are deprecated
21:22:09 <DorpsGek> Commit by frosch :: r26152 trunk/src/roadveh_cmd.cpp (2013-12-08 21:22:03 UTC)
21:22:10 <DorpsGek> -Revert/Fix (r26118) [FS#5822]: While the condition is non-sense, the 'true' case is required for articulated parts and the 'false' case is required for savegame compatibility.
22:14:10 *** LeandroL has joined #openttd
23:09:31 *** Myhorta has joined #openttd
23:33:07 *** DarkAce-Z has joined #openttd
23:59:51 *** onezero has joined #openttd
continue to next day ⏵
