IRC logs for #openttd on OFTC at 2010-12-30
⏴ go to previous day
00:21:18 <Xaroth> hah, in tron legacy you actually see a unix console with commands that are .. somewhat accurate
00:21:25 <Xaroth> normally you just see bollocks on the screens
00:23:25 *** Wolf01 is now known as Guest2630
00:23:25 *** Wolf03 is now known as Wolf01
00:27:47 <Xaroth> heh, bit less accurate than tron tho
00:28:37 <Xaroth> tron was a bit more ps -somethign | grep something \n kill -9 <some pid>
00:29:01 <Xaroth> which, is exactly how you kill something :P
00:30:12 <__ln__> anyway, i was watching that one tonight
00:30:53 <Xaroth> yeh, it's not the 1982 tron :P
00:31:47 <__ln__> they had 'top' running in some window, but i think it looked too modern
00:32:16 <Xaroth> hah, login to 'backdoor' user...
00:32:20 <Xaroth> it actually makes -some- sense
00:32:36 <Xaroth> normally in movies they just type 'login' 'win' and they win
00:33:24 <__ln__> i didn't realize the girl is 'thirteen' from house m.d. until i checked the imdb.
00:55:27 <SmatZ> Eddi|zuHause: wrong window :p
00:56:50 <Eddi|zuHause> this was meant as an example of nonsensical commands ;)
01:02:16 <Mazur> B.t.w. I've seen some picture attachments being scrolled in text form as output from commands, I think it was on NCIS.
01:03:23 <Mazur> And commands like: connect hacker
01:03:35 <Mazur> with the name of the hacker where I wrote hacker.
01:05:16 <Mazur> And of course a picture of the world with lines "following" the IP packets come up on a different, large wallscreen as a result.
01:07:27 <Mazur> Enhancing pictures is also such fun, lots of details not in the original picture come up when they do that.
02:01:02 *** glevans2 has joined #openttd
02:02:11 <Xaroth> worst part is when they show an IP Address that's not even remotely posible
02:04:31 *** Biolunar_ has joined #openttd
02:07:23 *** perk111 has joined #openttd
02:13:11 *** fanioz_ has joined #openttd
02:21:46 *** fanioz_ is now known as fanioz
03:43:36 *** fanioz_ has joined #openttd
04:46:36 *** DarkTomas has joined #openttd
04:46:52 <DarkTomas> I have a question *gg*
05:07:48 *** DarkTomas has left #openttd
05:14:37 *** lasershock has joined #openttd
05:56:18 *** Eddi|zuHause has joined #openttd
06:40:51 *** Cybertinus has joined #openttd
07:38:58 *** DayDreamer has joined #openttd
07:59:05 *** DayDreamer1 has joined #openttd
08:35:48 *** zodttd2 has joined #openttd
08:39:57 *** lasershock has joined #openttd
08:56:51 <dihedral> i am totally confuddled
08:56:56 <dihedral> i have a const NetworkClientSocket *owner
08:57:07 <dihedral> and get an error when using owner->client_id
08:57:21 <dihedral> invalid use of incomplete type const struct ServerNetworkGameSocketHandler
09:00:17 *** Kurimus has joined #openttd
09:01:47 <Rubidium> dihedral: you need to include the right header
09:01:59 <Rubidium> I guess it's network_server.h
09:02:04 <dihedral> i just found that out too :-P
09:03:07 <Rubidium> also, why do you need direct access to the command array when there are appropriate accessor functions?
09:04:23 <dihedral> i am using CommandPacket when it gets appended to the clients queue on the server side
09:05:01 <dihedral> but then it did get late last night ^^
09:07:01 <dihedral> or would you rather i use a different approach
09:08:57 <Rubidium> doing it in DistributeCommandPacket seems the most sane approach
09:09:59 <dihedral> i actually am one level up from that
09:10:10 <dihedral> after the call to DistributeCommandPacket
09:11:50 <Rubidium> the src/command.cpp and second chunk from command_type are not needed; there is a perfectly good accessor function for that
09:16:46 <Rubidium> maybe it also makes sense to put the index of the first command in a CMD_NAMES packet
09:17:32 <Rubidium> also, you only need to send the lower 16 bits of cp->cmd as the high 16 bits aren't useful for logging in any case
09:18:42 <dihedral> the upper 16 bits are flags?
09:19:03 <Rubidium> no, they are the default error message StringID
09:19:21 *** |Jeroen| has joined #openttd
09:19:31 <dihedral> are the flags somewhat stable?
09:19:32 <Rubidium> also line 223 of the diff is badly aligned
09:20:18 <Rubidium> actually the flags are all masked out before sending the commandpacket
09:21:03 <Rubidium> but I rather leave the lower 16 bits in case we get more than 255 commands
09:25:08 *** Alberth has joined #openttd
09:25:08 *** ChanServ sets mode: +o Alberth
09:33:55 *** JVassie has joined #openttd
09:35:51 *** ZirconiumX has joined #openttd
09:41:11 *** Progman has joined #openttd
09:42:25 <dihedral> at least he left like 3 minutes for "Anyone" to reply
09:48:30 <Mazur> --- Anyone :No such nick/channel
09:48:30 <Mazur> --- [Anyone] End of WHOIS list.
09:53:49 <dihedral> i am not quite happy with NetworkAdminCmdLogging, i feel client_id should only be assigned if an admin is asking for command logging
09:54:48 <dihedral> Xaroth, cmd names is useful in combination with cmd logging - as the names of commands can change and i do not want that to have an affect on the admin network, making the network protocol stable by transmitting an enum over the network
09:55:20 <dihedral> poll for ADMIN_UPDATE_CMD_NAMES and you will receive 2 packets full of names :-)
09:56:01 <dihedral> Rubidium, another thought ;-) if the id is not transmitted in combination of the names, you cannot create offsets
09:56:33 <dihedral> so it would probably make sense to always transmit id, name, bool (has next)
10:02:55 <dihedral> lets the packet fill up a little sooner but not that much - makes about 1/8 difference of the amount of cmd names that fit into the first packet
10:05:04 <Rubidium> dihedral: or use command ID ffffh to flag "end of packet"
10:05:26 <Xaroth> the bool next one is used in other stuff as well
10:06:09 <dihedral> but it's 70 bytes less for the first packet :-P
10:06:22 *** tokai|mdlx has joined #openttd
10:06:24 <Xaroth> who cares about size :/
10:06:31 <Xaroth> it's often only sent once
10:06:43 <dihedral> size does not (always) matter
10:06:56 <dihedral> i like the 0xffff better
10:07:14 <dihedral> that way you know you have reached the end
10:07:42 <Xaroth> but iirc it's <bool> <id> <name>
10:07:52 <Xaroth> if not <bool> == true, abort
10:08:05 <dihedral> Xaroth, the data does not fit in one packet
10:08:10 <Rubidium> but the bool isn't needed when you have a flag in ID
10:08:11 <dihedral> currently it's split over 2 packets
10:08:27 <Rubidium> (or a sentinel value)
10:08:37 <Xaroth> Rubidium: but why create yet another way to pack an array of values :P
10:08:38 <dihedral> well - does not really matter
10:08:56 <dihedral> Xaroth, yet another way will mean, stable over admin network
10:09:18 <Xaroth> how is creating 50000 different ways to send sets of data, stable?
10:09:31 <dihedral> how many sets are sent?
10:09:56 <dihedral> i recall client and company details and updates, but they are each in their own packet
10:10:34 <dihedral> i think putting each cmd name in it's own packet a waste of space and overhead
10:10:42 <Rubidium> hmm, just leave the bool; it's consistent with the rest of the packets
10:11:07 <Rubidium> (admin packets that is)
10:11:23 <Xaroth> i would suggest: <packet header> < array of <bool next> <id> <name> > <bool of 'more follows'>
10:11:40 <Xaroth> or instead of a bool a count of how much more follows
10:11:54 <dihedral> we do not know how much more follows
10:12:38 <dihedral> i was otherwise considering a marker packet, that indicates the end of a set of data
10:12:56 <dihedral> which for Client and Company info when joining the game would also be relevant
10:13:09 <Xaroth> well you need a way to either mark the start or end of the data
10:14:07 <dihedral> a single client info packet is fine - i more refer to when you join the game and poll for all client info's
10:14:21 <dihedral> when does the bot know it's done :-P
10:15:04 <dihedral> it could make sense to send a End Of Data type packet
10:15:48 <Rubidium> dihedral: that's kinda implicit by another packet type arriving :)
10:16:14 <Rubidium> although sending "true ffffh false" instead of "false" at the end of the last packet would make some sense
10:16:48 <dihedral> that would then get rid of the end of data packet i am thinking of :-D
10:17:36 <dihedral> because - what if no other packet arrives for some time? :-P
10:17:50 <Xaroth> then the admin needs to sort out his network :P
10:18:25 <dihedral> paused game, no clients, 5 companies
10:21:41 <dihedral> so, 0xffff, or another packet type as marker
10:23:56 <dihedral> but also not adaptable to other packets
10:24:28 <dihedral> currently the end of client info and company info is not marked, and waiting for another packet can potentially take a while
10:24:51 <Rubidium> imo you don't need to send such explicit markers
10:25:54 <dihedral> also, as 0xffff false does not fit into the structure of the rest of the packet, 0xffff "" false?
10:33:42 <dihedral> then just adding another bool is easier
10:35:06 *** ZirconiumX has joined #openttd
10:35:31 <DorpsGek> dihedral: Don't ask to ask, just ask
10:36:57 <ZirconiumX> thanks for confirming my bug...
10:37:18 <dihedral> true 0xffff <- that is odd, because it defeats the meaning of true as 0xffff is not really a cmd id :-P
10:37:34 <dihedral> ZirconiumX, it's been fixed already
10:37:53 <ZirconiumX> I know, and I wanted to thank you for that
10:38:03 <dihedral> ah - you are welcome :-)
10:38:28 <dihedral> though i did not write the fix :-P
10:41:38 <dihedral> Rubidium, what benefit does true 0xffff false have over false false
10:41:43 *** LordAro has joined #openttd
10:41:44 <dihedral> you said it makes sense
10:42:01 <dihedral> writing the code for it i am coming to think it's more mind boggling
10:43:31 <dihedral> i could send a false : next id if another packet is to follow, then false 0xffff would make sense as end of transmission
10:46:26 <dihedral> but that would be as good as a 2 boolean values (more data : more packets)
10:59:37 *** Eddi|zuHause has joined #openttd
11:04:45 <Rubidium> still I wonder why you're so bothered with sending a "no more packets of this type" marker
11:04:53 <Rubidium> why would you need it?
11:05:09 <Rubidium> it's not like you'd receive other packets until you received all of the command name packets
11:05:27 *** |Jeroen| has joined #openttd
11:05:42 <Rubidium> so, just adding them to a mapping when receiving them would be perfectly fine
11:06:50 <Rubidium> I wouldn't be bothered to even consider checking whether there would be more packets of that type; I would handle them and be done with them
11:07:42 <Rubidium> and when someone queries for a command name given an id I'd just return from whatever I have... but requesting the command name without having received a command seems kinda pointless
11:09:14 <dihedral> i was just going to transmit the whole lot
11:09:36 <dihedral> you query for all names instead of just one
11:10:02 <dihedral> right, so querying for a single command name is what you would like supported?
11:10:13 <Rubidium> no, I'm talking from the perspective of an "admin" tool talking to the library which talks over the admin protocol to OpenTTD
11:10:53 <Rubidium> dihedral: no, it's how I would implement the "get command name" API in my libopenttdadmin
11:11:23 <dihedral> yes, that is what i was after
11:11:36 <dihedral> static mapping of name -> id
11:12:03 <dihedral> and i'll probably build something to implement a type of Dynamic Enum
11:12:26 <dihedral> though it never really will be of the Enum type in java .... grrr
11:45:28 *** |Jeroen| has joined #openttd
11:55:11 *** Devroush has joined #openttd
11:55:48 <dihedral> looking at a product page: Supported Filesystems: UTF-8, .EXT3, .NTFS
11:56:53 *** KenjiE20 has joined #openttd
12:00:20 *** Adambean has joined #openttd
12:06:33 <peter1138> so i added michi's tweaks as a separate graph
12:07:12 <peter1138> on a 5% incline, for the two vehicles i tested yesterday, the graphs is eerily similar to ttdpatch
12:08:26 <peter1138> first is the VT-95, heh
12:10:02 *** Cybertinus has joined #openttd
12:10:31 *** fonsinchen has joined #openttd
12:10:31 <dihedral> what is the black line in the graph
12:11:07 <peter1138> acceleration output, but the units are meaningless
12:11:19 <dihedral> i love you "Button" :-P
12:11:26 <peter1138> it was added when i was experimenting with 16 bit subspeed
12:12:01 <peter1138> incline should be 0.03 for ottd sloeps and 0.05 for ttdp
12:17:01 <peter1138> of course, if you want exact ttdpatch curves... well
12:17:15 <peter1138> the code's behind that graph, heh
12:21:16 <Eddi|zuHause> but the calculated top spead doesn't really match the observed top speed?
12:21:25 *** Cybertinus has joined #openttd
12:23:41 <Eddi|zuHause> hm... the dbset readme doesn't contain all values
12:23:51 <Eddi|zuHause> it misses the mass and the air drag
12:24:05 <peter1138> i'm getting them from ottd
12:24:18 <peter1138> printed out the airdrag value, heh
12:24:30 <peter1138> the rest is shown in the gui anyway
12:44:47 <dihedral> peter1138, could you do that same thing using values from something like the 2cc set?
12:45:06 <dihedral> i.e. the locs mentioned in the thread
12:45:45 <Eddi|zuHause> oh... is that mass of the vT95 empty or full?
13:16:54 <CIA-2> OpenTTD: alberth * r21665 /trunk/src/ (5 files): -Codechange: Make GetCallbackWnd a method of _thd.
13:18:15 *** |Jeroen| has joined #openttd
13:18:23 <CIA-2> OpenTTD: alberth * r21666 /trunk/src/ (vehicle_gui.cpp viewport.cpp): -Codechange: Use GetCallbackWnd at more places.
13:18:48 <peter1138> hmm, so 40 passengers
13:21:00 <peter1138> Eddi|zuHause, makes no difference
13:21:37 <peter1138> maxte increases to 38kN
13:21:41 <dihedral> those were fat 40 people :-P
13:22:00 <peter1138> each person weighs 1/16th of a ton
13:22:19 <ctibor> they have some luggage :-)
13:22:19 <peter1138> i guess it gets rounded down, or it's display incorrectly, heh
13:23:06 <peter1138> dihedral, it's 62.5kg
13:23:40 <dihedral> where did that study come from? :P
13:23:43 <peter1138> in fact it's quite below normal for an adult male
13:23:47 <dihedral> america would not fit into that :-P
13:24:08 <dihedral> but then people in openttd are smaller
13:24:12 <dihedral> and gravity is different
13:25:19 <peter1138> interesting that wagons have unladen and laden weight displayed
13:25:30 <peter1138> but engines that take cargo don't
13:26:16 <peter1138> and max t.e. is unladen max t.e.
13:27:06 <peter1138> how long should a BR612 be?
13:27:12 <dihedral> we should introduce a new passenger loading algorythm
13:27:33 <dihedral> passengers may have different weights (randomly determined at station when loading)
13:27:58 <dihedral> passengers to not fill waggons from the front to the back, only taking the next waggon when the previous one filled up
13:28:03 <dihedral> noooo, they sit all over the place
13:28:33 <dihedral> realistic passengers
13:28:38 <dihedral> or rather new passengers?
13:29:22 <peter1138> hmm, all the photos i see of BR612 are either two or four parts, all (look as if) they're powered
13:29:40 <dihedral> and a low chance of one out f 100 passengers being obese - needing two seats, weighing more, and paying for one
13:30:04 <planetmaker> dihedral: you can already do that via newgrf
13:30:11 <planetmaker> so no need for new work there
13:30:30 <planetmaker> might be a bit hackish, but feasable
13:31:01 <dihedral> you make me a fatpass newgrf? :-P
13:31:42 <planetmaker> well. If I do that, you can only buy those wagons with that feature in Februaries where it has 29 days, but feasable ;-)
13:31:46 <dihedral> or if you like leave the p away
13:31:49 <peter1138> you could only make 62.5 kg and 125 kg passengers :p
13:31:53 <planetmaker> you have to provide graphics though :-P
13:32:17 <dihedral> peter1138, no tripple weights? :-P
13:32:18 <planetmaker> peter1138: nah, I'd use CB38 and change capacity and wagon weight ;-)
13:32:29 <planetmaker> (that's why I call it hackish)
13:32:41 <peter1138> dihedral... 30st people? :S
13:37:33 <planetmaker> who uses those kind of funky units?
13:38:33 <planetmaker> strange folks ;-)
13:38:44 *** tim is now known as Timmaexx
13:39:18 <peter1138> not really, it's a convenient unit that doesn't result in big "hard to understand" numbers ;P
13:40:19 *** ZirconiumX has joined #openttd
13:41:31 <DorpsGek> dihedral: Don't ask to ask, just ask
13:42:02 <ZirconiumX> hello dihedral, what you doing this time
13:47:01 <Alberth> dihedral: it is just ZirconiumX his way of saying hello, it seems
13:47:27 <ZirconiumX> how else do you say hello?!?
13:47:37 <Alberth> without question mark
13:48:09 * ZirconiumX attempted to break ice, but failed...
13:48:36 <Alberth> temperatures are above 0 celcius here :)
13:49:04 <Alberth> here == in the channel
13:50:10 <dihedral> is there at all a termperature in the channel?
13:50:20 <dihedral> and don't start with cpu temp :-P
13:50:40 * ZirconiumX gives server a blanket
13:50:46 <dihedral> ZirconiumX, the questionmark threw me off i just thought you wanted to have some questions answered :-)
13:51:44 <planetmaker> dihedral: that's usual ;-) He always enters the channel and asks cautiously for a 'hello' ;-)
13:51:47 * dihedral will go out do some shopping and phoning and then sit in starbucks and enjoy a coffee :-P
13:52:30 <planetmaker> and I'm slow it seems :-P
13:52:49 <peter1138> starbucks sell coffee?
13:52:59 <ZirconiumX> which would you prefer, a friendly hello, or a barge into the conversation, that may not even be on the same track, and a kicking as a result
13:53:35 <dihedral> a friendly hello of course, just one needs to get used to friendly hellos as they don't usually exist from new people :-P
13:53:44 <dihedral> peter1138, for a certain definition of ....
13:55:11 <Rubidium> peter1138: in the dozens of times I've been to Starbucks I've never bought coffee, so I guess they don't sell coffee
13:55:18 <dihedral> Rubidium, in case you did not get the message, dell diagnostic software is not os dependent anmore :-)
13:55:38 <dihedral> i've had a coffee there... once
13:56:11 <Rubidium> dihedral: the diagnostics software is fine, just the stupid hell-desk employee who *must* be able to see stuff happen in Windows is the problem
13:56:45 <Rubidium> even though the can't really use anything from the Dell diagnostics software in Windows
13:56:52 <ZirconiumX> I had a Packard Bell computer,
13:57:06 <dihedral> hmmm - i have a vm :-D
13:57:15 <dihedral> perhaps i can break stuff in there on purpose
13:57:20 <Rubidium> nor does the hell-desk employee have any clue about how to get the GPU/CPU temperature under Windows, even though I gave them the temps as given to by Linux
13:57:30 <ZirconiumX> It was renamed the Packard Hell, after it took 3 hours to boot up...
13:57:51 <dihedral> hehe - i hope i get different support Rubidium
13:57:58 <glx> Rubidium: speedfan does that
13:58:10 <glx> though I don't know if it can read ATI sensors
14:01:48 <ZirconiumX> DELL support is now tested on more chipsets.
14:01:58 <ZirconiumX> no idea if that's correct
14:03:55 <Rubidium> glx: I don't care what does, what I'm annoyed about is that I needed to install Windows so the hell-desk morons could do their work properly, but when I installed it it seemed that the morons were really morons and didn't even know how to get the CPUs temperature
14:04:25 <glx> they just follow the script
14:05:00 <Rubidium> what really helped though is that when the overheat protection kicks in it's quite loud, so whenever the Dell moron was doing something under Windows (that took more than a few minutes), the overheat protection would kick in
14:05:23 <Rubidium> and even then they kept telling me it was probably a BIOS issue
14:06:11 <Rubidium> and not just their tech that put about a inch of cooling paste between the chips and the heat pipes
14:07:00 <Rubidium> glx: eventually it was, when he was updating the BIOS and it went into thermal protection
14:07:03 <glx> like a too slow fan rotation for given temp
14:08:06 <Rubidium> glx: it was at max speed
14:08:36 <Rubidium> glx: it is wrongly designed
14:08:45 <Rubidium> that's definitely true
14:09:14 <ZirconiumX> Put In Dust Bin *ahem*
14:09:55 <Rubidium> nah, I more or less got free-at-home-next-business-day support...
14:09:55 <glx> I still need to try to open my brother's laptop to clean it and maybe change thermal paste
14:10:21 <Rubidium> so they're starting to become a regular by now
14:10:26 <Eddi|zuHause> <peter1138> hmm, all the photos i see of BR612 are either two or four parts, all (look as if) they're powered <-- if you mean the modern BR 612, they seem to be fixed double-units which may occasionally travel in pairs.
14:11:36 <Rubidium> so they're definitely making a loss on my laptop, which is what they should make for ill designed hardware
14:13:18 <Eddi|zuHause> peter1138: each wagon has one set of driven axles and one set of undriven axles
14:14:12 <dihedral> i get next business day support for my laptop too
14:14:31 <Rubidium> dihedral: how many bytes are 16 bits?
14:14:37 <Rubidium> + /* Should SEND_MTU be exceeded, start a new packet (magic 18: uint16 for the id + 2 x bool)*/
14:14:44 <Rubidium> + p->Send_uint32(cp->cmd & 0xFFFF);
14:14:53 <Rubidium> + * uint16 ID of the command (Lower 16 bits) (see command.h).
14:16:44 <Rubidium> I'm also missing the documentation that very clearly states that the command IDs and such are inherently unstable so they must not trust on a particular value having the same meaning between releases
14:17:54 <fonsinchen> Rubidium: now that we have auto-orders and thus stopping orders work better in cargodist ... What is the most significant remaining problem with cargodist in your opinion?
14:19:17 *** Wolf01 is now known as Guest2680
14:19:17 *** Wolf03 is now known as Wolf01
14:20:01 <Rubidium> fonsinchen: I don't know exactly at this point; I haven't really looked at the code recently
14:20:24 <Rubidium> well, I tried but I found that the patches were compound patches that because bigger and bigger
14:20:33 <Rubidium> instead of patches to apply on top of eachother
14:20:52 <Rubidium> which made seeing what each individual branch is about somewhat more tricky to understand
14:21:12 <planetmaker> <3 patch queues ;-)
14:21:25 <fonsinchen> ok, that's a problem. They should be such that they can be applied on top of each other.
14:25:24 <fonsinchen> Somehow I removed the code for incremental patches in order to get clean names for the "cd.diff", but didn't replace it.
14:26:25 *** Dante123 has joined #openttd
14:29:49 <ZirconiumX> Can I just say something
14:30:35 <ZirconiumX> why don't you wait till tomorrow, and you can play with that!
14:31:11 <ZirconiumX> or download r21659
14:34:01 <planetmaker> dada_: what compiler (version) do you use?
14:34:24 <dada_> powerpc-apple-darwin9-gcc-4.0.1
14:35:31 <ZirconiumX> What version of Xcode?
14:35:59 <dada_> Do you know where I can find that? I thought Xcode was just a collection of multiple things
14:36:17 <dada_> But I think it's the last one that works on 10.5, they stopped making them install after a particular version
14:36:25 <ZirconiumX> Look in your Hard disk
14:36:40 <ZirconiumX> Look for a folder that says Xcode
14:36:45 <Eddi|zuHause> ZirconiumX: a person may stay silence and risk others perceiving him as an idiot, or he may open his mouth and remove all doubt.
14:37:14 <dada_> there doesn't seem to be an xcode dir, but I still had the DMG around, which states: xcode314_2809_developerdvd
14:37:43 <planetmaker> dada_: the error is in your compiler, not in OpenTTD, I'm afraid
14:38:05 <planetmaker> but it will be interesting which version it breaks for you nevertheless
14:38:11 <dada_> aha, new function that 4.0.1 doesn't support? I'll update it then
14:38:34 <planetmaker> you cannot update it...
14:38:48 <planetmaker> unless you update your OS which is probably not an option for PPC macs.
14:38:55 <planetmaker> i686-apple-darwin10-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5494) <-- that one builds it
14:38:56 <Rubidium> an "internal compiler error" means the compiler itself is broken. That's not something OpenTTD can do about
14:39:36 <ZirconiumX> PPC support on GCC was dropped some time ago
14:40:07 <planetmaker> ZirconiumX: in this case again: si tacuisses :-P
14:42:11 <Eddi|zuHause> get a virtual machine that runs x86 code :p
14:42:14 <Eddi|zuHause> or get a real computer :p
14:42:19 <Rubidium> ZirconiumX: I really doubt that GCC dropped PPC support
14:42:26 <planetmaker> dada_: does the current nightly of OpenTTD work for you?
14:42:46 <dada_> by the way planetmaker, that version number you showed me is just one build higher than my gcc
14:42:53 <dada_> the nightly? you mean bin?
14:43:05 <planetmaker> yes, the binary download from our website
14:44:38 <ccfreak2k> What happened to the first 21,659...whatevers?
14:44:52 <dada_> seems to work just fine
14:45:44 <Rubidium> Zirwhoisgonenow: powerpc is a primary platform for gcc 4.5, whereas apple's platforms are secondary
14:46:14 <planetmaker> Not sure whether you have other compilers at your disposal; you might try those, dada_
14:46:31 <Rubidium> (and for what it's worth in 4.5 Apple's platforms got bumped from primary to secondary targets)
14:46:48 <planetmaker> you can easily switch them via gcc_select
14:46:54 <dada_> I don't know if there is, I haven't tried macports myself
14:47:06 <planetmaker> Ammler: the gcc from macports don't compile openttd
14:48:05 * dada_ make clean and tries again for good measure..
14:48:08 <planetmaker> they don't respect the file system layout and hirachy as apple's compilers do, thus they fail
14:48:29 <planetmaker> (roughly speaking)
14:48:37 <planetmaker> longer ago that I tried some versions
14:49:02 <Eddi|zuHause> sometimes i really don't understand xkcd...
14:50:27 <planetmaker> makes it IMHO a tiny bit better, but oh well...
14:51:13 <Eddi|zuHause> not really helping either...
14:52:45 <Eddi|zuHause> why would "krasse Spachtelmasse" say "don't touch me"? and what does that have to do with "Impact"?
14:53:16 <fonsinchen> I see that smallmap-stats is not sufficiently documented.
14:54:27 <fonsinchen> I'm still wondering if I should further simplify it. I could remove the mouse-over functionality.
14:57:35 <dada_> planetmaker: I believe the segmentation fault might have been entirely incidental...I'm recompiling the same version and it just passed the group_gui.cpp with no problem
14:59:07 <dada_> maybe I should close my bug report then
14:59:34 <planetmaker> you can only request it. Don't bother though ;-)
15:00:27 <dada_> well, I'll just post anyway to let others know that it must have been some weird failure on my part...this is an old machine, maybe one of the memory units is faulty
15:00:57 <planetmaker> I just closed it ;-)
15:07:06 *** roboboy has joined #openttd
15:08:43 <planetmaker> right... now I know again why I couldn't be bothered with macports gccs anymore: after tricking the sdk detection one ends up with things like /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBundle.h:147:120: error: format string argument not a string type
15:32:58 <CIA-2> OpenTTD: alberth * r21667 /trunk/src/ (tilehighlight_type.h viewport.cpp window.cpp): -Codechange: Introduce _thd.Reset().
15:37:21 <dada_> planetmaker: openttd 21666 successfully compiled
15:37:49 <planetmaker> was it really 40 minutes compile time, though?
15:38:25 <dada_> no...I went to get groceries :)
15:39:31 <dada_> now...if only I could figure out how to get these stuck trucks out of that tunnel...
15:40:03 <planetmaker> sounds like an old(er) savegame which was made with a version which had a bug ;-)
15:57:33 *** Chicago has joined #openttd
15:58:39 *** Chicago_Rail_Authority has joined #openttd
16:15:19 *** HerzogDeXtEr1 has joined #openttd
16:19:31 *** fonsinchen has joined #openttd
16:42:50 <DJNekkid> sorry for asking, as i probably could have tested it, but what happens if a railtype have ID higher then 0xF ?
16:43:21 <DJNekkid> if i, for example, have 14 types with ID 0x00-0x0D
16:43:33 <DJNekkid> and then two types with id 0x10 and 0x11 ?
16:43:39 <DJNekkid> for a total of 16 types
16:43:59 <Yexo> the railtypes with ids >= 0x10 are ignored
16:44:33 <DJNekkid> is it possible to change that?
16:44:43 <Yexo> is there a good reason to?
16:45:35 <DJNekkid> full freedom to choose what to be included in nutracks. Can give, say, 20or so different ones to include, but only 16 of them can be used at once
16:45:45 <DJNekkid> thus do i need IDs higher then 0x10
16:46:07 <Eddi|zuHause> why not set the ID by action 6?
16:46:28 <DJNekkid> probably because i didnt know it were possible :P
16:46:58 <Eddi|zuHause> combined with action D you can make sure each ID is only used once
16:46:59 <Yexo> it can be changed, but either it requires quite a lot of changes to the openttd code or it'd use more memory for _every_ newgrf (not only those including railtypes, but every one)
16:47:17 <DJNekkid> oki, then thats not a (good) option :)
16:48:21 <DJNekkid> but that action6 thingy might be...
16:48:51 <Eddi|zuHause> DJNekkid: i'm imagining like this: for each (not skipped by action 7/9 or conditional compiling) railtype definition you have an action 6 replacing the ID with the content of parameter N, and right afterwards, you increase content of parameter N with action D.
16:49:48 <DJNekkid> that is one way to do it... :)
16:50:22 <Yexo> try nml, you'll get the action6 for free :)
16:50:39 <Eddi|zuHause> DJNekkid: that's what i can come up with within 2 minutes ;)
16:50:53 <DJNekkid> i had some other thoughts as well, but sure... :)
16:51:11 <planetmaker> Eddi|zuHause: that's what sounds the easiest straight-forward approach
16:51:21 <DJNekkid> i was thinking of a action14 table with 16 parameters... one for each ID
16:51:56 <Eddi|zuHause> that sounds tedious... and unnecessarily exposing implementation details to the user
16:52:18 <Yexo> that means your grf will break when a user accidentally assigns two railtypes to the same id
16:52:47 <DJNekkid> Yexo: no, because each ID will have its own parameter
16:53:01 <planetmaker> yep. The one obstacle with the increasing ID type is to write the RTT with the desired IDs
16:53:04 <Yexo> so the users will chose a railtpye for every id?
16:53:15 <Yexo> what happens if the users selects the same railtype twice?
16:53:31 <Yexo> will he get the same railtype twice?
16:53:58 <Eddi|zuHause> planetmaker: what does the railtype grf need railtype labels for?
16:54:13 <Yexo> also, it will be quite tedious to implement that in nfo, you'll have to create a loop over all railtypes for every parameter and check every time if this one has been selected by the user
16:54:15 <DJNekkid> Eddi|zuHause: invisible engines to enable the different ones
16:54:36 <Eddi|zuHause> DJNekkid: imho that's a big design flaw of railtypes
16:54:58 <DJNekkid> Yexo: i dont think it would be too hard, as everything but the action0s are templated
16:55:48 <DJNekkid> Eddi|zuHause: true enough, but still a valid awnser :)
16:56:54 <Eddi|zuHause> planetmaker, DJNekkid: i was imagining more like one parameter to choose from like 3 or 4 predefined subsets, and a second (invisible to the user) parameter for the internal ID numbering, then one can have fixed railtype tables for each of the subsets
16:57:49 <Eddi|zuHause> for each of the subsets, the ID numbering would be deterministic enough to fix the RTT
16:58:09 <planetmaker> probably those two ideas can be considered equivalent
16:58:37 *** einKarl has joined #openttd
16:58:53 <DJNekkid> but then the problem arise, again
16:59:07 <Eddi|zuHause> if you think in "blocks", you might have the need for "padding" railtypes that don't actually exist, to align the blocks, and then can switch around the block contents with action 6 again
17:00:00 <Eddi|zuHause> but this may get complicated/difficult to maintain
17:00:02 <DJNekkid> if, lets say, the 230kmh tracks is disabled
17:00:22 <DJNekkid> and my 230kmh engine is set to use E230 in its trainset RRT
17:00:39 <DJNekkid> then it wont appear, because nothing is known about E230
17:00:55 <planetmaker> where's the problem?
17:01:26 <DJNekkid> the engine wont appear
17:01:35 <Eddi|zuHause> DJNekkid: the trainset can check the existence of E230, and choose to fallback to the default electric railtype instead
17:02:49 <Yexo> either that or just have 1 parameter where you can chose between a few presets, that makes it a lot easier
17:03:20 <Eddi|zuHause> yeah, that's what i said
17:03:36 <DJNekkid> i did have a plan to do that once...
17:03:52 <DJNekkid> there even is a image/table in the nutracks tread about it
17:04:19 <Eddi|zuHause> i like "Option A" and "Option 2" ;)
17:04:48 <Yexo> well, "A" is different from "2", not? :p
17:04:57 <DJNekkid> about in the middle of page11
17:05:51 <planetmaker> DJNekkid: that table is not equivalent to chose different blocks
17:06:20 <planetmaker> My main desire for that is to get NuTracks compatible with other railtype newgrfs so that it does not claim the whole chunk of railtypes
17:07:47 <SmatZ> planetmaker: this time I remembered the password, so I changed it on this computer too :)
17:09:03 <planetmaker> actually it'd do NuTracks quite good if it cut out e.g. the 230km/h track entirely
17:09:30 <planetmaker> and make it maybe, if you want 140 and 200km/h instead of 120 and 160
17:10:22 <planetmaker> or 100,200,highspeed
17:11:06 *** zachanima has joined #openttd
17:11:31 *** zachanima has joined #openttd
17:12:08 <planetmaker> but possibly the most easy solution would be to offer not one giant railtypes newgrf but one for each block ;-)
17:12:24 <planetmaker> easier for the player to select. and also easier to programme
17:12:35 <planetmaker> like nutracks-3rdrail
17:12:46 <planetmaker> nutracks-planning
17:12:50 <planetmaker> nutracks-narrowgauge
17:13:04 <Wolf01> that's what I said yesterday
17:13:50 <planetmaker> not to forget the marvelous nutracks-subway
17:14:06 <Wolf01> yeah, good use of catenary :D
17:14:28 <Wolf01> too bad building's roof is blinking where is red
17:14:51 <planetmaker> that's just a graphics issue which would be easy to fix
17:15:10 <planetmaker> or what do you mean?
17:16:29 <Wolf01> the worse thing are the tunnel entrances, I think there isn't a way to fix them with only a grf since the topmost part is always drawn over the catenary
17:17:45 <planetmaker> hm, yes, probably.
17:27:31 <dihedral> or whoever might want to look at it
18:10:30 *** LordAro has joined #openttd
18:13:03 *** IchGuckLive has joined #openttd
18:13:45 <IchGuckLive> Good evening from Germany. Why are in the desert the Waterwells not rising production if i take water from them ??
18:14:49 <dihedral> because wells do not produce the water, they provide access to water
18:15:07 <dihedral> imagine a balloon full of water below the ground
18:15:22 *** fjb is now known as Guest2698
18:15:26 <planetmaker> also why do oil wells disappear? Just because.
18:15:28 <dihedral> wells provide means of accessing them and the more you drain the less is left
18:16:15 <Rubidium> and once more I broke someone's patch
18:16:36 <dihedral> which patch did you break?
18:18:14 * planetmaker would bet on dihedral
18:18:37 <dihedral> sounds more like my patch broke something
18:18:49 <planetmaker> nah. your patch is broken ;-)
18:18:56 <planetmaker> try to apply it now to trunk :-P
18:19:05 <IchGuckLive> Yexo: so there is no need to play stop and go with the game it rises only in 20years of time BAD
18:19:05 <Rubidium> or just try to svn up :)
18:19:21 <dihedral> hmm... nothing happened :-D
18:19:35 <IchGuckLive> im in year 3 after start
18:19:42 <Yexo> IchGuckLive: I have no idea what you mean with "no need to play stop and go with the game"
18:19:50 <Yexo> and it seems like you totally didn't understand it
18:20:00 <Yexo> or you don't truely understand what "random" means
18:20:27 <IchGuckLive> Yexo: iread it now ones more !
18:21:18 <dihedral> planetmaker, got another wish for the admin network? :-P
18:21:42 <planetmaker> yes. A usuable interface now which connects to it ;-)
18:22:20 <planetmaker> can I take a screenshot via console?
18:22:38 <dihedral> i'll give you a command logger ;-)
18:24:25 <IchGuckLive> ok i go with that and provide as mutch service as i coudt to the water well so i will now run 1train per wagon to a diferent city
18:27:03 <Yexo> you still didn't understand
18:27:11 <Yexo> the production increase/decrease is random
18:27:12 *** ZirconiumX has joined #openttd
18:27:29 <ZirconiumX> hello (no question mark)
18:27:48 <Yexo> the chance of a production increase is higher when the percent of transported cargo is higher
18:27:59 <IchGuckLive> as i see all industries except the providet ones are in or decresing AFTER 1 year
18:28:01 <Yexo> the percent of transported cargo depends on the cargo ration in your station
18:28:31 <IchGuckLive> thats shown in the station list
18:28:34 <Yexo> the very same wiki page I linked you to earlier has a section on how the station rating works
18:28:39 <dihedral> ZirconiumX, lol :-) hello
18:29:07 <ZirconiumX> Yexo, In NoAI, is it possible to set a penalty for crossing into the local authority's tiles?
18:29:09 <Yexo> try to get it over at least 60% and if possible over 80%
18:29:28 <ZirconiumX> hello PM, and dihedral
18:29:53 <Yexo> ZirconiumX: yes, you can use AITile::IsWithinTownInfluence
18:32:11 <IchGuckLive> one more Question Halicopters are only going done on by one ,even on a 3 park area is this correct ?
18:32:33 <CIA-2> OpenTTD: rubidium * r21668 /trunk/ (7 files in 4 dirs): -Feature: command logging using the admin interface (dihedral)
18:32:47 <Rubidium> oh, only 18 minutes lag
18:33:26 <ZirconiumX> Rubidium: 18 minutes?!?
18:33:51 <planetmaker> commit to cia - message
18:35:10 *** JVassie_ has joined #openttd
18:37:08 <IchGuckLive> but you got to find them
18:38:42 <IchGuckLive> and Thanks for the help
18:40:18 * ZirconiumX then kicks CIA-2 again
18:40:52 <ZirconiumX> ah, lag's back to normal
18:49:08 <CIA-2> OpenTTD: translators * r21669 /trunk/src/lang/ (34 files in 2 dirs):
18:49:08 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
18:49:08 <CIA-2> OpenTTD: simplified_chinese - 6 changes by ww9980
18:49:08 <CIA-2> OpenTTD: greek - 10 changes by fumantsu
18:50:27 <ZirconiumX> While (!pub_found) DeclareWarOnRussia (no offence intended)
18:54:11 *** Chicago_Rail_Authority has quit IRC
19:17:44 *** Biolunar has joined #openttd
19:21:15 *** fonsinchen has joined #openttd
19:33:15 *** Wizzleby has joined #openttd
20:18:46 *** Brianetta has joined #openttd
20:30:29 *** ChanServ sets mode: +v tokai
20:48:49 *** andythenorth has joined #openttd
20:49:17 <Alberth> hi hi ho andythenorth
21:05:14 *** ChanServ sets mode: +v tokai
21:11:40 *** cup_cup has joined #openttd
21:30:52 *** Chillosophy has joined #openttd
22:09:23 *** andythenorth has left #openttd
22:11:13 *** mib_ed7e0c has joined #openttd
22:17:47 <Zuu> good then at least we can feel bored togeather :-)
22:20:17 <Zuu> Oh, I found a bug in my software. At least some excitement :-)
22:23:29 <Eddi|zuHause> you should declare it an easter egg ;)
22:30:03 <Zuu> hehe, it was a repaint-error so you could use it to figure out how and when it repaints the screen. :-)
22:38:12 *** ABCRic_ has joined #openttd
22:40:23 *** ABCRic is now known as Guest2720
22:40:23 *** ABCRic_ is now known as ABCRic
22:55:37 <Wolf01> I converted my entire site in php this evening... it should demonstrate how bored i get :|
22:57:21 <Wolf01> *how much bored I can get... and I should avoid to speak like Yoda
22:58:41 <Eddi|zuHause> yoda speak like avoid you should
23:02:11 <__ln__> to what language did you convert your entire site in php into?
23:02:46 <Wolf01> from plain static html to php ;)
23:04:32 * Zuu has designed a new example for his junction simulator but pounders to draw different vehicle types with different colors or something ^^
23:07:50 <Zuu> Or maybe get some comic clipart images :-p
23:10:25 <__ln__> who can be blamed for the british narrator of mythbusters?
23:12:35 <peter1138> the whole thing went downhill when they introduced a team
23:13:30 *** ABCRic_ has joined #openttd
23:13:54 *** ABCRic is now known as Guest2722
23:13:55 *** ABCRic_ is now known as ABCRic
23:14:14 <__ln__> that's one way of putting it, but doesn't remove the fact that the british narrator is pretty annoying and apparently all the non-dubbing europe has to listen to him.
23:28:56 <SmatZ> anyone ever experienced that SIGFPE handler is ignored?
23:29:07 <SmatZ> and division by zero kills the app instead?
23:29:26 <SmatZ> I even have assert(handler == signal(SIGFPE, handler))
23:31:38 <SmatZ> and it crashes on line 7...
23:34:59 <SmatZ> the handler is not executed
23:37:04 <__ln__> SmatZ: signal man page says: "Integer division by zero has undefined result. On some architectures it will generate a SIGFPE signal."
23:38:15 <SmatZ> __ln__: it should generate SIGFPE on x86 (and it does according to gdb), just the handler is ignored and the app crashes
23:38:28 <SmatZ> I am not trying to find out what causes the misbehaviour
23:38:42 <SmatZ> because simple code doesn't crash...
23:38:55 <SmatZ> maybe it has something to do with SDL being used
23:39:37 <SmatZ> maybe the signal is delivered to the SDL thread, that has no handler
23:41:35 <__ln__> SmatZ: i guess you are aware that by default SDL sets its own signal handlers for things such as SIGSEGV?
23:42:18 <SmatZ> __ln__: I expect those are overriden if I call signal() and three lined below I do 1/0
23:44:09 <SmatZ> looks like the signal delivery is "random"
23:44:19 <SmatZ> (to which thread the signal is delivered)
23:44:34 <SmatZ> it makes me wonder how ottd's signal handling actually works...
23:44:45 <SmatZ> or, why it works, if it really works :P
23:46:09 <__ln__> the signal man page also says: "The effects of signal() in a multithreaded process are unspecified."
23:48:40 <SmatZ> __ln__: I remember reading something about that in the past, too
23:49:02 <SmatZ> then I wonder even more why we use signal() in openttd if it's very unreliable
23:49:13 <Mazur> I vote for the best sitcom line I heard this year for: "Sheldon is one lab-accident away from being a super-villain."
23:50:12 <Mazur> Although TBBT has some other strong contenders.
23:51:07 <SmatZ> it just took me time to realise you are in multithreaded environment when using SDL
23:53:08 <dihedral> SmatZ, i noticed when playing with tcl and signals that a bunch of signals can be ignored
23:54:14 <SmatZ> dihedral: I need to call the handler, not ignore the signals :)
23:55:30 <dihedral> i replaced handling of signals, and i was not as the signals were not even available
23:56:00 <dihedral> it was like the os did not even know them - it was not i who tried to ignore them :-P
23:58:06 <__ln__> SmatZ: may i recommend the PowerPC architecture where division by zero does not cause any signals nor aborting the app.
23:58:33 <SmatZ> __ln__: your recommendation has been taken into consideration :)
continue to next day ⏵