Interkarma wrote: ↑Fri Jul 17, 2020 11:28 pm
Those Func warning do not appear when downloading from latest tag. I just downloaded and confirmed again then. Please double-check you're using the correct version. If you have the correct code, Func.cs will be nowhere in your project. You can ignore the editor style change to inline.
I did not forget to change the version, I mention this above:
This build is still internally versioned as 0.10.25, but will have the display name "0.10.25a" on live builds page when ready.
Oh, I was just downloading the tagged .rar file and pasting the folders enclosed into my project folder, not using the clone tool, because I can't seem to figure out how to do that with the new Github interface, at least with the tagged versions. So that's probably why Func.cs had not been removed.
I misread "on live builds page" as going to be on the launcher for some reason.
Downloading the zip/rar archive is perfectly OK. Just check that Func.cs isn't present in the code at all.
We seem to be talking about different things too. I was looking at editor warnings in Unity when Func.cs is still present, and you're seeing editor style change suggestions in VS. It does that for all of the Func calls on my end, not just the >4 attribute ones.
We only had a custom Func delegate for >4 attributes. Everything else was just .NET. Now we have .NET 4.x in Unity 2019, they're all .NET and the custom Func delegate isn't needed any more. This shouldn't affect anything (in theory) once mods are rebuild against the new code in Unity 2019.
Yeah, after I removed Func.cs the warnings are gone, both in the Unity debug log, as well as in the VS editor. Yeah, on my side I was only getting warnings on Funcs with 4 or 5+ targets it seems, not the other ones with less, for whatever reason.
There are also a fair amount of warnings in Unity in some of the ModSupport scripts about Fields never being assigned, which I don't recall seeing before in the previous 0.10.24 version and earlier unity verison, so (maybe) that could possibly have something to do with some of the mods having issues? Not my department to say, I really have no idea, lol, just a quick observation on that one.
Here is the .dfmod built version that is currently throwing "Constant does not match defined type" error when you hit "start" with the mod active, in DFU 0.10.25:
Thanks, I've setup test environment that should match yours. I can confirm that mod works in editor and I see the following error after launching game in build.
ModManager - started loading mod: LimitedGoldShops
Error (): Constant does not match the defined type.
I'll poke at this more when I can. If someone more experienced with the mod system and runtime C# compiler than myself is around (e.g. TheLacus/Hazelnut) your feedback is welcome.
TheLacus wrote: ↑Sat Jul 18, 2020 12:57 am
It's not possible to define enums inside mod scripts. This is a known limitation that has always been there.
Use constants instead. You can make a static class containing only constants to partially emulate an enum.
I did not use an enums in this mod, unless you looked in "Altered Base Scripts" which is just there to keep track for a PR I had to make that got merged in 0.10.24. All the relevant bundled assets are outside that folder.
Just having this class defined and included in mod build will produce the "constant does not match the defined type" error at start. Removing the code file above from build will remove the error.
I note the use of "WindowModes.Sell" there. Would this enum be enough to trigger error, TheLacus? This one is defined inside of core.
Just having this class defined and included in mod build will produce the "constant does not match the defined type" error at start. Removing the code file above from will remove the error.
Interesting, I have no idea why that is, or how you were able to pin-point that, but at least I have somewhere to look now