IRC logs for #openttd.dev on OFTC at 2012-09-22
⏴ go to previous day
01:00:37 *** Zuu has joined #openttd.dev
01:52:49 *** snobby has left #openttd.dev
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: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: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: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:23:49 <Terkhen> what I said before was related to tip, with 24536 I'm not getting any warnings either
09:06:35 *** Alberth has joined #openttd.dev
09:39:07 *** DorpsGek sets mode: +v Alberth
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: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 *** DorpsGek sets mode: +o TrueBrain
13:13:25 *** 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: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: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 *** DorpsGek sets mode: +o Yexo
13:19:29 *** DorpsGek sets mode: -o Yexo
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: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:24:09 <TrueBrain> why does Alberth have 2 accounts btw? :D
13:24:30 <TrueBrain> number 6 and 7 in the 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
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: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:23:12 *** FLHerne has joined #openttd.dev
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: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: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: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:16 <Terkhen> hmm... using the enum as array indexes?
17:34:27 <Terkhen> yes, that's why they are there :)
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: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:03:24 <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:12 <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:18 <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: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: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: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 *** DorpsGek sets mode: +v Supercheese
18:47:26 <Terkhen> Supercheese: we finally decided on option 4)
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: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: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: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: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:06 <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
20:07:24 *** Guest7919 has joined #openttd.dev
20:10:32 *** maceex has joined #openttd.dev
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:16:32 <Terkhen> it's strange that "old savegames are broken" bugs always come in groups after long intervals without any :)
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:26 <Yexo> something to look at later
continue to next day ⏵
