Call for ideas/feedback: Building "live" inside the game

[Legacy_OldTimeRadio]

               

I was going to post this a few days ago and I just didn't have time to write it all up.  Seeing the threads about CEP/Q and a potential CEP/Q merge I just wanted to get your opinions/ideas on this.  Right now there are a buttload of placeables in CEP and, IMO, the only way a fresh builder can really get to know them all is to basically go through, appearance by appearance, and memorize them.  BTW, this isn't specific to CEP, it's more of a general problem when you have a large number of placeable appearances and sometimes differing names for similar items.  Uh, so "Rock" vs "Stone" vs "Boulder".  That kind of situation.

 

Normally, the solution would be to just make palette entries for your appearances but we're talking about situations where making a blueprint for each appearance would be prohibitive.  So, pretty specific problem.

 

I'd like to get any feedback or ideas on how we could move some portion of the building process (let's just say placeables at the moment) to something that could be taken care of in-game or, put another way, outside the toolset.  Something which might allow even a newbie have a little easier time accessing the full range of placeables without having to invest so much time and memory to get up to speed.

 

Let me give you an example of what I'm talking about.  This is pretty convoluted, I admit.  The user would make their area in the tileset and set the raised or lowered areas, etc.  Then launch the map.  Their player character would have a bunch of widgets, each one basically a palette category or subcategory and by activating them it brings up a radial menu (hopefully with easy-to-identify icons) and they can place individual placeable instances or multiple instances (like a cluster of trees) using those widgets.  Adjust their facing, etc.  Then they run a special widget which writes all that information out to the log file and they run a utility to extract the data from the log file, converting it into XML which would be converted into a GIC for the area.  Area could then be edited conventionally.

 

Like I said, pretty convoluted.  I'm not entirely sure if some of this would be possible, like the radial menu (if there are any limitations there), or even how useful it would be.

 

Does anyone have thoughts on the topic?

               
               

               
            

[Legacy_henesua]

               

I have thought about this, including along lines similar to what you describe. The problem I see with the method you suggest is that the interface would be sub-optimal in game for selecting, placing and adjusting placeables. I think the toolset is probably the best we have until someone completely hacks all of this and makes a decent GUI.

 

So far I have not had any profound ideas to solve this. All I've got is to better organize with categories.

 

You can do this in two ways: (1) is to name placeables in the placeables.2da so that they can be found by category. This means the starting word of the name defines the broad category and each subsequent name helps make it more specific. But words toward the start are more likely to be shared by other resources.

Tree, Spruce 1

Tree, Spruce 2

Furniture, Chair 1

Furniture, Table 1

 

and so on.

 

One reason it is useful is because the appearance menu will jump to the placeable you are looking for if you start to type in the name while selecting the appearance drop down menu. Example: To get to the tools you type "tool" without pausing and teh menu will jump to the first name that starts with "Tool"

 

(2) Likewise you can make blueprints. This should be done more often, but teams are often worried about bloating the palettes of their module. This concern is overblown though because not all blueprints need to be in the module. You can give builders a set of blueprints or even allow them to make their own if you import their areas into the core module. Give them all these tools, let them build and then export their work for inclsion in the main branch of the module - the master module. The blueprints won't come with the area, and do not need to.

 

Blueprints can be tedious to make, but it is possible to automate the process for static placeables, one for each appearance. I know that with the tools this can be done. I however have not cracked this one, because a member of our team took it upon themself.

 

 

I also appologize for the ramble. My brain is a junk yard lately. Lots and lots of work and not enough sleep. I hope you can parse my mess. '> I'd like to ehar all about how others have tackled this same problem.

               
               

               
            

[Legacy_3RavensMore]

               

With too many brain cells killed off in my life, I can never remember what everything looks like from the simple placeable names, and I have a--perhaps silly--way of doing this.  I have a handful of "placeable selection" areas with all instances of the various categories of placeables, such as a furniture area, a light source area, a flora area, etc.  I can easily browse and visually choose what I want.  Once it's game time, those areas are removed.

               
               

               
            

[Legacy_Proleric]

               Yes, I generally have a reference placeable in areas under construction, which I can quickly change in the toolset to browse appearances, using an improved naming convention. I have placeables.2da open, too, for text search.

Beyond the issue of knowing what placeables look like, the OP also touches on creating placeable clusters in game. I've used scripts to make circles, other precise relative placements, and random scatterings. Since only static placeables can be seen at a distance, where necessary I print the locations calculated in game to the log, for cut-and-paste to static toolset objects (a tedious business; I've wondered about Letoscript, but it doesn't seem to have trigonometric or random functions).
               
               

               
            

[Legacy_Rolo Kipp]

               

<hiding something...>

 

I'd normally be all over this, but I'm going off in a rather wild direction with my semi-secret jME project. Two aspects that do apply here are

