Upgrading Mods to 0.10.25 and Later
- Magicono43
- Posts: 1143
- Joined: Tue Nov 06, 2018 7:06 am
Re: Upgrading Mods to 0.10.25 and Later
Alright, so all 4 of my released mods I have rebuilt and tested in 0.10.25 in their compiled forms, and they are all working in a controlled setting by themselves, no issues so far. The only one that gave issue was Limited Gold Shops, but that was resolved by the Overload TheLacus added in a few posts ago.
Now for the more scary part, seeing how these mods work when loaded together with other mods, this should be interesting, but hopefully this slow and meticulous method makes trouble shooting a bit easier as it goes on here.
Now for the more scary part, seeing how these mods work when loaded together with other mods, this should be interesting, but hopefully this slow and meticulous method makes trouble shooting a bit easier as it goes on here.
- Ralzar
- Posts: 2211
- Joined: Mon Oct 07, 2019 4:11 pm
- Location: Norway
Re: Upgrading Mods to 0.10.25 and Later
TheLacus wrote: ↑Sat Jul 18, 2020 12:55 pm Your mod is relatively big so it's not easy to find out what exactly is causing this issue. I'd suggest to consider compiling most, if not all, of your mod using Visual Studio and load the assembly at run time from resulting .dll file, but I understand this might be overwhelming.
After talking it over with Magicono, it might appear this is not a 0.10.25 bug. But something probably introduced in 0.10.24, just that no one spotted it because it caused random OTHER mods to fail, not your own mod.
I made a new topic here:
viewtopic.php?f=22&t=3934
-
- Posts: 256
- Joined: Thu Nov 21, 2019 9:27 pm
- Magicono43
- Posts: 1143
- Joined: Tue Nov 06, 2018 7:06 am
Re: Upgrading Mods to 0.10.25 and Later
Yes, mods updated to 0.10.25 are incompatible with earlier version, they won't even show up in the mod-list if you put a 0.10.25 in the 0.10.24 DFU client. But the reverse is not necessary true, many mods still function for the most part without even being updated for 0.10.25 specifically.Lokkrin Zhataros wrote: ↑Sat Jul 18, 2020 10:49 pm Sorry if this breaks the flow of this topic, I couldn't find the answer to this question anywhere so far (apologies if this question was already asked and answered somewhere else or this was not the place to ask this).
Was wondering if mods needing to be updated to the latest Unity engine, will they become incompatible with earlier versions of DFU like 0.10.24 or earlier?
-
- Posts: 256
- Joined: Thu Nov 21, 2019 9:27 pm
- Interkarma
- Posts: 7253
- Joined: Sun Mar 22, 2015 1:51 am
Re: Upgrading Mods to 0.10.25 and Later
Have started adding to known limitations of portable compiler, with suggested workarounds. This information is now on first page of this topic (third post).
viewtopic.php?f=12&t=3929#p45737
viewtopic.php?f=12&t=3929#p45737
- Magicono43
- Posts: 1143
- Joined: Tue Nov 06, 2018 7:06 am
Re: Upgrading Mods to 0.10.25 and Later
Oh yeah, forgot to mention that the Linux builder suddenly started working when I built some mods with it yesterday night, so that Linux thing might have been a red-herring. At least on my end building for 64-bit Linux is working now.
- Magicono43
- Posts: 1143
- Joined: Tue Nov 06, 2018 7:06 am
Re: Upgrading Mods to 0.10.25 and Later
So Hazelnut, Ralzar, and I did a bunch of troubleshooting on why one of my mods and at least one of Ralzar's is causing this "Index was outside the bounds of the array" compile error during mod initialization if the "problem" mods were in certain load order configurations. We did not really find a definite answer after the process, but we have a few possible hunches. One of the more potentially convincing ones is perhaps these "problem" mods are so large in terms of size, that they overload the array they are put in as a string in someway during mod initialization and causing the problems, or something. My mod in question is about 2607 lines, but even after I cut it down to 1497 lines just for fun, it was still giving the same error, so not really sure on that one, but it made the most sense at the time.TheLacus wrote: ↑Sat Jul 18, 2020 12:55 pm The compiler fails to parse source code from your mod:
This is the source code of mcs-ICodeCompiler, which unfortunately is not receiving updates anymore:
Your mod is relatively big so it's not easy to find out what exactly is causing this issue. I'd suggest to consider compiling most, if not all, of your mod using Visual Studio and load the assembly at run time from resulting .dll file, but I understand this might be overwhelming.
Anyway, unless somebody has a better explanation, we might want to consider your proposition of just pre-compiling the mods in some other way as you mentioned, but none of us are 100% sure on what the process would be for compiling a mod in VS and then loading the resulting .dll file into a .dfmod build and running that as the assembly package instead of through the mcs compiler.
If you have the time, maybe a link to the process in question, or a deeper explanation would be appreciated, and hopefully this process may work to get this "bug" we are having out entirely, hopefully at least.
- Interkarma
- Posts: 7253
- Joined: Sun Mar 22, 2015 1:51 am
Re: Upgrading Mods to 0.10.25 and Later
TheLacus wrote: ↑Sat Jul 18, 2020 12:55 pm This is the source code of mcs-ICodeCompiler, which unfortunately is not receiving updates anymore:
Code: Select all
// TODO: For eval only, need better handling of empty int file_index = file == null ? 0 : file.Index; // FIXME: This value is certainly wrong but what was the intension int max = checkpoint_index < 10 ? checkpoint_index : 10; for (int i = 0; i < max; i++) { int offset = checkpoints [checkpoint_index - i].LineOffset; <-- line 265 delta = row - offset; if (delta >= 0 && delta < (1 << line_delta_bits) && checkpoints[checkpoint_index - i].File == file_index) { target = checkpoint_index - i; break; } }
Reading through the mcs-ICodeCompiler source, I note the following comment for Location struct (of which Checkpoint.LineOffset is a member).
Code: Select all
/// This uses a compact representation and a couple of auxiliary
/// structures to keep track of tokens to (file,line and column)
/// mappings. The usage of the bits is:
///
/// - 16 bits for "checkpoint" which is a mixed concept of
/// file and "line segment"
/// - 8 bits for line delta (offset) from the line segment
/// - 8 bits for column number.
Code: Select all
LineOffset = line - (int) (line % (1 << line_delta_bits));
If line_delta_bits has a 8-bit limit, it probably wouldn't take much for code written a certain way to fail lexing. Distance between checkpoints needs to be as short as possible to fly under the delta bit limit. But I don't know enough about C# lexing specifically to say what might trigger this. But shorter lines and minimal inlining of tokens should help.
I also noticed line_delta_bits has a bit length based on FULL_AST which conditionally sets line_delta_bits to 24 bits. I don't think the current mcs.dll has this enabled in compile?
Code: Select all
#if FULL_AST
readonly long token;
const int column_bits = 24;
const int line_delta_bits = 24;
#else
readonly int token;
const int column_bits = 8;
const int line_delta_bits = 8;
#endif
TheLacus, Hazelnut - any thoughts?
-
- Posts: 102
- Joined: Tue Feb 12, 2019 12:55 am
Re: Upgrading Mods to 0.10.25 and Later
I'm trying to update Tedious Travel which uses HardStrings. By just grepping through the code, I know the index of the localized string but I can't find an appropriate const and I don't want to hard code the index to a literal int ('9' in this case).
Is there an example somewhere in the codebase of how to reference these string resources correctly? I couldn't find one grepping through the code.
Thanks
Is there an example somewhere in the codebase of how to reference these string resources correctly? I couldn't find one grepping through the code.
Thanks