Times are UTC Toggle Colours
01:00:37 *** Zuu has joined #openttd.dev 01:00:37 *** ChanServ sets mode: +v Zuu 01:15:50 *** Zuu has quit IRC 01:52:49 *** snobby has left #openttd.dev 04:56:01 *** Eddi|zuHause has quit IRC 04:56:17 *** Eddi|zuHause has joined #openttd.dev 07:54:47 *** peter1138 has joined #openttd.dev 07:54:47 *** ChanServ sets mode: +v peter1138 08:05:28 *** Supercheese has quit IRC 08:14:28 <planetmaker> Terkhen, http://www.tt-ms.de/forum/showthread.php?tid=5933 <-- that seems a mingw related warning. Can you reproduce that? 08:14:45 <planetmaker> or is it expected? do you know (see screenshot)? 08:18:27 <Terkhen> planetmaker: although it is not exactly the same, it might be related to a recent issue 08:18:36 *** Zuu has joined #openttd.dev 08:18:36 *** ChanServ sets mode: +v Zuu 08:18:46 <Terkhen> when you install mingw, it lets you use prepackaged versions of packages or current versions 08:18:59 <Terkhen> the tutorial suggests to use prepackaged 08:19:17 <Terkhen> someone recently used current, and it seems that the gcc version used by mingw in current has compiler bugs 08:19:25 <Terkhen> let me see if I can find the thread 08:20:15 <planetmaker> I mean... it's only compile warnings. But wondering :-) 08:20:38 <Terkhen> oh 08:20:41 <Terkhen> then I have no idea :P 08:20:48 <Terkhen> I'm not getting any warnings 08:21:06 <planetmaker> also not r24536, thus tip? 08:21:16 <planetmaker> well, near tip 08:23:49 <Terkhen> what I said before was related to tip, with 24536 I'm not getting any warnings either 08:25:13 <planetmaker> hm, ok. Thanks 09:06:35 *** Alberth has joined #openttd.dev 09:29:40 <Terkhen> @voice Alberth 09:39:07 <Terkhen> @voice Alberth 09:39:07 *** DorpsGek sets mode: +v Alberth 09:39:25 <Alberth> thanks! :) 09:39:35 <Terkhen> I managed to sign peace with DorpsGek :) 10:12:51 <TrueBrain> Alberth: register with nickserv, and you also get auto-voice :) 10:21:04 <Alberth> TrueBrain: I am 10:21:37 <planetmaker> @whois alberth 10:21:53 <planetmaker> hm :-) 10:22:18 <Alberth> it's not very talkative, does it have voice? :) 10:24:41 <TrueBrain> DorpsGek doesnt need to know it; he should get autovoice from chanserv upon joining :) 12:46:10 *** andythenorth has joined #openttd.dev 12:46:11 *** ChanServ sets mode: +v andythenorth 13:11:59 <TrueBrain> @op 13:11:59 *** DorpsGek sets mode: +o TrueBrain 13:13:21 *** TrueBrain changes topic to "OpenTTD Dev Channel | Logs: http://webster.openttdcoop.org/?channel=openttd.dev | Voice (talk-right) upon request; make sure you are registered to NickServ before asking" 13:13:25 <TrueBrain> @deop 13:13:26 *** DorpsGek sets mode: -o TrueBrain 13:16:39 <Yexo> is there a shortcut to giving someone voice? 13:16:46 <Yexo> does @voice register the right with nickserv? 13:16:51 <TrueBrain> nope 13:16:55 <TrueBrain> the @voice just adds it temporary 13:17:01 <TrueBrain> you have to add it to chanserv if you want to make it stay 13:17:39 <TrueBrain> most people are already registered to NickServ, I don't see a need to make them register to DorpsGek too, so the latter will never auto-voice :) 13:18:00 <Yexo> ok 13:18:15 <TrueBrain> so the shortcut is: /msg chanserv access #openttd.dev add <name> MEMBER :D 13:18:54 <Yexo> -ChanServ- You do not have access to the ADD command on channel #openttd.dev. 13:19:25 <Yexo> @op 13:19:25 *** DorpsGek sets mode: +o Yexo 13:19:28 <Yexo> @deop 13:19:29 *** DorpsGek sets mode: -o Yexo 13:19:31 <Yexo> that didn't help 13:19:40 <TrueBrain> try now 13:19:49 <Yexo> thanks :) 13:19:54 <Yexo> whatever you did :p 13:19:58 <TrueBrain> I made you master 13:20:13 <Yexo> in that case, make more devs here master 13:20:18 *** mib_wspg9m has joined #openttd.dev 13:20:28 <TrueBrain> I am not sure why planetmaker didn't .. 13:20:28 <Yexo> it'd be highly annoying to have to wait for someone to give a new users voice here 13:20:37 <planetmaker> I thought ops could give membership 13:20:42 <TrueBrain> and you can always temp-voice someone 13:20:46 <TrueBrain> so it isnt a biggy in any case 13:20:51 <Yexo> ah, true :) 13:20:59 <TrueBrain> planetmaker: I kinda assumed too .. but it seems you cant :D 13:21:27 <planetmaker> :-) then let's all be masters of the universe ;-) 13:21:37 <TrueBrain> Yexo: all devs can use DorpsGek @voice, or op theirself and voice, so meh :) 13:22:44 *** andythenorth has quit IRC 13:24:09 <TrueBrain> why does Alberth have 2 accounts btw? :D 13:24:22 <planetmaker> two? 13:24:30 <TrueBrain> number 6 and 7 in the list 13:24:53 <Alberth> which list? 13:24:59 <TrueBrain> ./msg chanserv access #openttd.dev list 13:25:07 <planetmaker> TrueBrain, albert != alberth I assume 13:25:22 <TrueBrain> so which one is it? :D 13:25:26 <planetmaker> removed the first 13:25:51 <TrueBrain> yeah, AlberT is someone else :D 13:26:03 <TrueBrain> Last seen: Wed 21 Mar 2007 02:28:24 +0000 (5y 6m 5d 10:57:19 ago) 13:26:18 <Alberth> w're all one big family :) 13:26:27 <TrueBrain> ./msg chanserv access #openttd.dev list 13:26:31 <TrueBrain> oops 13:29:33 <Zuu> nice error :-) 13:33:57 *** mib_wspg9m has quit IRC 14:14:42 *** KenjiE20 has left #openttd.dev 14:56:17 *** bassals has joined #openttd.dev 15:12:45 *** andythenorth has joined #openttd.dev 15:12:46 *** ChanServ sets mode: +v andythenorth 15:40:57 <Terkhen> https://secure.openttd.org/bugs/task/5297 <--- I'm inclined to use option 4), any thoughts? 15:42:15 <Alberth> +1 15:44:05 <Yexo> 4) or 2), 4) has my preference too 16:08:03 <Terkhen> ok, I'll commit 4), I think that I've waited enough :P 16:08:05 <Terkhen> thanks :) 16:23:12 *** FLHerne has joined #openttd.dev 16:23:27 <Terkhen> http://devs.openttd.org/~terkhen/patches/index.php?folder=scenario/ <--- creates ExtendedHeightmap and HeightmapLayer classes and uses them to generate heightmap instead of the current scheme, it also cleans up most of the heightmap code 16:24:05 <Terkhen> I'm not planning to commit this part until I have most of the real feature code finished, but I would like to get some pointers about the foundations before I build up further in the queue 17:01:26 <Alberth> oh, you have started, nice 17:02:31 <Terkhen> I started many times, got stumped, and left it for another day :P 17:08:03 <Alberth> if ((height_layer->width * num_div) / height_layer->height > ((this->width * num_div) / this->height)) { way too many parentheses in 50 17:09:50 <Terkhen> ok, I'll try to make it nicer 17:10:02 <Terkhen> it is the original scaling code with just variable changes 17:13:50 <Alberth> ah 17:14:28 <Alberth> at first sight the number of new files seems a bit large 17:15:13 <Alberth> ie (without looking at it in details), I would simply throw all headers in heightmap.h 17:15:34 <Terkhen> heightmap_layer and heightmap could be merged... at first I planned to delegate more functionality in heightmap layers, but in the end I decided that it would be better if they were just data struct handled by the extended heightmap 17:15:59 <Terkhen> that would reduce all heightmap files to just three, heightmap_base.h, heightmap_type.h and heightmap.cpp 17:16:09 <Terkhen> heightmap.h is removed later in the queue, after the cleanup 17:16:22 <Alberth> why split _base and _type ? 17:17:08 <Terkhen> it is the naming scheme being used in other classes 17:17:51 <Alberth> hmm, let me rephrase :) why not move _type stuff into _base ? 17:19:03 <Terkhen> other classes keep enums at _type, class definitions at _base and global functions at _func, check for example vehicle 17:20:04 <Alberth> I thought we only did that when it has a use 17:20:20 <Terkhen> other than consistency, there is no good reason for keeping two separate headers, as nothing requires heightmap_type specifically 17:20:43 <Terkhen> if it is only when it has a good use, in this case it should have a single header :) 17:20:58 <Alberth> do you want specific comments now? 17:21:51 <Alberth> it looks like a nice start, a bit big-ish, but perhaps that's needed, I don't know how much is still coming 17:22:16 <Terkhen> I'm interested mostly in knowing if the class structure that I'm using has any problems that I'm not seeing 17:23:30 <Terkhen> after this, it is missing "load of extended heightmaps with only a height layer and a metadata file", "export of scenarios as extended heightmaps", "gui for deciding which features do you want to export, "implementing support for each layer and object file" 17:23:46 <Terkhen> it's going to be big, yup 17:25:58 <Alberth> struct ExtendedHeightmap in 30 needs memory management of the HeightmapLayer * in layers 17:26:16 <Alberth> and I'd drop '_map' in the variable names :) 17:26:27 <Terkhen> hmm... true :O 17:26:36 <Terkhen> that's means too much java for me 17:27:29 <Terkhen> the _map is because I did not know how to explicitly separate the "maximum height for each tile" variables from the "MapSizeY()" variable 17:29:48 <Alberth> My reason was that they are in a ExtendedHeightmap structure, what other heights except of the map do you have there? :) 17:30:45 <Terkhen> lines 98, 99, 100 and 102 17:30:49 <Terkhen> of patch 030 17:30:55 <Alberth> this->layers has a fixed max number of layers? (ie every HeightmapLayerType exists at most once?) 17:31:20 <Terkhen> maybe they should have _tile_ instead of _map_, that should be more clear 17:31:30 <Terkhen> Alberth: yes, it can only have one of each type of layer 17:33:08 <Alberth> wouldn't an array be easier than a map in that case? 17:34:01 <Alberth> oh, 'highlight' links give me colours :D 17:34:17 <Terkhen> hmm... using the enum as array indexes? 17:34:27 <Terkhen> yes, that's why they are there :) 17:35:13 <Alberth> :) 17:35:36 <Alberth> Order of these enums has to be the same as in lang/english.txt <-- such comment really makes me wonder what it refers to :) 17:36:04 <Terkhen> you are right, the map is not needed, I'll change it to a plain array with a MAX_LAYERS enum value at the end :) 17:37:44 <Alberth> struct HeightmapLayer in 20 needs a constructor if you want that free(this->information) does something sane 17:41:17 <Alberth> Hmm, would it be useful to make a derived class for each type of layer? 17:42:14 <Alberth> +void ExtendedHeightmap::ApplyHeightLayer(const HeightmapLayer *height_layer) <-- this would move to that class then 17:43:23 <Alberth> void ApplyLayers(); <-- I read that as "ApplyLawyers()" :D 17:43:39 <Terkhen> WRT the constructor, true, I'll add it 17:44:11 <Terkhen> about making each type of layer a derived class... it's one of the details I'm most unsure about 17:44:44 <Terkhen> in one hand, all layers are quite simple, and it might be better to just keep them as data and let the extended heightmap manage each one of them individually 17:45:06 <Terkhen> on the other hand, even if they are simple, each one is a different type of paletted image 17:45:21 <Terkhen> and it might be worth the effort of keeping them separate just to let each one of them have different "load" methods 17:46:33 <Alberth> it does not reduce code amounts I think, just organization, and finding code again 17:47:56 <Terkhen> it might also be helpful to keep the code of each layer in a separate class if the road layer ends up being more complicated than the others 17:48:29 <Alberth> or if we add generators some day 17:49:09 <Terkhen> ok, I'll switch to derived classes for each layer type :) 17:49:40 <Alberth> by moving 'everything' in a derived layer class, the global management code in the extended heightmap does not change when you add/modify layers 17:50:19 <Alberth> I cannot see big disadvantages at this time, and it might become useful 17:50:26 <Terkhen> given this change, it might be worth to keep heightmap_base and heightmap_layer_base (and heightmap.cpp and heightmap_layer.cpp) files separate 17:52:10 <Alberth> 70 +ExtendedHeightmap *_extended_heightmap_gui; add " = NULL;" so "delete _extended_heightmap_gui;" doesn't break 17:52:22 <Alberth> I am however not sure "delete NULL" is allowed 17:53:57 <Yexo> delete NULL; is valid (it's a NOP) 17:56:30 <Alberth> k 17:57:01 <Alberth> 70 line 155 _extended_heightmap_gui = new ExtendedHeightmap(); <-- check for being NULL before? 17:57:42 <Alberth> and after 159 set it to NULL? 17:58:18 <Terkhen> ok to all NULL issues 18:01:04 <Alberth> that seems to hold for _extended_heightmap in 80 too 18:01:50 <Terkhen> most surely, ok :) 18:03:35 <Alberth> it would be nice if you could move 90 further up, so it becomes more clear you moved the code, but I cannot see how well that can be done 18:03:44 <Alberth> it seems like a nice start 18:05:13 <Terkhen> I did not find any way of keeping 090 closer to the moved code without keeping the heightmap conversion broken for a few revisions 18:05:57 <Terkhen> Alberth: thanks for the review, I'll start implementing all changes :) 18:29:55 <Terkhen> meh, I forgot that modifying colour codes and keeping the old translated strings is bad(TM) 18:30:19 <Terkhen> what was the preferred solution, removing them or modifying the colour codes in the existing strings? 18:31:18 <Yexo> if you just change the colour modify them in existing strings 18:32:40 <Terkhen> will that mess up things if someone has already translated the modified strings (they show up in WT3 as strings needing validation) 18:32:45 <Terkhen> TrueBrain^ 18:33:47 <TrueBrain> it will just push them again to the "needs validation" category 18:33:57 <TrueBrain> WT3 is build in such way that subversion always wins 18:34:08 <TrueBrain> so if anyone made any change to it outside the colour change, it will be lost 18:35:15 <Terkhen> okay, thanks :) 18:36:20 <TrueBrain> you can ofc wait for 19:45, but meh :) 18:38:25 <Terkhen> warning: STR_REFIT_NEW_CAPACITY_COST_OF_REFIT: command 'RED' exists in template file but not in language file <-- I'm worried because I compiled the revision of today's translators commit and got many warnings like that one 18:38:38 <TrueBrain> your fault :D 18:39:08 <Terkhen> exactly, that's why I'm fixing it :P 18:39:29 <Terkhen> there is a nightly at least, so at least it is not a total disaster :) 18:39:39 <TrueBrain> the system is very forgiving :) 18:46:31 *** Supercheese has joined #openttd.dev 18:47:14 <Terkhen> @voice Supercheese 18:47:14 *** DorpsGek sets mode: +v Supercheese 18:47:26 <Terkhen> Supercheese: we finally decided on option 4) 18:47:38 <Supercheese> Ah, I see 18:48:00 <Terkhen> it's been committed already, today's nightly should have it for english... and tomorrow's nightly for all other languages 18:48:11 <Supercheese> :) 18:51:49 <Alberth> FS#5263 http://devs.openttd.org/~alberth/group_gui2.png (yeah, my test save games were totally broken) combined patch (it is split in the FS task) http://devs.openttd.org/~alberth/diffs/all_except_remove_useless_panel.patch 18:53:08 <TrueBrain> Terkhen: as a FYI, it undid 4 changes in 2 languages :) 18:53:26 <Terkhen> 4 of those are my own changes 18:53:41 <TrueBrain> hehe 18:53:42 <Alberth> it adds a little bit more space at the left of the group gui, splits the buttons at the bottom right a bit better, and removes some old size stuff that is not really needed 18:53:55 <TrueBrain> here I was proud of our translators, but it was only you :P 18:54:06 <Terkhen> that reduces the damage a bit, I'm sorry for the other translator 18:54:17 <Terkhen> oh, it does not undo all of my changes, only the changes to those two strings? 18:54:19 <Terkhen> nice :P 18:54:28 <Terkhen> Alberth: compiling 18:54:30 <Alberth> patch by Juanjo 18:54:33 <TrueBrain> yes yes, WT3 is relative clever :) 18:55:18 <Alberth> the three shots, the top one is original, the bottom 2 are changed versions for different text sizes 18:56:05 * Alberth ponders whether something can be relative unclever :p 18:57:13 <Terkhen> Alberth: why is the separator between the two buttons present in 2 but not in 3? 18:57:35 <Alberth> font is too big 18:57:53 <Alberth> it's there, just width=0 :) 18:58:52 <TrueBrain> Alberth: ofc; for the same reason something can be relative clever. In fact, saying it is relative is a bit useless, as clever etc is always based on a bias, therefor relative :D 18:59:38 <Terkhen> Alberth: looks fine to me, both code-wise and appearance-wise 18:59:54 <Alberth> ok, thanks for the check 19:01:05 <Alberth> TrueBrain: perhaps everything can be relative clever as well as relative unclever :) 19:01:25 <TrueBrain> I like the relative clever level of this conversation :D 19:01:57 <Terkhen> after spending all the day code to me it reads like "blablabla clever blablabla unclever" 19:02:04 <Terkhen> which probably means that I should continue tomorrow 19:02:18 <TrueBrain> I also read it like that, so not sure :D 19:02:57 <Alberth> "clever" is easier to type then "blablabla" :p 19:03:03 <Terkhen> :P 20:07:24 *** Guest7919 has joined #openttd.dev 20:09:37 *** Guest7919 has quit IRC 20:10:32 *** maceex has joined #openttd.dev 20:29:16 *** andythenorth has quit IRC 20:56:31 *** maceex has left #openttd.dev 21:03:58 *** Alberth has left #openttd.dev 22:12:25 <Yexo> FS#5207 and FS#5306 are both crashes due to not validating TTD savegames good enough 22:13:01 <Yexo> http://devs.openttd.org/~yexo/fs5207_2.diff I made this as a start, it works for FS#5207 but is clearly not good enough since the savegame from FS#5306 still crashes with this applied 22:16:32 <Terkhen> it's strange that "old savegames are broken" bugs always come in groups after long intervals without any :) 22:19:09 <Yexo> yep 22:19:19 <Yexo> although 5207 is from june, so it's a few months old already 22:19:49 <Yexo> I think it needs the patch above and then some more checks to clean up all unused water bits 22:20:26 <Yexo> after that some consistency check to make sure tiles with 'coast' bit set can actually be at the coast etc. 22:25:13 <Terkhen> so it must assume that most water tiles might be incorrect? 22:29:07 <Yexo> yes 22:29:26 <Yexo> something to look at later 22:29:27 <Yexo> good night 22:43:54 <Terkhen> good night Yexo 23:16:13 *** bassals has quit IRC 23:56:28 *** Zuu has quit IRC