IRC logs for #openttd on OFTC at 2011-02-19
⏴ go to previous day
00:04:42 *** rhaeder1 is now known as rhaeder
00:13:50 <supermop> going home, be back in a few minutes
00:30:22 *** supermop has joined #openttd
00:43:51 <supermop> so i have nml working now (i think)
00:44:25 <supermop> so i have an nml file, and i have some pngs
00:44:35 <supermop> next i need the language file
00:44:46 <supermop> do i then put them all in a folder?
00:45:46 <Yexo> all language files go in a directory named "lang"
00:46:28 <supermop> all lang files for this grf, or for all grf i plan to make?
00:47:02 <supermop> and I assume that directory then goes into the same one that contains the nml file?
00:47:03 <Yexo> I'd advise to keep each project (=nml file, png files, lang directory) in a separate directory
00:48:06 <supermop> so i want to make mlsd.grf, i start with a folder containing (.png files), mlsd.nml, and 'lang'
00:48:36 <supermop> and that folder should be called 'mlsd'
00:49:12 <Yexo> you can call that folder whatever you want
00:49:29 <Yexo> but project name is a logical choice, so 'mlsd' sounds good
00:49:32 <supermop> how does nml find the folder then?
00:49:42 <Yexo> it doesn't, you give it that folder
00:49:46 <supermop> if its name is arbitrary?
00:50:10 <Yexo> you open a command prompt in that directory and run "nmlc mlsd.nml -o mlsd.grf"
00:50:39 <Yexo> did you install nmlc via python or did you use the exe I uploaded?
00:51:13 <Yexo> if you're not comfortable with the commandline at all, just create a bat file with the above nmlc line as contents
00:51:18 <Yexo> add "pause" as second line
00:51:26 <Yexo> that you can double-click that bat file to create your grf
00:51:52 <supermop> no idea what bat is, so i will stick with command line
00:52:10 <supermop> reminds me of playing tto on dos
00:52:15 <krinn> it's a text file with the command it gave you but name end with .bat
00:57:04 *** Devroush has joined #openttd
00:59:57 *** roboboy has joined #openttd
01:02:50 <supermop> gah i get a fatal error because of an unknown action 0 property
01:03:15 <supermop> but i dont even know which are the action 0s because it is in nml
01:03:37 <Yexo> ehm, if you use nml there is no reason to use nforenum
01:03:45 <Yexo> or grfcodec for that matter
01:04:52 <supermop> started another game
01:05:08 <supermop> no error, but it isn't doing anything either
01:07:59 <supermop> no effect whatsoever on depot graphics
01:08:29 <Yexo> you can only supply depot graphics for railtypes that have rail graphics that are also provided by a newgrf
01:09:10 <Yexo> also you have a lot of item(FEAT_RAILTYPES, rail_tracks)-blocks, you need to give each of those a unique name
01:09:53 <Yexo> that means the "rail_tracks" part
01:09:57 <supermop> it doesnt do anything whether it is loaded by itself, or also with nutracks
01:10:29 <supermop> you mean the lable for the track type goes there?
01:10:44 <Yexo> no, a unique name you can make up yourself goes there
01:10:53 <Yexo> but it has to be different for each track type
01:11:06 <Yexo> otherwise the changes overwrite eachother
01:11:20 <supermop> so it could just be "type_3RDR"
01:11:40 <Yexo> like now you're saying: "Here is a railtype named rail_tracks with label RAIL. Change the label of railtype named rail_tracks to ELRL. Change the label of ...."
01:11:40 <supermop> to help me keep it straight?
01:15:13 <supermop> i have 28 names to come up with, give me a second
01:15:28 <Yexo> I'm not sure that is going to work
01:17:22 <Yexo> every newgrf can only define 16 railtypes. I'm not sure what nml will do when you try to use more than 16.
01:17:34 <Yexo> Either it gives you an error message or it tries to use higher ids.
01:17:49 <Yexo> in the latter case openttd will simply ignore everything with an id >= 16
01:18:13 <Yexo> the proper way to fix it is to set the id's yourself, but nml currently doesn't support non-constant ids
01:18:27 <Yexo> so that'll have to wait until I can fix that somewhere this weekend
01:19:54 <krinn> Yexo can an AIList() have dup item ?
01:20:19 <supermop> it is not for 28 typs at the same time
01:20:33 <Yexo> supermop: doesn't matter
01:20:53 <supermop> but so that it can recognize the lables used by nutrack, or swedish rails, or slow rails, or transrapid
01:21:02 <supermop> depending on what is loaded
01:21:10 <Yexo> I know, but currently nml doesn't support that
01:23:15 <supermop> nml says, unexpected token ...
01:23:20 <supermop> so i will wait on that
01:24:42 <supermop> good night and thanks!
01:52:03 *** DanMacK has joined #openttd
02:16:45 <Belugas> [17:47] <krinn> i suppose you don't work on the WE belugas ? <---depends what you call work, krinn... Work for work? nope, got my share during the week alright. Although they call me sometimes... but not as intensive.
03:19:32 *** Markavian has joined #openttd
03:40:30 *** Markavian has joined #openttd
03:55:49 *** roboboy has joined #openttd
05:38:28 *** andythenorth has joined #openttd
05:56:18 *** Eddi|zuHause2 has joined #openttd
06:28:35 *** Markavian has joined #openttd
06:45:09 *** DoubleYou has joined #openttd
06:48:22 *** roboboy has joined #openttd
07:09:28 *** amkoroew has joined #openttd
07:18:17 *** Kurimus has joined #openttd
07:32:42 *** Cybertinus has joined #openttd
07:55:45 *** DayDreamer has joined #openttd
08:18:30 <dihedral> well done for rc1 :-)
08:18:40 <dihedral> i am looking forward to having a game of that :-)
08:20:22 <planetmaker> good point. I just should restart our stable ;-)
08:27:14 *** andythenorth has joined #openttd
08:34:59 *** Wolfsherz has joined #openttd
08:43:53 *** Eddi|zuHause2 is now known as Eddi|zuHause
09:09:03 *** HerzogDeXtEr1 has joined #openttd
09:33:42 *** |Jeroen| has joined #openttd
09:37:11 <Terkhen> hmm... writing documentation is really boring
09:46:04 *** Scuddles has joined #openttd
09:50:25 *** Dreamxtreme has joined #openttd
09:51:24 *** Alberth has joined #openttd
09:51:24 *** ChanServ sets mode: +o Alberth
10:02:40 *** Progman has joined #openttd
10:06:04 <yorick> something about the ubuntu .debs for the 1.1.0-RC1 is broken...the beta is registered as newer than the rc
10:07:36 <Eddi|zuHause> that's your package manager which is broken.
10:09:26 <yorick> or it could be gdebi that is broken
10:12:56 *** fmauneko has joined #openttd
10:14:44 *** Adambean has joined #openttd
10:18:37 <__ln__> how's the openttd C# port progressing?
10:21:24 <planetmaker> hm... interesting: trains, propert 09 (speed): "This limit is ignored for wagons with a livery override for the current train, so that train sets always get their max speed from the engine's max speed." :-)
10:21:26 <Terkhen> __ln__: in its current state, sometimes people ask about it
10:21:41 <planetmaker> but what means the next sentence "For wagons, a value of 0 means "default" (which depends on cargo type and date of introduction), and FFFF means no limit."?
10:22:20 <planetmaker> __ln__: as far probably as a java port ;-)
10:22:37 <planetmaker> Terkhen: I don't understand that sentence in the specs
10:22:49 <Terkhen> why should max speed depend on cargo type and date of introduction by default? shouldn't callbacks take care of that if the developer wants to do that?
10:22:50 <planetmaker> what's the default speed for a wagon? Especially if that should be cargo-dependent?
10:22:59 <planetmaker> that's what I wonder, too :-)
10:25:09 <Terkhen> planetmaker: OpenTTD does not seem to take into account that (see train_cmd.cpp line 228)
10:26:25 <planetmaker> well, that's what is said before that in the specs, too
10:26:44 <planetmaker> I just wonder whether that sentence c/should just be deleted from the specs
10:26:47 <Terkhen> yes, but that cargo type stuff is nowhere to be seen, and it does not make much sense anyways
10:27:07 <planetmaker> but it'll need a frosch to probably to look at :-)
10:27:19 <planetmaker> maybe ttdp does something weired there
10:28:00 <planetmaker> any such weiredness in interpreting the nfo specs would probably be hidden in the newgrf reading routing, though
10:28:23 <planetmaker> s/routing/routine/
10:29:30 <Terkhen> see newgrf.cpp line 568
10:29:36 <Terkhen> if (speed == 0xFFFF) speed = 0;
10:30:04 <planetmaker> yes, that also makes sense from the specs. But cargo-dependent default?
10:31:04 <Terkhen> it's the first time I hear something like that, yes
10:31:24 <Terkhen> probably my brain is used to filtering the parts of the specs that make no sense
10:33:12 <planetmaker> sadly specs are one of the few places where that behaviour can be really dangerous
10:34:00 <Terkhen> yes, that's why I prefer to touch them as less as possible :P
10:34:19 <dihedral> reading that out of context sounds weird
10:35:16 <Terkhen> some kind of "blame" for that wiki page history would be useful
10:35:24 <Terkhen> so we can know when and why it was added
10:35:53 <planetmaker> there's a history function
10:36:05 <planetmaker> as every wiki ;-)
10:36:23 <planetmaker> but not as convenient as blame, indeed
10:36:32 <Terkhen> yes but it does not seem to go much far
10:37:42 <Terkhen> I can't find a way of checking older revisions
10:38:06 <Terkhen> even editing the link manually to show an older one fails
10:38:29 <Terkhen> so I guess this will remain a mistery
10:38:45 <planetmaker> hm... indeed. The wiki does NOT keep all versions :-(
10:38:52 <planetmaker> at least not for me either
10:38:59 <Terkhen> that's really wrong IMO
10:39:01 <planetmaker> I always assumed it does
10:39:14 <planetmaker> let's hope for a new one ;-)
10:41:03 <dihedral> planetmaker, NewStations on the welcome server?
10:41:09 <krinn> just to help, it make sens to me to have a speed limit on wagon and some other wagons aren't affect
10:41:12 <dihedral> according to rc1 it's not found in the online content
10:41:40 <krinn> like if you want limit a wagon speed because of dangerous cargo, radiactive, instability...
10:42:00 *** roboboy has joined #openttd
10:42:58 <Terkhen> krinn: you can already do that via callbacks, that's why the description of this action 0 property does not make much sense
10:44:42 <planetmaker> dihedral: we already had games with grfpack newgrfs
10:44:58 <planetmaker> but honestly, an oversight ;-)
10:45:14 <dihedral> well - perhaps the next game then :-P
10:45:15 <planetmaker> it was in my stations preset
10:45:34 <krinn> Terkhen, some internals, to avoid return train engine speed limit to 10mph because the train pull 10mph speed limit wagons?
10:45:53 <planetmaker> don't tell me, dih, that using the coop grfpack is a problem for _you_
10:46:05 <Terkhen> krinn: sorry, what do you mean?
10:46:19 <dihedral> planetmaker, no it's not, i am just too lazy right now :-D
10:48:59 <krinn> Terkhen, as planetmaker said, it's not to limit trainsets
10:49:40 *** frosch123 has joined #openttd
10:50:27 <Terkhen> krinn: are you talking about the livery part?
10:50:43 <krinn> say you have a train engine with 100mph, that pull wagon of 10mph, it's speed will be limit to 10mph, but still for train speed calc you should be able to know that trainset (the engine+wagon) raw speed is base on the train real engine speed
10:51:22 <krinn> something like, don't take the 10mph limit a trainset have when you want to calc some train acceleration, but use the real speed the train engine could reach
10:51:38 <Terkhen> I was not talking about the livery part, but about the limit on cargo type part
10:51:57 <krinn> :) i might take something wrong so
10:52:45 <Terkhen> the problem is: with action 0 you can set the max speed of a wagon or engine, and with callbacks you can modify properties under certain conditions
10:53:00 <Terkhen> talking about those conditions in action 0 does not make much sense, at least to me
10:54:02 <planetmaker> quite. And if so they'd need explicit naming than some wavy 'default values' - esp. as CB36 is not an a priori default.
10:54:28 <planetmaker> nor is livery override a default
10:54:32 <krinn> well, maybe some old days limits, like before refitting is introduce, callback weren't need, and limit was base on the cargo the wagon have (as it cannot be refit)
10:54:41 <planetmaker> it's something which an engine may or may not define
11:25:17 *** Vikthor has joined #openttd
11:36:09 *** Markavian has joined #openttd
11:52:04 *** KenjiE20 has joined #openttd
12:00:53 *** DanMacK has joined #openttd
12:32:53 *** Devroush has joined #openttd
12:40:35 *** fjb is now known as Guest1908
12:45:23 *** Brianetta has joined #openttd
12:52:56 *** Skiddles has joined #openttd
13:18:04 <CIA-11> OpenTTD: frosch * r22106 /trunk/src/ (newgrf.cpp sprite.cpp sprite.h): -Codechange: Add DrawTileSeqStruct::MakeTerminator(), DrawTileSeqStruct::IsTerminator(), DrawTileSeqStruct::IsParentSprite() to simplify stuff.
13:18:40 *** fmauneko has joined #openttd
13:19:46 * Zuu uses no NewGRFs + last nightly and can't build airports.
13:20:35 <Zuu> Couldn't find a relevant fix in the commit log since yesterday evening.
13:23:10 <Zuu> If I disable "Disable infrastructure building when no suitable vehicles are available" in advanced settings, I can build an airport and then aircrafts.
13:26:12 <Zuu> It seems like AIs are also affected.
13:29:26 *** zachanima has joined #openttd
13:31:43 <Zuu> But when I started a new game with this advanced setting = off, then AIs were able to build airports.
13:31:46 *** andythenorth has joined #openttd
13:32:04 <Zuu> (and human players as well)
13:32:47 <dihedral> you said that the nightly before last works?
13:32:52 <dihedral> and yesterdays fails?
13:36:30 * andythenorth ponders drawing smoke directly onto ship sprites
13:36:40 <Alberth> Zuu: trunk seems to work (r22105), did you pause the game perhaps?
13:37:56 *** Biolunar has joined #openttd
13:38:19 <Zuu> Make sure you have "Interface -> Disable infrastructure building when no suitable vehicles" enabled
13:39:01 <andythenorth> when my log raft breaks down, the smoke effect is positioned on the logs :(
13:39:17 <Zuu> I'll check again tonight if it works and if not make a better report at bugs.openttd.org.
13:51:00 * andythenorth has white pixels and can't find them
14:08:03 *** valhallasw has joined #openttd
14:29:55 *** Dreamxtreme has joined #openttd
14:30:40 <CIA-11> OpenTTD: frosch * r22107 /trunk/src/water_cmd.cpp: -Cleanup (r1903): Remove unused struct.
14:51:59 <CIA-11> OpenTTD: frosch * r22108 /trunk/src/ (table/water_land.h water_cmd.cpp): -Codechange: Replace some magic with some other magic though less easy to break.
14:55:50 <CIA-11> OpenTTD: frosch * r22109 /trunk/src/table/station_land.h: -Fix (r21269, 21272): Missing undeffing of macros.
14:56:55 <Zuu> planetmaker: When customer support is at its best :-D
14:57:27 <CIA-11> OpenTTD: frosch * r22110 /trunk/src/ (table/water_land.h water_cmd.cpp): -Codechange: Remove WaterDrawTileStruct and use DrawTileSprites/DrawTileSeqStruct instead.
15:01:46 *** gohan4748 has joined #openttd
15:02:10 <planetmaker> Zuu: yes, I feel a bit guilty. But... he didn't give any effort either, so the feeling of guilt is a bit limited
15:04:41 <Zuu> yes indeed, the error report was not very descriptive.
15:04:47 <DanMacK> No guilty feelings PM, that was perfect
15:06:04 <Zuu> In OSS you as "customer" have to make yourself obligable for the support by walking half the distance. If you don't, then you shoudn't complain on what kind of answers you get. :-p
15:09:07 *** Markavian has joined #openttd
15:18:33 *** DayDreamer has joined #openttd
15:37:33 *** tokai|noir has joined #openttd
15:38:57 *** supermop has joined #openttd
16:04:42 *** Chruker has joined #openttd
16:08:01 *** supermop has joined #openttd
16:09:07 *** KritiK_ has joined #openttd
16:15:02 *** KritiK_ is now known as KritiK
16:17:13 <supermop> so planetmaker, it looks like i cannot conditionally support railtype from multiple sets in nml yet
16:17:50 <supermop> so i am just going to rewrite it to work just with nutracks, and another grf to work just with default for now
16:19:28 <planetmaker> why wouldn't that work?
16:20:07 <planetmaker> if railtype_available and grfpresent()...
16:20:13 <planetmaker> along that logic?
16:20:26 <planetmaker> or maybe I miss what you actually try to do :-)
16:21:11 <supermop> apparently nml get confused if you try to set up conditions for more that 16 labels, even if they would not all work at the same time
16:21:37 <supermop> nml itself stops at the line with the 17th type and gives an error
16:21:59 <planetmaker> hm... do you have the nml file for me?
16:22:27 <supermop> i didnt upload the most recent yet
16:23:07 <supermop> the version that is in my thread on the forum compiles fine once i fixed those name strings,
16:23:19 <supermop> but it doesnt do anything in game
16:24:08 <supermop> because it is worded to just keep changing the label for the regular tracks
16:24:32 <planetmaker> but it doesn't do that?
16:25:34 <supermop> but absolutely nothing happens
16:25:37 <planetmaker> I'll look at it; so far I only looked at whether it compiles really ;-)
16:26:45 <supermop> rubidium was helping me last night with it
16:26:59 <supermop> he made some flyspray thing about it
16:27:48 <gohan4748> im in alot of chats
16:29:06 <planetmaker> supermop: I don't find that entry. Could you summarize the discussion or give a time?
16:29:47 <supermop> maybe around 10 pm est, so 3 am gmt
16:31:19 <supermop> it was yexo, not rubidium that was helping me
16:34:46 <planetmaker> right. Read that IRC discussion. Then there's no way to get that done with the current version. But well... soonish :-)
16:35:27 <supermop> i can just make a couple different grfs for the major railsets for now instead
16:36:01 <planetmaker> nah. I'd do that grf - for now - with 16 railtypes in the form you plan. And wait for NML to support more.
16:36:24 <planetmaker> it'd be IMHO the cleaner solution.
16:36:57 <planetmaker> it's something which *should* work ;-)
16:37:40 <planetmaker> after all when you write it now to work with 16 labels, you can then easily add another 16 when that nml-task is implemented. Simply copy&paste a few lines of code and add a few more graphics ;-)
16:38:09 <planetmaker> or are you in a big rush to get them churned out like now? And not... in, say a week or a month?
16:38:55 *** Chris_Booth has joined #openttd
16:39:32 <planetmaker> the advantage of the one-grf solution is the much higher user-friendlyness
16:40:03 <planetmaker> I find it kinda boring to have - for example - like 3 or 4 different total bridge replacement sets, one for each road and rail type, possibly even combination thereof
16:40:18 <planetmaker> that's... something which could and should IMHO be handled in one newgrf
16:40:25 <planetmaker> and this'd be the same thing
16:40:35 <planetmaker> and now I stop the monologue ;-)
16:45:32 <Hirundo> too long, didn't read
16:48:25 *** andythenorth has left #openttd
16:49:33 <supermop> yeah i am worried about being too much trouble to attract users
16:51:24 <Zuu> Depends on how much the users mean to you :-)
16:53:05 <Zuu> I got 25 upgrades of ottdau in about 48 hours which is maybe not a lot, but it make me happy that there are some people that find it usefull. :-)
16:53:17 <supermop> but yes, it seems odd to me that we still must have so few bridges
16:53:41 <supermop> almost no one uses my grf as is
16:54:00 <supermop> i was hoping that adding matching depots would help a bit
17:00:12 <supermop> just something that has always bothered me
17:00:37 <planetmaker> Zuu: if I still played on windows, I'd have it :-)
17:00:58 <planetmaker> was a must-have for me back then :-)
17:01:31 <supermop> i wish i could add a couple bridges just for monorail or maglev etc, but doing so would eat in to the total number of bridges i could have
17:01:38 <planetmaker> supermop: you mean your station grf? Or did you do a bridge grf I missed?
17:01:59 <supermop> just did some sketching and drawings on the bridges
17:02:04 <supermop> never coded anything
17:02:21 <Zuu> planetmaker: I agree about it being a must-have ^^
17:03:31 <supermop> i wanted to add 10 or so suspension bridges, each with a very specific length range, so that graphics could be drawn to look idea for a suspension bridge
17:03:43 <supermop> and then ad some cable stayed bridges as well
17:04:02 <planetmaker> well. There's only limited newgrf support for bridges
17:06:12 <supermop> yeah, that is why i never went any further than concept
17:06:48 <planetmaker> well. There surely somewhen will be full support in the same way as for vehicles, industries or stations...
17:07:14 <planetmaker> but noone so far even started on thinking about the specs ;-)
17:08:17 <supermop> the possibilities would be interesting
17:09:10 <supermop> call backs so that if two bridges of same owner and type are next to each other, they could look like one wide bridge
17:10:26 <supermop> so you could simulate say, the brooklyn bridge as [oneway road][tram][oneway road]
17:10:32 <Terkhen> hmm... it is not possible to set up + and - as hotkeys?
17:10:40 <planetmaker> that'd be a really advanced thing. I'd not bet on that too soon. But allowing to define your own bridges and more than 11 - that's probably not too difficult
17:10:49 <planetmaker> Terkhen: as they're ascii <128: probably
17:11:44 <Terkhen> someone complained about + and - not working anymore for zoom out/zoom in
17:12:00 <supermop> yeah, if you could do at least more types, then there is the ugly solution of "Suspension bridge, right" and "suspension bridge, left"
17:12:02 <Zuu> Terkhen: I've complained about that before
17:12:36 <Terkhen> I don't know if it is feasable to fix this
17:12:46 <Zuu> At least about that it is rather troublesome to figure out what character that I should encode my -+ keys as in hotkeys.cfg.
17:13:59 <Zuu> But that was long time ago I tried to fiddle with my hotkeys.cfg to do anything with non-a-z keys.
17:14:21 <supermop> maybe something to vary appearance of certain bridge types depending on date built
17:15:18 <Zuu> As for the record in SDL for example you only recive the key symbol in the key down event, and need to store it along with the keycode so that when the key is released you can inside your program generate an internal symbol release message.
17:16:36 <Zuu> Had to fiddle a bit with that in order to make it work well with symbol based hotkeys in a SDL program I write.
17:18:51 <Terkhen> given the contents of the _keycode_to_name, NUM_PLUS and NUM_MINUS should be usable
17:19:23 <Terkhen> they are even used in _maintoolbar_zoomin_keys at the toolbar code
17:22:43 <Terkhen> they probably were added later, after deleting my hotkeys.cfg they work correctly
17:23:02 <Terkhen> Zuu: zoomin = NUM_PLUS,=,SHIFT+=,SHIFT+F5
17:23:02 <Terkhen> zoomout = NUM_MINUS,-,SHIFT+-,SHIFT+F6
17:24:29 <Terkhen> hmm... something strange happens
17:25:08 <Terkhen> they only work just after I delete my hotkeys.cfg
17:25:33 <Terkhen> the next time OpenTTD is opened they are reset to only SHIFT+F5 and SHIFT+F6
18:02:40 <CIA-11> OpenTTD: rubidium * r22111 /trunk/src/ (cargopacket.cpp cargopacket.h station.cpp vehicle.cpp): -Codechange/fix-ish: upon cleaning a pool a destructor should not delete items from other pools
18:23:57 <CIA-11> OpenTTD: smatz * r22112 /trunk/ (7 files in 3 dirs): -Codechange: register all pools in a pool vector
18:25:37 <CIA-11> OpenTTD: smatz * r22113 /trunk/src/openttd.cpp: -Codechange: use PoolBase::CleanAll() to clean all pools at game exit
18:32:10 <Markk> So basically, you lick yourself on your banana?
18:33:23 <Rubidium> hmm... someone didn't update the topic
18:34:20 <Rubidium> gohan4748: do you want to be banned?
18:36:25 <SmatZ> I wonder if gohan4748 is actually a person
18:36:26 * DanMacK sniffs the air and smells a ban coming on
18:36:43 <SmatZ> he had comments like those at #gcc #oftc #moocows and maybe other places
18:37:27 <Terkhen> either he fails at trolling or someone took his IRC nick
18:38:03 <gohan4748> i just want to have fun
18:38:04 <SmatZ> seems he got banned from #linode :)
18:40:57 <V453000> even being banned once says something :)
18:41:04 <gohan4748> im not banned from#gcc #oftc #moocows
18:41:14 <gohan4748> im not banned from #gcc #oftc #moocows
18:41:19 <planetmaker> thanks for sharing. Any reason to not put you on ignore?
18:41:48 <planetmaker> (except that I then don't see why others might rightfully complain?)
18:42:15 <SmatZ> well, you were banned at #oftc, but the timed ban has expired :p so yes, you are not banned there now
18:42:26 <planetmaker> @kban gohan4748 300 this time has not expired yet
18:42:26 *** DorpsGek sets mode: +b *!~sasuke@adsl-99-59-84-86.dsl.chcgil.sbcglobal.net
18:42:27 *** gohan4748 was kicked by DorpsGek (this time has not expired yet)
18:42:44 <planetmaker> 5 minutes though. as warning
18:44:05 <Terkhen> I doubt he will understand the warning
18:44:17 <V453000> he seems extensively stupid
18:44:26 <Wolf01> they take it as a challenge
18:44:50 * Rubidium ponders /mode +q *!~sasuke@adsl-99-59-84-86.dsl.chcgil.sbcglobal.net
18:44:56 <Wolf01> when he'll return he will do anything to get another one
18:45:02 <SmatZ> Rubidium: you are late with that one :)
18:45:24 <CIA-11> OpenTTD: translators * r22114 /trunk/src/lang/ (danish.txt unfinished/frisian.txt):
18:45:24 <CIA-11> OpenTTD: -Update from WebTranslator v3.0:
18:45:24 <CIA-11> OpenTTD: danish - 3 changes by beruic
18:45:24 <CIA-11> OpenTTD: frisian - 13 changes by Taeke
18:45:30 <Rubidium> SmatZ: no, just to make him silent in the future without him really noticing ;)
18:46:50 *** planetmaker sets mode: +q *!~sasuke@adsl-99-59-84-86.dsl.chcgil.sbcglobal.net
18:47:03 * planetmaker is in BOFH mode ;-)
18:47:26 *** DorpsGek sets mode: -b *!~sasuke@adsl-99-59-84-86.dsl.chcgil.sbcglobal.net
18:51:49 *** gohan4748 has joined #openttd
18:55:22 <CIA-11> OpenTTD: smatz * r22115 /trunk/src/ (core/pool_func.cpp core/pool_type.hpp openttd.cpp): -Fix (r22114): some comments and code ordering were wrong
18:58:16 <Rubidium> planetmaker: really, I was thinking of COFH
18:58:19 *** gohan4748 has left #openttd
18:59:17 <Rubidium> channel operator (from heaven)
19:00:43 *** planetmaker sets mode: -q *!~sasuke@adsl-99-59-84-86.dsl.chcgil.sbcglobal.net
19:00:59 <planetmaker> maybe he understood. ;-)
19:24:30 *** andythenorth has joined #openttd
19:31:56 <DanMacK> Definitely a nice set that
19:32:10 <DanMacK> Good representation of a GP40-2
19:38:21 *** supermop has joined #openttd
19:41:04 <dihedral> * planetmaker is in BOFH mode ;-) <- that does not happen very often :-P
20:51:18 *** valhallasw has joined #openttd
21:06:40 *** Vikthor has joined #openttd
21:32:02 <Zuu> Terkhen: I tried to add then non-numpad keys that you suggested but didn't got it to work. Also when I exited OpenTTD it removed my additions. (but some other changes I have in the file remained)
21:32:04 <Zuu> zoomin = SHIFT+F5,=,SHIFT+=
21:32:04 <Zuu> zoomout = BACKQUOTE,SHIFT+BACKQUOTE,SHIFT+F6,-,SHIFT+-
21:32:39 <Zuu> The BACKQUOTE thing was there in my file. Not sure if I've put it there myself or if it has been there since before.
21:37:05 <Terkhen> Zuu: I have not tested but I think that this problem was introduced in r22094
21:38:29 <Zuu> Looking at _keycode_to_name, it looks like a quite short list to me.
21:38:45 <Zuu> For example, I can't find page up/down there.
21:40:03 <Zuu> Shouldn't there be a entry there fore each WKC_KEY? (apart from a-z, 0-9 which are probably not non-normal keys)
21:47:04 <Zuu> Hmm, it looks like ParseCode (line 67 in hotkeys.cpp) is responsible for parsing single symbols/codes from the config file.
21:47:35 <Zuu> It accepts a-z and the keycodes that exist in _keycode_to_name and then nothing else.
21:48:31 <Zuu> So according to this it should be impossible to use eg. number-keys in your config file.
21:59:32 <Zuu> What exactly is the problem you are trying to solve? That it does not get the config change that you suggested?
22:07:13 <Zuu> What is interesting is that ParseCode first check if you have written something that exist in the _keycode_to_name list, then it checks if you have written something that matches [a-zA-Z]. If you have written something else it will return 0. Then back in ParseKeyCode, there is several checks on the return value from ParseCode. However, if you have written something non [a-zA-Z] or not in the _keycode_to_name array, code will be 0.
22:08:21 <Zuu> hmm, I think I'm wrong. it is only lowercase that is allowed ( [a-z] )
22:08:35 <Zuu> but that's a detail in this matter.
22:10:55 <Zuu> It might be that you need some checks to ignore if someone has written a multi-letter lowercase word so that you don't parse eg. "word" as the w-key.
22:11:29 <Zuu> But as far as I can see there is no need to do validity checks on the keycodes that exist in the _keycode_to_name array.
22:12:29 <Zuu> It could be that there is a broken assumption somewhere that all keys in _keycode_to_name are WKC_SPECIAL_KEYS.
22:16:19 <Terkhen> Zuu: some of the keys that patch allows might not be suitable for being used as hotkeys (for example [)
22:18:03 <Zuu> The problem with eg [ is that if I want that as hotkey I have to figure out what that resambles on US-qwerty to be able to write it into my hotkeys.cfg file.
22:18:22 <Zuu> Or did you forsee any other issues with [ ?
22:19:40 *** valhalla1w has joined #openttd
22:28:59 <Zuu> In principal I don't see any problem with letting people use whatever hotkeys they want. Though it is probably a good idea if the hotkey loader blocks those hotkeys that don't work in OpenTTD.
22:29:14 <zydeco> look, the topic still says 1.1.0-beta5
22:30:40 <Terkhen> at least in my keyboard I cannot press [ by itself
22:31:34 <zydeco> yes, the spanish keyboard sucks for coding
22:31:50 <zydeco> especially objective-c :p
22:32:07 <Zuu> Hmm, yes we only need the keycodes for keys that can be pressed by themself on US qwerty as that is what OpenTTD uses.
22:32:24 <Zuu> At least from the perspective of keycodes somehow.
22:32:43 <Zuu> Still I get dvorak while typing in chat.
22:33:57 <Zuu> What users like me or Terkhen will have use for is a dialog where you can type how to press [ on your own keyboard an get the string representation of that keycode.
22:34:54 <Zuu> The fact that that string representation will not be "[" is something I think would require rather large changes to overcome.
22:38:00 <SmatZ> why is "[" == WKC_L_BRACKET == 147, and not its ascii code, 91?
22:39:04 <Zuu> possible because keycode != symbolcode
22:39:18 <Zuu> several symbols usually share the same key.
22:41:15 <frosch123> @topic set 1 1.0.5, 1.1.0-RC1
22:41:15 *** DorpsGek changes topic to "1.0.5, 1.1.0-RC1 | Website: *.openttd.org (translator: translator, server list: servers, wiki: wiki, patches & bug-reports: bugs, revision log: vcs, release info: finger) | Don't ask to ask, just ask | 'Latest' is not a valid version | English only"
22:45:09 <Terkhen> yes, a GUI for hotkeys would be nice :)
22:46:10 <Eddi|zuHause> is the keycode layout-dependent?
22:46:16 <Terkhen> if there are some keyboards with [] as keys then it should be kept IMO
22:46:30 <Eddi|zuHause> [ is on AltGr+8 here
22:46:53 <Terkhen> Eddi|zuHause: I don't think so, from what I see the keys are mapped to constant codes
22:48:21 <Eddi|zuHause> so there's an intermediate layer which translates raw keycode to "unified" keycodes?
22:53:43 <Terkhen> Eddi|zuHause: yes, it's done in src/video/*_v
22:55:02 <Eddi|zuHause> aha, so there's also an os-abstraction-layer
23:00:08 <SmatZ> US keyboard layout has []
23:02:48 <Zuu> Note that I don't think my code for [0-9] works.
23:03:23 <Zuu> The array would contain entries for all symbols that you can produce by pressing a key without a modifier on US-qwerty.
23:04:29 <Zuu> hi krinn, welcome to the hotkey-night
23:04:49 <krinn> rubiduim, doesn't the UTF8 encoding should be on the computer that run openttd and not only on the source file, my system is UTF8 and my files are encode as-is per default
23:06:10 <CIA-11> OpenTTD: smatz * r22116 /trunk/src/ (28 files in 3 dirs): -Codechange: use PoolBase::Clean() at more places
23:07:07 <krinn> well Zuu i could help if you need azerty/fr tests :)
23:08:01 <Zuu> I think that if it can handle my layout it will be pretty good with most layouts. :-p
23:08:20 <krinn> here [ is altgr+5 and ] altgr+ (hmm 2 keys left the backspace one)
23:09:42 <Zuu> here [ is altgr + ö and ] is altgr + p. (those are located on e and r on a qwerty-board)
23:10:40 <Zuu> However, that's not the main issue at the moment.
23:11:38 <Zuu> The main issue is to make it possible to configure any config you like on a US-qwerty board. Then a transaltor can be used to provide the US-qwerty equivalent of a key combination on other keyboards/layouts.
23:11:54 <Terkhen> Zuu: that seems to revert r22094... does it trigger FS#4510 again?
23:13:18 <krinn> well, i would say without seeing futher, that the patch now return *start; only if >='0' && <='9' while it was always returning it before
23:13:27 <krinn> looks a bit dangerous imo
23:13:59 <Zuu> Hmm, I'll take a look. But a user should not enter a local letter in the hotkeys.cfg - though we still will need to have guards to not make that crash OpenTTD.
23:14:41 <krinn> if user/openttd/who call that expect on failure to get back its original value, the patch will make it fail now
23:16:24 <krinn> a=that && b=thepatchfunction, the test like if (a==b) will fail because now b=0 on failure while b=that before
23:16:33 <Zuu> As said before, I don't know exactly how that line will look like. But the idea is that it will return the keycode for key 0-9.
23:17:15 <krinn> imo safer to reput the return *start; if >=0 && <'9' fail to return it
23:18:22 <krinn> this will of course cancel the patch :) because who cares if it's >0 or <9 *start is return anyway ^^
23:19:40 <Zuu> krinn: Care to post some code?
23:19:54 <krinn> if (*start >= 'a' && *start <= 'z') return *start - ('a'-'A');
23:19:54 <krinn> + if (*start >= '0' && *start <= '9') return *start;
23:20:03 <krinn> this part from hotkeys.cpp
23:23:50 *** DoubleYou has joined #openttd
23:23:54 <Zuu> yes, that's the line you discuss, but I've problem seeing what your suggestion look like.
23:24:04 *** andythenorth has joined #openttd
23:24:15 <krinn> before the patch, *start was always return
23:24:33 <krinn> after the patch, *start will only be return if >='0' && <='9'
23:24:56 <krinn> it's less safe, maybe someone expect *start to be return in case of failure
23:24:58 <Zuu> No, you need to read the whole function
23:25:20 <krinn> have a link to the function?
23:25:28 <Zuu> ParseKeycode + ParseCode work close togeather with eachother.
23:26:57 <Zuu> line 38 and 39 has been swapped since I made the patch - but that should not affect the execution.
23:27:12 <Zuu> just a tiny speed improvement.
23:28:30 <Zuu> The return value on line 19 is probably wrong by a constant value.
23:29:05 <krinn> well, i don't see something better with line 19
23:29:21 <krinn> if before "return *start" was ok
23:29:39 <krinn> now it will do the same but just add 2 tests for nothing
23:29:55 <krinn> as the action from those test is just doing like before -> return *start
23:30:05 <krinn> just eat cpu cycles for the tests
23:30:36 <Zuu> Well, the idea with my change is (as written earlier tonight) to only accept keysymbols that are in _keycode_to_name array with the exception of a-z + 0-9 which got these two special checks.
23:31:39 <krinn> it's only valid if you really prefer now not return *start when (end - start ==1)
23:32:24 <Zuu> Yes that is exactly what I want
23:33:02 <krinn> to get catch by line 38 so ?
23:33:03 <Zuu> I only want to allow the strings that exist in the array + [a-z] and [0-9].
23:33:38 <Zuu> Maybe some other ascii-shortucts can be added in addition to a-z and 0-9.
23:34:29 <Zuu> A problem is that there are some keycodes that are not WKC_SPECIAL_KEYS but are still >= 128.
23:34:52 <krinn> hence that additional filter so ?
23:35:08 <Zuu> please read backlog from 22:30
23:36:34 <Zuu> Sorry if I'm a bit arrogant, but this all has already been discussed and I think you don't have the full background to this problem.
23:42:05 <Zuu> Terkhen: Can't reproduce FS#4510 with my patch. (I used a swedish ä in my config). My patch ignores everything that is not in the _keycode_to_name array (except for a-z and 0-9 that is still granted).
23:42:47 <Zuu> It is not ready for inclusion yet however, as it might break some hotkeys if there were some ascii keys that worked before but not anymore.
23:43:21 <Zuu> It will make the array rather long, and some might think that will be ugly.
23:44:45 <Zuu> There might exist some ascii ranges that can be converted in a block like a-z and 0-9 that can reduce the length of the array, but otherwise I don't see a way around it.
23:46:25 <Zuu> As SmatZ mentioned before the ascii code for [ is not the same as the keycode for it and I don't know if there exist any easy map between keycodes and ascii for other chars than a-z + 0-9.
23:47:08 *** roboboy has joined #openttd
23:47:44 <Terkhen> I still have the feeling that the special keys array could use a rework, yes
23:48:00 <Terkhen> but a small fix for backporting is desirable
23:48:27 <Terkhen> but it's too late already :)
23:49:28 <krinn> do you capture the altrgr code too ?
23:50:04 <Zuu> take a look on the WKC-related code in the os-layer.
23:50:30 <krinn> so you shouldn't be able to catch [ for french keyboard that need it
23:51:29 <Zuu> You would probably have to write ALT and not ALTGR in your hotkeys.cfg
23:52:00 * SmatZ wonders what GR stands for...
23:52:08 *** Markavian has joined #openttd
23:52:18 <Zuu> Alternative group of symbols?
23:52:41 <SmatZ> only the right Alt is AltGR, right?
23:52:55 <SmatZ> I wonder why they are different :)
23:53:22 <krinn> and key are positioned like that (right alt is altgr and if you look on key, the code to the right is the one coming up for that key with altgr push)
23:53:36 <Zuu> Because otherwise you can't use symbols typed with altgr togeather with Alt in a key combination.
23:53:47 <Zuu> That will not be possible in OpenTTD.
23:54:05 <Zuu> Unless we change to a symbols based hotkey system.
23:54:20 <Zuu> Which is quite a bit of work.
23:54:48 <SmatZ> I have only little experience with SDL key mapping, and there I was surprised how many SDLK_* are unused on normal keyboard
23:54:57 *** JOHN-SHEPARD_ has joined #openttd
23:55:05 <SmatZ> I don't know how other drivers behave
23:55:26 <SmatZ> so I can't help you much there :(
23:55:52 <Zuu> I've implemented symbol based hotkeys in Junctioneer, but that's quite a lot of work from my side.
23:56:22 <Zuu> With OpenTTD not only using SDL but several other drivers I fear it will become a nightmare to implement it for all drivers.
23:58:57 <Zuu> Also it will be problematic since you lose the ability to use meta keys that are involved in producing symbols for hotkeys in order to support all users in a sybols based hotkey system.
continue to next day ⏵