IRC logs for #openttd on OFTC at 2012-05-27
⏴ go to previous day
00:00:27 *** Djohaal has joined #openttd
00:27:29 *** LordAro has joined #openttd
00:50:29 *** Hazzard has joined #openttd
00:52:37 *** Djohaal_ has joined #openttd
02:07:55 *** Hazzard has joined #openttd
03:34:22 *** Hazzard has joined #openttd
04:37:48 *** Hazzard has joined #openttd
04:43:07 *** telanus has joined #openttd
04:56:17 *** Eddi|zuHause has joined #openttd
05:48:59 *** andythenorth has joined #openttd
06:06:33 *** Zeknurn has joined #openttd
06:22:08 *** tokai|mdlx has joined #openttd
06:41:44 * andythenorth has not released a set for a while
07:29:06 *** sla_ro|master has joined #openttd
07:41:49 *** valhallasw has joined #openttd
08:21:49 *** Zeknurn has joined #openttd
08:22:52 *** Progman has joined #openttd
08:37:34 *** mahmoud has joined #openttd
08:40:13 *** Nat_aS is now known as Nat_AFK
09:04:12 *** TGYoshi has joined #openttd
09:10:43 *** Alberth has joined #openttd
09:10:43 *** ChanServ sets mode: +o Alberth
09:14:28 *** telanus has joined #openttd
09:19:06 *** andythenorth has joined #openttd
09:21:21 *** mahmoud has joined #openttd
09:37:15 *** Alberth has joined #openttd
09:37:15 *** ChanServ sets mode: +o Alberth
09:37:46 <Alberth> you scared the desktop so much it closed the window, Wolf01 :)
09:38:47 <Alberth> it could also have been me pressing a weird button :p
09:40:58 *** Hazzard has joined #openttd
09:42:25 *** frosch123 has joined #openttd
10:12:11 *** mahmoud has joined #openttd
10:32:45 *** Chris_Booth has joined #openttd
11:00:44 *** Biolunar has joined #openttd
11:03:35 *** pedro123456 has joined #openttd
11:10:12 *** andythenorth has joined #openttd
11:12:26 *** mahmoud has joined #openttd
13:20:38 <Terkhen> I prefer them, they allow you to see all available options at once
13:20:59 <Terkhen> but the position feels a bit strange
13:21:26 <Terkhen> I would expect it to be at the left of the option, not at the left of its description
13:23:25 <frosch123> scattering dropdowns all over the place is also weird
13:23:30 <frosch123> this way all buttons are on the left
13:23:50 <frosch123> (and figuring out the position of some text is even harder)
14:05:47 *** Hazzard has joined #openttd
14:06:06 *** Firartix has joined #openttd
14:08:14 *** LordAro has joined #openttd
14:18:36 *** HerzogDeXtEr has joined #openttd
14:22:06 *** mahmoud has joined #openttd
14:41:03 *** Hazzard has joined #openttd
15:16:17 <Eddi|zuHause> frosch123: i think it's a step in the right direction. but making it more obvious that you can enter a number in <> settings is also needed
15:17:05 <Eddi|zuHause> and while at it, the description should show the default value
15:27:22 <frosch123> the latter could be arranged :)
15:29:29 <Alberth> selecting a number with a drop-down is not useful, unless it has a very small range
15:29:51 <Eddi|zuHause> that was not what i was saying...
15:30:42 <Eddi|zuHause> currently, with numeric settings, an edit box pops up when you click on it. but that is not very obvious. an explicit button may make it more obvious
15:31:18 <Eddi|zuHause> the < > buttons should stay, but maybe a third button added inbetween
15:32:32 <Alberth> only keep the <> for numeric settings?
15:32:49 <Alberth> not sure about adding a 3rd button, what would be on it?
15:33:26 <Alberth> there are no such buttons anywhere
15:34:03 <Eddi|zuHause> the starting year in the new game window has a similar problem. it is by no means obvious that you can click on the year to enter a number
15:37:13 <Alberth> you should not want to change it anyway :D
15:40:41 <Terkhen> maybe all three types of options (boolean buttons, numeric values with < > and dropdowns) should be aligned at the right part of the window
15:40:54 <Terkhen> that way the window would feel less misaligned
15:41:08 <frosch123> there is a mockup for that on the forums
15:41:12 <frosch123> it looks quite stupid
15:41:21 <frosch123> you cannot tell what buttons belong to what setting
15:41:31 <frosch123> if there is lots of whitespace between them
15:41:51 <frosch123> you would have to add dots or line, but that is likely ugly as well :)
15:52:18 <Alberth> it also sucks for navigation, you constantly have to move between buttons and the tree (un)collapse buttons then
15:54:05 <frosch123> even better point :)
16:00:29 <frosch123> max zoom out must be a weird setting
16:01:12 <frosch123> seems to be the only setting that does not start at 0
16:49:53 *** Rhamphoryncus has joined #openttd
16:50:41 *** Prof_Frink has joined #openttd
17:07:30 *** andythenorth has joined #openttd
17:18:45 *** mahmoud has joined #openttd
17:24:27 *** andythenorth has joined #openttd
17:25:38 * Chris_Booth play andythenorth
17:25:41 * Chris_Booth play andythenorth
17:25:45 * Chris_Booth plays andythenorth
17:26:11 <andythenorth> that's some life I won't get back :(
17:26:56 <andythenorth> @DorpsGek r24246
17:27:03 <andythenorth> DorpsGek: @24246
17:27:16 <DorpsGek> Alberth: Commit by michi_cc :: r24246 /trunk/src (5 files) (2012-05-14 19:56:49 UTC)
17:27:17 <DorpsGek> Alberth: -Add [FS#5052-ish]: [NewGRF] Variable with the current max speed for vehicles.
17:27:38 <DorpsGek> @andythenorth r24246
17:27:47 <andythenorth> meh, that's not in DorpsGek's command list
17:28:20 <andythenorth> anyway, looks like an interesting commit
17:28:25 <andythenorth> not sure what to use it for yet
17:28:51 <andythenorth> seems most like something to display in text
17:28:58 <andythenorth> but there's no info text for vehicles
17:29:08 <Alberth> convert cargo if it goes faster than some limit :p
17:29:30 <Terkhen> if speed > value, increase a counter in town storage, and then use a NoGo script to fine the company
17:30:02 <Terkhen> change vehicle weight when it reaches relativistic speed
17:30:14 <andythenorth> hovercraft should age passengers faster
17:30:25 <frosch123> andythenorth: it is meant to make engines figure out, whether they are running under load, or whether they are idling at the speed limit
17:30:37 <andythenorth> so hence running costs?
17:33:55 <Snail_> hi guys, I'm having fun coding new features for my trainset
17:34:17 <Snail_> a thing that would *greatly* help (not just me) would be to have more than 8 userbits...
17:34:28 <Snail_> like, a larger bit mask for user data
17:36:14 *** Devedse has joined #openttd
17:36:33 <andythenorth> Snail_: you have the luxury of userbits, and you want more :o
17:36:52 <andythenorth> try not using any, it will make you a more heroic newgrf author :)
17:36:53 <Terkhen> I have never used them, what are possible use cases for userbits?
17:37:26 <andythenorth> detecting things like 'class of lead engine'
17:37:36 <andythenorth> rather than being pinned down to detecting by ID
17:37:59 * andythenorth does not have any user bits to play with, and is grumpy about that
17:38:08 <Snail_> 1. to have engines with multiple liveries: the way they userbits are set or cleared can set a special livery for an engine, and the caches attached to it would change specs according to it
17:39:06 <Snail_> only checking by engine ID would not be sufficient, and checking by refitting cycle would not be sufficient either, because the same engines might have different sets of available liveries depending on certain conditions
17:39:24 *** kkimlabs_ has joined #openttd
17:39:35 <Snail_> 2. userbits can be useful to assign specific characteristics of wagons, such as push-pull capabilities
17:40:34 <Snail_> 3. they must be used to enforce particular conditions, such as not allowing the train to leave a depot if a driving trailer is attached to the consist in a position other than last
17:40:37 <Terkhen> you could always store all engine/consist related information in the persistent storage to free some bits
17:40:45 <andythenorth> there is no persistent storage....
17:40:58 <andythenorth> not unless I miseed a commit
17:41:08 <Snail_> Terkhen: I tried to, but the persistent storage has one value for engine class
17:41:10 <Terkhen> that says that vehicles have a persistent storage
17:41:19 <andythenorth> since when is that?
17:41:27 <Terkhen> no idea, it was there before I coded town storage
17:41:49 <andythenorth> spec says industries only
17:41:50 <Snail_> so if I buy two engines with the same ID, and I store something in the persistent storage for the first engine, and then something else for the 2nd engine, the last info would overwrite the first
17:42:12 <Snail_> so I can't go with persistent storage, I need to go by userbit
17:42:15 *** Nat_AFK is now known as Nat_aS
17:42:33 *** Djohaal has joined #openttd
17:43:09 <Snail_> frosch123: I know. I didn't say anything for a while because I tried to make use of the current 8 bits, but there are things I'd like to add that would require more than 8 bits
17:43:27 <frosch123> i still think that the 8 bit are completey useless
17:43:33 <Terkhen> andythenorth: sorry, I was wrong it seems :P
17:43:34 <Snail_> I've been talking with MB about this for a while, and he would also need more than that to make stuff happen
17:43:38 <frosch123> and extending them does not make them more useful
17:43:39 <Terkhen> that's just the list of "parent" objects
17:43:47 <frosch123> the OR-mechanic is just useless
17:43:51 <Snail_> frosch123: allow me to disagree :p
17:44:18 <Snail_> I would not possibly have coded the livery system in my set hadn'it it been for the userbits
17:44:39 <frosch123> just because something is currently the only way to do something does not mean that it is good
17:45:01 <Snail_> well, it doesn't mean it's perfect, but it means it works
17:45:43 <Snail_> or at least that it's better than nothing :)
17:46:33 <CIA-17> OpenTTD: translators * r24294 /trunk/src/lang/ (13 files): (log message trimmed)
17:46:33 <CIA-17> OpenTTD: -Update from WebTranslator v3.0:
17:46:33 <CIA-17> OpenTTD: catalan - 2 changes by arnau
17:46:33 <CIA-17> OpenTTD: traditional_chinese - 1 changes by Luper
17:46:33 <CIA-17> OpenTTD: croatian - 7 changes by VoyagerOne
17:46:35 <CIA-17> OpenTTD: danish - 3 changes by beruic
17:46:35 <CIA-17> OpenTTD: dutch - 9 changes by mazele
17:46:52 <andythenorth> how about removing 'wagons' and making trains fixed consists?
17:46:56 <Snail_> even something like 16 bits with just OR would greatly help
17:47:07 <andythenorth> fixed consists would solve this
17:47:43 <frosch123> Snail_: whether it's 16 bit or 32 bit makes absolutely no difference
17:47:49 <Snail_> andythenorth: but that would take away the possibility of adding or removing wagons
17:48:04 <Snail_> frosch123: what do you mean?
17:48:04 <frosch123> you do not have to bargain for bits
17:48:10 <andythenorth> trains would be articulated vehicles
17:48:19 <andythenorth> they could be refitted by cargo subtype for length
17:48:22 <frosch123> it needs a solution that convinces
17:48:34 <frosch123> not extending crap that is broken for 8 years
17:49:02 <andythenorth> frosch123: that's how things like PHP win. Where's the issue :P :)
17:49:09 <frosch123> and unconditional OR-ing is about the most stupid thing you can do
17:49:17 <frosch123> that prevents combining multiple grfs
17:49:30 <Snail_> I agree it's limited, but it's still better than nothing
17:49:32 <frosch123> which is the design-scheme from 8 years ago, and is just inappropiate today
17:49:48 <andythenorth> I once proposed arbitrary labels
17:49:54 <andythenorth> primarily for lead vehicle
17:50:01 <andythenorth> to be extended at will by author(s)
17:50:18 <andythenorth> probably all wrong for seven kinds of reason
17:50:21 <Terkhen> I guess that you need something like town persistent storage, except that having one of those for each vehicle would reduce the game to a crawl :)
17:50:32 <andythenorth> persistent storage is one option
17:50:36 <andythenorth> there must be others...
17:50:56 <frosch123> so far i did not read any requirement for storage
17:51:07 <frosch123> every usecase so far was about detecting certain unit compositions
17:51:11 <andythenorth> imo this is same problem class as: refit livery, refit length, refit subtype, refit power
17:51:23 <frosch123> so, andy's labels seem a lot more appropiate than any amount of storages
17:51:30 <Snail_> I tried persistent storage, but it's got one value for ID, not one value for veh icle. Userbits are unique for each vehicle
17:51:38 <andythenorth> storages are going to suck
17:51:39 <Terkhen> I meant "like" as in, each NewGRF has its space but can read other NewGRfs stuff
17:51:47 <Terkhen> storages are not an option for vehicles :)
17:51:49 <andythenorth> storages do not provide any convention across grfs
17:51:55 <Snail_> labels could be interesting
17:52:21 <andythenorth> if I stuff a bitmask of four attributes in storage 1, but you put a max speed in there as a word....wtf :P
17:52:39 <andythenorth> ^ no problem if no-one ever tries to combine vehicles from multiple sets :P
17:52:47 <Snail_> andythenorth: how would they work? each vehicle would have a string of characters that it could arbitrarily set? and they'd be accessible from other vehicles (through var61)?
17:53:07 <andythenorth> not even sure they would work tbh :P
17:53:14 <andythenorth> I'm just suggesting idea
17:54:10 <andythenorth> I suggest things, and frosch123 tells me how they would work, or politely ignores my stupid ideas :)
17:56:33 <andythenorth> what are the cases you have again?
17:56:53 <andythenorth> described in terms of wagon X, engine A etc...
17:57:29 <Snail_> engine ID A can have liveries 1, 2 and 3, so it's got three refits
17:57:41 <Snail_> engine ID B can have liveries 1, 2 and 4
17:58:20 <Snail_> so if I attach two engines, one type A and one type B in a multiple traction, the consist can only have liveries 1 and 2 (engines with different liveries can't be attached to each other)
17:59:00 <Snail_> now, how to check which livery the engines currently have? ... I can't go by refit cycle, because each engine's refit options depend on what's attached to the consist
17:59:16 <Snail_> so going there by userbits is the best solution (so far)
17:59:50 <Snail_> for instance livery 1 has userbit pattern 0000 0000, livery 2 has pattern 0000 0010, livery 3 has pattern 0000 0011 etc.
18:00:07 <Snail_> like this, I reserve a few userbits for the liveries
18:00:45 <Snail_> then, one more userbit is reserved to check whether a driving trailer is not in the last position (which would prevent the train from leaving the depot)
18:01:14 <andythenorth> so the lead vehicle refit is dependent on the consist :o
18:02:06 <Snail_> a couple more userbits are used to check for push-pull compatibility for coaches, a couple more for service type (local/long distance, coz "old" long distance coaches would end up being used as local)
18:02:14 <Snail_> andy: yes, that's how it works now
18:03:25 <Snail_> probably a custom label for each vehicle would solve a few of these problems. I could use it to determine the engine's livery, thus freeing a few userbits
18:03:48 * andythenorth thinks livery refits are part of the problem, not a solution
18:03:48 <andythenorth> but we are where we are
18:04:08 <andythenorth> this set of problems smells also related to FS 4934
18:04:59 <Snail_> andythenorth: historically, there were many different companies that used the same (or very similar) engine types, so I want to recreate this in my sets ;)
18:05:36 <Snail_> therefore an engine is available in many livery refits that also have an impact on looks, specs, attachment rules, etc.
18:06:09 <andythenorth> Snail_: I understand the desire. It's the method of 'livery by cargo subtype refit' that I think smells wrong
18:07:06 <Snail_> andy: I see your point... I tried other approaches, but couldn
18:07:17 <Snail_> couldn't find any convincing ones
18:07:24 <andythenorth> and it strikes me FS 4934 only gets worse if more things can be checked in a varact 2 chain, especially wrt checking rest of consist
18:07:35 <andythenorth> there are no other convincing methods
18:08:00 <andythenorth> refitting length of a truck by cargo subtype is not convincing either :P
18:08:07 <andythenorth> nor is refitting power of a vehicle
18:09:17 * andythenorth wonders whether a graphics branch should be much more limited, and much more subject to caching
18:09:59 * andythenorth doubts the implementation could be stretched to that
18:10:31 <andythenorth> at least with current act 2 (varact 2) / action 3
18:11:33 <frosch123> andythenorth: you have to differ between stuff that is only needed in depots to check the composition
18:11:37 * andythenorth ponders forcing graphics to be provided by restricted set of cbs
18:11:42 <frosch123> and stuff that is only needed when the vehicle is visible
18:11:57 * andythenorth ponders forcing cbs to return action 1 realsprites block :P
18:12:02 <andythenorth> not action 2 ID :P
18:12:07 <andythenorth> this has certain...problems
18:12:09 <frosch123> fs#4934 is only about the fact, that ottd determines the look of vehicles everytime they move, instead of only when they are visible
18:12:24 <andythenorth> but we know that solving it is very hard?
18:12:25 <frosch123> the current method might be faster when zoomed out and a lot of vehicles are visisible
18:12:36 <frosch123> but certainly slower if the map is huge and only a part is visible at a time
18:12:50 <andythenorth> if sprites can be arbitrary size, what choice do we have but to checking everything?
18:12:59 <andythenorth> checking / check /s
18:13:07 <frosch123> the middle way is to keep the cache, but only invalidate it when moving and fill it when needed
18:13:28 <frosch123> vehicles sprites are not of any size
18:13:41 <frosch123> esp. not rv and train sprites
18:20:06 *** Devedse has joined #openttd
18:20:11 <andythenorth> Snail_: this is one of those questions that unpicks lots of other questions :P
18:20:24 <andythenorth> it's not a simple feature request ;)
18:20:45 <Snail_> well, if I got 8 extra userbits, I'd be happy and shut my mouth :D
18:21:19 <Snail_> it would be a workable solution to my problems and would allow me to code what I have in mind with no glitches
18:21:26 <Snail_> even if perhaps it's not so elegant :p
18:22:04 <andythenorth> worse is better :P
18:25:35 <Terkhen> that only pospones a better solution :)
18:26:11 <Terkhen> s/pospones/postpones/
18:26:31 <Snail_> well, any solution that works is good enough to me, as a newGRF developer :) and more userbits would do the trick
18:29:32 <Terkhen> for us, as developers, it means implementing the same thing twice
18:29:43 <Terkhen> better to do it right once
18:29:45 * andythenorth tries to figure out why refit cycle can't be used for this?
18:29:56 <andythenorth> I'm sure the reason is good
18:30:11 <andythenorth> nvm, I kind of see it
18:30:19 <Snail_> andythenorth: because the refit options can change according to the consist :)
18:30:23 <frosch123> refit_cycle is a user-set value, no grf-set value
18:31:40 <Snail_> Terkhen: I see, but how hard would it be to allocate 8 more bits to the userbit mask?
18:32:09 <frosch123> Snail_: the question is how grfs would access them
18:32:20 <frosch123> again, you do not have to bargain for bits
18:32:30 <frosch123> ottd has no problem to add 32bits to vehicles
18:32:36 <frosch123> but you need a newgrf spec to access them
18:32:46 <frosch123> and the current one cannot be extended
18:33:07 <frosch123> you need somethnig new, and doing the same twice though it is already known to be bad, is stupid
18:33:28 <andythenorth> it's also tiresome that this is only about trains
18:33:36 <andythenorth> trains are not particularly special
18:33:50 <andythenorth> so a solution that could be applied elsewhere is desirable
18:34:06 <andythenorth> which suggests spec update
18:34:07 <Snail_> how about custom labels as andy suggested? would that be feasible?
18:34:40 <andythenorth> labels as they exist elsewhere are get, not set
18:34:46 <andythenorth> dunno if that matters
18:35:18 <Snail_> oh, so they can't be changed?
18:35:27 <andythenorth> for railtypes, cargos etc, no
18:35:31 <andythenorth> there are no cbs to set them
18:35:40 <Snail_> right. I see what you mean
18:35:46 <andythenorth> they're effectively a compile time constant (I think)
18:35:51 <andythenorth> or run time constant at least
18:36:05 <Snail_> right, so they wouldn't help in this case
18:36:14 <andythenorth> not sure if it matters how they work now though
18:36:20 <andythenorth> this would be a different case
18:36:56 <andythenorth> I worry that labels are just a pretty face on persistent storage
18:37:19 <andythenorth> a 4 char label is just 4 bytes of storage :P
18:39:00 <Snail_> the issue is that if they're not changeable, accessing them would give you pretty much the same info as accessing the vehicle ID
18:39:12 <Snail_> coz there would be a 1-to-1 correspondence between ID and label
18:39:42 <andythenorth> they would need to be changeable
18:41:39 <Snail_> yep, so the question is, would it be possible to implement labels for vehicles that could also be set through a callback
18:42:53 *** Nat_aS is now known as Nat_AFK
18:48:21 <Terkhen> tomorrow is monday, besides that yes
18:48:48 <NGC3982> monday is the pride of the week!
18:49:54 <frosch123> i think there is not even funday monday tomorrow
18:51:36 <NGC3982> &i kind of like them. althought, that might have to do woth the fact that i barely work on mondays.
18:58:37 *** Nat_AFK is now known as Nat_aS
19:11:04 *** Devroush has joined #openttd
19:19:14 *** andythenorth has joined #openttd
19:32:18 *** andythenorth has joined #openttd
19:49:20 *** chester_ has joined #openttd
19:51:27 *** Nat_aS is now known as Nat_AFK
20:02:30 *** kkimlabs_ has joined #openttd
20:13:49 *** Nat_AFK is now known as Nat_aS
20:33:25 *** andythenorth has left #openttd
20:50:56 *** Nat_aS is now known as Nat_AFK
21:12:59 <Knogle> Can anyone tell me what exactly GSSignList returns? sign_id's?
21:15:28 <Knogle> odd, if I loop through all on the signs and use GSLog to show them, it just returns 0 for all of them.
21:16:05 <frosch123> you might first have to set a company
21:16:16 <frosch123> i guess by default you only get your own signs
21:16:31 <frosch123> i.e. the ones placed by the goalscript or those placed in scenario editor
21:16:43 <Knogle> that's the ones I'm trying to list
21:16:53 <Knogle> the ones the gamescript set
21:17:26 <frosch123> hmm, wait, what are you printing with gslog?
21:18:08 <frosch123> the lists in the api are all lists of pairs (somewhat map-ish)
21:18:17 <frosch123> so, you have to make sure to list the keys, not the values
21:18:58 <Knogle> can I paste 4 lines of code here?
21:19:07 <frosch123> use paste.openttdcoop.org
21:20:38 <Knogle> I guess that's all wrong then.
21:22:11 <frosch123> foreach (town, value in townlist) { } <- i am not sure whether foreach returns the key or the value, but that syntax gives you both
21:22:42 <Eddi|zuHause> yeah, try "foreach (_, sign in signlist)
21:25:08 <Knogle> tried both, still returns 0 for each sign
21:32:50 <Knogle> local signlist = GSSignList();
21:32:50 <Knogle> signlist.Valuate(GSSign.GetLocation);
21:33:15 <frosch123> in that case "dummy" will be the tileindex
21:33:41 <frosch123> key remains signid, value is tile
21:35:48 <Knogle> ah, yes.. that makes more sense.
21:36:08 <Knogle> I'd rather want the signid
21:53:51 <Davidt> wjhat languege is opentt?
21:54:40 <Davidt> isnt openttd by some guy who made rct1?
21:56:22 <frosch123> if you want assembler, look at ttdpatch :p
21:59:47 *** Chris_Booth has joined #openttd
22:00:21 * Davidt is away: im going, dunno where. WHO KNOWS?
22:22:29 *** Hazzard has joined #openttd
22:23:02 <Eddi|zuHause> Davidt: please disable away messages
22:32:14 *** brambles has joined #openttd
23:15:46 *** Nat_AFK is now known as Nat_aS
23:46:39 *** mahmoud has joined #openttd
continue to next day ⏵
