Log for on 9th April 2013:
Times are UTC Toggle Colours
03:04:56  *** Supercheese has joined
07:47:33  *** Supercheese has quit IRC
12:55:47  *** ntoskrnl has joined
13:31:32  *** Ristovski has joined
15:10:50  *** frosch123 has joined
15:10:50  *** ChanServ sets mode: +v frosch123
15:36:36  *** Zuu has joined
15:36:36  *** ChanServ sets mode: +v Zuu
16:28:07  *** Ristovski has quit IRC
16:45:53  <Zuu> I haven't been able to set up my own server. Or well I did, but it was not able to set up an SSL socket for incomming connections. So instead I tried to upload to the usual musa server, but from Linux. This results in almost the same error as from windows. The difference is probably in the different underlying SSL stacks.
16:47:06  <Zuu> I also tried to untar the tar file created in Linux. It do look better than opening the windows tar in 7zip. However I also did upload a tar made in windows to my Linux VM and untared it there. Then both tars look equal.
16:47:16  <Zuu> When untaring both these I get this interesting error:
16:47:17  <Zuu> tar: Beginner_Tutorial__Ship_AI-14\license.txt: implausibly old time stamp 1970-01-01 01:00:00
16:55:19  *** Alberth has joined
16:55:19  *** ChanServ sets mode: +v Alberth
17:16:37  <Zuu> Hmm, I've made a copy of where I've stripped out all server related code and make it just load a local tar file and validate that. This validation works fine. :-(
17:20:14  <Zuu> I do however currently not get the missing license.txt error but an error that indicate that the server caught an exception over there.
17:20:33  <Zuu> Rubidium: Could you get the last stack trace/error from
17:42:57  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25171 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
18:17:08  <Rubidium> Zuu: <- not really useful...
18:17:30  <Rubidium> I've restarted it now
18:21:50  <Zuu> Oh, upload from Linux suceeded
18:23:28  <Zuu> Now I lost my test case :-p
18:23:57  <frosch123> :p
18:32:14  <Zuu> Hmm, there are no deps in my bananas manager. And this SQL looks like it inserts reverse deps:
18:32:15  <Zuu> 			db_conn.query("INSERT INTO bananas_file_deps (from_file_id, to_file_id) VALUES (%d, %d)" % (dep_id, file_id))
18:32:41  <Zuu> file_id is the new file that get uploaded from what I can see.
18:33:45  <Zuu> Unless the bananas_file_deps table is all reverse, it looks like musad. just made it so that SuperLib 27 depends on Tutorial Ship AI and not the other way around.
18:34:13  <Zuu> Eh.. yes my bananas manager confirms that.
18:34:33  <Zuu> Now you get the Tutorial Ship AI when you download SuperLib 27. :-D
18:36:55  <Zuu> Fix:
18:45:55  <Zuu> Anyway, the reason why I need musa is mainly to set dependencies for a scenario. Dependencies that should be possible to deduce from the .scn file. An alternative to promoting musa for complex scenarios would be to allow bananas to open an uploaded .scn and scan it for dependencies. I would guess that it can get md5sum and uniqueid of both NewGRFs and AIs/GSs. Or would it too expansive in CPU usage for the server?
18:46:19  <Zuu> Since .scn/.sav is compresed, I guess it is not just to read the header of the file?
18:47:11  *** ntoskrnl has quit IRC
18:48:13  <frosch123> i would think i have half for that in c
18:48:38  <frosch123> you need to decompress the save and then parse it to get the right newgrf resp. ai chunks
18:49:05  <frosch123> luckily you can skip unknown chunks though, so it would not have to know the whole save format :p
18:49:53  <Zuu> The question is, if someone upload a 2048x2048 scenario, will that make the server go on its knes?
18:50:11  <frosch123> it might take a second to decompress
18:50:26  <frosch123> but there are not 10 uploads per second :p
18:50:52  <Rubidium> (or 10 a day)
18:50:58  <Zuu> right, so it sounds possible then from performance point of view.
18:51:51  <Zuu> And it will do the right thing for users who may not have all the knowledge to get musa dependencies right.
18:51:53  <Rubidium> Zuu: you added one thing with two deps, right?
18:52:00  <Zuu> Rubidium: Yes
18:52:23  <Rubidium> then the deps should be inverted now
18:52:24  <Zuu> It was supposed to dep on SuperLib 27 (for AIs) and MetaLibrary 5.1.
18:52:48  <Zuu> Rubidium: Thanks for clearing up the mess
18:53:12  <Zuu> Looks good in my bananas manager view
18:55:08  <frosch123> Zuu: unfortunately the saves have no md5sum of ais
18:55:12  <frosch123> only the name and the version
18:55:40  <Zuu> frosch123: name as in 4 char short name?
18:55:52  <frosch123> i believe long name
18:56:00  <Zuu> That is even worse...
18:56:01  <frosch123> that is also used in openttd.cfg after all
18:56:40  <frosch123> hmm, yeah, what was the 4 char id added for, when not for saves?
18:56:41  <Zuu> From the short name we have a direct conversion to the uniqueid which is stored in the database.
18:57:08  <frosch123> maybe that is also the reason why we still do not have any "download missing ai/gs" :p
18:57:31  <Zuu> Shift each of the 4 ansi chars  into a uint32 to get the uniqueid.
18:59:44  <Rubidium> Zuu: I reckon the musad SQL fix is okay ;)
18:59:45  <Zuu> Perhaps adding the AI/GS uniqueid/shortname + md5sum to the savegame format is a good thing so that we could in the future offer dependency auto-detection for scenarios.
18:59:59  <frosch123> yup :)
19:00:13  <Zuu> Of course that will only work for scenarios created after this change.
19:00:24  <Rubidium> s/created/saved/
19:01:03  <Zuu> So, everyone who target OpenTTD 1.4+ will be able to use it. Which should be fine.
19:03:09  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25172 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:09:36  <Zuu>  <---- fixes musa client so that it properly encode AI/GS dependencies. (otherwise uploading content that depend on any script will fail)
19:10:18  <Zuu> However, you also need this client patch which fixes the client so that it doesn't remove the temporary tar file until it has been uploaded:
19:10:36  <Zuu> :-)
19:13:24  <Zuu> Rubidium: Let me know when you have applied the musad.patch and restarted it so I don't create more mess untill it has been fixed. :-)
19:14:38  <Rubidium> I just svn-up-ed and restarted r25172
19:20:52  <Rubidium> Zuu: the dep looks okay, except you add another newline at the end which doesn't seeem necessary
19:23:33  <Rubidium> did it remove the file too early? Stupid crappy Windows making things harder than needed
19:23:59  <Rubidium> it's really a nuisance that we have to account for it, when it could also work "just right"
19:24:01  <Zuu> The reason it removed it too early was a mistake on my side.
19:24:20  <Rubidium> ... triggered by needed to frack with it because of Windows
19:24:28  <Zuu> yes
19:24:30  <Rubidium> anyhow, it looks okay
19:27:01  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25173 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:30:36  *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25174 || Logs: || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking"
19:52:07  <Zuu> I think we just got our first scenario on bananas which depends on a NewGRF. However, it is broken (it doesn't contain a .id nor a .title file which I apparently forgot to add)
19:52:36  <Zuu> The musa packaged GS is also broken as the lang files have been added to its root rather than into a lang sub directory.
19:55:24  <frosch123> <- Zuu: something like that?
19:56:22  <frosch123> ah, grfid is again the wrong way around :p
19:56:23  <Zuu> frosch123: The first 3 parts for NewGRF looks exactly what is needed.
19:57:07  <frosch123> well, there is currently no more for gs and ai :)
19:57:31  <Zuu> frosch123: Did you see the that I commited to musa recently? It should pull out type, uniqueid and md5sum from any tar from bananas.
19:58:05  <Zuu> It do however not help you in the task to get gs/ai data, but may be useful for verification.
19:58:09  <frosch123> well, that does not help on the server, does it?
19:58:15  <Zuu> No
19:58:56  <Zuu> It was just an utility for constructing a recipie for However, if we detect deps on the server, then this utility is useless.
19:59:47  <frosch123> you still need it for libraries
20:01:22  <frosch123> actually, gs/ai libs are loaded via name + version as well, aren't they?
20:01:27  <Zuu> Yes, when the GS/AI subdirectory packing error is solved, it should be possible to upload AIs/GSs that depend on old libraries. And in that case will be useful to compute the dependency declaration for those libraries.
20:02:03  <frosch123> so, maybe the server could be able to resolve ai/gs name + version into content it as well?
20:02:13  <frosch123> then it can also detect ai/GS libs
20:02:57  <Zuu> I am usure if the AI/GS long name is forced to be unique. But if it is used for loading, I guess so.
20:03:26  <frosch123> well, the shortname seems to be only used for bananas :p
20:03:36  <frosch123> both saveload and library load use long name :p
20:04:34  <Zuu> I shall check if musa enforce no long name change. The current bananas web UI do not allow name change.
20:11:29  <frosch123> do you think reading "import" stuff from .nut files is feasible? or would it involve higher magic with comments and such?
20:12:43  <Zuu> Hmm, I cannot see that impose a limit that you may not rename your content.
20:15:15  <Zuu> frosch123: We could read import stuff from *.nut. That will probably work in 98% of all scripts. Some 2% of the scirpts may use global variables with scirpt names that they pass to import() or some other magic that is hard to parse without executing the Squirrel code.
20:16:12  <Zuu> We could detect if someone call import() and check that they at least declare one dependency. Or if bananas get a preview step, display warnings if we think that the imports and dependencies don't match.
20:17:17  <Zuu> If someone use if( /* check OpenTTD version *) { import("some lib", 1); } else { import("some lib", 2); }, trying to automagically detect libraries will fail.
20:17:18  <frosch123> well, i would rather think: if bananas would detect dependencies itself, it could encourage authors to use a format which bananas can parse :)
20:17:30  <Zuu> Yes that is possible
20:18:22  <Zuu> We can even force authors to follow a certain format that is a subset of what Squirrel is capable of doing in order to upload to bananas.
20:18:41  <Zuu> Eg. Only import using literal strings.
20:19:26  <frosch123> i think "enforcing" is not necessary. rather detect what you can detect. and the author has to add the rest
20:20:31  <Zuu> The enforced way will not require a preview step for bananas. And getting changes into bananas web UI seem to be a bottle neck. So a solution that needs less changes there may still be favorable.
20:23:12  <Zuu> But yes, doing it in a non-enforced way may still give the same result as most users probably will stick to the defined format to get automatic deps.
20:24:09  <Zuu> And any auto-detection of deps should probably require a preview step in the bananas UI that the uploader need to confirm before data is saved.
20:24:55  <Zuu> Or just allow editing it afterwards? hmm we already allow edits, so no preview is really needed.
20:30:59  *** Ristovski has joined
20:47:46  *** Alberth has left
21:02:09  *** frosch123 has quit IRC
21:23:30  *** Ristovski has quit IRC
22:23:04  *** Supercheese has joined
23:00:50  *** Zuu has quit IRC

Powered by YARRSTE version: svn-trunk