1056 réponses à ce sujet

[Tchos]

I'm still in the process of relocating, and much of my time is occupied by household work. I also don't yet have internet access here, so everything I'm doing and writing is offline, waiting for me to have some kind of access so that I can upload/post it, as I'm doing now.

Recent work (and I wish I could show a screenshot for this, or a video): The first thing I did was create a new VFX marker for a spot on the sea where the player will be told about as a diving spot. X marks the spot! I tried to make it look like the kind of X you'd find on a treasure map. This clickable spot and its map pin only appear when you've been told where to find it.

I made a marker like this instead of the usual overland map spawning placeables because it's the site of a sunken ship, where nothing should show on the surface of the water. The idea is that the captain of the ship follows a map to this location, which is explained in the dialogue.

Certain transitions are also handled by dialogue, but these are special transitions that involve relaying important information to the player before actually going in. This is also accompanied by a faded-to-black screen and appropriately atmospheric sound effects.

[Tchos]

I wanted to do a test to make sure I could add new content to the module after its release.  The way I set up this framework, I like the idea of making little extra quest add-ons for it, such as for holidays or special events, based around this sizable town.

Now, part of what I've done here was also necessary since the town keeps crashing my toolset, and I didn't want to have to try loading it anymore, so I thought that if I can just add anything else I need to it via scripting, I won't have to open it ever again.  And I think I can do that, even though I neglected to add any phantom scripts into the area's On Exit, On Heartbeat, or On User Defined Event fields.  It does have custom scripts in the Client Enter and On Enter, though, so that'll probably be enough for my purposes.

Even though I placed dozens of tagged waypoints and tagged non-static objects all over town, there are still many areas where I'd want to place things that don't have anything convenient nearby, so I needed some other way to reference specific locations, and I knew of one method from looking at the script for the icicle melting quest in MotB, which provided an example of how to get a location from a specified vector.  Great!  Then I just needed a way to pinpoint a vector for any given location.

I looked around in scripts and includes for a while, before finally going in-game and checking the command console.  I found the "loc" command there, which reports the vector of wherever the PC is standing.  So I stood in a particular place, and wrote down the vector.  Then I moved out of the way and saved my game, so that I could test this spawning in a saved game.

Next I added a few lines to the On Module Load script, which is a campaign script.  For an add-on release, I'd distribute this modified script to replace the one already in the campaign folder.  The new lines first check to see if a tagged add-on object exists, and if not, it spawns it at the location derived from the specified vector.

So I loaded my saved game, and indeed the new object was there.  So this bodes well for adding post-release content, modifying the contents of the town area through scripts.

A couple of things that aren't ideal -- the spawned placeables of course have no effect on the walkmesh, so if I don't want the player to be able to walk through them, I'd have to set them to dynamic collisions, and I'd rather not do that for performance reasons.

Also, I couldn't find a way to check the angle my PC is facing, for specifying the heading/rotation in the location, so I had to eyeball it based on the direction of the arrow on the minimap.

I added a shady goods dealer to provide your rogue supply needs.  This character is a friend (or at least an "associate") of the rogue companion that you can recruit.

Mm...some interesting troubleshooting I had to do for the overwater map.  My tests had revealed some problem when I transitioned to the map using a character other than the main PC, and a different-seeming problem if I used any character other than a dwarf.

I found one problem quickly -- I was setting the ship VFX on the PC object each time in the while loop, and not the party member object, which cycles through the party.

The other problem was that different character races created different sized ships, and any player-created characters that had used the height or girth sliders caused noticeable distortions in the ships.  I determined that this is because EffectSetScale() is relative, while SetScale() is absolute.

