IRC logs for #openttd on OFTC at 2010-08-19
⏴ go to previous day
00:32:36 <Eddi|zuHause> "Andere Leute würden solch Set erst in 10 Jahren der Öffentlichkeit vorstellen und vorher gelegentlich Screenshots posten." <-- lmao ;)
00:34:59 <Rubidium> smells like someone making a joke of mb
01:22:30 *** fmauneko_ has joined #openttd
01:28:35 *** fmauneko_ is now known as fmauNeko
02:06:50 *** Eddi|zuHause2 has joined #openttd
02:19:05 *** donoteat has joined #openttd
02:19:44 <donoteat> is there a way to get a scenario made in Chill's patchpack version of OTTD to work in the trunk version of OTTD?
02:19:56 <donoteat> or do I have to start everything over again?
02:22:46 *** rhaeder has joined #openttd
02:23:35 <donoteat> I hope silence doesn't mean "no"
02:26:35 *** rhaeder1 has joined #openttd
02:31:40 * donoteat starts over the scenario :|
02:36:25 *** roboboy has joined #openttd
04:39:05 *** Adambean has joined #openttd
04:56:22 *** Eddi|zuHause2 has joined #openttd
05:45:22 <andythenorth> var 60, shift 10, mask 1, check for 1 (1=desert)
05:45:49 <andythenorth> shift 0A might be more appropriate :P
06:11:05 *** devilsadvocate has quit IRC
06:23:22 *** Kurimus has joined #openttd
06:38:11 *** ^Spike^ has joined #openttd
07:00:02 *** roboboy has joined #openttd
07:14:40 *** Br33z4hSlut5 has joined #openttd
07:41:27 *** JVassie_ has joined #openttd
07:45:38 <Rubidium> planetmaker: your code of FS#4056 doesn't work for me "sed: can't read s/^OPENTTD.GRF = [0-9a-f]*$/OPENTTD.GRF = d4c3f8d93c85136203feb7159151beb5/: No such file"
07:48:42 <Rubidium> planetmaker: does it still work for you if you remove the space between the -i and ""?
07:53:40 <planetmaker> nope, it fails: sed: 1: "/Users/ingo/ottd/fixing ...": command i expects \ followed by text
07:55:59 <planetmaker> that option doesn't exist
07:56:29 <Rubidium> yay... temporary file, here we come!
08:01:07 <jordi> Rubidium: wow, the debian email is probably more detailed than any I have written before
08:01:18 <jordi> Rubidium: I don't think any of the requests will face big opposition
08:01:29 <jordi> openmsx is just data, nothing that can "break"
08:01:55 <Rubidium> jordi: I hope the requests will be granted, but I'm more interested in the "date" question :)
08:02:36 <planetmaker> positive, Rubidium :-)
08:03:58 <jordi> Rubidium: I don't think that's any concern
08:04:21 <jordi> I just came back from a loooong trip, but I don't think Debian is releasing anytime "soon"
08:04:54 <Rubidium> jordi: they hope to do it this year
08:05:23 <dihedral> well - that is soon in terms of debians release cycle ^^
08:06:08 *** Progman has joined #openttd
08:07:42 <CIA-2> OpenTTD: rubidium * r20551 /trunk/Makefile.grf.in: -Fix [FS#4056]: apparantly Mac OS X's sed and GNU's can't decide on a single "format" for replacing stuff in-place
08:08:12 <Rubidium> dihedral: the freeze came almost a month earlier than most expected, although you could see signs of it the day before the freeze happened
08:09:51 <jordi> Rubidium: ie, not "soon" :)
08:10:21 <planetmaker> Rubidium, : "The -E, -a and -i options are non-standard FreeBSD extensions and may not be available on other operating systems"
08:10:30 <planetmaker> so fjb would have problems, too ;-)
08:10:41 <Rubidium> nah, he doesn't have nforenum :)
08:12:05 <dihedral> am i to interprete r20551 as a OSX Fix?
08:12:11 <jordi> Rubidium: fwiw, I expected the freeze on March :)
08:12:41 <Rubidium> jordi: that's more when mr. Shuttleworth wanted it to happen :)
08:13:24 <Rubidium> jordi: in any case, my reasoning was to be clear and give an answer to most of the conceivable questions the release team has so it doesn't need mailing back and forth for a few times
08:13:29 <jordi> but in Debconf9, it seemed a good date for some
08:13:43 <jordi> yeah, the email was good
08:13:53 <peter1138> the announced early freeze was recinded the next day
08:13:57 <peter1138> but that wasn't announced
08:14:19 <peter1138> let's go for retracted, as i can't spell
08:14:20 <Rubidium> I liked the freeze during the release team's speech on debconf10
08:15:18 <jordi> is there any ongoing effort to pursue authors of the bits and pieces that make up opensfx in order to GPL it?
08:20:19 <Rubidium> let me say that I haven't had real incentives to work on it since December
08:20:36 <Rubidium> and nobody else seems to care enough about it either
08:22:09 *** TB is now known as TrueBrain
08:22:22 <CIA-2> OpenTTD: terkhen * r20552 /trunk/src/ (misc_gui.cpp window.cpp): -Fix: Never show tooltips when the mouse cursor is outside the window.
08:24:32 *** TomyLobo has joined #openttd
08:24:46 * Rubidium wonders if there's anyone in here that manages to "create" more than 4 commands per "frame_freq" (for the sane values of frame_freq, i.e. <= 10) frames by manual gameplay
08:25:26 <planetmaker> how long is a frame?
08:26:01 <Rubidium> so 30 ms, 10 frames = 300 ms
08:26:09 <planetmaker> well. A large piece of TF is one command, right?
08:26:17 <planetmaker> And a long rail track as well
08:26:32 <planetmaker> refit for a wagon chain also?
08:27:28 <planetmaker> overbuilding stations and track conversions?
08:27:39 <Rubidium> restoring a vehicle's orders (from backup) when buying a vehicle = 1 commands as well
08:27:44 <Rubidium> planetmaker: those are as well
08:28:00 <Rubidium> the only thing I can think of is cloning vehicles like a mad man
08:28:00 <planetmaker> :-) the vehicle commands was clear from the last commits ;-)
08:28:10 <planetmaker> One cannot clone pretty fast
08:28:49 <Rubidium> although... 4 clicks in 300ms is still a lot
08:28:52 <planetmaker> what about a group of shared vehicles which get new orders?
08:29:04 <planetmaker> 4 clicks in 300ms is feasable
08:29:37 <planetmaker> new orders as in: goto + click on another vehicle not in group
08:29:39 <Rubidium> 104 times in 10 seconds seems to be the world record (or was one)
08:29:57 <Rubidium> planetmaker: that's one command as well
08:30:30 <planetmaker> !rcon ban 78.144.*.* ?
08:31:08 <planetmaker> !rcon list_settings *pf*
08:31:17 <planetmaker> (or similar, I don't know exact syntax)
08:31:38 <Rubidium> list_settings isn't a command (or trigger any)
08:31:57 <Rubidium> changing a setting triggers one
08:32:10 <planetmaker> but no mass-change possible ;-)
08:32:18 <Rubidium> banning might trigger one for each banned person if they had an orderbackup open
08:33:20 <Rubidium> peter1138: hmm, that's 3-ish at most? As the road building happens in a callback
08:34:34 <Rubidium> so processing 4 commands per client every "frame_freq" frames wouldn't hamper anyone's gameplay if frame_freq is reasonable low
08:35:06 <Rubidium> and queueing up to 32 commands before killing the connection
08:36:24 *** Eddi|zuHause2 is now known as Eddi|zuHause
08:36:25 <Rubidium> building bridges doesn't connect roads
08:36:35 <Rubidium> planetmaker: no, incoming ones
08:36:50 <Rubidium> yes, commands coming from clients
08:36:51 <planetmaker> But... every player may do as many things
08:37:03 <planetmaker> And have 25 clients, everyone busy...
08:38:01 <Rubidium> planetmaker: but 32 commands per client in a queue, that means that for it needs to send 8 commands each frame for 8 frames (frame_freq = 1)
08:38:17 <Rubidium> it = any of your clients
08:39:55 <Rubidium> in any case, the numbers are all configurable 1..65535
08:43:23 <Rubidium> I think that setting it to 1 command per frame and 8 commands in queue won't be even noticable
08:43:41 <Rubidium> although that requires real-life testing :)
08:44:26 <Rubidium> it'll break the dump all at once pasting of "templates" though
08:44:29 <peter1138> does this have a purpose, or is it just anti-copy-paste? :p
08:44:43 *** Chris_Booth has joined #openttd
08:44:46 <planetmaker> I guess anti-bot ;-)
08:45:08 <Rubidium> peter1138: it's anti-person-who-is-trying-to-dos the server
08:45:25 *** Brianetta has joined #openttd
08:45:26 <Rubidium> by e.g. sending loads and loads of expensive-to-test, but still failing, commands
08:46:44 <Rubidium> the anti-bot/anti-copy-paste is more a beneficial side effect, although this won't totally break them or disallow them
08:47:07 <Rubidium> as long as they limit the amount of commands they send each frame_freq frames
08:52:15 *** FlyveHest|Work has joined #openttd
08:52:42 <FlyveHest|Work> hi all, a completely newb question here
08:53:03 <FlyveHest|Work> i am setting up a dedicated server, and want to add some of the ECS vectors
08:53:18 <FlyveHest|Work> what do i do about busses/train wagons to transport that cargo?
08:53:34 <planetmaker> add a newgrf which supports them
08:53:38 <FlyveHest|Work> what grf do I need to add for those?
08:53:52 <planetmaker> nearly any vehicle newgrf found on bananas supports it
08:54:04 <FlyveHest|Work> planetmaker: which one would you recommend? i cant seem to find info om the ecs wiki about this
08:54:13 <planetmaker> I don't recommend any :-)
08:54:29 <planetmaker> They're all good. It's a matter of personal taste
08:54:41 <planetmaker> and of what fits the scenario
08:54:53 <planetmaker> but before you setup a dedicated server, test them locally
08:55:20 <FlyveHest|Work> thats what i'm doing currently
08:56:03 <FlyveHest|Work> something like eGRVTS would work?
08:56:19 <FlyveHest|Work> perfect, i'll try that .. thanks :)
08:56:34 <planetmaker> also add trains which support that ;-)
08:56:46 <planetmaker> egrvts is only road + tram
08:58:02 <FlyveHest|Work> ah, ok, thats why there aren't any train wagons :)
08:58:14 *** roboboy has joined #openttd
08:58:26 <FlyveHest|Work> is there a train equivalent to egrvts?
08:58:30 <planetmaker> egrvts = extended generic road vehicle set ;-)
08:59:00 <planetmaker> as said: any train set found probably does the trick
08:59:16 <planetmaker> ukrs, nars2, 2cctrainset, ...
08:59:48 <CIA-2> OpenTTD: rubidium * r20553 /trunk/src/ (9 files in 5 dirs): -Feature: allow rate limiting of incoming commands
09:04:27 <FlyveHest|Work> how do you refit a cargo wagon?
09:04:35 <FlyveHest|Work> sorry for the, probably, stupid questions :)
09:05:39 <planetmaker> obviously it was a stupid question :-P
09:06:30 <FlyveHest|Work> i'll google first, ask later ;)
09:08:25 <Eddi|zuHause> <FlyveHest|Work> is there a train equivalent to egrvts? <-- try "old wagons, new cargoes"
09:10:26 <FlyveHest|Work> Eddi|zuHause: will that "just" make the old wagons refittable?
09:10:30 *** [hta]specx has joined #openttd
09:10:35 <Eddi|zuHause> FlyveHest|Work: yes.
09:10:45 <FlyveHest|Work> could be that I should try that, then
09:11:20 <FlyveHest|Work> but, I think that maybe i'll just run stock settings until me and the other players are comfortable with ottd .. all the different industrytypes, busses and wagons, its a bit overwhelming :)
09:12:12 <planetmaker> playing vanilla is not the worst thing to do
09:12:38 <planetmaker> Using newgrfs sparingly is also nearly always a good idea :-)
09:13:36 <planetmaker> FlyveHest|Work, if you want to get ideas for arrangements, you might looks through a few savegames from our PublicServer savegame list; even though, also not every savegame is really running a completely sane choice there, too
09:14:22 <planetmaker> also, of course, the list of newgrfs ages. As such the newer savegames might be more interesting in that respect than older ones
09:15:04 <FlyveHest|Work> planetmaker: arrangements of newgrfs?
09:15:22 <planetmaker> selection. Choice.
09:15:51 <planetmaker> sometimes order of newgrf matters.
09:16:05 <planetmaker> But don't worry about that (now)
09:16:05 <FlyveHest|Work> i read that somewhere, yes
09:16:31 <FlyveHest|Work> i wont .. the most interesting thing for me would be to add some new industries, to expand the route possibilities
09:16:42 <OwenS> "Congratulations! Your place at The University of Sheffield (S18) to study Physics (4 years) (F301) has been confirmed. "
09:17:26 <planetmaker> welcome to the path to improved nerdyness and geek-dom
09:17:34 <FlyveHest|Work> but, playing vanilla until we "get it" is probably a pretty good idea :)
09:17:44 <FlyveHest|Work> its been some years since I last played TTD ;)
09:17:55 <planetmaker> FlyveHest|Work, then it's a pretty good idea :-)
09:18:06 <FlyveHest|Work> we had a blast 5 people last night, though, sitting on mumble and generally totally messing up the world ;)
09:18:09 <OwenS> OK. Knowns: I got two As and a B, at least :P Now, to finish breakfast, get dressed & showered, and go into college to find out what exactly :p
09:19:48 <planetmaker> in 2 to 3 years you'll find also joy in integrating the banana space ;-)
09:20:17 <planetmaker> though hilbert space is usually sufficient ;-)
09:21:56 <planetmaker> and you'll know what's funny about calling it banana space :-P
09:22:18 <Rubidium> yeah, that it's filled by NewGRF devs
09:24:30 <planetmaker> are they integrable on the L^2 norm?
09:24:56 <planetmaker> at least the function space is infinite ;-)
09:31:13 *** Kurimus has joined #openttd
09:32:22 *** Lachie_ has joined #openttd
09:33:42 *** thvdburgt has joined #openttd
09:34:19 *** Adambean has joined #openttd
10:08:02 <Hirundo> To what extent is different enums having the same XY_prefixes a problem?
10:08:53 <Rubidium> it'll definitely be confusing
10:10:14 <OwenS> Overall results: AABb [with an a from last year] :)
10:10:52 <Hirundo> Even if the code sections in which they are used don't overlap?
10:11:41 *** FlyveHest|Work has quit IRC
10:15:23 *** Timmaexx has joined #openttd
10:21:32 *** Hirundo has joined #openttd
10:23:02 *** Terkhen has joined #openttd
10:23:33 *** V453000 has joined #openttd
10:24:32 *** andythenorth has joined #openttd
10:48:36 *** Timmaexx_ has joined #openttd
10:55:12 <dihedral> Hirundo, what do you want to duplicate??
10:55:45 <planetmaker> Eddi|zuHause, grades
10:55:45 <Hirundo> SC_xx, currently used for screenshots
10:56:13 <planetmaker> anglo-saxon grades are A-a-B-b-C-D-fail
10:56:25 <planetmaker> maybe D is already fail, dunno
11:10:21 <TomyLobo> anglo-saxon grades are just fail
11:11:13 *** FlyveHest|Work has joined #openttd
11:13:52 <FlyveHest|Work> can you abandon a company while playing on a dedicated server?
11:14:48 <TomyLobo> if you want to get rid of it, make sure it has no money left :)
11:14:58 <FlyveHest|Work> how do you do that? Is it by using the console?
11:15:15 <FlyveHest|Work> not as the server administrator, but as a regular player :)
11:15:25 <FlyveHest|Work> and autocleaning is disabled :)
11:15:49 <TomyLobo> cause there is a max of companies :)
11:15:57 <FlyveHest|Work> i can see that there is a reset_company command in the console
11:16:00 <FlyveHest|Work> TomyLobo: exactly
11:16:06 <TomyLobo> and he wants to make a company and restructure the landscape with it :)
11:16:22 <CIA-2> OpenTTD: rubidium * r20554 /trunk/config.lib: -Fix [FS#4057]: typo in configure --help
11:16:27 <FlyveHest|Work> and, my current company has gone down the drain, i just want to restart, without bothering the rest of the players
11:17:06 <Ammler> join a server with support or more companies
11:17:08 <FlyveHest|Work> i couldn't see an option in the GUI, and I am not sure about the reset_company function in the console
11:17:24 <FlyveHest|Work> Ammler: thanks, but that doesn't really answer my question :)
11:17:35 <Ammler> your question is answered already
11:18:17 <FlyveHest|Work> selling all vehicles will remove the company immediately
11:18:30 <Ammler> [13:15] <Eddi|zuHause> then you can't
11:18:57 <FlyveHest|Work> seems like a strange omision, i might add
11:19:09 <FlyveHest|Work> but i'll just use admin powers to remove it, then
11:19:53 <Ammler> you are admin but not able to setup autoclean?
11:20:06 <FlyveHest|Work> its not that i'm not able to, i just don't want it on
11:20:13 <FlyveHest|Work> its not a public server
11:20:30 *** JakeGrimshaw has joined #openttd
11:20:37 <Ammler> what is the issue with the novehicle_autoclean?
11:22:26 *** devilsadvocate has joined #openttd
11:22:31 <FlyveHest|Work> seems like I have to enable company autoclean alongside novehicles
11:22:33 <JakeGrimshaw> I don't suppose anyone knows the code to embed a youtube video in a post on the forums ?
11:22:44 <FlyveHest|Work> or can I disable the company autoclean by setting them to 0?
11:23:16 <FlyveHest|Work> the wiki mentions this on autoclean_unprotected, but not in protected
11:29:04 <Ammler> maybe update the wiki, if it isn't "clear"
11:29:57 *** extspotter has joined #openttd
11:30:20 <FlyveHest|Work> it cleaned two companies, so somethings working :)
11:33:26 <CIA-2> OpenTTD: yexo * r20555 /trunk/src/ (ai/ai_gui.cpp graph_gui.cpp lang/english.txt): -Fix [FS#4053]: wrong tooltip for the company select button in the AI debug and performance rating windows
11:36:25 <CIA-2> OpenTTD: yexo * r20556 /trunk/src/ai/ai_gui.cpp: -Fix (r20555): a tempory copy/pasted line ended up in the commit
11:38:48 <VVG> I want the timetable to start at day X and _date_fract Y. So i supply the start date with dayX and set vehicle lateness_counter to _date_fract Y. Will that work?
11:38:59 *** fmauneko has joined #openttd
11:41:49 <Eddi|zuHause> VVG: that sounds wrong
11:44:04 <Rubidium> timetable start resetting he lateness?
11:44:13 *** FlyveHest|Work has quit IRC
11:45:28 <VVG> that, i thought about first calling timetablestart cmd, then call set vehicleontime cmd modded to use p2 parameter for lateness_counter
11:46:28 <VVG> or does lateness also resets when timetable actually starts?
11:46:50 <Hirundo> Why is such precise control of timetable start time important to you?
11:47:06 <VVG> for virtual time system patch
11:48:22 <Rubidium> VVG: the latenesscounter won't work
11:48:37 <Rubidium> it will be reset for each and every order that is not order 0
11:48:48 <Rubidium> and the timetable_start date only comes into play at order 0
11:49:22 <Rubidium> and then the timetable_state date sets the lateness counter to "current time" - "start time"
11:50:00 <Hirundo> VVG: like in PhilSophus' old timetable patch?
11:50:38 <VVG> yeah, i'm trying to update vt system from that patch to current trunk
11:52:50 <Rubidium> there's somewhat a design disagreement between ITiM and what I put in trunk (or would like in trunk)
11:52:51 <VVG> Rubidium: does resetting it later actually matters? The timetable lentgh will be in x amount of ticks anyway.
11:54:03 <Rubidium> e.g. ITiM reduced the "range" of date significantly so he could put _date_fract in the same 32 bits, however that'll again break horribly with longer days (more ticks a day)
11:56:03 <Rubidium> and limiting the date to 2400 if you want to allow a day to take 32 times as long as it does now doesn't make much sense
11:57:08 <VVG> how that comes into play with purely virtual time?
11:57:10 <Rubidium> VVG: ITiM and the daylength patch do not work together
11:58:03 <VVG> i'm not trying to do anything with daylenght
11:58:45 <Rubidium> VVG: because the 32bits virtual time "clock" limits the range of dates by a factor DAY_TICKS. The daylength patch increases DAY_TICKS, thus reducing the range of dates even more
12:00:00 <Rubidium> regardless of whether you were thinking about that, I was thinking about it when I "changed" trunk's CmdSetTimetableStart to the current behaviour
12:00:33 <Rubidium> the solution is relatively simple: just add a second timetable_start variable for the amount of ticks from the start date
12:01:19 <dihedral> VVG, you are getting some very good hints
12:01:25 <dihedral> i can only suggest to follow them ;-)
12:02:34 <CIA-2> OpenTTD: rubidium * r20557 /trunk/known-bugs.txt: -Document [FS#3928]: why we won't fix the issue
12:02:35 <VVG> i'm trying to understand them right now
12:04:48 *** Timmaexx_ has joined #openttd
12:07:46 <VVG> 1st, i dont understand hiw daylength patch came into mentioning, it surely is out of the scope of my current interests.
12:09:25 <VVG> 2nd, why does limiting date to 2400 matters for virtual time? I'm lost here too :(
12:11:09 <VVG> I'm surely lacking some fundamental knowledge to understand what's going on :(
12:28:48 *** KenjiE20 has joined #openttd
12:29:37 <Hirundo> Basically, you should not store Date * DATE_TICKS in a single 32-bit number, because of overflow problems
12:30:51 <Hirundo> to prevent overflows, ITiM reduce MAX_DATE by factor 74 (DAY_TICKS), limiting dates to around 2400 AD, which is bad (tm) as well
12:37:14 <VVG> Does that mean, that if i switch int32 vars in vt patch to int64 it will be ok and there won't be a need to limit current max year by a factor of 74?
12:42:46 <avdg> I guess you can do the math on your own :p
12:51:15 <TomyLobo> where do dates start?
12:51:32 <TomyLobo> you could just make them start at 1500 and end up with a max date of 3900
12:53:29 <Rubidium> glx: more 5 million years
12:55:16 <Rubidium> TomyLobo: then you'd still be limiting the current range and breaking (some) savegames unnecessarily
12:55:46 <VVG> what could be possible the reason to use int32 to store virtual time and limit max dates, instead of using int64?
12:56:11 <Rubidium> passing int64 in a command is kinda tricky
12:56:50 <avdg> humm does it really need that much more space? :p
12:56:53 <CIA-2> OpenTTD: yexo * r20558 /trunk/src/ (ai/ai_gui.cpp graph_gui.cpp widget.cpp widget_type.h): -Codechange: use one generic function to create a list of company buttons
12:57:40 <Belugas> Yexo, make it a plugin function!
12:58:08 *** Chris_Booth is now known as Guest113
12:58:19 <peter1138> surely it shuld be company knobs
12:58:26 <peter1138> leading the way to the undo knob
13:05:28 <VVG> from what i understand, it needs int64 only when calculating seconds passed since day 1 year 0. And that is used in just a handful of places.
13:06:56 <avdg> tomyLobo: yep, twice as much, but it still doesn't mean that openttd uses double the memory then
13:09:03 <planetmaker> VVG, that's in a lot of places
13:09:05 <Belugas> VVG, where? in RL computing or in OpenTTD's computing?
13:10:37 <Rubidium> planetmaker: why? It's just in visualisation and for determining the parameters to the timetable start command
13:11:09 <Rubidium> internally OpenTTD should be quite happy to run with the current stuff
13:12:20 <Rubidium> the "ony" thing is the timetable start 'tick' offset
13:12:55 <Rubidium> when that is done it is conceivable that the whole virtual time is/can be done at client side
13:16:08 <planetmaker> Rubidium, you mean just a scaling factor for the display?
13:16:28 <planetmaker> hm, probably makes sense most
13:16:39 <Rubidium> that's what the whole virtual time stuff is
13:16:41 <planetmaker> and least messing with stuff. Especially compatibility...
13:17:36 <Rubidium> with a few hooks via commands, though those operate mostly on ticks (which is the smallest a time unit can be as well), except the start date
13:17:49 <Rubidium> which has some space to pass an offset in ticks from that particular start date
13:18:03 <Rubidium> start date command that is
13:22:30 <VVG> to me, it seemed easier to pass tick offset, if it's needed, through cmdsetvehicleontime as lateness_counter, since it's already there. If the whole timetable lenght is being counted in ticks, then that means offest matters only at first start of timetable.
13:28:10 <Hirundo> VVG: It may be easier to have 1 day == n virtual minutes, instead of 1 tick == n virtual seconds
13:28:16 <Rubidium> VVG: commands take time to get over the network, so if you say: start in 20 ticks and the network takes 5 ticks to get the command to all clients you actually set it to 25 ticks from the moment you gave the command
13:32:53 <VVG> that's nasty thing to happen
13:44:54 <CIA-2> OpenTTD: yexo * r20559 /trunk/src/ (5 files): -Fix [FS#4045]: make sure that all vehicles are build in the most northern depot/hangar tile
13:58:44 <VVG> is it ok using int64 % int32?
14:02:25 <Hirundo> What can be gained by setting timetables accurate up to a single tick? currently everything is rounded to days and I see no real reason to change that
14:03:33 <Rubidium> Hirundo: daylength 32?
14:03:51 <Rubidium> maybe you want it to be every 60 ticks?
14:04:08 <Rubidium> more "importantly", months aren't regular so counting it difficult
14:05:42 <Hirundo> As I said, why not set one (or more) virtual minute(s) to be equal to one day and do away with the virtual second
14:05:49 <VVG> Internally, timetable works in ticks, right?
14:05:57 *** theholyduck has joined #openttd
14:06:02 <Hirundo> Yes, but all values are rounded to days
14:06:47 <Hirundo> autofilled values, and values entered by users entering them in days
14:07:08 <Hirundo> what is shown depends on a gui setting
14:07:16 <VVG> you can enter values in ticks, right?
14:07:54 <Hirundo> yes, I'm not sure whether these are rounded as well
14:08:40 <VVG> internally, it works with exact tick values, right? Only what's shown in gui is rounded.
14:08:55 <VVG> That's what i currently assume.
14:12:01 <VVG> okay, with starting year 4999999 virtual time seems to work for me now
14:12:18 <Hirundo> what's shown in gui is rounded in the gui code, but the 'unrounded' values are often a multiple of DAY_TICKS as well
14:13:15 <Rubidium> if you set the "gui" to ticks it won't be rounded (AFAIK)
14:13:18 <VVG> well, you can still enter them in multiple of something else, right?
14:18:18 <VVG> Is it ok, if i supple cmdtimetablestartdate with ticks until the timetable start from current moment, do a proper conversion to days inside there and set lateness_counter appropriatly?
14:18:52 <VVG> Rubidium: that advice of yours to use second timetable_start var is something i have no idea how to do :(
14:19:20 <Rubidium> VVG: no, supplying ticks to moment in a Cmd won't work due to the previously described network lag
14:21:34 *** George is now known as Guest117
14:22:24 <VVG> even if timetable start is somewhere in the future?
14:25:26 <CIA-2> OpenTTD: rubidium * r20560 /trunk/src/ai/api/ai_object.cpp: -Fix: AIs (still/again?) crashing for certain commands
14:26:52 <CIA-2> OpenTTD: rubidium * r20561 /trunk/src/water_map.h: -Fix: compiler warning
14:28:01 *** PinguTux has joined #openttd
14:33:27 <VVG> Rubidium: if i were to add second timetable_start var, where should it go?
14:33:52 <Rubidium> near the first one with some similar, but descriptive name
14:34:05 <Rubidium> maybe rename timetable_start to timetable_start_date
14:34:13 <Rubidium> and call it timetable_start_ticks_offset
14:35:46 *** perk111 has joined #openttd
14:38:36 *** Timmaexx has joined #openttd
14:46:57 *** Biolunar has joined #openttd
14:48:26 *** HerzogDeXtEr1 has joined #openttd
15:06:47 *** Chris_Booth has joined #openttd
15:17:20 *** Grelouk has joined #openttd
15:19:26 *** zachanima has joined #openttd
15:19:53 <CIA-2> OpenTTD: yexo * r20562 /trunk/ (14 files in 4 dirs): -Change: [NoAI] Move all functions from AIList to AIAbstractList
15:26:31 <VVG> There is Tileinxded tile param of CmdSetTimetableStart that's not being used there. Is it ok supply the tick offset through it to CmdSetTimetableStart?
15:28:01 <Rubidium> nope, depending on the settings everything from 1..2049 might be seen as invalid tiles and just the command returns an error (i.e. is not executed)
15:37:22 <Rubidium> though there are some free bits in p1
15:37:40 <CIA-2> OpenTTD: yexo * r20563 /trunk/ (50 files in 6 dirs): -Change: [NoAI] rename AIAbstractList to AIList
15:42:03 <planetmaker> now... that looks odd :-)
15:42:53 <VVG> bits is something i have absolutely no idea about, and can't think of any use for me :(
15:44:29 <CIA-2> OpenTTD: yexo * r20564 /trunk/bin/ai/ (compat_0.7.nut compat_1.0.nut): -Fix (r20562): provide compatibility for AIs using the 0.7/1.0 API and using AIList::ChangeItem
15:50:05 <Rubidium> planetmaker: may look odd, but it retains the most history
15:58:35 <dihedral> Rubidium, what is it you understand under virtual time (i.e. as mentioned earlier wrt that patch)
15:59:52 <Rubidium> virtual, as it says... not related to the game days in OpenTTD or related to the real outside world time
16:00:27 <dihedral> what purpose would that have, if you introduce time which is not related to real time, nor to the ingame time?
16:00:32 <Rubidium> whatever conversion/visualisation methods I don't really care about
16:00:37 <Rubidium> dihedral: read the backlog
16:01:09 <VVG> it's to get 24h visualisation of timetables
16:01:21 <Rubidium> dihedral: it is some conversion of the in-game date, but not trivial and not necessarily the same
16:14:23 *** roboboy has joined #openttd
16:17:04 <VVG> Rubidium: how can i check what bits are free for taking?
16:34:55 <Ammler> on bananas, what is max version for?
16:36:00 <Ammler> only useable for abandoned sets?
16:36:20 <planetmaker> in order to disable things, yes
16:39:43 <Yexo> Ammler: for example or an AI that used the 1.1 API but is not yet compatible with the latest changes in trunk
16:40:27 *** |Jeroen| has joined #openttd
16:40:30 <Ammler> Yexo: but you can't "force" people to update a grf with it?
16:40:58 <Yexo> no, you can always download it with an older openttd version
16:41:11 <Yexo> the maximum version is only used to determine whether or not it's visible in the online content list in openttd
16:41:15 <Ammler> hmm, well, we could implement that in the grf itself
16:42:17 <planetmaker> disable, if version not to your liking
16:42:23 <Ammler> by disable the grf and a note to run bananas update
16:42:27 <Yexo> yes, but you don't know anything about future versions
16:42:44 <planetmaker> it would be VERY bad newgrf behaviour, yes
16:42:59 <planetmaker> as it breaks basically savegame compatibility
16:43:03 <Ammler> well, if there is no update available :-)
16:43:05 <Yexo> and why would you write a newgrf that disables itself in the currently latest version? imo you'd be far better of updating the newgrf code then implementing that check
16:43:40 <Yexo> Ammler: at the time you create the newgrf it always works in the latest version (assumption), when the newgrf becomes broken due to changes you want to disable it
16:43:58 <Yexo> to disable it you'll have to change the newgrf, so users need to update first only to notice that the update doesn't work
16:43:59 <planetmaker> but only for new downloads
16:44:01 <Ammler> Yexo: not to disable itself, to force people to update
16:44:07 <Yexo> they can still remove the update and play with the older version
16:44:19 <Yexo> you can't force people to update
16:44:46 <Yexo> if you upload a newer version to bananas the older versions won't be visible in-game anyway
16:44:52 <Yexo> so there is no need to set a maximum version
16:45:00 <Ammler> but if poeple would like to play with newer openttd, they would need to update
16:45:39 <Yexo> Ammler: yes, but at the time you write the newgrf you don't know from which openttd version on they need an update for the grf
16:46:03 <Yexo> you don't know currenlty whether openttd 1.1 will work with current opengfx, so you can't check in opengfx for opentd version 1.1 and then force the user to upgrade
16:46:09 <planetmaker> but you don't want a newgrf which behaves like the windows genuine talk-back disadvantage verification tool
16:47:15 <planetmaker> "you're running a not-licensed newgrf. Please connect to bananas and make sure you get the newest version, the only one which you can get a license for :-P
16:47:18 <Ammler> yeah, you would do that "on purpose"
16:48:07 *** [hta]specx has left #openttd
16:49:51 *** ProfFrink has joined #openttd
16:52:25 <VVG> CmdSetTimetableStart gets w->windownumber as p1 parameter and uses bits 1-16 from it to get a vehicle id. Am i free to use other bits for myself here?
16:55:53 <Eddi|zuHause> if both the documentation and the code says the other bits are not used, you can use them
16:56:00 *** ProfFrink is now known as Prof_Frink
16:59:27 <VVG> except the comments in code, is there some other source of documentation?
17:08:49 *** TheMask96 has joined #openttd
17:15:44 <Yexo> docs.openttd.org, but that's autogenerated from the comments in the code
17:16:01 <Yexo> and there is some documentation on the wiki, but part of that is very outdated/incorrect
17:21:08 <Rubidium> the wiki is good if you want outdated and 'has never been correct' information
17:21:33 <Rubidium> ^/trunk/docs/ does not have anything that's useful for VVG
17:23:47 *** JVassie has joined #openttd
17:24:30 <Zuu> While the wiki per definition never can be completely up to date, I still find it uesful.
17:24:58 <Zuu> It can introduce you into new topics, which you then have to confirm against the source code.
17:26:32 <VVG> Well, in this case, i assumed my judgment of the code was correct and went ahead with using free bits. :)
17:27:52 *** Intexon has joined #openttd
17:28:02 <ABD> i am loohing to play with a groub of people
17:28:31 <ABD> is it that the reght places
17:28:32 <Zuu> Do you look for people to play with, or do you arleady know those people?
17:29:00 <ABD> i am looking for people to play with
17:29:28 <Zuu> OpenTTDCoop usually have people on their servers
17:29:31 <ABD> this is the first time for me to enter the chat room
17:29:35 <Zuu> In addition they do cooperative playing.
17:29:59 <avdg> abd: use version 1.0.3, there are a lot active servers using it atm
17:30:10 <planetmaker> ABD: look at your server list from ingame
17:30:21 <Zuu> openttdcoop -> #openttdcoop on this server
17:30:24 <planetmaker> Join one of those servers where there are a few clients connected
17:30:59 <planetmaker> But question really is: do you want competitive play or cooperative one :-)
17:31:11 <planetmaker> there are differences as Zuu pointed out ;-)
17:31:51 <avdg> abd: can you already build networks?
17:31:54 <planetmaker> I might be biased towards cooperative play ;-)
17:32:32 <planetmaker> which can be found on... yeah, the openttdcoop server(s)
17:33:35 <ABD> whrer can i fiund the openttdcoop server??
17:33:36 <planetmaker> let me recommend for starters maybe our 'stable' server which runs OpenTTD 1.0.3
17:33:52 <planetmaker> look for #openttdcoop Stable
17:34:25 <planetmaker> hm, in the server list? Ingame?
17:34:45 <planetmaker> main menu->multiplayer->find servers
17:35:00 <planetmaker> make sure you search in the internet, not in LAN
17:36:08 <ABD> should i speak with people first
17:36:10 <avdg> you can also join the yellow ones, but you have to install extra stuff
17:37:51 <planetmaker> we do :-) See you
17:37:55 <Zuu> The extra stuff is usually found through the in-game content downloader.
17:38:12 <planetmaker> that was quick :-)
17:38:33 <TomyLobo> he might also want to invest in an english course :)
17:39:25 <planetmaker> I've seen worse. Especially by people who are native speakers
17:39:29 <VVG> So. I use Changetimetablestartcallback as a place to calculate startdate and offset, use bits 17-30 of p1 to store offset. In cmdsettimetablestart set the start date and v->timetable_start_ticksoffset, which i later use in updatevehicldetimetable when the timetablestartdate is set. Am i on right track here?
17:39:53 <planetmaker> who then speak in abbreviations only
17:39:59 <TomyLobo> the nature of his mistake (b/p, swapping letters) might also hint at dyslexia
17:41:03 <Zuu> I didn't even notice he had some swapped letters :-p
17:41:58 <Zuu> While I haven't been diagnosed with it, it would not surprise me. :-)
17:42:35 <Yexo> "whrer", "qustion", "fiund" <- neither of those have swapped letters
17:43:05 <Yexo> it looks much more like careless typing
17:43:26 <Zuu> where -> where looks like someone doing touch-typing quickly and miss-aligning the the finger taps in time.
17:43:51 <planetmaker> where->where looks like the unity operator
17:43:55 <Yexo> u is next to the i, so same for fiund, and qustion just misses a letter
17:44:17 <Hirundo> as long as the frist and lsat letters are in palce, it's prefectly raedalbe
17:44:51 <planetmaker> I call 'perfectly' something else, but yes
17:44:55 <Zuu> As long as only some words are muffeled, it is not that hard to guess the missing words. :-)
17:45:14 <avdg> hirundo: from where do I know that :p
17:46:09 <CIA-2> OpenTTD: translators * r20565 /trunk/src/lang/ (15 files in 2 dirs): (log message trimmed)
17:46:09 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:46:09 <CIA-2> OpenTTD: belarusian - 7 changes by KorneySan
17:46:09 <CIA-2> OpenTTD: simplified_chinese - 3 changes by pda1573
17:46:09 <CIA-2> OpenTTD: traditional_chinese - 5 changes by josesun
17:46:10 <CIA-2> OpenTTD: chuvash - 31 changes by mefisteron
17:46:10 <CIA-2> OpenTTD: dutch - 5 changes by habell
17:47:34 <Zuu> hmm, what is the language order of the WT3 commit messages?
17:47:48 <Zuu> Not alphabetical it seems.
17:49:25 <planetmaker> you miss your name there, Zuu ? ;-)
17:50:06 <Zuu> Well, at least I do not get highlighted that often.
17:50:30 <Ammler> hmm, instead using the info sprite, maybe we could make a special sprite "PLEASE UPDATE" and use that, one which is really ugly and you can't continue playing
17:54:10 <glx> there's .notice for highlights ;)
17:54:45 <Ammler> anyway, it would be nice, if the "missing sprite" sprite would be a own sprite to define independently
17:55:02 <planetmaker> Ammler, which sprite do you want to mis-use for that end?
17:55:16 <Ammler> none, I would make one
17:55:29 <planetmaker> Yeah, but you have to replace one :-)
17:55:30 *** fmauneko has joined #openttd
17:55:47 <Rubidium> and you want it to be used by e.g. dbset if you're using "more" wagons?
17:55:52 <planetmaker> how would the players otherwise see the update request?
17:56:26 <planetmaker> ah. ok, now I understand, Ammler :-)
17:56:30 <Ammler> you could make a sprite with the text "PLEASE UPDATE" for example
17:56:34 <planetmaker> Yes, that MIGHT make sense :-)
17:57:14 <planetmaker> Rubidium, I think the idea is to replace new GUI sprites by that one
17:57:35 <planetmaker> And... OpenTTD won't bork, if I define too many GUI sprites, right?
17:57:53 <Ammler> you don't have the issue with openttd trunk, as it has always the right set with it :-)
17:57:59 *** ajmiles has joined #openttd
17:58:20 <planetmaker> Then the idea can be: Define one additional GUI sprite with the info "please\n update" :-)
17:59:06 <Ammler> planetmaker: it isn't just GUI
17:59:33 <planetmaker> Ammler, but... other places is hard
17:59:51 <Ammler> your solution is already possible :-)
18:01:35 <Ammler> but the next issue will be the airport previes
18:01:49 <Ammler> which is for example a new feature
18:03:31 <planetmaker> Well. Test what happens, if you now define type 17 :-)
18:03:57 <planetmaker> And test also what happens, if you define type 16 with only 1 sprite
18:04:04 <Ammler> it feels damn hackyish :-)
18:04:31 <planetmaker> Unknown features are by definition unsupported...
18:05:24 <planetmaker> You want to supply sprites for things which are not know how they look like and how they're going to be defined
18:05:58 <planetmaker> I like the idea in principle :-)
18:09:59 <Ammler> at least the good linux distros do also update the basesets, when they update openttd :-)
18:11:05 *** Chris_Booth has joined #openttd
18:21:19 *** frosch123 has joined #openttd
18:23:06 <andythenorth> :o Hirundo gets cookies
18:26:22 *** Alberth has joined #openttd
18:28:02 *** lobster has joined #openttd
18:28:50 *** Devroush has joined #openttd
18:34:54 <Rubidium> Ammler: a major problem with simply letting OpenTTD use a sprite from "extra" is that it gets into major mayhem when that sprite does not exist; OpenTTD will crash quite hard
18:36:22 <Rubidium> which means that your "current" use base will get crashing OpenTTDs because they haven't updated the set yet
18:37:56 <Ammler> yeah, it would still need the current solution as worst case backup
18:38:19 <andythenorth> Hirundo: got some suggestions for string changes in connection with that patch
18:39:33 <Rubidium> I've often thought about providing some mechanism for setting something in the .obg to tell when it's outdated, but that'll just simply fail horribly for nightlies and for openmsx/opensfx it's not needed at all
18:39:41 <Ammler> Rubidium: for the airport sprites it is too late anyway
18:40:38 <Rubidium> though... I think it would be fairly safe to assume that a certain set of sprites must exist after the base graphics set is loaded and if that is not the case a nice red error box can be shown that you need to update your graphics set
18:41:54 <Rubidium> and I think that is a more durable way that adding "ugly" untranslated sprites
18:42:31 <Ammler> and that would also work with airport preview sprites already :-)
18:42:46 <Rubidium> and in theory work for 1.0.x as well
18:43:16 <planetmaker> question: when to show that? I guess at start of game only
18:43:49 <Ammler> I guess, the missing airport would cause only after starting a map
18:44:38 <Ammler> or will the whole extra grf be loaded on startup?
18:45:01 <Rubidium> at least the sprite locations in the file will be known, so that can be used
18:45:36 <Ammler> well, it doesn't matter, what is the easiest, I would say
18:45:51 <Ammler> at least we could then blame "not reading the red box" :-)
18:47:50 <Ammler> using the sprite from openttd.grf is bad idea?
18:48:17 <Ammler> I guess so, wouldn't "force" the people to update, there might be other reasons, too
18:50:38 <VVG> Now that i actually made handling of startdate with ticks offset, it turns out my handling of edit box for entering times is broken :( dropdown works though
19:01:34 *** TruePikachu has joined #openttd
19:02:09 * TruePikachu discovered that, in DSLinux, L=Shift :D
19:03:12 <Hirundo> andythenorth: could you just post them in the topic?
19:03:20 <TruePikachu> Anyway, I'm working on a special Ro-Ro station with 10 task-oriented platforms
19:03:49 <TruePikachu> It will feed a factory
19:04:07 <TruePikachu> @me? I'm not at my computer ATM
19:04:45 <TruePikachu> Brb, I'll post a save of a version after I'm off the can
19:05:15 *** lobster has joined #openttd
19:05:55 <TruePikachu> Actually, I'll stitch screenshots
19:06:50 <TruePikachu> 4 waypoints plus Industrial Station Renewal = uberstation
19:07:29 <TruePikachu> I concluded that the terminus version wasn't working efficiently enough; it flooded with goods, causing Xrufuian to 'take some off my hands' (i.e. steal them all)
19:09:58 <TruePikachu> I don't like the exit ATM, it jams frequently, and requires an additional balancer
19:10:20 <TruePikachu> (as in, I need to build another balancer in the small space I have for one)
19:16:50 <TruePikachu> Lol, my computer is lagging like crazy right now
19:20:41 * Rubidium (cattle) prods Ammler
19:21:38 * frosch123 has the impression that the MAKEOPTS environment variable is gentoo specific
19:22:13 <Rubidium> that could very well be
19:22:39 <Ammler> Rubidium: I like it (k)
19:23:52 <CIA-2> OpenTTD: rubidium * r20566 /trunk/src/ (lang/english.txt newgrf.cpp newgrf_config.h openttd.cpp): -Feature: happy smiles on the faces of Ammler and planetmaker
19:26:21 * Rubidium wonders how long it takes for the tt-ms folks to wonder what the hell that feature is about
19:27:12 <avdg> do they really care about commits?
19:27:34 <Rubidium> they have a "Neuste OpenTTD-Features" tracker, which reacts on -Feature and -Release
19:29:48 *** JVassie has joined #openttd
19:36:00 <Ammler> ./configure: line 168: generate_grf: command not found
19:38:13 <Rubidium> because generate_grf and generate_lang are extremely similar
19:38:25 <Rubidium> and generate_lang apparantly worked
19:55:13 *** DJNekkid has joined #openttd
20:01:28 <andythenorth> Hirundo: does the ship patch actually change CC? I have the GUI, but no CC changes..r20565
20:01:35 <andythenorth> tested with FISH and default ships
20:02:24 <Hirundo> It should, I'll take a look
20:02:52 <Ammler> the debug levels aren't saved somewhere for restart?
20:03:00 <Ammler> so also if -1 would work
20:03:32 <Ammler> need to add it to the start command of course :-$
20:08:39 *** fmauneko is now known as fmauNeko
20:15:57 <CIA-2> OpenTTD: terkhen * r20567 /trunk/known-bugs.txt: -Document [FS#3966]: Add note to known-bugs about this issue.
20:20:34 <CIA-2> OpenTTD: yexo * r20568 /trunk/src/ai/api/ (ai_vehicle.cpp ai_vehicle.hpp): -Codechange: change the value of AIVehicle::VEHICLE_INVALID and use it as return value instead of ::INVALID_VEHICLE
20:33:20 <VVG> I'm doing something wrong. On second click on edit box ottd crashes. What may be an issue here?
20:34:08 <Rubidium> get a debug build's backtrace and we might be able to tell
20:34:09 <CIA-2> OpenTTD: rubidium * r20569 /trunk/src/timetable_cmd.cpp: -Cleanup: the change timetable command doesn't need the packed bit anymore
20:35:05 <CIA-2> OpenTTD: rubidium * r20570 /trunk/src/ (timetable_cmd.cpp timetable_gui.cpp): -Codechange: free/reserve some bits in the timetable commands to increase the vehicle pool limit
20:39:26 <CIA-2> OpenTTD: rubidium * r20571 /trunk/src/ (6 files in 2 dirs): -Codechange: free/reserve some bits in the order commands to increase the vehicle pool limit
20:40:38 <Hirundo> 1 million vehicles - sweet :)
20:41:15 <TruePikachu> Our XP Professional box here got hit vy a virus which sets random passwords on all accounts
20:42:04 <VVG> 0 - 20 - is that 21 one bits?
20:42:12 <CIA-2> OpenTTD: rubidium * r20572 /trunk/src/ (6 files in 2 dirs): -Codechange: free/reserve some bits in the wagon move command to increase the vehicle pool limit
20:44:36 <Alberth> VVG: some '20' are the number of bits
20:44:46 <Rubidium> VVG: GB(data, start, count)
20:45:42 <CIA-2> OpenTTD: rubidium * r20573 /trunk/src/ (5 files in 2 dirs): -Codechange: free/reserve some bits in the sell vehicle command to increase the vehicle pool limit
20:49:56 <VVG> I've build the debug version. Now i just crash it and look for stack trace in crash log?
20:50:39 <Rubidium> no, you run it in your debugger
20:58:42 <CIA-2> OpenTTD: rubidium * r20574 /trunk/src/ (6 files in 3 dirs): -Codechange: a little over 1 million vehicles should be enough for the forseeable future
21:00:12 <VVG> the whole system stopped responding when i used Start debugging in VC2008 :(
21:00:39 <andythenorth> Rubidium: does 1m vehicles provide enough room for ships to have smoke sprites?
21:01:35 <Rubidium> andythenorth: if that's 1 million ships, then nope...
21:02:11 *** Chris_Booth has joined #openttd
21:05:01 <VVG> The thread 'Win32 Thread' (0x7b8) has exited with code 0 (0x0).
21:05:01 <VVG> First-chance exception at 0x7c812afb in openttd.exe: 0xE1212012: 0xe1212012.
21:05:01 <VVG> Unhandled exception at 0x7c812afb in openttd.exe: 0xE1212012: 0xe1212012.
21:05:12 <VVG> Is that an output that might be helpful?
21:05:49 <Rubidium> there should be a stack trace somewhere
21:13:44 <VVG> the only stack trace i can find is in crash.log
21:14:10 <Rubidium> that's all numbery, right?
21:14:44 <VVG> yeah, like that: 00000000 00000000 00000000 0012CDAC 0012E644 00000000 CCCCCCCC CCCCCCCC
21:14:45 <ccfreak2k> That's one way to put it.
21:16:12 <Rubidium> so... any MSVC user that can explain how to perform an OpenTTD debug?
21:18:07 <VVG> just in case, the error i get is this: Message: String 0x6982 is invalid. You are probably using an old version of the .lng file.
21:18:36 <Rubidium> then you're messing up somewhere with the strings :)
21:18:39 <Hirundo> 'Start debugging' from the menu?
21:19:59 <VVG> i made some progress here, i got "dissasmbly window" with that type of lines "7C814D3D mov eax,dword ptr fs:[00000018h]"
21:20:32 <Hirundo> what version do you use?
21:20:56 <Hirundo> "the whole system stopped responding when i used Start debugging in VC2008 :(" <- you need patience :)
21:21:04 <VVG> openttd.exe!_output_l(_iobuf * stream=0x00000000, const char * format=0x00000000, localeinfo_struct * plocinfo=0x00000000, char * argptr=0x00000000) Line 1161 + 0x18 bytes C++
21:21:31 <Rubidium> there should be a window/tab somewhere with stack trace or something
21:21:49 <Hirundo> Did you try 'start debugging'? It tends to work perfectly (although slowly) for me
21:22:33 <VVG> yes, start debugging, game runs, made it crash, now trying to figure out what's where
21:23:05 <Hirundo> what did you click after the crash?
21:23:33 <VVG> Is this : 00E685CD mov eax,dword ptr [ebp-28h]
21:23:34 <VVG> 00E685D0 mov dword ptr [ebp-18h],eax
21:23:34 <VVG> 00E685D3 mov ecx,dword ptr [ebp-18h]
21:23:34 <VVG> 00E685D6 mov dword ptr [ebp-1Ch],ecx
21:23:39 <VVG> how the stack trace looks like?
21:24:02 <VVG> Hirundo: break->show dissasmbly
21:24:15 <Hirundo> you don't need the disassembly
21:24:52 <glx> 23:21:13] <VVG> openttd.exe!_output_l(_iobuf * stream=0x00000000, const char * format=0x00000000, localeinfo_struct * plocinfo=0x00000000, char * argptr=0x00000000) Line 1161 + 0x18 bytes C++ <-- that's from the trace
21:26:15 *** [com]buster has joined #openttd
21:26:17 <VVG> I select that line as stack frame and get a green arrow poiting me to: 00E685B8 add esp,0Ch
21:26:53 <glx> started VS with openttd.sln?
21:27:48 <glx> ho that's a system function, so it's ok to get only asm for it
21:28:03 <VVG> it asked me if i want to recover some file from previous session, to be exact
21:28:29 <VVG> but from the looks of it it opened all like it does when selsecting openttd_vs90.sln
21:28:58 <glx> paste the call stack somewhere
21:29:08 <Hirundo> Debug > Windows > Call stack
21:29:30 <VVG> [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll]
21:29:30 <VVG> > openttd.exe!_output_l(_iobuf * stream=0x00000000, const char * format=0x00000000, localeinfo_struct * plocinfo=0x00000000, char * argptr=0x00000000) Line 1161 + 0x18 bytes C++
21:29:41 <VVG> that's all i have in call stack window
21:30:42 <ccfreak2k> Are all four args supposed to be 0?
21:30:44 <glx> kernel32.dll!@BaseThreadInitThunk@12() + 0x12 octets
21:30:44 <glx> ntdll.dll!___RtlUserThreadStart@8() + 0x27 octets
21:30:44 <glx> ntdll.dll!__RtlUserThreadStart@8() + 0x1b octets
21:31:12 <Hirundo> What's your windows version?
21:31:15 <glx> and at least a WinMain somewhere
21:31:35 <glx> unless you are not in main thread
21:31:55 <VVG> I found the thread secection window just now
21:32:10 <VVG> those 4 lines are from Main thread
21:34:50 <glx> [23:05:09] <VVG> Unhandled exception at 0x7c812afb in openttd.exe: 0xE1212012: 0xe1212012. <-- anyway that's usually an assert ;)
21:35:53 <glx> the pastebin one is for sound
21:36:15 <VVG> it's the only other thread that has openttd.exe in it
21:36:34 <VVG> others all ntdll, kernel, and some other dlls
21:38:10 <VVG> glx: mind that this is a patched version
21:38:37 <glx> patched or not, it's the same for MSVC ;)
21:39:04 <glx> but when it crashes it should just go to the crash location
21:40:06 <glx> unless you forced it to continue
21:40:53 <glx> because 0xE1212012 is an assert
21:41:52 *** [com]buster has joined #openttd
21:42:04 <VVG> okay, start debugging->ottd crash, now i have a choice between break and continue
21:42:46 <VVG> There is no sourcode avaible for current location, OK/SHOW dissasebmly
21:43:23 <glx> not important, but check the call stack
21:44:31 <glx> you should have abort(), error() and the failing line
21:45:18 * Rubidium is so happy it's easier in Linux to get someone to get a stack trace :)
21:45:52 <VVG> where should i have them?
21:46:04 <VVG> call stack looks the same, for example again this line: > openttd.exe!_output_l(_iobuf * stream=0x00000000, const char * format=0x00000000, localeinfo_struct * plocinfo=0x00000000, char * argptr=0x00000000) Line 1161 + 0x18 bytes C++
21:48:10 <VVG> if that is of any help to you, ottd crashes on second mouse click on edit box of mine
21:52:34 <VVG> the stuff for edit box is in date_gui.cpp
21:53:34 <VVG> as i wasn't sure, how relevant other stuff might be, i made a diff with all stuf i changed
21:55:13 <glx> next time patch from root, not from src ;)
21:56:08 <VVG> why? src is the only thing changed
21:57:05 <glx> because it's better to do it from root, just in case
22:02:25 <VVG> that edit box is one the 2 base functionality things left to work out and it seems it's beyoud me to make it by copypasting stuff from other places :)
22:03:39 *** [alt]buster has joined #openttd
22:03:49 *** [alt]buster is now known as [com]buster
22:06:43 <CIA-2> OpenTTD: rubidium * r20575 /trunk/src/ai/ai_gui.cpp: -Fix [FS#4059] (r20542): reloading of companies did load another AI
22:08:11 <glx> VVG: does it compile for you ?
22:09:21 <glx> +inline Time64 DateToTimeNonCapped(Date date, DateFract fract = 0) {
22:09:21 <glx> + return int64 time_since_year_zero = (date * DAY_TICKS + fract);
22:09:21 <glx> ^^ that's wrong for my MSVC
22:12:36 <VVG> it's different here, how come there is such a line in patch?
22:14:13 <Rubidium> because you've given the wrong / not-up-to-date version?
22:14:29 <VVG> i just compiled it, looks ok
22:14:51 <VVG> i found that line, that's a leftover from trying different things, it shouln't be there at all
22:15:48 <VVG> i totally forgot about that when i got distracted by other things :(
22:16:43 <VVG> anyway, it happily compiled with those lines there
22:17:52 <VVG> date.cpp should not have anything after last OnNewYear
22:19:18 <VVG> wait a sec, i'll post a more proper version
22:19:30 <VVG> compiling it atm to check it runs :)
22:20:25 <glx> of course svn up failed (I ran it in src because of you ;) )
22:22:35 <VVG> there, without those lines in date.cpp, compiles fine, runs, crashes fine when forced to :)
22:23:51 <VVG> what version of MSVC do you have that it complained previosly?
22:25:25 *** [alt]buster has joined #openttd
22:25:32 *** [alt]buster is now known as [com]buster
22:26:04 <VVG> mine didn't complain a bit about those lines ;(
22:35:58 <VVG> set interaction->show timetable in to hhmm or hhmmss to get the settime dialog when setting timetable start date, that where the edit box that crashes is
22:41:21 <VVG> one thing i should have mention long ago - i have no understanding of how edit box actually works, what i have there is bits copypasted from other places in ottd code
22:41:47 <glx> I get a "String is invalid message"
22:43:11 <glx> error("String 0x%X is invalid. You are probably using an old version of the .lng file.\n", string); <-- this one
22:46:18 <VVG> i cant make any sense out of it
22:47:10 *** [com]buster has joined #openttd
22:53:11 <glx> it's {WHITE}{STRING} resolving to {STRING} resolving to 0xb3c81 which is not a valid string
22:54:08 <glx> it crashes opening the OSK
22:56:30 <VVG> it's uncomprenhensible for me
22:57:52 <VVG> NWidget(WWT_EDITBOX, COLOUR_WHITE is this the case here? the STR_JUST_STRING doesn't have any color codes
22:58:51 *** perk111 has joined #openttd
22:59:35 <TruePikachu> ^^ If that is where the error is, no closing )
22:59:37 <VVG> resolving to 0xb3c81 which is not a valid string <-- what is that?
22:59:49 <Rubidium> the STR_JUST_STRING of WWT_EDITBOX seems/feels wrong
23:01:07 <Rubidium> VVG: replacing the STR_JUST_STRING with STR_TIME_CAPTION might help
23:02:43 <VVG> isnt that what's is show as name of the window?
23:03:28 <Rubidium> what is not STR_JUST_STRING is the caption of the on screen keyboard
23:04:27 <Rubidium> and as nothing sets the parameters for that string it crashes OpenTTD
23:06:40 <glx> it's just luck it sometimes work
23:08:57 *** [com]buster has joined #openttd
23:13:37 <VVG> can't really express how happy i am now
23:26:53 <TruePikachu> Lol @ forum - epic typo
23:27:13 <TruePikachu> "...when attacked to the train..."
23:30:20 *** Brianetta has joined #openttd
23:31:59 <Eddi|zuHause> * Rubidium wonders how long it takes for the tt-ms folks to wonder what the hell that feature is about <-- i seem to remember a discussion that nobody actually goes to the main page, so they don't usually see that feature list
23:33:05 <Rubidium> but I saw it... in OpenTTD's HTTP logs
23:34:53 <Rubidium> hitting trac every minute asking for the last 90 days worth of commits
23:39:36 <Rubidium> yes, getting a 0.5 MiB XML
23:40:07 <frosch123> can we somehow charge for that?
23:42:28 <Rubidium> nah, he scaled back his thing after a mail claiming I didn't like it that their "ticker" costs 22 GiB a month
23:43:09 <ccfreak2k> Who is he in this context?
23:50:47 *** [alt]buster has joined #openttd
23:50:51 *** [alt]buster is now known as [com]buster
continue to next day ⏵
