Log for on 22nd September 2012:
Times are UTC Toggle Colours
01:00:37  *** Zuu has joined
01:00:37  *** ChanServ sets mode: +v Zuu
01:15:50  *** Zuu has quit IRC
01:52:49  *** snobby has left
04:56:01  *** Eddi|zuHause has quit IRC
04:56:17  *** Eddi|zuHause has joined
07:54:47  *** peter1138 has joined
07:54:47  *** ChanServ sets mode: +v peter1138
08:05:28  *** Supercheese has quit IRC
08:14:28  <planetmaker> Terkhen, <-- 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
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
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
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: | 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 add <name> MEMBER :D
13:18:54  <Yexo> -ChanServ- You do not have access to the ADD command on channel
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
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 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 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
14:56:17  *** bassals has joined
15:12:45  *** andythenorth has joined
15:12:46  *** ChanServ sets mode: +v andythenorth
15:40:57  <Terkhen> <--- 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
16:23:27  <Terkhen> <--- 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
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 (yeah, my test save games were totally broken) combined patch (it is split in the FS task)
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
20:09:37  *** Guest7919 has quit IRC
20:10:32  *** maceex has joined
20:29:16  *** andythenorth has quit IRC
20:56:31  *** maceex has left
21:03:58  *** Alberth has left
22:12:25  <Yexo> FS#5207 and FS#5306 are both crashes due to not validating TTD savegames good enough
22:13:01  <Yexo> 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

Powered by YARRSTE version: svn-trunk