IRC logs for #openttd on OFTC at 2012-01-08
⏴ go to previous day
00:14:16 *** Illegal_Alien has joined #openttd
00:18:53 <Eddi|zuHause> so... did $someone profile nml yet?
00:22:14 <Yexo> a big part of the time is spend in compressing real sprites
00:26:02 <Eddi|zuHause> we need nmlcache :p
00:26:43 <Eddi|zuHause> at least the realsprites, which don't change 99% of the time...
00:28:16 <Eddi|zuHause> and grfcodec can compress the sprites in 2 seconds...
00:29:25 <Eddi|zuHause> > time grfcodec -e -p1 cets.grf
00:29:27 <Eddi|zuHause> Sprite80646 Done: 99% Compressed: 39% (Transparency:100%, Redundancy: 35%)
00:30:56 <welshdragon> is openttd.org down?
00:31:17 <Eddi|zuHause> can we do nfo-output and pipe that through grfcodec?
00:31:55 <Yexo> you'll get a slightly worse compression
00:34:44 *** Brianetta has joined #openttd
00:37:22 <Eddi|zuHause> still not really fast
00:38:34 <Yexo> haven't found a good way to profile nml though, so it's been hard to figure out where the slowness comes from
00:39:38 <welshdragon> can Giant Screenshot be disabled? I've just killed my map I've been working on
00:39:57 <Eddi|zuHause> just waaaaait... :)
00:40:24 <Eddi|zuHause> we could make a confirmation box like when selling all vehicles and stuff
00:40:50 <welshdragon> why does it kill OpenTTD
00:41:17 <Eddi|zuHause> no, it just locks up until it's done
00:41:40 <Eddi|zuHause> (maybe it can be threaded?)
00:42:32 <michi_cc> Eddi|zuHause: Out of interest, what's the reason to have all track sets as separate entries in the CETS RTT instead of using the fallback mechanism?
00:42:34 <welshdragon> so it could be hours before it's completed? :(
00:43:34 <Eddi|zuHause> michi_cc: it felt easier to generate this way
00:44:02 <Eddi|zuHause> michi_cc: i mean composing the tracktypeXY identifiers
00:45:18 <Eddi|zuHause> michi_cc: it could probably compressed somewhat with using #defines
00:45:41 <Rubidium> Eddi|zuHause: it'd be pretty difficult to do that as you'd be calling the drawing methods from two threads which might easily cause artefacts
00:46:30 <Rubidium> and then I'm talking about the 'easy' case where you use a bootstrap-esque window to show the progress, i.e. without a background of vehicles
00:46:33 <Eddi|zuHause> Rubidium: hm, so the drawing functions need to get de-globalised?
00:47:08 <Rubidium> Eddi|zuHause: that, and sprite loading, possibly blitting
00:47:27 <michi_cc> Where's the difference between using "tracktype_certs%s%s%s :\n'%(track_type[1], track_type[0], track_type[4])" or "tracktype_dbrails%s%s%s :\n'%(track_type[2], track_type[0], track_type[4]))" instead of having whatever tracktype_certs??? evaluates to have the matching tracktype_dbrails??? has fallback?
00:47:45 <michi_cc> Then you wouldn't need all that runtime querying for each engine.
00:48:10 <Eddi|zuHause> michi_cc: the nutrack railtypes are kinda orthogonal to that, so it won't work for them
00:50:19 <Eddi|zuHause> there's not much "runtime querying". the track set is calculated once and stored in a parameter, the railtype property is calculated once during the loading stage for each engine, the only "runtime" decision is checking the parameter in CB23 (purchase list text)
00:50:36 <michi_cc> Okay, you're right with that. Still, the DBrails case could be done with RTT fallback.
00:51:12 <Eddi|zuHause> michi_cc: yes, but then i lose the ability to display dbrails-specific text
00:51:55 <Eddi|zuHause> which is kind of a micro-feature, but i see no harm in that
00:51:58 <michi_cc> Do we really need that? Maybe mb will also adapt the proposed TC** scheme :p
00:52:15 <Eddi|zuHause> one has hopes and dreams, right? :p
00:52:52 <Eddi|zuHause> he has the 12.12.12 left :)
00:54:59 <michi_cc> One interesting (vapour) feature is the variable loading weight of wagons depending on track class (if it really will be in 0.9, that is). I don't really know how to sanely handle a wagon driving from heavy track to light track though, otherwise it would be quite nice to have.
00:56:54 <Eddi|zuHause> i think he said he won't implement that
00:57:32 <Eddi|zuHause> i'm still thinking of a way to sanely implement that in CETS
00:58:43 <Eddi|zuHause> my idea was providing one wagon each with light/medium/heavy load, and even empty wagons can only run on the high track class. alternative would be to severely limit speed if overloaded
00:59:15 <michi_cc> Either a big running cost penalty or better a speed penalty. The only problem with that is that ideally YAPF would know that and apply penalties for too light track.
00:59:37 <Eddi|zuHause> i don't see how to sanely do that
01:00:31 <Eddi|zuHause> need a tracktype penalty callback
01:00:51 <Snail_> is it possible at all? I think we can't change the vehicles' speed according to the railtype they're traveling on
01:01:07 <Eddi|zuHause> Snail_: speed limit can be adjusted with cb36
01:01:11 <michi_cc> Maybe do the light/medium/heavy load via (auto-)refit, but that would require CB changeable track type.
01:01:12 <Snail_> coz speed, unlike TE, is cached so it can be changed only at certain times (depot visit, stop at station, etc)
01:01:39 <michi_cc> Snail_: CB36 for speed will be called if the vehicle enters a tile with a new railtype.
01:01:49 <Eddi|zuHause> Snail_: i think railtype change is such a time
01:02:02 <Snail_> well, I tried to do a test about this
01:02:20 <Snail_> I tried to change the speed through property depending on the railtype
01:02:49 <Snail_> and my engines didn't change speed when crossing a different railtype tile.. they only changed it after reversing, depot visit etc
01:03:11 <Eddi|zuHause> a test grf for that case would be nice
01:04:56 <Snail_> I could make one, but that would work with my new tracks...
01:05:31 <Snail_> anyway I talked to MB about this and he told me that speed is cached, and entering new railtype tile doesn't enforce it to be reset
01:05:38 <Snail_> unlike TE (with TE, this works well)
01:05:39 <michi_cc> Snail_: Looking at the source code I see that this is done when the lead engine enters the new railtype, so you have to query the railtype if the engine via parent scope and not use the current vehicle.
01:06:06 <Snail_> but what if I code this for the engine itself?
01:06:35 <Snail_> I coded my engines so that their speed would be limited if they entered rackrail tracks, but it didn't work
01:07:22 <michi_cc> Hmm, but doing it for the wagon should still work, the whole chain is updated when any part changes railtype.
01:07:49 <michi_cc> Snail_: OpenTTD source looks correct at first sight to me, so it might be a bug in your test code.
01:08:15 <Snail_> ok, I can provide you with the *.GRF with this
01:08:23 <michi_cc> Can you paste the apporpriate CB36 source code?
01:08:24 <Snail_> but I also have to include my tracks :p
01:08:48 <Snail_> ok, I'll do it... wait a sec, I'll write it in m4nfo and then translate to NFO
01:09:09 <michi_cc> Maybe m4nfo has a bug :p
01:12:08 <Snail_> ok, I can paste the code that (1) checks for the railtype, (2) limits the speed if the railtype is of a certain type, and (3) sets this property for the engine's callback
01:12:15 <Snail_> / Test for rackrail: limit speed
01:12:15 <Snail_> 11364 * 0 02 00 03 81 4A 00 FF 01
01:12:17 <Snail_> 11365 * 0 02 00 04 81 10 00 FF 03
01:12:23 <Snail_> / End of test for rackrail
01:12:25 <Snail_> 11366 * 0 02 00 13 85 0C 00 FF FF 02
01:12:27 <Snail_> / ref(1) if(CB_TSFX) // text
01:12:27 <Snail_> 04 00 36 00 36 00 // no capacity
01:12:29 <Snail_> cf 00 2d 00 2d 00 // switch lights
01:12:44 <Eddi|zuHause> don't paste in IRC
01:13:56 <Snail_> sorry, I'm not much of an IRC expert :)
01:14:55 <Snail_> the line I commented as "no capacity" in the end is the one that collects the property reducing speed when on rackrail tracks
01:16:58 <Yexo> can you also show us your railtype table?
01:17:02 <Eddi|zuHause> is the engine already on the new tile when the callback is run?
01:17:44 <Yexo> to test that send the vehicle to a rackrail depot and out again, the callback is run again in that case and it must be onthe rackrail railtype
01:18:30 <Eddi|zuHause> he said earlier that it worked in depot etc.
01:19:16 <Snail_> Yexo: yes, the railtype for rack is called NRAN ( {N}arrow gauge, {R}ackrail speed, axle weight {A}, {N}o electrification )
01:19:27 <Snail_> yes, when it gets out of a depot it works
01:20:07 <Snail_> but if I buy it in a non-rackrail depot and start it, and send it on a track that is non-rackrail until a certain point, and rackrail beyond that point, the engine won't slow down when hitting the first rackrail tile
01:20:31 <Eddi|zuHause> what if you have a track like <normal><rackrail><normal>?
01:20:52 <Snail_> mind you, when it reaches the end of the track (which is a rackrail tile) and reverses to come back, the slower speed limit is enforced
01:21:23 <Snail_> Eddi|zuHause: in that case, it will go through the rackrail part at the normal speed, then it reaches the normal track again, and continues with the same speed
01:23:55 <Eddi|zuHause> but, TE should be cached the same way as speed, or not?
01:24:20 <Snail_> I don't think so. I'm no expert, but I asked MB and he told me it's not the case
01:24:29 <Snail_> TE is not cached, but always computed
01:25:23 <Yexo> <michi_cc> Snail_: OpenTTD source looks correct at first sight to me, so it might be a bug in your test code. <- can you give me a pointer?
01:25:26 <Yexo> I can't find the right code
01:25:41 <Yexo> speed is updated by Train::ConsistChanged, but that doesn't seem to be called (not even indirectly) when entering a new tile
01:26:11 <Snail_> Yexo: ok, do you need all the NFO that codes the engine I'm testing this on?
01:26:33 <Eddi|zuHause> Yexo: i'd search for the compatible/powered calculation
01:26:40 <Yexo> Snail_: no, I just wanted to have a quick look at the openttd code
01:27:11 <michi_cc> Yexo: I think you're right. It updates the max track speed, but not the vehicle speed.
01:27:56 <Eddi|zuHause> void Train::RailtypeChanged() <-- i think it should be added there
01:28:09 <Eddi|zuHause> there's only this->PowerChanged();
01:28:13 <Yexo> it might actually be intentional that it doesn't work for speed
01:28:14 <michi_cc> I guess we should call ConsistChange insead of PowerChange then.
01:28:24 <Yexo> if speed was set to 0 on a new railtype, things would break pretty badly
01:29:15 <Eddi|zuHause> Yexo: speed is clamped to 1
01:29:24 <Eddi|zuHause> or, should be :p
01:29:49 <Snail_> perhaps it's like this not to be too much CPU-intensive? otherwise, if it were always recomputed, there would be *lots* of recalculations all the time... i.e. whenever any train enters a new tile...
01:30:10 <Yexo> it only has to recalculate if a vehicle enters a new tile with another rail type
01:30:15 <Eddi|zuHause> Snail_: no, only when entering a new railtype
01:30:32 <Eddi|zuHause> Snail_: and at that point, lots of other things need calculation anyway, so the effect won't be that big
01:31:45 <Eddi|zuHause> michi_cc: does ConsistChanged do anything that is dangerous outside a depot?
01:31:45 <michi_cc> Yexo: From looking at blame output the power changed is basically a remains from the elrails merge. It was always just PowerChanged from then on.
01:32:05 <michi_cc> Eddi|zuHause: Yes, but it has a parameter to error for length changed.
01:32:17 <Eddi|zuHause> so it was just forgotten in railtypes...
01:32:57 <Yexo> not perse, IIRC the "current railtype var" was a later addition
01:33:31 <Yexo> before that addition there was no use for redoing the speed callback
01:33:32 *** dotwaffle has joined #openttd
01:34:23 <michi_cc> Yes, but I think ConsistChanged can be used for that. It's also called when reversing for example, so I guess nothing would break.
01:34:28 <DorpsGek> Yexo: Commit by michi_cc :: r20165 /trunk/src (newgrf_engine.cpp newgrf_railtype.cpp) (2010-07-16 19:02:59 UTC)
01:34:29 <DorpsGek> Yexo: -Feature: [NewGRF] Information (var 4A) about the current railtype a train is on.
01:35:04 <Yexo> michi_cc: I guess you're right
01:35:21 <Eddi|zuHause> issue solved. moving on :)
01:35:34 <Yexo> 18 months and only now the first bug report
01:36:02 <Snail_> you mean it will be solved in the next nightly?
01:36:26 <Eddi|zuHause> it's not commited yet
01:36:38 <Yexo> not by me, I'm really off to bed now
01:36:50 <Eddi|zuHause> but "there exists a solution" is already enough for me :)
01:38:09 <Snail_> ok, so I'll be on the lookout for a nightly that solves this ;)
01:38:33 <michi_cc> The only thing I'm a bit skeptical about is that ConsistChanged also updates the cargo capacity. But nobody complained yet about trains changing capacity on reversing, so I guess that's okay :)
01:39:04 <Eddi|zuHause> does it throw away the surplus cargo?
01:40:13 <Eddi|zuHause> anyone fancy implementing ctrl+flip for articulated vehicles? :)
01:40:17 <Snail_> michi_cc: meaning that, if you code wagons with different capacities across different railtypes, they might lose cargo if mving from heavy tracks to light tracks/
01:40:47 <Snail_> Eddi|zuHause: it might be cool, but only for certain vehicles
01:41:02 <Eddi|zuHause> Snail_: that's probably a very silly idea to change capacity :p
01:41:03 <Snail_> i.e. it would be great for certain MUs, not for steamers with tenders ;)
01:41:26 <Eddi|zuHause> Snail_: well, the newgrf controls which vehicles can be flipped
01:41:45 <Eddi|zuHause> Snail_: and some steamers were designed to run equally fast in both directions. like BR 50
01:42:34 <Eddi|zuHause> BR 50 was a "light" engine for branch line use, and generally too large for many turntables
01:42:38 <michi_cc> Eddi|zuHause: It doesn't, but like I said, you could already mess with it on reversing, which is why I'm not that worried.
01:43:29 <michi_cc> In theory the speed update could be split, but then there's simply some other property than isn't updated but should.
01:44:24 <Eddi|zuHause> yeah, should probably just tell the newgrf coders "better not change <XYZ> outside depot"
01:44:43 <Elukka> some steamers also ran on push-pull trains which made reverse speed pretty important
01:44:57 <Snail_> Eddi|zuHause: then I'd like articulated vehicles to be flippable. In fact one of my DMUs would benefit from this :D
01:45:17 <Eddi|zuHause> Elukka: those are usually ones that have builtin tenders
01:46:19 *** dotwaffle has joined #openttd
01:49:03 <Snail_> yep those were the tank engines. They can be flippable already
01:49:25 <Elukka> assuming i understand the term 'wendezug' right and they're titled correctly...
01:49:25 <Eddi|zuHause> Snail_: well, not mine :p
01:50:27 <Elukka> well, that br 23 certainly seems to be pushing judging from the smoke
01:50:55 <Eddi|zuHause> Elukka: that was already very late, 1960s or so
01:51:41 <Eddi|zuHause> Elukka: and the P8 has a "wannentender" from the war-time BR 52 (which is derived from the above mentioned BR 50)
01:52:06 <Elukka> yeah, the tender really doesn't fit it :P
01:55:54 <Eddi|zuHause> well, DB quickly scrapped the inferior-material 52's, but reused the tenders elsewhere
01:56:58 <Eddi|zuHause> DR, however, used them quite long, because they couldn't get replacements
01:57:05 <Elukka> i think it's one of the prettier steamers, particularly with the original tender
01:58:24 *** fjb|tab has joined #openttd
02:08:14 <Eddi|zuHause> Elukka: anyway what i meant to say, the tender is already specially crafted for backwards travel
02:08:56 <Eddi|zuHause> where "fast" is like 90km/h
02:09:28 <Eddi|zuHause> which is "ok" for a generic passenger train
02:10:09 <Eddi|zuHause> a P8 with original tender wouldn't be able to go that fast backwards
02:10:45 <Elukka> i've heard that, but what feature of a tender enables a locomotive to go fast backwards?
02:12:04 <Eddi|zuHause> i guess the connection to the engine. and the BR 50/52 tenders had a wind shield on the sides
02:14:00 <Eddi|zuHause> the engine-tender connection is usually made in a way so the tender pulls down the engine (to get more adhesive weight). while going backwards, the engine may not push up the tender
02:14:08 <Eddi|zuHause> otherwise it might jump off the tracks
02:15:35 <Eddi|zuHause> this is not a design goal if you're only going 40km/h backwards
02:17:00 <Eddi|zuHause> a related issue is getting steering cars for express trains like modern IC or the ICE2
02:18:50 <Eddi|zuHause> to this day the ICE2 may not go top speed with steering car in front when there are high winds
03:12:02 *** fonsinchen has joined #openttd
03:29:00 *** MagisterQuis has joined #openttd
05:56:27 *** Eddi|zuHause has joined #openttd
07:34:36 *** DayDreamer has joined #openttd
07:35:40 *** DayDreamer has left #openttd
07:36:13 *** sla_ro|master has joined #openttd
07:57:23 *** andythenorth has joined #openttd
08:20:43 *** Progman has joined #openttd
08:41:53 <CIA-6> OpenTTD: rubidium * r23772 /trunk/src/lang/latvian.txt: -Fix (r23771): validation failure
08:42:08 *** peter1138 has joined #openttd
08:42:08 *** ChanServ sets mode: +o peter1138
09:06:26 *** Devroush has joined #openttd
09:17:04 <andythenorth> does anyone play with 'vehicles never expire' *off*?
09:26:00 <SmatZ> andythenorth: those who play with default settings, I guess :)
09:29:24 <V453000> is that still as default? :o
09:29:46 * andythenorth is wondering how much effort to put into keeping a short buy menu
09:30:15 <andythenorth> if I try and keep the menu short, but everyone has 'vehicles never expire'....kind of pointless :P
09:30:26 *** TWerkhoven has joined #openttd
09:31:54 <V453000> well you could put sort the vehicle ID by date of release of the vehicle, or by the "usefulness" of the vehicle so people buy the first few in the top of the list
09:32:06 <V453000> but I personally like more to sort by vehicle type
09:32:18 <V453000> like all passenger trains together, etc
09:32:42 <V453000> and since there are all the filters, one can always sort it his way and choose from the top I guess
09:35:08 <LSky`> if anyone with knowledge of servers is around,
09:35:38 <LSky`> im trying to run a 1.1.4 dedicated server, but its not receiving a session key from the master server, no errors, it just doesnt advertise at all
09:35:48 <LSky`> th 1.2.0-beta2 server works fine, no issues
09:35:58 <Rubidium> 99% chance your firewall blocks stuff
09:36:08 <LSky`> that would get the error
09:36:27 <LSky`> i forward both 3979 for 1.1.4 and 3980 for 1.2.0
09:36:37 <LSky`> the 1.2.0 works great, even if I change the port to 3979
09:36:56 <Rubidium> works fine with my 1.1.4
09:37:04 <LSky`> yeah, hence I wondered what the issue was
09:37:14 <LSky`> it doesnt say that its unable to receive the key
09:37:22 <LSky`> it seems like its not even asking for one
09:37:28 <LSky`> when I clearly enable advertising
09:39:11 <SpComb> sudo tcpdump -f 'host <masterserver>'
09:40:10 <SpComb> if you're desperate, install wireshark and try there
09:40:28 <SpComb> it'll tell you if you're even sending anything out, or seeing any UDP back
09:40:43 <SpComb> not that I know what your actual issue is
09:41:06 <LSky`> well i just double checked the port
09:41:21 *** Alberth has joined #openttd
09:41:21 *** ChanServ sets mode: +o Alberth
09:41:26 <LSky`> it also works with the 1.2.0-beta2 server if I change it back to 3979 there
09:41:31 <LSky`> so its not a firewall issue
09:42:35 <LSky`> the odd thing is, it get queried
09:43:49 <LSky`> actually now Icheck it, it does actually get queried just as much as the other server :\
09:45:29 <LSky`> it gets queried but it doesnt show up in the list... :|
09:47:33 <SpComb> are you looking in the right place in the list? :)
09:48:01 <LSky`> the server list on the site and in the server browser
09:48:20 <LSky`> but im not surprised that it doesnt show up, no messages that its being advertised show up in that server's console
09:50:06 <LSky`> i got wireshark working, looking at the traffic now, what should I be looking for?
09:50:18 <SpComb> dunno, UDP to/from master server?
09:51:49 <LSky`> well I guess it somehow works
09:51:58 <LSky`> since someone just connected the instant I put it up
09:52:20 <LSky`> yet it doesnt advertise again, what is this i dont even :(
10:01:04 <LSky`> yeah, its just ignoring the cfg file
10:02:56 <LSky`> "...\OpenTTD 1.1.4\openttd.exe" -D -c 114.cfg as a shortcut should work right?
10:12:01 <LSky`> Also, "You have a newer version of OpenTTD, Setup will now exit" fffffffffff
10:13:48 *** fonsinchen has joined #openttd
10:33:55 *** Chris_Booth has joined #openttd
10:35:14 <SpComb> LSky`: just use the .zip's
10:35:26 <LSky`> I did, unfortunately a reinstall didnt work
10:35:48 <LSky`> I thought I did something wrong with pointing it to the right cfg, but for some reason it wont do what I want it do :D
10:36:15 <LSky`> it just, doesnt use a config at all
10:36:32 <Alberth> the readme explains in great detail how the cfg file is found
10:37:58 <LSky`> which is why i asked; "...\OpenTTD 1.1.4\openttd.exe" -D -c 114.cfg as a shortcut should work right?
10:38:03 <Yexo> LSky`: if you point it to a location where it isn't allowed to write a file, it can't make a new config file
10:38:23 <Yexo> LSky`: whether or not that works depends on what the working directory is when you execute that link, and also where the config file is
10:38:58 <LSky`> so it doesnt automatically search for the config file in the normal folder?
10:39:25 <LSky`> `> I thought I did something wrong with pointing it to the right cfg, but for some reason it wont do what I want it do :D
10:39:30 <Yexo> as Alberth already said: see readme.txt
10:39:34 <LSky`> C:\Users\LSky\Documents\OpenTTD
10:39:43 <Yexo> unless that is the working directory, no
10:40:04 <Yexo> use -c C:\Users\LSky\Documents\OpenTTD\114.cfg to have it use that file
10:41:07 <LSky`> thanks, that did actually work
10:41:27 <LSky`> which only makes me wonder why the 1.2.0-beta2 server works without specifying the folder
10:41:38 <andythenorth> multi-trailer trucks, number of trailers refittable by cargo subtype abuse
10:41:47 <andythenorth> first trailer capacity might be split with truck
10:41:48 *** fjb|tab has joined #openttd
10:42:11 <andythenorth> ^ try templating that efficiently :P
10:50:26 <Alberth> m4 supports computations and conditional inclusion of text
10:51:01 <andythenorth> m4 is not nml :P
10:51:44 * andythenorth waves and points at rv-wagons
10:52:48 <Alberth> cpp is also not nml :)
11:05:19 * andythenorth figures it out. maybe
11:07:52 *** TGYoshi has joined #openttd
11:08:23 * Alberth has full confidence in andy
11:10:04 * andythenorth might be about to learn about IDs in nml the hard way :P
11:10:45 <andythenorth> if I wasn't obsessed about having my CPP includes in alphabetical order, life would be easier :/
11:12:07 <planetmaker> andythenorth, just prefix them with 001_myname and 015_anothername etc
11:12:12 <planetmaker> then all is in good order ;-)
11:12:40 <andythenorth> or I should deliberately disorder them now
11:12:47 <andythenorth> removing temptation to try and keep them ordered
11:23:12 <Alberth> if I include A, B, and C, and A includes E, then the order of processing in A E B C which is not alphabetical
11:25:12 <Alberth> Justkidding!! /me hugs andythenorth
11:26:36 *** Brianetta has joined #openttd
11:28:12 *** mahmoud has joined #openttd
11:50:59 *** Hyronymus has joined #openttd
11:52:25 *** tokai|mdlx has joined #openttd
11:56:06 *** fjb|tab has joined #openttd
11:57:24 <andythenorth> does nml automatically take care of splitting a cb for the buy menu chain?
11:58:09 <planetmaker> no. But each CB should have a purchase version
11:58:25 <planetmaker> if you don't define that one, though, the normal CB is used
12:01:38 *** JVassie has joined #openttd
12:04:38 *** frosch123 has joined #openttd
12:20:36 *** valhallasw has joined #openttd
12:27:53 <frosch123> so, who has a big endian machine and can make a screenshot using a 32bpp blitter?
12:31:05 <andythenorth> core 2 duo is little endian?
12:31:59 <frosch123> all intel stuff uses le
12:32:36 <planetmaker> __ln__, could do on his G4
12:39:59 <TrueBrain> basically, only old computers are BE :P
12:40:33 <frosch123> BE is like using decimal number representation in the cpui
12:40:54 * andythenorth used to be big endian
12:45:34 <__ln__> afaik Wii, PS3 and Xbox360 are BE
12:47:56 <CIA-6> OpenTTD: michi_cc * r23773 /trunk/src/ (rail_cmd.cpp saveload/vehicle_sl.cpp train.h train_cmd.cpp): -Change: [NewGRF] Update all cached train properties if a train vehicle enters a new railtype.
12:55:01 <frosch123> hmm, would a "newgrf suggestion forum" be fun? :p
12:55:20 <TrueBrain> useful .. not sure :P
12:55:30 <andythenorth> suggestions for newgrfs?
12:55:38 <andythenorth> or suggestions for newgrf spec features? :P
12:55:46 <frosch123> the former of course
12:56:08 <frosch123> there is a suggestions forum in the ottd and ttdp section, but not in the graphics section
12:56:13 <andythenorth> can it be hidden from my view?
12:56:26 <andythenorth> maybe a browser plugin could do that :P
12:56:32 <frosch123> you mean that would increase the usefulness?
12:56:50 <frosch123> TrueBrain: see, it has use
12:57:52 <TrueBrain> there is a use in the hiding of the use
12:57:56 <TrueBrain> this is getting tricky :P
12:58:07 <frosch123> it's like a spam filter
13:02:00 *** FLHerne has joined #openttd
13:05:05 <andythenorth> there's nothing so fun as figuring out why the buy menu reports wrong capacity :P
13:09:49 *** TomyLobo has joined #openttd
13:09:57 <Eddi|zuHause> we need step-by-step callback debugging
13:10:35 <andythenorth> position in consist can't be evaluated during buy menu, yes/no?
13:10:44 <andythenorth> also cargo subtype
13:12:43 <Eddi|zuHause> none of the 40+/80+ variables
13:12:55 <andythenorth> I just solved this in HEQS, can't remember how :D
13:13:53 <Eddi|zuHause> make front and tail different IDs, and report all capacity in the front
13:14:19 <andythenorth> or fake it on the trailers for buy menu switch
13:14:33 <andythenorth> either way, fake it :P
13:15:32 <frosch123> Eddi|zuHause: are you sure that is useful with nml?
13:17:29 <Eddi|zuHause> frosch123: i don't understand the question
13:17:46 <frosch123> the step-by-step debugging
13:18:33 <Eddi|zuHause> frosch123: need debugging symbols in nml :p
13:19:54 * andythenorth needs a code generator :P
13:21:53 <andythenorth> how do I know when I'm abstracting too far with CPP?
13:21:58 <Eddi|zuHause> nml has at least 3 code generators builtin
13:22:11 <andythenorth> if you have to open > n templates to find the actual code, it's too many
13:22:48 <Eddi|zuHause> just make it for arbitrary numbers, and then every n is just a special case
13:22:50 <Alberth> 7 ? (that's the number of things a human can manage to do at the same time)
13:25:24 <Eddi|zuHause> i currently have tracking table -> generate.py -> processing.py -> write.py -> tree.py -> vehicle template -> alignment template -> png file
13:26:08 <Eddi|zuHause> occasionally also a custom callbacks file
13:26:24 * andythenorth might do evil with #ifdef
13:26:57 <Eddi|zuHause> that's really the least evil i do :p
13:27:14 <Alberth> it is evil by definition, almost :)
13:27:31 <andythenorth> can cpp evaluate a value?
13:27:41 <andythenorth> e.g. if #define NUM_TRAILERS 2
13:27:44 <Eddi|zuHause> that's why we have nml
13:27:49 <Alberth> yes, but only for internal use :)
13:28:46 * andythenorth could concatenate paths
13:28:47 * Alberth refrains from recommending a different macro expansion engine
13:28:58 <Eddi|zuHause> andythenorth: it can only evaluate plain constants, not do any calculations
13:29:28 <andythenorth> otherwise I have #define NUM_TRAILERS_IS_1 True
13:30:29 <Eddi|zuHause> #define NUM_TRAILERS 2
13:30:38 <Eddi|zuHause> #if NUM_TRAILERS == 1
13:30:47 <Eddi|zuHause> #elsif NUM_TRAILERS == 2
13:35:09 <andythenorth> if I was really smart I'd switch in nml :P
13:35:26 <andythenorth> instead of relying on hardcoded things
13:38:30 *** Adambean has joined #openttd
13:40:16 <TrueBrain> so the question is: are you? :P
13:41:30 *** KenjiE20 has joined #openttd
14:33:16 *** fonsinchen has joined #openttd
14:34:24 *** Markavian has joined #openttd
14:46:42 <CIA-6> OpenTTD: frosch * r23774 /trunk/readme.txt: -Fix: Wrong path in readme.txt
14:52:49 *** valhalla1w has joined #openttd
15:10:39 *** supermop_ has joined #openttd
15:15:12 *** valhallasw has joined #openttd
15:16:57 <Fixer> ohi, i need some info on STR_GOAL_QUESTION_BUTTON_SURRENDER(etc), don't know how to translate it, can somebody explain what is the meaning of that STR_GOAL_QUESTION_BUTTON form?
15:18:01 <Yexo> goal scripts can open a window with question
15:18:19 <Yexo> the goal script can chose up to 3 pre-defined buttons to add to that window
15:18:21 <Fixer> question to the player?
15:18:28 <Eddi|zuHause> Fixer: a game script can ask the player a question, like: "your mission would be to infiltrate the casino: [Accept], [Deny Existence], [Self destruct]"
15:18:48 <planetmaker> Eddi|zuHause, the button text is pre-defined
15:18:54 <Yexo> can also be a simpel message, like "You've reached part 1 out of 3. [ok], [cancel]"
15:19:26 <Fixer> SURRENDER is pre-defined message
15:19:37 <planetmaker> it's one of the possible buttons
15:19:47 <Yexo> some of the others might be hard to translate
15:20:32 <planetmaker> I was quite struggling with some. "next" is quite ambiguous. As is previous etc
15:20:35 <Eddi|zuHause> Yes/No/FileNotFound
15:21:04 <Eddi|zuHause> planetmaker: "weiter"/"zurück"?
15:22:33 <planetmaker> maybe, Eddi|zuHause
15:22:33 <Eddi|zuHause> the problem is, for translation you need context, and the context is given by the game scripts, which may not be written yet
15:22:47 <michi_cc> For some of these button texts it might make sense to look at what your OS generally uses for them.
15:30:30 <Eddi|zuHause> Fixer: what's on the monopoly board?
15:34:17 <frosch123> "go" as in "let's go"
15:38:21 *** JVassie has joined #openttd
15:49:54 *** [1]Mark has joined #openttd
15:49:55 *** Mark is now known as Guest23340
15:49:55 *** [1]Mark is now known as Mark
16:00:28 <andythenorth> nml is pretty epic
16:00:37 <andythenorth> what's truly epic about it though is the documentation
16:02:17 <planetmaker> I hope that was not ironic ;-)
16:03:38 *** Chris_Booth has joined #openttd
16:04:15 <supermop_> what are you doing in nml today, andy?
16:04:39 <frosch123> robbing and thiefing
16:05:41 * andythenorth just saw a flaw in a beautiful plan :/
16:06:02 <planetmaker> throw enough beautiful sprites on it so that the flaw will be hidden ;-)
16:06:08 <andythenorth> if I have a vehicle with 1 trailer, I want a subtype refit string "No trailer"
16:06:24 <andythenorth> and if a vehicle has 2 trailers, I want a subtype string "No trailers"
16:06:29 <andythenorth> which I've just coded :P
16:06:52 <andythenorth> breaks refitting
16:06:59 <andythenorth> when using auto-replace
16:07:16 <andythenorth> haven't tested yet :P
16:07:31 <planetmaker> if it's different vehicles I don't see how it breaks
16:07:31 <andythenorth> might be ok because it's first refittable type
16:08:14 <supermop_> no trailer, singular still makes sense for a vehicle that normally has 2
16:08:16 <Hirundo> As long as its both subtype X, the string doesn't matter methinks
16:08:35 <andythenorth> frosch123: what got fixed recently with auto-replace and subtypes?
16:08:55 <supermop_> a truck with no trailer has no trailer regardless of what its has at other times
16:09:24 <andythenorth> supermop_: yes, but it's nicer with the optional s
16:10:32 <andythenorth> HEQS trams hide invisible trailers inside the length of the visible vehicles
16:10:38 <andythenorth> don't think I can do that here
16:10:46 <andythenorth> templates will be spaghetti if I do that
16:11:12 <frosch123> andythenorth: it not considers all articulated parts when searching for a subtype with the same name
16:12:22 <supermop_> ok you guys keep up the good work, i am off to get lunch
16:14:42 *** JVassie has joined #openttd
16:21:49 <Eddi|zuHause> dear oberhümer... WHAT DID I SAY ABOUT EMPTY LINES IN THE TRACKING TABLE!
16:23:17 <andythenorth> nml I can't reuse switch identifiers, unlike varaction 2 IDs in nfo?
16:23:30 <andythenorth> not a problem...just checking...
16:23:43 <Eddi|zuHause> no, identifiers must be unique
16:24:13 <andythenorth> lots more CPP concatenation then :P
16:24:21 <Eddi|zuHause> which lead me to my VEH_ID(evilness)
16:25:11 <andythenorth> I am using it in a more verbose way, because my brain recoils at seeing it in expressions
16:25:30 <planetmaker> whatever helps the understanding
16:25:36 <andythenorth> i.e. I define a constant, then use it wherever
16:25:41 <planetmaker> the bits come nearly at no cost ;-)
16:26:02 <Eddi|zuHause> a cost of a 5 minute compilation time...
16:26:03 <andythenorth> means I don't have to concatenate things with my brain :P
16:26:50 <andythenorth> 6s for BANDIT currently
16:27:16 <andythenorth> 3s for HEQS (nfo)
16:27:38 <Eddi|zuHause> hmz... the parameter description doesn't resize on number of lines
16:27:39 <planetmaker> well... OpenGFX takes MUCH longer, if you include the gimp part
16:55:28 *** MagisterQuis has joined #openttd
16:57:16 <rasco> so... i've got a question:
16:57:54 <rasco> all the cost amounts, like running costs, purchase costs etc. they can only be multiplied by 2's right??
16:58:12 <CIA-6> OpenTTD: frosch * r23775 /trunk/src/ (screenshot.cpp screenshot.h settings_gui.cpp): -Change: Hide the PCX screenshot format from the options window, if a 32bpp blitter is used.
16:59:13 <rasco> is there a way to set really custom costs with a grf? not just doubling the prices?
17:00:17 <frosch123> the overall cost stuff can only be changed by powers of 2
17:00:31 <frosch123> every vehicle sets its purchase cost in more detail
17:02:08 <rasco> okay. and is there a way for one grf to manipulate the vehicle costs of another grf one-by-one (instead of globally)?
17:03:16 <Yexo> one grf can override every vehicle property from vehicles in one other grf
17:03:40 <rasco> oh, perfect. so i could set completely custom prices for my favorite trainset without modifying the set itself.
17:04:02 <Yexo> yes, although that might fail if that trainset uses callbacks to set the cost
17:04:26 <rasco> ok. does the default one use callbacks to set the cost?
17:05:09 <rasco> ok. i would like to make a server with custom (higher) running costs. especially for planes.
17:06:16 <rasco> just multiplying them by powers of 2 didnt work out since it made the earlier planes completely useless
17:06:42 <rasco> yeh. i guess i will have to take a close look at it.thanks.
17:07:10 <rasco> so... another question. i've searched for this before on the forums and found a patch but it's really old:
17:07:17 <rasco> making the multiplayer time slower.
17:07:44 <Yexo> it's still not decided how that should be done and what influences it has on the economy
17:08:03 <rasco> ok. why is time speed an issue with the economy?
17:08:22 <rasco> is the economy coupled with the real-time clock?
17:09:01 <Yexo> if you make a year twice as long (but vehicles run at the same speed), your vehicles travel twice the distance they would before
17:09:26 <Yexo> this means twice as much income. If the running costs are per year it'd be an obvious difference
17:09:53 <Yexo> some industry newgrfs rely on the fact that they produce cargo every 256 ticks, which means 8 or 9 times per month
17:10:21 <Yexo> if a month was suddenly twice as long, they might not produce twice as much leading to problems with your trains (since train capacity would be doubled)
17:10:56 <rasco> i see, there are various issues here :/
17:11:52 <rasco> but i guess whichever decision is made, newgrf's wouldn't necessarily work when speed is changed
17:12:11 <rasco> so that isn't really an issue. just put a warning above the setting.
17:13:43 <rasco> so what about making vehicles slower on slower speed?
17:14:16 *** Hyronymus is now known as Guest23349
17:14:20 *** Hyronymus has joined #openttd
17:14:52 <rasco> or...hmm. if you let them run at regular speed you would have to alter all incomes and running costs
17:15:12 <rasco> frosch123: i've thought about just pausing the game for a few minutes automatically
17:15:18 <rasco> but it sucks since you can't build anything etc.
17:15:27 <frosch123> you can in newer ottd's
17:15:53 <frosch123> for < 1.2 in singleplayer, for >= 1.2 also in multiplayer
17:16:03 <frosch123> there is an advanced setting to enable build in pause
17:16:10 <frosch123> hmm, or is that even in 1.1
17:16:14 <rasco> well that is interesting...
17:16:36 <Eddi|zuHause> i think it's in 1.1
17:17:16 <rasco> is there such a server? one that makes the time run slower by pausing?
17:17:22 <frosch123> so, where is the gamescript that pauses the game 50% of realtime? :p
17:17:45 <frosch123> rasco: 1.2 has scripting support, so it should be possible to run such a server with 1.2
17:17:53 <frosch123> but i doubt there is one :)
17:18:06 <frosch123> might also look weird :p
17:18:37 <frosch123> however, it is common for servers to pause if no clients are conneted
17:19:06 <Alberth> like slow down the time by a factor 2, and stop all trains every second half of the day :p
17:19:17 <rasco> is it the option "command_pause_level"?
17:19:25 <rasco> frosch123: i might make such a script
17:20:40 <rasco> hmm, what value do i set it to?
17:21:23 <frosch123> i guess "3" allows everything
17:22:13 <rasco> so is there LUA scripting now or what?
17:24:09 *** MagisterQuis1 has joined #openttd
17:25:08 <rasco> squirel's modules are .nut files? :D
17:26:43 <frosch123> (ottd uses squirrel 2.2.x, in case you browse that site)
17:48:27 <SmatZ> frosch123: what was the reason not to switch to 3.0? problems with backwards compatibility?
17:48:44 <frosch123> yes, we would break all ais
17:49:09 <frosch123> at least as far as i understood the issue :p
17:52:21 *** andythenorth has joined #openttd
17:53:04 <andythenorth> should I let articulated (semi) trucks refit to 0 trailers?
17:53:07 <andythenorth> with 0 capacity?
17:53:29 <frosch123> i thought you do not want cargo subtypes :p
17:53:44 <andythenorth> I drank that coolade already
17:53:55 <andythenorth> unless you shipped rv-wagons while I was just in the shower :P
18:12:05 <Terkhen> andythenorth: depends, would that reduce running cost accordingly?
18:12:54 <andythenorth> where do all the trailers go? :P
18:17:59 *** MagisterQuis has joined #openttd
18:21:29 * andythenorth has to write some magic for auto-refit :o
18:22:32 <andythenorth> it's only magic because I don't know how it works yet :(
18:22:48 <Eddi|zuHause> i haven't actually looked at autorefit yet
18:23:24 <andythenorth> I'll probably allow it per same class
18:24:21 <Eddi|zuHause> sounds like a good initial estimate
18:27:28 * andythenorth aims for BANDIT r100
18:29:37 *** atoz-chevara has joined #openttd
18:30:14 <andythenorth> can nml do maths in spritesets?
18:32:35 *** atoz-chevara has left #openttd
18:32:36 <andythenorth> I don't know what I need yet
18:32:40 <andythenorth> but I have a feeling
18:33:12 <iddqd> that tonight’s gonna be a good night
18:39:38 *** TWerkhoven2 has joined #openttd
18:45:27 <CIA-6> OpenTTD: translators * r23776 /trunk/src/lang/ (6 files in 2 dirs): (log message trimmed)
18:45:27 <CIA-6> OpenTTD: -Update from WebTranslator v3.0:
18:45:27 <CIA-6> OpenTTD: basque - 18 changes by rosie2999
18:45:27 <CIA-6> OpenTTD: italian - 2 changes by lorenzodv
18:45:27 <CIA-6> OpenTTD: latvian - 35 changes by Tranzistors
18:45:28 <CIA-6> OpenTTD: tamil - 117 changes by aswn
18:45:28 <CIA-6> OpenTTD: ukrainian - 24 changes by Fixer
18:46:08 <andythenorth> Eddi|zuHause: that's pretty neat
18:46:42 <andythenorth> maybe you want to work on trucks next :P
18:48:56 * andythenorth is just going to cheat
18:49:01 <andythenorth> defines are like duck tape
18:49:08 <andythenorth> most things can be fixed with "more"
18:56:36 <Eddi|zuHause> hm... i need to group companies... so one can offer parameters like: None/All/All German/Prussia/Saxony/Bavaria/All Swiss/SBB/BLS/RhB/All Austrian/kkStB/...
18:59:14 <andythenorth> I have same issue in BANDIT for continents
18:59:24 <andythenorth> seems trivial, just work
19:00:21 <Eddi|zuHause> well, currently i can offer: None/All/Prussia/Saxony/Bavaria/SBB/...
19:00:29 <Eddi|zuHause> but not the "All <xyz>"
19:01:34 <Eddi|zuHause> and then i have various private railways that don't offer a complete set of engines, so they shouldn't be standalone, but like "DBAG only" and "DBAG + private"
19:01:50 <Eddi|zuHause> which i currently can't do either
19:05:30 *** HerzogDeXtEr has joined #openttd
19:07:03 *** George|2 has joined #openttd
19:07:03 *** George is now known as Guest23375
19:07:04 *** George|2 is now known as George
19:23:21 <Eddi|zuHause> oooooh... access fault!
19:24:08 <Eddi|zuHause> i guess it's kinda dangerous that openttd doesn't validate against changed files
19:24:09 <Rubidium> is that an euphimism for an (induced) earthquake?
19:24:26 <SpComb> Eddi|zuHause: binaries?
19:24:53 <SpComb> while loaded or between save/load?
19:25:50 <Eddi|zuHause> while the game is running
19:25:57 <Eddi|zuHause> overwriting the newgrf
19:27:24 <Rubidium> that shouldn't happen; IIRC we just open it once per (save)game
19:27:49 <Rubidium> so if something happens, then it's a concurrency issue with reading/writing to it at the same time
19:28:29 <Eddi|zuHause> Rubidium: refilling sprite cache?
19:28:38 <Rubidium> and IMO more a 'tool that modified grf'-issue; that should not change the file, but write a new one and then replace it so you don't end up with a broken file
19:29:21 <Rubidium> Eddi|zuHause: yes, it opens the file once and the sprite cache reused the file handle
19:29:38 <Eddi|zuHause> and then the file is modified
19:29:48 <SpComb> Rubidium: but openttd still shouldn't crash if someone "corrupts" a grf file while it's loading :)
19:30:40 <Eddi|zuHause> not sure if it can be solved at all
19:30:40 <SpComb> you can't assume a file open()'d is immutable, even though the usual semantics are to replace the filename with a new inode
19:31:02 <SpComb> but if you don't want to load it all into memory, well
19:31:18 <Eddi|zuHause> you can't run an md5sum on each read access
19:31:25 <Rubidium> SpComb: but... reading the whole file in memory doesn't help either
19:31:31 <SpComb> Eddi|zuHause: neither is md5sum atomic..
19:31:40 <Rubidium> as you can change it while it's reading the file
19:31:56 <SpComb> Rubidium: well, read it in, parse it to make sure it's valid, and then refernce it later
19:31:56 <Rubidium> so in any case you can be screwed by the NewGRF changing
19:32:14 <SpComb> I assume the issue is that the grf was valid when loaded, but then changed to invalidate those assumptions?
19:32:42 <SpComb> or does openttd also crash if loading a semi-written/corrupted grf that doesn't change?
19:32:52 <Eddi|zuHause> Rubidium: can read the file twice and compare? :)
19:33:16 *** mahmoud has joined #openttd
19:33:27 *** Kurimus has joined #openttd
19:33:46 <Eddi|zuHause> my problem was that i unpaused without reload_newgrfs first
19:33:56 <Eddi|zuHause> and then it immediately segfaulted
19:34:28 <Rubidium> SpComb: some invalid NewGRFs may crash OpenTTD when loading them
19:34:41 <Rubidium> but good luck trying to figure out where and when
19:35:14 <Rubidium> and honestly I can't be really bothered by changing those files while OpenTTD is running
19:35:26 <Rubidium> it's like changing NewGRFs in-game, which is something we don't support either
19:35:57 <Eddi|zuHause> hm... town built a 7 tile bridge over river... i thought that is guarded against?
19:37:24 <SpComb> Rubidium: as long as it doesn't have security implications, I guess it's acceptable
19:37:58 <Terkhen> Eddi|zuHause: it should be guarded, IIRC it only allows to cross 3 tiles of water
19:39:40 <Terkhen> hmm... right, that's for bridges over "flat" terrain
19:39:50 <Terkhen> bridges that start on a slope have a limit of 11
19:41:03 <frosch123> Eddi|zuHause: do not modify the file, but delete it, and recreate it
19:41:13 <frosch123> if you have a proper kernel and filesystem, they should not interact
19:41:15 <Eddi|zuHause> frosch123: i just type make
19:41:45 <Eddi|zuHause> Terkhen: that looks like the fault then
19:41:51 <frosch123> try adding an "rm bla.grf" before calling nml then
19:42:44 <Eddi|zuHause> frosch123: no, nmlc should then make sure it writes to a new file, and replace the original one afterwards
19:43:22 <Eddi|zuHause> frosch123: the file should be deleted only if compile was successfull
19:43:42 <Eddi|zuHause> arctic rivers look weird in alpine...
19:44:39 <SpComb> Eddi|zuHause: it should indeed
19:44:58 <SpComb> open() + write() is only for things like databases, not text files
19:49:41 <Eddi|zuHause> should probably overwrite the open/close routines there
19:50:22 <Alberth> SpComb doesn't matter what you do in the user program, the kernel handles writing to disk
19:51:11 <Alberth> and does not do a single write :p
19:51:14 <SpComb> Alberth: it does, open() + write() + close() isn't atomic at all to other processes
19:51:35 <Eddi|zuHause> SpComb: but that's not the actual issue
19:51:50 <SpComb> and file.write() is just fwrite(), and that can do arbitrarily many write()s, and I don't think even those are necessarily atomic
19:52:17 <SpComb> userspace proccesses must do open('foo.tmp'), write, rename('foo.tmp', 'foo')
19:52:33 <SpComb> + an fsync() thrown in at some point in between, can't remember
19:52:40 <SpComb> if they want atomic file saves
19:52:54 <Alberth> why would you want that?
19:53:17 <Alberth> the file is only available after the program finished
19:53:21 <SpComb> and if openttd wants it's old open() fd to retain the old version as it was when it origionally loaded it
19:54:38 <Alberth> so do nmlc .... -o foo.tmp ; mv foo.tmp foo.grf instead
19:54:54 <SpComb> although nmlc should do that itself internally
19:55:14 <Alberth> nml does not promise atomic file creation
19:55:19 <blathijs> nmlc is a compiler, not a runtime-openttd-grf-file-updater
19:55:25 <SpComb> well, it should, if openttd assumes them :)
19:55:44 <blathijs> Openttd calls nmlc at runtime?
19:57:07 <Eddi|zuHause> no, but nmlc can run while openttd is open
20:01:08 * Alberth has lots of programs running at the same time
20:01:45 <Alberth> but simple solution, run them in separate directories, and use 'mv' :)
20:03:02 *** Chris_Booth has joined #openttd
20:04:44 <blathijs> Eddi|zuHause: I can also run echo "foo" > some_file.grf while openttd is open, so what? ;-)
20:05:09 <Eddi|zuHause> blathijs: OPENTTD SHOULD NOT SEGFAULT WHEN DOING THAT (sorry, for the fifth time now)
20:07:01 <valhallasw> Eddi|zuHause: you're overwriting a data file that is in use, and you're surprised stuff breaks?
20:07:29 <Eddi|zuHause> valhallasw: i'm not surprised. i'm saying it should be guarded against.
20:07:41 <Eddi|zuHause> valhallasw: no program should _ever_ segfault
20:08:19 <Eddi|zuHause> a segfault is the first sign of a potential code injection
20:08:25 <frosch123> if you type reload_newgrfs fast enough, it works
20:08:26 <blathijs> Eddi|zuHause: Then it should be fixed in openttd, not nmlc, right?
20:08:35 <valhallasw> Eddi|zuHause: oh, right, good point
20:08:57 <Eddi|zuHause> frosch123: yes. but i tend to forget that :)
20:08:59 <valhallasw> I hadn't looked at it that way, but rather as 'stuff crashes when I do stupid things'
20:09:52 <Eddi|zuHause> blathijs: yes. the nmlc part was in response to those "workarounds" that were given as potential solutions
20:11:10 <valhallasw> Eddi|zuHause: on the other hand... if you can write to files, you can also write to openttd.exe
20:13:14 <Rubidium> Eddi|zuHause: tell use where it crashes, then I'll add a NOT_REACHED() there. Then it won't be segfaulting anymore ;)
20:13:36 <Eddi|zuHause> Rubidium: the problem with segfaults, you don't get a backtrace
20:14:58 <Eddi|zuHause> ALSA lib pcm.c:7316:(snd_pcm_recover) underrun occurred
20:14:59 <Eddi|zuHause> Speicherzugriffsfehler
20:19:27 *** mouseym has joined #openttd
20:21:59 <Eddi|zuHause> Terkhen: maybe the "beginning on slope" rule should be "beginning on slope on height 1"?
20:22:27 <Eddi|zuHause> or only "bridge on height 1"?
20:22:36 <Eddi|zuHause> (meaning "across ocean")
20:25:49 <Eddi|zuHause> Terkhen: i mean replace "if (slope == SLOPE_FLAT)" by "if (height > 1)"
20:26:23 <Eddi|zuHause> Terkhen: so 11 tile bridges are only allowed on height 1 (ocean), not any higher (river)
20:27:38 <Eddi|zuHause> check might need some more details
20:28:00 <Terkhen> checking for && IsSea(bridge_tile) in the second build method sounds cleaner to me
20:28:02 *** Chris_Booth_ has joined #openttd
20:29:10 <Eddi|zuHause> Terkhen: or check for river width, if the bridge is more than X tiles longer than the river/lake/ocean is wide, forbid the bridge
20:31:36 <Terkhen> hmm... but it already can only build bridges over water (I'm sorry, I think that I'm not following you)
20:31:51 <Eddi|zuHause> Terkhen: "&& IsSea" on the second lopp is wrong, because that will forbid crossing rivers next to slopes
20:32:47 <Eddi|zuHause> slope is the wrong check there
20:33:44 *** Chris_Booth_ is now known as Chris_Booth
20:34:21 <Eddi|zuHause> Terkhen: with "width" i mean for each water tile in <bridge direction>, go in <orthogonal direction> and count the water tiles.
20:35:00 <Eddi|zuHause> if max_width + X < bridge_length: forbid
20:35:41 <Eddi|zuHause> that allows crossing lakes and oceans, cross rivers, but not bridge rivers or canyons lengthwise
20:36:20 <Eddi|zuHause> and it's completely agnostic of river/sea
20:36:35 <Eddi|zuHause> which is kind of an arbitrary distinction, e.g. in scenarios
20:43:08 <Elukka> this is how you remove snow and ice from tracks
20:43:12 <Elukka> with a goddamn jet engine
20:43:38 <FLHerne> NewGRF would be shiny :P
20:44:04 <FLHerne> Can NewGRFs remove snow?
20:50:21 <jonty-comp> i've always thought for train tracks under snow
20:50:33 <jonty-comp> they should just pump gigawatts of heat into the tracks
20:50:37 <jonty-comp> and melt all the snow on them
20:50:43 <jonty-comp> clearly that is the best solution
20:50:57 <andythenorth> Eddi|zuHause: swap the alpine river banks :P
20:52:49 <Eddi|zuHause> andythenorth: it should only need an actionA-ish
20:53:05 <Eddi|zuHause> basically the same that alpine already does with the land sprites
20:53:08 <andythenorth> Eddi|zuHause: that newgrf is mostly actionA-ish :P
20:53:21 <andythenorth> just find + replace arctic / temperate :P
20:53:43 <Eddi|zuHause> i mean not actually include any sprites
20:54:55 *** mahmoud has joined #openttd
21:05:34 *** KillerByte has joined #openttd
21:19:25 <Eddi|zuHause> anyone spot the irony in killer being killed?
21:23:27 <Rubidium> well, you kill fire with fire ;)
21:50:47 *** Mycomeback31 has joined #openttd
22:00:21 <FLHerne> Just made a 64 x 32768 map and sent an aircraft from one end to the other
22:00:31 <FLHerne> It took quite a while
22:03:48 <FLHerne> No, there weren't any towns in the opposite corners of the map :P
22:04:04 <FLHerne> Rather pointless really
22:04:18 <__ln__> was it refuelled in air?
22:07:08 <FLHerne> I don't know - I'm not using a recent enough version to have range...Does the new aircraft range thing allow refuelling?
22:07:18 <Elukka> there's an aircraft range thing?
22:08:45 <FLHerne> Apparently. I haven't used it yet though. Could be quite fun if it works...
23:06:33 *** FLHerne has joined #openttd
23:20:41 *** fjb|tab is now known as Guest23394
23:20:42 *** fjb|tab has joined #openttd
continue to next day ⏵