1) I do intend to build a cataloger/indexer/dependency generator that will iterate through the neverwinter directory and build a complete reference for all assets (not just models and textures). This catalog (with image/anim viewers, movie players and audio player) will eventually be integrated with the Vault. 

B ) I do intend to create alternate tools for creating/editing mods (based primarily on PSpeed's Modpacker, actually). Eventually, I might have a complete enough suite to replace the Aurora toolset. The above catalog will be integrated with these tools.

 

<...behind his back>

               
               

               
            

[Legacy_Rolo Kipp]

               

<musing aloud...>

 

To expand on that a little... I do like the idea of simplified development tools being available for the DM in game, even if it's just simple translate/rotate widgets for placing placeables.

 

One of the jME projects out there just implemented ingame images... so your PC can put up posters and photo's etc... That also sounds cool, even if you limit it to DM accounts only.

 

One of the mods for Skyrim made a "spell" that grew trees where you pointed ("Poison Petal Forest" or some such...).

That would actually be possible (non-static :-P ) in game now. Trees and other placeables... but the *chooser* to let you preview the object you want to place...

Hmmm...

Implement a "placeable-magic" system where the DM can see VFX of the placeable before choosing?

Perhaps build a 3D "radial menu" of appearances and target one to expand that branch for further options?

 

Without NwN2's GUI sub-system, we'd have to build a whole GUI layer ingame through scripting. But thinking about it, I don't think it's impossible. Just perhaps not worth the effort when we can be moving in other directions....

 

Ok, Work glares at me. I'm off again...

 

<...about druthers>

               
               

               
            

[Legacy_Tarot Redhand]

               

<SmeowG stirred>

 

Or you could just shout to the world that documentation is key. This is why all of the stuff I've released (under my id as opposed to the ccc) has a catalogue pdf document and a demo module (to show what stuff looks like in game). It just takes a little more effort. What is the point of releasing stuff if no one knows what's there?

 

<then crawled off to lurk again>

 

TR

               
               

               
            

[Legacy_FunkySwerve]

               

(2) Likewise you can make blueprints. This should be done more often, but teams are often worried about bloating the palettes of their module. This concern is overblown though because not all blueprints need to be in the module. You can give builders a set of blueprints or even allow them to make their own if you import their areas into the core module. Give them all these tools, let them build and then export their work for inclsion in the main branch of the module - the master module. The blueprints won't come with the area, and do not need to.

 

Blueprints can be tedious to make, but it is possible to automate the process for static placeables, one for each appearance. I know that with the tools this can be done. I however have not cracked this one, because a member of our team took it upon themself.

 

 

I also appologize for the ramble. My brain is a junk yard lately. Lots and lots of work and not enough sleep. I hope you can parse my mess. '> I'd like to ehar all about how others have tackled this same problem.

We solved the issue with a Builder's Mod for our module. It's an empty module, with a template for each placeable in the mod, along with some scripts from the module proper, like our vfx placeables script (allows placement of vfx, either duration or looping fnf/instant/etc). Avoids cluttering the module palette, and allows easy area construction. Once the areas are built, we do a letoscript pass to set all static places to incrementing names, so that only useable/interactable placeables show up at the top of the list.

 

Funky

               
               

               
            

[Legacy_OldTimeRadio]

               

Thanks to everyone for the expert input and perspectives so far! 

 

Sometimes it's difficult for me to know what's possible without actually testing it myself but with at least two (if not three) endorsements of a builder's module with a builder's palette, and the ability to build using that palette without necessarily impacting the palette of the production module (if I understand things correctly), that would seem to be "the way to go" for the problem I'm trying to solve.  In the three instances (outside of CEP) where I've looked at importing a mass of placeables, I think I was looking at around a max of 10,000-15,000 placeable appearances, total.  The blueprint limit on such a builder's module would come in around ~15k, minus the default blueprints from Bioware, correct? 

 

@Funky, has that Letoscript static baker been released?  The work I'm looking at might well only take place this winter so no hurry, but I hope you don't mind if I hit you up for some advice when/if I get that far.

 

@Tarot, I totally understand what you're saying about documentation but in my experience most people blow right over it.  A percentage do utilize the docs but these folks seem to be in the minority.  A good demo module is, I agree, key.  If not a demo video, etc.

 

For Rolo and others who have either kicked around variations on this idea or whose interest is piqued by it, the DTMS tool in CEP along with the Overland Map concept from Darkness Over Daggerford might be interesting concepts/tools to play around with and explore.  In the same way I loosely described the placeable placing and baking process in my first message, I had originally thought something similar could be used to assist in generating cutscene scripting, probably for use in conjunction with the Gestalt camera system.  On a slightly different point, something Rolo brought up about the possibility of using VFX in order to preview models, I want to include that adding them to to TailType.2da/WingType.2da and applying them to a null creature appearance might get around any limitation VFX might have, row-wise.  I love the idea of some kind of faux menu/chooser system within the game using this method and it "seems" doable.