Upgrading Mods to 0.10.25 and Later

Discuss modding questions and implementation details.
User avatar
Magicono43
Posts: 1139
Joined: Tue Nov 06, 2018 7:06 am

Re: Upgrading Mods to 0.10.25 and Later

Post by Magicono43 »

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.

User avatar
Ralzar
Posts: 2211
Joined: Mon Oct 07, 2019 4:11 pm
Location: Norway

Re: Upgrading Mods to 0.10.25 and Later

Post by Ralzar »

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

Lokkrin Zhataros
Posts: 256
Joined: Thu Nov 21, 2019 9:27 pm

-

Post by Lokkrin Zhataros »

-
Last edited by Lokkrin Zhataros on Wed May 26, 2021 3:25 am, edited 2 times in total.

User avatar
Magicono43
Posts: 1139
Joined: Tue Nov 06, 2018 7:06 am

Re: Upgrading Mods to 0.10.25 and Later

Post by Magicono43 »

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?
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
Posts: 256
Joined: Thu Nov 21, 2019 9:27 pm

-

Post by Lokkrin Zhataros »

-
Last edited by Lokkrin Zhataros on Wed May 26, 2021 3:25 am, edited 2 times in total.

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Upgrading Mods to 0.10.25 and Later

Post by Interkarma »

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

User avatar
Magicono43
Posts: 1139
Joined: Tue Nov 06, 2018 7:06 am

Re: Upgrading Mods to 0.10.25 and Later

Post by Magicono43 »

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.

User avatar
Magicono43
Posts: 1139
Joined: Tue Nov 06, 2018 7:06 am

Re: Upgrading Mods to 0.10.25 and Later

Post by Magicono43 »

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.
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.

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. :lol:

User avatar
Interkarma
Posts: 7236
Joined: Sun Mar 22, 2015 1:51 am

Re: Upgrading Mods to 0.10.25 and Later

Post by Interkarma »

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.
LineOffset is stored as a delta like so:

Code: Select all

LineOffset = line - (int) (line % (1 << line_delta_bits));
This compiler stage seems to be the lexical analysis / tokenization stage (thinking back to the old "Dragon Book" - Compilers: Principles, Techniques, and Tools).

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
I'm just quickly diving in before I have to leave for work, so probably just talking out of my ass. :) Maybe we should be thinking about forking the source for mcs-ICodeCompiler and rebuilding this ourselves. We might be able to resolve this with a few tweaks and a custom rebuild. Can we rebuild and get 24 bits for deltas between checkpoints? If nothing else, a little more control over this critical component of DFU would be useful.

TheLacus, Hazelnut - any thoughts?

jimfcarroll
Posts: 102
Joined: Tue Feb 12, 2019 12:55 am

Re: Upgrading Mods to 0.10.25 and Later

Post by jimfcarroll »

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

Post Reply