Wow ... has it really been a week since I had time to post the next section in this thread?
With the basic idea of building Rooms using player defined Room Blocks established, how those Room Blocks are "allowed" to be structured within the Base Plot Volume through very simple "touching" rules, the fundamental concept of having a fully 3D positioning GUI to locate
and move elements around within the Volume ... *and* being able to export/import all of that data to a Plain Text File in the same way that Mission Architect and Player Costumes can be exported/imported to and from text files ... it is now necessary to move on to other important considerations for dealing with the Styling of the walls, floors and ceilings, and how to place Items within the boundaries of Room Blocks.
My thoughts for Styling of (contiguous) Room Blocks is relatively simple ... but can be made more complex without too much (conceptual) difficulty, assuming that the programmers don't put their foot(s) down (too definitively). The basic notion is that every Room Block of the same Type at any given *height* within a contiguous Room has an identical Wall Styling. This is broadly similar in concept to what we have now with the Legacy Editor, in terms of Low Walls, Floor Walls, Mid Walls, High Walls and Very High Walls with respect to Wall Styling. Now to be clear, at this point I'm envisioning the classic Floor Trim and Ceiling Trim being changed into Decorative Wall Objects so as to make their inclusion/removal more of a Designer Choice and to also allow for greater design freedom(s, particularly in very irregularly shaped 3D contiguous Rooms).
The important thing to remember though is that the Base Plot Volume is essentially a "solid" or otherwise "impassable" space (in 3D), and the Room Blocks are basically "hollowing out" that space so as to give a (cubic) bubble of air which Players can move and around in and Items to be placed in. That means that any Styling of textures for the walls of these Room Blocks goes only on the
"inside" of the Room Blocks ... just like what we see with the Legacy Editor. The thing is though that when Players are allowed to "free form" create Room Blocks and additively arrange them in shapes other than perfect rectangular prisms, all kinds of additional possibilities come into play which can make "auto assignments" like this less than optimal.
For example, if a player wanted to create some "swimming pool" holes in the floor of an otherwise symmetrical Room, that would have to be done with Room Blocks to "hollow out" the underwater pool space. But then you can run into a situation where a player wants those multiple pools to have different Styling within the "pits" of the pool spaces, and if EVERYTHING in the same room, at the same height has the same Wall Styling within that set of Room Blocks, then the editor is "too constricting" for what players may want to do and unnecessarily limiting of their creativity.
The compromise, of course, is to limit the continuity of Wall, Floor and Ceiling Styling to only contiguous Room Blocks at the same height/altitude. That way, you could have a "swimming pool pit" group of Room Blocks on one side of a very large Room, and a single Room Block off to the side (ie. not contiguous with the "main pool") as a "hot tub pit" in the same overall Room flooring, and be able to define the Styling of the "big pool" and "hot tub" separately. Even though "pool" and "hot tub" are located at the same height/altitude, as far as the placement of their Room Blocks is concerned, because they don't share a common contiguous Wall between them, their Floor and Wall Styling can be defined separately ... so as to have a powder blue pool and a white hot tub (for example).
The Basic Rule of Styling then becomes a matter of all *contiguous* Room Blocks, of the same Type, at the same height/altitude in the Base Plot share the same Styling for Floor, Walls and Ceiling (if applicable). Note that Room Blocks that are adjacent to each other
do not have a Floor, Wall or Ceiling where another Room Block is touching them, allowing Room Blocks to be stacked and arrayed so as to be able to create wide open spaces within the Base Plot Volume. Also note that since two adjacent Door Room Blocks will be necessary to transition from one Room Type to another, it is perfectly possible to have the Door Room Blocks duplicate the Styling of any non-Door Room Blocks they are adjacent to, so as to preserve the current behavior (if desired...) of having the Styling "switch" from Room to Room at the halfway point inside any given "Door" between those Rooms.
And
I know that that all reads as a lot of gobbledygook when spelled out in text. If I could demonstrate the principles using children's wooden blocks, it would make things
so much clearer because all of this is very VISUAL stuff, and we're basically playing "telephone" here for some very spatial and visual concepts (except this is a pure text medium, making it even harder to clarify things).
The short end of the story is though that with all of the above, including the concepts advanced in my OP, it should be possible to create contiguous Rooms of almost any shape and size that people want to build them to within my proposed Base Editor, and have greater freedom to customize the appearance of the
interior of those spaces than we have been able to achieve in the Legacy Editor.
The next question that needs to be answered is ... just how BIG is the Base Plot Volume going to be? And how will positioning data for everything that is intended to be within the Base Plot Volume going to be addressed/dealt with?
Currently, the largest Base Plot available through the Legacy Base Editor is 24x28 squares. Each of those squares has a potential volume of 2x2x3=12 Room Blocks using the system that I'm proposing.
- 24x28 * 12 = 8,064 Room Blocks "worth" of Volume when using the Legacy Base Editor.
- It's 48x56x3 Room Blocks of total available space.
- That's 768 ft x 896 ft x 48 ft of total volume ... on the largest Base Plot available to the Legacy Editor. That is 33,030,144 cubic feet of space.
Now here's the interesting thing I take away from this. Even using just the Legacy Editor as a "guide" (they're not so much
rules so much as more like "guidelines" really...) we're still talking about numbers that in Base-10 read as ... 3 digits X axis ... 3 digits Y axis ... 2 digits Z axis ... for recording where everything "is" inside of a Base in all three dimensions. That means that
at the maximum it *should be possible* to have a volumetric addressing/recording system that is pure text/integer only based looks broadly like this:
XXXYYYZZ
So anything with a data string of 10020050 would mean X=100, Y=200, Z=50. In this case, I'm using Z as the "altitude" attribute.
Now given all of that, if using Room Blocks of 16ft x 16ft x 16ft and limiting the data recording system to an XXXYYYZZ positioning system, that means a theoretical maximum Base Plot Volume of 62x62x6 Room Blocks ... which is the equivalent to a 31x31 Legacy Base Plot with
double the available height. As a practical matter, however, I would personally recommend a "one size fits all" Base Plot Volume of 60x60x6 Room Blocks of 16ft x 16ft x 16ft each. As a consequence of this, I would advocate
removing the purchasing of a Base Plot as something to be bought with Prestige. My thought is that the pure SIZE of the Base Plot Volume should not be a consideration when it comes to working out what an SG can afford to buy. Instead, what is important, and what should be the REAL cost driver is
how much stuff you put *into* the available space.
Essentially, instead of paying for the Base Plot *and* the Rooms, like we do in the Legacy Editor, an SG would only be paying for the Room Blocks they buy, and the Items that get placed within those Room Blocks. Want a cheap starter Base? Be frugal in your buying of Room Blocks and keep everything small, cramped and pokey.
60x60x6 Room Blocks is 960 ft x 960 ft x 96 ft of internal volume ... or 88, 473,600 cubic feet of total space (about 2.68x the volume of the Legacy Editor).
All of that from using a Plain Text formatting for a Base-10 recording of coordinates in an XXXYYYZZ format. Note that this data formatting then makes it very easy to record the positioning of Room Blocks (in multiples of 16 *only* in all three dimensions) in a way which is totally compatible with a way to record the positions of Items within the spaces of those Room Blocks. Although it would be "easiest" from a computer programming standpoint to make the XYZ origin point a 00000000 location, I'd recommend instead making the "minimum" location in all three dimensions be the "1 ft" position so as to make things "easier" for the humans/Players to do some of the more complex 3D positioning math and relationals in their heads. That means a "minimum" coordinate position of 00100101 up through a "maximum" of 96096096, and the coordinates recorded for all Room Blocks must be equal to 16^
n (where 16^0=1) as part of a "sanity check" for the positioning things inside of a Base Plot Volume.
As mentioned previously in my OP, it is possible to extend this coordinate mapping system beyond simply placing things in 3D space. In the case of Room Blocks, it would be possible to extend this to include Room Type and also the number of Defensive Items permitted within that Room Block. Using the "by the foot" coordinate scheme I've just demonstrated, it should be possible to do *this* to define the "root" vertex point of a Room Block ...
Room Type Coordinates: XXXYYYZZEDFFWWCC
X = X axis coordinates (in ft)
Y = Y axis coordinates (in ft)
Z = Z axis coordinates (in ft)
E = Edit Privilege Ranking Level (0-5)
D = Max Defensive Items permitted in Room Block
F = Floor Styling type
W = Wall Styling type
C = Ceiling Styling type
The nice thing about this notation is that it organizes everything in a way which puts everything into a 16 character integer numeric string (3-3-2-1-1-2-2-2). It also allows SGs to set the "Edit" permission security level on a
Room Block by Room Block basis so as to grant permission to edit the
contents of Room Blocks based on their Ranking within the SG. This then allows the granting of Edit Rights to lower Ranking SG members
in very specific and controlled ways over *portions* of an SG's Base ... if desired ... rather than granting Global Permission to edit anything and everything as an All Or Nothing proposition. This then makes possible the creation of "sandbox" spaces within an SG where members
other than the Official Base Builder can have a chance to "play" with the design and placement of Base Items within the permitted space(s). It is then a very simple matter of changing the Global Base Edit Privilege, like we are used to in the Legacy Editor, to being something "granted" as a boolean Y/N proposition
to specific SG Members by Name or by @Global through the SG Controls Window(s), rather than something which is granted simply by attaining a specific Ranking within an SG. Needless to say, adding and deleting Room Blocks would require a Global Base Edit Priviledge ... while adding and deleting Base Items placed within Room Blocks would be controlled via the Edit Privilege Ranking Level (expressed as a minimum Rank within the SG) assigned to each Room Block.
This then creates a better Base Integrity Security Scheme where SG owners don't need to be
as worried about granting SG Edit Permission to newer/other players. It makes it *possible* for players
other than the SG Base Admin to participate in, gain knowledge in and demonstrate their skill with my (proposed) Base Editor so as to not *necessarily* keep it as something reserved for the Ivory Tower Few so as to guard against Griefing.
Now ... where this gets "interesting" is when extending the basic XXXYYYZZ coordinate system to Items, both Decorative and Functional, placed within the available spaces of Room Blocks. In this case, I'm talking about adding
rotational information in terms of yaw, pitch and roll away from zero.
My basic thought here is that it ought to be possible to code the Base Render Engine to rotate ANY placed Base Item in 15 degree increments for yaw, pitch and roll rotation. That gives a total of 24 positional increments (24*15=360) and requires the use of integers between 0 and 23. This can then be represented like so to locate the "root" vertex point of the Hit Box of that Item ...
Base Item: XXXYYYZZTVYYPPRR
X = X axis coordinates (in ft)
Y = Y axis coordinates (in ft)
Z = Z axis coordinates (in ft)
T = Room Type Exclusivity (ie. Control Items only in Control Room Blocks)
V = PvP Raid Pathing Exclusivity (0 or 1)
Y = yaw rotation
P = pitch rotation
R = roll rotation
Again, this is a 16 character integer only string (which could potentially be shortened to only 14 characters) to define the location (X, Y, Z) and orientation (yaw, pitch, roll) of a Base Item in three dimensions. It is also possible to define if an Item requires Raid Pathing Exclusivity to prevent other Items being placed within the Item's Hit Box by use of a boolean integer value.
Now, one of the limitations that will need to be made, is that the Hit Boxes which define the outer boundary "space" that an item will occupy
NEEDS to be confined within the volume "carved out" of the Base Plot Volume by the Room Blocks. What I mean by this is that it should
not be possible to have a Base Item's Hit Box extend beyond the boundaries of the volume of the (contiguous) Room Blocks. That means no rotating an Item in such a way as to put part of it through the Floor, Wall or Ceiling of a Room Block. Likewise, Base Items are "not allowed" to exist outside the boundaries of spaces defined by Room Blocks and a "sanity check" can be (relatively easily) programmed into my proposed Base Editor to verify these things (and flag offenders for the Player to deal with/clean up) via an optimizer script (as first mentioned in my OP).
Now as far as *I'm* concerned, the real beauty of this entire "bootstrapping" system of building things up in Room Blocks, working out a coordinate system to express that in integer strings which can then be exported/imported via text files, and having a 3D GUI element assisting with controlling it all above and beyond mere Point'n'Click interfacing is that it allows the entire rendering engine to operate on a VERY object oriented basis. It becomes possible to define each
element to be used in the Base
*once* and the specify all of the locations within the Base where that element is to be found ... and it uses the same scheme and notation (16 character integers) for both creating empty spaces (Room Blocks) and filling those spaces with "things" (Base Items) within those space. And the entire coordinate notation system that I've presented makes it possible to run both "sanity checks" as well as record keeping "optimizer" routines so as to sort both Room Blocks and the Base Items within them in ways which can make life easier for the game engine to render both the environment and the objects within it in a more holistic sense for the entire Base.
I see the Coordinate system basically calling for an Asset (such as a Lamp or a Tree or an Entry Room Block, for example) *ONCE* ... and then defining all of the locations within the Base Plot Volume where copies of that one Asset are found, using the 16 character integer string for each copy of that particular Asset. The next data set calls for a different Asset *once* ... and then defines all of the locations where copies of *that* Asset are located.
One side effect of doing things like this is that rather than setting up the Base Editor to have a sort of "Current Room" function like what we've got with the Legacy Editor, instead you've got something more akin to a "Current Assets" function, where you specify which Asset you wish to address, and then scroll through all of the locations
scattered throughout the entire Base that that particular Asset can be found. The difference is that with data organized (and optimized) the way I've been talking about so far, it should be perfectly possible to streamline (by resequencing) the sequencing of Assets by coordinates such that a "search" through the location(s) of any particular type of Asset is
not limited to only a First In-First Out ordering like what we've got using the Legacy Editor in its Current Room functionality and limited
by Room to addressing particular Base Items.
By the way, in case anyone is wondering ... I can easily see an SG Base with 30,000 Assets (Room Blocks, Base Items and Storage Container Contents combined) needing about 500kb (at most) worth of plain text file to record the WHAT and WHERE of everything that is needed to record an SG Base in a plain text file that could be saved locally to a player's CoH game client and potentially(?) speed up the zoning transition when entering one's own SG Base. Considering that Mission Architect allows us to have THREE story arcs of up to 100k each to begin with ... that's not all that
bad considering that Players can only be a part of ONE Supergroup at a time. In fact, I'd argue that allocating 0.5 MB
*at most* to an SG Base, with the understanding that that is a MAXIMUM and that hardly any SG Bases would be that "big" ... and that most would be hard pressed to exceed 300kb worth of 16 character integer data strings (~18k Assets) ... I'm thinking that would be a *bargain* for Paragon Studios in terms of data management and storage. And that's assuming I'm even doing the math right on how much memory these things would cost (ie. I'm probably not, but work with me here).
Oh and just so there's no confusion ... when I'm talking about Base Items above, I'm referring to every object that can be found in the Personal Item and Place Item modes of the Legacy Editor. That means all the Arcane, Tech, Lighting, Room Details, Chairs, Shelves, Wall Items, Pillars, etc. etc. etc. I'm just lumping under the general heading of "Base Items" for simplicity. Hope that didn't trip anyone up.
Anyway, that's about all the time I've got for this trip to the
WALL OF TEXT CRITS YOU! 
If you're still reading this at this point ... you may actually have more patience and/or interest in this sort of thing than I do! I'll try to get back to writing up more of my ideas concerning revamping the Base Editor in particular (and SGs in general) probably by next week sometime. Next time I'll try to get around to discussing things like how an entirely revamped Base Editor would handle things like Base Rent (including if this is even relevant going forward) as well as how to deal with Raid Pathing and the fabled PvP Base Raiding Options that could be built into a Base Editor like the one I'm envisioning (and at great length laying out here in this thread).
Until then ... May The Force Field Defender Be With You.
Yeah except for the "nothing is going to happen in Issue 21" (where we got alphabetical listing of storage and, if you count 21.5 now this) and huge crit walls of text on a new editor (when the devs were all the while adding Z-axis and rotation to the existing editor) you've been spot on... the devs did do something.
