IRC logs for #openttd on OFTC at 2011-11-13
⏴ go to previous day
00:58:58 <Markk> Ich hätte lust mit großen tieren.
01:03:06 <Eddi|zuHause> i don't know if there ever is a right channel for that :p
01:38:25 <valhallasw> Markk: oh my. im mein land?
01:41:11 <Markk> Nein, in einem land, wo es legal ist.
01:43:22 *** Rabbit67890 has joined #openttd
01:44:18 <Markk> Es ist aber nur einen lyrische. :)
01:44:52 <valhallasw> You're missing my reference ;-)
01:45:20 <valhallasw> (rammstein released a new song the 11th, called 'mein land')
01:45:34 <Markk> I listened to it today acctually. :)
01:46:29 <Markk> (Most of the german I've learned is from Rammstein and Wikipedia)
01:47:39 <Markk> I had some german folks at a placed I used to work at, and they did not fancy me walking around and saying that.
01:47:56 <valhallasw> nooo, probably not.
01:48:10 <valhallasw> even though, according to wikipedia, zoophilia is legal in germany
01:49:34 <valhallasw> it's actually legal in most european countries
01:50:12 <valhallasw> but that's mainly because there is often not a specific law covering it
01:52:03 <valhallasw> anyway, time to get some sleep
01:52:11 <valhallasw> have fun listening to rammstein :p
01:52:28 <Rabbit67890> ok.... who screwed my client
01:52:50 <Rabbit67890> WRONG CHANNEL *facepalm
03:27:17 *** rhaeder1 has joined #openttd
04:33:02 *** DoubleYou has joined #openttd
05:56:25 *** Eddi|zuHause has joined #openttd
07:19:42 *** mahmoud has joined #openttd
07:38:04 *** andythenorth has joined #openttd
08:03:00 <andythenorth> Eddi|zuHause: why bother with refrigerated, covered etc? Why not just use the cargo aging cb to differentiate between wagons?
08:10:29 <andythenorth> same for armoured
08:19:10 *** Kurimus has joined #openttd
08:20:03 <andythenorth> hola planetmaker
08:21:50 <peter1138> when do opengfx+ rvs start?
08:23:13 <peter1138> hmm, the readme for it is...
08:23:18 <peter1138> well it's about compiling it
08:27:52 <planetmaker> peter1138: it starts at the same time as default vehicles
08:28:16 <planetmaker> and yes, the readme is not yet targeted mostly at players
08:28:26 <planetmaker> nearly no readme is ;-)
08:28:46 <peter1138> it's a common problem with tons of opensource software too
08:28:57 <peter1138> this is how you download and compile it
08:29:05 <andythenorth> wtf stops the front vehicle of a tram from loading cargo?
08:29:10 <peter1138> but ... _what is your software_ :S
08:29:13 <planetmaker> well. Others don't read it, peter1138 ;-)
08:29:36 <peter1138> planetmaker, too true
08:29:48 <peter1138> i only read the readme cos we have that funky ingame viewer now :)
08:30:10 <peter1138> andythenorth, capacity 0 :p
08:30:23 <andythenorth> that's what I thought
08:30:25 <andythenorth> but the code lies
08:34:13 <andythenorth> definitely has a capacity
08:34:18 <andythenorth> it's reporting it correctly
08:35:24 <andythenorth> it's set by cb 36
08:36:23 <andythenorth> I can see capacity of consist changing if I adjust return value of cb
08:36:41 <andythenorth> are there flags that stop powered vehicles loading?
08:46:06 *** TWerkhoven has joined #openttd
08:48:18 <andythenorth> new HEQS feature: bugs :(
08:48:44 <Rubidium> oh, that sounds like a fun new cargo
08:48:54 <Rubidium> ant farm -> food factory
08:52:07 <andythenorth> maybe I'm doing it wrong
08:52:35 <andythenorth> this 'fake changing RVs consist by subtype' idea is very clever
08:52:45 <andythenorth> but quite complex
08:56:41 <Rubidium> andythenorth: you seem to love Grace Hopper so much you should start a train set and introduce the Grace Hopper for transporting the cargo BUGS (bulk) from a farm to a food factory
08:59:39 *** Progman has joined #openttd
08:59:49 *** JVassie has joined #openttd
09:01:02 <planetmaker> things like ant farm -> food factory sounds like an excellent addition to toy climate :-)
09:01:06 *** BloodyRain2k has joined #openttd
09:02:46 <BloodyRain2k> I didn't change any settings but just used the Auto Updater 2 I had from longer ago so I guess something got messed up somewhere.
09:04:20 *** DayDreamer has joined #openttd
09:06:29 <andythenorth> Rubidium: that is the best suggestion in some time
09:07:34 <planetmaker> BloodyRain2k: same savegame?
09:07:40 <Rubidium> BloodyRain2k: do you have a savegame where it seems to misbehave?
09:07:49 <Rubidium> (so we can take a look at it)
09:07:54 <peter1138> ^ Grace Hopper transport BUGS +1
09:09:12 <andythenorth> where's Eddi|zuHause when he's needed? :P
09:09:48 <BloodyRain2k> It misbehaves like that everywhere, even on a server I joined
09:10:55 <Rubidium> there are many settings that influence going to depots, without knowing what the exact settings are you are using there is nothing that can be said about it
09:10:56 <BloodyRain2k> but going by your question it doesn't seem like I missed a change in the updates, not that I read them to begin with ^^;
09:12:02 <BloodyRain2k> I didn't change anything and to test the settings I just deleted them from my nightly version so it would recreate them with the defaults, still the same result. I'll upload the save from that now.
09:12:30 <andythenorth> I can't figure out how to stop the buy menu telling lies about tram capacity :\
09:15:31 <Rubidium> also, what "old" version and "new" version are we talking about?
09:16:41 <BloodyRain2k> Rubidium: 'old' version was 1.0.9 or something close to that, 'new' is 1.1.3
09:17:22 <andythenorth> the tram capacity when built is 80t. it has refits up to 225t
09:17:26 <andythenorth> buy menu shows 225t
09:17:35 <andythenorth> 225t != 80t, so that's going to annoy players
09:17:39 <Rubidium> 1.0.9 doesn't exist and closest would be 1.1.0 (mathematically at least)
09:18:14 <andythenorth> I tried faking the 80t capacity by putting it on the lead vehicle for buy menu only, but that results in an extra refit for every cargo
09:18:27 <Rubidium> BloodyRain2k: in any case, "breakdowns are disabled" and "servicing when breakdowns are disabled" is disabled as well, so they won't have any intention to go to the depot
09:18:53 <andythenorth> I tried running cb 16 during buy menu through the entire varact chain for wagons, but subtype seems to be ignored in buy menu, so I get max cap for each vehicle
09:19:32 <BloodyRain2k> Rubidium: I suspected that too and turned servicing on even if breakdowns are off to test it but they still didn't go in there. Afaik they should go into the depot if all station tracks are full. Atleast I remember it like that and they don't do that anymore.
09:19:36 * andythenorth wonders if default subtype can be forced
09:19:54 <Rubidium> in the Crumplewig savegame. In the Findtown savegame breakdowns are enabled and they go to the depot when needed
09:19:55 <Eddi|zuHause> just make a special callback for purchase list
09:20:26 <andythenorth> one varact, setting capacity according to position in consist?
09:20:57 <Eddi|zuHause> yes, something like that
09:21:07 <BloodyRain2k> Rubidium: weird, breakdowns aren't on for me there but even if I turn them on they ignore the depot.
09:21:11 *** DayDreamer has joined #openttd
09:21:27 <andythenorth> Eddi|zuHause: I'll try that thanks
09:22:42 <planetmaker> Rubidium: you've looked at the speed code extensively. Can you tell me in engine.cpp:368 - why is there a /2 when referencing this->u.road.max_speed ?
09:23:35 <planetmaker> or rather the *2 after the property was obtained, possibly via CB?
09:24:12 <BloodyRain2k> I think I'll get a completely fresh 1.1.3 and see if that behaves different than my current 1.1.3 (and I could swear there was a 1.0.9 somewhen, maybe not neccessarly as stable)
09:25:01 <planetmaker> there's never been a 1.0.9 anywhere
09:26:18 <andythenorth> Eddi|zuHause: I have a proposal for classes / refits
09:26:25 <Rubidium> planetmaker: you know trains are in 1/1.6 mph, right?
09:26:34 <andythenorth> - add a new flag for 'cargo is sensitive to aging'
09:26:39 <Rubidium> planetmaker: well, ships and RVs are in 1/3.2 mph
09:26:47 <andythenorth> - remove classes refrigerated, covered, armoured
09:27:02 <planetmaker> yes, that I found. sure
09:27:02 <andythenorth> - use cargo aging cb in conjunction with flag
09:27:06 <Eddi|zuHause> andythenorth: can't remove classes
09:27:16 <andythenorth> remove / deprecate in documentation /s
09:27:25 <planetmaker> Rubidium: but, internally the nfo value is stored for the properties, right?
09:27:26 <andythenorth> 'refuse to support' :P
09:27:40 <planetmaker> Or do I miss the conversion? I only found one for the aircraft speed
09:27:55 <Eddi|zuHause> andythenorth: that's useless as long as the default cargos have them
09:28:07 <andythenorth> Eddi|zuHause: mask out the bits :P
09:28:11 <planetmaker> as such I don't quite get why RV once use * 2 and the other time / 2 in that very line
09:28:25 <andythenorth> anyway, the point was the special flag + use aging cb for gameplay
09:29:00 <Rubidium> planetmaker: the nfo unit differs per vehicle type (well, ships and rvs are the same)
09:29:07 <andythenorth> transport gold by open wagon if you like, but it might suffer some....shrinkage
09:29:09 <Eddi|zuHause> andythenorth: sure, flag is useful
09:29:24 <planetmaker> yes. 1/1.6mph, 1/3.2mph and 1/8 mph
09:30:05 <Eddi|zuHause> planetmaker: RVs have two speed properties?
09:30:11 <Rubidium> so, to unify it to 1/1.6 you need to divide the 1/3.2 by two
09:30:46 *** Alberth has joined #openttd
09:30:46 *** ChanServ sets mode: +o Alberth
09:31:06 <planetmaker> return (max_speed != 0) ? max_speed * 2 : this->u.road.max_speed / 2; <<--- but here?
09:31:15 <planetmaker> Why once *2 and once /2 for road vehicles
09:31:27 <planetmaker> the preveious line uses GetEngineProperty to retrieve the speed
09:31:46 <Rubidium> planetmaker: what Eddi|zuHause said: there are two properties for RVs for speed
09:33:03 <andythenorth> Eddi|zuHause: declare 'classes v2', mark some as 'not available in v2', do nothing to enforce it in code, hope all is well? Nothing breaks, new / maintained sets stop having problems?
09:33:06 <Eddi|zuHause> one of these half-baked attempts at unifying things
09:33:16 <BloodyRain2k> Rubidium: ok, even in a completely fresh seperate 1.1.3 do my trains refuse to use a depot as overflow
09:33:35 <Eddi|zuHause> andythenorth: what's the achieved effect wrt to the 3 goals i put up?
09:34:58 <planetmaker> hm, ok, so the GetEngineProperty uses always the property 15... yes, then it makes sense. Thanks
09:35:05 <BloodyRain2k> Rubidium: uhm, somewhat refuse to, just now after a short waittime the train went into the depot... wth
09:35:08 <andythenorth> Eddi|zuHause: meets goal (1) by reducing number of classes, reducing likelihood of AND NOT collisions
09:35:11 <planetmaker> (or the CB does behave like prop. 15)
09:35:30 *** Biolunar has joined #openttd
09:35:54 <andythenorth> meets goal (2) by allowing vehicle set authors to offer vehicles that are advantageous for some cargos, this is same as 'suggestion' you describe
09:36:04 <andythenorth> goal (3) is met by labels anyway
09:37:04 <Eddi|zuHause> goal (3) means "don't use labels unless you have to"
09:37:49 <Eddi|zuHause> if "deprecate classes" means "you have to use labels for all default cargos", then goal (3) is failed
09:40:35 *** sla_ro|master has joined #openttd
10:07:11 <andythenorth> Eddi|zuHause: wrt (3) whether you *have* to use labels depends on the specific classes currently in use yes / no?
10:08:14 <andythenorth> so we'd have to keep armoured
10:10:10 <andythenorth> a vehicle set that *refused* to use refrigerated or covered would still transport all default cargos
10:11:49 <andythenorth> "let's make a *new* standard"
10:12:02 <andythenorth> then there can be two standards :P
10:23:56 *** Celestar has joined #openttd
10:26:55 * andythenorth always wanted to be an animator :P
10:27:15 <Alberth> doing your morning-exercises, andy ?
10:27:53 *** BloodyRain2k has joined #openttd
10:28:17 <BloodyRain2k> meh, chatzilla has it downsides, like when you forget about it and restart the FX due to memory shortage...
10:30:50 <Alberth> although I fail to see the advantage, why can't the train wait before the entrance signal?
10:32:01 <Alberth> I tend to add more platforms or build a holding place for waiting trains
10:34:42 <BloodyRain2k> I tend to use depots to store overflow, mostly due to side attached stations where's no space for waiting trains. And that setting is true and it still doesn't work.
10:39:28 *** valhallasw has joined #openttd
10:39:31 <Celestar> hacking cliffs into CmdTerraformLand seems wrong ..
10:40:47 <planetmaker> I can imagine functions where it's even more wrong ;-)
10:42:12 <planetmaker> something like there, yes
10:48:45 <Alberth> BloodyRain2k: isn't it a sign you have too many trains :)
10:49:24 <Celestar> I gotta think the whole terraform UI with this.
10:50:08 <BloodyRain2k> I prefer too much (atleast a few) than too few, in case the production steps up they can catch in, that's why. And building large scale for waiting space isn't just my thing. I miss this overflow feature ;_;
10:50:20 <Celestar> "raise land" on a corner usually raises all 4 adjacent tiles. What happens if this corner is on a cliff?
10:50:24 <BloodyRain2k> Alberth: and I keep forgetting the highlightings :3
10:50:34 <Celestar> should all of them be raised?
10:50:50 <Celestar> only the ones of the "selected" tiles?
10:50:59 *** JVassie has joined #openttd
10:51:01 <Celestar> remove the cliff if possible?
10:52:28 *** TGYoshi has joined #openttd
10:54:09 <Yexo> BloodyRain2k: are you sure that setting is not only true inyour config file but also in the savegame?
10:55:15 <BloodyRain2k> Yexo: very sure as I didn't change it and created quite a few new games already
10:56:56 <BloodyRain2k> Alberth: I could do that but I don't want, I want them to go into the depot only if they need maintance or the station's full (and they behaved like this before I updated)
10:57:36 <Alberth> Celestar: you probably want to keep the 'affect all selected tiles' semantics that we have now
10:58:23 <Alberth> BloodyRain2k: sorry, way too advanced for me, you need a real player :)
10:58:30 <BloodyRain2k> Yexo: fact is that I didn't touch a single setting after updating but just went on playing and was wondering why it didn't work anymore like before so something was changed with just the update.
11:00:08 <BloodyRain2k> Alberth: there's a work around I could use but that's prone to completely locking a terminal station and it only works with block signals: when I put a 2way combo signal before the depot it works like before but the space between the depot and it's signal can stuck in a train if there's a small green phase
11:00:27 <BloodyRain2k> or was it terminus... dunno, the ones that only have one end :3
11:01:03 <Yexo> BloodyRain2k: if you replace your presignal with a normal signal (like in the wiki image) it works fine
11:01:05 <Celestar> Alberth: yeah I think so as well.
11:01:06 <Rubidium> you still haven't shown us a savegame from the old version where "it" worked
11:01:51 <Celestar> Alberth: that still doesn't answer the question if you just raise one corner, which has, in the extreme case, 4 adjacent tiles of different heights.
11:02:44 <BloodyRain2k> Yexo: nope, ALL setups that should work don't, as if the depot has a way higher penalty than a red signal. Which is why I even tried a completely fresh 1.1.3 to check if there's something messed up but there it's like that too.
11:03:06 <Yexo> BloodyRain2k: I just confirmed in 1.1.3 that it worked
11:03:15 <Yexo> if it doesn't your settings are not default
11:03:22 <BloodyRain2k> Rubidium: I doubt that would change anything as I didn't change a single setting between 'old' and 'new' but I can dig in the old ones and see if I find one where it still works.
11:03:25 <Yexo> in other words: provide your config file / a savegame
11:05:29 *** Brianetta has joined #openttd
11:07:00 <Yexo> BloodyRain2k: I just tried your setup in 0.7.5 and the same result: the wiki example (with normal signal) works fine, your example (with presignal) doesn't
11:07:08 <BloodyRain2k> I guess the configs are really the problem, in the way that the game seems to have stopped using the openttd.cfg next to the exe... I removed that and it still had all settings and didn't create a new one.
11:07:44 <Yexo> try My Documents/OpenTTD/openttd.cfg
11:08:06 <Celestar> Alberth: well if you only select a single (cliffed) corner, just raise the one corner of the tile which is selected...
11:08:08 <Alberth> Celestar: I'd go for raise the corners of all 4 tiles, whether they are smoothly connected or not
11:08:50 <Alberth> In RCT you can select a tile or a corner
11:10:35 <Celestar> Alberth: yeah that's why I'm just trying to go for
11:10:48 <Alberth> BloodyRain2k: loaded games use the openttd.cfg only for client-side data (eg window settings and mouse interface, etc), all other settings always come (and always have come) from the save game
11:12:27 <BloodyRain2k> Yexo: yeah there it was, any way I can restrict it to the one next to the exe? About to test it with nuked settings now.
11:12:50 <Yexo> it should always use the config next to the exe if there is one
11:18:26 <BloodyRain2k> ah ok, so if there's none it starts using that one? good to know. anyways, nuked settings still don't make that work and yeah, I just reset that eol thing to true and started a new game and it still don't work.
11:18:58 <BloodyRain2k> I'll post the settings file I just used, there got to be the problem somewhere.
11:20:44 <BloodyRain2k> I'll dig through my old games now.
11:21:54 *** Adambean has joined #openttd
11:24:28 *** Cybertinus has joined #openttd
11:27:15 *** HerzogDeXtEr has joined #openttd
11:27:28 <Alberth> Celestar: I recently implemented such terrain changing code in FreeRCT (although it has no cliff-foundations yet), but I am still clueless about the UI, the RCT one seems very useless to me
11:32:03 <Celestar> Alberth: I'll keep that in mind :P
11:33:03 <Alberth> it's a nice puzzle :)
11:42:13 <Yexo> no, they will never turn green if both platforms are occupied
11:42:20 <Yexo> at least not in 0.7 or higher
11:44:04 <BloodyRain2k> mhm I think the one earlier may be right about 1.0.9 and I'm messing it up with a 0.9.x but still, now I think I know what it feels like if you question your own sanity...
11:44:19 <Yexo> there is no 1.0.9, nor any 0.9.x
11:48:23 <BloodyRain2k> bah whatever, then I'm going nuts, doesn't change much. Ok another thing then, is there an addon to make car removal add wagons in case the train gets shorter from new engines or wagons?
11:48:53 <Yexo> there is no general way to decide properly for all cases which wagon should be added
11:49:15 <BloodyRain2k> copy the first behind the engine? including fitting?
11:49:43 <Yexo> that might be a cab control wagon or something similar
11:49:51 <Yexo> or the only mail wagon in an othrewise passenger train
11:50:02 <BloodyRain2k> I mean I know that there are some packs that add 20 wagons that can transport the same 20 goods through fitting
11:50:31 <BloodyRain2k> I think if you're using multi good trains and that feature you can expect messing it up either way, because removal can eat that only mail or whatever wagon too :P
11:50:43 <BloodyRain2k> so don't come at me with that ^^
11:50:48 <Yexo> no, removal will always eat the last wagon
11:50:55 <BloodyRain2k> whatever, it remains the same
11:52:16 <BloodyRain2k> if it's removing the first wagon, starting from the back, that's not an engine (I just assume it won't remove tailing engines) then it could just go the same way through the train and copy the first wagon that fits that criteria
11:53:53 <Yexo> however the first wgon that fits the criteria might not be buildable anymore
11:54:53 <Alberth> or it may not be allowed at the new position
11:55:08 <BloodyRain2k> mhm true, in that case it could see which non engine wagons that can carry that good could fit in the gap. That should be possible, right? Don't know much about OTTDs code, just about general coding.
11:55:45 <Yexo> BloodyRain2k: sure, but such a wagon might have a lower maximum speed
11:55:57 <Yexo> or the newgrf might forbid attaching that wagon to the train
11:55:58 <Alberth> by Murphys law, the game will then pick the wrong one
11:56:10 <BloodyRain2k> Alberth: another point, but it's aware of that for upgrading already, because I had some trains that had an engine that allowed all wagons and wanted to upgrade to one that's restricted and it refused to do that since it would break the train.
11:56:21 <Alberth> and players start screaming "it is broken!!!"
11:56:26 <Yexo> or attaching such a wagon might triple the running cost for the front engine of the train
11:56:49 <BloodyRain2k> If you go that way Alberth you don't need to make any game at all because someone will always scream that ^^
11:57:54 <BloodyRain2k> yeah you got points but I think if you're using an auto feature you should be aware that there could arise problems, I'd take that if it would do a favorable choice in most cases. even if it'd only be half, I'd still have half of the work to fix.
11:58:26 <Alberth> BloodyRain2k: players now still have control, at the expense of a bit more work, which is why what you want is not implemented
11:58:33 <BloodyRain2k> If you ever played with different length wagon packs you know what a pain it can become to fill a gap that came from better wagons that were shorter
11:59:54 <Alberth> just replace the whole train?
12:00:43 <Yexo> BloodyRain2k: the length of wagons can depend on the train they're attached to
12:01:02 <Yexo> the game doesn't know this in advance (ie before it actually attached them)
12:01:35 <BloodyRain2k> I wish there'd be a 'refit train x to like train y' copying it whole except the orders. Yexo: ok that's indeed a problem.
12:01:48 <Alberth> BloodyRain2k: I started fixing this issue 3 times already, and got stuck in the code each time
12:02:52 <BloodyRain2k> Then how about a simple clone wagon button? That would still get rid of the going through the sometimes long list and refitting it properly (which you mostlikely forget)
12:04:46 <Alberth> it still has most of the problems mentioned previously, I think
12:05:34 <BloodyRain2k> mhm, if order linked trains could also link their setup it would reduce it even more. It would be just hard to define which's the source train of the change and which are not.
12:06:08 <Alberth> yep, you want groups in there too
12:07:06 <Alberth> but there is not even an object "train X" in the game currently
12:07:27 <BloodyRain2k> It would work, if a train differs from the layout it seeks out a favorable depot for changing and fits itself. That way you'd only have to fit one train and all linked ones will fit them self.
12:07:54 <BloodyRain2k> yeah ._. that's the point I'm failing at already without even knowing the limitations of the game
12:08:15 <Alberth> you cannot express a "layout" currently
12:08:58 <Alberth> only the vehicles actually used in the game exist, as a big bunch of vehicles
12:09:29 <BloodyRain2k> I guess you're trying to tell me the game can't 'ghost' a train just for it's layout in it's current state
12:10:36 <Alberth> to change it, you need to introduce a "train" concept (a bunch of related vehicles), which means a fundamental shift in how the vehicles are handled
12:10:44 <Alberth> a lot of code rests on that
12:11:13 <BloodyRain2k> Well we already got groups which I think can have individual refitting rules. Would it be possible to use the first train in that group as layout base for all others? I know you can sort them all ways but there should be a core order that could be used.
12:11:50 <BloodyRain2k> Like the default order by train number, I guess that's the core one.
12:14:28 <Alberth> I don't know. Personally, I consider groups useless, but ymmv
12:16:07 <BloodyRain2k> whatever ymmv is, I don't use groups much at all too. Almost never to be precise but shared orders are groups on their own, aren't they?
12:16:36 <BloodyRain2k> well I guess not, that list is missing the replace button.
12:17:05 <peter1138> they're sort of "implicit" groups
12:17:20 <peter1138> why have 1 way of doing things when you can have several o_O
12:17:22 <Alberth> ymmv = your mileage may vary = you may have a different idea about it
12:17:40 <Alberth> peter1138: less work :p
12:18:27 <BloodyRain2k> but it would be an approach way, wouldn't it? the first train in a shared order serves as layout basis and all others refit them self to be exact like that. Alberth: ah, that's it. peter1138: yup, simple lazyness ^^ but you don't like adding 1 wagon to 200 trains yourself either eh? :3
12:18:27 <Alberth> like 'instead of having a proper 'train' concept, use the first train in a group in core order
12:19:12 <BloodyRain2k> should be optional of course, I can imagine there are cases where it would cause havoc on mass
12:19:17 <peter1138> i wonder where my engine patch went
12:20:05 <peter1138> it lets you have wagons & engines in any order
12:20:07 <BloodyRain2k> I guess the best place for that 'setting' would be a "Keep first's layout" button in the shared order list
12:20:30 <BloodyRain2k> ah you mean like the engine at the end? or if you feel like it in the middle? ^^
12:20:34 <peter1138> as long as there's something with power (even if unpowered) it's a train
12:21:30 <BloodyRain2k> reminds me of that 'bug' where engines keep reversing at terminus stations but switch to the 'other end' of the train, that ticks me off everytime -.-
12:21:52 <BloodyRain2k> one reason I stopped building terminus stations...
12:22:08 <BloodyRain2k> well rather avoid it at all costs xD
12:23:13 <Alberth> oh, and you're not bothered about instant 45 degrees corners ?
12:23:32 <Alberth> or even 90 degrees :D
12:24:07 <Alberth> and the completely broken scales ? :D
12:25:12 <BloodyRain2k> I try to make 45° curves atleast 1.5 tiles long (since default's 0.5) and I never build 90° ones ^^ and if you mean by scales that the trains with 200 kmh are faster than a 900 kmh plane, not really, but a reversed engine at the head of a train yeah, that ticks me off :D
12:25:26 <BloodyRain2k> anyways what do you think about that shared order list approach Alberth, would that be from the accessing, usefulness and doability something good?
12:26:29 <Alberth> In my opinion, it is another piece of half-done fix that only makes solving it properly harder
12:27:17 <BloodyRain2k> sounds like a no : /
12:28:08 <BloodyRain2k> guess it's a big bunch of work, mostlikely even bigger than I imagine it since I don't even know the code
12:28:52 *** Cybertinus has joined #openttd
12:29:01 <Alberth> it pushes people into using things in a single particular way
12:29:19 <BloodyRain2k> anyways about my earlier overflow problem, I think it really was never working like I thought it was since I found an older save that was build to use it but the signals are different, the track rails have exit signals and there's no entrance but just a normal signal and there it works
12:29:44 <Alberth> as Yexo said a long time ago already ;)
12:30:07 <BloodyRain2k> yup, I just didn't figure it out that way until now xD
12:30:18 <BloodyRain2k> I was too distracted by feeling insane o,o
12:31:03 <Eddi|zuHause> wrt Celestar's GUI issue: make it a modifier button (like one-way, bulldozer, etc.)
12:31:28 <Eddi|zuHause> when set, the "dot" for heightlevel changes will not be on the tile border, but slightly shifted to one of the 4 tiles
12:32:12 <Eddi|zuHause> so the corner to be changed is chosen similar to how autorail decides the rail bit
12:32:56 <BloodyRain2k> btw <3 shared orders, one of the nicest things in ottd if you ever have to change something :D
12:33:21 <Arafangion> Maintaining them is a PITA, though.
12:34:30 *** andythenorth has joined #openttd
12:34:48 <Alberth> BloodyRain2k: shared orders should be a group concept
12:35:11 <andythenorth> Alberth: I thought you didn't discuss groups any more :)
12:35:56 <Alberth> I discuss against shared orders instead ;)
12:40:27 <BloodyRain2k> mhm, the yapf just prefered a straigth 45 straigth curve over a 45 45 45 (straigh towards the same tiles) one O.o
12:42:51 <planetmaker> a curve is a penalty
12:44:39 <michi_cc> andythenorth: I think you're over-complicating the whole cargo class thing (just like the BR set guys tend do *duckundweg* :). Add the include/exclude properties, rename/clarify some classes (i.e. mostly copy the table of Eddi), remove unused stuff (hazardous, and eGRVTS doesn't count, Zephyris is still around, and it's CC licensed) and maybe add non-pourable and powder or whatever.
12:45:59 <michi_cc> andythenorth: Then you can still argue a bit about adding classes to the currently defined cargoes. IMHO just do it and tell people complaining not to use five year old vehicle sets or live with the fact that they don't provide a vehicle for exotic cargo B.
12:47:09 <andythenorth> michi_cc: you just described what I want to do :P
12:47:13 <andythenorth> what's complicated about it :D
12:47:26 <BloodyRain2k> uhm yeah planetmaker, I explained it badly. I'll sketch it up on paste bin xD too lazy for paint.
12:47:56 <michi_cc> The fact that the backlog of the whole last week or so is nothing else except cargo classes? :p
12:48:06 <andythenorth> yeah, there is that :P
12:48:20 <andythenorth> who's in charge? :P
12:49:45 <planetmaker> yapf has no concept of curve length afaik
12:49:58 <planetmaker> thus: build properly ;-)
12:50:05 <BloodyRain2k> ah, thought it had since it had curve penalties
12:50:50 <planetmaker> a curve is just a thing like -/
12:51:05 <planetmaker> but not how much space between two consecutive ones
12:51:18 <BloodyRain2k> wonder if it'll learn that somewhen too
12:51:36 <planetmaker> otherwise: unlikely ;-)
12:53:49 <CIA-6> OpenTTD: rubidium * r23203 /trunk/ (6 files in 2 dirs): -Change: make locks more consistently looking (PaulC)
12:54:08 <SpComb> consistencify lock looks
13:00:49 <andythenorth> who actually is in charge of cargo classes?
13:01:02 <andythenorth> cos concensus on it is unlikely
13:01:32 *** JVassie_ has joined #openttd
13:09:49 *** JVassie has joined #openttd
13:26:05 <andythenorth> is cb36 used in the buy menu for trailing parts of an articulated RV consist?
13:26:19 <andythenorth> and if so, is var 40 (consist position) available?
13:27:30 *** Cybertinus has joined #openttd
13:28:56 <BloodyRain2k> meh whatever, ignore me -_- forgot the settings are saved in the save and that one got created with borked ones...
13:31:18 <andythenorth> wallyweb proposes having industries produce and accept based on lists of cargo classes
13:31:41 <andythenorth> so the industry would accept 'piece goods, bulk, liquid' etc
13:31:56 <andythenorth> and produce 'express, piece goods, refrigerated' for example
13:32:33 <andythenorth> but as that's not going to happen, /me will continue staring at tram code
13:32:49 <andythenorth> Eddi|zuHause: either your proposed solution for trams doesn't work, or I can't code :O
13:32:57 <andythenorth> evidence suggests the latter is more likely
13:34:16 <Alberth> such industry only makes sense for eg a warehouse imho
13:34:23 <b_jonas> andythenorth: so that's like how most transport companies actually work: they don't open the package they transport, so they don't know what really is in it, only their properties
13:36:11 <andythenorth> cb36 is available for articulated rvs in buy menu
13:36:16 <andythenorth> var 40 appears not to be
13:36:25 <andythenorth> there's nothing in the wiki about it
13:38:47 <BloodyRain2k> well I guess I'll free you of my presence, thanks for all the help and sorry for the trouble, hf whatever you're doing now :D
13:40:24 <Arafangion> Alberth: You're describing "goods".
13:42:18 <andythenorth> what would cause a varact 2 to return whatever range is first checked?
13:42:22 <andythenorth> irrespective of the value
13:46:22 <Yexo> using an invalid variable
13:47:01 <Alberth> I did? I thought I just argued against having all industries accept anything with certain properties
13:47:37 <andythenorth> I should have read the var table, not the description (in the wiki)
13:48:20 <b_jonas> so a power station should accept anything burnable, including mail?
13:48:41 <andythenorth> so the only fix I can think for trams is to change the order of subtypes
13:48:50 <Yexo> andythenorth: and var 40 is inded not availble in the buy menu
13:48:58 <planetmaker> mail: yes. witches: no ;-)
13:49:19 <andythenorth> Yexo: is that by design, or lack of implementation?
13:49:57 <b_jonas> how about wood? that also floats on water.
13:51:25 <andythenorth> does anyone other than me care that the buy menu lies about HEQS tram capacity? Maybe it doesn't need fixing
13:51:45 <andythenorth> reports (e.g.) 300t, builds 80t
13:54:05 <andythenorth> silence is the same as nobody cares :)
13:54:27 <andythenorth> I _could_ split the vehicle IDs for the trailing vehicles, so there are two kinds of wagon
13:54:38 <andythenorth> one is built at 0 cap, the other at FOO cap
13:54:57 <andythenorth> then vary the cb16 return values for building articulated vehicle
13:55:42 <andythenorth> seems like a bit of an arse about though
13:57:28 * Alberth never played with HEQS trams so far
13:57:53 <planetmaker> they're well worth it :-)
13:59:04 <Alberth> I have no doubt about that. I just do too many different other things
14:05:55 <andythenorth> what can cause a vehicle to have capacity, but not load?
14:06:16 <andythenorth> this is quite maddening :P
14:09:00 <andythenorth> for the record, the answer is: setting the load amount to 0
14:09:56 <andythenorth> just in case anyone else ever spends an hour with that problem :P
14:14:25 * andythenorth thinks wallyweb has quite a fundamental misunderstanding of how cargos work :O
14:15:13 <Alberth> NewGRF has so many traps built-in :)
14:15:47 <andythenorth> Alberth: that's the fun part :)
14:15:57 <andythenorth> if it was easy, I'd be bored
14:16:20 <Alberth> so either you are bored or you are crazy :p
14:17:00 <Alberth> for your sake, /me hopes XOR
14:17:06 * andythenorth writes the embarassing "here's a new version because I screwed up" changelog :P
14:17:43 <Alberth> ever counted the number of "-Fix:" in the openttd repo? :)
14:21:33 <Yexo> or looked at the changelog for any x.y.z version for z > 0?
14:22:24 *** SystemParadox has joined #openttd
14:27:05 *** andythenorth is now known as Guest16899
14:27:05 *** andythenorth_ has joined #openttd
14:27:05 *** andythenorth_ is now known as andythenorth
14:28:53 *** andythenorth is now known as Guest16900
14:28:53 *** andythenorth_ has joined #openttd
14:28:53 *** andythenorth_ is now known as andythenorth
14:46:35 *** andythenorth is now known as Guest16902
14:46:35 *** andythenorth_ has joined #openttd
14:46:35 *** andythenorth_ is now known as andythenorth
14:47:35 *** andythenorth is now known as Guest16903
14:47:35 *** andythenorth_ has joined #openttd
14:47:35 *** andythenorth_ is now known as andythenorth
14:48:44 *** andythenorth is now known as Guest16904
14:48:44 *** andythenorth_ has joined #openttd
14:48:44 *** andythenorth_ is now known as andythenorth
14:49:25 <andythenorth> stupid router is flapping :\
14:50:34 <MNIM> better than fapping, I suppose.
14:59:27 *** KritiK_ has joined #openttd
15:05:07 *** KritiK_ is now known as KritiK
15:54:52 <planetmaker> andythenorth: looIRS #3235: in principle vehicle set authors can always create situations where a cargo is NOT transportable
15:55:14 <andythenorth> yup, but it's a game of probabilities ;)
15:55:26 <planetmaker> Thus by providing only three classes for (FIRS-specific) cargos, would possibly make non-transportability less of an issue but not completely remove it
15:55:36 <planetmaker> Though probably completely removing it, will never be feasible
15:55:46 <planetmaker> so, yes, game of probabilities
15:56:01 <andythenorth> that, combined with Eddi's proposal that AND NOT (piece, bulk, liquid) is out of spec would help
15:56:14 <andythenorth> although AND NOT express could still cause problems
15:56:27 <planetmaker> you mean the suggestion as on the user page in the spec wiki?
15:57:09 <andythenorth> apart from I 100% disagree about adding even more classes, I agree with the rest of that proposal
15:57:24 *** panna_ is now known as virrpanna
15:57:48 <planetmaker> what's the rest? The change of classes for existing cargos?
15:58:00 <planetmaker> s/cargos/cargo labels/?
15:58:43 <andythenorth> ok I'll read it and be more precise :)
15:59:19 <planetmaker> From what I remember, it's two (main) things he suggests:
15:59:43 <planetmaker> a) the re-definition of the classes. Which basically the same as adding two new ones
15:59:55 <planetmaker> And clarifying the descrition of a few others.
16:00:13 <planetmaker> Air fright is IMHO a bad naming though. Wonders happen, but I do agree with mb there
16:00:24 <andythenorth> adding classes -1
16:00:29 <andythenorth> changing existing labels -1
16:01:02 <andythenorth> specifying that 'never exclude' applies to a number of the classes +1
16:01:26 <andythenorth> noting that hazardous 'is not in common use' +1
16:01:58 <andythenorth> example schemas for sets +1 (although I disagree about the detail of the classes)
16:02:14 <planetmaker> all agreed. maybe "adding classes +/- 0" from my POV
16:02:59 <andythenorth> for vehicle sets, I'm going to refuse to use 'extra' classes, possibly including refrigerated. That's not controversial because vehicle set authors can do that.
16:03:15 <andythenorth> for FIRS it's highly controversial to do the same :(
16:03:19 <andythenorth> but I think it's the correct route
16:03:50 <andythenorth> extra = hazardous, oversized, covered, powdered, not pourable
16:03:55 <andythenorth> possibly refrigerated
16:04:06 <andythenorth> I'd say armoured too in FIRS case
16:04:26 <andythenorth> I'm now convinced these classes are not helping the situation
16:05:59 <michi_cc> Except for explicit cargo labels the extra classes are the only way to differentiate vehicles more than open wagon/closed wagon/tanker. And explicit labels are obviously only for cargoes defined in the past.
16:06:15 <andythenorth> so my proposal is simply to ignore them :)
16:07:45 *** LordAro has joined #openttd
16:07:46 <andythenorth> if other people want them, there's nothing to stop them being used
16:07:52 <andythenorth> nobody controls the spec
16:09:41 <michi_cc> So all vehicle set authors that want to provide FIRS compatibility (with more than those three base wagons) will be forced to explicit include/exclude/XOR lists and need to maintain them every time you decide to change a cargo again?
16:10:38 <andythenorth> that's going to happen either way
16:11:16 <peter1138> best version number ever :D
16:12:08 <andythenorth> michi_cc: the only significant information there is "every time you decide to change a cargo again?" :P
16:12:37 <andythenorth> so the answer to "classes don't work" could be "industry authors may never change a cargo, neither it's classes, nor the labels, nor anything at all" ;)
16:14:18 * andythenorth really regrets that the FIRS cargo labels were published. It would have been much better to keep cargo information private.
16:15:25 <michi_cc> Classes do work, there's nothing fundamentally wrong with the current cargo classes. Some names and descriptions can be clarified, and a guide for when to use as OR and when to use as AND NOT added. The only real problem is the XOR property which makes changing classes difficult, but other than that, while some vehicle sets/industry sets may use classes wrong, all other "problems" are simply bugs in the set just like a wrong sprite alignment is.
16:15:47 <Eddi|zuHause> andythenorth: you're kinda contradicting yourself there. if you do not want your labels published, set designers _must_ depend on classes
16:15:50 <michi_cc> That's not a failure of the conecpt.
16:16:15 * peter1138 ponders a YAIM network game
16:16:42 <Eddi|zuHause> michi_cc: i agree there
16:17:18 * andythenorth is running out of arguing :P
16:18:11 <andythenorth> why do vehicle set authors get to control what's in an industry set, is the fundamental problem I can't get past
16:18:31 <andythenorth> it totally limits the ability to design a decent set
16:19:02 <andythenorth> I want to make good things, not crappy things
16:19:51 <ABCRic> use ALL the vehicle sets!
16:21:04 <michi_cc> andythenorth: Somehow you're the only one having a problem there. You set your classes properly (i.e. always at least one base class, maybe some extra classes) and if somebody comes complaining that ABC vehicle set can't carry Hubba Bubba, you tell them you don't care about bugs in other vehicle sets.
16:21:39 <andythenorth> michi_cc: that would be nice if it was a clean sheet of paper ;0
16:21:53 * andythenorth ponders FIRS Renewal
16:22:31 <andythenorth> adding classes: allowed
16:22:40 <andythenorth> but may cause refit explosions
16:22:45 <andythenorth> removing classes: not allowed
16:22:52 <andythenorth> changing labels: not allowed
16:23:01 <andythenorth> result: industry set that cannot be improved
16:25:01 <Yexo> <andythenorth> changing labels: not allowed <- where did you get that from?
16:25:11 <Yexo> new label = new cargo = set classes however you want
16:25:19 <Yexo> special support for the new cargo doesn't exist
16:25:24 <michi_cc> For FIRS specific cargoes removing classes is allowed. You might make some GRF authors unhappy that did explicit FIRS support, but that's all that happens (as long as you don't do it every second week).
16:25:29 <andythenorth> yes it does, because people rely on the XOR
16:25:32 <Yexo> it only removes specific refitting for special cargos
16:25:58 <Yexo> andythenorth: that only brings us back to: nobody should allow on the XOR, only on specific inlcude/exclude masks
16:26:02 <Yexo> than the problem is gone
16:26:36 <peter1138> if you change your cargos
16:26:39 <andythenorth> Do I have to care because I'm required to maintain a stable API? Yes
16:26:48 <peter1138> tell the authors of sets who use them :p
16:26:55 <Yexo> <michi_cc> For FIRS specific cargoes removing classes is allowed. You might make some GRF authors unhappy that did explicit FIRS support, but that's all that happens (as long as you don't do it every second week). <- but you might "break" those sets in the sense that suddenly no vehicle can transport a certain cargo
16:27:15 <andythenorth> It's really frustrating that I've had the requirement to maintain a stable API imposed upon me
16:27:18 <Yexo> if a cargo was explicitely included from some wagons and (implicitely, via cc mask) include in another
16:27:40 <peter1138> so, anyone for a YAIM game with FIRS, HEQS, ETCS
16:27:40 <michi_cc> Yexo: Of course, I just don't think this is the end of the world.
16:28:05 <andythenorth> michi_cc: some people do, and there's no spec :P
16:29:48 <michi_cc> peter1138: Didn't you have a patch for include/exclude property? Just commit that stuff so we can move on at least some thous :)
16:30:06 <peter1138> is it what's needed?
16:30:26 <Yexo> as far as I can see it'd solve all current practical problems
16:30:27 <andythenorth> peter1138: it works for me
16:30:37 <peter1138> (also i unconventionally made it a common prop instead of assigning the next two properties for each vehicle class
16:30:49 <Yexo> the rest is theoretical babble habout how classes don't fit every cargo and are not realistic however you define them
16:30:54 <andythenorth> we can then say that sets using the old method are not guaranteed any support
16:31:14 <Yexo> andythenorth: nobody was ever "guaranteed" any support at all
16:31:29 <peter1138> imho, classes were always a fallback system
16:31:44 <andythenorth> which is completely at odds with the other prevailing view
16:32:02 <peter1138> michi_cc, is YAIM commitable yet? :D
16:32:16 <Yexo> due to the current limitation of specific refit support only for the first 32 cargos classes currently are more than a fallback system
16:32:20 <peter1138> Recticulating splines
16:32:21 <Yexo> your patch would fix that
16:33:09 <michi_cc> peter1138: A common prop probably makes sense, I always wondered why nobody reserved space for them. Maybe start at 80 or so though, just in case so we don't get common-specific-common-specific etc blocks in the end.
16:33:09 *** TWerkhoven[l] has joined #openttd
16:35:20 <michi_cc> peter1138: No idea, so far people were only bitching how this or that would destroy the game (without actually having played anything), but nobody made any suggestions for the base costs in src/table/pricebase.h (or the maintenance multipliers for the default rail types and airport types). As I pulled these numbers totally out of the air, I'd be quite surprised if they really would make sense :p
16:35:35 <peter1138> andythenorth, CHIPS has awesome buffer stops
16:37:51 <peter1138> andythenorth, i can actually see them at 2x ;)
16:38:34 <andythenorth> did you commit EZ yet? :P
16:39:11 <andythenorth> peter1138: the new props have a length byte at the start of the list?
16:40:23 * andythenorth hopes we can teach nforenum to count :P
16:40:43 <peter1138> yexo said that's easier than a nul terminated list
16:41:18 <andythenorth> otherwise we'll have to teach andythenorth to count
16:45:30 <peter1138> cool, i can build roads without fences disappearing
16:50:01 <Eddi|zuHause> andythenorth: the problem with counting is that you need a syntactical method to mark the end of the list
16:51:47 <andythenorth> like industry layouts?
16:52:15 <Eddi|zuHause> no idea about those
16:57:50 <andythenorth> they have a delimiter byte
16:58:26 <Eddi|zuHause> more like an escape sequence
16:58:37 <andythenorth> two bytes for industry layouts /s
16:59:20 <planetmaker> uh, sorry, was on the phone
16:59:43 <planetmaker> summary as I read it:the xor by label should be deprecated.
17:00:05 <Eddi|zuHause> so you'd write something like "<action 0> <...> 40 00 \0l 01 02 03 ... XY \0r <...>"
17:00:13 <planetmaker> explicit support for a label via a new property desired
17:00:22 <planetmaker> maybe explicit support to NOT support an specific cargo
17:00:29 <planetmaker> via another property
17:00:32 <planetmaker> all issues solved then?
17:01:30 <planetmaker> sounds fine to me this or these properties
17:01:45 <planetmaker> I'm not 100% positive on the exclude property, but I won't bitch about it ;-)
17:02:27 <Eddi|zuHause> andythenorth: then nforenum could count all bytes between "\0l" (left) snd "\0r" (right) and fill in the number in the byte left of "\0l"
17:02:52 <Eddi|zuHause> andythenorth: these markers would not have a representation in the final grf
17:03:08 <Yexo> actually it's quite easy to supprot both (prefix length-byte or FF terminated list)
17:03:15 <Yexo> 0-terminated doesn't work because 0 is a valid index
17:04:18 *** HerzogDeXtEr has joined #openttd
17:06:32 <Yexo> first byte is number of indices to follow, every index is a byte
17:06:45 <planetmaker> allow refit by label?
17:07:22 <z-MaTRiX> someone know-of a function of a square in usable form?
17:07:32 <planetmaker> or rather by ctt-entry?
17:11:04 <Eddi|zuHause> planetmaker: excerpt from yesterday:
17:11:07 <Eddi|zuHause> [12.11.2011 12:44] <Eddi|zuHause> Yexo: it appears to work, but i'm not entirely sure about correctness. www.informatik.uni-halle.de/~krause/nml_move_bytelistprop.diff and www.informatik.uni-halle.de/~krause/nml_ctt_lists.diff
17:11:08 <Eddi|zuHause> [12.11.2011 12:45] <Eddi|zuHause> accompanying CETS diff: www.informatik.uni-halle.de/~krause/cets_ctt_lists.diff
17:11:30 * planetmaker looks. Thx. Missed that
17:11:37 <andythenorth> I didn't test any edge cases
17:11:44 <CIA-6> OpenTTD: rubidium * r23204 /trunk/src/ai/api/squirrel_export.awk: -Fix (r23201): if you rename a constant, then also rename it in the helper scripts that use it
17:17:57 * andythenorth tries patching nforenum
17:18:55 <Eddi|zuHause> planetmaker: in nml, you can give a list of labels
17:19:11 <planetmaker> yes, that's what I'd assume :-)
17:19:26 <planetmaker> but the patch uses ctt-entries, it seems
17:19:33 <planetmaker> which is good enought, too, I guess
17:19:52 <Yexo> planetmaker: in nml, a label (when it's defined in the CTT) is a constant with as value the index in the CTT
17:20:42 <planetmaker> seems after we made all newgrfs which use tiles incompatible with stable OpenTTD we now make all vehicle sets incompatible with stable openttd ;-)
17:20:46 <Eddi|zuHause> the variable name is probably subject to change
17:21:20 <Eddi|zuHause> CETS was never compatible with any stable openttd
17:21:44 <planetmaker> not that. But heqs, fish, ogfx+trains, ogfx+rv
17:22:01 <planetmaker> cets is too advance to think of that :-)
17:22:01 <Eddi|zuHause> there'll be a next stable openttd :)
17:22:12 <planetmaker> pehw. Lucky us :-)
17:23:59 <andythenorth> planetmaker: HEQS incompatible? not yet...
17:25:43 <andythenorth> Yexo: nforenum patch is happy with props 0x40 and 0x41
17:25:52 <planetmaker> :-) But I see you getting it incompatible, andythenorth ;-)
17:27:03 <andythenorth> planetmaker: certainly that's my plan
17:27:29 <andythenorth> maybe it's a good thing that bananas has no way to provide the newest grf compatible with your ottd
17:27:34 <andythenorth> maybe it causes upgrading
17:27:48 <andythenorth> Yexo: I only tested for RVs, I assume it works for the others
17:28:17 <Yexo> yes, it was copied-pasted between vehicle types
17:28:43 <planetmaker> is the new trend to give the same feature the same property number? :-)
17:29:14 <Eddi|zuHause> i really hope so
17:29:54 <andythenorth> keeping them different means frequent wiki trips
17:30:01 <andythenorth> frequent wiki trips is good
17:31:00 * Alberth ponders changing the spec based on creation date of the newgrf
17:32:58 * andythenorth ponders changing spec based on random numbers
17:33:52 <planetmaker> much better is file creation date
17:34:07 <andythenorth> we could...you know...use like....versions and stuff
17:34:20 <andythenorth> I propose the number 7 for the spec most people are using
17:34:26 <andythenorth> and maybe 8 for a new one?
17:34:33 <andythenorth> might as well keep them in order :P
17:34:57 <Alberth> sounds like a plan ;)
17:35:03 <andythenorth> incidentally does *anyone* understand Wallyweb's proposal for cargos?
17:35:10 <andythenorth> I'm fairly certain Wallyweb doesn't
17:41:44 <planetmaker> I didn't quite understand his point. Maybe it's a language thing
17:44:12 <Eddi|zuHause> i'm fairly sure it doesn't have anything to do with what we're discussing
17:46:56 <andythenorth> afaik there are only two questions remaining about classes
17:47:17 <andythenorth> (1) if I change classes in FIRS, am I required to ship a new label (MB thinks no btw)
17:47:29 <andythenorth> (2) should Eddi's proposal for extra classes be adopted
17:48:34 <peter1138> i'm pretty sure wallyweb doesn't know the technical side of what's being discussed
17:49:26 <planetmaker> with the current system a change in classes of a cargo means new label.
17:49:59 <planetmaker> The "sane" way mb talks of in his posting is something which he must have kept to himself. What ECS did was not really sane with the change of classes
17:50:14 *** BloodyRain2k has joined #openttd
17:50:19 <planetmaker> as it breaks existing newgrfs to do so. As the nasty xor property exists
17:50:53 <andythenorth> but did the spec ever guarantee that wouldn't happen?
17:50:58 <Eddi|zuHause> planetmaker: afaik ECS only added newly defined classes to the cargos.
17:50:59 <planetmaker> a new label doesn't break them
17:51:25 <andythenorth> I am fine to break sets, or change labels, I just don't want a massive argument *after* I've written whatever code I have to write ;)
17:52:19 <andythenorth> labels are shared *across* sets, so changing their classes seems less correct (I don't particularly care about the breaking vehicle sets)
17:53:06 <planetmaker> Still, I'd not have used it as a 100% iron-clad rule
17:53:21 <planetmaker> I'd silently (or not so silently) have changed the classes of SCRP
17:53:34 <andythenorth> that one was a stupid case anyway, because the wiki was wrong
17:53:36 <planetmaker> It's FIRS only so far
17:53:44 <andythenorth> all I did was bring the code in compliance with the wiki :P
17:54:02 <andythenorth> that change underlines how bonkers the XOR effects are :P
17:54:08 <Yexo> BloodyRain2k: savegame please
17:54:41 <andythenorth> planetmaker: "It's FIRS only so far" <- except we don't know who in Brazil, or Poland, or Russia or whatever is using it in their set
17:55:05 <andythenorth> their *appears* to be russian and hungarian and polish efforts for example that don't participate in this community :)
17:55:10 <andythenorth> their / there /s
17:56:46 <Eddi|zuHause> BloodyRain2k: a key element in overflow depots is the pathfinder penalties. in your case, when the "firstred exit penalty" is lower than the "go through depot" penalty, the overflow depot won't work anymore
17:57:10 <Eddi|zuHause> BloodyRain2k: you'll probably find that if you shorten the tracks to the depot, it will start to work
17:59:46 <Eddi|zuHause> BloodyRain2k: i don't have your savegame, so i can't check the values, but you have three options: 1) keep the depot detour short, 2) increase firstred_exit_penalty or decrease depot_penalty(whatever its actual name) in the console, or 3) set firstred_twoway_eol to true
18:00:58 <planetmaker> the latter was in early OpenTTD versions the default
18:01:13 <planetmaker> which might result in (old) wiki pages relying on it to be true
18:01:51 <BloodyRain2k> Yexo: reproduceable with default values, just did that now. Eddi|zuHause: firstred_twoway_eol is already true but I'll try the other things. planetmaker: yeah I got already made aware that I have to manually set that for each new config I make for trying.
18:02:33 <BloodyRain2k> Eddi|zuHause: could that depot one be the rail_depot_reverse_penalty? since that's the only depot one I see currently
18:07:29 <andythenorth> planetmaker: we missed a consolidation in FIRS: WOOL and FICR are both 'natural fibres' :o
18:07:44 <andythenorth> and it would make almost no difference to gameplay to consolidate them I think
18:08:21 <andythenorth> maybe a bit of the charm might be lost, I find wool appealing for some reason
18:09:35 <planetmaker> FICR is fibre _crops_ while (sheep) wool is not a crop :-)
18:09:46 <planetmaker> Yes, having wool is charming :-)
18:10:11 <Eddi|zuHause> planetmaker: compare "(Schaf-)Wolle" and "Baumwolle"
18:10:15 <andythenorth> they're all natural fibres...but yes
18:10:27 <BloodyRain2k> Ah ok, works with that longer buildway if that depot penalty is 0, tried 1000 before since it's 5000 by default but 1000 still didn't make it work. Thanks Eddi|zuHause :3
18:10:29 <andythenorth> there's no reason to remove them
18:10:49 <planetmaker> Eddi|zuHause: yes? FICR still doesn't fit then to WOOL
18:10:54 <BloodyRain2k> although I wonder what I've now broken on the other side since it wouldn't be set to that by default for no reason...
18:10:58 <planetmaker> compare wool and cotton, Eddi|zuHause ;-)
18:11:02 <andythenorth> planetmaker: new label NFBR
18:11:07 <Eddi|zuHause> planetmaker: i know :)
18:11:17 * andythenorth is not proposing doing this btw
18:11:25 <andythenorth> just mentioning it's possible
18:11:48 <Eddi|zuHause> planetmaker: "cotton" is an arabic loan word, while "Baumwolle" is one of those pragmatic german word creations
18:15:50 <planetmaker> I'd not be too thrilled to change that all
18:16:22 <andythenorth> planetmaker: do you want to leave comments? Better thought left to brew I think
18:16:25 <planetmaker> I still think that the classes of covered, refrigerated make sense
18:16:54 <planetmaker> in the "and not" property
18:16:54 <Eddi|zuHause> andythenorth: i'm currently inclined to just leave cargos alone, only clarify the classes, and rules for vehicle creation that ensures all possible combinations of classes will be supported
18:17:17 <planetmaker> and add the prop. 40,41
18:17:28 <BloodyRain2k> meh whatever, I'm starting to hate overflow depots because they hate me -.- firstred exit penalty is 20k, depot reverse penalty is 0, twoway eol is true and that train still doesn't go into it.
18:17:40 <BloodyRain2k> anyways thanks again
18:17:48 <Yexo> BloodyRain2k: I've never had the need for overflow depots, why do you need them at all?
18:17:59 <andythenorth> FWIW, if FIRS was a solo set, I'd make the changes and live with the consequences
18:18:04 <Yexo> to me it looks like that as soon as you need one you have too many trains, so you should stop/sell one
18:18:27 <andythenorth> however /me does not fancy trying to maintain FIRS alone :o
18:20:29 *** KenjiE20 has joined #openttd
18:21:49 <planetmaker> but, andythenorth, many of those labels are not FIRS' labels alone...
18:22:25 <BloodyRain2k> I just like to have atleast one spare waiting in there to not get a gap if the production should raise for some reason, that's all. And they are more compact than waiting lines. I guess I'll get used to forced overflow ones as optional ones are too much of a damn pain to have them working
18:22:29 <planetmaker> iirc FISH, BEER, CLAY, BDMT all are multi-set labels
18:22:57 <andythenorth> planetmaker: we'd have to split labels
18:22:59 <Yexo> BloodyRain2k: just create another platform for you station instead?
18:23:06 <Yexo> that also allows you to have an extra train waiting
18:23:25 <andythenorth> the point I should make is that it seems we either go for minimal classes, or we adopt the full proposal by Eddi|zuHause
18:23:49 <andythenorth> Eddi|zuHause + me have been around the classes enough that I think the current 'extra' ones are basically half-assed
18:23:56 <andythenorth> and broadly not useful
18:24:17 <planetmaker> they are useful. In the "and not" category
18:24:30 <andythenorth> 'covered' in particular has zero information content imho, as any vehicle can provide a cover, and many sets do
18:24:46 <planetmaker> Thus eddi's suggestion is - as you outlined earlier - a good one by large parts
18:25:01 <andythenorth> the classes proposed by Eddi|zuHause are what is needed if we want to enable detailed class-based vehicle control
18:25:02 <planetmaker> open hopper: bulk and not covered
18:25:08 <planetmaker> problem solved. use case found
18:25:33 <BloodyRain2k> Yexo: yeah I'm aware of that, but overflow depots let you keep a few ready without having to do that if there's no more space for example. If now a 4 line station has an amount of trains running smooth near the main line and the production goes down your trains end up blocking.
18:25:55 <planetmaker> really, andythenorth, the classes are not a problem. Just the clarifications how vehicle sets shall use them
18:26:05 <Eddi|zuHause> planetmaker: not entirely sure whether that is a "realistic" use case
18:26:08 <BloodyRain2k> I know that that would then be called a bad layout probably but there's not always space for all these waiting lines and etc.
18:26:10 <planetmaker> if they don't not your problem, but vehicle set bug
18:26:23 <planetmaker> Eddi|zuHause: realistic or not, I don't mind ;-)
18:27:14 <andythenorth> planetmaker: you just prevented UKRS 2 and NARS 2 carrying clay, grain etc for most of the set's lifetime with that example
18:27:17 <andythenorth> classes == fallback
18:27:27 <z-MaTRiX> what is your opinion about functional polymorphism in C ?
18:27:32 <Eddi|zuHause> a purely academic set of wagons that doesn't have any "real" vehicles in mind is probably not a good goal
18:27:35 <andythenorth> (I don't mean to say we support specific sets backwards, they're just examples)
18:27:58 <Eddi|zuHause> or maybe that's exactly the problem
18:28:01 <planetmaker> andythenorth: if ukrs and nars don't support clay, it's a bug there
18:28:14 <andythenorth> or it's a bug in the provision of classes as a fallback :P
18:28:19 <andythenorth> or it's a bug in the goal
18:28:29 <Alberth> z-MaTRiX: it looks plain ugly
18:28:41 <planetmaker> and you thus try to topple over everything with classes etc, because of clay in those two sets?!?!
18:28:54 <Eddi|zuHause> z-MaTRiX: relying on "true"=="1" in arithmetic expressions is imho bad style
18:29:06 <andythenorth> I'm trying to retrieve classes from a current dumb position
18:29:16 <andythenorth> either they're detailed, or fallback, but currently they fail both
18:29:17 <Alberth> z-MaTRiX: a=(i>=b)?c:d
18:29:17 <Eddi|zuHause> use (i>=b)?c:0 instead
18:29:22 <andythenorth> we should decide :P
18:30:21 <planetmaker> andythenorth: I think the decision is clear: update class description. Issue solved
18:30:36 <andythenorth> Eddi|zuHause: ^ does that meet your case for detailed control?
18:30:37 <planetmaker> no further action required for industry sets
18:30:42 <andythenorth> i.e. no new classes
18:31:23 <andythenorth> no 'powderised', no 'not pourable'
18:31:58 <Eddi|zuHause> andythenorth: we can decide on one without deciding on the others
18:32:02 <z-MaTRiX> Alberth<< ok, how about a more complex problem?
18:32:36 <Eddi|zuHause> andythenorth: we can clarify the uses of classes without adding new ones, but we can also decide on new ones after we clarified the existing ones
18:32:52 <andythenorth> it would seem better to clarify current first
18:33:17 <andythenorth> Eddi|zuHause: what would happen if you shipped your proposal to the wiki?
18:33:52 <Alberth> z-MaTRiX: the problem with source code is how to write the code clear, which is a different problem from writing it as short as possible
18:34:13 <z-MaTRiX> well yes, but for example i can have 1 loop instead of 4
18:34:29 <z-MaTRiX> that is mainly redundant
18:34:29 * planetmaker would ask frosch about it (again) when he's back
18:35:15 <Eddi|zuHause> andythenorth: the wagon-section is more tutorial-style, so has no influence on actual specs. the class tile needs reducing of the new classes, and needs a consensus of the express class
18:35:55 <planetmaker> Eddi|zuHause: still, the wagon suggestion might still have a place there on the classes page
18:36:06 <Alberth> z-MaTRiX: perhaps you need a smarter way to decide the sequence to iterate over?
18:36:07 <planetmaker> As it gives vehicle authors the idea how to use them
18:37:31 <Eddi|zuHause> planetmaker: i think "tutorial/tips - cargo classes for vehicle sets", "tutorial/tips - cargo classes for industry sets" and linking both from the cargo class page
18:37:45 <planetmaker> that's also feasible
18:38:08 <planetmaker> you could implement that anyway :-)
18:40:07 <z-MaTRiX> Alberth<< yeah i'm on it ;)
18:40:09 <andythenorth> wallyweb just describes the current system, minus labels
18:40:13 <andythenorth> maybe he's right :)
18:41:07 <andythenorth> no explicit refitting at all :o
18:41:31 * andythenorth suspects we'd end up with classes like 'wood', 'tropical wood', 'sawn wood' :P
18:43:24 * andythenorth resists the obvious
18:45:32 <CIA-6> OpenTTD: translators * r23205 /trunk/src/lang/ (estonian.txt italian.txt portuguese.txt welsh.txt):
18:45:32 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:32 <CIA-6> OpenTTD: estonian - 8 changes by Jaanus
18:45:32 <CIA-6> OpenTTD: italian - 3 changes by Snail_
18:45:32 <CIA-6> OpenTTD: portuguese - 24 changes by ABCRic
18:45:34 <CIA-6> OpenTTD: welsh - 34 changes by kazzie
18:46:03 <Eddi|zuHause> i think the "obvious" stuff that andythenorth talked about involves the word "morning" :p
18:46:47 <andythenorth> generally that sort of thing is best left to #tycoon or whatever it's called
18:47:13 <andythenorth> Eddi|zuHause: my 2p, express is express. It's a fact on the ground, it pragmatically works
18:47:21 <andythenorth> nobody likes it, lots of people use it though
18:48:56 * andythenorth ponders having a cargo define a list of labels, not just one label
18:49:04 <andythenorth> maybe that's what frosch's suggestion was :o
18:49:23 <andythenorth> they share one name string
18:49:30 <andythenorth> could suck in gameplay though
18:49:37 <andythenorth> feeder systems would be horrible to setup
18:50:26 <Eddi|zuHause> frosch's suggestion was loosely based on my lengthy discussion with MB about railtype compatibility
18:51:51 <andythenorth> lists of labels would address composite cargos like BDMT
18:52:17 <andythenorth> could be a list of BRCK, CEMT, LMBR etc
18:53:17 * andythenorth not saying it's a good idea
18:53:25 <Eddi|zuHause> maybe we could use "real" cargo-subtypes
18:53:45 <andythenorth> the current ones are silly :)
18:53:56 <Eddi|zuHause> then the cargo would not be "Coal" and "Ore" but "Bulk (Coal)" and "Bulk (Ore)"
18:54:58 <Eddi|zuHause> that's quite likely going to cause way more headaches than the existing system :p
18:56:01 <andythenorth> keep the current system :P
18:56:12 *** frosch123 has joined #openttd
18:57:37 <planetmaker> never too late. never too early. always exactly on time
18:58:22 <Eddi|zuHause> conclusion: he must be a wizard
18:58:35 <frosch123> magic or anti-magic?
18:59:05 <andythenorth> magic OR anti-magic
18:59:40 <frosch123> darn, i hoped you had finished that topic :p
18:59:40 <Eddi|zuHause> is that like black magic?
19:00:00 <andythenorth> Eddi|zuHause: a list of labels means an industry set could add a new cargo, referring only to already known cargos (by label)
19:00:31 <andythenorth> thereby avoiding a stupid bunfight about 'this cargo mostly travels by xyz'
19:01:44 <andythenorth> frosch123: you had a proposal about labels. I didn't understand it :)
19:01:49 <andythenorth> how would it work?
19:02:01 <frosch123> the equivalency stuff?
19:03:08 <frosch123> you would define a cargo SCMT (bulk), and would define that (SCRP, piecegoods) is a equivalent cargo
19:03:17 <Eddi|zuHause> andythenorth: the way i understood it: when you define a new cargo like AORE, you can say "this cargo behaves like IORE", so a vehicle set will get refitability and graphics, without knowing AORE
19:03:21 <frosch123> if a vehicleset knows about SCMT, that one will be used
19:03:53 <frosch123> if it does not know about SCMT, but about SCRP, then SCMT (bulk) pretends to be SCRP (peicegoods) for vehicles of that set
19:04:14 <planetmaker> so legacy settings for labels?
19:04:17 <frosch123> if it does not know about either of the cargos, or it knows both, then SCMT will be used
19:04:47 <frosch123> tricky is vehicle var 42, which returns the union of all cargoclasses in the train
19:05:29 <frosch123> but i guess it needs to use the cargoclasses of the equivalent cargo as well, to keep stuff consistent within one grf
19:05:34 <andythenorth> tricky is when IORE pretends to be AORE which pretends to be IORE :P
19:05:44 <andythenorth> I guess you solved that :)
19:05:56 <frosch123> AORE can only pretend to be IORE if AORE is defined
19:06:14 <Eddi|zuHause> frosch123: how would you know the cargo classes of the equivalent cargo? you don't have an industry set that defines it
19:06:20 <frosch123> equivalency only takes places, if one of the cargo is defined, and the equivalent one is not
19:06:34 <frosch123> Eddi|zuHause: it is defines along the equivalency
19:06:38 <andythenorth> so the set would have to define the equivalent cargos before then new ones
19:06:52 <frosch123> if you define the equivalency, you also have to set the cargo classes
19:06:57 <andythenorth> this would be self-contained improvement to cargo side of the vehicle-cargo interface?
19:07:28 <frosch123> andythenorth: the equivalency is a property of the cargo being defined
19:07:33 <frosch123> it is not a global property
19:07:49 <frosch123> so you can only define equivalent cargos, if you define a cargo
19:08:22 <frosch123> anyway, this is my state of knowledge from thursday morning
19:08:32 <frosch123> no idea whether there was anything new in the thread :p
19:09:20 <andythenorth> except from eddi
19:10:09 <andythenorth> so far: add prop 0x40 and 0x41 to cleanup the XOR mess; improve the wiki and create a 'spec' for setting classes (we can't enforce it, but we can say when a vehicle set is doing something wrong)
19:11:14 <andythenorth> deprecate but don't remove old behaviours, and indicate that vehicle sets might 'break' wrt industry sets (if the industry sets change labels for example)
19:11:36 <andythenorth> or add classes or anything else that causes and XOR-related explosiojn
19:11:56 <andythenorth> unfinished argument about FIRS classes, which I'm looking like losing
19:12:09 <andythenorth> mark 'hazardous' as "stupid idea, no-one should be using it"
19:12:21 <andythenorth> don't screw with existing cargos
19:12:27 <andythenorth> maybe add some new classes (meh)
19:12:43 <andythenorth> and then maybe your equivalence property
19:13:22 <planetmaker> maybe we should remove the xor property in newgrf v8 ;-)
19:15:00 <peter1138> just use prop 80/81 ;)
19:16:59 <Eddi|zuHause> peter1138: it's generally a bad idea to keep "deprecated" stuff easily accessible. only causes newbies to use them when they shouldn't.
19:17:30 <andythenorth> just clear it to 00 00 00 00
19:17:42 <andythenorth> when reading it in ottd
19:18:26 <Eddi|zuHause> andythenorth: that for sure makes it fun for debugging :p
19:18:50 <andythenorth> it's an exercise in reading the specs :P
19:19:02 <andythenorth> like my adventure with vars today :P
19:19:55 <andythenorth> Eddi|zuHause: btw the set capacity in the buy menu fails for the trams - consist info not available :D
19:20:17 <andythenorth> I'm going to live with the buy menu telling lies until $someone_else figures out a fix
19:21:37 * andythenorth wonders if that sentence makes any sense ^^ :P
19:25:26 <Eddi|zuHause> andythenorth: that's why you should have a separate callback just for the buy menu. to avoid all non-buy-menu variables
19:26:45 <andythenorth> you can't access var 40 (consist info) in the purchase menu
19:27:24 <andythenorth> I tried another route, which is to have the lead vehicle supply fake capacity to the buy menu and avoid handling cb 16 (articulated instructions) for buy menu, but that triggers warnings in ottd
19:27:55 <andythenorth> I had a couple more ideas I should maybe try though
19:28:37 <andythenorth> I could try lying to cb 16 is one idea (fake the consist itself)
19:29:19 <andythenorth> such a silly problem :D
19:31:14 <Eddi|zuHause> you could circumvent that by having separate vehicle IDs for front and other vehicles
19:31:33 <Eddi|zuHause> (if i understand the problem right)
19:33:42 <andythenorth> they have separate IDs
19:33:50 <andythenorth> let me test my newest idea :)
19:35:21 <michi_cc> andythenorth: Return the total capacity in the first vehicle and zero for all parts in the purchase menu and the proper capacity distribution in the normal case?
19:36:46 <andythenorth> I tried that, but got a warning in-game that purchase menu info differed. I might try again though, maybe I had some other prop changing that caused that.
19:37:36 * andythenorth thought that cargos already had an ID-based equivalent type property. Seems I was confusing that with industries.
19:38:51 <michi_cc> andythenorth: You still need to handle CB 16 in the purchase menu.
19:39:11 <andythenorth> ok, I'll try that and zero the vehicle capacities
19:39:35 <andythenorth> or build a different number of vehicles in cb 16 :P
19:39:40 <andythenorth> which might not be valid
19:46:30 <andythenorth> cheating cb16 appears to work just fine
19:46:56 <Yexo> "Keep in mind that this proposal is not for TTDPatch nor the current versions of OpenTTD." <- right, so we're discussing nothing
19:47:29 *** LordAro_ has joined #openttd
19:47:37 <andythenorth> he simply proposes deleting labels altogether
19:47:45 <andythenorth> can't see that happening :P
19:47:58 *** LordAro is now known as Guest16935
19:47:58 *** LordAro_ is now known as LordAro
19:48:22 <andythenorth> refits based only on classes would certainly work
19:48:27 <LordAro> should probably set it to do that automagically, tbh...
19:49:00 <LordAro> (i'm talking about me, not anything newgrf-ish :) )
19:53:22 <LordAro> am i still connected?
19:53:34 <LordAro> things have gone dead
19:53:51 <Terkhen> if what you says appears there, you are connected
19:54:32 <LordAro> update manager seems to sap most of the cpu/memory so pc appears slow, i think...
19:56:02 <LordAro> question: linux antivirus. any use?
19:57:35 <LordAro> indeed, clamav, bitdefender, couple of others
19:57:46 <LordAro> none of them seem to work particularly well though
20:00:50 <andythenorth> apparently me and george drove oztrans away :o
20:02:54 * LordAro deletes 'newgrfreadmedev' branch
20:03:04 <michi_cc> andythenorth: Do any of your GRFs work on TTDP? As he was targeting only that can't really have been you.
20:03:30 *** KillerByte has joined #openttd
20:03:35 * LordAro creates 'readmeviewerdev' branch :)
20:04:21 <andythenorth> "Note that OzTrans was not resistant to OTTD per se but rather having to frequently update his code per frequent changes to industry sets. "
20:05:33 <KillerByte> hey, I was wondering if this is the right channel to ask about the debian package for OpenTTD. According to the Ubuntu software center, OpenTTD is version 1.0.4. I am aware that I can get a deb package from the website downloads page, but is it possible to update the package management system more regularly (or right now)
20:06:02 <KillerByte> RPM's were fine last time I checked
20:06:23 <Alberth> LordAro: linux antivirus is typically used at mail servers for checking mail for non-linux systems :)
20:07:32 <Rubidium> KillerByte: we have no control over Ubuntu's packages. It's something Ubuntu (refuses) to update frequently
20:07:55 <Rubidium> (Ubuntu's packages being the packages in Ubuntu's repository, not the Ubuntu packages on our website)
20:07:55 <TinoDidriksen> Could make a launchpad ppa
20:09:07 <Alberth> KillerByte: You could also download a nightly and unpack it in your $HOME rather than install it centrally
20:11:07 <KillerByte> ok. I was just wondering if there was a way to make it more updateable via the ubuntu updater as a release comes out
20:12:58 <Rubidium> KillerByte: then you have to become an Ubuntu maintainer/developer
20:13:19 <Rubidium> and only then new versions get into new releases of Ubuntu, or you make a PPA
20:14:29 <LordAro> i thought blathijs was our ubuntu maintainer?
20:16:15 <Rubidium> LordAro: there is no Ubuntu maintainer
20:16:32 <Rubidium> blathijs makes the package for Debian which eventually, after a long time, trickle into Ubuntu
20:16:44 <Rubidium> Ubuntu has *no* security support whatsoever
20:16:59 <KillerByte> ok this is making a little more sense now. It appears that the OpenTTD package is only added at the start of an ubuntu release, but by the time the release officially comes out, it is outdated
20:17:26 * andythenorth has an idea, it's fiddly, but not bad. Documentation would be an arse for it :P
20:17:42 <andythenorth> - parameter in FIRS: 'more classes' 'fewer classes'
20:17:51 <KillerByte> I am looking at launchpad btw
20:21:20 <Rubidium> ah yes, the place where an OpenTTD has been declared upstream for OpenTTD with no means to say that it is definitely not OpenTTD's upstream
20:25:53 <andythenorth> cb 16 has a counter
20:25:56 <andythenorth> that should help :P
20:26:11 <andythenorth> let's try fix #7
20:28:02 <andythenorth> hmm, no way to pass cb 16 info to cb 36. Scrub that idea
20:28:10 <Snail_> I have a question about translations... there are a few lines which, in Italian, have been translated in a way that's not exactly precise
20:28:37 <Snail_> I tried to change them, but I just noticed someone just changed the back to the previous (slightly incorrect) way
20:29:01 <Snail_> yes but it might be confusing for players
20:29:18 <Snail_> it's about refitting and waiting for *full load* or for *any full load*
20:29:47 <peter1138> andythenorth, basically what wallyweb is proprosing is already doable
20:30:07 <andythenorth> yup, he's describing some fraction of the current spec
20:30:21 <peter1138> simply by not using the refit bitmask, you've got it
20:30:24 <andythenorth> apropros of the spec
20:30:38 <Snail_> what is the difference between "unload and wait for full load", and "unload and wait for *any* full load"?
20:30:43 <andythenorth> BUT if only we'd done that, OzTrans would still be here :O
20:30:56 <peter1138> you can still use labels to draw specific cargo
20:31:13 <peter1138> Snail_, if the vehicle can load multiple cargo types, it will finish loading when any one of them is full
20:31:17 <andythenorth> peter1138: except wally appears to think they should be removed : )
20:31:18 <peter1138> otherwise it has to be completely full
20:31:27 <peter1138> andythenorth, wally doesn't understand the technical side
20:31:39 <andythenorth> neither does andythenorth :P
20:31:56 <andythenorth> grr. I can't lie to cb16, it gets sad about refittable types
20:32:03 <andythenorth> this is...challenging
20:32:19 <Terkhen> Snail_: wait for any full load waits until the capacity of one of the cargos that the vehicle can carry is complete
20:32:23 <Eddi|zuHause> Snail_: difference is waiting for _all_ cargos to be fully loaded, or only _one_ cargo to be fully lodaded
20:32:36 <andythenorth> why will nothing accept my lies :P
20:32:40 <Snail_> I see. thanks for the explanation :)
20:33:17 <Snail_> is there a place in the forums where translations can be discussed without starting an editing war? whenever I try to give a better translation, someone changes it back to the old way...
20:33:27 <andythenorth> does anyone know the reason var 40 not available in purchase menu?
20:33:51 <Eddi|zuHause> Snail_: some languages have a translation topic. but not all translators read them
20:33:56 <andythenorth> as I am writing ever more layers of code and defines to try and stop the purchase menu lying about capacity
20:34:13 <Snail_> right... they might even not know about the forums...
20:34:31 <andythenorth> my 'template' is gaining so much 'ifdef' that my f key is wearing out :P
20:35:18 <Eddi|zuHause> Snail_: the translator software knows email addresses for each translator, so you can ask for contact info
20:37:03 <andythenorth> @calc 40 + 40 * 0 +1
20:37:39 <Eddi|zuHause> value did not change since last time :p
20:37:50 <LordAro> andythenorth: facebook? ;)
20:39:24 <planetmaker> which language, Snail_?
20:39:47 <planetmaker> hm, ok, I know neither forum nor thread about it :-)
20:39:51 <CIA-6> OpenTTD: truebrain * r23206 /trunk/ (. .hgignore): -Change: ignore .svn in .hgignore, and .hg in svn:ignore
20:40:06 <andythenorth> lord I get it wrong, I don't know why. My sister-in-law just got it wrong with the same answer, and she studied the same engineering courses at the same university as me
20:40:19 <Snail_> yep I couldn't find any...
20:40:34 <Alberth> andy: perhaps your teacher was wrong :)
20:40:36 <Snail_> I'm writing to the translator's email address if I can get the other person's addy
20:40:42 <andythenorth> I was basically taught that you just don't do that sum. You don't know where the brackets are so you don't do it.
20:40:52 <planetmaker> start a thread in General OpenTTD, I'd suggest. Unless there's somewhere an Italian forum. You might ask there, too. Or give a pointer
20:40:56 <planetmaker> worked for German ;-)
20:41:18 <andythenorth> if you're writing a compiler or maths co-processor you don't have the luxury of refusing the sum I guess.
20:41:18 <CIA-6> OpenTTD: truebrain * r23207 /trunk/src/ai/ (ai_instance.hpp api/ai_object.hpp): -Codechange: make functions private/protected/public depending on their current usage (and reorder functions a bit)
20:41:20 <planetmaker> which sum, andythenorth?
20:41:31 <planetmaker> The simple one you quoted? with the *0?
20:41:38 <andythenorth> engineers seem to answer 1
20:41:54 <andythenorth> based on a small sample size
20:42:00 <andythenorth> computer scientists answer 41
20:42:04 <planetmaker> ehm... then they missed basic math class
20:42:23 <planetmaker> +,- < *,/ < () ;-)
20:42:26 <CIA-6> OpenTTD: truebrain * r23208 /trunk/src/ai/api/ai_object.cpp: -Codechange: mark function with /* static */ in the source file, which are defined static in the header file
20:42:31 <Eddi|zuHause> hey... nobody remembers what they did in 3rd class :p
20:42:51 <andythenorth> I don't think order of operations is taught in the UK
20:43:02 <planetmaker> Eddi|zuHause: I'm sure it appeared in the first weeks of analysis, too. Not only in school ;-)
20:43:03 <andythenorth> not in state school anyway
20:43:07 <Alberth> Eddi|zuHause: not true, I still remember I made a lot of very boring sums
20:43:10 <peter1138> is either 1, 41 or 81
20:43:26 <andythenorth> peter1138: you are correct, why do so many people think it's 41?
20:43:41 <andythenorth> it's not clearly 41 unless you have a convention on orders of operation
20:43:43 <Eddi|zuHause> we should all learn UPN. then no brackets are needed
20:43:50 <CIA-6> OpenTTD: truebrain * r23209 /trunk/src/ai/ (9 files in 2 dirs): -Codechange: track the current active script instance directly, instead of assuming the current company points you to the right one.
20:43:53 <planetmaker> andythenorth: that convention exists universally, though
20:44:00 <peter1138> all programmers know that * comes before +
20:44:03 <Eddi|zuHause> or whatever it's called in english
20:44:12 <peter1138> reverse polish notation
20:44:32 <andythenorth> If you're ordering concrete, and your surveyor tells you you need 40 + 40 * 0 + 1 kilotons of concrete, you don't remember your basic maths textbook, you send them away to learn about brackets
20:44:52 <peter1138> a calculator will answer 1
20:45:05 <andythenorth> planetmaker: I know, my wife showed me :P
20:45:17 <Alberth> peter1138: depends on how good the calculator is :p
20:45:31 <peter1138> Alberth, simple 4 function one
20:46:02 * Alberth does not consider such a calculator as useful
20:46:05 <Snail_> peter1138: any chance we can add a parameter to "railtypes" to allow certain rail types only to have 90-degrees curves?
20:46:08 <TinoDidriksen> My calculator answers 41
20:46:10 <andythenorth> when you're ordering concrete, you don't say "let's compare calculator specs"
20:46:17 <Snail_> I think something like this would be very useful for NG sets
20:46:22 <valhallasw> why not Alberth? I find calculators are extremely efficient for quick calculations
20:46:28 <peter1138> 90° bends are always ugly :p
20:46:29 <valhallasw> much better than win-enter-calc-enter
20:46:30 <Snail_> as they would have a real advantage in games
20:46:40 <andythenorth> Snail_: not in my games :)
20:46:45 <valhallasw> oh, /me should read better
20:46:50 <Eddi|zuHause> peter1138: "minimum curve length" property
20:46:53 <Snail_> yes, but in reality, narrow gauge tracks could have sharper bends than standard gauge
20:46:55 <andythenorth> unfortunately the 'forbid 90 degree curves' would conflict
20:47:10 <andythenorth> it's a painful road to make newgrfs that conflict with advanced settings
20:47:12 <Snail_> and something like this would translate this advantage in gaes
20:47:38 <Eddi|zuHause> valhallasw: afair you can just do win+c
20:47:39 <andythenorth> Snail_: the advantage for me of NG is: it's awesome :)
20:47:43 <peter1138> also that 90° bends messes up path reservation
20:47:53 <Snail_> right... perhaps this could be an exception to the advanced settings
20:47:56 <Alberth> valhallasw: useful calculators usually end up in a 'scientific' corner for me (but I use Python normally as calculator, much more convenient)
20:47:56 <andythenorth> Snail_: with YAIM patch, NG might be really useful
20:49:03 <Snail_> andythenorth: so that NG could have lower maintenance costs
20:49:17 <valhallasw> Eddi|zuHause: doesn't seem to work on my windows box. But even then, entering calculations in calc is horrible, as I never know what happens after a set of keystrokes
20:49:27 <valhallasw> while I can predict that for my hp-41 ;-)
20:49:54 <Eddi|zuHause> Snail_: for CETS we once discussed making the curve speed limit more severe. e.g. narrow gauge: 30km/h, standard gauge (<16t axle weight): 25km/h, ... standard gauge (<22.5t): 15km/h
20:50:10 <valhallasw> Alberth: ah, yes, makes sense. Although I generally use it mainly for quick additions/subractions/multiplications (i.e. (frame number - trigger frame)/4000, or stuff like that
20:51:00 <andythenorth> Snail_: you could try pursuing the curve stuff Eddi|zuHause suggests, although NG is not that fast anyway
20:51:16 <Eddi|zuHause> Snail_: that would force the heavier trains to use _much_ longer curves
20:51:31 <Eddi|zuHause> but there was some support for that missing
20:51:32 <andythenorth> you could also try asking for a way to allow / disallow building on steep slopes according to rail type, as the primary advantage of NG was construction cost
20:51:35 <Snail_> Eddi|zuHause: yes that's true. But NG trains' max speed is usually 50km/h or below (as andy said)
20:52:00 <andythenorth> you can pin NG on the side of a mountain, less so for standard gauge
20:52:10 <Snail_> andythenorth: but in OTTD all the slopes are equally steep... aren't they?
20:52:13 <Eddi|zuHause> the current spec only provide very limited control over curve speed
20:52:41 <CIA-6> OpenTTD: rubidium * r23210 /trunk/src/ (101 files in 3 dirs): -Codechange: generate the GetClassName function for the AI classes programmatically
20:52:53 <andythenorth> Snail_: no, some have only 1 height level difference between corners, some have two levels ('steep slopes'). IIRC rails can now be built on most steep slopes though
20:53:09 <andythenorth> it might be interesting to have to level mountains a bit more to build standard gauge
20:55:07 <Snail_> oh, so "steep slopes" mean consecutive uphill tracks? not broken by horizontal tracks in between?
20:55:29 *** Devroush has joined #openttd
20:56:17 <planetmaker> Snail_: no, it refers to one tile
20:56:26 <andythenorth> screenshot would answer this best
20:56:30 <planetmaker> there exist tiles - without rail - which have two height difference
20:56:34 * andythenorth is making omelette however
20:56:51 <Alberth> at the right, 23, 27, 29, 30
20:57:23 * LordAro just bought a new monitor
20:57:52 <Snail_> planetmaker: ok, I see
20:58:10 <Eddi|zuHause> LordAro: they're all cute and cuddly in the beginning, but when they grow up...
20:58:32 <LordAro> (screen monitor, not monitor lizard :P
20:59:12 <Snail_> but there would be no way to build a track on those steep slopes. None of the 4 sides of the squares is horizontal
20:59:27 <planetmaker> oh, you can build horizontal tracks on them
20:59:41 <andythenorth> Snail_: I don't honestly know if railtypes could be restricted by slope
20:59:44 <andythenorth> industry tiles can
20:59:45 <planetmaker> possibly also up- or downslope with foundations
21:00:54 <Snail_> right, I just tried it in a game :D
21:01:47 <Eddi|zuHause> Snail_: on each steep slope, you can build 4 different rail bits
21:02:27 <Eddi|zuHause> slope in X direction, slope in Y direction, diagonal on the upper half, diagonal on the lower half
21:03:00 <Snail_> but this happens for all railtypes. There couldn't be an advantage for NG tracks there
21:03:23 <Eddi|zuHause> i don't see that happening either
21:03:55 <andythenorth> would be probably need a lot of rail-building tool modification to be possible
21:04:11 <Eddi|zuHause> so we're back at (1) curve speed, and (2) infrastructure maintenance
21:04:22 <andythenorth> railtype property: maximum height difference allowed on the tile? :P
21:04:55 <Eddi|zuHause> andythenorth: what are you going to do with a railtype that can be only placed on flat tiles?
21:05:03 <andythenorth> 0 is a pathological evil case :D
21:05:17 <Eddi|zuHause> andythenorth: this totally makes no sense
21:06:14 <Snail_> one more thing I was thinking of was rackrail-equipped NG tracks. I already drew graphics for such tracks and vehicles
21:06:29 <Snail_> but they would need a new acceleration system
21:06:41 <andythenorth> you can adjust TE according to railtype info?
21:06:56 <andythenorth> rackrail = TE ~ 1
21:07:01 <Snail_> theoretically yes, I did some tests there
21:07:46 <Eddi|zuHause> rack rail might be particularly interesting with more height levels
21:07:47 <Snail_> but the advantage is minimal if you boost TE when the vehicle is on rackrail tracks. It only affects very heavy trains at very low speeds (<= 10 kkm/h)
21:09:07 <Snail_> it would be very useful to be able to define a new acceleration model for certain tracks...
21:09:29 <Eddi|zuHause> maybe openttd handles the steepness all wrong
21:10:00 <andythenorth> does rackrail accelerate faster?
21:10:06 * andythenorth visits the krug pages..
21:10:52 <Eddi|zuHause> andythenorth: max_te has only effect on very low speeds. otherwise, pure power is relevant
21:11:16 <andythenorth> as long as you have adhesion, HP is the limiting factor...?
21:11:39 <Snail_> yes, this is why rackrail in-game has no real advantage unless we allow custom acceleration systems for railtypes
21:11:48 <LordAro> why's my ottd-auto-update script stopped working?...
21:12:06 <Eddi|zuHause> LordAro: because you didn
21:12:19 <andythenorth> Snail_: fake the HP?
21:13:33 <Snail_> but then rackrail engines would be disproportionately powerful w.r.t. other locos :D
21:13:44 <andythenorth> only when on rack
21:13:49 <Terkhen> Snail_: there are custom acceleration system for rail types
21:13:56 <LordAro> ah, only .tar.xz instead of .tar.gz :)
21:14:26 <andythenorth> terkhen beat my paste
21:14:31 <Eddi|zuHause> Snail_: have you tried your test series with a very high slope setting, like 7% or more?
21:14:35 <LordAro> how to untar a .tar.xz file (from command line)
21:14:51 <Snail_> oh yes, monorail or maglev. But can we create custom ones?
21:14:55 * LordAro bothers to google something :)
21:15:09 <Terkhen> Snail_: yes, as a patch to OpenTTD source code
21:15:20 <Terkhen> LordAro: I don't know much about tar, I always use tar xvf and it "works"
21:15:33 <Snail_> Eddi|zuHause: that's a good point, but it would affect other train types too. I don't know if that'd be desirable
21:15:54 <Snail_> Terkhen: you mean I would have to create my own patch?
21:16:20 <b_jonas> LordAro: if you have a new enough tar, then just tar xvf will work. if you don't, then try xzcat foo.tar.xz | tar xv
21:16:34 <Terkhen> yes, the only way to add new acceleration models is to change the source code
21:16:38 <planetmaker> LordAro: possibly tar xfvz file.tar.xz
21:16:41 <Eddi|zuHause> Snail_: the main thing that should do would be to make it really ineffective to have multiple consecutive slopes on normal rail
21:17:01 <LordAro> ty planetmaker / b_jonas
21:17:30 <b_jonas> if you don't have xz installed either, you can find it at http://tukaani.org/xz/ or try to download the same tarball gzip-compressed somewhere (it's usually available)
21:17:41 <Snail_> Eddi|zuHause: I can see that. It would force players to alternate slopes with flat pieces of track
21:18:12 <Terkhen> Snail_: I would like that... but some players would not. That would force to include Yet Another Setting
21:19:19 <Eddi|zuHause> maybe there could be newgrf-provided acceleration models? but that needs very optimized code, because it's run often
21:19:54 <Snail_> Terkhen: hmm. Right. Setting slopes to 7% could just be something "recommended" when playing with a certain set :D
21:20:46 <Terkhen> Eddi|zuHause: I'm not sure about the feasability of that... acceleration code needs to as optimized as possible
21:20:50 <Snail_> Eddi|zuHause: yes, but would a new acceleration model only affecting rackrail tracks be run that often?
21:21:12 <Eddi|zuHause> Snail_: twice every tick for each vehicle
21:21:34 <Terkhen> Snail_: my first implementation of realistic acceleration for road vehicles increased execution time on some testing maps to 150%
21:21:37 <Snail_> Eddi|zuHause: really? even on tracks other than rackrail? souds like a lot
21:21:40 <Terkhen> so yes, you need to be careful with that code :)
21:23:30 <Eddi|zuHause> Snail_: well, you would need to run at least some code until get to the point where you decide whether the vehicle is on rack rails at all
21:23:59 <Eddi|zuHause> Snail_: by then you've already passed through several newgrf code layers
21:24:40 <Snail_> Eddi|zuhause: true. This makes sense
21:25:32 <andythenorth> frosch123: (slightly) unrelated to classes, I had an idea for another misc cargo flag: 'cargo is sensitive to aging'
21:25:48 <andythenorth> for use not with refits...but the obvious cb for that prop
21:26:44 <Eddi|zuHause> andythenorth: but wouldn't that be a matter of payment rates? why would the wagon care about that?
21:27:14 <Eddi|zuHause> andythenorth: unless you give a reason _why_ the aging is relevant, what's the wagon gonna do about it?
21:27:57 <andythenorth> wagon knows the label and classes
21:28:03 <andythenorth> up to the author what the wagon does about it
21:28:26 <Eddi|zuHause> andythenorth: so still, at what point is the flag relevant?
21:28:43 <andythenorth> it's not, if you know the labels
21:29:16 <b_jonas> would it make sense if the first time you refit a vehicle it could be cheaper (or even free) whereas it's more expensive the next time?
21:29:35 <Eddi|zuHause> andythenorth: food is susceptible to aging because it must be refrigerated. mail (newspapers) is susceptible to aging because when it arrives it's just outdated
21:29:48 <Eddi|zuHause> andythenorth: so why would i put mail into a refrigerated wagon?
21:30:59 <andythenorth> Eddi|zuHause: in that case how does the wagon choice affect mail at all? Pick a faster vehicle :P
21:31:39 <andythenorth> armoured vs. refrigerated would be a better case against my idea
21:31:44 <Eddi|zuHause> andythenorth: exactly. why provide a flag that the vehicle set author doesn't care about and the user doesn't see?
21:32:06 <b_jonas> Eddi|zuHause: for AIs?
21:32:22 <Eddi|zuHause> b_jonas: then make AIs read the payment rates
21:32:45 <andythenorth> Eddi|zuHause: because I'm still pretty unconvinced by a lot of the rationale for extra classes tbh. This idea was about allowing players to make the choice of vehicle, but provide incentives
21:33:10 <andythenorth> it might not stack up mind
21:33:55 <Eddi|zuHause> andythenorth: so if the vehicle set chooses to provide a refrigerated wagon with aging bonus, then he needs the refrigerated class
21:34:11 <Terkhen> yes, ogfx-rv does that
21:34:23 <andythenorth> and the covered class, and the powderised class...and the armoured class and so forth
21:34:59 <Eddi|zuHause> andythenorth: that's a case you won't find a better solution for
21:35:00 <andythenorth> Eddi|zuHause: and that's the *only* way we can think of to do it?
21:36:00 <andythenorth> so why does the vehicle set author care about this if it's classes, but not if it's flags?
21:36:08 <andythenorth> and the player doesn't see it anyway, so why bother?
21:36:25 <Eddi|zuHause> andythenorth: why overcomplicate things? refrigerated wagon: OR mask = refrigerated, AND NOT mask = empty. full support for all known and future refrigerated cargos
21:36:58 <Eddi|zuHause> andythenorth: with a flag, you need to employ a special callback, etc.
21:37:22 <andythenorth> don't we have that cb already?
21:37:36 <Eddi|zuHause> no, it was only a future suggestion
21:38:27 <Eddi|zuHause> having or not having is irrelevant, though. you still need more implementation effort
21:38:39 <Eddi|zuHause> for something that is currently setting _one_ bit
21:38:50 <Terkhen> and keep things simple :)
21:39:25 <Eddi|zuHause> andythenorth: we have a refit _cost_ callback, but not a _refitability_ callback
21:39:44 <andythenorth> I don't care about refittability
21:39:53 <andythenorth> refittability is - soon -a solved problem
21:40:03 <andythenorth> what I'm puzzled about is the cargo aging cb :)
21:40:08 <andythenorth> I thought that was implemented?
21:40:16 <Eddi|zuHause> that is implemented, yes
21:40:27 <andythenorth> I was looking in the cb list for it :)
21:40:45 <Eddi|zuHause> but why would i put wool into a refrigerated van?
21:40:58 <Eddi|zuHause> only to then decide that it's not getting the aging bonus?
21:41:11 <andythenorth> these are reasonable objections ;)
21:41:24 <andythenorth> but you could if you wanted do such a thing
21:41:32 <LordAro> excellent, finally got it to work
21:41:49 <Eddi|zuHause> rather allow only refitting to the proper cargos, and don't use the aging callback at all
21:42:08 <Eddi|zuHause> for the other cargos there are regular wagons
21:42:22 <andythenorth> I'm not arguing against that, I'm looking at other interesting gameplay ideas
21:42:27 <andythenorth> for some definition of 'interesting'
21:42:43 <Snail_> speaking about refit costs and aging: I noticed that, if you create different subtypes of the same cargo and try to refit to another subtype *of the same cargo*, the cost of refitting is always 0
21:42:49 <Eddi|zuHause> good. but i don't see the use in this instance
21:42:49 <Snail_> (as I posted on the forum :D )
21:43:17 <Eddi|zuHause> Snail_: post that on the bugtracker
21:43:19 <andythenorth> Eddi|zuHause: it's probably better handled by knowing about specific cargos, but that seems kind of tiresome
21:44:14 <Snail_> I thought it was a "feature". I'll post it in the "openttd problems" board then
21:45:44 <Eddi|zuHause> Snail_: on the forum it might be missed
21:46:17 <Snail_> Eddi|zuHause: great! thanks :)
21:48:43 <andythenorth> Eddi|zuHause: imo this is another point in favour of your additional specific classes then :|
21:48:56 <andythenorth> it allows interesting custom aging
21:49:31 <andythenorth> I could transport any bulk by open wagon, but set a penalty on that vehicle for cargos requiring covered (e.g. grain)
21:49:41 <andythenorth> is that an abuse of classes, or correct?
21:50:02 <z-MaTRiX> should i do a few more bytes comparing 2 variables with zero and increase performance instead of floatingpoint dividing by zero?
21:50:52 <z-MaTRiX> (in any other case it will be only 2 extra comparisons)
21:51:56 <z-MaTRiX> a line with same end and starting point for example...
21:52:35 <Eddi|zuHause> andythenorth: that's a corner case, because it's not particularly "realistic". (you can just cover the wagon with a tarpaulin)
21:53:00 <andythenorth> swap grain for cargo example of your choice - I don't mind ;)
21:54:40 <Eddi|zuHause> andythenorth: like i said before, i see no actual use case for covered class, but since it's already been defined, we need to keep it
21:55:09 <andythenorth> we could mark it as "this class is stupid"
21:55:33 <andythenorth> you can trade covered for refrigerated in my case above if you wish
21:55:49 <Eddi|zuHause> andythenorth: you can use it in the graphics selection to decide whether to draw a tarpaulin or show the cargo
21:56:24 <andythenorth> that's the voice of someone who hasn't drawn 10 bazillion cargo sprites yet
21:57:49 <Eddi|zuHause> right, i wanted to sort out some recolour tables for magic-pink cargo graphics
22:00:44 <Eddi|zuHause> we had to patch several pieces for the magic-pink idea to work :p
22:02:01 <andythenorth> I know last time I looked at it I gave up
22:02:09 <andythenorth> flood-fill in source turned out to be easier
22:02:44 <Eddi|zuHause> recolouring+companycolour is tedious, i imagine :)
22:03:17 <Eddi|zuHause> luckily, i have a code generator, which takes most of the tedious tasks away :)
22:03:24 <andythenorth> iirc it's actually impossible if you use both cc
22:03:50 <Eddi|zuHause> actually it is possible, you just need several thousand recolour tables
22:04:04 <Eddi|zuHause> GermanRV is 50% recolour tables :p
22:13:22 <Snail_> andythenorth: you can use 2cc and use another color (for instance pink, as mentioned) for the cargo
22:17:53 <andythenorth> it's still tempting for FISH
22:19:24 * peter1138 ponders scrapping his EZ
22:20:00 * andythenorth scrapped all attempts to stop the buy menu lying :(
22:23:58 <michi_cc> peter1138: What's wrong with your EZ?
22:29:36 <Eddi|zuHause> <Snail_> andythenorth: you can use 2cc and use another color (for instance pink, as mentioned) for the cargo <-- no, you got that backwards. i meant the colour in the sprite is pink and it gets replaced by a real colour by the translation table
22:31:49 <Snail_> Eddi|zuHause: you mean the cargo is colored in pink? or the vehicle?
22:32:42 <Eddi|zuHause> Snail_: the cargo
22:33:32 <Snail_> right. So the vehicle can be in 2cc blue and green, which get replaced in-game?
22:34:13 <Eddi|zuHause> Snail_: in my case the vehicle is not recoloured, but in GermanRV it is
22:36:42 <Snail_> Eddi|zuHause: right, I see
22:41:33 *** supermop_ has joined #openttd
23:54:56 <peter1138> michi_cc, the stuff for gui sprites is irritating
23:56:26 <Eddi|zuHause> peter1138: why do GUI sprites need special handling? just load them like normal sprites (i.e. same conversions), and then pass the zoom level in the GUI drawing code
23:56:55 <Eddi|zuHause> possibly this allows you to have a setting about small/normal/large gui
continue to next day ⏵