I fixed this by first getting the current absolute scale of each PC with GetScale(), and saving the floats to local variables for later, then resetting the scale with SetScale() to 1.0, 1.0, 1.0 for while the players are on the overwater map.  With all party members at a standard 1.0 absolute scale, I then applied the EffectSetScale() on top of that.  That part might not have been necessary, but it saved me from rewriting too much code.  On exiting the map, the original scale values are read from the variables, reapplied to each PC, and the effects are stripped.  On testing, this worked.  The ship now looks correct no matter which race of PC is controlling it, and whether the party members are player-created or recruited companion, and the original scales are correctly reapplied after existing.

[Lugaid of the Red Stripes]

You might try duplicating that area and stripping down the duplicate, so you could at least look at things in the toolset when you try to place them.

[Tchos]

That is a good idea. Of course, the last time I attempted to fiddle with it was in stripping it down a bit, and that didn't work out very well. I reduced its dimensions one step along two of its sides that didn't need quite that much space, but then the next time I tried to open it, the toolset threw up so many errors they couldn't all fit in the message box. I restored it from backup and resolved not to touch it again.

It's fine, though. I think I can just write a script to report my PC's heading in-game with GetFacing() for the purpose of finding the spots I'll want to use. I don't actually need to see the item placed down in the toolset.

[Tchos]

I'm still in offline mode except for brief periods, but that should be taken care of by this weekend.  In the meantime, here's some of what I've been working on.

More troubleshooting, this time in the underwater areas.  Player-created party members (and the player) were using the swimming animation correctly, but recruited NPC companions were not.  In fact, if any of them were in the party, no one swam.

I first checked to make sure the NPCs actually had the correct numerical appearance set with a little debug script.  The script reported that the values were as expected.

After several experiments, I determined that the problem was that I had put the animation-switching script in the wrong slot.  I had put it in On Enter, and while that was sufficient for certain party members, it wasn't for the others.  All I know is that the party is not guaranteed to be present by the time the On Enter script is fired, thanks to Bob Hall.  So I moved it to On Client Enter, and then all party members were swimming correctly.

However, now the tour guide wasn't in her starting spot, and the swimming animation did not switch back to normal after leaving.

I split the script up into three fields (On Client Enter, On Enter, and On Exit) for its different functions, where previously it was all the same script.  Now On Client Enter and On Exit just handle the animation-switching, and On Enter handles the tour guide initialisation.  Now it all seems to work in all combinations of companions, and it also sends the guide to talk to the currently controlled PC, instead of the first.

I observed some local beta testing from a friend, but not much, since visiting time was limited.  We did catch one pricing issue, though, which again was caused by the item being marked as Plot, which sets its price at 0gp everywhere except on a vendor, who marks it up to 1gp.

I filled out the barks in the tavern.  I wish there were more "sitting" emotes that can be called from a seated NPC that wouldn't cause them to stand up to perform the emote.  A laugh, in particular, would be useful here.

I filled out a few flavour items -- the resting and the meals.  I had done a resting scene before with a Targa file of the rest scene from Baldur's Gate, but during that beta test I mentioned before, the tester mentioned that he liked the rat in BG that runs across the floor when you rest.  I told him I couldn't do that because it was just a static image.  But tonight I took another look at the image, and determined that it wouldn't be a big task to just recreate that scene in the game, and put in a rat running across the floor.  It went pretty smoothly, and I ended up with a reasonable approximation of that scene that plays when you rest at the inn.  For consistency, I added similar scenes to play when you rest in the other beds in the game, and other scenes for the meals that you can order at the inn and the tavern.  These are basically "slides" to illustrate and represent the action you're taking.

As far as the meals themselves, this involved writing a script to randomly select 8 meal offerings from a total of 46 (2 each from 4 categories).  Meals are purely RP-oriented flavour items, and have no in-game effect.  You pay a token amount, and get a small scene and description.  All of these meals should cost less than 1 gp (much less in some cases) but since there's no currency in NWN2 that's smaller than a gold piece (unless I were to add one of the available money systems that add copper, silver, and platinum coins), my choices were to charge nothing (since the cost would be negligible to a level 10 character), charge the lowest possible amount (higher than it should be, but this is consistent with other mundane in-game items that sell for 1 gp even though they should cost less), or include meals with the cost of renting a room (this would not work here, since one of my places that offers meals does not offer rooms for rent).

