RELEASED [SMAPI] Lookup Anything

@BigE: you'd probably use MonoDevelop on Linux; 'release' is the build configuration (MonoDevelop » Project » Active Configuration » Release).

 

Here's the thing about the Linux version of SMAPI and what the problem is:

The Linux version of SMAPI was released BEFORE the Linux version of Stardew Valley. It is designed and intended to run through WINE (or through something that uses WINE like Crossover or PlayOnLinux).

There's currently an issue with WINE that you can run .NET 4.0, OR you can run .NET 4.5, but you can't do both. Stardew Valley runs on .NET 4.0. SMAPI runs on .NET 4.5.

The Linux version of SMAPI is compiled in .NET 4.0 to be able to be loaded up in WINE in the same instance as Stardew Valley. However, if you use any code which is in .NET 4.5 and not 4.0, it isn't going to be compatible with the Linux version of SMAPI.

That is the ONLY issue with the Linux version. No, you don't have to do it in MonoDevelop. No you don't have to do anything else fancy. Just make sure that your code runs under .NET 4.0 and you are golden. That's it.

 

1.2 is great! The hideonkeyup option works like a dream c: thanks a bunch Pathoschild!

 

@ShneekeyTheLost The build they are referring to was compiled under MonoDevelop, as was the Mac version. See this Github Issue post for more details.

 

@ShneekeyTheLost @foghorn: thanks for the input, but I'm confused about the current state of affairs.

It's my understanding that:

1. The game uses Mono instead of .NET Framework on Linux and Mac.
   
2. The game uses MonoGame instead of XNA on Linux and Mac.
3. There's no official Linux/Mac version of SMAPI. (There are unofficial forks compiled against MonoGame.)

If so, shouldn't porting a LookupAnything release to Linux involve the following steps?

1. Replace all Microsoft.Xna.* references with MonoGame.Framework.
2. Change the target framework to Mono.
3. Recompile on Linux.

 

Ahh, I thought they were referencing this one, which was developed for WINE and .NET 4.0.

That looks like it *should* work for most things, although the recompile necessary will be beyond most end-users. I might be able to do some compiling and testing and releasing working versions over the next week or so. That way the end-users won't have to, and neither will the mod devs. I just go to the dev and say 'Hey dev, here, have a shiny linux/mac compatible version of your mod. I take no credit whatsoever for making the mod, just for converting it'.

 

@ShneekeyTheLost: that'd be much appreciated. When you figure it out, could you document (a) how to use mods on Linux/Mac, and (b) how to recompile mods for Linux/Mac? That way I can take care of Lookup Anything (which still updates pretty often), while you focus on the other mods.

 

Feature documentation is one of my core strengths. I'd be more than happy to do so once I get a chance to tear into it and figure out how it works.

 

Sorry, I got a bit sick. I am researching how to compile the Mods into a dll. I have not found any clear instructions yet on how to compile in Visual Studio Code or Mondevelop. With MonoDevelop I'm suppose to see a configure file which is where I an getting stuck. Hopefully Shneekey can do it faster than me. I believe Pathoschild is correct in regards to the following:

I see a lot of file label Mono and a MonoGame.Framework.dll.config file in the game folder, and one of the config files has mono_win32_compat_CopyMemory.

 

Monodev wants the solution file (*.sln) of the project you're trying to build. Compiling the mods isn't difficult, it's hunting down all the dead framework references that's a pain in the butt.
Shneekey's good, he's got this.

@Pathoschild Before all of this, I wanted to say that 1.2 looks great!

 

I just discovered this mod, and it looks great. Definitely going to install it.

I know this is a few versions too late for input, but for character info like you were considering, you could make that an optional setting in the configs. You could just have the field programmed in and just leave it blank of text unless the description config was enabled (with it being disabled by default). You could even store the text in .txt documents for easy access for alteration, thus enabling players to write their own notes in description fields.

 

@Davrial: it's never too late for input!

The mod already has NPC descriptions; try looking up a Junimo, for example. I just didn't add any text for the villagers. The text comes from the data.json file, so you can technically add your own villager descriptions (though editing that file isn't recommended).

Making it an optional feature would certainly work, but it complicates the release process somewhat (especially testing). I'd rather minimise optional features for now and focus on features that most players will use. The descriptions might be part of a proposed feature which unlocks details as you learn them; if not I could make it an optional feature in a later version.

TL;DR: I won't add optional villager descriptions for now, but I haven't forgotten about the feature. Thanks again for the input; it helps decide which features players want.

 

Can't wait to start using this once the 1.1 update hits! This is so useful from what I've seen!

 

The 1.1 update might break the mod, but I'll try to have a fixed version very soon after the update.

 

Version 1.3 is now available! This release mainly adds more loot info on monster lookup, adds icons to item fields, and revamps gift tastes to correctly match the game's algorithm.

Specific changes:

• Added possible drops and their probability to monster lookup.
• Added item icons to crafting output, farm animal produce, and monster drops.
• Fixed item gift tastes being wrong in some cases.
• Fixed monster drops showing 'error item' in rare cases.
• Fixed fields being shown for dead crops.
• Internal refactoring.

Here's an example of the new monster drops field. (Black items will definitely drop, gray items might drop if you have the burglar's ring, and crossed-out items won't drop this time.)


Here's an example of the item icons, which make it easier to review at a glance:

 

Stardew Valley 1.1 beta is now available on Steam. The beta breaks SMAPI, so many mods (including this one) don't work. I'll release a working version once 1.1 is released, and either SMAPI is updated or Farmhand is released.

 

...and by "many mods", he means "nearly everything that isn't a portrait"

 

As an update, Life has hit me pretty hard, haven't had a chance to spin up my IDE yet.

I think the whole problem can actually be avoided if Farmhand is built, from the ground up, with MONO and OpenGL, which will natively support all operating systems. That way this will all become a non-issue entirely, solving the problem at the source rather than patching every single mod and making mod developers work harder. Since SMAPI is going to be depreciated in favor of Farmhand, which is once again in active development, I'm hesitant to try back-porting at this time since the work may become obsolete in a few weeks.

 

Unfortunately Farmhand will have the same problem, because Stardew Valley itself doesn't use MonoGame on Windows. If it did, crossplatform modding would be much easier.

 

>.<

Ask the Chucklefish crew to convert SDV from .NET to MonoGame for all distros instead of just Mac/Linux?

This isn't a pretty problem with a pretty solution, unfortunately. It's basically going to mean someone (either one of the Farmhand people, or some interested third party) is going to have to fork Farmhand for MonoDevelop. Yeesh.