[mod request] smaller map size and reducing build boundaries.

[Dima_]

I've tried using the set up camp mod to achieve a similar effect, but on top of not getting any raids or trade ships, it's also frustrating to have a 10 block deadzone where i cant build anything. that amounts to about a third of my map not being usable, and it's pretty ugly. i'm fine with not having any raids, but the trade ships is what bugs me. so my request is to have a mod that can change the size of the smallest maps to be smaller, like 75x75 or even 50x50, and also reduce the 10 block border to something more like 2-3 blocks.

[Dima_]

bump

[CannibarRechter]

The boundary is probably hard coded. You should realize that even if someone were to code up something for you, it could have unintended consequences. Have you considered that if you build into the boundary area, raids will effectively initiate right in the middle of your base?

[Dima_]

ive thought about everything. ive had many weeks to think about this. those are not problems for what i am trying to do. i would not be asking this if i did not have a good reason for it.

[dburgdorf]

I doubt it would be terribly difficult to allow for a smaller overall map size.  But the border zone is probably stuck as is.  It's not something I've looked at in any detail, but in the course of working on my various mods, I've come across several cases -- and there are presumably a lot more -- where checks for valid building areas and the like are done on the basis of "Is the coordinate of this square more than 10 and less than the map size minus 10?" In other words, there's no universally-accessible "border size" variable, but instead, each and every check is individually written with an assumption of a border size of 10 squares, both in the base code and in the code for mods.

[neitsa]

I wondered the same thing a while ago and I have to concur with dburgdorf: it is technically possible but it would be very complicated to do it properly.

Both edges (no build and no zone edge) are defined in Verse.Gengrid class:

Code Select Expand


public static class GenGrid
{
public const int NoBuildEdgeWidth = 10;

public const int NoZoneEdgeWidth = 5;


The problem is that they are defined as const and not as variables. Being defined as const means that each time they are used in the code, the compiler will replace their names with their values. So if the code is "Function(NoZoneEdgeWidth);" the compiler writes "Function(5);". Examples:

Code Select Expand


public static bool InNoBuildEdgeArea(this IntVec3 c, Map map)
{
return c.CloseToEdge(map, 10);
}

public static bool InNoZoneEdgeArea(this IntVec3 c, Map map)
{
return c.CloseToEdge(map, 5);
}


And another example somewhere else (not "near" the const values) in the code:

Code Select Expand


// Verse.GenDraw
public static void DrawNoBuildEdgeLines()
{
GenDraw.DrawMapEdgeLines(10);
}


Those values are spread in multiple places around the code and tracking them seems to be really hard. This would requires multiple harmony patches and any change in the RW code would require to examine all the patches once again, etc. So it's technically possible to do a list of all the function that seems to use a "5" and a "10" as map edge widths, but in the end this would be quite difficult and prone to bugs (you can't miss one of the functions using these const otherwise the mod would fail)...

(edit)

Hmm maybe it's not "that" hard and they are spread only in just a few places here and there. But in all cases it would require a careful examination of RW code.

[dburgdorf]

The problem is that they are defined as const and not as variables....

You learn something new every day. I've often wondered why so many classes seemed to have definitions that were never used, where (what seemed to be) a variable was defined at the beginning of the class, but only appeared as an actual number rather than a call to the variable when referenced later. I'd never realized that that was due to compiler issues. I didn't know about the difference between "const" definitions and actual variables.

That's the sort of knowledge gap you end up with when you "learn to code" by modding instead of actually learning to code. 

[CannibarRechter]

That kinda makes me wonder; occasionally the core will have these calls that feature a magic number, like this:

Code Select Expand


Log.ErrorOnce("Fire DrawWorker with null thingDef: " + loc, 3427324);


I wonder if they're not really using a magic number, but instead referencing a const variable in the original code, and we're just seeing an artifact of the decompiler here. I can't find that particular const actually defined anywhere, though. I just checked.

[neitsa]

That kinda makes me wonder; occasionally the core will have these calls that feature a magic number, like this:

Code Select Expand


Log.ErrorOnce("Fire DrawWorker with null thingDef: " + loc, 3427324);


I wonder if they're not really using a magic number, but instead referencing a const variable in the original code, and we're just seeing an artifact of the decompiler here. I can't find that particular const actually defined anywhere, though. I just checked.

I wondered exactly the same about those hardcoded numbers in Log.ErrorOnce() . Defining a constant will add an entry in the assembly metadata, but I wasn't able to find any entry corresponding to those numbers. Moreover they don't seem to have any precise order (sequence), so my guess is that they are picked at random (which ultimately gives 2^32 possibilities). But yep, quite strange that they are not defined anywhere as const int...

[Dima_]

every time this thread is bumped it gives me false hope that someone managed to make this mod work.

[CannibarRechter]

From the description of how the constants are used, this mod would likely be overly involved to produce, and error prone regardless.

[Kapitan Oczywisty]

every time this thread is bumped it gives me false hope that someone managed to make this mod work.

I made it for myself, but if you still waiting: https://ludeon.com/forums/index.php?topic=46420.0