IRC logs for #openttd on OFTC at 2011-05-07
⏴ go to previous day
00:04:47 *** Progman has joined #openttd
00:10:40 <Eddi|zuHause> i think my first contact with delphi was 1997-ish
00:10:55 <Eddi|zuHause> i'm fairly sure it was delphi 2
00:14:35 <Eddi|zuHause> i was familiar with borland pascal 7 for a while already back then
00:15:49 <Eddi|zuHause> where stuff came on 13-ish diskettes :p
00:15:58 <CIA-1> OpenTTD: frosch * r22432 /trunk/src/smallmap_gui.cpp: -Codechange: Simplify smallmap colour constants using some more specialised macros.
00:16:01 <frosch123> don't miss the "bonus disk"
00:16:07 <frosch123> which was the best of all
00:16:14 <Eddi|zuHause> not sure i remember that
00:16:30 <frosch123> borland pascal 7 was the first version to include the rtl source
00:17:02 <Eddi|zuHause> hm... i'm fairly sure i never touched any of that
00:17:08 <frosch123> turbo pascal did not have any public rtl sources
00:23:01 <CIA-1> OpenTTD: frosch * r22433 /trunk/src/ (gfx_func.h smallmap_gui.cpp): -Add/Fix: Add constants for the palette colours used in the smallmap and fix some windows palette indices.
00:25:35 <Eddi|zuHause> i also used delphi 6 later
01:36:39 *** supermop has joined #openttd
01:44:20 *** rhaeder has joined #openttd
02:13:48 *** Dreamxtreme has joined #openttd
02:19:07 *** rhaeder1 has joined #openttd
02:25:49 *** rhaeder has joined #openttd
02:54:12 *** Dreamxtreme has joined #openttd
02:57:38 <Eddi|zuHause> i think roadveh_cmd.cpp:569:EnumCheckRoadVehClose must be adapted for the shorter vehicle thing to work correctly
03:38:53 *** rhaeder1 has joined #openttd
03:40:56 *** roboboy has joined #openttd
04:00:55 *** sla_ro|master has joined #openttd
04:56:17 *** Eddi|zuHause has joined #openttd
05:38:28 <__ln__> you're both up too early
05:39:14 <Yexo> I've been awake for 2,5 hours, so yes, definitely too early
05:41:35 <Terkhen> we are having the biggest thunderstorm I remember, I couldn't sleep :/
06:01:37 *** Kurimus has joined #openttd
06:17:34 *** Cybertinus has joined #openttd
06:35:38 <planetmaker> he, I usually sleep especially well during thunderstorm :-)
06:37:19 *** TWerkhoven has joined #openttd
06:40:54 <Terkhen> me too, but this time all windows were vibrating very noisily with each thunder
06:46:35 <planetmaker> hm, ok, then it will be hard :-)
07:01:59 *** DayDreamer has joined #openttd
07:03:05 *** DayDreamer has left #openttd
07:08:25 *** |Jeroen| has joined #openttd
07:27:51 *** ProfFrink has joined #openttd
07:28:43 *** DoubleYou has joined #openttd
07:29:42 *** andythenorth has joined #openttd
07:34:28 *** ProfFrink is now known as Prof_Frink
07:41:40 * Lakie ponders requesting an extension to renum
07:42:47 <Terkhen> hi andythenorth and Lakie
07:43:53 * andythenorth ponders requesting an extension to Lakie
07:43:57 <andythenorth> and maybe also Terkhen
07:44:21 <Lakie> I was thinking of maybe asking for the rpn to be extended to the escapes
07:44:46 <Lakie> So I could use things like \w(0x8000 VEH_ID +)
07:45:15 <Lakie> Probably won't happen though. :/
07:46:57 *** Hyronymus has joined #openttd
07:52:12 *** Alberth has joined #openttd
07:52:12 *** ChanServ sets mode: +o Alberth
07:58:49 <planetmaker> Lakie: most importantly, grfcodec has to be able to digest renum's output.
07:59:12 <planetmaker> renum is just for you to check. Grfcodec writes the grf.
07:59:20 <Lakie> But it seems the let statements in renum are broken anyway
07:59:52 <planetmaker> [09:44] Lakie So I could use things like \w(0x8000 VEH_ID +) <-- you mean to operate symbolically?
08:00:19 <Lakie> Na, renum would workout the calculation and store either \w<val> or the raw hex value
08:00:50 <Lakie> Which in a preprocessing environment is quite useful in my opinion
08:00:53 <Alberth> grfcodec supports postfix expressions? wow
08:00:54 <planetmaker> nforenum was never an essential processing step, was it?
08:01:18 <planetmaker> but adding that to grfcodec certainly wasn't a bad idea
08:01:42 <Lakie> Well, it at one point supported @@LET which put values to names, which one used later in the nfo
08:01:58 <Lakie> renum used to just calc then store the result where it hit the namee
08:02:29 <Lakie> But it seems the @@LET command no longer works at all
08:04:11 <Lakie> On the bright side, raw rpn on the sprite lines work correctly with renum.
08:05:22 <Lakie> Never mind, let does work, just not how I figured
08:07:43 <Lakie> Might be possible, probably take a while to link up the rpn system to the escapes though
08:09:10 <Lakie> And also allowing hexidecimal numbers in rpn statements, heh, seems like it could be a fair amount of work
08:18:03 *** roboboy has joined #openttd
08:19:08 <Alberth> I would implement (\wx8000 VEH_ID +) instead (or more likely allow infix operators :) )
08:35:51 *** lasershock has joined #openttd
08:49:02 *** Brianetta has joined #openttd
09:10:56 *** eQualizer has joined #openttd
09:35:55 *** rhaeder has joined #openttd
09:49:47 *** fmauneko has joined #openttd
10:04:26 *** KenjiE20 has joined #openttd
10:09:04 *** frosch123 has joined #openttd
10:20:51 <CIA-1> OpenTTD: terkhen * r22434 /trunk/src/newgrf_industries.cpp: -Feature [FS#4591]: [NewGRF] Allow to filter by town of the current industry when using industry variable 0x68 (Yexo)
10:22:22 *** Progman has joined #openttd
10:22:35 <andythenorth> means I can fix various things in FIRS ;)
10:23:20 *** sla_ro|master has joined #openttd
10:27:34 <andythenorth> what happens to savegames if I change a the ID of cargo?
10:28:55 <andythenorth> science could tell me, but I'm away from ottd right now
10:29:14 <Terkhen> I don't know but they probably get messed up badly
10:29:34 <Terkhen> I wouldn't mind it much, such things are to be expected with nightly versions
10:29:48 <andythenorth> FIRS 0.7.0 will break 0.6.4 savegames anyway
10:30:07 <andythenorth> I want to incur maximum breakage now, and hopefully no more until 1.0
10:30:41 <Terkhen> savegame incompatibility between major versions should also be expected IMO
10:30:55 <frosch123> andythenorth: esp. all vehicle will keep on carrying the same cargo ID
10:31:36 <frosch123> al constructed industries will continue to accept and produce the same IDs as well though
10:31:59 <andythenorth> I have a conflict with NARS 2 regearing, and need to shift one cargo to deal with it
10:32:06 <andythenorth> that cargo isn't in 0.6.4 though...so might be ok
10:32:17 <andythenorth> it is in my beautiful YACD game :(
10:42:38 <andythenorth> refit at stations?
10:42:54 <andythenorth> go to A, refit to best combination of cargos?
10:49:15 <Alberth> more likely in the depot, as we don't have station refit currently
10:49:41 <andythenorth> that means depot would need to query next station to see what cargo is waiting?
10:49:53 <andythenorth> and the cargo could have cleared by the time the vehicle arrives...
10:50:00 <andythenorth> unless it's then reserved for this vehicle
10:50:18 <planetmaker> andythenorth: a general concept of TTD is that you know what to transport beforehand
10:50:25 <planetmaker> and not only the cargo class
10:51:03 <Amis> What can make an primary industry drop production by 50% twice in 5 minutes on steady economy?
10:51:06 <andythenorth> one idea was packing cargo inside other units
10:51:49 <Amis> Screw you, randomness :/
10:52:27 <andythenorth> for e.g. box cars, it doesn't add much to have specify they are for goods, food etc
10:52:37 <andythenorth> more so with intermodal vehicles
10:52:46 <Rubidium> Amis: think of industry production as rolling a dice. Every X minutes a dice is thrown. If it's 1 then production lowers, if it's 2 or 3 the production increases and if it's 4, 5 or 6 nothing happens
10:53:30 <Rubidium> Amis: so on average you're more likely to roll 2 or 3 than 1, but it will happen that you roll 1 twice successively
10:53:57 <Amis> Well that dice screwed up my economy by decreasing a coal mine from 1080 tonnes to 270 in no time
10:54:26 <andythenorth> production decreases are boring
10:54:34 <andythenorth> try an industry newgrf ;)
10:54:42 <andythenorth> manual industries prevents decreases?
10:54:54 <Amis> On the other, it is really life-like... industries can screw up everything in real life by going boom
10:55:49 <Rubidium> but then there's the government that cheats some companies into not going boom
10:55:51 <planetmaker> good that it is a game :-)
10:58:50 *** andythenorth_ has joined #openttd
11:21:49 *** andythenorth has joined #openttd
11:23:43 <Wolf01> <Rubidium> but then there's the government that cheats some companies into not going boom <- looks like Italy
11:25:49 <planetmaker> Wolf01: not only there. Every government. Or we'd have way less banks right now
11:55:28 *** Brianetta has joined #openttd
12:09:30 *** Biolunar has joined #openttd
12:12:27 *** Intexon has joined #openttd
12:12:57 *** ZirconiumX has joined #openttd
12:16:14 <ZirconiumX> there's a guy pretending to be OBL
12:17:11 <planetmaker> and who or what is OBL? Not that I really care...
12:17:40 <frosch123> planetmaker: a victim of assasination
12:18:12 <planetmaker> well, then "one big looser" is also correct
12:18:16 <Eddi|zuHause> like JFK, only 50 years later
12:18:37 <|Jeroen|> how does a assasinated person chat ?
12:18:58 <frosch123> religious people can do that :p
12:19:00 <planetmaker> sub space messages from the lower spheres from hell. Or similar
12:19:31 <planetmaker> works also with inverted sign
12:19:49 <ZirconiumX> the guy's from ozzie
12:23:29 *** Chris_Booth has joined #openttd
12:57:57 * ZirconiumX would celebrate - but openttd still doesn't compile
13:01:35 <Rubidium> or ain't it ready yet?
13:09:11 * ZirconiumX has installed X.Org using MacPorts - and doesn't have a pig's ear how to use it
13:12:28 <Eddi|zuHause> get a useful OS.
13:12:56 <ZirconiumX> Funny really how stupid I am
13:13:09 <ZirconiumX> Mac OS X already *has* XFree86
13:20:05 *** sla_ro|master has joined #openttd
13:22:16 *** fmauneko has joined #openttd
13:23:22 <Zuu> michi_cc: Congratulations! I don't think I have time to sit at the computer for long at the moment, but tonight I will probably find time to compile + post a win binary if noone beats me to it.
13:24:50 <Rubidium> Zuu: then I could easily beat you ;)
13:24:56 <Rubidium> just need permission to do so ;)
13:28:38 <Eddi|zuHause> actually... why? gpl gives you all the permissions you need?
13:28:47 <Zuu> Rubidium: If you beet me by doing it with the compile farm and add it to finger.openttd.org (or the openttdcoop finger), I would happily add it to OpenTTDAU.
13:30:16 <michi_cc> Most big bugs seem to be found, so doing binaries is okay. It's only that I definitely will break savegame compatibility on the next release.
13:31:33 <Terkhen> Zuu: don't forget to keep the pdb file :)
13:32:18 <michi_cc> How about I make a 2.0 right now that changes the enable setting but nothing more, so that can serve as a baseline till trunk bumps (or something bug necessitates it)?
13:32:30 <michi_cc> That one could get proper binaries.
13:32:41 <Yexo> is the setting currently bool? you can change that to uint8 without savegame bump
13:32:58 <Yexo> with 0=off, 1=current form, 2=distribution
13:33:22 <michi_cc> No, I need to split that to several settings. Currently it is off, only pax, only industry, all.
13:33:30 <Eddi|zuHause> the old setting is off/pax/other/all
13:33:32 <Rubidium> Eddi|zuHause: because I was asked not to do it yet
13:34:47 <michi_cc> Which cargo groups should get their own settings? Right now the two groups are everything with town effect of pax and mail (e.g. also tourists), and everything else.
13:35:23 <Eddi|zuHause> there's also TE_GOODS
13:35:47 <Eddi|zuHause> and the default cargo valuables kinda would benefit from destinations as well
13:36:21 <michi_cc> and TE_FOOD and TE_WATER. But does it really need a switch for every single kind of cargo?
13:37:23 <Terkhen> michi_cc: IMO it should be a newgrf property of cargos... passengers and mail would have the same value, there could be another for goods and so on
13:38:05 <Yexo> I disagree, it's something that users should be able to change and not only by newgrfs
13:38:39 <Terkhen> what I mean is that the setting should not check specific types of cargos, just cargos with a given property
13:39:00 <Terkhen> the setting stays, but which cargos belong to each category can be set by newgrf
13:39:07 <Yexo> but that is exactly what michi_cc appears to be currently doing, checking the town effect
13:39:55 <Eddi|zuHause> town effect is a good first approximation, but it wouldn't cover valuables, and tourists might want a different algorithm than passengers
13:40:03 <Terkhen> I'm not sure if town effect is exactly the same, there might be cases where it would be desirable to set a given cargo to another category
13:40:20 *** Brianetta has joined #openttd
13:40:20 <Terkhen> ^but I agree with that, what I'm talking about can wait until yacd is more consolidated
13:40:57 <Yexo> alternative would be by cargo class
13:41:28 <Yexo> Eddi|zuHause: passengers and tourists are almost exactly the same from the code, is there really a need to differentiate between them?
13:41:54 <Terkhen> goods and FIRS supplies have similar cargo classes, but there are reasons for managing them differently
13:42:01 <michi_cc> The only difference between pax and tourists is that tourists are CC_EXPRESS. Makeing that an explicit settings seems very non-generic.
13:42:09 <Eddi|zuHause> Yexo: some people expressed the desire to have passengers on "full map" distribution, and tourists on "connected" distribution
13:42:38 <Yexo> imo that is way too specific, you'd end up with a setting per cargo type
13:43:34 *** rhaeder1 has joined #openttd
13:44:03 <Terkhen> if it is made a different property, passengers and tourists could easily have different values of it
13:44:28 <michi_cc> One way could be to have a setting each for TE_PASSENGERS/TE_MAIL, TE_GOODS/TE_FOOD (as cargos commonly accepted by houses), and everything else.
13:45:49 <michi_cc> TE_WATER is also a town growth cargo, but normal game has water towers for that, so as an industry-industry cargo I don't think it needs a separate switch.
13:46:00 <Yexo> "items disallowed in hand luggage: blunt and sharp objects" <- really, isn't everything either blunt or sharp by definition?
13:46:34 <Yexo> I'd maybe throw in TE_WATER with TE_GOODS/TE_FOOD, as it's essentially the same
13:48:52 <michi_cc> Any sensible idea how to split the other cargoes, (i.e. only using town effect or cargo class)? I can't really think of one.
13:49:32 <Yexo> armored/non-armored, but that is only for valuables in temperate
13:51:32 <michi_cc> Yes, that would either be a switch for valuables/gold/diamonds or would be climate dependent, which is not nice (e.g. alpine climate).
13:59:49 <michi_cc> Hmm, how to describe TE_GOODS/TE_WATER/TE_FOOD? It's not town-accepted (due to TE_WATER) and not town growth effect either (due to TE_GOODS).
14:00:08 *** Markavian has joined #openttd
14:00:34 <Yexo> TE_GOODS is not necessarily town accepted either
14:00:42 <Yexo> although for the default cargo it is
14:01:24 <Yexo> still "town as destination" describes it good enough, since watertowers are only allowed within towns
14:04:27 *** Karginator has joined #openttd
14:04:42 *** Karginator is now known as AndiK
14:09:56 *** zachanima has joined #openttd
14:11:14 *** AndiK is now known as AndiK|tire_change
14:31:43 *** Dreamxtreme has joined #openttd
14:47:27 <michi_cc> And YACD 2.0 is released.
14:49:05 <michi_cc> Rubidium: You can do binaries if you want now :) They could go onto my server, but openttdcoop would be okay as well if Ammler/pm agree.
14:50:50 <frosch123> hmm, looks like DrawLine needs an additional parameter for drawing "borders" around lines
14:52:51 <michi_cc> The interdiff between 1.2 and 2.0 isn't that big. I made proper helper functions :)
14:55:00 *** DayDreamer has joined #openttd
15:01:31 <Rubidium> michi_cc: 1) why is there a ^0 in the output of findversion.sh?, 2) it (yacd_2.0^0) does fail to compile
15:02:27 <michi_cc> Because findversion.sh was never properly test with tags, I'm preparing a patch for that right now. And is gcc being picky again?
15:05:09 <Rubidium> michi_cc: yeah, it's pretty picky
15:05:10 <Rubidium> /home/rubidium/openttd/special/yacd/src/ai/api/../../cargopacket.h:324:167: error: ‘INVALID_CARGO’ was not declared in this scope
15:05:27 <Rubidium> In file included from /home/rubidium/openttd/special/yacd/src/ai/api/../../station_base.h:17:0, from /home/rubidium/openttd/special/yacd/src/ai/api/ai_airport.cpp:15:
15:05:45 <Rubidium> or do I have the wrong thing?
15:07:01 <Rubidium> git fetch && git reset --hard origin && make <- that's what I typed
15:07:02 <michi_cc> Does it work if you add #include "cargotype.h" to cargopacket.h?
15:07:35 <michi_cc> That git command is okay, YACD is in the default branch.
15:07:54 <Rubidium> yep, then it compiles
15:08:12 <Terkhen> I'm getting the same error with the patch available at the thread
15:08:39 <Rubidium> the rest is loads of the same compile warning it seems
15:08:55 *** SystemParadox has joined #openttd
15:11:58 <michi_cc> Okay, that is valid in principle, it's just that we never instantiate a CargoList directly. Nevertheless, I'll fix that as well.
15:12:49 *** AndiK|tire_change is now known as Andik
15:12:51 *** Andik is now known as AndiK
15:12:52 <Rubidium> seems to work for me (Linux)
15:14:17 <CIA-1> OpenTTD: michi_cc * r22435 /trunk/ (findversion.sh projects/determineversion.vbs): -Fix: Git revision detection would return too much when tags are involved.
15:15:23 <Rubidium> seems to be something version detectioning as well
15:15:56 <michi_cc> Yeah, what's the contents of rev.cpp?
15:16:03 *** ChanServ sets mode: +v orudge
15:16:03 *** ChanServ sets mode: +v SmatZ
15:16:05 <Rubidium> no idea, that file's gone by now
15:16:49 * AndiK is trying to integrate his separation GUI into the timetable window.
15:16:56 <AndiK> I've got a little issue with that.
15:17:27 <AndiK> Is there any way to make a WWT_TEXT enlarge the window automatically when its string is too long?
15:17:51 <AndiK> Right now it makes a cut in the middle, which I don't quite like.
15:19:02 <Yexo> add some code for it to UpdateWidgetSize
15:19:20 <Yexo> however you might need to reinitialize the window when the size of the text changes
15:19:29 <Yexo> at least if you want to resize the window when the text changes
15:20:30 <Rubidium> Terkhen/Yexo/glx: can you get the contents of rev.cpp for michi's yacd git?
15:20:53 <Yexo> I don't have windows currently
15:22:09 * Rubidium wonders what michi uses if it isn't gcc and isn't msvc
15:22:30 *** Adambean has joined #openttd
15:23:07 <AndiK> Yexo: I'll try that out. Thx!
15:23:30 *** |Jeroen| has joined #openttd
15:23:33 <michi_cc> MSVC with cygwin git. Maybe it's a problem with Mysgit.
15:25:07 *** HerzogDeXtEr1 has joined #openttd
15:25:59 <Rubidium> anyhow, I'll be gone for the rest of the evening
15:26:08 <AndiK> When is UpdateWidgetSize() called?
15:26:27 <AndiK> MSVC doesn't find any calls to it.
15:26:51 <michi_cc> Rubidium: I've updated the repo with the compilation fix and rebased onto the last trunk commit
15:27:34 <Yexo> AndiK: during window initialization, by SetupSmallestSize
15:28:03 <Yexo> widget.cpp:2198 for actual call
15:36:30 *** douknoukem has joined #openttd
15:37:57 <AndiK> Is there anything like "GetDataTip()"?
15:44:10 <AndiK> Hm. I don't think that's what I want. I'd like to resize my TEXT widgets in UpdateWidgetSize without saving their current string indices.
15:44:51 <AndiK> Something like: size->width = GetStringBoundingBox(GetData(widget));
15:44:53 <Yexo> AndiK: without string indices, how do you know how big the widget should be?
15:45:07 <AndiK> The widget already knows its string index.
15:45:21 <AndiK> I'd like to read it from outside.
15:45:36 <AndiK> So I don't need to create an extra variable for it.
15:45:58 <Yexo> how does the widget know it's string index?
15:48:11 <Yexo> but WWT_TEXT already does that
15:48:16 <Yexo> you don't have to code that yourself
15:48:32 <Yexo> size = maxdim(size, GetStringBoundingBox(this->widget_data));
15:49:03 <Yexo> if it's a string with arguments, you have to set those arguments in SetStringParameters
15:49:04 <AndiK> And how does the cutoff in my screenshot happen, then?
15:49:23 <Yexo> is your patch available online?
15:50:01 <Terkhen> AndiK: did you use SetResize correctly for all widgets?
15:50:47 <marius> When placing two train stations next to each other, it says "station too spread out" .. wouldn't it be the opposite, too close proximity?
15:50:51 <Yexo> Terkhen: that doesn't seem to matter, at least not from reading the code
15:51:27 <AndiK> Not the current version... I'll upload it, mom
15:51:43 <Terkhen> marius: if you place a new station next to an existing one you are making the existing one bigger, not creating a new one
15:51:58 <Terkhen> if you want to create a separate station press Ctrl while clicking and select the appropiate option
15:52:51 <Eddi|zuHause> marius: when you place a station next to an existing one, they get joined. if that exceeds the maximum, then it is "too spread out"
15:53:14 <Eddi|zuHause> you can set the maximum station spread in the advanced settings
15:54:00 <marius> Now that sounds fun, what's the max it can handle? hehe
15:54:43 <marius> Now that sounds beastly, I'm gonna go try that haha
15:56:21 <marius> Dare I ask what the setting name is for the max spread value?
15:57:15 <Terkhen> it is in construction somewhere IIRC
15:57:50 <Yexo> advanced settings->stations->max station spread
15:58:09 <Terkhen> I did not remember correctly ;)
15:58:10 <marius> I'd have to set that in the console of my server, wouldn't I ?
15:58:38 <Yexo> or whatever value you want it to be
15:59:16 <marius> Hmm, that gave me an error saying the command waso nly available ot a network server?
15:59:30 <Yexo> you have to execute that at the server, or use rcon
15:59:38 <marius> oh, so the console won't do?
15:59:38 <Yexo> rcon <passwd> "set station_spread 16"
15:59:51 <Yexo> ^^ that is valid in your clients console
16:00:01 <Yexo> replace <passwd> by the rcon password of your server as set in openttd.cfg
16:01:23 <marius> Another random question, is loading/unloading time proportional to station length/wagons ?
16:02:03 <Yexo> but if your train is longer than the station you'll get a huge penalty in (un)loading times
16:02:24 <marius> That's what I was aiming for
16:02:37 <marius> Guess that'll teach me to try 1 block stations with 13 wagons haha
16:02:38 <ndh> depends on the wagon or the capacity/load?
16:02:59 <Yexo> every wagon has a property how fast it can be (un)loaded
16:03:15 <Yexo> that property is independent of the capacity of the wagon
16:03:53 <marius> There wouldn't happen to be a modders api or similar for this?
16:04:05 <Eddi|zuHause> michi_cc: how do i get 1.2? after git fetch i only have tags 1.1 and 2.0?
16:04:38 <Yexo> marius: for what? you can set the (un)loading speed and other properties of wagons via a newgrf
16:04:49 <Yexo> I guess the newgrf spec qualifies as "modders api or similar"
16:05:06 <marius> Yexo, I ment in general if one felt like adding to it etc but without the extensive coding knowledge required to mess with the actual source
16:05:07 <michi_cc> do a "git fetch --tags", I've renamed the tags because of the revision detection. You should get a tag yacd_1.2 then.
16:05:32 <Yexo> marius: to change the penalty of long trains with shorter stations you'll have to modify the openttd code
16:05:55 <marius> oh I didn't mean for the train times specifically, just in general really
16:07:01 *** andythenorth has joined #openttd
16:07:41 * andythenorth is now on holiday
16:10:20 <Yexo> AndiK: you'll need to add a few AddResize(1, 0) items to the widgets
16:10:37 <marius> This looks awesome, I'm gonna set to it
16:11:15 <andythenorth> less sunny though
16:11:30 <planetmaker> would make nice additions to FISH :-P
16:14:29 <AndiK> Yexo: Thanks a lot, so far. Now, at least all of the string show up when I resize the window manually.
16:18:08 <michi_cc> Eddi|zuHause: I've updated 1.2 with the same fix as 2.0 for that gcc error. Should you get that as well, re-fetch the tags to get the updated one.
16:18:35 <Eddi|zuHause> i've manually added the include like suggested above
16:19:05 <michi_cc> That's a solution as well of course :)
16:20:09 *** DayDreamer has left #openttd
16:21:19 *** tokai|mdlx has joined #openttd
16:26:37 *** Alberth has joined #openttd
16:26:37 *** ChanServ sets mode: +o Alberth
16:34:44 <Eddi|zuHause> michi_cc: but i still have something weird: in my game, there are two builtin industry docks: Vilskirch Fischgrund and Bliesdorf Baggersee. the latter is near a fishing harbour, and it says it accepts fish, but when i send a ship there, it doesn't produce a link
16:39:56 <andythenorth> my game was getting boring anyway...
16:43:10 *** JVassie has joined #openttd
16:44:32 *** SystemParadox has joined #openttd
16:50:54 *** SystemParadox has joined #openttd
16:54:04 <michi_cc> Eddi|zuHause: My very quick test shows a link in the minimap on your 1964 save. I've not test if it actually carries fish though.
16:54:48 <Eddi|zuHause> i wasn't in 64 yet, did you mean 54?
16:55:56 <michi_cc> 1962 actually, I think that save was from you
16:55:59 <AndiK> Should there be any problem with WWT_TEXT and multiline strings?
16:56:24 <Eddi|zuHause> that's the one i just started up
16:56:33 <Eddi|zuHause> and it didn't have a link...
16:57:15 <Yexo> AndiK: no, it'll take the length of the longest line
16:57:33 <AndiK> WWT_TEXT does but TruncateString() doesn't.
16:57:45 <Eddi|zuHause> i built a dock next to the second fishing harbour, and rerouted the ship 23 (not ship 2 to the first harbour)
16:58:05 <Eddi|zuHause> and then it started producing, and the station rating went from ~30% to 67%
16:58:50 <AndiK> Instead, it writes a DEBUG-message telling me that "DrawString" was used instead of "DrawStringMultiline".
16:59:10 <Yexo> ah, WWT_TEXT does indeed not support multiline strings
16:59:23 <michi_cc> Either the link expired or there was some bug. When I remove and readd the order for the dredging site to ship 23 the link appears.
16:59:44 <michi_cc> Links in 1.2 are not supposed to expire anymore as long as a vehicle is waiting.
17:00:34 <michi_cc> Anyway, looks like 1.2 is fine.
17:01:19 <AndiK> Okay then. At least now I know where my mistake was.
17:08:28 *** andythenorth has left #openttd
17:13:24 <AndiK> Is there any reason why WWT_TEXT does not support multiline strings or should I consider this a bug?
17:16:33 <Alberth> never needed it so far
17:17:12 <Alberth> multi-line text is usually rendered directly at a background widget
17:19:04 <frosch123> the tricky part is, how to resize a multiline text
17:19:26 <frosch123> it can have any shape when wrapping lines
17:19:58 <frosch123> WWT_TEXT otoh can easily determine the maximum width and height since there is no linewrapping
17:20:21 <Alberth> look eg at a station or airport placement how the accepted cargos are handled
17:20:23 <frosch123> so, i would say, the limitation is very much intentional
17:20:42 <frosch123> esp. since there is that particular debug output which was only added because of WWT_TEXT
17:22:42 <AndiK> And if multiline texts with WWT_TEXT only supported manual linebreaks?
17:23:33 <AndiK> I don't need automatic line wrapping. Only a correctly sized bounding box around my widget.
17:28:26 <Yexo> AndiK: I think the clean thing to do would be to introduce a new widget type WWT_MULTILINE_TEXT
17:29:14 <Yexo> or as suggested earlier just draw the text on a WWT_PANEL
17:29:59 <AndiK> For now I'll take a look at the WWT_PANEL solution.
17:31:23 <Alberth> WWT_PANEL can also be used as widget
17:31:26 *** douknoukem has joined #openttd
18:34:16 *** Absurd-Mind has joined #openttd
18:51:07 <Eddi|zuHause> michi_cc: another weird thing, in www.informatik.uni-halle.de/~krause/Loisachkirchen%20Transport,%209.%20Okt%201966.sav i just built train 69, from Wiedhof Ost to Havelwald Süd, which created a link for coal, but no link for clay
18:51:33 <Eddi|zuHause> from memory i built the coal wagons, gave the order, then added/refitted clay wagons
18:55:44 *** andythenorth has joined #openttd
18:57:26 *** Hyronymus has joined #openttd
19:05:39 <michi_cc> Adding vehicles was indeed missing a route pre-fill.
19:09:19 <michi_cc> I thought that was alright, but it is actually not totally. Please reload.
19:12:13 <michi_cc> That difference seems to only matter for autoreplace though, so your problem was likely the missing pre-fill on add.
19:29:07 *** Chris_Booth_ has joined #openttd
19:34:18 *** Chris_Booth_ is now known as Chris_Booth
19:35:56 * andythenorth wonders what ratio of horizontal / diagonal lengths should be for vehicles
19:36:57 <andythenorth> default sprites seem to vary
19:39:42 * andythenorth wonders whether to fix the wrong lighting on FISH
19:44:05 *** Chris_Booth_ has joined #openttd
19:49:35 *** eQualizer|dada has joined #openttd
20:13:38 *** douknoukem has joined #openttd
20:47:38 *** eQualizer|dada has quit IRC
21:20:42 *** Chris_Booth_ is now known as Chris_Booth
21:25:19 <peter1138> downloaded zuu's yacd build but it won't open the base graphics
21:25:26 <peter1138> is there something odd with paths on windows? :S
21:27:28 <peter1138> hmm, i see, the 1.1.0 installer puts everything under program files
21:27:34 <peter1138> this build looks in users\public
21:31:28 <Yexo> general problem: if the installer would put it in users\public, it would only work for the user who run the installer
21:32:12 <Yexo> wait, users\public? not users\<username>\OpenTTD or so?
21:32:53 <Chris_Booth> the grapichs are store in users/<username>/Openttd/
21:33:17 <Chris_Booth> and you may need to add the listing to regedit for openttd
21:33:32 <Chris_Booth> otherwise you will have a path issue with the openttd.exe
21:38:28 <peter1138> well yes, with openttd
21:38:52 <peter1138> users\public\openttd is a search path, yes
21:39:16 <peter1138> installer puts them in c:\program files\openttd
21:39:32 <peter1138> so they only work with the installed openttd
22:00:34 <Eddi|zuHause> bäh... need tram station on bridge heads and under bridges
22:19:27 *** Progman has joined #openttd
22:25:38 <Zuu> and yet are the bridges already quite a lot more flexible than in TTD. :-)
22:55:39 *** Brianetta has joined #openttd
23:35:41 *** Markavian has joined #openttd
23:45:18 <Eddi|zuHause> hm... when (ctrl+)cloning, it doesn't copy cargo subtype
23:48:35 *** amkoroew1 has joined #openttd
continue to next day ⏵