Is it possible to have a setting in the config file where you could set the # by # values of each tent size? You have something kinda like this with depth but it can only be used to make it smaller not bigger. I was hoping I could do something like have the max tent size be 30x30 but it doesn't look like that's an option. also, is is possible to have a setting where the tend gets taller rather than deeper? I really like the idea of having the door be at the base of a giant tent but currently even at max size when I walk in I'm standing just below the ceiling and then have to take the stairs down to the floor? Maybe have a config that set what the tent's "base" level is and if you get it to the bottom the tent gets taller vs deeper?

Tents in 1.16.5 use NBT structure files to determine shape and size, so it should be possible to provide your own NBT files using a data pack. The size is no longer hard-coded.

Tents in 1.16.5 use NBT structure files to determine shape and size, so it should be possible to provide your own NBT files using a data pack. The size is no longer hard-coded.

Do you have any example configuration?

Interesting ideas. As of right now, it takes a huge amount of tedious code to tell the system where to put each block for even a single size of a single type of tent. So configurable sizes will not be happening unless I find a way to define mathematically what shape each tent should be without risking random openings and holes.
But as for making the tent taller instead of deeper, that's a valid idea. I agree that it can seem unnatural to go inside and appear halfway up the wall because you've dug out your basement. I'll add the "feature" tag to this so I can keep it in mind for the next builds.

Ooh, neat. Yeah, that's probably definable mathematically. I'll see if I can whip up some code to test for it. What actually inspired this was that I originally planned to do a quick and dirty version of this by just going into creative, knocking out the walls, and treating the whole thing like a void world but as soon as I moved the tent it broke. Like, while the tent was in 1 place I could enter and exit no problem with only the door block remaining in tent dimension but once I took it down and moved it the tent just... stopped working. The door in didn't work and hitting it with a hammer to collapse it didn't do anything. I've been experimenting to try to figure out what the actual trigger is that broke the tent so I can do everything BUT that. So far I've been trying knocking out just part of the wall, knocking out the whole wall but leaving the dirt. building beyond the 15x15 size the largest tent base would be and so on but nothing has stuck yet. The only time I've been able to recreate the issue is when I accidentally broke one of the external tent blocks which I'm pretty sure I didn't do the first time.

So for the math the Shamiyana(if I'm thinking of the right one) is probably easiest because it's a rectangular prism/cube, so you just need to define 2 opposing corners. eg if you want it to be a square that starts at X1, Y1 , Z1 and goes to X2, Y2, Z2, you just do 3 nested fors loop. I don't actually know how Java does loops. I'm more into web languages, hence why I'm not doing this myself but the general psuedocode in a language like php would be something like

for (z=0; z++; z<Z2) //do this for as many layers as defined by the height value  
{
     for (x=X1; x++; x<x2) //loop through all x values from X1 to X2. (X1 is probably always 0)
     {
         if ( (x=X1) OR (x=X2) ) // we want the first and last row to be full lines of blocks
         {
            for (z=Z1;y++;z<Z2) //loop through all z values from Z1 to Z2. (Z1 is probably always 0)
            {
               coord[]="x y z"      
            }
         }  
         else //we want the rest to be just 2 blocks
         {
             coord[]='"x y Z1" place a block at the north end of the row
             coord[]="x y Z2" place a block at the south end of the row
         }
      }
}

//now we need to define where the door goes so it's in the middle of south wall regardless of the size. and as close to the middle as possible with an even length wall
doorcoord= [rounduptointeger(X2/2), Y1, Z1] 

the code for the breakable dirt level is basically just a repeat of the above but without the if/else (every row is filled so you just use the for (z=Z1;y++;z<Z2) { coord[]="x y z" } code) and set your X and Z to be for a square 1 block smaller than the wall layer.

for the tents that are squares except the corners go in one you just repeat the above and then add a line to stick in a coord 1 off from each corner (x1+1,y,z1+1 /x1+1,y,z2-1/ x2-1,y,z1+1/x2-1,y,z2-1).

For the ceiling you can actually do the same as the dirt layer and just make a solid roof, then calculate the center (if tentsize is > 3 AND odd then replace a 3x3 in the middle

X1= (rounduptointeger(x/2) -1),
X2=rounduptointeger(x/2)+1)
Y= ceilingheight
Z1= (rounduptointeger(z/2) -1),
Z2=rounduptointeger(z/2)+1)
with air blocks
and if tensize if > 3 AND even then replace a 2x2 in the middle

X1= ((x/2),
X2=(x/2)+1
Y= ceilingheight
Z1= (z/2) ,
Z2=(z/2)+1
with air blocks

once I get back home and can jump into the game I can look at the roofs and caluclate what the loops would be to create the other roofs/walls but it should absolutely be programmable mathematically. since it's defining an array or array to form geometric shapes.

I think it would really be good to re-work my "Blueprints" code in that way. But the tricky part is when tents are upgraded -- the tent door should not change position or we risk overwriting blocks that the player built. Even trickier: handling even-number tent widths where the tent door is not directly in the middle of the tent.
So I started a code snippet to build, for example, a hollow square. My math is horrendously messy but it seems to work. Here's an image of how my coordinate system works for a 5x5 hollow box:
image
And here's how I want it to work with a 6x5 hollow box:
image
And here's the horrible code that kinda works:

public static List<BlockPos> hollowSquare(final BlockPos origin, final int width, final int length) {
	final List<BlockPos> list = new ArrayList<>();
	final int left = -width / 2;
	final int right = width / 2 - (width % 2 == 0 ? 1 : 0);
	// add the first row (full)
	for(int i = 0; i < length; i++) {
		list.add(origin.add(i, 0, left));
	}
	// add the intermediate rows (endpoints only)
	for(int j = left + 1; j < right; j++) {
		list.add(origin.add(length - 1, 0, j));
		list.add(origin.add(0, 0, j));
	}
	// add the last row (full)
	for(int k = 0; k < length; k++) {
		list.add(origin.add(k, 0, right));
	}
	return list;
}

which gives this output:

Testing hollowSquare with width 6, length 5
(0, 0, -3)
(1, 0, -3)
(2, 0, -3)
(3, 0, -3)
(4, 0, -3)
(4, 0, -2)
(0, 0, -2)
(4, 0, -1)
(0, 0, -1)
(4, 0, 0)
(0, 0, 0)
(4, 0, 1)
(0, 0, 1)
(0, 0, 2)
(1, 0, 2)
(2, 0, 2)
(3, 0, 2)
(4, 0, 2)

I'll keep working on it and see what other changes would be needed to implement this. At the moment I can't promise that it will make it further than the "idea" stage depending on how complicated it makes all the other code relating to tent construction and de-construction. The most complicated formula will likely be generating circles, because in my experience the traditional distance formula is unreliable for making an unbroken ring of blocks. Just thinking out loud here, I appreciate the input.

Sorry, been meaning to get to this but my actual job has been sucking all my brainpower. I mean, the easiest solution to the even numbers problem is to just not allow them. Say "This number must be odd for math purposes" in the config file and then make the code check the config and if an even number is entered subtract 1. That would result in always having an odd number. Also I wasn't thinking you would allow for rectangular boxes (thought actually that would also be neat) I more was just thinking in terms of being able to scale up to larger boxes.

As for circles there's a mod called grid (https://www.curseforge.com/minecraft/mc-mods/grid) that includes functionality to generate circles of various sizes so you can probably pilfer their code to see what equation they use.