Back to Home / #openttd / 2011 / 11 / Prev Day | Next Day
#openttd IRC Logs for 2011-11-13

---Logopened Sun Nov 13 00:00:25 2011
00:04-!-Snail_ [] has quit [Quit: Snail_]
00:56-!-Eddi|zuHause [] has quit [Remote host closed the connection]
00:56-!-Eddi|zuHause [] has joined #openttd
02:14-!-DOUK [] has joined #openttd
02:19-!-mahmoud [] has quit [Ping timeout: 480 seconds]
02:19-!-mahmoud [] has joined #openttd
02:24-!-DOUK [] has quit [Ping timeout: 480 seconds]
02:38-!-andythenorth [] has joined #openttd
03:03<andythenorth>Eddi|zuHause: why bother with refrigerated, covered etc? Why not just use the cargo aging cb to differentiate between wagons?
03:10<andythenorth>same for armoured
03:19-!-Kurimus [] has joined #openttd
03:20<andythenorth>hola planetmaker
03:21<@peter1138>when do opengfx+ rvs start?
03:22-!-Neon [] has joined #openttd
03:23<@peter1138>hmm, the readme for it is...
03:23<@peter1138>well it's about compiling it
03:27<@planetmaker>peter1138: it starts at the same time as default vehicles
03:28<@planetmaker>and yes, the readme is not yet targeted mostly at players
03:28<@planetmaker>nearly no readme is ;-)
03:28<@peter1138>it's a common problem with tons of opensource software too
03:28<@peter1138>this is how you download and compile it
03:29<andythenorth>wtf stops the front vehicle of a tram from loading cargo?
03:29<@peter1138>but ... _what is your software_ :S
03:29<@planetmaker>well. Others don't read it, peter1138 ;-)
03:29<@peter1138>planetmaker, too true
03:29<@peter1138>i only read the readme cos we have that funky ingame viewer now :)
03:29<@peter1138>but you knew that
03:30<@peter1138>andythenorth, capacity 0 :p
03:30<andythenorth>that's what I thought
03:30<andythenorth>but the code lies
03:34<andythenorth>definitely has a capacity
03:34<andythenorth>it's reporting it correctly
03:34-!-He||isH [~hellish@] has left #openttd [gl & hf]
03:35<andythenorth>it's set by cb 36
03:36<andythenorth>I can see capacity of consist changing if I adjust return value of cb
03:36<andythenorth>are there flags that stop powered vehicles loading?
03:46-!-TWerkhoven [] has joined #openttd
03:48<andythenorth>new HEQS feature: bugs :(
03:48<Rubidium>oh, that sounds like a fun new cargo
03:48<Rubidium>ant farm -> food factory
03:50-!-pjpe [] has joined #openttd
03:52<andythenorth>maybe I'm doing it wrong
03:52<andythenorth>this 'fake changing RVs consist by subtype' idea is very clever
03:52<andythenorth>but quite complex
03:56<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
03:57-!-snack2 [] has joined #openttd
03:59-!-Progman [] has joined #openttd
03:59-!-JVassie [~James@] has joined #openttd
04:01<@planetmaker>things like ant farm -> food factory sounds like an excellent addition to toy climate :-)
04:01-!-BloodyRain2k [] has joined #openttd
04:01<BloodyRain2k>hi, I got a problem, for some reason after a recent update stations like this don't work like before anymore, the trains completely ignore that depot.
04:02<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.
04:04-!-DayDreamer [] has joined #openttd
04:06<andythenorth>Rubidium: that is the best suggestion in some time
04:07<@planetmaker>BloodyRain2k: same savegame?
04:07<Rubidium>BloodyRain2k: do you have a savegame where it seems to misbehave?
04:07<@planetmaker>or a new game?
04:07<Rubidium>(so we can take a look at it)
04:07<@peter1138>^ Grace Hopper transport BUGS +1
04:09<andythenorth>where's Eddi|zuHause when he's needed? :P
04:09<BloodyRain2k>It misbehaves like that everywhere, even on a server I joined
04:10<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
04:10<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 ^^;
04:12<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.
04:12<andythenorth>I can't figure out how to stop the buy menu telling lies about tram capacity :\
04:15<Rubidium>also, what "old" version and "new" version are we talking about?
04:15<BloodyRain2k>Rubidium: two saves, the 1965 one was from before deleting the openttd.cfg and these are nightly r23165 ones, just for the case it matters
04:16*andythenorth admits defeat
04:16<BloodyRain2k>Rubidium: 'old' version was 1.0.9 or something close to that, 'new' is 1.1.3
04:17<andythenorth>the tram capacity when built is 80t. it has refits up to 225t
04:17<andythenorth>buy menu shows 225t
04:17<andythenorth>225t != 80t, so that's going to annoy players
04:17<Rubidium>1.0.9 doesn't exist and closest would be 1.1.0 (mathematically at least)
04:18<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
04:18<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
04:18<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
04:19<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.
04:19*andythenorth wonders if default subtype can be forced
04:19-!-DayDreamer [] has quit [Read error: Connection reset by peer]
04:19<Rubidium>in the Crumplewig savegame. In the Findtown savegame breakdowns are enabled and they go to the depot when needed
04:19<Eddi|zuHause>just make a special callback for purchase list
04:20<andythenorth>one varact, setting capacity according to position in consist?
04:20<Eddi|zuHause>yes, something like that
04:21<BloodyRain2k>Rubidium: weird, breakdowns aren't on for me there but even if I turn them on they ignore the depot.
04:21-!-DayDreamer [] has joined #openttd
04:21<andythenorth>Eddi|zuHause: I'll try that thanks
04:22<@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 ?
04:23<@planetmaker>or rather the *2 after the property was obtained, possibly via CB?
04:24<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)
04:25<@planetmaker>there's never been a 1.0.9 anywhere
04:26<andythenorth>Eddi|zuHause: I have a proposal for classes / refits
04:26<Rubidium>planetmaker: you know trains are in 1/1.6 mph, right?
04:26<andythenorth>- add a new flag for 'cargo is sensitive to aging'
04:26<Rubidium>planetmaker: well, ships and RVs are in 1/3.2 mph
04:26<andythenorth>- remove classes refrigerated, covered, armoured
04:27<@planetmaker>yes, that I found. sure
04:27<andythenorth>- use cargo aging cb in conjunction with flag
04:27<Eddi|zuHause>andythenorth: can't remove classes
04:27<andythenorth>remove / deprecate in documentation /s
04:27<@planetmaker>Rubidium: but, internally the nfo value is stored for the properties, right?
04:27<andythenorth>'refuse to support' :P
04:27<@planetmaker>Or do I miss the conversion? I only found one for the aircraft speed
04:27<@planetmaker>of *128) / 10
04:27<Eddi|zuHause>andythenorth: that's useless as long as the default cargos have them
04:28<andythenorth>Eddi|zuHause: mask out the bits :P
04:28<andythenorth>in ottd
04:28<@planetmaker>as such I don't quite get why RV once use * 2 and the other time / 2 in that very line
04:28<andythenorth>anyway, the point was the special flag + use aging cb for gameplay
04:29<Rubidium>planetmaker: the nfo unit differs per vehicle type (well, ships and rvs are the same)
04:29<andythenorth>transport gold by open wagon if you like, but it might suffer some....shrinkage
04:29<Eddi|zuHause>andythenorth: sure, flag is useful
04:29<@planetmaker>yes. 1/1.6mph, 1/3.2mph and 1/8 mph
04:30<Eddi|zuHause>planetmaker: RVs have two speed properties?
04:30<Rubidium>so, to unify it to 1/1.6 you need to divide the 1/3.2 by two
04:30-!-Alberth [] has joined #openttd
04:30-!-mode/#openttd [+o Alberth] by ChanServ
04:31<@planetmaker>return (max_speed != 0) ? max_speed * 2 : this->u.road.max_speed / 2; <<--- but here?
04:31<@planetmaker>Why once *2 and once /2 for road vehicles
04:31<@planetmaker>the preveious line uses GetEngineProperty to retrieve the speed
04:31<Rubidium>planetmaker: what Eddi|zuHause said: there are two properties for RVs for speed
04:33<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?
04:33<Eddi|zuHause>one of these half-baked attempts at unifying things
04:33<BloodyRain2k>Rubidium: ok, even in a completely fresh seperate 1.1.3 do my trains refuse to use a depot as overflow
04:33<Eddi|zuHause>andythenorth: what's the achieved effect wrt to the 3 goals i put up?
04:34<@planetmaker>hm, ok, so the GetEngineProperty uses always the property 15... yes, then it makes sense. Thanks
04:35<BloodyRain2k>Rubidium: uhm, somewhat refuse to, just now after a short waittime the train went into the depot... wth
04:35<andythenorth>Eddi|zuHause: meets goal (1) by reducing number of classes, reducing likelihood of AND NOT collisions
04:35<@planetmaker>(or the CB does behave like prop. 15)
04:35-!-Biolunar [] has joined #openttd
04:35<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
04:36<andythenorth>goal (3) is met by labels anyway
04:37<Eddi|zuHause>goal (3) means "don't use labels unless you have to"
04:37<Eddi|zuHause>if "deprecate classes" means "you have to use labels for all default cargos", then goal (3) is failed
04:40-!-sla_ro|master [~slaco@] has joined #openttd
04:42-!-pjpe [] has quit [Quit: ajax IRC Client]
04:51-!-Wolf01 [] has joined #openttd
04:56<@planetmaker>hi Wolf01
05:07<andythenorth>Eddi|zuHause: wrt (3) whether you *have* to use labels depends on the specific classes currently in use yes / no?
05:08<andythenorth>so we'd have to keep armoured
05:08-!-ptr [] has joined #openttd
05:10<andythenorth>a vehicle set that *refused* to use refrigerated or covered would still transport all default cargos
05:11<andythenorth>"let's make a *new* standard"
05:12<andythenorth>then there can be two standards :P
05:17<BloodyRain2k>anyone else got an idea why my trains refuse to use depots at stations like this as overflow retreat? I even tried a completely fresh 1.1.3 so I'm wondering what's wrong.
05:23-!-Celestar [] has joined #openttd
05:24-!-BloodyRain2k [] has quit [Remote host closed the connection]
05:26*andythenorth always wanted to be an animator :P
05:27<@Alberth>doing your morning-exercises, andy ?
05:27-!-BloodyRain2k [] has joined #openttd
05:28<BloodyRain2k>meh, chatzilla has it downsides, like when you forget about it and restart the FX due to memory shortage...
05:29<@Alberth>BloodyRain2k: the image mentions something about a pathfinder setting that has changed
05:30<@Alberth>although I fail to see the advantage, why can't the train wait before the entrance signal?
05:32<@Alberth>I tend to add more platforms or build a holding place for waiting trains
05:34<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.
05:36-!-Guest16854 [~chatzilla@] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224508]]
05:37-!-DDR [~DDR@] has joined #openttd
05:38-!-Pulec [] has joined #openttd
05:38-!-andythenorth [] has quit [Quit: andythenorth]
05:39-!-valhallasw [~valhallas@] has joined #openttd
05:39<Celestar>hacking cliffs into CmdTerraformLand seems wrong ..
05:40<@planetmaker>I can imagine functions where it's even more wrong ;-)
05:41<Celestar>CmdStopTrain? :P
05:42<@planetmaker>something like there, yes
05:48<@Alberth>BloodyRain2k: isn't it a sign you have too many trains :)
05:49<Celestar>I gotta think the whole terraform UI with this.
05:49-!-JVassie [~James@] has quit [Read error: Connection reset by peer]
05:50<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 ;_;
05:50<Celestar>"raise land" on a corner usually raises all 4 adjacent tiles. What happens if this corner is on a cliff?
05:50<BloodyRain2k>Alberth: and I keep forgetting the highlightings :3
05:50<Celestar>should all of them be raised?
05:50<Celestar>only the ones of the "selected" tiles?
05:50-!-JVassie [~James@] has joined #openttd
05:51<Celestar>remove the cliff if possible?
05:52-!-TGYoshi [~TGYoshi@] has joined #openttd
05:54<@Yexo>BloodyRain2k: are you sure that setting is not only true inyour config file but also in the savegame?
05:55-!-DoubleYou [] has quit []
05:55<BloodyRain2k>Yexo: very sure as I didn't change it and created quite a few new games already
05:55<@Alberth>BloodyRain2k: force them into the depot?
05: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)
05:57<@Alberth>Celestar: you probably want to keep the 'affect all selected tiles' semantics that we have now
05:57-!-DDR [~DDR@] has quit [Quit: In democracy it's your vote that counts; In feudalism it's your count that votes. - Mogens Jallberg]
05:58<@Alberth>BloodyRain2k: sorry, way too advanced for me, you need a real player :)
05:58<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.
06:00<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
06:00<BloodyRain2k>or was it terminus... dunno, the ones that only have one end :3
06:01<@Yexo>BloodyRain2k: if you replace your presignal with a normal signal (like in the wiki image) it works fine
06:01<Celestar>Alberth: yeah I think so as well.
06:01<Rubidium>you still haven't shown us a savegame from the old version where "it" worked
06:01<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.
06:02<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.
06:03-!-pugi [] has joined #openttd
06:03<@Yexo>BloodyRain2k: I just confirmed in 1.1.3 that it worked
06:03<@Yexo>if it doesn't your settings are not default
06:03<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.
06:03<@Yexo>in other words: provide your config file / a savegame
06:05-!-Brianetta [] has joined #openttd
06:07<@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
06:07<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.
06:07<@Yexo>try My Documents/OpenTTD/openttd.cfg
06:08<Celestar>Alberth: well if you only select a single (cliffed) corner, just raise the one corner of the tile which is selected...
06:08<@Alberth>Celestar: I'd go for raise the corners of all 4 tiles, whether they are smoothly connected or not
06:08<@Alberth>In RCT you can select a tile or a corner
06:10<Celestar>Alberth: yeah that's why I'm just trying to go for
06:10<@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
06:12<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.
06:12<@Yexo>it should always use the config next to the exe if there is one
06:18<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.
06:18<BloodyRain2k>I'll post the settings file I just used, there got to be the problem somewhere.
06:20<BloodyRain2k> there it is
06:20<BloodyRain2k>I'll dig through my old games now.
06:21-!-Adambean [] has joined #openttd
06:24-!-Cybertinus [] has joined #openttd
06:27-!-HerzogDeXtEr [] has joined #openttd
06:27<@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
06:32<Celestar>Alberth: I'll keep that in mind :P
06:32-!-KritiK [~Maxim@] has joined #openttd
06:33<@Alberth>it's a nice puzzle :)
06:34-!-George [~George@] has quit [Read error: Connection reset by peer]
06:36<Celestar>gtg :)
06:36-!-Celestar [] has quit [Quit: leaving]
06:39-!-George [~George@] has joined #openttd
06:40<BloodyRain2k>Ok I loaded a lot of old games and all show the same borked behavior. So just to verify (or not) my sanity, did this ones entrance signal ever go green if the way to the depot was free but the station full? Because it doesn't for me now and I can't remember this as normal.
06:42<@Yexo>no, they will never turn green if both platforms are occupied
06:42<@Yexo>at least not in 0.7 or higher
06:42<@Yexo>perhaps in 0.6
06:44<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...
06:44<@Yexo>there is no 1.0.9, nor any 0.9.x
06:48<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?
06:48<BloodyRain2k>meh >_<
06:48<@Yexo>there is no general way to decide properly for all cases which wagon should be added
06:49<BloodyRain2k>copy the first behind the engine? including fitting?
06:49<@Yexo>that might be a cab control wagon or something similar
06:49<@Yexo>or the only mail wagon in an othrewise passenger train
06:49<@Yexo>or... ;)
06:50<BloodyRain2k>I mean I know that there are some packs that add 20 wagons that can transport the same 20 goods through fitting
06:50<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
06:50<BloodyRain2k>so don't come at me with that ^^
06:50<@Yexo>no, removal will always eat the last wagon
06:50<BloodyRain2k>whatever, it remains the same
06:52<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
06:52<BloodyRain2k>or not?
06:53<@Yexo>however the first wgon that fits the criteria might not be buildable anymore
06:54<@Alberth>or it may not be allowed at the new position
06:55<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.
06:55<@Yexo>BloodyRain2k: sure, but such a wagon might have a lower maximum speed
06:55<@Yexo>or the newgrf might forbid attaching that wagon to the train
06:55<@Alberth>by Murphys law, the game will then pick the wrong one
06:56<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.
06:56<@Alberth>and players start screaming "it is broken!!!"
06:56<@Yexo>or attaching such a wagon might triple the running cost for the front engine of the train
06:56<BloodyRain2k>If you go that way Alberth you don't need to make any game at all because someone will always scream that ^^
06:57<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.
06:58<@Alberth>BloodyRain2k: players now still have control, at the expense of a bit more work, which is why what you want is not implemented
06:58<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
06:59<@Alberth>just replace the whole train?
07:00<@Yexo>BloodyRain2k: the length of wagons can depend on the train they're attached to
07:01<@Yexo>the game doesn't know this in advance (ie before it actually attached them)
07:01<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.
07:01<@Alberth>BloodyRain2k: I started fixing this issue 3 times already, and got stuck in the code each time
07:02<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)
07:04<@Alberth>it still has most of the problems mentioned previously, I think
07:05<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.
07:06<@Alberth>yep, you want groups in there too
07:07<@Alberth>but there is not even an object "train X" in the game currently
07:07<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.
07:07<BloodyRain2k>yeah ._. that's the point I'm failing at already without even knowing the limitations of the game
07:08<@Alberth>you cannot express a "layout" currently
07:08<@Alberth>only the vehicles actually used in the game exist, as a big bunch of vehicles
07:09<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
07:10<@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
07:10<@Alberth>a lot of code rests on that
07:11<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.
07:11<BloodyRain2k>Like the default order by train number, I guess that's the core one.
07:14<@Alberth>I don't know. Personally, I consider groups useless, but ymmv
07:16<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?
07:16<BloodyRain2k>well I guess not, that list is missing the replace button.
07:17<@peter1138>they're sort of "implicit" groups
07:17<@peter1138>why have 1 way of doing things when you can have several o_O
07:17<@Alberth>ymmv = your mileage may vary = you may have a different idea about it
07:17<@Alberth>peter1138: less work :p
07:18<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
07:18<@Alberth>like 'instead of having a proper 'train' concept, use the first train in a group in core order
07:18-!-Elukka [] has joined #openttd
07:19<BloodyRain2k>should be optional of course, I can imagine there are cases where it would cause havoc on mass
07:19<@peter1138>i wonder where my engine patch went
07:19<@Alberth>it took off :)
07:20<@peter1138>it lets you have wagons & engines in any order
07:20<BloodyRain2k>I guess the best place for that 'setting' would be a "Keep first's layout" button in the shared order list
07:20<BloodyRain2k>ah you mean like the engine at the end? or if you feel like it in the middle? ^^
07:20<@peter1138>as long as there's something with power (even if unpowered) it's a train
07:20<@peter1138>whereever, yeah :)
07:21<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 -.-
07:21<BloodyRain2k>one reason I stopped building terminus stations...
07:22<BloodyRain2k>well rather avoid it at all costs xD
07:23<@Alberth>oh, and you're not bothered about instant 45 degrees corners ?
07:23<@Alberth>or even 90 degrees :D
07:24<@Alberth>and the completely broken scales ? :D
07:25<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
07:25<BloodyRain2k>anyways what do you think about that shared order list approach Alberth, would that be from the accessing, usefulness and doability something good?
07:26-!-Cybertinus [] has quit [Remote host closed the connection]
07:26<@Alberth>In my opinion, it is another piece of half-done fix that only makes solving it properly harder
07:27<BloodyRain2k>sounds like a no : /
07:28<BloodyRain2k>guess it's a big bunch of work, mostlikely even bigger than I imagine it since I don't even know the code
07:28-!-Cybertinus [] has joined #openttd
07:29<@Alberth>it pushes people into using things in a single particular way
07:29-!-perk11 [~perk11@] has joined #openttd
07:29<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
07:29<@Alberth>as Yexo said a long time ago already ;)
07:30<BloodyRain2k>yup, I just didn't figure it out that way until now xD
07:30<BloodyRain2k>I was too distracted by feeling insane o,o
07:31<Eddi|zuHause>wrt Celestar's GUI issue: make it a modifier button (like one-way, bulldozer, etc.)
07:31<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
07:32<Eddi|zuHause>so the corner to be changed is chosen similar to how autorail decides the rail bit
07:32<BloodyRain2k>btw <3 shared orders, one of the nicest things in ottd if you ever have to change something :D
07:33<Arafangion>Maintaining them is a PITA, though.
07:34-!-andythenorth [] has joined #openttd
07:34<@Alberth>BloodyRain2k: shared orders should be a group concept
07:35<andythenorth>uh oh
07:35<andythenorth>Alberth: I thought you didn't discuss groups any more :)
07:35<@Alberth>I discuss against shared orders instead ;)
07:40<BloodyRain2k>mhm, the yapf just prefered a straigth 45 straigth curve over a 45 45 45 (straigh towards the same tiles) one O.o
07:41-!-hanf [] has joined #openttd
07:42<@planetmaker>of course
07:42<@planetmaker>a curve is a penalty
07:44<+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.
07:45<+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.
07:47<andythenorth>michi_cc: you just described what I want to do :P
07:47<andythenorth>what's complicated about it :D
07:47<BloodyRain2k>uhm yeah planetmaker, I explained it badly. I'll sketch it up on paste bin xD too lazy for paint.
07:47<+michi_cc>The fact that the backlog of the whole last week or so is nothing else except cargo classes? :p
07:48<andythenorth>yeah, there is that :P
07:48<andythenorth>who's in charge? :P
07:48<BloodyRain2k>planetmaker: there, that should show it better than my explanation
07:49<@planetmaker>yapf has no concept of curve length afaik
07:49<@planetmaker>thus: build properly ;-)
07:50<BloodyRain2k>ah, thought it had since it had curve penalties
07:50<@planetmaker>a curve is just a thing like -/
07:51<@planetmaker>but not how much space between two consecutive ones
07:51<BloodyRain2k>wonder if it'll learn that somewhen too
07:51<@planetmaker>write a patch
07:51<@planetmaker>otherwise: unlikely ;-)
07:53<CIA-6>OpenTTD: rubidium * r23203 /trunk/ (6 files in 2 dirs): -Change: make locks more consistently looking (PaulC)
07:54<SpComb>consistencify lock looks
08:00<andythenorth>who actually is in charge of cargo classes?
08:01<andythenorth>cos concensus on it is unlikely
08:01-!-JVassie_ [~James@] has joined #openttd
08:07-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
08:09-!-JVassie [~James@] has joined #openttd
08:15<andythenorth>Eddi|zuHause: :)
08:16-!-JVassie_ [~James@] has quit [Ping timeout: 480 seconds]
08:19-!-hanf [] has quit [Read error: Connection reset by peer]
08:24<BloodyRain2k>bleh, back to signal problems this one doesn't work for me currently but did in a save so I got a messed up setting somewhere now. Here's the config, I just shifted the pf part up:
08:26<andythenorth>is cb36 used in the buy menu for trailing parts of an articulated RV consist?
08:26<andythenorth>and if so, is var 40 (consist position) available?
08:27-!-Cybertinus [] has quit [Remote host closed the connection]
08:27-!-Cybertinus [] has joined #openttd
08:28<BloodyRain2k>meh whatever, ignore me -_- forgot the settings are saved in the save and that one got created with borked ones...
08:31<andythenorth>wallyweb proposes having industries produce and accept based on lists of cargo classes
08:31<andythenorth>so the industry would accept 'piece goods, bulk, liquid' etc
08:31<andythenorth>and produce 'express, piece goods, refrigerated' for example
08:32<andythenorth>but as that's not going to happen, /me will continue staring at tram code
08:32<andythenorth>Eddi|zuHause: either your proposed solution for trams doesn't work, or I can't code :O
08:32<andythenorth>evidence suggests the latter is more likely
08:33-!-Mucht [] has joined #openttd
08:34<@Alberth>such industry only makes sense for eg a warehouse imho
08:34<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
08:36<andythenorth>cb36 is available for articulated rvs in buy menu
08:36<andythenorth>var 40 appears not to be
08:36<andythenorth>there's nothing in the wiki about it
08:37-!-glx [glx@2a01:e35:2f59:c7c0:3824:60d4:4cb:b2b3] has joined #openttd
08:37-!-mode/#openttd [+v glx] by ChanServ
08:38<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
08:38-!-BloodyRain2k [] has quit [Quit: ChatZilla 0.9.87 [Firefox 8.0/20111104165243]]
08:40<Arafangion>Alberth: You're describing "goods".
08:42<andythenorth>what would cause a varact 2 to return whatever range is first checked?
08:42<andythenorth>irrespective of the value
08:46<@Yexo>using an invalid variable
08:47<@Alberth>I did? I thought I just argued against having all industries accept anything with certain properties
08:47<andythenorth>Yexo: so I see
08:47<andythenorth>I should have read the var table, not the description (in the wiki)
08:48<b_jonas>so a power station should accept anything burnable, including mail?
08:48<andythenorth>so the only fix I can think for trams is to change the order of subtypes
08:48<b_jonas>(and withces)
08:48<@Yexo>andythenorth: and var 40 is inded not availble in the buy menu
08:48<@planetmaker>mail: yes. witches: no ;-)
08:49<andythenorth>Yexo: is that by design, or lack of implementation?
08:49<@Yexo>no idea
08:49<andythenorth>nvm :)
08:49<b_jonas>how about wood? that also floats on water.
08:51<andythenorth>does anyone other than me care that the buy menu lies about HEQS tram capacity? Maybe it doesn't need fixing
08:51<andythenorth>reports (e.g.) 300t, builds 80t
08:54<andythenorth>silence is the same as nobody cares :)
08:54<andythenorth>I _could_ split the vehicle IDs for the trailing vehicles, so there are two kinds of wagon
08:54<andythenorth>one is built at 0 cap, the other at FOO cap
08:54<andythenorth>then vary the cb16 return values for building articulated vehicle
08:55<andythenorth>seems like a bit of an arse about though
08:57*Alberth never played with HEQS trams so far
08:57<@planetmaker>they're well worth it :-)
08:59<@Alberth>I have no doubt about that. I just do too many different other things
09:05<andythenorth>what can cause a vehicle to have capacity, but not load?
09:06<andythenorth>this is quite maddening :P
09:09<andythenorth>for the record, the answer is: setting the load amount to 0
09:09<andythenorth>just in case anyone else ever spends an hour with that problem :P
09:14*andythenorth thinks wallyweb has quite a fundamental misunderstanding of how cargos work :O
09:15<@Alberth>NewGRF has so many traps built-in :)
09:15<andythenorth>Alberth: that's the fun part :)
09:15<andythenorth>if it was easy, I'd be bored
09:16<@Alberth>so either you are bored or you are crazy :p
09:16<andythenorth>XOR or OR?
09:17<@Alberth>for your sake, /me hopes XOR
09:17*andythenorth writes the embarassing "here's a new version because I screwed up" changelog :P
09:17<@Alberth>ever counted the number of "-Fix:" in the openttd repo? :)
09:21<@Yexo>or looked at the changelog for any x.y.z version for z > 0?
09:22-!-SystemParadox [] has joined #openttd
09:27-!-andythenorth is now known as Guest16899
09:27-!-Guest16899 [] has quit [Read error: Connection reset by peer]
09:27-!-andythenorth_ [] has joined #openttd
09:27-!-andythenorth_ is now known as andythenorth
09:28-!-andythenorth is now known as Guest16900
09:28-!-Guest16900 [] has quit [Read error: Connection reset by peer]
09:28-!-andythenorth_ [] has joined #openttd
09:28-!-andythenorth_ is now known as andythenorth
09:28-!-andythenorth_ is "(unknown)" on (unknown)
09:30<andythenorth>planetmaker: would you mind looking at this and collecting your thoughts? (no rush)
09:39-!-snack2 [] has quit []
09:39-!-Mucht [] has quit [Ping timeout: 480 seconds]
09:40-!-pugi [] has quit [Ping timeout: 480 seconds]
09:43-!-pugi [] has joined #openttd
09:46-!-andythenorth is now known as Guest16902
09:46-!-Guest16902 [] has quit [Read error: Connection reset by peer]
09:46-!-andythenorth_ [] has joined #openttd
09:46-!-andythenorth_ is now known as andythenorth
09:47-!-andythenorth is now known as Guest16903
09:47-!-Guest16903 [] has quit [Read error: Connection reset by peer]
09:47-!-andythenorth_ [] has joined #openttd
09:47-!-andythenorth_ is now known as andythenorth
09:48-!-andythenorth is now known as Guest16904
09:48-!-andythenorth_ [] has joined #openttd
09:48-!-Guest16904 [] has quit [Read error: Connection reset by peer]
09:48-!-andythenorth_ is now known as andythenorth
09:49<andythenorth>stupid router is flapping :\
09:50<MNIM>better than fapping, I suppose.
09:59-!-KritiK_ [~Maxim@] has joined #openttd
10:04-!-KritiK [~Maxim@] has quit [Ping timeout: 480 seconds]
10:05-!-KritiK_ is now known as KritiK
10:31-!-Mucht [] has joined #openttd
10:53-!-panna_ [] has joined #openttd
10:54<@planetmaker>andythenorth: looIRS #3235: in principle vehicle set authors can always create situations where a cargo is NOT transportable
10:54-!-panna [] has quit [Ping timeout: 480 seconds]
10:55<andythenorth>yup, but it's a game of probabilities ;)
10:55<@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
10:55<@planetmaker>Though probably completely removing it, will never be feasible
10:55<@planetmaker>so, yes, game of probabilities
10:56<andythenorth>that, combined with Eddi's proposal that AND NOT (piece, bulk, liquid) is out of spec would help
10:56<andythenorth>although AND NOT express could still cause problems
10:56<@planetmaker>you mean the suggestion as on the user page in the spec wiki?
10:57<andythenorth>apart from I 100% disagree about adding even more classes, I agree with the rest of that proposal
10:57-!-panna_ is now known as virrpanna
10:57<@planetmaker>what's the rest? The change of classes for existing cargos?
10:58<@planetmaker>s/cargos/cargo labels/?
10:58<andythenorth>ok I'll read it and be more precise :)
10:59<@planetmaker>sorry :-)
10:59<@planetmaker>From what I remember, it's two (main) things he suggests:
10:59<@planetmaker>a) the re-definition of the classes. Which basically the same as adding two new ones
10:59<@planetmaker>And clarifying the descrition of a few others.
11:00<andythenorth>clarifying +1
11:00<@planetmaker>Air fright is IMHO a bad naming though. Wonders happen, but I do agree with mb there
11:00<andythenorth>air freight -1
11:00<andythenorth>adding classes -1
11:00<andythenorth>changing existing labels -1
11:01<andythenorth>specifying that 'never exclude' applies to a number of the classes +1
11:01<andythenorth>noting that hazardous 'is not in common use' +1
11:01<andythenorth>example schemas for sets +1 (although I disagree about the detail of the classes)
11:02<@planetmaker>all agreed. maybe "adding classes +/- 0" from my POV
11:02<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.
11:03<andythenorth>for FIRS it's highly controversial to do the same :(
11:03<andythenorth>but I think it's the correct route
11:03<andythenorth>extra = hazardous, oversized, covered, powdered, not pourable
11:03<andythenorth>possibly refrigerated
11:04<andythenorth>I'd say armoured too in FIRS case
11:04<andythenorth>I'm now convinced these classes are not helping the situation
11:05<+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.
11:06<andythenorth>so my proposal is simply to ignore them :)
11:07-!-LordAro [] has joined #openttd
11:07<andythenorth>if other people want them, there's nothing to stop them being used
11:07<andythenorth>nobody controls the spec
11:08-!-ABCRic [] has joined #openttd
11:09<+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?
11:10<andythenorth>that's going to happen either way
11:11<@peter1138>best version number ever :D
11:12<andythenorth>michi_cc: the only significant information there is "every time you decide to change a cargo again?" :P
11:12<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" ;)
11:14*andythenorth really regrets that the FIRS cargo labels were published. It would have been much better to keep cargo information private.
11:15<+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.
11:15<Eddi|zuHause>andythenorth: you're kinda contradicting yourself there. if you do not want your labels published, set designers _must_ depend on classes
11:15<+michi_cc>That's not a failure of the conecpt.
11:16*peter1138 ponders a YAIM network game
11:16<Eddi|zuHause>michi_cc: i agree there
11:17*andythenorth is running out of arguing :P
11:18<andythenorth>why do vehicle set authors get to control what's in an industry set, is the fundamental problem I can't get past
11:18<andythenorth>it totally limits the ability to design a decent set
11:19<andythenorth>I want to make good things, not crappy things
11:19<ABCRic>use ALL the vehicle sets!
11:21<+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.
11:21<andythenorth>michi_cc: that would be nice if it was a clean sheet of paper ;0
11:21*andythenorth ponders FIRS Renewal
11:21<andythenorth>ditch FIRS
11:21<andythenorth>start again
11:22<andythenorth>adding classes: allowed
11:22<andythenorth>but may cause refit explosions
11:22<andythenorth>removing classes: not allowed
11:22<andythenorth>changing labels: not allowed
11:23<andythenorth>result: industry set that cannot be improved
11:25<@Yexo><andythenorth> changing labels: not allowed <- where did you get that from?
11:25<@Yexo>new label = new cargo = set classes however you want
11:25<andythenorth>it breaks sets
11:25<@Yexo>special support for the new cargo doesn't exist
11:25<@Yexo>no, it doesn't
11:25<+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).
11:25<andythenorth>yes it does, because people rely on the XOR
11:25<@Yexo>it only removes specific refitting for special cargos
11:25<andythenorth>= breaks sets
11:25<+michi_cc>Who cares?
11:25<@Yexo>andythenorth: that only brings us back to: nobody should allow on the XOR, only on specific inlcude/exclude masks
11:26<@Yexo>than the problem is gone
11:26<andythenorth>but they do
11:26<@Yexo>do you care?
11:26<andythenorth>do I care? No.
11:26<@peter1138>if you change your cargos
11:26<andythenorth>Do I have to care because I'm required to maintain a stable API? Yes
11:26<@peter1138>tell the authors of sets who use them :p
11:26<@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
11:27<andythenorth>It's really frustrating that I've had the requirement to maintain a stable API imposed upon me
11:27<@Yexo>if a cargo was explicitely included from some wagons and (implicitely, via cc mask) include in another
11:27<@peter1138>so, anyone for a YAIM game with FIRS, HEQS, ETCS
11:27<+michi_cc>Yexo: Of course, I just don't think this is the end of the world.
11:28<andythenorth>michi_cc: some people do, and there's no spec :P
11:29<+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 :)
11:29<@peter1138>i did
11:30<@peter1138>is it what's needed?
11:30<@Yexo>as far as I can see it'd solve all current practical problems
11:30<andythenorth>peter1138: it works for me
11:30<@peter1138>(also i unconventionally made it a common prop instead of assigning the next two properties for each vehicle class
11:30<@Yexo>the rest is theoretical babble habout how classes don't fit every cargo and are not realistic however you define them
11:30<andythenorth>we can then say that sets using the old method are not guaranteed any support
11:31<@Yexo>andythenorth: nobody was ever "guaranteed" any support at all
11:31<@peter1138>imho, classes were always a fallback system
11:31<andythenorth>me too
11:31<andythenorth>which is completely at odds with the other prevailing view
11:32<@peter1138>michi_cc, is YAIM commitable yet? :D
11:32<@Yexo>due to the current limitation of specific refit support only for the first 32 cargos classes currently are more than a fallback system
11:32<@peter1138>Recticulating splines
11:32<@Yexo>your patch would fix that
11:32<@peter1138>hmm, -c
11:33<+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.
11:33-!-TWerkhoven[l] [] has joined #openttd
11:35<+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
11:35<@peter1138>andythenorth, CHIPS has awesome buffer stops
11:35<@peter1138>start at 80, ok
11:37<@peter1138>andythenorth, i can actually see them at 2x ;)
11:38<andythenorth>did you commit EZ yet? :P
11:39<andythenorth>peter1138: the new props have a length byte at the start of the list?
11:40<@peter1138>yeah they do
11:40*andythenorth hopes we can teach nforenum to count :P
11:40<@peter1138>yexo said that's easier than a nul terminated list
11:41<andythenorth>otherwise we'll have to teach andythenorth to count
11:41<andythenorth>way harder
11:45<@peter1138>cool, i can build roads without fences disappearing
11:50<Eddi|zuHause>andythenorth: the problem with counting is that you need a syntactical method to mark the end of the list
11:51<andythenorth>like industry layouts?
11:52<Eddi|zuHause>no idea about those
11:57<andythenorth>they have a delimiter byte
11:58-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
11:58<Eddi|zuHause>no, not a byte
11:58<Eddi|zuHause>more like an escape sequence
11:58<andythenorth>two bytes for industry layouts /s
11:58<Eddi|zuHause>like \0l \0r
11:59<@planetmaker>uh, sorry, was on the phone
11:59<@planetmaker>summary as I read it:the xor by label should be deprecated.
12:00<Eddi|zuHause>so you'd write something like "<action 0> <...> 40 00 \0l 01 02 03 ... XY \0r <...>"
12:00<@planetmaker>explicit support for a label via a new property desired
12:00<@planetmaker>maybe explicit support to NOT support an specific cargo
12:00<@planetmaker>via another property
12:00<@planetmaker>all issues solved then?
12:01<@planetmaker>sounds fine to me this or these properties
12:01<@planetmaker>I'm not 100% positive on the exclude property, but I won't bitch about it ;-)
12:02<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"
12:02<Eddi|zuHause>andythenorth: these markers would not have a representation in the final grf
12:03<@Yexo>actually it's quite easy to supprot both (prefix length-byte or FF terminated list)
12:03<@Yexo>0-terminated doesn't work because 0 is a valid index
12:04-!-HerzogDeXtEr [] has joined #openttd
12:06<@Yexo> <- andythenorth: untested, but should provide nforenum support for prop 40
12:06<@Yexo>first byte is number of indices to follow, every index is a byte
12:06<@planetmaker>allow refit by label?
12:07<z-MaTRiX>someone know-of a function of a square in usable form?
12:07<@planetmaker>or rather by ctt-entry?
12:08-!-Pulec [] has quit []
12:09<@Yexo>by ctt-index
12:11<Eddi|zuHause>planetmaker: excerpt from yesterday:
12:11<Eddi|zuHause>[12.11.2011 11:02] <peter1138> [...] properties 0x40 & 0x41
12:11<Eddi|zuHause>[12.11.2011 12:44] <Eddi|zuHause> Yexo: it appears to work, but i'm not entirely sure about correctness. and
12:11<Eddi|zuHause>[12.11.2011 12:45] <Eddi|zuHause> accompanying CETS diff:
12:11*planetmaker looks. Thx. Missed that
12:11<andythenorth>worked for me
12:11<andythenorth>I didn't test any edge cases
12:11<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
12:17*andythenorth tries patching nforenum
12:18<Eddi|zuHause>planetmaker: in nml, you can give a list of labels
12:19<@planetmaker>yes, that's what I'd assume :-)
12:19<@planetmaker>but the patch uses ctt-entries, it seems
12:19<@planetmaker>which is good enought, too, I guess
12:19<@Yexo>planetmaker: in nml, a label (when it's defined in the CTT) is a constant with as value the index in the CTT
12:20<@planetmaker>yes, I know :-)
12:20<@planetmaker>seems after we made all newgrfs which use tiles incompatible with stable OpenTTD we now make all vehicle sets incompatible with stable openttd ;-)
12:20<Eddi|zuHause>the variable name is probably subject to change
12:21<Eddi|zuHause>CETS was never compatible with any stable openttd
12:21<@planetmaker>not that. But heqs, fish, ogfx+trains, ogfx+rv
12:22<Eddi|zuHause>there'll be a next stable openttd :)
12:22<@planetmaker>cets is too advance to think of that :-)
12:22<@planetmaker>pehw. Lucky us :-)
12:23<andythenorth>planetmaker: HEQS incompatible? not yet...
12:24<andythenorth>give me time :P
12:25<andythenorth>Yexo: nforenum patch is happy with props 0x40 and 0x41
12:25<@planetmaker>:-) But I see you getting it incompatible, andythenorth ;-)
12:25<@Yexo>great :)
12:27<andythenorth>planetmaker: certainly that's my plan
12:27<andythenorth>maybe it's a good thing that bananas has no way to provide the newest grf compatible with your ottd
12:27<andythenorth>maybe it causes upgrading
12:27<andythenorth>Yexo: I only tested for RVs, I assume it works for the others
12:28<@Yexo>yes, it was copied-pasted between vehicle types
12:28<@planetmaker>is the new trend to give the same feature the same property number? :-)
12:29<Eddi|zuHause>i really hope so
12:29<andythenorth>keeping them different means frequent wiki trips
12:30<andythenorth>frequent wiki trips is good
12:31*Alberth ponders changing the spec based on creation date of the newgrf
12:32*andythenorth ponders changing spec based on random numbers
12:33<@planetmaker>much better is file creation date
12:34<andythenorth>we know...use like....versions and stuff
12:34<andythenorth>I propose the number 7 for the spec most people are using
12:34<andythenorth>and maybe 8 for a new one?
12:34<andythenorth>might as well keep them in order :P
12:34<@Alberth>sounds like a plan ;)
12:35<andythenorth>incidentally does *anyone* understand Wallyweb's proposal for cargos?
12:35<andythenorth>I'm fairly certain Wallyweb doesn't
12:41<@planetmaker>I didn't quite understand his point. Maybe it's a language thing
12:44<Eddi|zuHause>i'm fairly sure it doesn't have anything to do with what we're discussing
12:46<andythenorth>me to
12:46-!-perk11 [~perk11@] has quit [Quit: Miranda IM! Smaller, Faster, Easier.]
12:46<andythenorth>afaik there are only two questions remaining about classes
12:47<andythenorth>(1) if I change classes in FIRS, am I required to ship a new label (MB thinks no btw)
12:47<andythenorth>(2) should Eddi's proposal for extra classes be adopted
12:48<@peter1138>i'm pretty sure wallyweb doesn't know the technical side of what's being discussed
12:49<@planetmaker>with the current system a change in classes of a cargo means new label.
12:49<@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
12:50-!-BloodyRain2k [] has joined #openttd
12:50<@planetmaker>as it breaks existing newgrfs to do so. As the nasty xor property exists
12:50<andythenorth>but did the spec ever guarantee that wouldn't happen?
12:50<Eddi|zuHause>planetmaker: afaik ECS only added newly defined classes to the cargos.
12:50<@planetmaker>a new label doesn't break them
12:51<@planetmaker>maybe, yes
12:51<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 ;)
12:52<andythenorth>labels are shared *across* sets, so changing their classes seems less correct (I don't particularly care about the breaking vehicle sets)
12:52<BloodyRain2k>hi again, I got a problem again with the overflow depots (what a wonder) because it seems to only work with a specific setup and not all. this one fails while this one works (same game)
12:53<@planetmaker>Still, I'd not have used it as a 100% iron-clad rule
12:53<@planetmaker>I'd silently (or not so silently) have changed the classes of SCRP
12:53<andythenorth>that one was a stupid case anyway, because the wiki was wrong
12:53<@planetmaker>It's FIRS only so far
12:53<andythenorth>all I did was bring the code in compliance with the wiki :P
12:54<andythenorth>that change underlines how bonkers the XOR effects are :P
12:54<@Yexo>BloodyRain2k: savegame please
12:54<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
12:55<andythenorth>their *appears* to be russian and hungarian and polish efforts for example that don't participate in this community :)
12:55<andythenorth>their / there /s
12:56-!-ABCRic [] has quit [Quit: Goodbye, world...]
12:56<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
12:57<Eddi|zuHause>BloodyRain2k: you'll probably find that if you shorten the tracks to the depot, it will start to work
12:59<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
13:00<@planetmaker>the latter was in early OpenTTD versions the default
13:01<@planetmaker>which might result in (old) wiki pages relying on it to be true
13:01<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.
13:02<BloodyRain2k>Eddi|zuHause: could that depot one be the rail_depot_reverse_penalty? since that's the only depot one I see currently
13:04<@planetmaker>hi LordAro
13:05<LordAro>hi pm
13:07<andythenorth>planetmaker: we missed a consolidation in FIRS: WOOL and FICR are both 'natural fibres' :o
13:07<andythenorth>and it would make almost no difference to gameplay to consolidate them I think
13:08<andythenorth>maybe a bit of the charm might be lost, I find wool appealing for some reason
13:09<@planetmaker>FICR is fibre _crops_ while (sheep) wool is not a crop :-)
13:09<@planetmaker>Yes, having wool is charming :-)
13:10<Eddi|zuHause>planetmaker: compare "(Schaf-)Wolle" and "Baumwolle"
13:10<andythenorth>they're all natural fibres...but yes
13:10<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
13:10<andythenorth>there's no reason to remove them
13:10<@planetmaker>Eddi|zuHause: yes? FICR still doesn't fit then to WOOL
13:10<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...
13:10<@planetmaker>compare wool and cotton, Eddi|zuHause ;-)
13:11<andythenorth>planetmaker: new label NFBR
13:11<Eddi|zuHause>planetmaker: i know :)
13:11*andythenorth is not proposing doing this btw
13:11<andythenorth>just mentioning it's possible
13:11<Eddi|zuHause>planetmaker: "cotton" is an arabic loan word, while "Baumwolle" is one of those pragmatic german word creations
13:12<@planetmaker>it is
13:12*andythenorth is proposing doing this - may interest Eddi|zuHause
13:15<@planetmaker>I'd not be too thrilled to change that all
13:16<andythenorth>planetmaker: do you want to leave comments? Better thought left to brew I think
13:16<@planetmaker>I still think that the classes of covered, refrigerated make sense
13:16<@planetmaker>in the "and not" property
13:16<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
13:17<@planetmaker>and add the prop. 40,41
13:17<@planetmaker>I concur
13:17<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.
13:17<BloodyRain2k>anyways thanks again
13:17<@Yexo>BloodyRain2k: I've never had the need for overflow depots, why do you need them at all?
13:17<andythenorth>FWIW, if FIRS was a solo set, I'd make the changes and live with the consequences
13:18<@Yexo>to me it looks like that as soon as you need one you have too many trains, so you should stop/sell one
13:18<andythenorth>however /me does not fancy trying to maintain FIRS alone :o
13:19-!-KenjiE20 [] has quit [Quit: WeeChat 0.3.5]
13:20-!-KenjiE20 [] has joined #openttd
13:21<@planetmaker>but, andythenorth, many of those labels are not FIRS' labels alone...
13:22<@planetmaker>or are they all?
13:22<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
13:22<@planetmaker>iirc FISH, BEER, CLAY, BDMT all are multi-set labels
13:22<@planetmaker>maybe also WDPR
13:22<andythenorth>planetmaker: we'd have to split labels
13:22<andythenorth>not idea
13:22<@Yexo>BloodyRain2k: just create another platform for you station instead?
13:23<@Yexo>that also allows you to have an extra train waiting
13:23<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
13:23<andythenorth>Eddi|zuHause + me have been around the classes enough that I think the current 'extra' ones are basically half-assed
13:23<andythenorth>and broadly not useful
13:24<@planetmaker>they are useful. In the "and not" category
13:24<andythenorth>'covered' in particular has zero information content imho, as any vehicle can provide a cover, and many sets do
13:24<@planetmaker>Thus eddi's suggestion is - as you outlined earlier - a good one by large parts
13:25<andythenorth>the classes proposed by Eddi|zuHause are what is needed if we want to enable detailed class-based vehicle control
13:25<@planetmaker>open hopper: bulk and not covered
13:25<@planetmaker>problem solved. use case found
13:25<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.
13:25<@planetmaker>really, andythenorth, the classes are not a problem. Just the clarifications how vehicle sets shall use them
13:26<Eddi|zuHause>planetmaker: not entirely sure whether that is a "realistic" use case
13:26<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.
13:26<@planetmaker>if they don't not your problem, but vehicle set bug
13:26<@planetmaker>Eddi|zuHause: realistic or not, I don't mind ;-)
13:26<@peter1138>pom te pom
13:27<andythenorth>planetmaker: you just prevented UKRS 2 and NARS 2 carrying clay, grain etc for most of the set's lifetime with that example
13:27<andythenorth>classes == fallback
13:27<z-MaTRiX>what is your opinion about functional polymorphism in C ?
13:27<Eddi|zuHause>a purely academic set of wagons that doesn't have any "real" vehicles in mind is probably not a good goal
13:27<andythenorth>(I don't mean to say we support specific sets backwards, they're just examples)
13:27<Eddi|zuHause>or maybe that's exactly the problem
13:28<@planetmaker>andythenorth: if ukrs and nars don't support clay, it's a bug there
13:28<andythenorth>or it's a bug in the provision of classes as a fallback :P
13:28<andythenorth>or it's a bug in the goal
13:28<@Alberth>z-MaTRiX: it looks plain ugly
13:28<@planetmaker>and you thus try to topple over everything with classes etc, because of clay in those two sets?!?!
13:28<Eddi|zuHause>z-MaTRiX: relying on "true"=="1" in arithmetic expressions is imho bad style
13:29<andythenorth>I'm trying to retrieve classes from a current dumb position
13:29<andythenorth>either they're detailed, or fallback, but currently they fail both
13:29<Eddi|zuHause>use (i>=b)?c:0 instead
13:29<@Alberth>z-MaTRiX: a=(i>=b)?c:d
13:29<andythenorth>we should decide :P
13:30<@planetmaker>andythenorth: I think the decision is clear: update class description. Issue solved
13:30<andythenorth>Eddi|zuHause: ^ does that meet your case for detailed control?
13:30<@planetmaker>no further action required for industry sets
13:30<andythenorth>i.e. no new classes
13:31<andythenorth>no 'powderised', no 'not pourable'
13:31<Eddi|zuHause>andythenorth: we can decide on one without deciding on the others
13:32<z-MaTRiX>Alberth<< ok, how about a more complex problem?
13:32<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
13:32<andythenorth>it would seem better to clarify current first
13:32<andythenorth>in either case
13:33<andythenorth>Eddi|zuHause: what would happen if you shipped your proposal to the wiki?
13:33<@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
13:34<z-MaTRiX>well yes, but for example i can have 1 loop instead of 4
13:34<z-MaTRiX>that is mainly redundant
13:34*planetmaker would ask frosch about it (again) when he's back
13:34<@planetmaker>+1 @ Alberth
13:34-!-Mucht [] has quit [Remote host closed the connection]
13:35<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
13:35<@peter1138>herp a derp
13:35<@planetmaker>Eddi|zuHause: still, the wagon suggestion might still have a place there on the classes page
13:36<@Alberth>z-MaTRiX: perhaps you need a smarter way to decide the sequence to iterate over?
13:36<@planetmaker>As it gives vehicle authors the idea how to use them
13:37<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
13:37<@planetmaker>that's also feasible
13:38<@planetmaker>you could implement that anyway :-)
13:40<z-MaTRiX>Alberth<< yeah i'm on it ;)
13:40<andythenorth>wallyweb just describes the current system, minus labels
13:40<andythenorth>maybe he's right :)
13:41<andythenorth>no explicit refitting at all :o
13:41*andythenorth suspects we'd end up with classes like 'wood', 'tropical wood', 'sawn wood' :P
13:42<@planetmaker>'virtual wood'
13:43*andythenorth resists the obvious
13:45<CIA-6>OpenTTD: translators * r23205 /trunk/src/lang/ (estonian.txt italian.txt portuguese.txt welsh.txt):
13:45<CIA-6>OpenTTD: -Update from WebTranslator v3.0:
13:45<CIA-6>OpenTTD: estonian - 8 changes by Jaanus
13:45<CIA-6>OpenTTD: italian - 3 changes by Snail_
13:45<CIA-6>OpenTTD: portuguese - 24 changes by ABCRic
13:45<CIA-6>OpenTTD: welsh - 34 changes by kazzie
13:46<Eddi|zuHause>i think the "obvious" stuff that andythenorth talked about involves the word "morning" :p
13:46<andythenorth>too puerile :P
13:46<andythenorth>generally that sort of thing is best left to #tycoon or whatever it's called
13:47<andythenorth>Eddi|zuHause: my 2p, express is express. It's a fact on the ground, it pragmatically works
13:47<andythenorth>nobody likes it, lots of people use it though
13:48*andythenorth ponders having a cargo define a list of labels, not just one label
13:49<andythenorth>maybe that's what frosch's suggestion was :o
13:49<andythenorth>they share one name string
13:49<andythenorth>could suck in gameplay though
13:49<andythenorth>feeder systems would be horrible to setup
13:50<Eddi|zuHause>frosch's suggestion was loosely based on my lengthy discussion with MB about railtype compatibility
13:51<andythenorth>lists of labels would address composite cargos like BDMT
13:52<andythenorth>could be a list of BRCK, CEMT, LMBR etc
13:53*andythenorth not saying it's a good idea
13:53<Eddi|zuHause>maybe we could use "real" cargo-subtypes
13:53<andythenorth>the current ones are silly :)
13:53<Eddi|zuHause>then the cargo would not be "Coal" and "Ore" but "Bulk (Coal)" and "Bulk (Ore)"
13:54<Eddi|zuHause>that's quite likely going to cause way more headaches than the existing system :p
13:56<andythenorth>keep the current system :P
13:56-!-frosch123 [] has joined #openttd
13:57<@planetmaker>never too late. never too early. always exactly on time
13:58<Eddi|zuHause>conclusion: he must be a wizard
13:58<frosch123>magic or anti-magic?
13:58<frosch123>evening :)
13:59<andythenorth>magic OR anti-magic
13:59<andythenorth>not XOR :P
13:59<Eddi|zuHause>is that like black magic?
13:59<frosch123>darn, i hoped you had finished that topic :p
14: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)
14:00<andythenorth>thereby avoiding a stupid bunfight about 'this cargo mostly travels by xyz'
14:01<andythenorth>frosch123: you had a proposal about labels. I didn't understand it :)
14:01<andythenorth>how would it work?
14:02<frosch123>the equivalency stuff?
14:03<frosch123>you would define a cargo SCMT (bulk), and would define that (SCRP, piecegoods) is a equivalent cargo
14:03<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
14:03<frosch123>if a vehicleset knows about SCMT, that one will be used
14:03<frosch123>if it does not know about SCMT, but about SCRP, then SCMT (bulk) pretends to be SCRP (peicegoods) for vehicles of that set
14:04<@planetmaker>so legacy settings for labels?
14:04<frosch123>if it does not know about either of the cargos, or it knows both, then SCMT will be used
14:04<frosch123>tricky is vehicle var 42, which returns the union of all cargoclasses in the train
14:05<frosch123>but i guess it needs to use the cargoclasses of the equivalent cargo as well, to keep stuff consistent within one grf
14:05<andythenorth>tricky is when IORE pretends to be AORE which pretends to be IORE :P
14:05<andythenorth>I guess you solved that :)
14:05<frosch123>AORE can only pretend to be IORE if AORE is defined
14:06<Eddi|zuHause>frosch123: how would you know the cargo classes of the equivalent cargo? you don't have an industry set that defines it
14:06<frosch123>equivalency only takes places, if one of the cargo is defined, and the equivalent one is not
14:06<frosch123>Eddi|zuHause: it is defines along the equivalency
14:06<andythenorth>so the set would have to define the equivalent cargos before then new ones
14:06<andythenorth>it's appealing
14:06<frosch123>if you define the equivalency, you also have to set the cargo classes
14:06<andythenorth>this would be self-contained improvement to cargo side of the vehicle-cargo interface?
14:07<frosch123>andythenorth: the equivalency is a property of the cargo being defined
14:07<frosch123>it is not a global property
14:07<frosch123>so you can only define equivalent cargos, if you define a cargo
14:08<andythenorth>makes sense
14:08<frosch123>anyway, this is my state of knowledge from thursday morning
14:08<frosch123>no idea whether there was anything new in the thread :p
14:09<andythenorth>nothing useful
14:09<andythenorth>except from eddi
14:09-!-BloodyRain2k [] has quit [Read error: Connection reset by peer]
14:10<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)
14:11<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)
14:11<andythenorth>or add classes or anything else that causes and XOR-related explosiojn
14:11<andythenorth>unfinished argument about FIRS classes, which I'm looking like losing
14:12<andythenorth>mark 'hazardous' as "stupid idea, no-one should be using it"
14:12<andythenorth>don't screw with existing cargos
14:12<andythenorth>maybe add some new classes (meh)
14:12<andythenorth>and then maybe your equivalence property
14:12<andythenorth>that was fun ;)
14:13<@planetmaker>maybe we should remove the xor property in newgrf v8 ;-)
14:13-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
14:14<@peter1138>why bother
14:15<@peter1138>just use prop 80/81 ;)
14:16<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.
14:17<andythenorth>just clear it to 00 00 00 00
14:17<andythenorth>when reading it in ottd
14:18<Eddi|zuHause>andythenorth: that for sure makes it fun for debugging :p
14:18<andythenorth>it's an exercise in reading the specs :P
14:19<andythenorth>like my adventure with vars today :P
14:19<andythenorth>Eddi|zuHause: btw the set capacity in the buy menu fails for the trams - consist info not available :D
14:20<andythenorth>I'm going to live with the buy menu telling lies until $someone_else figures out a fix
14:21*andythenorth wonders if that sentence makes any sense ^^ :P
14:22-!-pugi [] has joined #openttd
14:25<Eddi|zuHause>andythenorth: that's why you should have a separate callback just for the buy menu. to avoid all non-buy-menu variables
14:25<andythenorth>I do
14:26<andythenorth>you can't access var 40 (consist info) in the purchase menu
14:27<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
14:27<andythenorth>I had a couple more ideas I should maybe try though
14:28<andythenorth>I could try lying to cb 16 is one idea (fake the consist itself)
14:28<andythenorth>that might work
14:29-!-hanf [] has joined #openttd
14:29<andythenorth>such a silly problem :D
14:31<Eddi|zuHause>you could circumvent that by having separate vehicle IDs for front and other vehicles
14:31<Eddi|zuHause>(if i understand the problem right)
14:33<andythenorth>they have separate IDs
14:33<andythenorth>let me test my newest idea :)
14:35<+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?
14:36<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.
14:37*andythenorth thought that cargos already had an ID-based equivalent type property. Seems I was confusing that with industries.
14:38<+michi_cc>andythenorth: You still need to handle CB 16 in the purchase menu.
14:39<andythenorth>ok, I'll try that and zero the vehicle capacities
14:39<andythenorth>or build a different number of vehicles in cb 16 :P
14:39<andythenorth>which might not be valid
14:41-!-DOUK [] has joined #openttd
14:46<andythenorth>cheating cb16 appears to work just fine
14:46-!-mahmoud [] has quit [Ping timeout: 480 seconds]
14:46<@Yexo>"Keep in mind that this proposal is not for TTDPatch nor the current versions of OpenTTD." <- right, so we're discussing nothing
14:47-!-LordAro_ [] has joined #openttd
14:47<andythenorth>he simply proposes deleting labels altogether
14:47<andythenorth>not a bad aim
14:47<andythenorth>can't see that happening :P
14:47-!-LordAro is now known as Guest16935
14:47-!-LordAro_ is now known as LordAro
14:48<andythenorth>refits based only on classes would certainly work
14:48<LordAro>should probably set it to do that automagically, tbh...
14:49<LordAro>(i'm talking about me, not anything newgrf-ish :) )
14:53<LordAro>am i still connected?
14:53<LordAro>things have gone dead
14:53<@Terkhen>if what you says appears there, you are connected
14:53<LordAro>seems so :)
14:54<LordAro>update manager seems to sap most of the cpu/memory so pc appears slow, i think...
14:56<LordAro>question: linux antivirus. any use?
14:56<@Terkhen>they exist?
14:57<LordAro>indeed, clamav, bitdefender, couple of others
14:57<LordAro>none of them seem to work particularly well though
15:00<andythenorth>apparently me and george drove oztrans away :o
15:01<andythenorth>oh dear :|
15:01<LordAro>shame on you
15:02*LordAro deletes 'newgrfreadmedev' branch
15:03<+michi_cc>andythenorth: Do any of your GRFs work on TTDP? As he was targeting only that can't really have been you.
15:03-!-KillerByte [] has joined #openttd
15:03*LordAro creates 'readmeviewerdev' branch :)
15:04<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. "
15:05<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)
15:06<KillerByte>RPM's were fine last time I checked
15:06<@Alberth>LordAro: linux antivirus is typically used at mail servers for checking mail for non-linux systems :)
15:07<Rubidium>KillerByte: we have no control over Ubuntu's packages. It's something Ubuntu (refuses) to update frequently
15:07<Rubidium>(Ubuntu's packages being the packages in Ubuntu's repository, not the Ubuntu packages on our website)
15:07<TinoDidriksen>Could make a launchpad ppa
15:09<@Alberth>KillerByte: You could also download a nightly and unpack it in your $HOME rather than install it centrally
15:11<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
15:12<Rubidium>KillerByte: then you have to become an Ubuntu maintainer/developer
15:13<Rubidium>and only then new versions get into new releases of Ubuntu, or you make a PPA
15:14<LordAro>i thought blathijs was our ubuntu maintainer?
15:16<Rubidium>LordAro: there is no Ubuntu maintainer
15:16<Rubidium>blathijs makes the package for Debian which eventually, after a long time, trickle into Ubuntu
15:16<Rubidium>Ubuntu has *no* security support whatsoever
15:16<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
15:17*andythenorth has an idea, it's fiddly, but not bad. Documentation would be an arse for it :P
15:17<andythenorth>- parameter in FIRS: 'more classes' 'fewer classes'
15:17<KillerByte>I am looking at launchpad btw
15:21<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
15:21-!-Snail_ [] has joined #openttd
15:25<andythenorth>cb 16 has a counter
15:25<andythenorth>that should help :P
15:26<andythenorth>let's try fix #7
15:26<andythenorth>or so
15:27<Snail_>hi there
15:28<andythenorth>hmm, no way to pass cb 16 info to cb 36. Scrub that idea
15:28<andythenorth>hi Snail_
15:28<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
15:28<@peter1138>OpenTTD II :D
15:28<Snail_>I tried to change them, but I just noticed someone just changed the back to the previous (slightly incorrect) way
15:29<Snail_>yes but it might be confusing for players
15:29<Snail_>it's about refitting and waiting for *full load* or for *any full load*
15:29<@peter1138>andythenorth, basically what wallyweb is proprosing is already doable
15:30<andythenorth>yup, he's describing some fraction of the current spec
15:30<@peter1138>proposing, too
15:30<@peter1138>simply by not using the refit bitmask, you've got it
15:30<andythenorth>apropros of the spec
15:30<Snail_>what is the difference between "unload and wait for full load", and "unload and wait for *any* full load"?
15:30<andythenorth>BUT if only we'd done that, OzTrans would still be here :O
15:30<@peter1138>you can still use labels to draw specific cargo
15:31<@peter1138>Snail_, if the vehicle can load multiple cargo types, it will finish loading when any one of them is full
15:31<andythenorth>peter1138: except wally appears to think they should be removed : )
15:31<@peter1138>otherwise it has to be completely full
15:31<@peter1138>andythenorth, wally doesn't understand the technical side
15:31<andythenorth>neither does andythenorth :P
15:31<andythenorth>grr. I can't lie to cb16, it gets sad about refittable types
15:32<andythenorth>this is...challenging
15:32<@Terkhen>Snail_: wait for any full load waits until the capacity of one of the cargos that the vehicle can carry is complete
15:32<Eddi|zuHause>Snail_: difference is waiting for _all_ cargos to be fully loaded, or only _one_ cargo to be fully lodaded
15:32<andythenorth>why will nothing accept my lies :P
15:32<Snail_>I see. thanks for the explanation :)
15:33<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...
15:33<andythenorth>does anyone know the reason var 40 not available in purchase menu?
15:33<Eddi|zuHause>Snail_: some languages have a translation topic. but not all translators read them
15:33<andythenorth>as I am writing ever more layers of code and defines to try and stop the purchase menu lying about capacity
15:34<Snail_>right... they might even not know about the forums...
15:34<andythenorth>my 'template' is gaining so much 'ifdef' that my f key is wearing out :P
15:35<Eddi|zuHause>Snail_: the translator software knows email addresses for each translator, so you can ask for contact info
15:35<Snail_>oh, ok
15:37<andythenorth>@calc 40 + 40 * 0 +1
15:37<@DorpsGek>andythenorth: 41
15:37<Eddi|zuHause>value did not change since last time :p
15:37<LordAro>andythenorth: facebook? ;)
15:39<@planetmaker>which language, Snail_?
15:39<andythenorth>mumsnet :P
15:39<@planetmaker>hm, ok, I know neither forum nor thread about it :-)
15:39<CIA-6>OpenTTD: truebrain * r23206 /trunk/ (. .hgignore): -Change: ignore .svn in .hgignore, and .hg in svn:ignore
15:40<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
15:40<Snail_>yep I couldn't find any...
15:40<@Alberth>andy: perhaps your teacher was wrong :)
15:40<Snail_>I'm writing to the translator's email address if I can get the other person's addy
15:40<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.
15:40<@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
15:40<@planetmaker>worked for German ;-)
15:41<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)
15:41<andythenorth>if you're writing a compiler or maths co-processor you don't have the luxury of refusing the sum I guess.
15:41<@planetmaker>which sum, andythenorth?
15:41<andythenorth>the one ^^^^
15:41<@planetmaker>The simple one you quoted? with the *0?
15:41<andythenorth>engineers seem to answer 1
15:41<andythenorth>for some reason
15:41<andythenorth>based on a small sample size
15:42<andythenorth>computer scientists answer 41
15:42<@planetmaker>ehm... then they missed basic math class
15:42<@planetmaker>+,- < *,/ < () ;-)
15:42<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
15:42<Eddi|zuHause>hey... nobody remembers what they did in 3rd class :p
15:42<andythenorth>I don't think order of operations is taught in the UK
15:42<@peter1138>40 + 40 * 0 + 1?
15:43<@planetmaker>Eddi|zuHause: I'm sure it appeared in the first weeks of analysis, too. Not only in school ;-)
15:43<andythenorth>not in state school anyway
15:43<@Alberth>Eddi|zuHause: not true, I still remember I made a lot of very boring sums
15:43<@peter1138>is either 1, 41 or 81
15:43<@peter1138>1, 41 or 80, even
15:43<andythenorth>peter1138: you are correct, why do so many people think it's 41?
15:43<andythenorth>it's not clearly 41 unless you have a convention on orders of operation
15:43<Eddi|zuHause>we should all learn UPN. then no brackets are needed
15:43<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.
15:43<@planetmaker>andythenorth: that convention exists universally, though
15:44<@peter1138>all programmers know that * comes before +
15:44<Eddi|zuHause>or whatever it's called in english
15:44<@peter1138>reverse polish notation
15:44<Eddi|zuHause>yes, that one
15:44<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
15:44<@peter1138>a calculator will answer 1
15:44<@planetmaker> <-- @ andythenorth ;-)
15:45<andythenorth>planetmaker: I know, my wife showed me :P
15:45<@Alberth>peter1138: depends on how good the calculator is :p
15:45<@peter1138>Alberth, simple 4 function one
15:46*Alberth does not consider such a calculator as useful
15:46<Snail_>peter1138: any chance we can add a parameter to "railtypes" to allow certain rail types only to have 90-degrees curves?
15:46<TinoDidriksen>My calculator answers 41
15:46<andythenorth>when you're ordering concrete, you don't say "let's compare calculator specs"
15:46<Snail_>I think something like this would be very useful for NG sets
15:46<valhallasw>why not Alberth? I find calculators are extremely efficient for quick calculations
15:46<@peter1138>90° bends are always ugly :p
15:46<valhallasw>much better than win-enter-calc-enter
15:46<Snail_>as they would have a real advantage in games
15:46<andythenorth>Snail_: not in my games :)
15:46<valhallasw>oh, /me should read better
15:46<Eddi|zuHause>peter1138: "minimum curve length" property
15:46<Snail_>yes, but in reality, narrow gauge tracks could have sharper bends than standard gauge
15:46<andythenorth>unfortunately the 'forbid 90 degree curves' would conflict
15:47<andythenorth>it's a painful road to make newgrfs that conflict with advanced settings
15:47<Snail_>and something like this would translate this advantage in gaes
15:47<Eddi|zuHause>valhallasw: afair you can just do win+c
15:47<andythenorth>Snail_: the advantage for me of NG is: it's awesome :)
15:47<@peter1138>also that 90° bends messes up path reservation
15:47<Snail_>right... perhaps this could be an exception to the advanced settings
15:47<@Alberth>valhallasw: useful calculators usually end up in a 'scientific' corner for me (but I use Python normally as calculator, much more convenient)
15:47<andythenorth>Snail_: with YAIM patch, NG might be really useful
15:49<Snail_>andythenorth: so that NG could have lower maintenance costs
15:49<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
15:49<valhallasw>while I can predict that for my hp-41 ;-)
15:49<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
15:50<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
15:51<andythenorth>Snail_: you could try pursuing the curve stuff Eddi|zuHause suggests, although NG is not that fast anyway
15:51<Eddi|zuHause>Snail_: that would force the heavier trains to use _much_ longer curves
15:51<Eddi|zuHause>but there was some support for that missing
15:51<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
15:51<Snail_>Eddi|zuHause: yes that's true. But NG trains' max speed is usually 50km/h or below (as andy said)
15:52<andythenorth>you can pin NG on the side of a mountain, less so for standard gauge
15:52<Snail_>andythenorth: but in OTTD all the slopes are equally steep... aren't they?
15:52<Eddi|zuHause>the current spec only provide very limited control over curve speed
15:52<CIA-6>OpenTTD: rubidium * r23210 /trunk/src/ (101 files in 3 dirs): -Codechange: generate the GetClassName function for the AI classes programmatically
15:52<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
15:53<andythenorth>it might be interesting to have to level mountains a bit more to build standard gauge
15:53-!-Snail_ [] has quit [Read error: Connection reset by peer]
15:53-!-Snail_ [] has joined #openttd
15:55<Snail_>oh, so "steep slopes" mean consecutive uphill tracks? not broken by horizontal tracks in between?
15:55-!-Devroush [] has joined #openttd
15:56<@planetmaker>Snail_: no, it refers to one tile
15:56<andythenorth>screenshot would answer this best
15:56<@planetmaker>there exist tiles - without rail - which have two height difference
15:56*andythenorth is making omelette however
15:56<@planetmaker>wiki actually
15:56<@Alberth>at the right, 23, 27, 29, 30
15:57-!-Alberth [] has left #openttd []
15:57<@planetmaker>the last four
15:57*LordAro just bought a new monitor
15:57<Snail_>planetmaker: ok, I see
15:58<@Yexo> <- pretty thanks to FooBar :)
15:58<Eddi|zuHause>LordAro: they're all cute and cuddly in the beginning, but when they grow up...
15:58<LordAro>(screen monitor, not monitor lizard :P
15:59<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
15:59<@planetmaker>oh, you can build horizontal tracks on them
15:59<andythenorth>Snail_: I don't honestly know if railtypes could be restricted by slope
15:59<andythenorth>industry tiles can
15:59<@planetmaker>possibly also up- or downslope with foundations
16:00<Snail_>right, I just tried it in a game :D
16:00-!-DDR [~chatzilla@] has joined #openttd
16:01<Eddi|zuHause>Snail_: on each steep slope, you can build 4 different rail bits
16:02<Eddi|zuHause>slope in X direction, slope in Y direction, diagonal on the upper half, diagonal on the lower half
16:02<Snail_>yep, that's true
16:03<Snail_>but this happens for all railtypes. There couldn't be an advantage for NG tracks there
16:03<Eddi|zuHause>i don't see that happening either
16:03<andythenorth>would be probably need a lot of rail-building tool modification to be possible
16:04<Eddi|zuHause>so we're back at (1) curve speed, and (2) infrastructure maintenance
16:04<andythenorth>railtype property: maximum height difference allowed on the tile? :P
16:04<andythenorth>0, 1, 2
16:04<Eddi|zuHause>andythenorth: what are you going to do with a railtype that can be only placed on flat tiles?
16:05<andythenorth>0 is a pathological evil case :D
16:05<Eddi|zuHause>andythenorth: this totally makes no sense
16:06<Snail_>one more thing I was thinking of was rackrail-equipped NG tracks. I already drew graphics for such tracks and vehicles
16:06<Snail_>but they would need a new acceleration system
16:06<andythenorth>you can adjust TE according to railtype info?
16:06<andythenorth>rackrail = TE ~ 1
16:07<Snail_>theoretically yes, I did some tests there
16:07<Eddi|zuHause>rack rail might be particularly interesting with more height levels
16:07<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)
16:09<Snail_>it would be very useful to be able to define a new acceleration model for certain tracks...
16:09<Eddi|zuHause>maybe openttd handles the steepness all wrong
16:10<andythenorth>does rackrail accelerate faster?
16:10*andythenorth visits the krug pages..
16:10<Eddi|zuHause>andythenorth: max_te has only effect on very low speeds. otherwise, pure power is relevant
16:11<andythenorth>as long as you have adhesion, HP is the limiting factor...?
16:11<Snail_>yes, this is why rackrail in-game has no real advantage unless we allow custom acceleration systems for railtypes
16:11<LordAro>why's my ottd-auto-update script stopped working?...
16:12<Eddi|zuHause>LordAro: because you didn
16:12<@Terkhen>it's on strike
16:12<Eddi|zuHause>'t maintain it?
16:12<andythenorth>Snail_: fake the HP?
16:12<Eddi|zuHause>it felt lonely
16:13<Snail_>but then rackrail engines would be disproportionately powerful w.r.t. other locos :D
16:13<andythenorth>only when on rack
16:13<@Terkhen>Snail_: there are custom acceleration system for rail types
16:13<LordAro>ah, only .tar.xz instead of .tar.gz :)
16:14<@Terkhen> <---
16:14<@Terkhen>just only two :)
16:14*Snail_ goes read the wiki
16:14<andythenorth>oops sorry
16:14<andythenorth>terkhen beat my paste
16:14<Eddi|zuHause>Snail_: have you tried your test series with a very high slope setting, like 7% or more?
16:14<LordAro>how to untar a .tar.xz file (from command line)
16:14<Snail_>oh yes, monorail or maglev. But can we create custom ones?
16:14*LordAro bothers to google something :)
16:15<@Terkhen>Snail_: yes, as a patch to OpenTTD source code
16:15<@Terkhen>LordAro: I don't know much about tar, I always use tar xvf and it "works"
16:15<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
16:15<Snail_>Terkhen: you mean I would have to create my own patch?
16:16<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
16:16<@Terkhen>yes, the only way to add new acceleration models is to change the source code
16:16<@planetmaker>LordAro: possibly tar xfvz file.tar.xz
16:16<Eddi|zuHause>Snail_: the main thing that should do would be to make it really ineffective to have multiple consecutive slopes on normal rail
16:17<LordAro>ty planetmaker / b_jonas
16:17<b_jonas>if you don't have xz installed either, you can find it at or try to download the same tarball gzip-compressed somewhere (it's usually available)
16:17<Snail_>Eddi|zuHause: I can see that. It would force players to alternate slopes with flat pieces of track
16:18<@Terkhen>Snail_: I would like that... but some players would not. That would force to include Yet Another Setting
16:18-!-Guest16935 [] has quit [Quit: ajax IRC Client]
16:19<Eddi|zuHause>maybe there could be newgrf-provided acceleration models? but that needs very optimized code, because it's run often
16:19<Snail_>Terkhen: hmm. Right. Setting slopes to 7% could just be something "recommended" when playing with a certain set :D
16:20<@Terkhen>Eddi|zuHause: I'm not sure about the feasability of that... acceleration code needs to as optimized as possible
16:20<Snail_>Eddi|zuHause: yes, but would a new acceleration model only affecting rackrail tracks be run that often?
16:21<Eddi|zuHause>Snail_: twice every tick for each vehicle
16:21<@Terkhen>Snail_: my first implementation of realistic acceleration for road vehicles increased execution time on some testing maps to 150%
16:21<Snail_>Eddi|zuHause: really? even on tracks other than rackrail? souds like a lot
16:21-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
16:21<@Terkhen>so yes, you need to be careful with that code :)
16:21<Snail_>ew, I see :)
16:23<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
16:23<Eddi|zuHause>Snail_: by then you've already passed through several newgrf code layers
16:24<Snail_>Eddi|zuhause: true. This makes sense
16:25<andythenorth>frosch123: (slightly) unrelated to classes, I had an idea for another misc cargo flag: 'cargo is sensitive to aging'
16:25<andythenorth>for use not with refits...but the obvious cb for that prop
16:25<andythenorth>prop / flag
16:26<Eddi|zuHause>andythenorth: but wouldn't that be a matter of payment rates? why would the wagon care about that?
16:27<Eddi|zuHause>andythenorth: unless you give a reason _why_ the aging is relevant, what's the wagon gonna do about it?
16:27<andythenorth>wagon knows the label and classes
16:28<andythenorth>up to the author what the wagon does about it
16:28<Eddi|zuHause>andythenorth: so still, at what point is the flag relevant?
16:28<andythenorth>it's not, if you know the labels
16:29<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?
16:29<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
16:29<Eddi|zuHause>andythenorth: so why would i put mail into a refrigerated wagon?
16:30<andythenorth>Eddi|zuHause: in that case how does the wagon choice affect mail at all? Pick a faster vehicle :P
16:31<b_jonas>or a faster wagon
16:31<andythenorth>armoured vs. refrigerated would be a better case against my idea
16:31<Eddi|zuHause>andythenorth: exactly. why provide a flag that the vehicle set author doesn't care about and the user doesn't see?
16:32<b_jonas>Eddi|zuHause: for AIs?
16:32<Eddi|zuHause>b_jonas: then make AIs read the payment rates
16:32<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
16:33<andythenorth>it might not stack up mind
16:33-!-DayDreamer [] has quit [Quit: Leaving.]
16:33<b_jonas>Eddi|zuHause: true
16:33<Eddi|zuHause>andythenorth: so if the vehicle set chooses to provide a refrigerated wagon with aging bonus, then he needs the refrigerated class
16:34<@Terkhen>yes, ogfx-rv does that
16:34<andythenorth>and the covered class, and the powderised class...and the armoured class and so forth
16:34<Eddi|zuHause>andythenorth: that's a case you won't find a better solution for
16:35<andythenorth>Eddi|zuHause: and that's the *only* way we can think of to do it?
16:36-!-DDR [~chatzilla@] has joined #openttd
16:36<andythenorth>so why does the vehicle set author care about this if it's classes, but not if it's flags?
16:36<andythenorth>and the player doesn't see it anyway, so why bother?
16:36<Eddi|zuHause>andythenorth: why overcomplicate things? refrigerated wagon: OR mask = refrigerated, AND NOT mask = empty. full support for all known and future refrigerated cargos
16:36<Eddi|zuHause>andythenorth: with a flag, you need to employ a special callback, etc.
16:37<andythenorth>don't we have that cb already?
16:37<Eddi|zuHause>no, it was only a future suggestion
16:38<Eddi|zuHause>having or not having is irrelevant, though. you still need more implementation effort
16:38<Eddi|zuHause>for something that is currently setting _one_ bit
16:38<@Terkhen>good night
16:38<TrueBrain>sleep well Terkhen
16:38<@Terkhen>and keep things simple :)
16:39<Eddi|zuHause>andythenorth: we have a refit _cost_ callback, but not a _refitability_ callback
16:39<andythenorth>I don't care about refittability
16:39<andythenorth>refittability is - soon -a solved problem
16:39<@planetmaker>night Terkhen
16:40<andythenorth>what I'm puzzled about is the cargo aging cb :)
16:40<andythenorth>I thought that was implemented?
16:40<Eddi|zuHause>that is implemented, yes
16:40<@planetmaker>that's cb36
16:40<andythenorth>I was looking in the cb list for it :)
16:40<Eddi|zuHause>but why would i put wool into a refrigerated van?
16:40<Eddi|zuHause>only to then decide that it's not getting the aging bonus?
16:41<andythenorth>these are reasonable objections ;)
16:41<andythenorth>but you could if you wanted do such a thing
16:41<andythenorth>up to you
16:41<LordAro>excellent, finally got it to work
16:41<LordAro>tar -xvf worked, FYI
16:41<Eddi|zuHause>rather allow only refitting to the proper cargos, and don't use the aging callback at all
16:42<Eddi|zuHause>for the other cargos there are regular wagons
16:42<andythenorth>I'm not arguing against that, I'm looking at other interesting gameplay ideas
16:42<andythenorth>for some definition of 'interesting'
16:42<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
16:42<Eddi|zuHause>good. but i don't see the use in this instance
16:42<Snail_>(as I posted on the forum :D )
16:42-!-DDR [~chatzilla@] has quit [Quit: ChatZilla 0.9.87 [Firefox 7.0.1/20110928224508]]
16:43<Eddi|zuHause>Snail_: post that on the bugtracker
16:43<andythenorth>Eddi|zuHause: it's probably better handled by knowing about specific cargos, but that seems kind of tiresome
16:43<Snail_>oh, ok
16:44<Snail_>I thought it was a "feature". I'll post it in the "openttd problems" board then
16:45<Eddi|zuHause>Snail_: on the forum it might be missed
16:45<Eddi|zuHause>post it on
16:46<Snail_>Eddi|zuHause: great! thanks :)
16:46-!-KillerByte [] has quit [Remote host closed the connection]
16:48<andythenorth>Eddi|zuHause: imo this is another point in favour of your additional specific classes then :|
16:48<andythenorth>it allows interesting custom aging
16:49<andythenorth>I could transport any bulk by open wagon, but set a penalty on that vehicle for cargos requiring covered (e.g. grain)
16:49<andythenorth>is that an abuse of classes, or correct?
16:50<z-MaTRiX>should i do a few more bytes comparing 2 variables with zero and increase performance instead of floatingpoint dividing by zero?
16:50<z-MaTRiX>(in any other case it will be only 2 extra comparisons)
16:51<z-MaTRiX>a line with same end and starting point for example...
16:52<Eddi|zuHause>andythenorth: that's a corner case, because it's not particularly "realistic". (you can just cover the wagon with a tarpaulin)
16:53<andythenorth>swap grain for cargo example of your choice - I don't mind ;)
16:54<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
16:55<andythenorth>we could mark it as "this class is stupid"
16:55<andythenorth>you can trade covered for refrigerated in my case above if you wish
16:55<Eddi|zuHause>andythenorth: you can use it in the graphics selection to decide whether to draw a tarpaulin or show the cargo
16:56<andythenorth>that's the voice of someone who hasn't drawn 10 bazillion cargo sprites yet
16:56<andythenorth>tarpaulin ftw
16:57<Eddi|zuHause>right, i wanted to sort out some recolour tables for magic-pink cargo graphics
16:59<andythenorth>bulk is easy :P
17:00<Eddi|zuHause>we had to patch several pieces for the magic-pink idea to work :p
17:02<andythenorth>I know last time I looked at it I gave up
17:02<andythenorth>flood-fill in source turned out to be easier
17:02<Eddi|zuHause>recolouring+companycolour is tedious, i imagine :)
17:03<Eddi|zuHause>luckily, i have a code generator, which takes most of the tedious tasks away :)
17:03<andythenorth>iirc it's actually impossible if you use both cc
17:03<Eddi|zuHause>actually it is possible, you just need several thousand recolour tables
17:04<Eddi|zuHause>GermanRV is 50% recolour tables :p
17:12-!-Devroush [] has quit []
17:13<Snail_>andythenorth: you can use 2cc and use another color (for instance pink, as mentioned) for the cargo
17:16-!-KritiK [~Maxim@] has quit [Quit: Leaving]
17:17<andythenorth>it's still tempting for FISH
17:18-!-TGYoshi [~TGYoshi@] has quit [Quit: Poof]
17:18<andythenorth>but tmwftlb
17:19*andythenorth -> bed
17:19*peter1138 ponders scrapping his EZ
17:20*andythenorth scrapped all attempts to stop the buy menu lying :(
17:23-!-pjpe [] has joined #openttd
17:23<andythenorth>good night
17:23-!-andythenorth [] has quit [Quit: andythenorth]
17:23<+michi_cc>peter1138: What's wrong with your EZ?
17:27-!-Kurimus [] has quit []
17:29<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
17:31<LordAro>night all
17:31<Snail_>Eddi|zuHause: you mean the cargo is colored in pink? or the vehicle?
17:32-!-LordAro [] has quit [Quit: "Time is an illusion. Lunchtime doubly so."]
17:32<@planetmaker>good night
17:32<Eddi|zuHause>Snail_: the cargo
17:33<Snail_>right. So the vehicle can be in 2cc blue and green, which get replaced in-game?
17:34<Eddi|zuHause>Snail_: in my case the vehicle is not recoloured, but in GermanRV it is
17:36<Snail_>Eddi|zuHause: right, I see
17:39-!-JVassie [~James@] has quit [Ping timeout: 480 seconds]
17:41-!-supermop_ [] has joined #openttd
17:44-!-Biolunar [] has quit [Quit: All your IRC are belong to us!]
17:53-!-frosch123 [] has quit [Remote host closed the connection]
17:55-!-DOUK [] has quit [Ping timeout: 480 seconds]
17:56-!-valhallasw [~valhallas@] has quit [Quit: leaving]
18:18-!-sla_ro|master [~slaco@] has quit []
18:30-!-heffer [] has quit [Ping timeout: 480 seconds]
18:31-!-heffer [] has joined #openttd
18:37-!-Neon [] has quit [Quit: Python is way too complicated... I prefer doing it quickly in C.]
18:43-!-Wolf01 [] has quit [Quit: Once again the world is quick to bury me.]
18:49-!-Progman [] has quit [Remote host closed the connection]
18:52-!-Adambean [] has quit [Quit: Gone fishing]
18:54<@peter1138>michi_cc, the stuff for gui sprites is irritating
18:56<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
18:56<Eddi|zuHause>possibly this allows you to have a setting about small/normal/large gui
19:05-!-DDR [~chatzilla@] has joined #openttd
19:06-!-Brianetta [] has quit [Quit: Tschüß]
19:07-!-Brianetta [] has joined #openttd
19:07-!-TWerkhoven [] has quit [Quit: He who can look into the future, has a brighter future to look into]
19:10-!-SystemParadox [] has quit [Remote host closed the connection]
19:16-!-Cybertinus [] has quit [Remote host closed the connection]
19:31-!-ptr [] has quit [Quit: Zzzzzz]
19:37-!-Eddi|zuHause [] has quit [Remote host closed the connection]
19:37-!-hanf [] has quit [Quit: Leaving]
19:59-!-Eddi|zuHause [] has joined #openttd
20:13-!-DDR [~chatzilla@] has quit [Ping timeout: 480 seconds]
20:18-!-Eddi|zuHause [] has quit [Remote host closed the connection]
20:22-!-Brianetta [] has quit [Quit: Tschüß]
20:22-!-Brianetta [] has joined #openttd
20:23-!-Brianetta [] has quit [Remote host closed the connection]
20:23-!-Brianetta [] has joined #openttd
20:23-!-Brianetta [] has quit [Remote host closed the connection]
20:28-!-DDR [~chatzilla@] has joined #openttd
20:28-!-Eddi|zuHause [] has joined #openttd
20:41-!-enr1x [] has quit [Remote host closed the connection]
20:45-!-enr1x [] has joined #openttd
20:57-!-pugi [] has quit [Quit: I reject your reality and substitute my own]
21:14<Mazur>Hah! Succeeded at last! Perfect failsafe 3->2.
21:14<Mazur>Which V will tear to pieces as soon as he sees it, of course.
21:20-!-HerzogDeXtEr [] has quit [Read error: Connection reset by peer]
21:22-!-Brianetta [] has joined #openttd
21:25-!-Brianetta [] has quit []
21:25-!-Brianetta [] has joined #openttd
21:26-!-Brianetta [] has quit []
21:53-!-Mazur [] has quit [Read error: Connection reset by peer]
21:53-!-Mazur [] has joined #openttd
21:55-!-Elukka [] has quit []
22:07-!-glx [glx@2a01:e35:2f59:c7c0:3824:60d4:4cb:b2b3] has quit [Quit: bye]
22:26-!-rhaeder [] has joined #openttd
22:26-!-Snail_ [] has quit [Quit: Snail_]
22:30-!-rhaeder1 [] has quit [Ping timeout: 480 seconds]
---Logclosed Mon Nov 14 00:00:28 2011