IRC logs for #openttd on OFTC at 2007-08-04
⏴ go to previous day
00:00:04 <Wolf01> 'night all, good work TrueBrain ;)
00:00:07 <Eddi|zuHause> the standard does not really care about overflow... it usually assumes ring semantics
00:01:56 *** Digitalfox_Notebook has joined #openttd
00:02:29 <SmatZ> Eddi|zuHause: well I just suppose the gcc developers are not intentionally doing things breaking the standard, and even putting that switch as default for some optimisation level ...
00:02:56 <Eddi|zuHause> SmatZ: i am not discussing this any further
00:03:27 <Eddi|zuHause> gcc is either wrong in giving this warning or wrong in doing actions causing this warning...
00:06:24 <Rubidium> the problem is that there is no standard; just an assumed standard which they basically are breaking with that option
00:07:03 <SmatZ> Rubidium: yes, I agree with you, too
00:08:00 *** Smoovious has joined #openttd
00:08:51 <Rubidium> -O2 compiling is slow if you don't have gcc 4.2 installed on your distccds
00:10:46 <SmatZ> Rubidium: actually, I use the default './configure' with no switches, and it sets the '-O2 -fomit-frame-pointer' flags ... I compile with that settings, too
00:12:36 *** Gekkko` has joined #openttd
00:15:35 <SmatZ> Rubidium: in openttd, byte is signed, isn't it? it is causing an ineffective code in CBlobT::Size(), as TBase::RawSize() is of type byte, that may be signed
00:15:43 <SmatZ> the generated asm checks if it is signed
00:16:43 <Ammler> Hallo, is there a max for autoclean_unprotected
00:16:54 <SmatZ> because instead of '/ Titem_size' it does bit shifting, but for negative numbers, it must be changed to give the same value as division
00:17:13 <Ammler> I set it to 2400, but my unprotected company was cleaned
00:18:15 <Rubidium> Ammler: there is a max
00:18:38 <Ammler> I like to reset the passwort soon
00:18:47 <SmatZ> bsize_t is the same as ptrdiff_t that is signed
00:19:00 <Ammler> but no company cleaning
00:19:22 <Ammler> autoclean_protected = 24
00:19:31 <Rubidium> and ptrdiff_t is most likely an int
00:21:08 <SmatZ> Rubidium: I trust you :) now I search why bsize_t must be signed
00:23:44 <Eddi|zuHause> SmatZ: probably because of avoiding signed/unsigned mix in arithmethic calculations
00:26:23 <SmatZ> Eddi|zuHause: maybe, but I didn't find any problem - there are very few arithmetic operations done, and all are between bsize_t,bsize_t ... only one substraction is done, and the operands are checked not to give a negative results
00:26:39 <SmatZ> one additiion, and it is checked not to be negative
00:29:26 <SmatZ> after changing the typedef to typedef ::uint32 bsize_t; everything seems to work ok ... nvm
00:30:13 <SmatZ> there are comparisons outside the blob.hpp, you are right, Eddi|zuHause
00:36:21 <Eddi|zuHause> maybe you can insert that into the art series of TrueBrain's :p
00:39:00 <Eddi|zuHause> btw, the offset of the truck icon looks kinda wrong
00:40:47 <SmatZ> Eddi|zuHause: yes, it is ... maybe it is placed in a different way (by the center of the sprite, not the corner) in the ottd code
00:42:04 <Rubidium> too bad it gives totally unreadable text
00:43:26 <SmatZ> hmm it is not placed in a different way than other widgets...
00:44:39 <SmatZ> yes, it is unreadable... it could be changed, to use smaller fonts, but if it was meant only for toolbars, it wouldn't matter
00:46:01 <SmatZ> but the icons are not nice when downsampled this way
00:46:09 <Rubidium> SmatZ: toolbars are solved on another way already
00:46:24 <CIA-1> OpenTTD: rubidium * r10779 /trunk/config.lib:
00:46:24 <CIA-1> OpenTTD: -Fix: GCC 4.2 makes (by default for -O2, -O3 and -Os) an assumption that signed
00:46:24 <CIA-1> OpenTTD: integers do not overflow, whereas it is very likely that some of the legacy code
00:46:24 <CIA-1> OpenTTD: does so. It furthermore breaks with the assumed standard (the behaviour is not
00:46:24 <CIA-1> OpenTTD: actually defined in the standard) about the behaviour when signed integers wrap.
00:47:37 <SmatZ> I just tried something different, for really small displays in all directions
00:47:45 <SmatZ> whoa thanks Rubidium :)
00:48:38 <Rubidium> SmatZ: I'd start with some really large windows that cannot be downscaled much
00:48:45 <Rubidium> like the autoreplace window
00:48:52 <Gekkko`> Rubidium: nice fix above
00:48:57 <Rubidium> or the new vehicle window
00:49:03 *** Gekkko` is now known as Gekko
01:00:10 <Wezz6400> is it me or is openttd mostly developed during the night (for that particular developer)
01:00:44 <Rubidium> depends on what you call night
01:01:26 <Rubidium> I've basically stopped developing more than 3.5 hours ago ;)
01:01:40 <Wezz6400> then why did you just commit?
01:02:06 *** ThePizzaKing has joined #openttd
01:02:10 <glx> I don't call that a "developement" commit :)
01:02:55 <Rubidium> basically a no-brainer
01:03:31 <Wezz6400> still, I've been up at this time of day lately and I noticed commits by people I know to be in my timezone
01:03:45 <Rubidium> Wezz6400: and how would you know I'm in your timezone
01:04:18 <Eddi|zuHause> that is not very difficult to figure out :p
01:04:23 <SmatZ> err /whois Rubidium ... utwente.nl
01:04:28 <Wezz6400> Well if you go around tt-f it's not that hard to find people's nationality, however your hostname is also kind of a giveaway
01:04:32 <glx> my client says you are both supposed to be in .nl
01:04:47 <Rubidium> SmatZ: that only tells you where my "screen" with irssi is running
01:04:57 <Rubidium> it does not say a thing about my physical location
01:05:09 <Wezz6400> well I'm gonna assume you're not that far away from the timezone that machine is running
01:05:28 <SmatZ> Rubidium it can be true
01:05:29 <Wezz6400> it's not like you can get a uttwente hostname by just requesting it :P
01:05:47 <Rubidium> I was a few months ago 9 timezones away and will be 8 timezones away in a few months
01:05:54 <Eddi|zuHause> well, he could be at a "conference" somewhere half around the world temporarily
01:06:35 <Wezz6400> however most of the time he won't
01:06:39 <Rubidium> for all you know I'm now in Montreal
01:06:43 <Wezz6400> therefore it's a good guess
01:07:30 <Rubidium> glx: no, there's nothing interesting in Montreal right now ;)
01:07:58 <Wezz6400> Rubidium for all you know that one girl is there right now ;)
01:08:28 <Rubidium> glx: I doubt that he is right now
01:09:06 <glx> well he said he won't move far from it
01:09:17 <Wezz6400> anyways I wasn't critizing or anything, I just noticed
01:09:25 <Eddi|zuHause> it's like in Scrubs: "I go to a medical conference in Cleveland. By medical conference i mean golf session. And by Cleveland i mean Honululu." - "My taxi is waiting outfront. And by taxi i mean helicopter."
01:09:53 <Wezz6400> helicopters don't wait out front :P
01:10:17 <Eddi|zuHause> it's not a literal quote... it's more like a back-translation
01:10:38 <Wezz6400> I should go to bed, my remarks are borked
01:12:49 <Rubidium> bed, that's so overrated ;)
01:13:22 <Eddi|zuHause> go to bed != sleep
01:13:35 <Wezz6400> well it's 3:13 am (for me at least) so yeah, I agree
01:14:01 <Rubidium> advantage of doing devving late/at night is the fact that you most likely wont get called, don't have any problems with noise from small children playing, motor "terrorists" (i.e. the people driving with way too much noise) etc.
01:14:05 <Wezz6400> I actually found out I'm fitter when I sleep less than 8 hours a night, 7 or 7,5 is much better
01:14:07 <Rubidium> just perfect silence
01:14:44 <Rubidium> well, the spinning of my hdd because I turned laptop mode off as it made my movie playback jerky
01:15:29 <Wezz6400> I know what you mean
01:15:38 <Wezz6400> however atm I'm too tired to really do anything
01:15:39 <Rubidium> and no disturbances means much better efficiency
01:15:42 <Wezz6400> I just had a lot of fun on irc ;)
01:15:54 <Eddi|zuHause> 'motor "terrorists"' <- people with lawnmowers or motorscythes
01:16:28 <Rubidium> and I sleep well enough to not be waked by them in the morning ;)
01:16:39 <Eddi|zuHause> i have very light sleep
01:16:52 <Eddi|zuHause> i wake by the slightest noises
01:16:56 <Wezz6400> I live along a tram line and a reasonable busy road (with buses going one way) but it doesn't really bother me
01:17:22 <Wezz6400> it did a bit when I moved, but you get used to it
01:17:31 <Rubidium> you'll adjust pretty easily when the sounds are constant enough (i.e. happen often enough)
01:17:37 <Eddi|zuHause> the worst thing around here is the garbage-car every 2 weeks
01:17:39 <SmatZ> Rubidium: CanBuildVehicleInfrastructure() should return false for spectators ... it may cause problems lake this (with non-def GRF) -> http://192.168.0.5/ttd/screenshot.png (airport, rail available to specs) ... or eg. Shift+F1 asserts the game for spectators even with default GRF
01:18:18 <SmatZ> maybe the first problem is already fixed
01:18:26 <Wezz6400> my parents live a very silent neighbourhood
01:18:31 <Rubidium> SmatZ: I don't have that image on my secondary server
01:18:35 <Wezz6400> the worst thing there is the county's lawn mowers
01:18:55 <Eddi|zuHause> there was a time when i did not wake from the radio, but from my sister knocking against the wall shouting i should turn the volume of the radio down
01:19:56 <Eddi|zuHause> while the radio really wasn't very loud, it was just next to the wall, so it was louder on her side
01:19:57 <SmatZ> but the second part, Shift+F1 asserts for spectator openttd: /mnt/svn/openttd/trunk/src/player.h:241: Player* GetPlayer(PlayerID): Assertion `( (uint)((i) - (PLAYER_FIRST)) < ((uint)((sizeof(_players)/sizeof(_players[0])))) )' failed.
01:21:26 <glx> try to reproduce in latest trunk and if it is still present then open a bug report
01:22:11 <SmatZ> glx the second "[03:20:03] <SmatZ> but the second part, ..." is in the latest trunk, will test the first problem and in 0.5 branch
01:25:57 <CIA-1> OpenTTD: rubidium * r10780 /trunk/src/group_gui.cpp: -Fix: assertion when opening the advanced vehicle list with the shortcut when being a spectator.
01:26:06 <Rubidium> SmatZ: it's related to the advanced vehicle list, so it's not in 0.5
01:26:20 <Rubidium> and it shouldn't be in trunk either ;)
01:26:26 <SmatZ> ok, it was related... :)
01:29:12 <Wezz6400> well gl devving a bit more ;)
01:30:02 <Wezz6400> you are a stubborn man aren't you ;)
01:31:29 *** Eddi|zuHause2 has joined #openttd
01:31:31 <Rubidium> seen the diff? It's a one-liner and the bug was identified and fixed within a minute
01:31:55 <Wezz6400> sorry dude I was just kidding but I'm too tired
01:32:14 <glx> even SmatZ said what was needed
01:32:45 <Wezz6400> happens often when I'm tired, somehow the difference between a funny nasty remark gets borked for me and people misunderstand me, oh well
01:32:58 <Wezz6400> my bed is shouting ;)
01:33:25 <Rubidium> we're just playing with you ;)
01:33:40 <Wezz6400> me, who is never tired
01:33:59 <Wezz6400> I sometimes stay up until 7 for no particular reason :X
01:34:53 <Wezz6400> well I was tired already and was just about to go to bed when something funny happened on irc so I stayed; maybe I had a good reason to go to bed early :X
01:35:06 <Wezz6400> oh well, welterusten to you to when you do sleep ;)
01:35:08 <Rubidium> like on a winters afternoon starting with TTD and wondering why the sun is still shining after a "while"?
01:35:47 <Wezz6400> well for me it's usually thinking "oh crap" when I realize it's the first tram of the day I hear passing by
01:36:48 <Rubidium> for me it was rather: "oh crap", I've got to go to college in an hour
01:37:31 <Wezz6400> I never have had an hour, but I did stay up until like 6:30 once knowing all to well I had an appointment with classmates at 10:15
01:37:49 <Wezz6400> which ended up doing nothing but making nasty remarks from 12 to 15 I think :X
01:39:59 <SmatZ> oh no, I forgot running wine crashes my KDE :-x
01:41:14 <Rubidium> never ever run an application related to Microsoft Application (Interfaces) and irc on the same computer
01:41:32 <SmatZ> it shouldn't and didn't before gcc 4.2.0 ... maybe I should put that '-fno-strict-overflow' to my cflags too :-x
01:41:53 <glx> I'm on windows and on irc on the same computer :)
01:42:27 <Rubidium> yeah, and every day you are disconnected a few hours because you have to reboot your computer ;)
01:42:31 <glx> usually when windows crashes it does it on start
01:44:15 <Eddi|zuHause2> it's so funny (or rather not)... my (linux) computer sometimes crashes on boot, while my brother's (windows) computer is on
01:44:52 <Eddi|zuHause2> i think it has to do with smb/cifs, but i can't isolate/solve the problem
02:20:42 <SmatZ> in less than a hour, I am leaving to Holiday to biking in Norway... bye all! :)
02:31:19 <Eddi|zuHause2> at 5AM? that's an odd time...
02:33:48 <SmatZ> hopefully I am not a driver, we go by bus... so I will sleep later
03:49:10 *** ThePizzaKing has joined #openttd
05:45:27 *** roboman has joined #openttd
06:44:59 *** ThePizzaKing has joined #openttd
07:00:19 *** Vikthor has joined #openttd
07:29:00 *** Deathmaker has joined #openttd
08:36:19 *** ChanServ sets mode: +v tokai
08:37:57 *** Chris82 has joined #openttd
08:38:14 <Chris82> has this AllocateTown(); been replaced by something?
08:42:21 <Chris82> ah I just see it has been removed in r10755
08:42:28 <Chris82> but I don't really know what's the replacement for it
08:43:14 <peter1138> Town *t = new Town(); possibly
08:45:58 <Chris82> yep thx :) fixed it, found a town messed that one up
08:50:55 *** Maedhros has joined #openttd
09:00:45 <Rubidium> if only the author of that patch Chris82 had trouble with had listened... Chris82 would never had to ask this.
09:08:48 *** pPACO_BAN has joined #openttd
09:12:16 *** De_Ghost has joined #openttd
09:15:50 <Rubidium> Gekko: then there wouldn't be two functions that are virtually the same except for one or two lines
09:46:44 *** Progman has joined #openttd
10:00:22 <Ammler> something special changed since r10737?
10:00:44 *** Prof_Frink has joined #openttd
10:06:09 *** Nickman has joined #openttd
10:15:52 *** Prof_Frink has joined #openttd
10:35:44 *** pPACO_BAN is now known as Phazorx
10:37:21 <peter1138> Ammler: in 43 revisions, i'm guessing there must be some changes...
10:49:36 <Ammler> peter1138: just asked if we should update #openttdcoop server
11:07:07 <Phazorx> is there a reason why bridge and tunnel head tiles are flagged as "no pass zone" for RVs ?
11:09:48 *** XeryusTC has joined #openttd
11:13:26 <Phazorx> what kind of crashes?
11:20:13 *** De_Ghost has joined #openttd
11:56:16 *** Code601 has joined #openttd
12:15:52 *** simon444 has joined #openttd
12:16:10 <Eddi|zuHause2> Phazorx: have you ever seen a (2-way) tunnel that allowed overtaking?
12:16:33 <simon444> someone dropped a chair on my foot
12:16:48 *** Scuddles has joined #openttd
12:16:50 <hylje> chair throwing reaches to australia?
12:16:54 <Phazorx> Eddi|zuHause2: cant really say... it's hard to observe overtaking in tunnel
12:17:04 <simon444> my reflexes hit my hand forward
12:17:17 <Phazorx> but on one way i seen such things (trucks coming out in diffrent order than they come in)
12:17:33 <simon444> I hit some 8 year in front of me in the cheek
12:17:52 <simon444> the childs father then punched me in the jaw
12:18:17 <simon444> I think I have a bit of internal bleeding
12:18:32 <Eddi|zuHause2> *oooh* ... a bag of pity for simon444,,,
12:18:54 <simon444> I was hit about 25min ago
12:19:02 <simon444> thanks Eddi|zuHause2
12:19:44 <Eddi|zuHause2> well... i don't see how people on the other side of the world are supposed to help you...
12:23:24 <Eddi|zuHause2> go see a doctor?!?
12:23:54 <simon444> he isn't working right now
12:24:45 <Eddi|zuHause2> there's always emergency service somewhere...
12:25:49 <Eddi|zuHause2> and while you're at it, sue the guy...
12:25:57 <simon444> I think I'll call that Jewish emergency service
12:26:24 <simon444> it is the sabbath so they are in service
12:26:40 <simon444> now what is it called again?
12:27:15 <simon444> "Did you mean: hatzolah "
12:27:18 *** Deathmaker has joined #openttd
12:28:07 <simon444> Phazorx, wtf I am not after some militant group
12:28:44 <Phazorx> the word actualy means "civil consil" :)
12:29:21 <Phazorx> but they'll sure get the joke at jewish centre, on shabat day :)
12:31:05 <simon444> Hatzolah ("rescue" or "relief" in Hebrew)
12:44:44 *** Ammller has joined #openttd
12:54:14 <CIA-1> OpenTTD: truelight * r10781 /trunk/src/ (6 files in 2 dirs):
12:54:14 <CIA-1> OpenTTD: -Fix: ported more pieces to WinCE, so it compiles a bit more
12:54:14 <CIA-1> OpenTTD: -Fix: WinCE doesn't support console
12:54:14 <CIA-1> OpenTTD: -Fix: Set debug lvl4 when running a debug WinCE build (as you can't give parameters any easy way)
12:56:41 <hylje> isnt wince a bit.. old?
12:57:13 <TrueBrain> only if you don't know all the facts :p
12:57:52 *** simon444 has joined #openttd
13:01:28 <Nickman> how is the NewGRF site coming? :)
13:12:08 <simon444> <simon444> wow they are so helpful
13:12:09 <simon444> <simon444> they came to my home to check out my jaw
13:12:09 <simon444> <simon444> they said if I start getting pain in 4-6 hours to go to get it xrayed
13:12:09 <simon444> <simon444> they didn't take my donation
13:12:45 <simon444> <simon444> the childs father then punched me in the jaw
13:28:10 *** De_Ghost has joined #openttd
13:41:57 *** Wezz6400 has joined #openttd
13:47:56 <simon444> I am feeling really sick
13:48:28 *** Ammller has joined #openttd
13:51:55 <CIA-1> OpenTTD: truelight * r10782 /trunk/src/video/win32_v.cpp: -Fix: wrongly places #endif a long time ago broke WinCE compiling for sure
14:34:19 *** Thomas[NL] has joined #openttd
14:44:18 <peter1138> 13:53 < hylje> isnt wince a bit.. old?
14:44:35 <peter1138> yeah, so is windows, linux, bsds, os x...
14:48:47 *** Ammller has joined #openttd
14:49:12 *** skidd13 has joined #openttd
14:52:02 <Wolf01> TrueBrain, could you emulate also the battery usage with OTTD? this night i had a power consumption of 50% after closing OTTD, i hope it don't forget open threads, else i need to soft reset every time
14:59:44 <TinoDidriksen> ...if you exit a program it is the OS' job to clean up such things.
15:00:23 <Wolf01> with MS OSes could happen anything
15:00:58 <simon444> they buy crappy ones
15:01:21 <simon444> so far they haven't released any of their own oses
15:01:40 *** Ammlller has joined #openttd
15:02:12 <Wolf01> this is not the first time it happens, last time happened with a wardriving tool which i uninstalled
15:04:47 <TinoDidriksen> Uninstalling can leave behind stuff, sure. But if your taskman says OTTD is not running, then it is not running.
15:11:18 <Wolf01> ok, before OTTD the power meter said 280-300mA, after is stable over 340mA
15:13:16 *** Ammlller has joined #openttd
15:14:48 <Priski> Markus Schulz - First Time, nice song, reminds me of first time of being with woman first time :)
15:15:09 <Priski> recomment to all trance addicts :)
15:17:02 <Priski> and now everybody thinks that I am an freak... no big loss though...
15:22:20 <TrueBrain> Wolf01: when you close down OpenTTD normally, it closes all threads and stuff
15:29:47 <Nickman> TrueBrain, how is the NewGRF site coming along?
15:29:50 *** skidd13 has joined #openttd
15:29:54 <TrueBrain> Nickman: which site?
15:30:22 <Nickman> wern't you making a site to organize all the GRF's that need to be done and stuff?
15:33:22 *** Wolf01 is now known as Wolf01|AWAY
15:35:53 <Nickman> not really, hav'nt even seen that thread :D
15:36:43 <Nickman> I thought truebrain was working on someting to organise the making of 32 bpp sprites, but I could be mistaken :D
15:37:32 <TrueBrain> but I don't have the time
15:37:41 <TrueBrain> and nobody seem to want to pick it up
15:38:00 <Nickman> what do you have at the moment?
15:38:20 *** skidd13 is now known as Skidd13|away
15:38:40 <TrueBrain> <html><head></head><body></body></html>
15:39:01 <TrueBrain> yeah, I like to have things efficient :p
15:39:10 <TrueBrain> no, the problem is that I have no clue what artists need
15:39:29 <TrueBrain> and I don't have the time to find out :p
15:39:37 <Nickman> I would like to help if possible... :)
15:39:50 <TrueBrain> sure: figure out what is needed :p
15:40:02 <Nickman> but what do you mean by that?
15:40:15 <TrueBrain> we can make a long list with current graphics
15:40:19 <TrueBrain> and tell people: make 32bpp
15:40:22 <TrueBrain> but that will result in a disaster
15:40:26 <Nickman> are you talking about website features?
15:40:27 <TrueBrain> there need to be guidelines
15:40:42 <TrueBrain> the website is, what, 10 hour work?
15:40:53 <Nickman> depends on what you wan't to build ofcourse ;)
15:41:04 <Nickman> could be from 10 minutes to 10 days :D
15:41:14 <TrueBrain> what I think we need, takes me about 10 hours
15:41:23 <TrueBrain> I mean, you might do it in 10 minutes to 10 days :p
15:41:30 <Nickman> I think a list of what sprites are currently in the game is necessary
15:41:39 <TrueBrain> yeah, that is no problem, I have that list
15:41:49 <Nickman> with screens of the sprites to?
15:42:06 <TrueBrain> even with xoffs and yoffs
15:42:11 <TrueBrain> anyway, my biggest problem
15:42:19 <TrueBrain> is that we need a checklist of some kind
15:42:25 <TrueBrain> which 32bpp need to follow
15:42:32 <TrueBrain> like: light-direction, detail, size, ...
15:42:34 <Nickman> so if you make a system where people can upload their creations, and you can view thems ide by side and choose the best one?
15:42:52 <TrueBrain> that basicly is what I have in mind yes
15:42:57 <TrueBrain> with some kind of voting system maybe
15:42:59 *** Frostregen_ has joined #openttd
15:43:06 <TrueBrain> possibility to see more of the same author
15:43:17 <TrueBrain> login/register for artists
15:43:44 <Nickman> you might need to make some ristrictions that artist have to submit a full set of something
15:43:44 <TrueBrain> a nice piece of text that tells them that if they upload anything, it immediatly falls under the license of OpenTTD Developer Team
15:43:59 <TrueBrain> I do not really care if they upload one sprite or many sprites
15:44:55 <TrueBrain> I mean: one sprite of one artists can be 10 times better than 100 sprites of an other artists
15:44:59 <Nickman> so, what else do you need? :)
15:45:07 <TrueBrain> that really is my biggest problem
15:45:25 <TrueBrain> also, the upload should not only upload the png, but also the source file of which ever program is used
15:45:26 <Nickman> but you won't be using one grass tile from one artist and another one with different slope from another one will you? :D
15:45:37 <TrueBrain> most likely not, no
15:45:40 <Nickman> that isn't to hard :)
15:45:57 <TrueBrain> as said, the website itself is really easy
15:46:06 <TrueBrain> but just making the website doesn't make the 32bpp to work
15:46:08 <Nickman> and the guidelines, is that like you have to use these colours or thesematerials?
15:46:22 <TrueBrain> I am no artist, so I have no idea what needs to be defined
15:46:32 <TrueBrain> to make sure the quality of the sprites is good enough
15:46:39 <Nickman> we could ask in the 32bpp blender thread (or make a new one... :))
15:47:36 *** Skidd13|away has left #openttd
15:47:38 <Nickman> Wan't me to make a thread? :)
15:48:36 *** Frostregen_ is now known as Frostregen
15:48:37 <TrueBrain> please do; yesterday I also talked to _Ben_; he wanted some clearification too.. we need someone to 'lead' this 32bpp stuff forward, so I won't stop you :p
15:51:49 <peter1138> what is all this misuse of apostrophes?
15:52:06 <Nickman> I'll see what I can make up ;)
15:52:42 *** ChanServ sets mode: +v tokai
15:52:52 <peter1138> "wan't" "hav'nt" "you'r" ...
15:54:20 <ln-> that should no't be tolera'ted.
15:55:01 <TrueBrain> sorry we all aren't as perfect as you are :D
15:55:20 <peter1138> TrueBrain: you can shut up, you get them right :p
15:55:44 <TrueBrain> peter1138: I refuse to put myself under the same group as you :p
15:56:46 <ln-> let's say peter1138 is one of the "devs" group, and you are one of the "dev's" group. happy?
16:11:08 <simon444> * ChanServ gives voice to tokai
16:11:20 <simon444> ChanServ isn't even here
16:11:31 <simon444> tokai must be a witch
16:13:20 <Sacro> but how do you know he is a witch?
16:13:43 <ln-> ChanServ is, that's for sure.
16:13:54 <simon444> Sacro, you must also be one!
16:14:05 <Sacro> but i weigh more than a duck
16:14:07 * simon444 pours petrol around Sacro
16:15:09 * simon444 throws a match towards Sacro
16:15:24 <simon444> woho, Sacro is burning!
16:15:36 <simon444> Now we can all start to talk about sex
16:17:54 <peter1138> # let's talk about sex, bay bee
16:18:21 <simon444> I think we could turn this into a game
16:18:57 <Sacro> int main (int argc, char *argv[])
16:25:49 <Nickman> The site will be for 32 bpp graphics only TrueBrain? :)
16:27:39 <TrueBrain> Nickman: a big fat yes
16:27:50 <peter1138> i'd imagine so. 8bpp artists seem to be capable of managing by themselves
16:31:44 <simon444> okay any ideas for what do add to my mash potato?
16:32:02 <simon444> I have Balsamic vinegar
16:32:30 <simon444> other than that the stuff I have is pretty ordinary
16:35:07 <simon444> SpComb, heh, thanks but I can't eat eggs as they are icky
16:37:42 <simon444> TrueBrain, you must be a witch
16:37:49 <simon444> SpComb, don't have any
16:38:09 <TrueBrain> simon444: you are weird
16:38:12 <simon444> maybe I should add some oil and fry them into balls
16:45:58 <simon444> what a useless channel
16:46:08 <simon444> can anyone recommend me a useful channel?
16:46:48 <simon444> (better not be one of those autoban from the server channels)
16:53:28 <simon444> when is the next/last nightly build?
16:54:15 <peter1138> 8pm in some timezone
16:54:58 <simon444> peter1138, what time zone?
17:01:31 *** Digitalfox_Notebook has quit IRC
17:13:57 * simon444 put bbq source and parsley in his mash potato
17:14:28 <glx> nightly download page tell it
17:15:24 <DaleStan> And, for those of who don't know the current GMT offset for CEST?
17:17:27 <DaleStan> So why can't the page just say "22:00:06 GMT", like every other timestamp on *.openttd.org?
17:17:51 <glx> because the compile farm is on a server with CEST time
17:17:59 <simon444> Fri Aug 3 20:00:03 CEST 2007
17:18:00 <glx> and that is not modifiable
17:18:30 <glx> TrueBrain would like to have it in UTC though
17:18:32 <simon444> glx, so just convert it
17:18:57 <DaleStan> And the rest of the servers are all on UTC? Why does that matter? My computer is quite capable of generating UTC timestamps, despite being 4 or 5 hours off, depending on the time of year.
17:19:54 <simon444> Google, time in cest doesn't work!
17:20:06 <simon444> Google, time in nyc works.
17:20:59 <simon444> so another 3 hours till another build
17:23:12 <simon444> and another 2 hours for it to complete?
17:23:34 <simon444> glx, which box do I make sure not to visit in order not to slow down the compile?
17:26:08 *** RichK67 has joined #openttd
17:26:47 <CIA-1> OpenTTD: richk * r10783 /branches/NewGRF_ports/ (11 files in 4 dirs):
17:26:47 <CIA-1> OpenTTD: [NewGRF_ports] -Feature: Added placing FSMport in any of up to 4 different orientations. GUI now has a preview image for each orientation - not interactive, just a screenshot stored.
17:26:47 <CIA-1> OpenTTD: Next to modify the vehicle movement to account for the station orientation. Need to add saveload ability.
17:26:47 <CIA-1> OpenTTD: Commuter Airport rb_airport2.grf now includes 2 orientations.
17:26:49 <CIA-1> OpenTTD: airports.grf modified to include direction arrows.
17:28:35 <simon444> RichK67, just in time. glx is about to start compiling the nightly
17:28:39 <RichK67> i discovered that you only need one finite state machine to cope with all 4 orientations
17:29:01 <glx> simon444: it's an automatic process and I'm not responsible for it
17:29:03 <RichK67> but you needed 4 graphics layouts... the rest is maths
17:29:42 <simon444> glx, I thought you compile it by hand
17:30:48 <RichK67> simon444: this isnt in trunk/nightly... its being developed in a branch, for merge later
17:30:57 <RichK67> lots of problems to solve yet
17:31:33 <simon444> RichK67, oh that sucks
17:32:06 <simon444> is there anywhere I could see the last patches submitted?
17:32:07 <RichK67> minor little one of cant save it atm, and cant load an existing game... other than that, its great ;)
17:32:24 <simon444> RichK67, nightlys are meant to be broken!
17:32:56 <simon444> RichK67, the one I used the other night was
17:33:46 <RichK67> ah, but that is the rare exception... the aim is always to have nightly as stable or better than last release (since it has latest bugfixes)
17:35:25 <simon444> nightlys are just bug fixes
17:51:43 *** simon444 has joined #openttd
17:52:17 <simon444> okay who thought that was funny?
17:52:45 <simon444> to reboot my machine?
18:02:56 <simon444> YOU SON OF A BITCH, You must be a witch! (sorry capslock)
18:20:15 <simon444> who wants to play a team game with me?
18:21:01 <simon444> Rexxie, how about you?
18:21:18 <Rexxie> I'm busy writing an angry letter to air france
18:22:29 <simon444> Rexxie, I have written many such letters
18:24:24 <simon444> Rexxie, I can increase your success rate
18:24:41 <simon444> Is this air france in ottd?
18:26:03 <simon444> glx, how long till the nightly is complete?
18:27:38 <RichK67> its like a boiling kettle.... the more you watch it, the longer it takes... ;)
18:32:12 <simon444> I want to know to download fridays or if I should wait a little bit
18:33:09 *** Kittysune has joined #openttd
18:33:56 <RichK67> check the website - it tells you when it is run
18:34:50 *** UnderBuilder has joined #openttd
18:35:18 <simon444> RichK67, it is being ran right now
18:47:22 <simon444> anyone want to play???
18:50:01 *** Wolf01|AWAY is now known as Wolf01
18:51:14 <Wolf01> RichK67, i have an old idea for you, you might be interested
18:51:52 <simon444> then bombed all the houses
18:52:00 <simon444> then went to start an industry
18:52:11 <simon444> and it gave me the error need to build a town first
18:52:35 <RichK67> hi Wolf01... fire away
18:53:05 <Wolf01> do you remember my idea (and Frostregen's patch) about eyecandy?
18:53:26 <simon444> I expanded it and bombed everything but one house
18:54:11 <simon444> I expanded the town fours times
18:54:18 <simon444> and left one of the outer house
18:54:48 <simon444> I did this again only expanding one time and leaving the outer house and it has a population of 13!
18:54:55 <RichK67> Wolf01: yeah, i thought it was effectively superceded by action0houses
18:54:56 <simon444> 13 buggers in one house!
18:55:13 <Wolf01> the idea is to extend that patch to load eyecandy objects from grf, but also to have "active" eyecandy, such houses generating passengers to build your own city, and maybe to build industries
18:56:08 <RichK67> Wolf01: very useful in scenario building... not so sure it would be ok in network though
18:56:32 <simon444> okay this is a real bug: I have a town with 13 pop and it still says must build town before can place coal mine
18:57:06 <RichK67> simon444: write them down, then submit them with savegames to Flyspray
18:57:20 <simon444> I have a town with 1433 and still can't start a coal mine
18:57:32 <RichK67> in other words... less running commentary ;)
18:57:41 <simon444> RichK67, would you just try it out
18:58:01 <Wolf01> yes, that is not a problem, the eyecandy objects now are a sprite replacement for the purchased land, for complex things the editor should be the right place
18:58:14 <RichK67> nope - im busy writing airport FSM rotation
18:58:31 <simon444> RichK67, I started a new game and the same problem
18:58:44 <simon444> I think this is a proper bug
18:59:02 <simon444> RichK67, so much for nightly being stable
18:59:03 <RichK67> then submit it with savegame to bugs.openttd.org ... aka Flyspray
18:59:54 <RichK67> i said... "as stable or better"... of course, new features introduce new bugs.... give us the full info, and it will be looked at
18:59:57 <simon444> RichK67, I have to registered
19:00:11 <RichK67> so register.... its automatic i think
19:00:53 <simon444> 4) error - need to build town first
19:01:26 <RichK67> last time i say this: submit it to bugs.openttd.org....
19:03:28 <simon444> never mind - making a random town isn't bugged
19:03:54 <simon444> RichK67, I am not going to register and this is such a basic bug that someone else will submit it
19:04:33 <Wolf01> it should allow guest submissions
19:04:54 <Phazorx> i think simon444 got more stubborn after being hit in the head
19:05:12 *** skidd13 has joined #openttd
19:09:31 <Wolf01> but you can always register, you might need it in a later time, it doesn't bite, like me
19:15:08 <simon444> Wolf01, is that a requirement of GPL4?
19:17:30 <RichK67> simon444: one question... how close to the town did you try to build the mine? if a long way away, you could be outside its radius
19:18:12 <simon444> I tried all different town sizes
19:18:12 <RichK67> and radius is related to population... so pop=0, no radius
19:18:29 <simon444> my random town has 0 pop
19:18:49 <simon444> and is about 700 blocks away from my coal mine
19:20:56 <Wolf01> i can feel smell of no-bugs
19:22:58 <simon444> glx, well it is working at 700 blocks
19:23:04 <simon444> but only if it is a random town
19:23:14 <simon444> regular towns of any size are broken
19:25:13 <glx> it needs at least one random town
19:36:10 <Rubidium> people not being registered when they post a bug makes it virtually impossible to ask addition questions to the bugsubmitter
19:37:59 <Phazorx> Rubidium: yesterday desyncs
19:38:09 <Phazorx> it is sort of reproducable in 14 game days
19:38:26 <Phazorx> but doesnt wotk every time (gotta be right half of day as well i guess)
19:38:47 <Rubidium> that isn't difficult ;)
19:38:55 <Rubidium> just send a pause command at the right moment ;)
19:39:04 <Rubidium> it's like two lines of code
19:39:11 <Phazorx> that's what i was trying but still i get it like every other time
19:39:19 <Phazorx> not sutre what esle is a faktor
19:39:53 <Phazorx> and another thing, server start date is aug01,
19:40:22 <Phazorx> client that join before aug 13-14 desync at 14-15
19:40:43 <Phazorx> client joined before aug 11-12 do not desync
19:41:02 <Phazorx> but pretty much all client who have not desync earlier will desycn at Oct 13
19:41:11 <Phazorx> is that same bug or 2 different ones you think?
19:41:11 <simon444> is there any undo button?
19:41:19 <simon444> I just fucked something up
19:41:32 <Rubidium> hopefully the first ;)
19:41:37 <simon444> and saved a bit to early
19:42:10 <simon444> Rubidium, eeew that would be my wife if anything...
19:42:39 <simon444> there is no undo command in the terminal
19:43:22 <simon444> Rubidium, is there a way of undoing or should I just go back to my last save?
19:45:12 <simon444> the silence is killing me
19:45:20 <simon444> someone say something
19:45:54 <simon444> it I am just loading my last save
19:57:19 <Xintron> Spider pig, spider pig, does whatever a spider pig does. Can he swing from a web, no he can't he's a pig. Lookoooooooout he is a spider pig!
19:58:51 <simon444> what year does electric rails come?
20:03:01 <Sacro> hmmm, sh4un.co.uk is no longer the first hit for spiderpig
20:05:19 <alex_> offtopic: whats a good flash editor?
20:05:56 <Rubidium> really, who wants flash?
20:06:09 <Rubidium> I've seen someone trying to do debugging in it and it was awful
20:06:53 <Rubidium> function does not exist, don't care, I'll just make it return 0 or false whatever you want as return value type
20:07:08 <Rubidium> or at least something like that, don't remember exactly
20:07:40 <Phazorx> it ingonres duplicate function definiton
20:07:43 *** Prof_Frink has joined #openttd
20:07:59 <Phazorx> and if they are on different layers - can call one or another clsoe to random
20:08:20 <Phazorx> sloping is broken to in some nested case
20:14:22 <Rubidium> Phazorx: got that savegame for me?
20:14:31 <Rubidium> the desyncing one that is
20:15:10 <Phazorx> trying to find definitive pattern here... but i guess we both can do same with more efficiency
20:16:16 <Rubidium> that gives annoying filenames when you download stuff
20:17:34 <Rubidium> and my computer is kinda running out of cpu power at the moment :(
20:18:33 <simon444> alex_, porting ottd to flash so the little kiddiez play with it?
20:19:56 <Phazorx> somewhere around 13th is the even that causes desync on 14th
20:26:47 <simon444> alex_, think of the ad money!
20:26:59 <simon444> too bad you will have to open source it
20:27:10 <simon444> then I can just steal it and make the ad money
20:28:57 *** Wezz6400 has joined #openttd
20:46:38 <Rubidium> Phazorx: that game is way too big for my computer to be able to find the cause of the desync
20:46:50 <Rubidium> it takes more than 10 seconds to do one day :(
20:47:03 <Phazorx> you only need 15 days...
20:47:33 <Rubidium> and I need to do that a lot of times
20:48:05 <Phazorx> well that's the best i can do i'm affraid
20:48:42 <Rubidium> can't you stop some groups of vehicles and still get the desync?
20:48:55 <Phazorx> if i'd have guaranteed way to get the desync i;d try to stop some
20:49:04 <Phazorx> well if i stop all - no desync
20:51:40 <simon444> is this a new feature
20:52:29 <Phazorx> chris made the game this way
20:53:41 <Phazorx> Rubidium: can you trace the cause of desync somehow?
20:54:17 <Phazorx> i mean i can disable groups if i know how exactly to cause it
20:54:21 <Rubidium> but it requires incrementally adding more debug output till you find the origin of the desync
20:54:41 <Phazorx> currently there us a high chance of desyncing but i'm not getting it every time for some reason
20:54:42 <Rubidium> which means rerunning it a lot of times
20:55:00 <Rubidium> and having a guaranteed desync is a must
20:55:18 <Phazorx> well i need soemthing mroe granular than a date then
20:55:35 <Phazorx> is there a way to get tick count, or even better freeze at particular tick?
20:55:41 <Rubidium> and you must always hit the same desync, otherwise your incremental search back into "history" does not work
20:56:11 <Phazorx> hence my question... cuz i know there are more than one instance that causes it
20:58:18 <Rubidium> and: if (_tick_counter == <<magic value>>) DoCommandP(0, 1, 0, NULL, CMD_PAUSE); in for example IncreaseDate
20:58:28 <Rubidium> Phazorx: yes, it's a variable
20:59:27 <Rubidium> RichK67: would you be so kind to commit airports.grf as I suspect you've got a local modification in there that is needed to be able to build airports.
20:59:31 <simon444> Phazorx, which chris
20:59:41 <simon444> I am going to kick his butt
21:03:09 * Rubidium guesses Phazorx is talking to someone who is on my irc client's ignore list
21:03:35 <Phazorx> i tihnk you made the right choice there mate :)
21:08:27 <RichK67> Rubidium: it should have gone up with the last submit
21:09:28 <RichK67> yup, r10783... first item in list
21:09:45 <Rubidium> oh, then you forgot to update files.h ;)
21:10:08 <Rubidium> and it doesn't explain the crash when opening the build airport window
21:10:20 <Rubidium> without having any newgrf loaded
21:10:40 <RichK67> yeah... it will eventually be 100% newgrf... dont try it withotu
21:12:41 <RichK67> ill bother about MD5ing it once development (and mods to airport.grf are finished)
21:13:18 <Rubidium> can't find the hangar of the rotated commuter, is that a know issue?
21:13:57 <RichK67> read the commit message... only placement has been done (except i have it working locally on my pc :) )
21:15:11 <Rubidium> are you aware of any deadlocks in the normally oriented commuter?
21:16:00 <RichK67> same FSM anyway... its only the graphics that shift for rotation
21:17:02 <RichK67> i have a const... and want to pass one of its values to be used in a routine that expects a non-const as input... how do i do it... it keeps whining
21:17:03 <Rubidium> plane in souther and middle terminals, plane circling to land, planes in depot try to go to a terminal and a plane just before the depot with it's nose to SW (would need to rotate 90 degrees clockwise if it goes into the depot)
21:17:23 <Sacro> RichK67: pass by reference?
21:17:28 <RichK67> take a screenie... saves are useless
21:17:38 <RichK67> i would like to sacro... it still whines
21:18:45 <Rubidium> RichK67: depends on whether the function actually needs the variable to be non-const
21:18:54 <simon444> fuck openttd crashed!
21:19:14 <Rubidium> the ugly way would be just casting it to a non-const version
21:19:26 <Rubidium> but that might make the compilers do wrong things with it
21:20:12 <Rubidium> RichK67: what you miss in that screenshot is the aircraft flying around to land (must have taken the image at the wrong time
21:20:19 <RichK67> sorted it anyway... it works now :)
21:21:41 <simon444> is there any dumps i should send in
21:21:54 <simon444> I think I know what is causing it
21:22:23 <RichK67> Rubidium: can you check if the the one outside the depot is heading to hangar?
21:23:13 <simon444> yep confirmed the problem
21:23:29 <simon444> creating the 26th train = crash!
21:23:31 <RichK67> ok, ill throw a ton of a/c at it... problem will be in the state machine, not the controller (i hope)
21:25:26 <Rubidium> hmm, it looks like once all aircraft have taken off, there can only be one aircraft at the ground
21:26:33 <simon444> RichK67, what info should I give for my bug?
21:26:39 <Rubidium> unless an aircraft goes into the depot, as then a second can land
21:28:22 <RichK67> Rubidium: somethings gone screwy there... ive not yet seen it in my tests, and unfortunately i need to see what it was prior to the blocks getting set... something is set, and has not got cleared.
21:28:51 <simon444> RichK67, bug not present in a slightly older build
21:29:02 <simon444> what info should I put in my report
21:29:23 <simon444> or should I just wait and see if it is still there in a few days from now
21:31:16 <Rubidium> it's fairly easy to reproduce: (well, what I've done)
21:31:53 * simon444 thinks he is being ignored :(
21:32:39 <Rubidium> start a game in 2010 with only the NewGRF FSM airport grf, build a commuter in the original direction and a commuter in the other direction adjacent to the airport (press CTRL)
21:33:29 <Rubidium> then build two of the cheaper (second) aircraft, give the first orders to go from the first to the second airport, start that, clone the orders of the first for the second aircraft, start that aircraft
21:34:18 <Rubidium> cheat to get money, clone one aircraft and clone that one 7 times (button where the go-to-depot button is when not in the depot) (so you've got 10 aircraft), then start all of them at once (green flag)
21:35:08 <glx> RichK67: would be nice to fix all warnings in newgrf_fsmports.h
21:35:34 <RichK67> would be if i had any
21:35:50 <hylje> Rubidium: clone one aircraft 7 times produces ten aircraft?
21:38:06 <RichK67> glx: i get no warnings at all...
21:39:48 <RichK67> glx: check out newgrf.cpp line 2103. the three "not used" entries are used there
21:44:21 <glx> but as they are static they are "defined" in all cpp that includes newgrf_fsmports.h I think
21:45:10 <RichK67> they will be dying later, as i wont need that way of instantiating once the predefined old airports are removed
21:45:40 <RichK67> but fine, spend time fixing stuff that is going to be deleted ;)
21:45:58 <peter1138> simon444: version, problem, savegame, steps
21:46:31 <Rubidium> RichK67: all those warnings make you miss other warnings that might be important
21:46:47 <Rubidium> like /home/rubidium/openttd/ports/src/aircraft_cmd.cpp:1094: warning: taking address of temporary
21:47:08 <simon444> my first 10 trains are not servicing and have had 30 break downs since last service
21:47:41 <simon444> I have deports on the route
21:48:09 <Rubidium> what basically happens is that some struct is pushed on the stack, then the address of that is stored in amd and then the struct is popped from the stack
21:48:23 <simon444> they are breaking down so much that my newer trains are claiming they are lost
21:48:36 <Rubidium> which means that anything that pushes something on the stack corrupts your data
21:49:17 <RichK67> ok, so how do i get to see these warnings then...
21:49:38 <Rubidium> you don't as they are generated by gcc
21:49:57 <Rubidium> and neither MSVC nor gcc is superior in the generated warnings
21:50:20 <RichK67> Rubidium: cant reproduce your error - followed to the letter.... 10 perfectly flying aircraft
21:50:20 <Rubidium> the union of the warnings generated by both compilers is much more interesting
21:51:48 <Rubidium> RichK67: it could be caused by the beforementioned issue
21:52:19 <RichK67> so maybe MSVC is compiling the problem away
21:53:07 <Rubidium> maybe it pops it later
21:53:15 <Rubidium> are you running a debug or release binary?
21:54:44 *** Darkebie has joined #openttd
21:56:12 <Phazorx> hwo do i revert to stock from applied patch in svn ?
21:56:26 <RichK67> Rubidium: i think ive fixed it.... ill diff, and pastebin
21:56:41 <Phazorx> peter1138: no revision needed?
21:57:28 <DaleStan> That'll revert to whatever revision happens to be local, Phazorx. To change revisions, use svn up instead.
21:57:54 <Phazorx> DaleStan: got that one
21:58:32 <RichK67> hmmm.... inconsistent newlines again
21:59:52 <RichK67> weird... all of todays edits have used LF, not native CRLF
22:02:35 <RichK67> amd_original is only used there, and is unnecessary... try this instead
22:03:37 <RichK67> nothing looks deadlocked there... that can be a normal position... which a/c is the problem
22:04:02 <Rubidium> RichK67: they are all stationary/non-moving
22:04:36 <Rubidium> and that patch won't solve the issue as the issue is the &RotateAMDbyRotation()
22:05:30 <Rubidium> i.e. getting the pointer of the return value without keeping the return value
22:06:33 <RichK67> hmmm... i get way confused on when to use which... oh well... back to "hello world"
22:07:01 <RichK67> Rubidium: can you apply your diff, ill scrap my mod
22:07:19 <Rubidium> I'll apply your change over mine
22:08:44 <RichK67> i cant see any visual reason why those arent moving right
22:11:12 <RichK67> im laying money on the MSVC / gcc difference.... its working perfectly here
22:11:44 <Rubidium> the rest of the warnings remaining for newgrf ports are unused variable/function warnings which I'll just ignore for now as you might need it in one of the upcoming patches.
22:13:38 <RichK67> ive got 18 a/c zipping around having great fun... no sign of a lock here
22:14:05 <Rubidium> here a deadlock is a sure thing :(
22:14:09 <Phazorx> why can i not use "many random industries" in scenario editor?
22:14:20 <Phazorx> build button is greyed out
22:16:17 <Rubidium> because you don't have a town yet?
22:18:38 <Rubidium> I can't reproduce it
22:19:09 <Phazorx> Rubidium: can not reproduce what ?
22:19:43 <Rubidium> the greyed out button
22:20:02 <Phazorx> perhaps that's GRFs i have ?
22:20:29 <glx> Phazorx: I have a pending fix for that
22:20:59 <Phazorx> ahh... and in mean time?
22:21:11 <peter1138> in the mean time, ignore it
22:21:22 <Phazorx> shoyuld be before that issue
22:22:20 <Rubidium> ah, I finally reproduced it
22:23:01 <Rubidium> you've got the difficulty setting industries set to none
22:23:25 <Rubidium> which makes the random industry building build none
22:23:29 <RichK67> Rubidium: debug build or release build, and i cant reproduce your bug... can i leave you to hunt it? (state machine in rb_airport2.grf is probably ok... look elsewhere first)
22:24:09 <Phazorx> Rubidium: does that preference option controls random in game building ?
22:24:27 <Phazorx> cuz only reason i was setting it to none to avoid industries building later
22:24:42 <Phazorx> is there a way to disable/conrol that ?
22:25:12 <peter1138> you can probably write a newgrf to do it
22:25:22 <Rubidium> yes, as peter1138 said
22:25:23 <peter1138> although you won't be happy when all your industries have closed down
22:25:48 <peter1138> maybe that is newgrf controllable, i don't know.
22:26:04 <Phazorx> hmm... i'd rather have it as game option tho
22:26:22 <Phazorx> kidna makes more sense since that is engione behavior rather thana mod to content
22:26:32 <Nickman> TrueBrain you here? :p
22:26:41 <Phazorx> peter1138: with prospering enabled that is not an issue
22:26:53 <Phazorx> and i'd like to be able to disable all industries for pax only games
22:27:17 <Phazorx> as well as disabel building powerstations and any other second tier when it is not needed
22:28:59 <CIA-1> OpenTTD: rubidium * r10786 /branches/NewGRF_ports/src/aircraft_cmd.cpp: [NewGRF_ports] -Fix: do not get a pointer of memory that might get overwritten and assume it is correct; just keep the returned struct as-is.
22:31:52 <RichK67> btw, Rubidium. does your problem happen with unadjacent airports?
22:33:22 <Rubidium> the aircraft before the depot is waiting on "something"
22:39:57 <RichK67> when it happens, pause, put a breakpoint on aircraft_cmd.cpp:1908, and then check the heading, position, v->u.air.owned_blocks, and st->airport_flags.... i expect st->airport_flags to have upper_block = 0000001 .. ie runway blocked .. if it isnt i have no idea
22:41:13 <RichK67> Rubidium: it may be worth you checking my coding of fsmblockmap ... i could well have made one of these weirdo stack references
22:41:34 <RichK67> of course, doesnt explain why MSVC works
22:41:51 <Rubidium> RichK67: it looks ok to me, though it leaks some memory
22:42:59 <RichK67> anyway, do you like the gui?
22:47:11 <RichK67> what should we do about the old buttons? should we keep the standard OTTD airport buttons, but hot-wire them to an ottd_newgrf_standard_airports.grf??
22:48:59 <peter1138> use whatever new gui you're doing
22:49:08 <peter1138> like the fund industry gui did
22:50:01 <RichK67> so all airports to be loaded via newgrf... and hardcode in a load of a default newgrf?
22:51:35 <Eddi|zuHause2> what does the GUI have to do with how they are loaded?
22:51:54 <Rubidium> RichK67: v[05]: 0000000400000000, s[00]: 0000002c0000000e
22:52:08 <RichK67> indexed to different structures
22:52:18 <Rubidium> first are upper,lower of vehicle, second of the station
22:52:29 <Rubidium> that's the one before the depot
22:53:24 <RichK67> block 40 looks clear....
22:54:51 <Rubidium> v[01]: 0000002800000002, s[00]: 0000002c0000000e
22:54:57 <RichK67> you'll need to step through, trying to catch its movement, and watch the block states change.... i cant imagine why its happening... the state machine is doing the right things (its got pretty simple now)
22:54:59 <Rubidium> that's the one waiting at the top
22:55:27 <Rubidium> it holds quite a few blocks
22:55:46 <RichK67> ill add saving, and then you can send a game... :)
22:57:25 <RichK67> at least we know the adjacent is a red herring
23:03:23 <Rubidium> where do those block bits relate to? to the positions?
23:06:33 <RichK67> lower blocks 0x00-0x3F are terminals etc, upper 0x40-0x7B are "open" blocks.... and can represent anywhere you need a block
23:07:07 <RichK67> you'll need to compare with the state machine in rb_airport2.nfo
23:08:02 <Rubidium> oh, I didn't add enough zeros to those strings :(
23:08:17 <Phazorx> hmm... hard crashes with nothing in debug
23:08:23 <Rubidium> and your 40 was in hex
23:08:34 <Phazorx> last line "dbg: [misc] [Pool] (CargoPacket) cleaning pool..
23:08:43 <Rubidium> debug is not for hard crashes
23:08:55 <RichK67> position 01 should move to position 0B if block43 is free... 43 is 0000....0004, so yes it has the block, is looking for the block...
23:09:49 <Phazorx> was not starting dedicated.. and guess what happens if the box doesnt have X
23:10:23 <RichK67> definitely check out HasBlocks and BlocksAreFree... i suspect you may catch it doing something odd around a/c_cmd:1936
23:12:42 <RichK67> one thing to check... does any other aircraft have block 43 as well?
23:14:00 <RichK67> cant see why it doesnt pass this then: if (st->airport_flags.BlocksAreFree(¤t->reserveblock) || //if can reserve blocks
23:14:00 <RichK67> v->u.air.owned_blocks.HasBlocks(¤t->reserveblock)) { //or vehicle already has blocks
23:14:22 <RichK67> first clause should be false, second true
23:15:43 *** Brianetta has joined #openttd
23:16:20 <RichK67> thing is, i really cant understand why its ok here....
23:17:52 <Rubidium> v[07]: 00000000000000040000000000000000, s[00]: 000000000000002c000000000000000e
23:18:09 <Rubidium> with that state it should go into that branch?
23:18:34 <RichK67> check state and heading
23:18:42 <RichK67> state should be 41 takeoff
23:19:27 <RichK67> heading (ie. entry in FSM command) should also be 41
23:19:54 <RichK67> when stopped on line 1936
23:22:49 <Rubidium> v[ 1]: 1936. r: 00000000000000080000000000000000, h: 65
23:23:29 <RichK67> with block 0x42 occupied... looks A1
23:23:35 <Rubidium> and no blocks to reserve
23:24:09 <Rubidium> oh, one block to reserve ;)
23:24:26 <Rubidium> there's an 8 in there
23:25:06 <RichK67> should be (hex)... heading=41, reserve=block43, release=block42, next_pos=0x0B
23:25:42 <RichK67> and i would guess, holding block42
23:25:59 <Rubidium> v[01]: 00000000000000040000000000000000, s[00]: 000000000000002c000000000000000e
23:26:22 <RichK67> im totatlly confused now
23:27:10 <Rubidium> the vehicle is holding block 42, the station has blocks 42 and 43 and 45 set
23:27:14 <RichK67> nope, 43... bah... too late to do 128 bit binary
23:27:47 <RichK67> did any aircraft takeoff and land?
23:28:05 <Rubidium> all the time, but the last plane that did that landed
23:28:36 <Rubidium> v[06]: 00000000000000280000000000000004, s[00]: 000000000000002c000000000000000e
23:29:01 <Rubidium> which has locked 43 and 45
23:29:04 <RichK67> thing is, as a protection against leaving an airport in a bad state, all a/c release all blocks they hold at exit, and zero all their holdings
23:29:36 <RichK67> so in theory, even if an aircraft leaves a bad block lingering, it should clean up on exit
23:30:18 <RichK67> 45 is the airport entrance next to the tower
23:30:51 <RichK67> (where it is i'd guess)
23:31:04 <RichK67> and it has reserved term3
23:31:21 <Rubidium> yes, waiting to get into the block to get into terminal "lane"
23:31:43 <Rubidium> s/the block to get into//
23:31:45 <RichK67> (and people want to automatically create their own plug-together airports... sheeshk!)
23:32:54 <RichK67> ah... sorry misread your lists
23:33:32 <RichK67> v1 is holding block42 only (correct), and wants (= r) block43... which the station says is not clear
23:33:53 <RichK67> so correctly, it waits
23:34:11 <RichK67> the problem is the unreleasing of some other aircraft... a/c 1 is just the victim
23:34:31 <Rubidium> aircraft #6 in this case
23:36:42 <RichK67> is it absolutely predictably repeatable ... ie. can you force #6 to be the problem again...
23:37:20 <Rubidium> it had block 43 and 44, then it took 45 and freed 44
23:37:25 <RichK67> we need to trace what happens as #6 moves from 01 to 0B and onwards on its takeoff cycle before it snafus it
23:37:58 <RichK67> the fault is that it should not have retained 43
23:38:29 <RichK67> it should be 100% clean coming in after its takeoff
23:40:06 <RichK67> block43 should have been released when it went from the tile next to the runway onto the runway for takeoff
23:40:28 <RichK67> and then if it still had it on exit, it should also have been cleared
23:41:00 <Rubidium> it gets bits 40, 43 and 44 all at the same time
23:45:00 <RichK67> Rubidium.... interesting... we have a good pointer there then
23:45:34 <RichK67> there is only one multi-block reserve, and it should be just 44 and 40
23:47:13 <RichK67> so, its probably the newgrf translator taking the block in incorrectly... newgrf.cpp:2286 ReadBlocksInto command
23:47:41 <Rubidium> hmm, some weird things seem to be happening
23:48:15 <Rubidium> I give you some stuff in the actual order it was executed:
23:48:17 <Rubidium> v[01]: 00000000000000180000000000000000, s[01]: 000000000000001c000000000000000c
23:48:20 <Rubidium> v[01]: 00000000000000280000000000000002, s[01]: 000000000000002c000000000000000e
23:48:23 <Rubidium> v[ 1]: 1936, res: 00000000000000200000000000000000, rel: 00000000000000100000000000000000, h: 0
23:48:41 <Rubidium> the reservation and release done after it has actually happened?
23:48:58 <Rubidium> or is there another place where reservations can be done?
23:52:39 <RichK67> about 4 locations: AirportMove is where 90%+ happen. only others are FreeTerminal (where it reserves the terminal), EnterHangar (where it clears all blocks it owns), and Flying (where it reserves the landing approach reserves)
23:53:03 <RichK67> oh, and EndTakeoff, where it releases everything again
23:54:35 <RichK67> can you check what blocks it is trying to reserve in the Flying step... it should be upper 00000000011 (ie. 40 and 44
23:56:16 <RichK67> if its 00000000000019, then we have our culprit
23:56:38 <RichK67> in the current->reserveblock.upper
23:57:20 *** Gekkko` has joined #openttd
23:57:47 *** Gekkko` is now known as Gekko
23:57:52 <Rubidium> 0, v[ 1]: 1936, res: 00000000000000190000000000000000, rel: 00000000000000000000000000000000, h: 68
23:58:31 <RichK67> error is in my coding of ReadBlocksInto ... i was well confused there
23:59:07 <RichK67> newgrf.cpp:2046.... can you analyse and recode it properly... it will be same weirdo referencing thingy
23:59:46 <RichK67> (it will be the multi-block handling code
continue to next day ⏵
