Times are UTC Toggle Colours
03:04:56 *** Supercheese has joined #openttd.dev 07:47:33 *** Supercheese has quit IRC 12:55:47 *** ntoskrnl has joined #openttd.dev 13:31:32 *** Ristovski has joined #openttd.dev 15:10:50 *** frosch123 has joined #openttd.dev 15:10:50 *** ChanServ sets mode: +v frosch123 15:36:36 *** Zuu has joined #openttd.dev 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 musad.py 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 openttd.org 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 #openttd.dev 16:55:19 *** ChanServ sets mode: +v Alberth 17:16:37 <Zuu> Hmm, I've made a copy of musad.py 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 musad.py? 17:42:57 *** DorpsGek changes topic to "OpenTTD Dev Channel || Latest SVN: r25171 || Logs: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 18:17:08 <Rubidium> Zuu: http://paste.openttdcoop.org/show/2218/ <- 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: http://devs.openttd.org/~zuu/musad.patch 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: http://webster.openttdcoop.org/?channel=openttd.dev || Voice (talk-right) upon request via #openttd; make sure you are registered to NickServ before asking" 19:09:36 <Zuu> http://devs.openttd.org/~zuu/musa-dep-fix.patch <---- 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: http://devs.openttd.org/~zuu/musa-fix3.patch 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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: http://webster.openttdcoop.org/?channel=openttd.dev || 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> http://paste.openttdcoop.org/show/2219/ <- 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 depgen.py 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 musa.py. 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 depgen.py 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 musad.py 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 #openttd.dev 20:47:46 *** Alberth has left #openttd.dev 21:02:09 *** frosch123 has quit IRC 21:23:30 *** Ristovski has quit IRC 22:23:04 *** Supercheese has joined #openttd.dev 23:00:50 *** Zuu has quit IRC