Anyway, this seems like the sort of place where a new meals.2DA would be useful, but I opted to just include the menu items in the script itself.  Maybe in a future module, I could include the P&P currencies and use a 2DA to put in all the menu items, giving each an appropriate price instead of having a flat fee for everything.

These were items that have been on my to do list for a long time.  Glad to finally get them taken care of.

I also filled out the Witcher-style safe deposit boxes that I had implemented early on.  They were already functional, but they were free, and I also thought it might not be completely clear that the two locations that offer them do not share their contents.  I added more explanation for them in dialogue, added a modest fee, and a key requirement to access them.

[ColorsFade]

Tchos wrote...


I had done a resting scene before with a Targa file of the rest scene from Baldur's Gate, but during that beta test I mentioned before, the tester mentioned that he liked the rat in BG that runs across the floor when you rest.  I told him I couldn't do that because it was just a static image.  But tonight I took another look at the image, and determined that it wouldn't be a big task to just recreate that scene in the game, and put in a rat running across the floor.  It went pretty smoothly, and I ended up with a reasonable approximation of that scene that plays when you rest at the inn.  For consistency, I added similar scenes to play when you rest in the other beds in the game, and other scenes for the meals that you can order at the inn and the tavern.  These are basically "slides" to illustrate and represent the action you're taking.

That is very cool. 

When you create that scene, do you save it off somehow then, for reuse when you rest? Or is it something that only happens when you rest in that particular spot, because it's part of the area? I'm fuzzy on the details of how you did that. 

I was thinking about doing something similar for when you first enter a new area, kind of like the short movies that played in BG1 when you enter Beregost for the first time, or Durlag's Tower. I just wanted to do a cut-scene of a particular spot in the area, maybe a couple townsfolk walking by, that's it. But just having that establishing shot is kind of cool. I just don't know if that's something that can be saved then, or how to pull it off. Not sure if I will do it or not, but it's an idea. 

[Tchos]

@CF: It's part of the area in each case.  There are three locations that have usable beds or a rentable room.  Resting in the wild doesn't require a scene like this, since I'm using the MotB wandering monster chance rest interrupt system.

The past few days' updates:

A lot of my design work has always been stymied by two things -- the inability to rotate placeables sideways, and the lack of bottom faces on all rock placeables (and placeables in general).  Often, I want to place some items above eye level, but I cannot because it would reveal the nothing underneath.  Well, at least now with Gmax I can provide myself with the necessary placeables.

I modified some RWS cliff faces to face downward for use as roof fillers, patches, and overhangs.  An important note: When modifying a copy of an existing mesh like this, it's not enough that the file name be different (even renamed with MDB Cloner is not enough).  The mesh's selection name (not sure of the terminology) within Gmax must also be renamed, or the toolset will not allow both separate appearances to exist in the same area at the same time.  The effect seems to be that whichever one is loaded first, if the selection names are the same, the toolset will use the data for the first one on both of them, even though the meshes themselves are different (different meshes, different filenames, different lines in the 2DA).  I had encountered that effect before when trying to adapt some MotB flat plane ("card") placeables, but at the time I didn't have Gmax, nor any experience with it, so all I knew was that those placeables were somehow different from other ones that I had successfully modified using MDB Cloner.

These new placeables should afford me a similar level of freedom of design for natural interiors to what I've been enjoying with the placeable walls for manmade interiors.  I've opted for the method of using the exterior area terrain deformation in lieu of the cavern tilesets, for the sake of freedom of elevation.  There are several methods out there for simulating cavern roofs in such situations, such as skyboxes, domes, dark fog obscuring where the ceiling would be, or roof placeables such as Ar Pharazon's cave roofs.  The ceilings are important here and part of the design, so I'm going to try a combination of these new placeables along with Ar Pharazon's cave roofs.  If I can make an interesting area to explore, it'll be worth it.  That's assuming, of course, that I can make it so that it doesn't introduce any navigational or camera-related annoyances not present in the standard tilesets.

