Tool SMAPI: Stardew Modding API

Many thanks ClxS!

It's pretty awesome to get a link to a tutorial, examples and even some advice!

I'll read up and check out the examples.

Thank you!
Ice

Edit:
I've read through the tutorial and checked out the specific example you linked. After playing with Storm and what not, the tutorial makes a ton of sense. The example is also really clean/expressive and could be exactly what I am looking at. I'll have to see if I can iterate over the shipped items (a param given to the ShippedMenu constructor). Hopefully I'll have some time to try it out tomorrow.

Man, some days the internet can be depressing, but it's amazing how friendly and helpful strangers can be on the internet, especially modding communities.

Thanks!

 

So I've been keeping up-to-date with SMAPI mod updates. However, for some reason, the trainer can't be accessed. I've updated to 39.2, moved the trainer.dll into the mods folder. It uploads the other mods, but I can't freezetime etc. Is there anything I'm doing wrong?

 

@iceburg 333 welcome to the mod community.

See This guide first http://community.playstarbound.com/threads/guide-how-to-make-smapi-0-37-mod.110224/

Then bookmark this thread for constantly updated tutorials and resources http://community.playstarbound.com/...-and-general-modding-discussion-redux.109131/

 

Nice work on the API. Just wondering why your repo is forked from mine? What happened to the original one

 

When Zoryn deactivated her base originally, github went weird. Rather than activate my fork as a standalone repository, it redirected the base to be the closest match to Zoryn's.

After 0.39.2 the way mods has stored changed a bit. We no longer have a lot of DLLs inside the mod folder but instead have a folder for each mod, along with a manifest.
Your folder structure should look like:
- Mods
- - TrainerMod
- - TrainerMod.dll
- - manifest.json

You'll need to also get the new version of TrainerMod.dll if you're just using your old one.

 

Audio problems ahoy

Everything is updated (new version of SMAPI, Stardew Valley is at 1.06) and the only mod I have is CJBCheatsMenu, which loads and works fine. The problem is that the game has no audio when I start it up with the SMAPI exe. It's fine if I load it from its normal exe, but then I can't use any mods. I'm searching about and can't find an exact answer for how to get this fixed. No sound effects, no sound, no anything. It works completely fine otherwise.

 

It's a little odd, but SMAPI hasn't somehow muted itself has it? If you right-click the speaker in the Windows task bar and select Volume Mixer, make sure the SMAPI one isn't muted?
Other than stuff like that I've really no idea what it could be.

 

Thanks Drogean!

Per the help on this thread, my mod is working on my local. I now have a mod that saves the items you ship each night to a csv file. I am working on a presentation system for the data, and then will release the mod.

Thanks all!

 

@ClxS I've noticed that when typing in help to the console, I get the hollowing message: [9:12:24 PM] Commands: System.Linq.Enumerable+WhereSelectListIterator`2[StardewModdingAPI.Command,System.String]
Is this a royal screw-up on my end, or is there just something I'm not getting? Running SMAPI 39.2 right now.

 

Ah no it is definitely a problem with the API. Someone reported it on GitHub a few days ago and Zoryn has fixed it now I think. The fix will be included in the next release!

 

Any news on steam on house streaming fix yet be nice to be able to play this on steam link too

 

Hopefully an upcoming major change will resolve this. I think it might partly be due to launching the game from a separate program, since it also stops Shadowplay and Windows 10 Xbox from working with it as well.

__________________________

Okay so I've got a question for any modders!
How do you access the game object? Do you use SGame, or Game1.game1?
The issue is that I don't feel like SGame fits well with what I now want to do, and I plan to remove it soon. I'll keep the most common accessors and a non-inheriting SGame class for backwards compatibility with mods that use the specific features SGame offered, but if your mod needlessly depends on it I suggest you move towards using Game1.game1 now so your mod wont stop working later.

 

I noticed that you can't add new accessories the way you can with shirts and hairstyles (just extending the image and adding new ones does it). You are limited to 19 accessories (the creation screen actually reads 20, with Accessory 1 being no accessory).

Using dotPeek, I found this bit of code in farmer.cs

public void changeAccessory(int which)
{
if (which < -1)
which = 18;
if (which < -1)
return;
if (which >= 19)
which = -1;
this.accessory = which;
}

Which looks like its the bit that limits the accessories to just 19 options. Can this be changed using a mod? I'm fumbling around reading up on SMAPI tutorials and playing inside MVS but I'm feeling overwhelmed.

 

I think you could just use Farmer.accessory=DesiredAccessori or what number you want. But you will have to make this every time the game loaded and make a special menu to choose new accessories.

 

Welp.. I tried this:



and got this:



But the arrows don't work. I feel like I'm getting closer though ^_^




