IRC logs for #openttd on OFTC at 2016-11-05
⏴ go to previous day
00:29:37 *** ElleKitty has joined #openttd
01:31:03 *** Supercheese has left #openttd
01:40:39 *** HerzogDeXtEr has joined #openttd
02:45:24 *** Supercheese has joined #openttd
03:00:18 *** supermop_ has joined #openttd
04:17:06 *** zeknurn has joined #openttd
04:22:10 *** zeknurn is now known as zeknurn`
07:02:03 *** Fatmice has joined #openttd
07:02:56 <Fatmice> V453000, are you around?
08:03:00 *** sla_ro|master has joined #openttd
08:23:12 *** Alberth has joined #openttd
08:23:12 *** ChanServ sets mode: +o Alberth
08:57:55 *** Defaultti has joined #openttd
09:11:58 *** andythenorth has joined #openttd
09:26:52 *** Progman has joined #openttd
10:36:18 *** tokai|noir has joined #openttd
10:36:18 *** ChanServ sets mode: +v tokai|noir
11:09:51 *** andythenorth has joined #openttd
11:15:48 <Alberth> apparently, you cannot write 0 bytes 1 time successfully :)
11:41:16 <andythenorth> Wolf01: is NRT? o_O
11:42:19 <Wolf01> I didn't do anything in the last 2 days
11:46:48 *** frosch123 has joined #openttd
11:56:19 <frosch123> is it catenary day?
11:57:10 <Wolf01> Need to fix the order of entries in dropdown
12:06:53 <frosch123> what is revert-9-master?
12:07:35 <andythenorth> at a guess, one of the branches created by github to merge across forks
12:08:07 <andythenorth> I’m guessing that github treats the forks as git remotes, then makes branches from them for pull requests
12:08:26 <andythenorth> I am not a fan of that, seems like massive overkill compared to feature branches in same repo
12:18:26 <Alberth> git is a distributed version control system :)
12:19:02 <Alberth> you get tracking of changes that you have seen for free
12:19:27 <Wolf01> I'll work in a branch of your repo in future, I'll trash my fork because it's a pita to do cross repo merges
12:21:03 <Wolf01> andy's master -> my master -> my dev -> andy's road-tram-types -> andy's master
12:21:04 <Alberth> it's just one additional netweork transfer
12:21:37 *** zeknurn has joined #openttd
12:21:46 <Alberth> so it saves you one master?
12:21:59 <Wolf01> I should have forked ottd not andy's
12:22:28 <Wolf01> Because if I want to sync with trunk I need to wait for andy too
12:22:43 <Alberth> you can just skip your master, and build "my dev" onto "andys master" in your repo
12:23:20 <Wolf01> Also if andy already applied some of my edits, maybe from one of my silly branches, we'll have conflicts all around
12:23:44 <Wolf01> That's why andy's dev is useless now
12:24:07 <Alberth> yeah, but conflicts have nothing to do with being remote
12:24:26 <Alberth> that happens if you work in the same area always
12:24:30 *** zeknurn is now known as zeknurn`
12:24:42 <Wolf01> No, but having all in one place is better
12:31:16 <andythenorth> you can add ottd as a git remote if you want to sync
12:31:20 <andythenorth> that’s what I’ve done
12:31:44 <andythenorth> I don’t know if/how Tortoise SVN will do that for you though
12:32:35 <andythenorth> the main reason I abandoned ‘dev’ in my repo is because the name is ambiguous
12:32:59 <andythenorth> and one thing git *cannot* do is rename branches that exist anywhere outside local
12:40:07 <frosch123> "tram" -> "road", ""->"rail"
12:47:05 <andythenorth> frosch123: am I applying your patches to my repo, or can you push them? o_O
12:47:34 <frosch123> i push that to trunk, then a pull trunk, then i merge trunk, then i push to your repo, easy :p
12:53:11 <DorpsGek> Commit by frosch :: r27676 /trunk/src (9 files in 2 dirs) (2016-11-05 12:53:03 +0100 )
12:53:12 <DorpsGek> -Codechange: Rename catenary functions, so that they refer unambiguously to either RoadCatenary or RailCatenary.
13:14:18 * andythenorth should copy some catenary from a tram grf
13:16:17 * andythenorth needs a faster CPU for compiling
13:16:33 <frosch123> not all types should have catenary :)
13:18:45 * andythenorth has been i7 for years
13:21:00 *** Myhorta has joined #openttd
13:29:21 *** gelignite has joined #openttd
13:34:49 * andythenorth needs tram sprites meanwhile :P
13:35:26 <Wolf01> How is with the gui split?
13:35:27 <frosch123> how did you group the sprites?
13:37:03 <andythenorth> Wolf01: gui split is fine afaict
13:37:10 <andythenorth> we need to resurect the icon I drew
13:37:48 <Wolf01> You could redraw the road icon too, and make rail, road, and tram all the same size
13:37:49 <andythenorth> frosch123: resp. the nml, or the sprites?
13:38:40 <Wolf01> Now I need to figure out why blue road builds red road
13:38:48 <frosch123> railtypes have two action3, one for wires, one for pylons
13:38:57 <frosch123> this separation does not seem to make sense for road
13:39:07 <andythenorth> I have only implemented the catenary flag in the nml afaict
13:39:23 <andythenorth> so currently using default catenary
13:39:58 <andythenorth> Wolf01: wrong indexes :P
13:40:05 <frosch123> roads seem to have a "back" and "front" group
13:40:17 * andythenorth has no idea, but has spent years getting the wrong value out of select widgets :P
13:42:12 <Wolf01> DropDownListParamStringItem *item = new DropDownListParamStringItem(rti->strings.menu_text, _sorted_roadtypes[roadtype][rst].Pack(), !HasBit(c->avail_roadtypes, roadtype)); <- I think the problem is here, maybe on the other side I don't ::Unpack(), but it's strange, if I don't do that it shouldn't work at all
13:47:36 <frosch123> ottd code makes no sense
13:50:26 <frosch123> Wolf01: you are translating the type twice
13:50:47 <frosch123> there should be no _sorted_roadtypes within the new DropDownListParam...
13:50:54 <frosch123> compare with GetRailTypeDropDownList
13:52:12 <Wolf01> Ok, I can tell you why I did it so
13:52:32 <Wolf01> If I store just the road subtype, it can conflict between tram and road
13:53:02 <Wolf01> With ::Pack() instead I can pass both road type and sub type
13:53:22 <Wolf01> But to retrieve the identifier I need to take it from the array
13:55:00 <Wolf01> I could change the macro to return the identifier instead of the subtype
13:55:02 <frosch123> FOR_ALL_SORTED_ROADTYPES(rst, roadtype) { <- rst is a roadtype, not a index into _sorted_roadtypes
13:55:25 <Wolf01> #define FOR_ALL_SORTED_ROADTYPES(var, type) for (uint8 index = 0; index < _sorted_roadtypes_size[type] && (var = _sorted_roadtypes[type][index].subtype, true) ; index++)
13:55:28 <frosch123> if you do _sorted_roadtypes[roadtype][rst] do do _sorted_roadtypes[roadtype][_sorted_roadtypes[index]]
13:56:07 <frosch123> so, do not use _sorted_roadtypes within the loop
13:56:08 <Wolf01> I could have done var = index
13:56:29 <frosch123> make it the same as for railtypes :)
13:57:03 <frosch123> anyway, is it intentional that ottd draws all the wrong catenary sprites?
14:00:33 <frosch123> but it only fixed the flat tracks, the sloped ones are still wtf
14:02:04 <Wolf01> frosch123, changing the way you said only fixed the order, but not the index-to-roadtype
14:02:22 <Wolf01> And I hope the order is right
14:04:55 <Wolf01> First one builds blue, second yellow, third red and the last one catenary
14:05:29 <Wolf01> andythenorth, the dropdown is in the right order now?
14:05:34 *** Defaultti has joined #openttd
14:06:23 <frosch123> why are there 16 sprites for 4 slopes?
14:09:33 <andythenorth> Wolf01: normal-blue-yellow-red is correct order
14:09:34 <Wolf01> There should be 16 roadbits
14:09:51 <andythenorth> ‘blue’ is missing name for some reason :)
14:10:06 <Wolf01> Ok, then I can commit this fix
14:11:43 <Wolf01> Now, index vs roadtype
14:16:34 <frosch123> well, looks like the second 8 are just trash sprites
14:16:46 <Wolf01> static CallBackFunction MenuClickBuildRoad(int index)
14:16:46 <Wolf01> _last_built_roadtype_identifier = RoadTypeIdentifier(index);
14:16:46 <Wolf01> ShowBuildRoadToolbar(_last_built_roadtype_identifier);
14:16:53 <frosch123> they contain something in the existing grfs, but the graphics do not make any sense
14:17:14 <Wolf01> Maybe they are the gui sprites?
14:17:48 <frosch123> 1394 to 1414 are fine
14:18:04 <frosch123> 1423 to 1437 are used since fs#1019
14:18:15 <frosch123> 1438 to 1445 are still unused
14:18:25 <frosch123> and they are ordered differently that the other slopes
14:18:51 <andythenorth> how would 1435 ever make sense? :|
14:18:59 * andythenorth fails to understand that one
14:19:04 *** Defaultti has joined #openttd
14:19:57 <Wolf01> Different poles? Maybe it was prepared to have both road with catenary and tram with a different catenary?
14:20:15 <andythenorth> there are two separate styles of catenary here
14:20:17 *** HerzogDeXtEr has joined #openttd
14:20:51 <Wolf01> 1435 shows different poles than 1424
14:21:25 <andythenorth> but...1435 can never be used without another overlay sprite
14:21:35 <andythenorth> I guess 1437 is supposed to overlay 1435
14:23:17 <Wolf01> Like 1395 is the overlay for 1423
14:24:09 <andythenorth> frosch123: are some of these intended for bridges?
14:24:19 <andythenorth> bridges have a different catenary style in ogfx it seems
14:24:30 <andythenorth> 1439 is a transitition sprite
14:24:37 <andythenorth> it has both types of pole
14:26:00 <Wolf01> I think we'll need to do V's way of layers with catenary on junctions/rail ccrossings
14:27:01 <frosch123> andythenorth: 1446 to 1451 are for bridges
14:27:38 <frosch123> hmm, bridges might be an idea
14:27:47 <andythenorth> when I build a bridge, I appear to get 1439
14:29:20 <frosch123> static const SpriteID tram_offsets[2][6] = { { 107, 108, 109, 110, 111, 112 }, { 4, 5, 15, 16, 17, 18 } };
14:29:22 <frosch123> static const SpriteID back_offsets[6] = { 95, 96, 99, 102, 100, 101 };
14:29:23 <frosch123> static const SpriteID front_offsets[6] = { 97, 98, 103, 106, 104, 105 };
14:30:14 <frosch123> well, then i have no idea how to split these sprites
14:30:42 <frosch123> they are mixed catenary, depot track, depot catenary, more catenary, brdige catenary, bridge tracks
14:33:02 *** JacobD88 has joined #openttd
14:37:18 *** ChanServ sets mode: +v tokai
14:41:36 * andythenorth looks at bridges
14:41:54 <andythenorth> bridge sprites have road baked in
14:42:00 <andythenorth> we’ll just overlay it? :o
14:42:08 <frosch123> do tram tunnels also only exist with road?
14:42:19 *** HerzogDeXtEr1 has joined #openttd
14:43:31 <Wolf01> How do I include the definition for uint8? The intellisense says it's in stdafx.h, but after including it it doesn't find it
14:45:41 <Wolf01> Ok, I'm idiot, I need to modify my stdafx to include ottd's one
14:50:54 <Wolf01> Ok, I think is better to not try unit testing again ottd
14:53:14 <Wolf01> This poor game is too header-spaghetti
14:53:58 <frosch123> while 23-26 seem to line up with 0-3 somewhat, 46-48 and 55 are just wtf
15:00:02 <andythenorth> 46-48 are blank in ogfx?
15:00:16 * andythenorth trying to map sprite numbers to the spritesheet
15:00:55 * frosch123 comparing groups to rails
15:18:17 *** behalebabo has joined #openttd
15:23:49 <Wolf01> Where is "_debug_" defined? It seem I can't use DEBUG() because of that, and I can't find the definition
15:24:05 <frosch123> it's constructed via macros :)
15:24:48 <frosch123> #define DEBUG_LEVEL(x) { #x, &_debug_##x##_level }
15:31:04 <Wolf01> Ha! With debug I finally understand that I'm clearly an idiot
15:31:35 <Wolf01> Index is index, not identifier
15:33:34 <Wolf01> But it should unpack in the right way
15:34:11 <Wolf01> I appended 4, 6, 2, 0 and when I click on the item I get one of those, in the right order
15:35:09 <Wolf01> Then the problem is on road_cmd now
15:40:51 <frosch123> oh, there are no combines road/tram depots
15:43:21 *** JacobD88 has joined #openttd
15:48:40 <Wolf01> Hmmm, all is right, but doesn't work o_O
15:52:37 <frosch123> this defines the new action3 spritetypes, and their order, and comparison to the existing tram sprites and in comparison to railtypes
15:53:45 <Wolf01> Are you sure to remove fences and crossings for ROTSG?
15:54:02 <Wolf01> Fences could be used in a highway grf
15:54:06 <frosch123> for railtypes the crossing defines the barriers and stuff
15:54:31 <frosch123> no idea how roadtypes would also add more stuff
15:54:37 <Wolf01> We'll need a bit to disallow roadtype crossings
15:54:42 <frosch123> fences can be added later :)
15:54:52 <frosch123> there are no fence mapbits currently
16:05:17 <Wolf01> I think that there's a problem with sprite mapping to roadtypes
16:06:16 <Wolf01> The values in the stack are right from dropdown item click to bits in map array
16:06:32 *** sla_ro|master has joined #openttd
16:06:36 <Wolf01> And the tile info agrees with me
16:21:47 <Wolf01> frosch123, could you be able to track down the wrong sprite problem for roadtypes?
16:22:07 <Wolf01> Yellow roads using red roads sprites <-
16:22:33 <Wolf01> Also I committed 2 fixes for the dropdown
16:26:21 <frosch123> or shall i pull from your one?
16:26:53 <Wolf01> I committed in my dev one
16:27:47 <frosch123> ok, so i add a third remote :p
16:31:50 *** JacobD88 has joined #openttd
16:53:41 <frosch123> it looks like valid java syntax
16:53:50 <frosch123> but i have no idea why c++ compiles it
16:54:49 <Wolf01> It initializes the 2 possible roadtype identifiers into the structure which merges them in a tile
16:55:40 <Alberth> can't you state the value of a constant as part of the declaration nowadays? although it doesn't look like a constant
16:55:59 <frosch123> it has no "static", so it is a member
16:56:05 <frosch123> member are initialised in some constructor
16:56:10 <frosch123> i have no idea what that construct does
16:56:13 <frosch123> i would claim it is invalid
16:56:45 <frosch123> Wolf01: you pack and unpack RoadTypeIdentifier multiple times
16:56:49 <Alberth> maybe it's a no-op expression :)
16:57:03 <frosch123> i think "RoadTypeIdentifier(uint8 data = 0)" should become "explicit"
16:57:22 <Wolf01> GetRoadTypeInfo(road_identifier.Pack()) <- ok, there is wrong
16:58:02 <Wolf01> It should only be packed when the function requires an int
17:02:26 <frosch123> there are some places, where Roadype is converted nito a RoadTypeIdentifier
17:02:35 <frosch123> because it uses the incorrect implicit conversion
17:05:25 <frosch123> implicit conversions are the root of all evil once again :)
17:06:54 <Alberth> there are more levels of evil? :)
17:07:12 <frosch123> hmm, it would be easier if the grf would not modify the original roadtypes
17:07:16 <frosch123> maybe the grf is wrong :)
17:07:22 <Wolf01> I noticed that, it can't even tell the difference between Class(void) and Class(int) if I do Class x = new Class();
17:09:15 <andythenorth> frosch123: you want a grf without original road and tram?
17:12:23 <frosch123> oh right, i cannot push to wolf
17:14:30 <Wolf01> I hope is the right frosch123 :P
17:16:12 <Wolf01> So, if I want exactly the type I should use "explicit"? Or else it accepts everything it can automagically cast?
17:18:22 <frosch123> if you have a function "SetupRoadToolbar(RoadTypeIdentifier roadtype_identifier)"
17:18:38 <frosch123> and you have an implicit conversion from integer to RoadTypeIdentifier
17:18:53 <frosch123> then it will implicitly convert any enum to integer, and then to RoadTypeIdentifier
17:19:04 <frosch123> so, SetupRoadToolbar(ROADTYPE_ROAD) will compile
17:19:05 *** sla_ro|master has joined #openttd
17:19:21 <frosch123> with the "explicit" you disallow the implicit case from integer to RoadTypeIdentifier
17:20:03 <frosch123> so you would have to write SetupRoadToolbar(RoadTypeIdentifier(ROADTYPE_ROAD)) or SetupRoadToolbar((RoadTypeIdentifier)ROADTYPE_ROAD), if you really wanted that conversion
17:20:20 <frosch123> however, since C and C++ are the worse languages designed ever, it does not work in all cases
17:20:53 <frosch123> it cannot distinguish implicit conversions and constructors when declaring variables
17:21:30 <supermop_> how are roads and tramways coming along today
17:22:41 <Wolf01> Where did you push the diff?
17:23:32 <frosch123> ! [remote rejected] HEAD -> dev (permission denied
17:27:29 <frosch123> andythenorth: you have the source to that grf somewhere?
17:28:11 <Wolf01> andythenorth, if you agree, we could continue to use our own repository, but you only pull the merge from my master, where I merge the dev commits when all things work (or seem to work)
17:32:19 <Wolf01> Uhm, frosch123, I think you reverted something like 6 of my commits
17:33:24 <Wolf01> - void ModifyRoadType(RoadType roadtype)
17:33:24 <Wolf01> + void ModifyRoadType(RoadTypeIdentifier roadtype_identifier)
17:33:45 <frosch123> yep, that was a bug :p
17:34:09 <frosch123> SetupRoadToolbar takes a RoadTypeIdentifier as parameter
17:34:13 <frosch123> but was passed a RoadType
17:34:20 <Wolf01> It updated to the "void ModifyRoadType(RoadType roadtype)"
17:35:00 <frosch123> did you push everything before?
17:35:18 <frosch123> as above link shows, i changed it from RoadType to RoadTypeIdentifier
17:35:58 <Wolf01> I'll try a cleanup with revert
17:41:18 <Wolf01> It complains about no default constructor found if I don't do that
17:41:20 <frosch123> RoadTypeIdentifier() : basetype(INVALID_ROADTYPE), subtype(INVALID_ROADSUBTYPE) {} <- i only know that syntax
17:41:27 <frosch123> still surprised the other one compiles
17:41:36 <frosch123> though i have no idea whether the compiler actually does anything
17:41:41 <frosch123> or whether it ignores it
17:42:25 <Wolf01> I usually work like that with no problems
17:43:09 <Wolf01> But for example doing "RoadTypeIdentifier rti;" it throws error
17:43:17 <frosch123> oh, i saw that, but thought it only contains the nml
17:43:55 <andythenorth> sprites are in gfx/
17:44:22 <andythenorth> it’s a hack of railtypes example, so it’s a mess
17:44:34 * andythenorth will fix before it goes to trunk nml
17:44:59 <andythenorth> Wolf01: I am happy to merge from your master if that works for you
17:45:09 <andythenorth> just make pull requests when you want to merge something?
17:45:17 <Wolf01> I don't think there's anything new
17:46:15 <frosch123> Wolf01: cxx 1998: 9.2 (4): "A member-declarator can contain a constant-initializer only idf it declares a static member (9.4) of integral or enumeration type, see 9.4.2"
17:46:23 <frosch123> so, at least in cxx 1998 it is invalid
17:46:41 <frosch123> i also wouldn't know to what constructor it should apply otherwise
17:46:48 <frosch123> default constructor only, or all constructors?
17:46:51 <Wolf01> Ok, so it is from that "new c++" the internet talks about
17:48:40 <Alberth> we have several of those :p
17:49:06 <frosch123> it is used if the constructor does not have its own initializer
17:49:51 <frosch123> it's about in the middle of that page
17:51:08 <andythenorth> supermop: did you ever play with the IH africa roster? o_O
17:51:14 <andythenorth> your pax coach looks good in game
17:53:39 <andythenorth> but the engine roster makes no sense :P
17:54:21 <Wolf01> So frosch123/Alberth, what should I do? Explicit initialization every time?
17:54:58 <Alberth> that gives the least surprises
17:58:21 <frosch123> currently ottd trunk is supposed to compile with both c++98 and c++11
17:58:38 <frosch123> that is, we made changes to things that are invalid in newer c++
17:59:06 <frosch123> but we did not use anything that requires newer c++ without adding some #ifdef
17:59:16 <frosch123> (like the static_assert in stdafx.h"
18:00:59 <Wolf01> Heh... I should initialize this:
18:00:59 <Wolf01> RoadTypeIdentifier _sorted_roadtypes[ROADTYPE_END][ROADSUBTYPE_END];
18:01:33 <frosch123> it is initialised at runtime
18:01:40 <Wolf01> It doesn't even compile
18:02:06 <Wolf01> 4>..\src\road_cmd.cpp(50): error C2512: 'RoadTypeIdentifier': no appropriate default constructor available
18:03:20 <Wolf01> If adding a void constructor works, you will get garbage into members
18:05:09 <Wolf01> RoadTypeIdentifier() : basetype(INVALID_ROADTYPE), subtype(INVALID_ROADSUBTYPE) {} <- maybe I could do it like this
18:15:59 <frosch123> Wolf01: i see, i failed the save->compile->commit order :)
18:16:14 <frosch123> didn't compile after my last change
18:18:32 <frosch123> though you can skip the call in RoadTypeIdentifiers()
18:18:42 <frosch123> it's thje same as the default constructor
18:19:19 <frosch123> so you do not need to explicitly initialise road_/tram_identifier
18:19:24 <frosch123> it will use the default constructor anyway
18:23:11 <Wolf01> Uhm, but it's not initialized as invalid
18:26:21 <Wolf01> Or you meant this? RoadTypeIdentifiers() : road_identifier(RoadTypeIdentifier()), tram_identifier(RoadTypeIdentifier()) {}
18:28:16 <frosch123> RoadTypeIdentifier has a default constructor, so RoadTypeIdentifiers() should use it
18:30:02 <frosch123> hah, found the text issue
18:30:16 <frosch123> it's yet another invalid conversion with that cursed constructor
18:30:22 <frosch123> do we really need it?
18:30:45 <Wolf01> I didn't figure out a better way to do this
18:30:55 <Wolf01> If you have suggestions they are welcome
18:35:05 <Wolf01> _cur.grffile->roadtype_map[basetype][id + i] <- this held the packed identifier before, then I changed it to subtype because I already had the basetype
18:35:44 <Wolf01> Also saved me to do pack/unpack and initializing various invalid identifiers
18:37:55 <frosch123> would make it more explicit
18:39:14 <frosch123> i believe some files have windows eol
18:39:22 <frosch123> git doesn't have the svn:eol-style thing
18:39:48 <Wolf01> Yes, a lot of files have that, the vs extenson to fix them complains about mixed style everytime
18:40:11 <Wolf01> I usually leave them as I found them
18:41:58 <frosch123> ok, so we blame andy :)
18:42:22 <Wolf01> So, if I need to unpack, I have to do it explicitly, makes sense
18:43:16 <Wolf01> I copied from the stuff in bool VehicleListIdentifier::Unpack(uint32 data)
18:44:34 <frosch123> i see :) well, as long as you type the right code, you do not need to rely no a compiler to check it :)
18:46:09 <Wolf01> I'll commit the fix in newgrf.cpp, that's more obvious to be fixed
18:55:04 <Wolf01> Ok, with the last commit I made everything seem to work
19:10:59 <frosch123> + static RoadTypeIdentifier Unpack(uint8 data) { <- there should be a \n before the {
19:11:02 <frosch123> otherwise it looks great :)
19:14:56 <frosch123> hmm, except, assert inside command handlers crashes servers :)
19:15:37 <frosch123> though i guess it is impossible to assert when passing only 5 bits
19:16:52 <Wolf01> Yes, it should be impossible
19:17:30 <frosch123> keep it as it is :)
19:17:41 <Wolf01> Ok, I'll commit it then
19:51:30 <Wolf01> Mmmh, I'm not able to get the latest edits from andy :(
19:52:45 <Wolf01> Eh, I need those, the problem it is trying to merge my changes and conflicts because they already are in my repo
20:06:10 <frosch123> pools also have Get and GetIfValid methods, so maybe this fits the style
20:08:50 <Wolf01> Btw, I need to figure out how to get the missing commits from andy
20:12:07 <Wolf01> I could do it with cli
20:14:18 <frosch123> i only ever do cli :)
20:14:44 <Wolf01> I should reinstall git
20:14:58 <Wolf01> But I don't want to have it twice
20:17:05 <DorpsGek> Commit by frosch :: r27677 /trunk/src (5 files) (2016-11-05 20:16:59 +0100 )
20:17:06 <DorpsGek> -Codechange: Remove implicit VehicleListIdentifier from uint32 constructor, to make conversions more explicit.
20:17:31 <Wolf01> Meh, "fatal: Not a git repository"...
20:19:00 <Wolf01> I'm trying to run what github suggests
20:20:50 <frosch123> git merge andy/road-and-tram-types
20:20:58 <frosch123> depending on whatever you called the andy remote
20:22:55 <Wolf01> Oh wait... this is a svn checkout, I deleted the git one
20:22:55 <Wolf01> But merge with github and svn doesn't work
20:24:18 <Wolf01> I'll see if timeouts or crashes after 90MB
20:24:37 <Wolf01> Ok, I can't even do it
20:24:51 <Wolf01> It must be from the same repository :P
20:25:24 <frosch123> i have heard of people using a git client on a svn server
20:25:34 <frosch123> you are the first one with a svn client on a git server :)
20:26:42 <Wolf01> Tortoise with the github patch says "Error"
20:29:13 <Wolf01> Ok, starting from the repo seem to read the patch
20:30:19 <Wolf01> Nice, I get the same empty failed hunks like Snail
20:30:45 <frosch123> what is andy's branch called in your clone
20:31:10 <Wolf01> I don't even have references to andy's repo
20:31:44 <Wolf01> Snail, how did you managed to patch some days ago with the weird conflicts?
20:31:58 <Snail> you mean to compile OTTD?
20:32:18 <Snail> I still can’t :( need to play with the pre-compiled nightlies
20:34:16 <frosch123> Wolf01: do you want to keep figuring it out yourself? or shall i merge and push to your repo?
20:34:42 <frosch123> i can't help you with tortoise stuff
20:35:11 <Wolf01> I would like to figure it by myself, a frosch chouldn't be there every time I'll need him ;)
20:36:00 <Wolf01> I'm good with tortoise and svn, I just can't understand this:
20:36:52 <Wolf01> In the diff viewer there isn't a single conflict
20:54:22 *** andythenorth has joined #openttd
20:55:28 <andythenorth> frosch123: that’s Red Electric Road?
20:55:32 <frosch123> we do not want to overlay catenaries, so i only draw the catenary of one roadtype, but with the roadbits of both types combined
20:55:48 <frosch123> andythenorth: yes, but that is no longer the issue :)
20:55:58 <andythenorth> just checking it’s road, and not tram :P
20:56:28 <frosch123> there is a roadtype and a tramtype in that picture, both with catenary
20:56:29 <Wolf01> Could electric road cross electric tram?
20:56:39 <andythenorth> but the catenary would be one type only
20:56:42 <frosch123> the catenary looks the same, but the tiles with both road and tram use the road catenary
20:56:59 <andythenorth> I think I had a note to myself somewhere
20:57:00 <Wolf01> Yes because electric road could have a "third rail"
20:57:11 <andythenorth> wise authors would keep their catenary same across tram / road
20:57:22 <andythenorth> ‘trolleybus looks different’ isn’t useful here
20:57:30 <Wolf01> If you load 2 concurrent roadtypes grfss?
20:59:41 <Wolf01> RoadType grf should be allowed to overwrite once the base catenary, and the last loaded one is the one which will be shown
21:00:38 <andythenorth> frosch123: image looks right; I’m trying to spot the obvious mistake we’ve all missed :P
21:01:05 <Wolf01> We all missed that we couldn't have different catenaries right now
21:01:36 <andythenorth> no that was known by me
21:01:52 <andythenorth> I just saw it as a benefit :)
21:02:54 <frosch123> andythenorth: do you also have a note on drive-in roadstops?
21:03:23 <Wolf01> They should be removed from trams
21:04:04 <Snail> so frosch123… your suggestion about sprite stacking seems to work
21:04:30 <Snail> thanks for that tip. Although it does make my code more complicated :p
21:04:46 <Snail> at least it solves my problem
21:06:27 <andythenorth> what’s the question about drive-in stops? o_O
21:12:02 <Wolf01> If I push the merged patch to my dev, how many problems it will cause with future merges?
21:12:52 <andythenorth> Wolf01: what does it patch?
21:13:26 <Wolf01> Oh, everything, I'm trying to sync my dev/master with your roa-and-tram-types
21:15:45 <andythenorth> in that caseit is not likely to cause problems with future merges
21:16:11 <andythenorth> there is an edge case where I reverted one merge a few days ago, and if that contains any commits you’re trying to merge, it will refuse
21:16:30 <andythenorth> they have to be cherry-picked in manually
21:16:45 <andythenorth> or someone who is good at git would just say ‘oh of course just rebase xyz'
21:17:23 <andythenorth> the idea of separate branches for different concerns in this patch is a nice...theory
21:17:31 <andythenorth> but everything will end up cross-dependent
21:17:51 <andythenorth> so might as well just merge
21:18:17 <Wolf01> We should update all the branches at the same time, and pull from a staging branch only
21:19:23 <Wolf01> The problem here is: I get from you, you get from me, frosch pushes to yours and sometimes to mine
21:19:52 <frosch123> i did not cross push anything
21:20:19 <frosch123> andythenorth: does nrt allow drive-in stops? what sprites to draw?
21:20:36 <andythenorth> I do not have a note for that :D
21:20:51 <andythenorth> could we get away with not supporting them? o_O
21:20:51 <frosch123> ok, i'll keep on skipping that question then :)
21:22:03 *** Supercheese has joined #openttd
21:22:31 <andythenorth> can we deprecate them? :P
21:25:28 <peter1138> depreciate them, like the pound
21:25:38 <andythenorth> does that mean they can come back up too?
21:25:46 <andythenorth> depending on the news of the day?
21:26:27 <peter1138> depends how often we avoid telling the truth
21:29:27 <andythenorth> can’t handle the truth
21:30:03 <andythenorth> Wolf01: so is your goal to get all your stuff into ‘my’ repo?
21:30:22 <frosch123> oh, there are no build commands for roadstops yet
21:30:23 <Wolf01> All "our" stuff in your repo
21:30:31 <frosch123> so there is no point in adding the drawing code :p
21:30:58 <andythenorth> Wolf01: I am going to add your repo as a remote
21:31:05 <andythenorth> it’s easier that using github pull requests
21:31:17 <andythenorth> but I have to not merge wrong branch… :P
21:31:51 <Wolf01> My master should be good, but it can't be merged to your branch because reasons
21:32:57 <andythenorth> ok, merge conflict
21:33:26 <frosch123> delete the HasCatenary member
21:33:38 <andythenorth> that’s the only conflict afaict
21:33:39 <Wolf01> There are something like 2 easy to solve conflicts
21:34:15 <frosch123> Fuco: there has always been a git mirror
21:34:34 <Wolf01> In 2 cases I modified the same lines which were modified by frosch when he removed the catenary bit
21:34:58 * andythenorth has done the merge
21:35:00 <frosch123> Fuco: only the official trunk is in svn. all development in the past years has always happend in hg or git branches
21:35:05 <andythenorth> haven’t checked it compiles mind
21:37:49 <frosch123> hmm, levelcrossing needs for cases for drawing :p
21:37:58 <frosch123> both road and rail can be custom or non-custom
21:38:36 <andythenorth> level crossings :x
21:38:43 * andythenorth tried to patch those once so trams don’t have road
21:38:45 <Wolf01> Also if you build a tram/rail crossing you need to have road too, for reasons
21:38:50 <andythenorth> it’s baked into the base tile
21:38:55 <andythenorth> I spent about a week on it
21:39:24 <andythenorth> it’s mostly just a sprite issue, but ran into some kind of ‘that is not a good enough spec’ problem
21:39:27 <andythenorth> so I abandoned it :)
21:39:32 <frosch123> well, with railtypes it is all solvable
21:39:41 <frosch123> problem is just tricking the original sprites
21:39:49 <andythenorth> oh that was the problem, it’s not solvable with default tracks
21:40:12 <andythenorth> and then it got caught up in ‘should trams even be allowed to cross monorail / maglev'
21:40:17 <andythenorth> standard #openttd stuff :)
21:41:18 <frosch123> road/tram underlay -> road/tram overlay -> rail overlay -> rail crossing sprites -> rail catenary -> road/tram catenary
21:41:30 <frosch123> 6 layers, and V was proud of 4 :p
21:41:46 <andythenorth> can we have a snow layer? o_O
21:42:01 * andythenorth has been considering types of road
21:42:13 <andythenorth> arctic, there could be a ‘snowploughed’ type that costs more
21:42:24 <andythenorth> and an ‘uncleared’ type that costs less :P
21:42:30 <Wolf01> And why not night layer, instead of drawing everything again with blue tint?
21:42:51 <frosch123> because games with day/night and weather suck
21:42:52 <andythenorth> or palette transform? :P
21:43:08 <andythenorth> it’s always midday in openttd
21:44:04 <Wolf01> Tractive effort change with rain
21:47:53 <andythenorth> wash your mouth out
21:48:17 <andythenorth> but if we had those...
21:48:24 <andythenorth> we could have fireworks on Nov 5th eh?
21:49:01 <andythenorth> such fireworks outside
21:51:11 <Wolf01> Such heavy rain outside
21:55:11 <Wolf01> Good, I think I'll create a development branch on your repo now
21:55:27 *** zeknurn has joined #openttd
21:55:46 <Wolf01> And I'll make pull requests when I'll need to merge into yours
21:57:54 <Wolf01> What's the status of your master?
21:58:13 *** zeknurn is now known as zeknurn`
22:00:21 <andythenorth> contains ottd master
22:00:27 <andythenorth> but nothing else
22:00:45 <andythenorth> there’s no particular reason to keep it clean
22:01:06 <andythenorth> every other project I work on, no merging to master until it’s ready for a production tag
22:01:09 <Wolf01> Should I branch from master and then pull from road-and-trams or should I branch directly from road-and-trams?
22:01:19 <andythenorth> branch from road-and-trams
22:01:34 *** Progman_ has joined #openttd
22:03:01 <Wolf01> Better if I install git
22:03:40 <Wolf01> I'll regret it a lot, but it's easier to solve github problems with git (I wonder why)
22:06:10 *** Progman_ is now known as Progman
22:13:44 *** Smedles has joined #openttd
22:15:55 <andythenorth> Snail: you have macbook wifi trauma? O_O
22:15:59 <frosch123> depots are too big for the gui picker :p
22:16:38 <andythenorth> Snail: you keep leaving and joining the channel ;)
22:16:54 <Snail> no, I just went out for the groceries
22:17:08 <andythenorth> frosch123: depots clip outside the UI for me, you mean that?
22:17:15 <Snail> dunno why it connected again, and then disconnected, why I was away
22:17:18 <andythenorth> it’s only a coupld of pixels, but eh
22:20:08 <Wolf01> Error encountered while cloning the remote repository: Response status code does not indicate success: 410 (Gone).
22:22:05 <andythenorth> Wolf01: no /branches :)
22:23:30 <Wolf01> Do I need to clone the entire repository?
22:24:19 <andythenorth> you’d end up with most of it anyway, even if you could clone a branch
22:24:38 <andythenorth> because the tree would reference a lot of shared commits
22:32:52 <Wolf01> How does it work when I want to commit then? I only see master
22:33:32 <andythenorth> what does ‘git branch’ tell you?
22:35:25 <Wolf01> Or better, I found the branche, but I don't know how to switch to them
22:36:56 <Wolf01> Maybe it did everything automagically with a double click on it?
22:36:57 <andythenorth> git checkout [branchname]
22:37:42 <Wolf01> Yes it did that automatically
22:39:15 <Wolf01> I don't want to know what could happen to edits if I switch branch
22:42:22 <Wolf01> Enough for this evening, I have a movie to watch
22:44:38 * andythenorth has a weird FIRS bug
22:44:44 <andythenorth> been trying to solve it for years
22:44:50 <andythenorth> Bulk Terminal is very hard to build
22:45:08 <andythenorth> I can find a straight bit of coast where the layout should fit
22:45:08 <Wolf01> I managed to build it every time O_o
22:45:48 <andythenorth> if I bulldoze the coast, and wait for bulldozed land to clear
22:45:53 <andythenorth> then I can build it every time
22:46:08 <andythenorth> why is a coast tile different after it has been bulldozed?
22:46:12 <andythenorth> and how can I check for that in the grf?
22:46:24 <andythenorth> bulldoze / dynamite /s
22:46:42 <andythenorth> I don’t change the terrain shape at all
22:51:04 <Wolf01> Instead I found a strange bug which I can't replicate, I can't run steam trains without a caboose, my friend, same company can run them without caboose O_o (happens with UKRS, so not your problem)
22:55:44 *** mescalito has joined #openttd
22:59:13 *** andythenorth has left #openttd
23:09:51 *** Fatmice has joined #openttd
23:22:52 *** JacobD88 has joined #openttd
continue to next day ⏵
