IRC logs for #openttd on OFTC at 2010-12-09
⏴ go to previous day
00:16:02 <CIA-10> OpenTTD: yexo * r21440 /trunk/src/ (strings.cpp strings_func.h townname.cpp): -Codechange: pass a pointer to just past the end of the argv array around in FormatString and friends
00:17:03 <CIA-10> OpenTTD: yexo * r21441 /trunk/src/strings.cpp: -Codechange: check all accesses to the argv array so a bad NewGRF can 'only' trigger an assert but no longer cause an invalid memory read
00:24:15 *** rhaeder has joined #openttd
00:27:08 *** roboboy has joined #openttd
00:47:12 *** Markavian has joined #openttd
00:49:57 *** supermop has joined #openttd
01:03:35 *** Keyboard_Warrior has joined #openttd
01:44:15 *** Keyboard_Warrior has quit IRC
02:28:09 *** welshdragon has left #openttd
02:28:23 *** welshdragon has joined #openttd
05:56:17 *** Eddi|zuHause has joined #openttd
06:35:18 *** PulseNeon has joined #openttd
07:08:39 *** Mortomes|Work has joined #openttd
07:14:42 *** norbert79 has joined #openttd
07:14:59 *** norbert79 has left #openttd
07:15:52 *** fonsinchen has joined #openttd
07:18:18 *** Cybertinus has joined #openttd
08:15:38 *** IchGuckLive has joined #openttd
08:16:09 <IchGuckLive> Good morning from Frech snowed Germany 4inch
08:17:16 <Mortomes|Work> It's darker outside now than when I left home 2 hours ago
08:17:24 <IchGuckLive> Question on subsidy : if a bus service reatched the offer ,can i build a train service there and get the same multplier
08:26:52 <IchGuckLive> Question on subsidy : if a bus service reatched the offer ,can i build a train service there and get the same multplier
08:27:04 <PulseNeon> IckGluckLive: I think they do count, as -long- as it's between the same cities
08:28:04 <IchGuckLive> so i will do so in 5min we will now more
09:02:15 *** Progman has joined #openttd
09:07:10 *** JVassie has joined #openttd
10:08:48 *** PulseNeon has left #openttd
10:46:57 *** LadyHawk has joined #openttd
10:47:44 <LadyHawk> forgive me if this has been noted, or already addressed in a nightly.. i found an issue with grouping trains and send for servicing
10:48:03 <LadyHawk> i have 2 groups of trains, 1 group i sent for servicing, but the second group also took the order
10:48:32 <LadyHawk> i have ottd 1.0.5 without nightlies
10:49:53 <LadyHawk> the 2nd group has a forced service on it's route so it's unneccessarily blocking the track off now lol
10:50:42 <LadyHawk> the 2nd group seemed to be fine at first, no order showing and they kept loading.. maybe because they were too far from a depot at the time i dont know
10:50:56 <LadyHawk> but by the time they reached the place group 1 went to the depot, the 2nd joined in
10:51:10 <LadyHawk> i have breakdowns set to 0 and servicing off so that can't be a coincidence
10:53:50 <Terkhen> LadyHawk: are you sure you had "Group 1" selected when you used the "Send for service" order?
10:54:03 <LadyHawk> just watching the trains now... a train from group 2 seems to continue it's normal order, not noting the depot order.. but once it reaches the 'Path Signal' by the station (PBS) they change their order to the servicing one
10:55:05 <LadyHawk> i can try and let the mess clear in my saved game and do it again to make sure
10:55:31 *** fjb is now known as Guest447
10:58:00 <Terkhen> LadyHawk: if you can reproduce the problem, you should report the savegame and the required actions to trigger the problem to http://bugs.openttd.org/
11:00:03 <LadyHawk> ok will do, just trying it again but there's 1 condition i can't recreate right now.. the trains seem fine this round
11:18:22 <LadyHawk> i want drive through train servicing stations, sorta like the drive through bus stop, so 1 train can go in and 1 out at same time
11:19:24 *** ChanServ sets mode: +v tokai
11:21:09 <LadyHawk> just the same as a regular train depot, just with track on 2 sides instead of 1
11:22:26 <Terkhen> LadyHawk: IIRC they call them RoRo stations
11:22:55 <b_jonas> Terkhen: ror stations are stations, she asked for depots
11:23:31 <Terkhen> hmm... there was a patch to get depots to work like that, but to my knowledge it never was finished
11:24:57 <LadyHawk> i use that right now but since there's 1 way tracking systems, there should be like 1 way train depots to go with it
11:26:26 <b_jonas> so what would be the advantage of these drive-through depots?
11:27:32 <LadyHawk> adaptability to a 1 way track system that you dont have right now, on a heavily used 1 way track system, the screeny i posted doesn't work because each train waits in effect for 2 trains (1 going in, then it coming out)
11:28:35 <b_jonas> if you put the depots next to stations, there's less wait I think
11:28:44 <b_jonas> because the trains don't have to slow down as much
11:29:05 <Terkhen> I prefer to not place the depots directly in the mainline
11:29:13 <b_jonas> I usually put depots next to station entrances, with the entrance part guarded by path signals
11:29:32 <LadyHawk> if you have 1 way tracks everywhere, and put depots by all stations, trains end up going wrong because they want to reach the closest depot, rather than a depot on their own route
11:29:49 <LadyHawk> when they go wrong they stop listening to stuff like entrance/exit signals
11:30:00 <LadyHawk> and block everything off completely until you rebuild the track yourself
11:30:15 <b_jonas> one-way path signals help there
11:30:25 <Eddi|zuHause> you can make depot orders
11:31:20 <LadyHawk> all trains forced into 1 depot again, slows them down because each train will block the next one off twice
11:31:34 <LadyHawk> a block of 'choose 1 out of 4 available' is quicker, but can't do that with an order
11:32:53 <b_jonas> LadyHawk: there's a go to nearest depot order, isn't there?
11:32:57 <Eddi|zuHause> [waypoint]-[signal]-[switch-block]-[depots]
11:33:10 <b_jonas> you can put that after stations in the order list, and put multiple depots at the station exit
11:33:19 <Eddi|zuHause> "goto waypoint, if need servicing . choose nearest depot"
11:33:50 <b_jonas> Eddi|zuHause: hmm, that sounds nice
11:34:18 <LadyHawk> 'go to nearest depot' is what makes trains go wrong.. and the switch block thing is what i got now, in a central place without the way point
11:34:38 <b_jonas> but I still think the right place for most rail depots is at signal exits or entrances because anywhere else trains going to it will have to slow down unnecessarily
11:34:41 <LadyHawk> trains seemed to understand they had no choice but to go through that so i didn't see the point of placing a waypoint lol
11:35:08 <Eddi|zuHause> LadyHawk: yes, excactly that is why you need the waypoint. you put it in a place where the "wrong" depots are not reachable anymore
11:35:55 <LadyHawk> so train goes from station -> waypoint -> station
11:36:11 <LadyHawk> when train is in between station -> waypoint, and reaches a send for servicing order from the list
11:36:25 <LadyHawk> not the depot along its route by the waypoint
11:36:37 <Eddi|zuHause> LadyHawk: it won't get send to depot notices anymore
11:36:47 <Eddi|zuHause> except right after the waypoint
11:37:19 <LadyHawk> goto train overview -> manage list -> send for servicing ?
11:37:55 <LadyHawk> i have breakdowns 0 and servicing off so to replace them i have to use those XD
11:38:06 <Eddi|zuHause> LadyHawk: i'm not sure about that. i meant the periodical servicing mostly
11:38:30 <LadyHawk> 1 group of trains has a forced block, but another needs to receive an order from that list
11:38:32 <Eddi|zuHause> LadyHawk: if replacement is set, they automatically go for servicing, even if servicing is off
11:38:39 <LadyHawk> need a central depot block for that or they block stations
11:39:39 <LadyHawk> put a depot there, trains will go towards it and end up blocking the exit signals in the stations where a train's already waiting
11:39:45 <Eddi|zuHause> sending _all_ trains to depot simultaneously is bound to cause problems...
11:39:46 <LadyHawk> entrance/exit signals get ignored
11:40:11 <b_jonas> LadyHawk: that's why I'm saying use block signals or one-way path signals
11:40:22 <b_jonas> use two-way path signals only where they're really needed
11:41:58 <LadyHawk> hmmm i dont think i have the space to do that with realistic acceleration
11:43:02 <b_jonas> didn't you say you're using one-way tracks anyway?
11:43:08 <b_jonas> what do you not have the space for then?
11:43:32 <b_jonas> it is okay to use the two-way path signals right at terminus stations where trains go two way
11:44:31 <b_jonas> but like this: two-way path signal from the station tracks to the switcher part, but one-way path signals from the entry lines to the switcher part, and one-way signals from the switcher to the exit lines
11:45:18 <b_jonas> oh, you mean at the crossings?
11:45:27 <b_jonas> what on earth are all those industries?
11:45:39 <LadyHawk> the loading stations in the circled tracks
11:45:44 <LadyHawk> they're all iron ore mines
11:45:52 <LadyHawk> there'll be 200+ trains going to a 13 track offload station
11:46:01 <LadyHawk> i like challenging builds :)
11:46:26 <b_jonas> I don't have any practice in such large networks, so I can't give good advice
11:46:49 <LadyHawk> the station setup itself i got the hang of, i've had 180 trains on it ok
11:46:58 <LadyHawk> just the track leading to the station got a bit clogged
11:47:05 <LadyHawk> so i restarted trying a different setup
11:47:28 <LadyHawk> 1 central circle, and 'wings', rather than a circled grid
11:51:04 <LadyHawk> something like this would love to see 2 trains accessing a depot, 1 going in, 1 going out the other end :)
11:51:24 <b_jonas> and it has very few trees or towns too
11:51:26 <peter1138> i guess an improved mountain range and river generator wouldn't be in your list of priorities :p
11:51:43 <LadyHawk> trees obstruct my view so i left those out XD
11:51:50 <LadyHawk> and a mountain range would only get leveled anyway
11:52:12 <b_jonas> LadyHawk: you couldn't level it completely if industries are at different heights
11:52:44 <LadyHawk> i didn't really make the map to tackle world obstacles though
11:52:57 <LadyHawk> i build it so i could see just how efficient i could build my train tracks
11:53:01 <LadyHawk> pushing it to the limit
11:53:24 <b_jonas> also mountains are not as much of a challenge if you (1) have build with foundations and autoslope, (2) use realistic acceleration, (3) have lots of money, (4) don't have to worry about chopping down trees hurting your town reputations.
11:54:24 <b_jonas> unless you want ships.
11:54:32 <LadyHawk> i'm no expert, if i see something that doesn't work fast compared to the rest, i try and rebuild it.. what i found so far is having to merge say.. 8 lanes to 3, take steps, 8->5->3 and give all merging tracks the option to take 2 different tracks except for the outer ones
11:54:51 <LadyHawk> so if a train's merging, they have the option to take another lane
11:55:56 <LadyHawk> giving a train the option to take 3 different tracks.. slows them down for the chance that 1 train blocks everything off
11:56:44 <LadyHawk> the main obstacle i have is the depots being forced 2 way, not 1 way
12:00:22 <LadyHawk> thinking about it though, a train depot like that could be too easy, unless you make their exit slightly slower than their entrance.. to avoid people from just plopping them in the central track
12:01:03 <b_jonas> presumably trains would still have to slow down whenever they enter it, just like at normal depots
12:01:57 <LadyHawk> but thinking about them entering and exiting at the same speed... there wouldn't be any difference in having 200 trains on 1 track all going down 1 depot.. no waiting for eachother, no slowdowns because they'll all have the exact same speed
12:02:34 <LadyHawk> slow their exit more than their entrance.. and trains end up queueing up inside the depot.. keeping people from doing it the easy way because they all just clump up
12:03:00 <b_jonas> if you wanted to play that way, you'd just set the options to no service and trains never getting old and starting in year 3000 with the best maglevs.
12:03:46 <LadyHawk> that'd be boring.. maglevs aren't affected by the realistic accel slowdown in turns
12:04:13 <LadyHawk> it's more fun having to build a depot into it
12:04:59 <b_jonas> your screenshots seem to have lots of sharp turns though
12:05:17 <b_jonas> and yes, it would be boring
12:05:29 <LadyHawk> there's not a single slowdown turn in the entire track
12:05:45 *** KenjiE20 has joined #openttd
12:05:45 <LadyHawk> except for maybe the loading station exits, i'm not sure
12:05:58 <LadyHawk> but they're already slow there so that doesn't matter much to me
12:07:24 <b_jonas> how long are your trains?
12:07:44 <LadyHawk> 3 bits of grid, loco + 5 cars
12:07:59 <LadyHawk> sorta stuck with me since yeh olden ttdx days
12:08:00 <b_jonas> oh, so that's why those corners don't slow them down
12:08:35 <LadyHawk> i haven't noticed any slowdowns with any lenght on those turns.. 1 normal, 3 diag, 1 normal for a turn's always seemed fine
12:08:39 <LadyHawk> but maybe i missed it i dunno
12:08:47 <b_jonas> um... are your trains maybe already slow?
12:09:05 <b_jonas> wait, are you even playing realistic acceleration?
12:09:21 <LadyHawk> if i didn't, the bridges to cross would block everything off lol
12:09:34 <LadyHawk> the 7 lenght stations are to account for their early slowdown into stations
12:10:38 <b_jonas> I guess your trains are just shorter than your corners
12:11:14 <LadyHawk> those not work for all lenghts?
12:11:35 <b_jonas> not according to the wiki I think
12:11:52 <LadyHawk> i guess in that case i'm learning something new
12:12:17 <LadyHawk> i figured because the turn itself isn't quite 90 degrees it would be fine
12:14:52 <LadyHawk> trying to work out that long train's max speed now on that picture, 4x 45 turns
12:15:51 <b_jonas> you could just look at the status window of the train in game, for it shows the current speed
12:16:30 *** DayDreamer has joined #openttd
12:18:10 <LadyHawk> the tiles counting the diagonal tracks.. and this counts for as long as the train doesn't fit in between the bends because that counts as being only 1x45 for that train
12:18:29 <LadyHawk> 6 long trains would need
12:18:48 <LadyHawk> i'll just have to build one and see
12:19:00 *** Devroush has joined #openttd
12:19:15 <b_jonas> though of course your network might get efficient if you had fewer but longer trains
12:20:06 <LadyHawk> but then i wouldn't have to try and make my tracks so efficient
12:20:25 <LadyHawk> less traffic, less challenge lol
12:22:29 <LadyHawk> weee got it, 6 long trains, 5 diagonals.. guess my setup isn't as effective as i thought XD
12:24:56 <LadyHawk> i love the complexity of such a simple game, best of its kind
12:41:06 *** norbert79 has joined #openttd
12:41:09 *** norbert79 has left #openttd
12:49:55 *** SystemParadox has joined #openttd
13:04:03 *** fonsinchen has joined #openttd
13:58:25 *** SpComb^ has joined #openttd
14:06:22 *** richardu1 has joined #openttd
14:53:42 <Belugas> we have, in our app, a messaging system
14:53:52 <Belugas> drop a message on database,
14:53:59 <Belugas> wait for polling to pick it
14:54:13 <Belugas> and the HO database will advise mail recipient
14:54:26 <Belugas> there is this new customer who says that the process is too slow
14:54:32 <Belugas> so he wanted instant messaging
14:54:39 <Belugas> i told him it already exists
15:02:44 <Mortomes|Work> issue status: Rejected Reason: e-mail
15:02:53 <Rubidium> no form of communication is instant
15:03:17 <dih> for certain definitions of instant ^^
15:03:44 <SmatZ> email is sometimes instant enough :)
15:03:49 <dih> define 'instant' somewhat broader, and then Belugas messaging thing is 'instant' too
15:03:55 <planetmaker> I guess I could aquire 50000 frames with the camera next door in that time between you press enter and I read it ;-)
15:04:14 <dih> planetmaker, that's just because you read too slowly :-P
15:04:21 <SmatZ> how many fps does it record?
15:04:29 <dih> there - you see - it's taking pictures :-P
15:04:47 <dih> 50000 clicks will take a while
15:04:48 <planetmaker> Depends on the image size I select. Something from 1000 ... 62000
15:05:27 <planetmaker> 1kfps @ 1Mpixel. And then scale down ;-)
15:06:20 <planetmaker> hehe. yeah. It records max. 4 seconds
15:06:26 <SmatZ> a terabyte in few seconds :)
15:06:36 <planetmaker> then the 4GByte internal memory are full and you first have to readout
15:06:54 <planetmaker> or you have to go for much slower speed which GBit ethernet can support
15:07:16 <SmatZ> true, not "few seconds"
15:07:52 <dih> planetmaker, why does it not have a 10Gb ethernet connection? :-P
15:08:07 <planetmaker> because I know of no manufacturer who offers such cam.
15:08:41 <planetmaker> especially if it has to be crash-hardened as well :-P
15:09:19 <SmatZ> it is that camera you let fall down from the tower?
15:09:29 <planetmaker> one of those, yes
15:09:52 <dih> the cam is soo fast, the 2nd frame captures light before the 1st frame gets it :-P
15:10:22 <planetmaker> that's called interlaced, dih ;-)
15:10:28 <dih> if you move just as fast, you could capture yourself taking a picture
15:10:29 <planetmaker> Luckily it's not that "fast" :-P
15:11:12 <Belugas> if onlyit was true for me :(
15:15:56 *** fonsinchen has joined #openttd
15:19:02 *** Doorslammer has joined #openttd
15:20:08 <CIA-10> OpenTTD: rubidium * r21442 /trunk/src/subsidy.cpp: -Fix [FS#4293] (r21412): don't use the current company for awarding subsidies; it's not quite valid there
15:27:20 *** Spoons is now known as FauxFaux
15:49:48 *** Doorslammer has joined #openttd
16:06:56 *** SystemParadox has joined #openttd
16:11:12 <dih> Rubidium, what do you think of a method to inject settings into clients for the current multiplayer game?
16:11:34 <dih> only for relevant settings of course
16:11:55 <Yexo> inject settings into clients/ what is that supposed to mean?
16:12:41 <ccfreak2k> Probably means change gameplay settings for that session.
16:12:48 <dih> server being able to set a client setting
16:12:56 <Yexo> the normal game settings can already be changed via rcon and if it is about the client-side only settings, why should the server change those?
16:12:59 <Yexo> they're client-side for a reason
16:15:10 <dih> something like drag_signals_density
16:16:14 <Rubidium> those are client settings for a reason
16:16:39 <dih> assume you are in a game with 200 clients (i am using the word 'assume' for a reason :-P)
16:16:43 <Rubidium> and pushing server settings to the client will override the clients settings for new and other games as well
16:16:46 <dih> every body using public chat
16:17:03 <dih> hence they should only be active for the current session
16:17:22 <Rubidium> way too much work for too little benefit
16:17:24 <dih> you could then enforce 'team chat' to be the default
16:17:24 <Eddi|zuHause> dih: i think you got the answer ;)
16:18:12 <Rubidium> as we'd need to keep track of the settings the server forced down to the client and make sure only those settings are reset to what the client had before, whereas all the other client settings that the client updated while playing the game are synced with the global settings
16:18:28 <Rubidium> not to mention that it then becomes a guess game which settings are per-game and which are global
16:18:39 <dih> one could use a server setting variable
16:18:48 <dih> which would override the client side setting
16:18:53 <Ammler> you could rather make some settings company dependend
16:19:03 <Rubidium> Ammler: that already exists...
16:19:21 <Rubidium> dih: but what if the client wants to override the server setting?
16:19:40 <Rubidium> how do you keep track of the variables that came from the server and which didn't?
16:20:10 <dih> the ones from the server are in the respective 'server settings' var
16:20:20 <Rubidium> there has been enough problems with "newgame" settings already, so adding two new "states" of client settings
16:20:43 <Rubidium> dih: but that 'server settings' var contains *all* "client" settings
16:20:58 <dih> however, the server settings can be dumped, as they should only be relevant for the current game
16:20:59 <Rubidium> as you would be allowed to set any setting
16:21:20 <dih> the server settings could merely contain those settings the server is allowed to influence
16:21:29 <planetmaker> he. Forcing client-side settings from the server to the client seems conceptionally as wrong as it can get.
16:21:50 <Rubidium> dih: please describe to me how to get the drag signal setting in your vision
16:21:54 <planetmaker> Those then stop being client-side settings at that very point
16:21:58 <Rubidium> for the follow cases
16:22:03 <Rubidium> 1) server doesn't set it
16:22:06 <Rubidium> 2) server does set it
16:22:12 <Rubidium> 3) server does set it but client overrides it
16:22:29 <Rubidium> 4) server doesn't set it but client changes
16:22:41 <dih> 2) and 3) server defines a minimum possible value
16:23:04 <Eddi|zuHause> 9-state-logic :)
16:23:05 <Rubidium> if 1 doesn't happen, then you *always* override *all* client settings
16:23:35 <planetmaker> yeah. Forcing all players to play the game in arabic language. Hilarity ensues
16:23:44 <ccfreak2k> Signal spacing when drag constructing them?
16:23:54 <dih> you are not supposed to override *all* but be able to define a certain selection of client settings
16:24:06 <planetmaker> Then they're not client settings
16:24:22 <dih> what if you only want to define a minimum
16:24:49 <planetmaker> Minimum language id <3
16:24:50 <Rubidium> dih: no, I want to know *how* you want to implement it
16:25:16 <Rubidium> planetmaker: no, language 5B :)
16:25:21 <dih> first of all, only a few settings should be overrideable
16:25:47 <Eddi|zuHause> dih: you are thinking this from the wrong direction, i think
16:25:51 <Rubidium> as how you explain it the server's configuration can define a subsection of settings that it will override at the client
16:26:04 <Eddi|zuHause> what you actually need is a server side setting: minimum signal distance
16:26:19 <Eddi|zuHause> and the client checks this minimum with the client setting
16:26:22 <dih> the server can code wise only override a few settings
16:26:29 <dih> langauge definately not being one of them
16:26:36 <Eddi|zuHause> only hacked clients can then override this minimum
16:26:53 <Rubidium> Eddi|zuHause: and anybody building signal by signal
16:26:57 <planetmaker> or people just build signals manually.
16:27:17 *** ChanServ sets mode: +v tokai
16:27:53 <Eddi|zuHause> dih: anyway, this way, no new way of enforcing settings needs to be introduced
16:28:36 <Eddi|zuHause> only the new server side setting, and a validation routine for the client side setting
16:29:18 <Eddi|zuHause> i don't really understand what you wanted to achieve with the team chat setting...
16:29:20 <Rubidium> Eddi|zuHause: and where does that validation happen?
16:29:38 <Rubidium> does that happen on the client's global client side settings?
16:30:22 <Eddi|zuHause> Rubidium: i don't know these details about the settings system
16:30:24 <Rubidium> the only thing I see this doing is arbitrarily changing (global) user side settings based on the server you're joining
16:31:05 <Rubidium> *if* I join a server to spectate I don't want my settings to become mutilated
16:31:26 <Rubidium> *if* I join a server and start a new company I don't want my settings to become mutilated
16:31:50 <dih> on the client side, one could (mis)use the newgame settings ^^
16:32:06 <Rubidium> as that doesn't store the client side settings
16:32:19 <Rubidium> client side settings are stored *completely* separated from the game settings
16:32:34 <Rubidium> also changing newgame settings means mutilating the global settings
16:33:11 <dih> actaully looking at the settings, i cannot find enough settings which would be worthwhile wanting to change from the server side ^^
16:33:15 <Eddi|zuHause> Rubidium: there are several ways to approach this, but each has its own downsides
16:33:50 <Eddi|zuHause> Rubidium: e.g. you could enforce the minimum only on command execution, that way, the setting itself is unaffected, but visual representation in the signal gui might be off
16:34:29 <Rubidium> and all of them will be a maintenance issue
16:34:37 <Eddi|zuHause> or you could also change the visual representation, but then that one is not in sync with the setting anymore, which can cause other confusion
16:35:07 <Rubidium> there's already enough problems with "game" and "newgame" settings, so please don't add another load of nuances to the system
16:35:10 <Eddi|zuHause> or you enforce the actual setting walue, which has the side effects you mentioned earlier
16:35:39 <Eddi|zuHause> i'm not defending the idea
16:35:40 <dih> Rubidium, what are the issues with 'newgame' settings?
16:35:50 <Eddi|zuHause> i'm just stating options
16:36:02 <Rubidium> dih: e.g. I set the pathfinder penalties in the config file and it doesn't work with my savegame
16:36:41 <Rubidium> dih: e.g. I set the pathfinder in the game, but when starting a new game it is using another pathfinder
16:37:44 <dih> i can understand the first one
16:38:17 <dih> the second one i do not follow, if you change pathfinder stuff in the newgame settings and issue a newgame command, the new settings are not used?
16:38:44 <Rubidium> you change them in the *game* settings, not the *newgame* settings
16:39:45 <planetmaker> you should play more, dih ;-)
16:40:02 <dih> it may not always be expected
16:40:08 <Rubidium> dih: no, it's the right behaviour but it confuses many "noobs"
16:40:31 <planetmaker> yep. Otherwise my settings would change upon every load of a savegame
16:40:49 <dih> ok, but that is not a problem with the game / newgame settings, that is a problem with assumptions some people make
16:41:07 <Rubidium> adding *extra* layers of that, one that only applies to "random" settings when joining a server but only some servers, isn't something I'd aim for
16:41:44 <dih> yep - can understand that :-)
16:42:37 <Rubidium> the game/newgame stuff is predictable, what you propose adds a whole slurry of parameters and dependencies making it a nightmare to understand
16:43:44 <Rubidium> besides that you haven't come up with a sane and simple method that works for the 4 cases I described before
16:44:01 <Rubidium> and I can't think of a sane (or simple) method
16:44:08 <dih> though i would like to add the word 'yet' :-P
16:44:58 <Rubidium> "and yet I can't think of a sane (or simple) method"
16:45:48 *** supermop has joined #openttd
16:46:21 <dih> "you haven't come up with a sane and simple method _yet_"
16:47:18 <dih> anyhow, there are still a few things that could be done for the admin network anyway :-)
16:50:32 <planetmaker> yep, command logging could be done :-P
16:50:45 <Belugas> that may by why there are more servers than players... looks like all the fun is nw to be an admin
16:50:48 <planetmaker> or actually, a working bot might be more important
16:51:18 <planetmaker> Belugas, would be nice, if those servers were really administered. And not just setup and left to decay
16:51:41 <Belugas> although i never thoguh the situation was that bad :)
16:52:16 <Rubidium> planetmaker: you mean all those 1.0.4/1.0.3 servers :)
16:52:39 <Rubidium> or that nightly server that's almost 100 revisions behind
16:52:50 <dih> planetmaker, i have the feeling that command logging should be done differently :-P
16:52:52 <planetmaker> I'll take out the latter :-P
16:53:09 <planetmaker> Or I'd have to check our servers revisions ;-)
16:53:20 <dih> consider each command triggering a lookup if one of the connected bots registered for command logs
16:54:10 <dih> that would be a lot of wasted loops
16:54:27 <Rubidium> how many will generally be connected?
16:54:37 <planetmaker> Rubidium, I've the feeling that statement concerning 'setup and left for decay' could just as well apply to a number of 1.0.5 servers. The older revisions have an unproportionally higher chance to fall within that category, though ;-9
16:54:40 <Rubidium> about 0.5 bots will probably be above average
16:54:57 <planetmaker> We'd probably run 2 or 3 bots on our servers
16:55:12 <planetmaker> logging. rcon bridge. other stuff
16:55:13 <Rubidium> and the looping is in not much more complex than e.g. the current loop
16:55:33 <Rubidium> which checks whether the client's state is high enough to get the command
16:55:57 <Rubidium> for every command (not DoCommand, but DoCommandP)
16:56:03 <dih> but the chance is higher that most clients get the command
16:56:20 <dih> where as connected bots most likely will not have that package registered for update
16:56:22 <Rubidium> still, it's insignificant
16:56:33 <Rubidium> the chat stuff is probably more expensive
16:56:53 <dih> chat happens less than DoCommandP
16:57:26 <planetmaker> Probably Rubidium still knows from the recent logs ;-)
16:57:27 <dih> the one loop is not significant, but accumulated?
16:57:52 <dih> SmatZ should profile that once :-D
16:58:24 <Rubidium> dih: the actual receiving and validating of a command is more expensive than checking 3 bots whether they want it and sending it to one
17:00:20 *** KenjiE20 has joined #openttd
17:00:57 <dih> you mind if i add a server side setting? admin_cmd_logging
17:01:30 <dih> because i doubt many servers with bots will make use of that ^^
17:03:20 <planetmaker> IMHO it'd be another service a bot registers for.
17:04:11 <dih> planetmaker, assume 10 bots connected, none of them wanting to do command logging
17:04:35 <dih> each DoCommandP will trigger looping over 10 bots finding that none of them want the command info
17:04:51 <dih> if you ask me, that's a waste
17:05:01 <planetmaker> <Rubidium> dih: the actual receiving and validating of a command is more expensive than checking 3 bots whether they want it and sending it to one
17:05:13 <planetmaker> so you save exactly 9 ifs
17:05:28 <planetmaker> on the expense of an additional setting
17:05:51 <Rubidium> "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%."
17:06:02 <Rubidium> I think this falls *definitely* in the 97% category
17:06:18 <planetmaker> I don't really have a strong opinion either way, but... ^
17:06:46 <planetmaker> thanks, Rubidium, much better phrased than I could have put it :-)
17:07:01 <Rubidium> *imagine* a server, with 255 connected clients all pushing commands at the current limits
17:07:23 <planetmaker> all chatting via client-side bots :-P
17:07:29 <Rubidium> you'll have 510 commands incoming, which would be sent to the bots
17:07:43 <planetmaker> hacked clients ;-)
17:08:32 <Rubidium> now, lets assume the map is 256x256 tiles big
17:09:00 <dih> what if i introduce a uint16 array, one per update type, bitmasked to the bot index wanting the respective update
17:09:00 <Rubidium> the tile loop *alone* is going to be more expensive than checking those few bots whether stuff needs to be sent
17:09:33 <Rubidium> won't be much more efficient
17:09:44 <dih> for _all_ update type together?
17:10:06 <Rubidium> as you'd need to loop over all 16 bits each time, especially if the one bot (#15) is connected
17:10:27 <dih> ah - i though i could loop of the 1 bits only
17:10:44 <Rubidium> while doing so you need to update two counters; one for the bot index and one for the bitmask
17:10:45 <dih> and only loop if the mask is > 0
17:11:11 <Rubidium> dih: yes, you can loop the set bits only, but you still need to figure out which bit that is
17:11:29 *** fonsinchen has joined #openttd
17:11:29 <Rubidium> and with 16 bits that's becoming a mighty big lookup table
17:12:22 <dih> how can i remove 100 lines from the logs? :-P
17:13:29 <Rubidium> 1,100d (or something like that)
17:13:52 <planetmaker> dih, vi file 100dd
17:16:50 *** andythenorth has joined #openttd
17:20:22 *** ChanServ sets mode: +v tokai
17:22:51 <Rubidium> so many German translators and still it's like a week out-of-date
17:23:49 <planetmaker> they're all slackers and probably need a spanking
17:26:37 <Terkhen> new icu version, which still cannot be compiled in mingw :(
17:27:00 <Rubidium> oh, no worries... it can't be compiled with MSVC < 2010 either
17:28:02 <planetmaker> not? You're also a translator ;-)
17:28:23 <planetmaker> thanks for the prod, Rubidium
17:29:27 <Terkhen> if they are even scrapping supported platforms, I should probably stop waiting for a mingw fix :/
17:31:32 <Terkhen> the error is actually quite stupid; it has an undefined reference to `WinMain@16' while compiling the data library
17:40:05 *** Prof_Frink has joined #openttd
17:45:48 <Terkhen> it might be... but I noticed that the error was only present in the dlls so I just disabled building them
17:45:56 <Terkhen> let's see how far it gets now
17:48:02 *** frosch123 has joined #openttd
17:50:13 <Terkhen> hi Wolf01 and frosch123
17:51:06 <frosch123> evening everyone :)
18:01:07 *** Alberth has joined #openttd
18:01:07 *** ChanServ sets mode: +o Alberth
18:05:36 *** |Jeroen| has joined #openttd
18:07:56 *** theholyduck has joined #openttd
18:09:26 *** Brianetta has joined #openttd
18:12:07 *** PulseNeon has joined #openttd
18:12:23 *** Wolf01 is now known as Guest492
18:12:23 *** Wolf03 is now known as Wolf01
18:13:54 <dih> there are more of him... :o
18:20:49 <Wolf01> wow, I'm dlding at the wonderful sped of 10.6KB/s
18:46:16 <CIA-10> OpenTTD: translators * r21443 /trunk/src/lang/ (5 files):
18:46:16 <CIA-10> OpenTTD: -Update from WebTranslator v3.0:
18:46:16 <CIA-10> OpenTTD: croatian - 6 changes by VoyagerOne
18:46:16 <CIA-10> OpenTTD: english_US - 8 changes by Rubidium
18:46:16 <CIA-10> OpenTTD: german - 9 changes by planetmaker
18:46:17 <CIA-10> OpenTTD: hungarian - 1 changes by IPG
18:46:17 <CIA-10> OpenTTD: serbian - 6 changes by etran
18:48:30 <andythenorth> Wolf01: he estimates €1,600 I think
18:48:33 <andythenorth> it's in the thread
18:48:55 <PulseNeon> costly for a set of plastic bricks :/
18:49:02 <PulseNeon> no wonder Lego is so profitable.
19:00:41 <Eddi|zuHause> PulseNeon: i don
19:00:55 <Eddi|zuHause> 't think building such a model of other materials would get much cheaper
19:04:04 <Eddi|zuHause> "my idea is to build abu simpel and hide a moonbase incl. spaceships in it." <- crazy :p
19:05:01 <andythenorth> those crazy lego geeks :)
19:05:01 *** supermop has joined #openttd
19:05:10 <andythenorth> I don't really understand them a lot of the time
19:05:29 <supermop> what are we talking about
19:09:15 <Eddi|zuHause> we certainly do.
19:09:49 <Eddi|zuHause> and once upon a time we actually listened to this kind of people...
19:11:52 <andythenorth> it's a funny thread
19:12:03 <andythenorth> so many of them miss that they are being satirised
19:12:11 <Wolf01> give a look @ brickshelf.com
19:14:49 *** DayDreamer has joined #openttd
19:15:33 <andythenorth> the weird thing about lego fans - they have many of the 'towards autistic' traits of developers.
19:15:49 <andythenorth> but none of the 'bash things together, get stuff done, make progress' attitude
19:15:58 <andythenorth> they always believe stuff is getting worse not better
19:16:05 <andythenorth> developers seem to think stuff gets better
19:16:17 *** Progman has joined #openttd
19:16:22 <supermop> ive fallen victim to that
19:16:38 *** DayDreamer1 has joined #openttd
19:16:44 <supermop> but am generally been disapointed with all of the movie tie-ins
19:17:01 <supermop> still love to buy and play with lego in general though
19:25:28 *** JVassie_ has joined #openttd
19:25:34 *** ezrakilty has joined #openttd
19:31:28 <supermop> what prompted all this?
19:31:57 <Chrill> did I arrive at a bad time?
19:34:33 <Chrill> "what prompted all this?" sounds like something my mother would say when I had done something bad :(
19:38:20 <Belugas> that's AWESOME andythenorth !
19:38:30 <Belugas> i just can't imagine the PRICE of that model...
19:38:38 <andythenorth> you don't have to :)
19:38:42 <andythenorth> he put it in the thread
19:38:49 *** fonsinchen has joined #openttd
19:38:51 <andythenorth> not as awesome as a new terrain generator would be :P
19:39:27 <Alberth> the ship cost 10 months, so you may have to wait a bit longer for something more awesome :)
19:39:49 <andythenorth> supermop: in tgp.cpp
19:39:57 <andythenorth> 'someone' posted some teasing screenshots
19:40:02 <andythenorth> then went down a mine :D
19:40:13 <supermop> no idea what that is
19:40:43 <andythenorth> it's what generates maps when you choose terragenesis in new game settings
19:42:23 <Alberth> nah, tgp.cpp refers to a c++ source code file of openttd. In it is the algorithm described that the computer uses for generating maps :p
19:42:26 <supermop> my brother and i were talking about ways to make hydrologically correct maps the other day
19:42:59 <supermop> he is a hydrological engineer, so he is always using software to model that stuff
19:43:19 <supermop> no easy way to use it to create ottd maps that we can tell though
19:43:20 <Alberth> nice, we still need rivers :)
19:47:57 <Belugas> ho... i don't have time to read it all... i'll keep it fr reference :(
19:50:11 <supermop> i mostly am bothered by lakes and valleys which do not flow anywhere
19:51:06 <supermop> partially because the could not have realistically been formed by glaciers or rivers, but mostly because you cannot then run lines up along valleys
19:51:42 *** Phoenix_the_II has quit IRC
19:56:27 *** Phoenix_the_II has joined #openttd
19:57:23 *** Dreamxtreme has joined #openttd
19:57:27 <andythenorth> wonder how out of my depth I'd get trying to hack rivers
19:57:32 <andythenorth> (no pun intended)
19:57:53 <andythenorth> I need to first find a coast tile
19:58:46 <Alberth> a simple tile-loop :p
20:00:35 <Alberth> more to the point, where should the river go to from the coast? I don't see that
20:01:24 <Alberth> the other way around (find a good startingpoint at land, and then go to the coast) may be easier
20:12:11 <Rubidium> revive TrueBrain's mapgen. That resulted in pretty realistic (height)maps
20:12:53 <andythenorth> Alberth: all rivers have to end at coast
20:13:00 <andythenorth> so starting there guarantees a path
20:13:22 <Rubidium> andythenorth: that's so not real :)
20:13:33 <andythenorth> like, whatever :D
20:13:53 <andythenorth> otherwise here's what's needed: 1. patch to allow half-tile slopes for rivers
20:14:11 <andythenorth> 2. patch to allow rivers to flood depressions, creating lakes
20:14:18 <andythenorth> but preventing griefing in-game
20:14:30 <andythenorth> 3. patch to decide how full a lake should get so they can find an exit
20:14:56 <andythenorth> or alternatively, a path-finder that doesn't build a river if no path to coast is found
20:15:04 <andythenorth> which could be....slow?
20:17:25 <Terkhen> about 2., I would only activate that behaviour during map generation / scenario editor
20:19:24 <andythenorth> what if the landscape is terraformed?
20:19:35 <andythenorth> disallow terraforming under lakes?
20:20:25 <Eddi|zuHause> terraforming destroys the lake
20:21:50 <Eddi|zuHause> just clearing the affected tiles
20:22:08 <Eddi|zuHause> creating new shore line if parts of the lake remain
20:22:17 <Eddi|zuHause> like, exactly what currently happens
20:23:56 <andythenorth> but you could terraform out the walls of the lake...
20:25:11 <Eddi|zuHause> don't change the ingame behaviour of lakes/rivers.
20:25:20 <Eddi|zuHause> it is fine like it is.
20:29:33 <andythenorth> currently terraforming just removes rivers?
20:33:43 <Terkhen> you can raise the cost to high levels with a grf
20:34:04 <andythenorth> rivers have so many edge cases
20:34:37 <supermop> hey sorry was eating lunch
20:34:39 <andythenorth> if I can terraform a single point and block a river....serious griefing opportunity
20:34:49 <andythenorth> wonder how much rivers should be immovables?
20:35:20 <andythenorth> having an AI build and 'own' rivers is out of the question?
20:35:25 <andythenorth> 'navigation authority'
20:35:37 <Eddi|zuHause> andythenorth: you have canals for that.
20:35:47 <supermop> here are my few cents
20:36:22 <Eddi|zuHause> andythenorth: but possibly have an option that non-canal-water generally is unremovable
20:36:23 <supermop> i think it would be great if it were impossible to prevent blocking of rivers
20:37:09 <Eddi|zuHause> andythenorth: but that also means you cannot terraform (down) halftile-shores
20:38:07 <b_jonas> allowing to remove a tile of the river (and assuming it just flows in an underground canal there or something) is better than the alternative which is adding a way to destroy your opponent's tracks by flooding it with a river
20:38:22 <b_jonas> who cares if it's unrealistic?
20:38:42 <supermop> the path of the the flow must always be 1 tile wide
20:39:01 <supermop> that would be ideal, but probably not worth implementing
20:39:36 <supermop> i think having a river pathfinder should only be active during map generation
20:39:49 <b_jonas> right, that's what I'm saying too
20:40:25 <supermop> these are processes that take millions of years, so it's ok for a riverbed to be static even for a 1000 year game
20:40:51 <supermop> if you are using a river as a route for your ships
20:41:14 <b_jonas> if there are lakes too, those can appear or disappear within 1000 years
20:41:22 <supermop> the ability to cut it off by buldozing is a serious grief opprotunity
20:41:45 <supermop> as start up cost for using a river are much lower than for a canal
20:42:20 <b_jonas> maybe if you can only bulldoze a river tile if it wasn't used by opponent's ships for a few years?
20:42:58 <supermop> yeah, but that requires every water tile to keep track of last time it was traverse
20:43:26 *** JVassie has joined #openttd
20:43:28 <b_jonas> only an approximate time
20:43:42 <b_jonas> accurate to only a year, and the timeout is say four years
20:43:50 <b_jonas> so you need only three bits per player
20:43:53 <b_jonas> hmm, even that's too much
20:44:57 <supermop> i think a persistent entity and pathfinder for each river is better than trying to store more data in each water tile
20:45:19 <supermop> lets assume rivers stay griefable for now
20:45:52 <supermop> that they are created at map gen, then behave just like they do now thereafter
20:47:05 <supermop> here is my totally uninformed idea as to how to create them
20:47:07 <andythenorth> how rivers get on the map is decoupled from whether they are griefing opportunities at the moment
20:47:16 <b_jonas> also that map-time pathfinder isn't such an easy thing I guess
20:47:20 <andythenorth> they are griefing opportunities as implemented
20:47:40 <supermop> i will use a bitmap as an analogy
20:47:52 <andythenorth> Alberth: not to the same extent
20:48:00 <andythenorth> I can't raise one corner of a tile to destroy a road
20:48:03 <supermop> game starts with a medium grey square,
20:48:17 <andythenorth> I have to bulldoze a town road, only at a free end, not past junctions, and only if my rating is good
20:49:03 <supermop> randomly add a few hills (areas of lighter color)according to settings
20:49:31 <b_jonas> andythenorth: then rebuild it one-way for fun
20:51:42 <supermop> then randomly add a number of seeds for river
20:51:50 <supermop> number determined by setting
20:52:45 <supermop> start tracing paths toward map edge avoiding hills
20:52:55 <supermop> anding some amount of noise
20:53:45 <andythenorth> which map edge? :P
20:53:49 <supermop> apply a gradient along the path to lower terrain at some rate
20:54:09 <supermop> specify number of coast edges as now
20:54:18 <b_jonas> wouldn't it be better to generate a heightmap with high height resolution first, generating the rivers (according to flow of water and percipitation) on it, then quantizing the heights?
20:54:24 <supermop> after addition of hills
20:54:37 <b_jonas> on ttd maps you don't know where the river flows on a flat place
20:54:52 <supermop> run a sharp gradient to black on those edges
20:54:54 <b_jonas> in a high precision height map you do know because there are no equal heights
20:55:11 <supermop> but how do you get to that map first
20:55:24 <b_jonas> that's what you generate first
20:55:41 <supermop> currently maps are random
20:56:05 <supermop> i am thinking of approximating erosion by rivers to create the map
20:56:18 <supermop> so that valleys do not have dead ends
20:58:34 <CIA-10> OpenTTD: yexo * r21444 /trunk/src/ (strings.cpp strings_func.h): -Codechange: compute the type of elements in the argv string array on the fly and compare it with the type set by strgen
20:59:54 *** fonsinchen has joined #openttd
21:00:04 <supermop> they idea would be to randomly place rivers
21:00:17 <supermop> then interate them several times
21:00:40 <supermop> so that they effect the whole landscape
21:00:51 <supermop> then load that bitmap into the game
21:02:03 <CIA-10> OpenTTD: yexo * r21445 /trunk/src/ (strgen/strgen.cpp strings.cpp):
21:02:03 <CIA-10> OpenTTD: -Fix: [NewGRF] fix gender choice lists in newgrf strings.
21:02:03 <CIA-10> OpenTTD: Change: strgen no longer writes the type of a string for a gender choice list
21:07:51 <supermop> i'd rather hane maps with valleys than rivers that flood etc
21:08:28 <PulseNeon> I think naturally occuring rivers would be nice, a good use for ships inland as well
21:10:04 <b_jonas> what if instead the user is allowed to build some rivers for cheap?
21:10:31 <Eddi|zuHause> how do you define "some"?
21:10:51 <Eddi|zuHause> if the player really wanted that, he'd use the scenario editor
21:11:00 <Chrill> b_jonas: an artificially constructed river would be rather expensive
21:11:13 <Chrill> then again, just diggin a trench and let the water get there wouldn't..
21:11:14 <b_jonas> Eddi|zuHause: well, they have to look like rivers, like flowing down, and can't fork upwards, etc
21:11:16 <Chrill> not sure it'd hold a boat
21:11:35 <Eddi|zuHause> b_jonas: that doesn't make any sense
21:11:41 <b_jonas> Eddi|zuHause: and maybe there'd be rules that they can't be too close to each other or somthing
21:11:56 <Chrill> b_jonas: but if you want to merge two rivers, then?
21:11:59 <b_jonas> or maybe he can only specify the starting point of the rivers
21:12:12 <b_jonas> Chrill: you can merge downwards, but not upwards
21:13:32 <Eddi|zuHause> you're talking silly stuff
21:16:22 *** realbigdreamer has joined #openttd
21:18:04 <realbigdreamer> Hey guys, I have a problem. We are playing Open TTD on multiplayer and all the income I'm supposed to get does not get paid into my bank account. Anyone know how to fix it? I tried deleting the config file, but no change...
21:18:23 *** ccfreak2k has joined #openttd
21:18:31 <realbigdreamer> Running version 1.0.5 BTW
21:18:32 <Yexo> most likely you're using transfer orders incorrectly
21:18:33 <Eddi|zuHause> realbigdreamer: don't use "transfer"
21:18:49 <b_jonas> realbigdreamer: it's game money
21:18:54 *** ccfreak2k has joined #openttd
21:19:05 <realbigdreamer> Oh! Thanks let me change it!!!
21:19:05 <b_jonas> it won't ever go to your real bank accounts
21:19:23 <realbigdreamer> Lol, oh my bad b_jonas.... hahaha
21:21:56 <realbigdreamer> Thank you guys so very much! Now I will actually have a chance in the game... yay
21:26:29 <realbigdreamer> I used to play TTD when I was little, man I really appreciate Open TTD.
21:30:04 <Belugas> mmh... you grew up fast :D
21:41:20 *** realbigdreamer has quit IRC
21:41:45 <CIA-10> OpenTTD: yexo * r21446 /trunk/src/strings.cpp: -Doc: doxygen comments for some functions in strings.cpp
21:44:53 *** realbigdreamer has joined #openttd
21:45:22 <realbigdreamer> Haha, I've had 3 planes crash in the game I'm playing now... guess I'm doing something wrong.
21:45:59 <planetmaker> there are large and small planes.
21:46:10 <planetmaker> Large planes landing on a small airports have a high crash chance
21:46:25 <planetmaker> But even then. Plance can crash by default. Even if you do everything right
21:46:50 <planetmaker> otherwise they'd be your license to print money without any need of looking after it nor building infrastructure
21:47:05 <Belugas> gottogohome, enjoy the fish and thanks for the snow
21:47:21 <realbigdreamer> Oh, thanks. Yeah I have small airports and bigplanes... guess that explains it. :)
21:49:19 <realbigdreamer> I will play on a few of the online servers tomorrow, but I have a feeling I might do bad considering my knowledge of Open TTD...
21:49:36 <b_jonas> also it's not obvious what planes are small (propeller) and what are large (jet) from the name and graphics, so you may have to look it up
21:49:54 <b_jonas> (unless you just build large planes only)
21:50:51 <realbigdreamer> Okay thanks. I built something 500 planes in the current game
21:51:16 <supermop> 3/500 sounds not bad
21:53:30 <realbigdreamer> No, but I started with one and bought the other after about a month. The one crashed and I replaced it with money I borrowed. And the same thing happened again. Had a dept of about 200 pounds after that.
21:55:06 <realbigdreamer> I guess the helicopters are a good way of making money... The one I have now has a longer life than the planes I had.
21:56:27 <planetmaker> best way is running 747 across 1000 tiles between big towns when plane speed is at 1/1
21:56:38 <planetmaker> helicopters are too small ;-)
21:57:44 <realbigdreamer> I'll try that. Wow, I'm getting addicted to this game.... again!
21:58:53 *** Chillosophy has joined #openttd
21:59:09 <realbigdreamer> Quick question, can I host a server for about 4 players on my PC with a 3G connection? Dunno how intense the bandwidth usuage might be...
22:03:13 <planetmaker> download + 2-3 kbyte/s and player
22:09:14 <realbigdreamer> We might as well play on the servers that are currently online...
22:13:01 <realbigdreamer> Well it's 12:10 here, think I'm gonna call it a night. Cheers guys and thanks for the help. You seem like a nice community.
22:15:32 *** realbigdreamer has left #openttd
22:27:41 *** Devroush has joined #openttd
22:30:00 <Terkhen> finally, icu 4.6 compiles in mingw
22:30:38 <Terkhen> if you want something done you have to do it yourself, I guess
22:32:02 <supermop> thats why I started making grfs despite not knowing how to code
22:32:26 <supermop> had things i wanted to see in game...
22:32:35 <planetmaker> That's how it all started with me and OpenTTD-deving and newgrf-ing, too...
22:33:40 <supermop> thats part of why i went to architecture school
22:33:41 <planetmaker> I'd wonder whether there are many where it is actually different ;-)
22:33:59 <supermop> "be the change you want to see in the world"
22:34:49 <Terkhen> I wonder why I spend so much time fighting libicu
22:35:29 <Rubidium> because you like it?
22:35:31 <Terkhen> I guess because it's a fun puzzle
22:35:53 <Rubidium> Terkhen, next fun puzzle: cross compiling freetype/icu to DOS :)
22:36:22 <Terkhen> prerrequisite puzzle: managing to format my old 386 PC to be able to test DOS binaries there
22:36:37 <Terkhen> it ignores bootable diskettes for some reason
22:36:47 <Terkhen> and the BIOS is too scary
22:37:44 <Terkhen> for now I'll finish this and I will upload my hacky queue to libicu's tracker :)
22:38:39 <Terkhen> hmm... is DOS even able to handle UTF stuff?
22:38:41 <Rubidium> you could use dosbox; that runs the DOS OpenTTD binary
22:39:18 <Rubidium> Terkhen: probably not, but the drawing of text if fully contained within OpenTTD, so that shouldn't be a problem
22:51:21 <fonsinchen> 'm failing to compile opengfx ...
22:52:17 <fonsinchen> In valid nfo, can there be lines like this: '# 1 "<stdin>"'?
22:53:55 <Rubidium> what version of grfcodec and opengfx?
22:53:57 <polymorphZ> can someone tell me how to give same orders to 200 aeroplanes?
22:54:09 <fonsinchen> newest, just downloaded from the website
22:55:05 <Yexo> polymorphZ: make sure they have shared orders, if you haven't done that yet you'll have to change that for all 200 planes manually
22:55:06 <Rubidium> polymorphZ: use shared orders; see the wiki for more information
22:55:22 <fonsinchen> I mean newest grfcodec. opengfx is a hg checkout.
22:55:48 <PulseNeon> What does hg stand for?
22:55:50 <fonsinchen> But now as I'm trying to check the grfcodec version I find that something went wrong with its installation ...
22:56:01 <Rubidium> fonsinchen: and with "newest" you meant 5.0.0?
22:56:11 <Yexo> PulseNeon: mercurial, a version control system
22:56:38 <Rubidium> then your grfcodec isn't new enough
22:57:41 <Rubidium> you need r785 or higher of grfcodec to compile opengfx r551 or higher
23:00:27 <Rubidium> and for the next time "newest" is not a valid answer when someone asks for the version
23:01:28 <planetmaker> using 'newest' when referencing versions should be punishable
23:04:58 *** JVassie_ has joined #openttd
23:05:25 <supermop> hey guys i love the newest transport tycoon!
23:05:44 <fonsinchen> sorry, it seems I was typing faster than thinking ... time to go to sleep, I guess
23:05:58 <Prof_Frink> I prefer the newester version.
23:13:22 <polymorphZ> add shared vehicles dont add vehicles with same orders :(
23:14:40 <Xaroth> click clone vehicle, then click vehicle to clone orders from
23:14:46 <Xaroth> hold ctrl to make them share the order-list
23:15:30 <Sacro> Right, why does "#define output(...) printf(__VA_ARGS__); printf("\n");" not work?
23:15:52 <Sacro> I guess because it needs __VA_ARGS__ quoting but I can't figure that bit out
23:16:36 *** JVassie has joined #openttd
23:17:16 <polymorphZ> 3~ah thankyou i see now :)
23:17:56 <polymorphZ> so i should share orders when creating vehicles
23:17:58 <__ln__> Sacro! long time no C.
23:19:08 <__ln__> what does it do instead of working?
23:19:25 <Rubidium> Sacro: #define output(args...) printf(## args); printf("\n"); ?
23:19:28 <Sacro> __ln__: I get loads of "foo" is indufined
23:19:37 *** HerzogDeXtEr has joined #openttd
23:20:00 <__ln__> indufined, that sounds serious
23:20:24 <Sacro> I'm trying to get it so it either returns an identifier or it prints it
23:20:33 <Sacro> lexical analysis ftw :(
23:22:07 <Sacro> so basically i have output(OR);
23:22:14 <Sacro> which will go to return OR;
23:22:29 <Sacro> depending on whether DEBUG is defined
23:22:38 <__ln__> should __VA_ARGS__ be given to something like vprintf()? dunno, never tried '...' with macros.
23:23:01 <Rubidium> that won't work that way :)
23:23:09 <Sacro> Rubidium: what I'm doing?
23:23:25 <Sacro> hmm, and return "OR" will be different to return OR;
23:23:46 <Rubidium> try #define output(var) printf("%s\n", #var);
23:24:51 <Rubidium> then I've got too little context I fear
23:25:13 <Sacro> though that should work :\
23:25:16 <Sacro> looking at documentation
23:25:17 <Rubidium> though that's basically the way OpenTTD converts variable names to strings
23:26:12 <Sacro> that's what I'm doing (i think)
23:28:28 <Yexo> why are you using __VA_ARGS__ ? You still do printf(__VA_ARGS__) and not printf(#__VA_ARGS__)
23:28:54 <Yexo> though I think the latter will also not work
23:29:11 <Sacro> that's not been updated
23:29:19 <Sacro> i'm not going to commit until it works :p
23:29:22 <Yexo> in that case it's useless information
23:29:27 <Rubidium> you haven't declared those tokens, have you?
23:30:03 <Rubidium> I doubt latex does that
23:30:58 <Rubidium> #__VA_ARGS__ works fine, if compiled with -DDEBUG
23:31:55 <Rubidium> well, it doesn't give any complaints about AND and friends
23:32:08 <Rubidium> it fails to compile though, but that's probably because I'm missing a lot of stuff
23:32:42 <Sacro> how are you compiling it :\
23:33:09 <Rubidium> lex awl.lex; gcc -DDEBUG lex.yy.c
23:34:13 <Sacro> right, what what's the full #define line that works?
23:35:06 <Rubidium> works means: doesn't cause a compiler warning/error besides a load of somewhat unrelated stuff
23:35:10 <Rubidium> #define output(...) printf(#__VA_ARGS__) ; printf("\n");
23:58:34 *** asnoehu is now known as tycoondemon
continue to next day ⏵