Edit: I'm not any closer. That just sets the Accessory to whatever number (+2 I guess for some reason) you say. So frustrated =(

 

I've been trying stuff out with SMAPI and noticed a limitation for mods: you can't use basetypes (i.e. an abstract class inheriting from Mod) as it simply loads the first class of type Mod. this also means, it's impossible to have multiple mods in one DLL (which means it's harder to seperate concerns, which is a must for clean code). I'd propose the following in Program.cs LoadMods, Starting at Line 316:

Code:

Assembly mod = Assembly.UnsafeLoadFrom(targDll);
var modTypes = mod.DefinedTypes.Where(x => typeof(Mod).IsAssignableFrom(x) && x.IsClass && !x.IsAbstract);
if (!modTypes.Any())
{
    Log.Error("Invalid Mod DLL");
}
else {
    Log.Verbose("Loading Mod DLL...");
    foreach (var modType in modTypes)
    {
        Mod m = (Mod)mod.CreateInstance(modType.ToString());
        m.PathOnDisk = Path.GetDirectoryName(s);
        m.Manifest = manifest;
        Log.Success("LOADED MOD: {0}", modType.Name);
        Constants.ModsLoaded += 1;
        m.Entry();
    }
    Log.Success("LOADED ALL MODS: {0} by {1} - Version {2} | Description: {3} (@ {4})", manifest.Name, manifest.Authour, manifest.Version, manifest.Description, targDll);
}

this allows for multiple mods in one dll and only tries to instantiate classes which actually can be instantiated.

sorry if this is the wrong place for such suggestions but I only ever worked with TFS and have no idea how to propose a patch via git (assuming it's possible).

 

Ah good suggestion. There's a few other things that'll need to be changed in order for it to work (since I keep a reference to each mod instance in the manifest class), but I'll have a look. It should be an easy enough change to make.

 

FutureVersion Preview

Mostly for devs this one:
So here's a few more details about how the upcoming major update functions. Like I've said a couple of times before, it's essentially a rewrite which involves changing how the core of SMAPI works. After this update, support for SMAPI mods will be done through an optional backwards compatibility layer and may be phased out in the (distant) future.

So I've mentioned my issues with how Storm does it. Storm uses injection to alter the Stardew executable at runtime. It's the same way Stardew Injector did it, and I also had a go at doing it that way early on in SMAPI. This causes issues with the references which makes debugging a pain in the butt. It'd force us to use an approach similar to how Storm got around this by wrapping all the properties in accessors and not allowing direct access to the game object.
To address this but to allow us to inject our own code into Stardew we've opted for offline injection. What this means it that when you first install the modding API, you do it via a lightweight installer (doesn't leave any traces) which creates a version of Stardew with our code injected into it. Mod creators would then just reference this modified executable instead of Stardew Valley like they did in SMAPI. This in theory lets us have a single executable as the Stardew Valley.exe will no longer be used.
(We do not overwrite it though, just so people can always play without the API if they want)

This method has the added benefit that Steam and Gog will not automatically update the API and break mods, however it does mean that when a new version of Stardew releases, you'll need to re-run the installer to make the API use the latest version of the game. It'll be possible to make this happen automatically but that'll be coming at a later date.

The installer currently looks like this, it's only a lightweight single-file little thing:


At the moment, this'll create a new exe called 'Stardew Revolution.exe' right next to your Stardew Valley.exe. Mods still work mostly the same, and 0.39.2 SMAPI mods are compatible. The few mods which do not work are the ones which use Program.gamePtr and SGame. I do not plan to fix those issues since it forces the Core API to use the SMAPI way of doing things.

It also includes support for content only mods, allowing you to redirect XNBs without modifying the Contents folder. This is done just by having a manifest.json, such as this one I used for testing which uses Pamoire's Kitchen Retexture.

Code:

{
    "UniqueId" : "PamoiresKitchen",
    "Name" : "Kitchen Retextures",
    "Author": "Pamoire",
    "Version" : "0.1",
    "Description" : "An example Content only mod.",
    "Content" :
    {
        "XNB" :
        [
            {
                "File" : "farmhouse_tiles"
            }
        ]
    }
}

I'm still fixing up a few things. I start back at work again tomorrow so I'll be back to doing only an hour or so a day on it. I'll make it public for mod developers to give feedback on what they'd want addingsometime this week since before an official release since a lot of events are missing, and I only have an override for the TitleMenu at the moment.

 

Any way we can help / contribute to get things moving along?

 

Once I make the repo public I'll happily accept merge requests and stuff!
Currently only the console installer + debugger works fully, so I'm just wanting to finish up the UI one and fix a bug causing it to not load mods/log output, so then people can properly get it running on their machines.