Workshop Uploader issue under Linux

[simplex]

Just now I tried updating one of my mods at the Workshop, NoWarning, and the uploader seemingly pushed the new data directory with no issues. However, upon subscribing to the mod to see if everything was in order, to my suprise I was getting the files for another mod I have at the workshop instead, Blackhouse.

I tried uploading the mod again after renaming the data folder and putting it elsewhere, but the issue remains. I have no idea what might be going on (there are no symbolic links in the data folder, but even if that were the case I'm getting the Workshop files for Blackhouse, not its development directory or anything like that).

For the moment, I just set the visibility of the mod to hidden, but the current subscribers will receive a mod they didn't subscribe to. I just don't think having them search for and subscribe to it again would be ideal.

Any information on this issue, or how to handle this situation, would be most appreciated.

EDIT: Blackhouse is the first of my mods in alphabetical order (appearing first in the uploader list).

EDIT 2: The data size marked for the supposedly updated version of NoWarning is 36064 bytes (the same size as Blackhouse's), as opposed to the size of the folder I am trying to upload, which is 26619 bytes.

EDIT 3: Unsubscribing from the public preview version of the Mod Tools fixed the issue (after trying to upload the data folder again). I hope the public preview doesn't make it to release, Cheerio (or Brook). ;P

Edited November 17, 2013 by simplex

[Cheerio]

Just now I tried updating one of my mods at the Workshop, NoWarning, and the uploader seemingly pushed the new data directory with no issues. However, upon subscribing to the mod to see if everything was in order, to my suprise I was getting the files for another mod I have at the workshop instead, Blackhouse.

I tried uploading the mod again after renaming the data folder and putting it elsewhere, but the issue remains. I have no idea what might be going on (there are no symbolic links in the data folder, but even if that were the case I'm getting the Workshop files for Blackhouse, not its development directory or anything like that).

For the moment, I just set the visibility of the mod to hidden, but the current subscribers will receive a mod they didn't subscribe to. I just don't think having them search for and subscribe to it again would be ideal.

Any information on this issue, or how to handle this situation, would be most appreciated.

EDIT: Blackhouse is the first of my mods in alphabetical order (appearing first in the uploader list).

EDIT 2: The data size marked for the supposedly updated version of NoWarning is 36064 bytes (the same size as Blackhouse's), as opposed to the size of the folder I am trying to upload, which is 26619 bytes.

EDIT 3: Unsubscribing from the public preview version of the Mod Tools fixed the issue (after trying to upload the data folder again). I hope the public preview doesn't make it to release, Cheerio (or Brook). ;P

Is there any chance you changed something in the mod tools?  I just checked Steam and the public preview and the release version are identical on all platforms.  Any chance switching it basically triggered a cache verify for the mod tools?

[simplex]

@Brook

While the non-beta version of the Workshop Uploader seems to be properly uploading the data files, a similar issue to the beta one happens for the preview image: instead of using the image I selected to upload, the preview image I had previously uploaded to another one of my Workshop mods (this time Tallbrood) was used...

There's also the secondary issue that the uploader rejects this perfectly valid modinfo.lua file:

local icon_stem = "modicon"name = "Compromising Survival"id = "compromisingsurvival"version = "1.0"author = "simplex"forumthread = "/files/file/386-compromising-survival/"if icon_stem then	icon = icon_stem .. ".tex"	icon_atlas = icon_stem .. ".xml"endapi_version = 4description = ([[Upon death, politely asks if you *really* want to die.Icon by Willette.]]):gsub("^%s+", ""):gsub("%s+$", "")return icon_stem

If you're not going to embed a Lua interpreter in the uploader, at least don't raise an error upon failing to parse (or don't parse it at all...).

@Cheerio

Just verified cache, everything's fine.

Edited November 17, 2013 by simplex

[simplex]

An update on the image uploading issue: after trying to reupload the image at least a dozen times (keeping the mod visibility as hidden), always getting the Tallbrood preview image instead, it finally worked correctly. So the uploader is functioning erratically (both for preview images and code, apparently, since the regular and public preview versions are the same).

One more thing: Tallbrood is my last mod in alphabetical order (the last on the uploader list), so it looks like this is an issue with the extremes of the mod list.

Edited November 18, 2013 by simplex

[Brook]

An update on the image uploading issue: after trying to reupload the image at least a dozen times (keeping the mod visibility as hidden), always getting the Tallbrood preview image instead, it finally worked correctly. So the uploader is functioning erratically (both for preview images and code, apparently, since the regular and public preview versions are the same).

One more thing: Tallbrood is my last mod in alphabetical order (the last on the uploader list), so it looks like this is an issue with the extremes of the mod list.

 

As @Cheerio mentioned, the mod tools haven't changed since Oct 23rd, so there should be no binary differences between live and preview.

 

What I suspect is happening is that Steam Cloud is experiencing issues.  When you publish a mod, the files are first written to your private Steam Cloud storage and then a snapshot of those files in a specific state are published to the public workshop storage area.  Based on what you're describing, Steam is reporting to the mod uploader that this publish happened successfully (given that you didn't receive an error message), but on the server side something went awry and published the wrong revision of the file, a version that you had previously uploaded for a different mod.

 

I know it sounds like I'm passing the buck here, but this is consistent with Steam Cloud behaviour we've seen in the past.  I'll take a look from my end and let you know if I have any more information, but as you've already seen the solution is probably to wait and try again later. I would double check the mod uploader logs to verify that at least locally the uploader is sending the files that you expect.  It's highly unlikely that there is a mismatch between what the log says and what the mod uploader actually did, barring symlinks or other shenanigans.

 

Brook

[simplex]

As @Cheerio mentioned, the mod tools haven't changed since Oct 23rd, so there should be no binary differences between live and preview.

 

What I suspect is happening is that Steam Cloud is experiencing issues.  When you publish a mod, the files are first written to your private Steam Cloud storage and then a snapshot of those files in a specific state are published to the public workshop storage area.  Based on what you're describing, Steam is reporting to the mod uploader that this publish happened successfully (given that you didn't receive an error message), but on the server side something went awry and published the wrong revision of the file, a version that you had previously uploaded for a different mod.

 

I know it sounds like I'm passing the buck here, but this is consistent with Steam Cloud behaviour we've seen in the past.  I'll take a look from my end and let you know if I have any more information, but as you've already seen the solution is probably to wait and try again later. I would double check the mod uploader logs to verify that at least locally the uploader is sending the files that you expect.  It's highly unlikely that there is a mismatch between what the log says and what the mod uploader actually did, barring symlinks or other shenanigans.

 

Brook

I can assure you there were no shenanigans, as I use a Makefile to generate a snapshot of the distribution files (and them alone) in a completely clean "staging directory" before pushing that directory to the Workshop. But I think you're right about the issue being with Steam Cloud, since one of my No Warning users remarked this kind of issue does tend to happen sometimes in general, and additionally after having issues with these two mods I was able to push the rest without problems. Thank you for your attention, nevertheless.

But what about the modinfo.lua rejection, could you keep modinfo.lua parsing optional (through, say, a checkbox)?

Edited November 18, 2013 by simplex

[Brook]

But what about the modinfo.lua rejection, could you keep modinfo.lua parsing optional (through, say, a checkbox)?

 

While the modinfo.lua file is executed by the game, we consider this more of an implementation detail than anything else.  modinfo.lua should be thought of as a config file, not as a script.  The uploader does parse modinfo.lua with a lua interpreter (again as an implementation detail), but there are no libraries loaded, so gsub won't be available.  We currently feel this is working as intended. 

[seronis]

We currently feel this is working as intended. 

Well anyway to adjust those intentions to let those libraries be loaded? It would be interesting if things like the mods name or description could have dynamic info. A use case would be a holiday based mod that would tell you in the description what mode it would be running in.

 

Just a random thought

[simplex]

While the modinfo.lua file is executed by the game, we consider this more of an implementation detail than anything else.  modinfo.lua should be thought of as a config file, not as a script.  The uploader does parse modinfo.lua with a lua interpreter (again as an implementation detail), but there are no libraries loaded, so gsub won't be available.  We currently feel this is working as intended.

 

Well anyway to adjust those intentions to let those libraries be loaded? It would be interesting if things like the mods name or description could have dynamic info. A use case would be a holiday based mod that would tell you in the description what mode it would be running in.

 

Just a random thought

While it makes complete sense for modinfo.lua to run in an empty environment, things like string manipulation functions are certainly useful (especially since, provided the string submodule of the standard library is loaded, it can be considered an integral part of the language, even in an empty environment, since its entries can be called as methods of string objects). I just think the uploader should run modinfo.lua under the same conditions than the game, or not at all.

I hadn't faced this issue before because I don't usually write modinfos by hand, instead using scripts to generate them based on parameters exported by a Makefile, do the dynamicness is encapsulated in yet another layer of abstraction. But since this mod was considerably simpler, I felt that was overkill, so I went for the less involved solution of embedding that little dynamicness in modinfo.lua itself.

Edited November 18, 2013 by simplex

[simplex]

It would be interesting if things like the mods name or description could have dynamic info.

And oh, we can do that already. I wouldn't say it's a completely clean method, because it involves patching a method from ModIndex so that it won't reload modinfo.lua after the changes were applied, but it's certainly possible. I attached a sample mod (OnOff), which changes its name and icon according to whether it's enabled or not.

OnOff.zip

Edited November 19, 2013 by simplex