IRC logs for #openttd on OFTC at 2011-07-16
⏴ go to previous day
00:00:43 *** supermop has joined #openttd
01:19:37 <Markk> Hallo, where do I report a spelling mistake?
02:22:21 *** Texruska has joined #openttd
04:05:55 *** DayDreamer has joined #openttd
04:56:23 *** Eddi|zuHause has joined #openttd
05:51:30 <supermop> i jut got back from the bars
05:58:45 *** Cybertinus has joined #openttd
06:07:48 *** Scuddles has joined #openttd
06:40:14 *** TinoDid|znc has joined #openttd
06:42:55 *** TinoDid|znc is now known as TinoDidriksen
06:59:54 *** George is now known as Guest2363
07:41:05 *** Progman has joined #openttd
07:50:22 *** Alberth has joined #openttd
07:50:23 *** ChanServ sets mode: +o Alberth
08:33:32 *** Hyronymus has joined #openttd
08:48:33 <planetmaker> Hyronymus: re this guy asking for uploads: I don't currently know whether it's his NewGRFs... I seem to have them as I can't download them
08:48:46 <planetmaker> but I don't have database access
08:49:56 <planetmaker> and if I did I'm not sure I should try messing with it ;-)
08:50:48 <Hyronymus> does Rubidium have dbase access?
08:51:45 <planetmaker> but do you think it's a good idea to hold a possible violation of TOS of bananas against him at tt-forums?
08:52:23 <planetmaker> from what I see he asked in 5(?) threads the authors to please upload their work... could have been me 18 months ago :-P
08:52:26 <Hyronymus> no, I re-thought that
08:52:47 <Hyronymus> he'll just get a firm warning
08:53:10 <Hyronymus> but I do hope someone from Bananas will chip in to explain the copyright matter
08:53:31 <Hyronymus> twice warned, forth shy
08:53:48 <planetmaker> I don't know the licenses of those NewGRFs. Seem to be pointless ones anyway, given their name
08:54:03 <planetmaker> there's a similiar (or same) in the coop grfpack
08:54:41 <planetmaker> but mind, Hyronymus: uploading mb's newgrfs to bananas would NOT constitute a copyright infringement. It would be allowed by his license. But not by the terms of service of bananans
08:55:02 <planetmaker> so there are subtle differences there, too ;-)
08:56:36 <planetmaker> the author-only-uploads rule is more a safety net for OpenTTD's banannas service itself
08:57:59 <planetmaker> otherwise any GPL'ed or CC-BY-xy newgrf could be uploaded by anyone. or other custom licenses which allow distribution
08:58:46 <Alberth> one still can, just fork the project, give it a new name, and submit ;)
08:59:49 <planetmaker> but that changes the md5sum
08:59:50 <Hyronymus> I really need to read up on copyright stuff
08:59:55 <planetmaker> which makes it much less useful
09:00:27 <Alberth> and a new grfid probably
09:02:07 <planetmaker> why definitely? I can modify a newgrf, call it differently and upload w/o changed grfID to bananas if it doesn't exist there yet
09:02:11 <Rubidium> what's this whole bananas problem you're talking about?
09:02:39 <planetmaker> Rubidium: Hyronymus is concerned about the authorship of the last three newgrf uploads
09:03:05 <Rubidium> @base 10 16 1178767366
09:04:04 <Hyronymus> I was meaning I should definetly read up on copyright, planetmaker
09:04:51 <Hyronymus> that gut Forlostcontent has been asking for people to upload their grf's on tt-forums
09:04:54 <Rubidium> who did ever make those (useless) separator things?
09:05:20 <Hyronymus> and now it seems he placed them on Bananas and I'm not sure who made it originally and if there are any copyrights on it
09:05:36 <Rubidium> there are definitely copyrights on it
09:05:58 <Rubidium> as I doubt it's made by US government employees
09:06:30 <planetmaker> in Germany one cannot waive copyright ;-)
09:06:37 <Alberth> Hyronymus: that's normal around Rubidium :)
09:06:54 <Rubidium> Hyronymus: if you write an email, that email is copyrighted (unless you're a US goverment employee, then it's public domain)
09:06:55 <Hyronymus> ah, thanks for the heads-up Alberth :D
09:07:22 <Hyronymus> damn, more copyright stuff to look into
09:07:42 <Hyronymus> anymore peculiarities I ought to know of?
09:07:49 <Rubidium> copyright != license
09:08:01 <planetmaker> Hyronymus: copyright is something which is _automatically_ granted upon creation. Without any action taken by authors
09:08:17 <Rubidium> copyrights are used to enforce licenses
09:08:31 <planetmaker> and a license my state under which conditions the material may be used where
09:08:57 <Hyronymus> that puts things in a clear perspective
09:10:06 <Hyronymus> but that means in normal situations, only creators can decide on what license to use
09:10:09 <planetmaker> some legislations (like US) allow authors to waive or transfer copyright to other entities
09:10:18 <planetmaker> Hyronymus: of course. Exactly that it means
09:10:51 <Hyronymus> so Forlostguy now uploaded these things with a license but if he isn't the creator he hasn't got that right
09:11:02 <planetmaker> that depends on the license.
09:11:21 <Hyronymus> the creator released the stuff under a free to distribute license
09:11:51 * Hyronymus has seen the copyright light
09:13:02 <Alberth> a BSD-style license is free to distribute. GPL also enforces access to the source
09:15:45 <planetmaker> or maybe just publish as-is ;-)
09:16:02 <Hyronymus> if you do the latter, people can always suggest changes
09:18:24 <V453000> planetmaker: you should finish that blog article :P quite an interesting topic for example I know shit about but am interested in reading it
09:18:44 <planetmaker> V453000: that's the blog article's text ;-)
09:19:06 <planetmaker> just copy&pasted to a file so that people here now could see it ;-)
09:19:08 <Alberth> Hyronymus: I can also suggest changes without having access to the source.The source is however needed for forking the project if needed, and/or to implement changes myself
09:19:09 <V453000> but you never published the article :)
09:19:32 <planetmaker> yes... it's still missing on some licenses
09:20:52 <Alberth> Of course, anything I publish must again be free access to the source, so everybody can use that work
09:40:28 *** Biolunar has joined #openttd
09:55:31 <LordAro> Alberth, i may be stuck again :) i tried to convert GrfHasReadme to returning something useful (TarEntryListThingy) but that didn't really work http://pastebin.com/Rvs73Ejq <-- troublesome areas are GrfHasReadme() and PrintReadme()
09:56:53 <Alberth> could you please give me less than everything? It is so hard to find what you are talking about
09:57:05 <Alberth> and the pastebin is awful :p
09:59:16 <Alberth> and it does not have 'print*'
10:00:55 <Alberth> you cannot return NULL, as it is not a value of TarFileListEntry
10:01:13 <Alberth> (just like you cannot do bool b = "abc"
10:01:41 <LordAro> ok, but i'm not sure i should be useing TarFileListEntry in the first place
10:03:04 <Alberth> FioOpenFile needs it, doesn't it?
10:03:48 <LordAro> thats what i was thinking, but is the 'tar_entry' variable TarFileListEntry?
10:05:01 * Alberth looks for the type of _tar_filelist
10:06:36 <Alberth> ah, it's a typedef std::map<std::string, TarFileListEntry> TarFileList;
10:07:21 <Alberth> the second thing is what you want, which you can get from the iterator by (*iter).second iirc
10:07:50 <LordAro> so the function should be TarFile List?
10:07:51 <Alberth> if iter != _tar_filelist.end() of course
10:08:11 <LordAro> or do i convert in the function?
10:09:02 <Alberth> you can either return the iterator, or return a pointer to the TarfileListEntry
10:09:57 <Alberth> and since you have 2 functions that need that information, I'd make a new function that returns the value, then use that function in the two you already have
10:10:33 <Alberth> returning the pointer is better, returning the iterator is easier
10:11:47 <LordAro> how would i use (*iter).second? "avariable = tar_entry.(*iter).second" ?
10:11:54 <Alberth> (unless you understand pointers then the former is easier as well :D )
10:12:05 <LordAro> i don't understand pointers much :)
10:12:28 * LordAro seems to have developed a headache :L
10:12:50 <Alberth> (*iter).second is a value of type TarFileListEntry, so you can use it anywhere where you need such a value
10:13:39 <Alberth> for example in the FioOpenFile thingie
10:14:07 <Rubidium> what are you trying to do?
10:14:27 <Rubidium> sounds to me like you're looking for a readme.txt next to the newgrf, right?
10:14:38 <Alberth> getting the contents of the readme file out of a tar
10:15:49 <Rubidium> just use FioFOpenFile
10:16:52 <LordAro> Rubidium: not FioFOpenFileTar ?
10:18:10 <Rubidium> then it doesn't work if I place the newgrf and readme in a separate directory
10:18:52 * LordAro points blame at Alberth! :P
10:19:36 <Alberth> Rubidium is main OpenTTD developer for a reason :p
10:20:07 <Rubidium> not the last few months anymore :(
10:20:42 <Rubidium> still need to finish the CF
10:20:57 <Rubidium> but buildbot somewhat sucks
10:21:31 <Rubidium> so I'd need to 'fix' buildbot, or at least write massive amounts of code to get it to do what we'd like it to do
10:29:01 <LordAro> still not getting how to use (*iter).second
10:29:55 <Alberth> it is just a value, much like 1+2*3
10:30:38 <LordAro> but how do i associate it with tar_entry?
10:32:08 <Alberth> I just use a place holder name 'iter' here, as I don't have the source at the same screen as the IRC window, and I could not remember its precise name
10:32:31 <Alberth> sorry for the confusion
10:32:46 <LordAro> so (*tar_entry).second ?
10:33:22 <Alberth> yes, if (tar_entry != _tar_filelist.end())
10:33:38 <LordAro> thats there already :)
10:33:54 <LordAro> also, if i can't return NULL, what do i return?
10:33:59 <Alberth> if that condition does not hold, *tar_entry does not exist
10:35:14 <Alberth> but if you use FioOpenFile() as suggested by Rubidium, you don't need any of that
10:35:53 <LordAro> so what of your GrfHasReadme fucntion don't i need?
10:36:48 <Alberth> I have no idea at all
10:37:16 <Alberth> I have never used that function
10:37:58 <LordAro> or am i getting confused again?
10:38:23 <Alberth> I assume you need to create a path, so you can keep that part, I think.
10:38:45 <LordAro> it would help if some of the file thingy functions had some sort of documentation :)
10:42:44 <Alberth> I think there are at least 3 options now
10:43:08 <Alberth> 1. figure our how to use FioOpenFile (for example by looking how it is used)
10:43:32 <Alberth> 2. Use the tar-file approach I created for now
10:44:26 <Alberth> 3. Ignore the whole file loading problem, and start rendering text onto the window from a char *text="foo"; source, and do the file stuff later
10:45:19 <LordAro> i think 3, then 1, if 1 fails, 2 :)
11:17:44 *** HerzogDeXtEr has joined #openttd
11:30:35 *** TWerkhoven has joined #openttd
11:31:05 *** Kurimus has joined #openttd
11:49:24 *** Adambean has joined #openttd
12:08:02 *** frosch123 has joined #openttd
12:36:51 *** Absolutis has joined #openttd
12:37:02 *** Absolutis has left #openttd
13:04:42 <Ammler> LordAro: it should not autowrap (imo)
13:05:07 <LordAro> i'll get to that later ;)
13:05:34 <LordAro> because all that is at the moment is a const char* hard coded in
13:05:52 <Alberth> then you'll get those useless 1 line sentences where you can only read 5 of the 100 words
13:05:54 <Ammler> Alberth: not possible to horizontal scroll?
13:06:11 <glx> people will ask for a button to close the window ;)
13:06:14 <Alberth> it reads like shit imho
13:07:00 <Eddi|zuHause> planetmaker: the makefile doesn't seem to react on changes to generate.py
13:07:33 <Ammler> Alberth: how does autowrap handle idents?
13:08:12 <Eddi|zuHause> planetmaker: that's bad, because that's exactly what i need ;)
13:08:41 <Alberth> Eddi|zuHause: make clean && make
13:08:56 <planetmaker> Eddi|zuHause: pull
13:09:26 <Alberth> Ammler: not, really, unless you want to make a markup language.
13:09:50 <Alberth> note that autowrap is invisible if your lines are short enough
13:10:06 <Alberth> and you don't want to make really long lines anyway
13:13:45 <Ammler> and why is it just for newgrfs, couldn't the other contents use something like that too?
13:14:11 <Alberth> sure, I see no objection
13:14:18 <Alberth> LordAro: Suggestion! ^^
13:14:27 <Eddi|zuHause> planetmaker: seems to work better now
13:14:27 <planetmaker> it's more of a starting point, Ammler ;-)
13:14:49 *** keky___ has joined #openttd
13:15:03 <Eddi|zuHause> i hate how you cannot get "round" speed values :(
13:16:03 <LordAro> Ammler: i'll bother about Ais, Base sets, etc later! :)
13:20:14 <Eddi|zuHause> planetmaker: i have a new issue for you, i renamed english.lng to english.lng.in (in order to auto-fill it with engine names etc.)
13:20:30 <Eddi|zuHause> planetmaker: but now the makefile complains about lang/*.lng not existing
13:21:03 <planetmaker> right. How are they generated? By the same script?
13:21:41 <Eddi|zuHause> it takes the contents of english.lng.in, writes it into english.lng, and appends the engine names
13:25:14 <Eddi|zuHause> planetmaker: not really, it compiles, but starts out with this error message: "ls: Zugriff auf lang/*.lng nicht möglich: Datei oder Verzeichnis nicht gefunden", and you should probably also add lang/english.lng.in as dependency
13:27:13 <planetmaker> you're in the process of breaking all implicit assumptions, one after the other I put in the makefile framework ;-)
13:27:29 <Eddi|zuHause> yeah, i'm good at that ;)
13:28:17 *** supermop has joined #openttd
13:28:36 <planetmaker> Eddi|zuHause: could the language files be generated separately?
13:29:12 <Eddi|zuHause> planetmaker: i could write the strings to a temporary file, which gets merged with the lang file later
13:29:48 <planetmaker> nah, I meant rather a separate script. But I gues... not handy. Would need parsing the same file twice
13:29:54 <planetmaker> or is it done anyway?
13:31:42 <planetmaker> nope isn't. Ok...
13:32:02 <planetmaker> Eddi|zuHause: the patch I posted will work. As workaround.
13:32:16 <planetmaker> one can add english.lng.in to the deps in the same line in the makefile
13:32:34 <planetmaker> fixing the error you see is more work. But afaik it's not critical
13:32:46 <planetmaker> the grf builds for you with the patch, does it?
13:41:16 <Eddi|zuHause> yes, the grf builds
13:41:27 <Eddi|zuHause> and that link gives a 404
13:41:35 <Eddi|zuHause> hm, no that's my fault
13:43:12 <Eddi|zuHause> planetmaker: should that be scripts/generate.py in that last part of the patch?
13:43:59 <planetmaker> hm, I guess I found an easy solution
13:44:43 <Eddi|zuHause> patch unexpectedly ends in middle of line
13:44:44 <Eddi|zuHause> patch: **** malformed patch at line 22:
13:47:00 <Eddi|zuHause> anyway... something's completely wrong with the units
13:47:16 <Eddi|zuHause> the power is too small and the tractive effort is too high...
13:48:06 <Eddi|zuHause> planetmaker: do you have code to disable all original vehicles?
13:49:01 <planetmaker> no/* disable all monorail and maglev vehicles */
13:49:03 <planetmaker> disable(FEAT_TRAINS, 54, 115);
13:49:39 <planetmaker> disable_item(feature[, first_id[, last_id]]);
13:49:47 <Hirundo> disable_item(feature[, first_id[, last_id]]);
13:50:11 <Hirundo> so without any ids, you disable all items of feature X
13:52:18 <Eddi|zuHause> units are heavily underdocumented
13:58:59 <Eddi|zuHause> something is wrong with the availability code... choosing "extended" disables all "core" engines...
14:02:25 *** sla_ro|master has joined #openttd
14:08:52 *** LordPixaII has joined #openttd
14:11:06 <planetmaker> Eddi|zuHause: pull
14:14:09 <Eddi|zuHause> seems to work ;)
14:14:37 <Eddi|zuHause> where does the tractive effort come from? it's too high for the steam engines
14:16:30 <planetmaker> in the tracking table? I thought you knew where those values come from
14:17:00 <Eddi|zuHause> it's not directly set in generate.py it seems
14:17:09 <Eddi|zuHause> (i copied that from the dummy engine)
14:19:18 *** supermop has joined #openttd
14:20:00 <Eddi|zuHause> seems i need to calculate the coefficient
14:20:16 <Eddi|zuHause> cannot directly set the value
14:20:26 <supermop> alwas nice to calculate some coefficients
14:20:38 <supermop> are you patching RVs?
14:22:30 <supermop> what else has a coefficient
14:22:44 <supermop> just doing some physics for fun?
14:25:03 <planetmaker> the garment of your clothes also has a coefficient of friction
14:25:28 <planetmaker> luckily the frictional force is larger than the gravitational
14:27:46 <Eddi|zuHause> better now, i think ;)
14:43:21 *** |Jeroen| has joined #openttd
14:49:22 *** SpComb^_ has joined #openttd
15:20:02 <planetmaker> Eddi|zuHause: such rounding should not be needed
15:20:23 <Eddi|zuHause> planetmaker: but i hate the "99 km/h" value that openttd displays
15:20:30 <planetmaker> if so it's an NML bug
15:20:41 <planetmaker> as 100 in NML should give 100 in OpenTTD
15:21:02 <Eddi|zuHause> it's an openttd bug. internal grf value of 100 (mph*1.6) gets converted into 99 km/h
15:21:31 <Eddi|zuHause> that is a gui issue
15:21:39 <Eddi|zuHause> that exists since the beginning of time
15:21:52 <Eddi|zuHause> it was fixed once, but apparently some grf authors complained
15:21:59 <Eddi|zuHause> so it was "unfixed"
15:23:15 <Eddi|zuHause> nml also has some crazy conversion factor, that i don't really understand...
15:23:52 *** Notapipe has joined #openttd
15:23:53 <planetmaker> hp != kW if you mean that
15:23:57 <Eddi|zuHause> its conversion factor from m/s to "internal nfo units" is 3.5790976
15:24:46 <planetmaker> nml internal units != nfo units
15:24:51 <Eddi|zuHause> so if you give unit "km/h" it converts it to "m/s" (3.6) and then to "internal nfo units (mph*1.6)" (3.5790976)
15:25:16 <Eddi|zuHause> yes, nml internal unit is m/s
15:25:34 <planetmaker> and the conversion factor km/h to m/s is exactly 3.6
15:25:45 <planetmaker> see nml/nml/units.py
15:25:54 <Eddi|zuHause> i looked at that
15:26:26 <Eddi|zuHause> and in nml/nml/actions/action0properties.py there is the other conversion factor
15:26:32 <Eddi|zuHause> from m/s to "nfo units"
15:26:59 <planetmaker> yes. as km/h-ish != km/h
15:27:07 <planetmaker> and km/h-ish is the NFO unit
15:27:22 <Eddi|zuHause> yes. and this discrepancy is the annoying part
15:27:31 <Eddi|zuHause> too many rounding issues
15:27:45 <planetmaker> yes. and NML tries to compensate that by using this conversion factor
15:27:56 <Eddi|zuHause> "it doesn't work"
15:28:08 <Eddi|zuHause> i now tell nml to use the nfo units
15:28:58 <Eddi|zuHause> and the "correction" to get better display values for certain corner cases
15:29:30 <Eddi|zuHause> you can't get openttd to display 100km/h
15:29:36 <Eddi|zuHause> either 99km/h or 101km/h
15:30:09 <Eddi|zuHause> the granularity is not high enough
15:30:42 <Eddi|zuHause> the correction i did was to make sure it picks the higher value
15:32:13 <planetmaker> ah, right, that was the issue
15:32:26 <planetmaker> and NML's conversion factor is the best you can do
15:32:58 <planetmaker> but gives you in this case(s) rather the lower than higher value
15:32:59 <Hirundo> I guess it's a limitation in the nfo specs
15:34:18 <Hirundo> nfo v8 is about as elusive as *certain* newgrfs
15:34:54 <Eddi|zuHause> i vaguely remember a patch that changed some rounding issues wrt displaying the mph*1.6->km/h conversion
15:35:04 <Eddi|zuHause> that would also fix the 100km/h issue
15:42:30 <Terkhen> that's a openttd bug, yes
15:42:53 <Terkhen> IIRC it was fixed and then reverted because it "modified" newgrfs
15:43:07 <Eddi|zuHause> yes. something like that
15:44:11 <Eddi|zuHause> @opentt log r4322
15:44:13 <Eddi|zuHause> @openttd log r4322
15:44:33 <Eddi|zuHause> @openttd commit r4322
15:44:33 <DorpsGek> Eddi|zuHause: Invalid arguments for _commit.
15:44:38 <Eddi|zuHause> @openttd commit 4322
15:44:38 <DorpsGek> Eddi|zuHause: Commit by peter1138 :: r4322 /trunk (7 files) (2006-04-08 12:04:23 UTC)
15:44:40 <DorpsGek> Eddi|zuHause: - Codechange: Remove conversion of kmh to mph from gui code to within the units conversion system, in string.c. This means displaying kmh requires no conversion, instead of being convert from kmh to mph, and then back to kmh again.
15:44:56 <Eddi|zuHause> @openttd commit 8464
15:44:56 <DorpsGek> Eddi|zuHause: Commit by peter1138 :: r8464 /trunk/src (6 files) (2007-01-30 21:10:04 UTC)
15:44:58 <DorpsGek> Eddi|zuHause: -Revert (r4322): Change back to converting to mph in the GUI code, as 1 mph == 1.6 km/h is too far out for some people.
15:53:52 *** devilsadvocate has quit IRC
15:54:22 *** supermop has joined #openttd
15:54:22 *** Adambean has joined #openttd
15:54:22 *** Biolunar has joined #openttd
15:54:22 *** TinoDidriksen has joined #openttd
15:54:22 *** Scuddles has joined #openttd
15:54:22 *** Eddi|zuHause has joined #openttd
15:54:22 *** minecraftfan has joined #openttd
15:54:22 *** Rubidium has joined #openttd
15:54:22 *** Belugas has joined #openttd
15:54:22 *** devilsadvocate has joined #openttd
15:54:22 *** ThaAmazonous has joined #openttd
15:54:22 *** SirSquidness has joined #openttd
15:54:22 *** jonty-comp has joined #openttd
15:54:22 *** Blacklite has joined #openttd
15:54:22 *** PierreW has joined #openttd
15:54:22 *** tparker has joined #openttd
15:54:22 *** mikegrb has joined #openttd
15:54:22 *** Born_Acorn has joined #openttd
15:54:22 *** dotwaffle has joined #openttd
15:54:22 *** confound has joined #openttd
15:54:22 *** resistance.oftc.net sets mode: +oo Belugas orudge
15:54:51 *** ChanServ sets mode: +v Alberth
15:54:51 *** ChanServ sets mode: +v Terkhen
16:00:14 *** Polygon has joined #openttd
16:03:30 *** Chris_Booth[ph] has joined #openttd
16:05:13 *** Chris_Booth[ph] has quit IRC
16:12:02 <LordAro> should ignore people that complain about that imo
16:30:17 <Eddi|zuHause> feature request: double clicking on a GRF in the active GRF list should open the parameter window, not remove it from the list
16:31:40 <planetmaker> not sure I'd like that
16:31:48 <planetmaker> it'd break UI consistency
16:32:04 <planetmaker> and for configuration I need remove as much as add
16:32:51 <frosch123> it was like that in the old gui :p
16:32:58 <Eddi|zuHause> the parameter button is _very_ far away
16:33:08 <Eddi|zuHause> lots of mouse movement involved
16:33:38 <planetmaker> I'd go for some key+click
16:34:46 <Eddi|zuHause> something's not right with my TE calculation
16:35:24 <Eddi|zuHause> some engines get too little
16:36:15 <Eddi|zuHause> the 132 has 419 given in the table, but gets only 371 in the game
16:36:47 <Eddi|zuHause> but the V200(O) has 395 given in the table and gets 399 in the game
16:43:41 *** TWerkhoven has joined #openttd
16:51:57 <LordAro> please don't make too many modifications to that area of the code! :) i don't want my patch broken before it's even finished...
16:52:36 <Eddi|zuHause> you don't even know what code i am modifying.
16:54:36 <__ln__> would it be nice to have a sandworm-disaster in the desert climate?
16:54:57 <Eddi|zuHause> only if you make a total dune conversion set
16:55:12 <LordAro> Eddi|zuHause: i was talking about the newgrf parameter window stuff
17:09:50 *** Adambean` has joined #openttd
17:26:59 <planetmaker> we need to do something about the purchase list sprites, eh?
17:28:01 *** fjb is now known as Guest2412
17:28:21 *** supermop_ has joined #openttd
17:45:06 <Eddi|zuHause> planetmaker: yep ;)
17:45:23 <CIA-2> OpenTTD: translators * r22667 /trunk/src/lang/belarusian.txt:
17:45:23 <CIA-2> OpenTTD: -Update from WebTranslator v3.0:
17:45:23 <CIA-2> OpenTTD: belarusian - 6 changes by Wowanxm
17:45:57 <Eddi|zuHause> lots of things to do left ;)
17:54:11 * frosch123 wonders what is broken
17:58:25 <frosch123> is it normal that opengfx+trains results in ridicilous cheap engines?
18:02:56 <supermop_> openttd developers giving you a subsidy to buy their equipment?
18:03:29 <Alberth> he is very capable of doing that himself :p
18:04:04 <frosch123> hmm, it works if i use an official release
18:04:23 <frosch123> the version whichever i found on my machine is broken :p
18:04:32 <frosch123> resp. the nml version used to compile it was broken
18:04:39 <frosch123> let's update and recheck
18:05:29 <Alberth> or the nml semantics has changed :p
18:07:14 <frosch123> anyway, updating both nml and the grf seems to fix it
18:07:57 <frosch123> luckily i can change grfs in game :p
18:27:06 <Eddi|zuHause> planetmaker: actually, i am really wondering why it doesn't show the straight sprite. where is the gui sprite chosen?
18:33:19 <planetmaker> Eddi|zuHause: without looking at source: IIRC it's the 3rd sprite
18:33:40 <planetmaker> which of course in our case... is different
18:34:06 <CIA-2> OpenTTD: alberth * r22668 /trunk/src/fileio.cpp: -Codechange: FioFindFullPath tests already whether the file exists.
18:34:20 <Eddi|zuHause> planetmaker: yes, but it seems to pick the wrong spriteset
18:34:39 <Eddi|zuHause> one where var45 isn't 0
18:35:54 <planetmaker> but the reason is: curvature info is not available in purchase list
18:36:11 <planetmaker> thus we need to provide extra purchase list sprites
18:36:23 <Eddi|zuHause> well, yes, but why would it be non-0?
18:36:41 <planetmaker> undefined = anything?
18:38:04 <frosch123> you cannot rely on any value, support for it might be added
18:38:08 <planetmaker> another thing, Eddi|zuHause: we probably want to provide some manual sorting to the generate.py script by companies
18:38:16 <frosch123> that's why all sets of djnekkid will break at some point :p
18:38:19 <planetmaker> currently the prussian trains show last... which is unfortunate
18:38:41 <Eddi|zuHause> yes, the sorting is kinda crude :p
18:38:45 <planetmaker> frosch123: what does he use?
18:39:11 <frosch123> he uses undefined variables to check whether he is in purchase list
18:39:16 <Eddi|zuHause> planetmaker: feel free to provide a sort function :)
18:39:36 <frosch123> as he does not want to branch the purchase list case in action3
18:40:27 <planetmaker> Currently I ponder though: add purchase list sprite support to CETS, continue with the setup script for new NewGRF repositories or... something entirely different ;-)
18:40:40 <planetmaker> frosch123: uh... that's... "interesting"
18:40:59 <planetmaker> maybe I should try to convince him. But he's not around much lately anymore
18:41:21 <frosch123> hehe, i already told him, unfortunatelly he keeps on recommending that method to others :p
18:41:45 <frosch123> so, the better plan is to break it at some point :p
18:42:02 <planetmaker> hm, I recall faintly, somewhen the last three weeks or so there was something. Did you tell him that his stuff might break
18:42:14 <Eddi|zuHause> one more reason to finally code this extra callback info whether it's a GUI sprite or not
18:42:19 <frosch123> no, it is likely years ago
18:43:09 <planetmaker> may I rephrase you? :-P
18:43:19 <planetmaker> Eddi|zuHause: ^ ? ;-)
18:43:24 <CIA-2> OpenTTD: alberth * r22669 /trunk/src/ (fileio.cpp string.cpp string_func.h): -Codechange: For non-windows, only test for file existence again if strtolower actually changed the name.
18:45:23 <Eddi|zuHause> planetmaker: what?
18:47:16 <planetmaker> [20:39] Eddi|zuHause planetmaker: feel free to provide a sort function :) | sed "s/planetmaker/Eddi/g"
18:47:44 <planetmaker> yes, yes, I know ;-)
18:48:06 <Eddi|zuHause> planetmaker: we might sort on epoch first, but that makes the code more complicated
18:48:27 <Eddi|zuHause> s/first/afterwards/
18:48:41 <planetmaker> I thought about defining the company order
18:48:46 <Alberth> epoch is constant, very easy to sort :)
18:48:46 <planetmaker> that'd do the trick mostly
18:49:02 <planetmaker> i.e. not alphabetic company order but custom-defined
18:49:21 <Eddi|zuHause> planetmaker: that's easier to code
18:49:45 <planetmaker> and mind... each time we change vehicle order currently we break newgrf compatibility
18:49:50 <planetmaker> as vehicleIDs change
18:49:52 <Eddi|zuHause> but needs modification every time we extend the set ;)
18:50:21 <Eddi|zuHause> planetmaker: that's difficult to keep static
18:50:24 *** confound has joined #openttd
18:50:25 <planetmaker> Eddi|zuHause: sorting by company IMHO is a good thing here
18:50:50 <planetmaker> And... suggestion vehicleID: add them to the tracking table. Currently a continuous number
18:50:57 <planetmaker> then we won't ever break that
18:51:13 <Eddi|zuHause> yep, that's probably the only useful method
18:51:52 <planetmaker> and it will be quite convenient to not break it on every added vehicle ;-)
18:52:07 <planetmaker> (or removed or...)
18:52:39 <planetmaker> I should finish my sprite sets templates etc for cets
18:54:47 <LordAro> Alberth: i'm guessing those 2 commits will be useful to me in some way... :D
18:56:34 <Alberth> the former saves one FileExists test, the latter only has an impact on non-windows systems
18:57:13 <LordAro> well they look useful, and i didn't know about them before :)
18:58:15 <LordAro> rephrase: i'm guessing that the 2 functions you just modified will be useful to me in some way... ;)
19:00:45 <Alberth> that would be an interesting use :)
19:06:32 <LordAro> (note: i haven't actually lookout at the changeset, i'm just saying this judging from the commit message :) )
19:45:07 *** ar3k is now known as ar3kaw
20:12:33 *** Brianetta has joined #openttd
20:24:52 <Eddi|zuHause> planetmaker: manual sort order should work now
20:25:20 <Eddi|zuHause> planetmaker: unspecified companies will appear in the order they are in the tracking table
21:01:42 *** Polygon has joined #openttd
21:42:40 *** douknoukem has joined #openttd
21:51:54 <planetmaker> hm... Eddi|zuHause I only get the new sprites in the purchase list, not anymore in depots and on the tracks...
21:52:25 <Eddi|zuHause> planetmaker: weird
21:53:52 <planetmaker> hm... hold on. For some. For others not
21:54:27 <Eddi|zuHause> any examples in particular?
21:56:50 <planetmaker> from Prussia: all except the first
21:58:24 <confound> from Prussia with love
22:00:06 <Eddi|zuHause> the lengths are wrong as well
22:00:53 <Eddi|zuHause> i'll investigate that. it's not immediately obvious
22:01:19 <planetmaker> indeed. I'm off to bed now though, so have a good night :-)
22:03:48 <Eddi|zuHause> hm. might be the articulated callback result
22:04:09 <Eddi|zuHause> it might be invalid for some vehicle IDs
22:06:10 <planetmaker> oh... drat. only the first 0x80 may be articulated afair
22:06:28 *** ar3k is now known as ar3kaw
22:09:41 <Eddi|zuHause> there may be ways around it, with my var60+ patch
22:29:45 <Eddi|zuHause> hm... if this is the articulated callback, there is absolutely no reason why exactly this vehicle should work
22:31:36 <Eddi|zuHause> oh, looked in the wrong place
22:31:48 <Eddi|zuHause> yes, this seems to be one of the few IDs below 0x80
23:58:34 *** supermop has joined #openttd
continue to next day ⏵