AP's cave roofs required some modifications.  They were double-sided, and their fade property was set to false.  This means the roofs block the camera if they're close enough to the ground, and they also block the map.  Changing the fade property was just a setting in the placeables.2da, but I had to use Gmax to make them single-sided.  Opening them up, I found that the polygons were not actually double-sided, but that there was an intentionally-added extra copy of the ceiling mesh (in the same element) floating slightly above the down-facing one, with flipped normals.  I deleted the extra one.  While I had them open in there, I also saw that they had some extra phantom objects with the names HP_DR_STD01 and HP_DR_STD02 that I couldn't see a use for (they didn't contain any points or polygons), and also had some standard sub-objects that I don't think are necessary.  For instance, this is to be used as an environmental object ceiling, and thus I don't think it needs a walkmesh.

There were also a few stray polygons in separate smoothing groups that were causing some noticeable triangles.  I changed them all to a single smoothing group.  The revised models seem to work fine with the walkmeshes and C3 collision removed.

I also made a couple of full floor-to-ceiling rock columns (the meeting and fusing of stalactites and stalagmites).  I found, after I had made those, that Botumys' Drow Cave set includes several of these, as well as another set of roofs and other placeables that are useful for any kind of cave -- not only a drow cave.  It saved me the trouble of making some stalactite plane "card" placeables like I was going to, since it already had that and a few others.  I added a few of them to the palette, though I had to correct the 2da listings so that the appearances didn't all use the StrRefs of default toolset placeables (before this fix, the appearances all had duplicate names like RuralBHouse01 for the cave roof and rock columns, making it difficult to find the correct appearances in the toolset).  Also made them tintable.

Back to the default resources.  In general, most of the rocks in the toolset are upright.  Most of the time, I don't want upright rocks -- I want more flat-topped ones.  Also, they're in clumps with smaller rocks and surrounding dirt.  This, combined with their lack of bottoms, makes it difficult to use them on slopes, because there are parts at the bottom sticking out of the side of the hill unless I move them so far into the side that there's hardly anything showing above the ground, or create a special flattened terrain spot just to put rocks on.  There was another modder I was talking to a few months ago who was looking for more general-purpose rocks.  Maybe now I can provide him with some.

The mushroom clusters have a similar problem with slopes, since they seem to have been designed to be used on flat cave floors or flattened areas of exteriors.  The area of the clusters is too large to put them on sloped terrain.  In most cases, I want to put small mushrooms as decorations in places that are not flat, and in non-walkable areas, as a visual cue that the player should not try walking there.  Reducing the number of mushrooms in the clusters will fix that, just having two or three right next to each other instead of a dozen in a wider area.

Sometimes I regret this being a level 10 adventure.  My next one will definitely be for lower-level parties.  The toolset's selection of monsters and other enemies that fit this modules environments (such as the aquatic ones) aren't typically of a high enough level in the Monster Manual to properly challenge a level 10 party, even with the addition of some custom monsters.  What I've been having to do in some of these cases is create tribes of stronger variants of these creatures, which I prefer not to do.  The most recent ones are the kuo-toa, which are typically CR2.  It does make reference to kuo-toa of "7th level and higher", though, so there are clearly some out there, and it's probably fine to have a tribe of toughies here at the bottom of the sea, where ordinary folk would never see them.

I did my best to make the kuo-toa match their Monster Manual stats and abilities.  In some cases, I used approximations.  Some feats were irrelevant to this environment (you won't be fighting underwater).  Next I need to set up the sahuagin blueprints.  I checked the monster packs first for blueprints, and then Krondorl's D&D Monsters Compilation and Wild Bill's Monster Manual Series, but didn't find any blueprints for sahuagin.

Unfortunately, the drow cave stalactite columns were unsuitable for this cave in terms of how the light illuminates them, so I'll just stick with the ones I made.  Unfortunate, since I spent most of the day working with them to try to get a compatible texture on them, seeing how they and the other placeables were used, and reassigning the 2da entries.  I may still have a use for one of its ceilings, since it has a shape that can make it easier to connect to differently-angled ceilings, and the big glowing mushrooms are nice, as well as the particle effect they come with.

I was supposed to have internet back by now, but they're showing a lot of incompetence getting it installed, and wasting a lot of time.

Modifié par Tchos, 31 mars 2013 - 03:40 .

[Dorateen]

Tchos wrote...

The most recent ones are the kuo-toa, which are typically CR2.  It does make reference to kuo-toa of "7th level and higher", though, so there are clearly some out there, and it's probably fine to have a tribe of toughies here at the bottom of the sea, where ordinary folk would never see them.

This comment made me think back to other D&D adventures. What level were the kuo-toa in the underdark in BG2? They must have been up there. And I think I fought some in the higher-level range in Death Knights of Krynn. So it should be alright.

I actually enjoy 10th level adventures or thereabouts. A nice range of abilties and items to use.

Modifié par Dorateen, 01 avril 2013 - 03:35 .

[ColorsFade]

Dorateen wrote...

This comment made me think back to other D&D adventures. What level were the kuo-toa in the underdark in BG2? They must have been up there. And I think I fought some in the higher-level range in Death Knights of Krynn. So it should be alright.

I actually enjoy 10th level adventures or thereabouts. A nice range of abilties and items to use.

I agree. 

I think fretting about level range for creatures is mostly unnecessary. Sure, there are some creatures that probably shouldn't be found at lower levels (beholder, illithid, dragons), and a level 20 kobold probably isn't very likely either (although, now that I think about it, that might be kind of fun, and funny, in the right setting), but for the most part, I think it is totally acceptable to adjust creatures up/down to accommodate a story. 

Kuo-Tao don't strike me as a creature that really needs to be limited up/down one way or the other. Have fun with it. 

The big thing here, as I look at it, is that they fit the story. This is an underwater adventure (and I think Tchos is really doing something neat here with this). So use creatures that fit, and adjust their level ranges and spells/abilities accordingly. 

And yes - level 10 is a fun level range. A good mix of spells and abilities. 

[Arkalezth]

Dorateen wrote...

What level were the kuo-toa in the underdark in BG2? They must have been up there.

Well, BG2 started at around that level, and you visited the Underdark in chapter 5 or so, so they must have been of an even higher level.

I'll echo what others have said about level ~10. I think the game's at its best there. Lower levels (until 8 or so) tend to be significantly more boring IMO, as you don't have many options, half of the classes are not even available (and some of the available ones are not too different from each other early on),buffs are over in the blink of an eye, combat is slower because you only attack once every 6 seconds, etc.

Besides, I think we already have enough low level modules out there. It's good to see one where you can reach a decent level, for a change.

Modifié par Arkalezth, 01 avril 2013 - 05:36 .

[kamal_]

Whatever's fun, as long as it's internally consistent. Don't make your level 1 enemies generic orcs and then have your level 20 enemies also be generic orcs. The Kua-Toa/Sahaugin whatever in BG2 were fine because you never saw them elsewhere.

[Tchos]

Well, all right, then. I've been soundly convinced! Thank you for the feedback, everyone. I expect I won't make the next one lower level after all, or at least no lower than level 8.

As far as a level's spell power is concerned, I see the cleric's Raise Dead spell as a kind of threshold -- a sudden spike in power that you can first cast at level 9 (if I recall correctly).

Perhaps in OC NWN2 it isn't such a big deal, since companions auto-rez, and even in SoZ where they don't auto-rez, there are cheap Coins of Life (and cheaper scrolls) that you can afford much earlier, and there are no pen & paper penalties or material component costs to act as a level-limiter for it. But to me, gaining the ability to raise the dead seems like a pretty big rite of passage, so starting at level 8 would seem to be a good thing. Possibly.

[Alupinu]

kamal_ wrote...

Whatever's fun, as long as it's internally consistent. Don't make your level 1 enemies generic orcs and then have your level 20 enemies also be generic orcs. The Kua-Toa/Sahaugin whatever in BG2 were fine because you never saw them elsewhere.

Amen to that! Verity is the spice of life and good gaming.

[Dann-J]

kamal_ wrote...

Whatever's fun, as long as it's internally consistent. Don't make your level 1 enemies generic orcs and then have your level 20 enemies also be generic orcs.

Diseased orc, orc scout, orc warrior, elite orc warrior, orc general... all the way up to 'Avatar of Gruumsh', at which point you run like hell.

[Tchos]

Dann: If I were to include an avatar of a deity, it would be an avatar of Sune, I think.

Tsongo: I have Heegz' Hobgoblins blueprints on hand in the event of including some hobgoblins somewhere. They're also tinted and sized goblins, like yours, but I think they've done the work of adjusting the stats according to the Monster Manual, which would save me some time. Though, then again, I might want to change their appearances to batiri, just so that they're fiercer looking goblins who aren't all wearing kilts.

It's funny how a three-word note on my to do list ("Destroy shrine option") can amount to so many hours. Well, to do it the way I wanted, anyway. The easy way would be to just make the thing bashable, and give little or no feedback on the effects. But it is of course comprised of multiple objects, as well as visual effects and lights that also needed to change if you choose to destroy it, and I wanted to provide more options, and consequences for the actions, and extras like spawning appropriate rubble, special effects, etc., and that's why it all took a while. It's off the list now, though.

I wrote another utility script for the purpose, which can be useful in other areas. The ga_effect script uses integers from the visualeffects.2da file, but it doesn't seem like all of them work. I'm not sure if this is one of those things left over from NWN1 or not, but I notice that some, but not all of them include named .sef files like what I usually use in scripts to create visual effects. I need to do a little more experimenting to know for sure, but it's not really important since my ga_ script instead uses the method I usually use, which is to specify the name of a .sef in the script's string, rather than a constant integer.

I made this one apply the effect at a location rather than on an object, since I was using a waypoint in this case to tell it where to apply it (since the object was being destroyed), but I'll make a slightly modified alternate version for applying directly to an object later for other purposes (for instance, I know how to remove a .sef from an object, but not from a location, which is important in the case of permanent effects rather than temporary ones).

Another few general-use scripts that came out of this were a simple one to damage the player a variable amount (seems like something that should be in there already, but I didn't see one) -- this one needs a little expanding to allow you to pick what kind of damage in the conversation fields like with the amount, but for this instance I've hardcoded the type.

Also a couple of placeable scripts: one for on damage, the other for on use, to start a conversation. I know there are several scripts there already to start conversations from placeables, but they start the conversation with the object itself, which is not good if you plan to destroy the object during the course of the conversation, so I made a modified version to read the intended conversation-starter (such as an ipoint) from a string on the object. I used a separate script and separate string for the on damage and on use versions, just in case any future use of these scripts would require different conversations for the two different actions.

I also set up the wandering monsters in the 2da for this area (which is the final area), so that only aquatic monsters have a chance of disturbing your rest. I may not have mentioned it before, but I've been careful to specify the selection of wandering monsters in each area that has them, so that they're always appropriate for the type of environment.

[Alupinu]

In MinD I have hobgoblins. I just used the half orc model, turned the skin a dark orange-red tint and dressed them in junky looking hide armor along with half plate helm. I thought it made for a pretty convincing and fierce looking hobgoblin particularly when you give them the orc sound set.

[Dann-J]

Alupinu wrote...

In MinD I have hobgoblins. I just used the half orc model, turned the skin a dark orange-red tint and dressed them in junky looking hide armor along with half plate helm. I thought it made for a pretty convincing and fierce looking hobgoblin particularly when you give them the orc sound set.

I did something similar with the greyorc model for my hobgoblins. I gave mine the bugbear soundset.  I scaled them down slightly in the Y axis to de-emphasise that bison-like hump though.

The half-orc  has some interesting additional armour accessories that other player types lack (greyorcs and hagspawns also use the half-orc accessories). Quarrel's mash-up chainmail variant from SoZ is especially hobgoblin-like, given that they usually make armour from bits and pieces they retreive from fallen enemies.

[Tchos]

Hmm, if only hobgoblins were able to undo the buckles and straps, like a typical adventurer, they could retrieve fully intact suits of armour from their fallen enemies, instead of just bits and pieces.    Actually, one thing I like from the early Elder Scrolls games is how many gear slots there are, where as a player, you could really make a patchwork mess outfit if you wanted to, much like we can as modders in the toolset with the creatures that have those armour pieces, with individual left and right shoulder pieces, head, chest, legs, belt, and individual left and right arms.

I went through some of my earlier heartbeat scripts and did a little rewriting for better CPU efficiency.  There were a few from the earlier work that were doing their full processing without any PC presence, so I added the early checks and aborts that I had built into the ones I wrote later, and replaced a few legacy commands with their improved counterparts.  People reading through my code to see how to use my scripts will probably appreciate the more streamlined versions.

I also added a couple of script lines for the vision of the past (HideHostileCreatures & ShowHostileCreatures) so that enemies of the present would be hidden and not distract from the vision until it ended, and scripted the ipoint that controls all of these events to spawn only when the quest is at the necessary stage, rather than being there the whole time.  I had already scripted it to destroy itself at the end of the events, but this saves an extra little bit of heartbeat processing before that time.  It seems to work in my test, which is good.  Fiddling with something complex after it's already working always has the potential to mess things up.

While I was in the forest, I also prepped another door for future expansion.

Speaking of messing things up, I found that I can't use the usual check that I normally use to abort a heartbeat early (to save processing if the PC's not around, in cases where the heartbeat doesn't need to do anything without the PC there) if the heartbeat is on a placeable, because placeables don't have AI, and thus:

if (GetAILevel() == AI_LEVEL_VERY_LOW) return;

always returns TRUE because the constant AI_LEVEL_VERY_LOW = 0.  For placeables, instead, I'm using a check to see if the PC is in the same area as the placeable.  If there's a more efficient way I could abort the heartbeat early on a placeable, I'd like to know.

I also made a new trigger script for subzone name displays, as in The Witcher.  My thanks for this go to Marshall of Legends and Seraphimsage, whose custom UI displays served as the models for this one.  Examining the SoZ overland map also brought illumination on how to handle the triggers for it.

I have not found a way to define a new font style anywhere except in fontfamily.xml.  For the sake of mod compatibility, there should be a way to define a custom UI's own special fonts so that 1. They display as expected, regardless of any fontfamily.xml mods the user might have installed, and 2. It wouldn't require bundling one's own fontfamily.xml with the mod, with custom font styles included.  As it is, I'll do without the custom font, though I'd really rather have one for this.  If there is a way to add additional font definitions outside of the fontfamily.xml, I would like to know.

I have proper internet again, so I'll set about showing some screenshots for the more recent work, and maybe a video.

[Tchos]

My Questland area has been developing the same problem in opening as the docks area has, and it's nowhere near as large or complicated. I was just trying to open it to test out some loot variables on a series of creatures (confirming something in my tutorial on the SoZ loot system), but it crashed the toolset on opening 5 times in a row. It's not actually a problem in this particular case, since it's only a testing area, and there's nothing in it that I don't also have in the actual areas or in the blueprints. I can just delete the area and make a new testing area. It's just a nagging sign that this may be a pattern -- that the more I work with an area, the harder it will become to open it.

As I was adding crafting loot drops to my enemies, there were certain ones that didn't have any appropriate distillable loot, so I wanted to create a new distillable body part for a particular kind of undead that doesn't have any. Investigating how to do this (for the OC crafting system) led me on an interesting journey. I found the 2DA files that have recipe lists, but the notes in them by ChazM say that they shouldn't be edited manually, and referred to a module that would be uploaded to the Vault.

I retrieved the module and ran it, and it had some basic instructions on creating new recipes. Sort of. The module functions as a kind of compiler for the 2DA entries that should not be manually edited. However, it doesn't do the best job of explaining how you define new recipes in the first place. I think Chaz left a sentence or two out of the "Creating Recipes" book that you get in-game, or at least what's there could be phrased a little better. I had to re-read it a few times to understand what needs to be done, and I'm not the only one who had trouble with it, judging from some of the comments on the Vault. The confusion stems from the fact that since part of the recipe generation takes place in-game, it needs to be a little more explicit that the first part must be done before the module is loaded.

To define a new recipe (including a distillable body part), you first modify the script ga_setrecipes outside of the game. Then you play the module, talk to the deer and tell it to run the script, then run another script to export the recipes into a log. Then, outside of the game again, you open the log file and copy the results into two 2da files. Logging has to be turned on for this purpose, and instructions for that are here.

Reading through the script also revealed why the toolset item "Skeleton Knuckle" doesn't do anything, and is instead an unexplained junk item. The script uses a skeleton rib for the constant SKELETON_KNUCKLE.

Anyway, it all worked fine. My new item distilled into the essences as expected, and the required skill level was properly set. I wrote it into the new 2das, and tried it out in my module with those 2das, and it didn't work. So I checked to see if there were any other crafting 2das in my override. Sure enough, Kaedrin's PrC overrides those files. So I put the 2das into my hak to override the override. Users of Kaedrin's will thus be missing the 36 recipes added by that pack while they play my module, so that they will be able to distill this module-specific item, and any others that I may add.

Here's a video sneak peek at the early cave design. The lights are placeholders, and there isn't much in the way of decoration yet (I still need to make at least 1 or 2 important placeables for it), there's almost no object or enemy placement, and there are placeholder humans standing around that I just have in there for my own reference while I'm building, to get a sense of scale, but you can get a general idea of where I'm going with this.

And here's the eating and resting:

The X-marks-the-spot effect for the overwater map:

• http://www.youtube.com/watch?v=RZTacnIFKik

[kamal_]

Those are cool videos.

[ColorsFade]

The cave is awesome

[ColorsFade]

Tchos wrote...
AP's cave roofs required some modifications.  They were double-sided, and their fade property was set to false.  This means the roofs block the camera if they're close enough to the ground, and they also block the map.  Changing the fade property was just a setting in the placeables.2da, but I had to use Gmax to make them single-sided.  Opening them up, I found that the polygons were not actually double-sided, but that there was an intentionally-added extra copy of the ceiling mesh (in the same element) floating slightly above the down-facing one, with flipped normals.  I deleted the extra one.  While I had them open in there, I also saw that they had some extra phantom objects with the names HP_DR_STD01 and HP_DR_STD02 that I couldn't see a use for (they didn't contain any points or polygons), and also had some standard sub-objects that I don't think are necessary.  For instance, this is to be used as an environmental object ceiling, and thus I don't think it needs a walkmesh.

There were also a few stray polygons in separate smoothing groups that were causing some noticeable triangles.  I changed them all to a single smoothing group.  The revised models seem to work fine with the walkmeshes and C3 collision removed.

What would it take to get you to upload a .HAK with those fixed ceilings?