We should be VERY excited about this upcoming feature!

ABJECT_SELF

I was happy to see we finally have a new development build (8193.21) but even happier to see the feature list, as there's some very exciting stuff here. The new game launcher, UI customization and water physics are great and all, but there's one feature listed here that could completely change how NWN modules are built and I don't see people talking about it yet.



I'm talking about visual transform "lerping", or the ability to smoothly transition between different object transform values. Right now it's awkward to implement these effects during gameplay because they happen instantly, but with lerping, players can actually see objects grow and shrink before them. I know this sounds like a fix for a minor inconvenience, but there's a trick this feature would allow that every builder/scripter should be aware of.

All through NWN's long life, getting placeables to move during gameplay has been incredibly difficult without explicitly creating animations for them. If you wanted a boulder to roll down a hill or (in my case) a car drive off a cliff, you'd have to destroy and recreate that same object over and over in slightly different positions, and players would still see the object "fade" from one location to the next. Shadows of Undrentide attempts something like this during the campaign, and while it's a great cutscene, watching that boulder jump from frame to frame still breaks the illusion.

Now the great thing about this lerping feature is, according to the announcement, this applies to ALL visual transforms, not just scale but XYZ offsets and rotations. This means scripters finally have a means to animate moving placeables! You could drop a placeable, add a positional offset to place it at the starting position, code a new offset with lerping and the amount of time it takes to reach the end offset, then watch the placeable move from starting position to end position in real time!

The possibilities here are pretty wild. You could have a castle wall be breached and code that wall section to collapse before the player's eyes. You could have the player be chased by a giant, rotating boulder Indiana Jones-style. You could even use it on creatures to make them leap across ledges or fall through a collapsing bridge.

I'd love to see everybody taking advantage of this once it's pushed to the stable branch. I might even build a library specifically for real-time placeable animations if it encourages more interactive environments.

TarotRedhand

Nice and all but don't forget that these transforms only apply to the visuals. They don't effect collision detection because the walkmeshes for various things are not altered. Once "moved" the PC can walk straight through them. This renders this feature of limited use. Unless you are aiming for illusions (say a doorway blocked by a bookcase that can actually be walked through) you need to find ways to keep PCs away from things altered by SetObjectVisualTransform().

TR

FreshLemonBun

It's a nice feature noted and kind of asked for when the visual transforms first came out. It's nice to have but I think we're exaggerating if we say it will change how modules are made. Maybe we can sort of simulate some things better like climbing or jumping but it still wont be perfect.

On the other hand please turn your attention to this little thing. If this does what I (and maybe others) have asked for then it's pretty big in changing how NWN works or at least in how it's presented to the player.

// Overrides a given strref to always return sValue instead of what is in the TLK file.
// Setting sValue to "" will delete the override
void SetTlkOverride(int nStrRef, string sValue="");

FreshLemonBun

Okay so I did a quick test and it's not that great.

Seems like they forgot to make it parse custom tokens in the same way that the tlk itself does. That's a pretty big oversight.

It's still not impossible to work with but you have to get the data other ways which is more clunky and prone to errors that give glitchy outputs i.e. missing names if the target isn't acquired fast enough. There are probably other things that make it difficult to work with that I haven't seen yet. Otherwise you probably use it for all sorts.


Another thing missing is setting the default entry to no entry since "" resets it to the original. Setting it to " " will probably introduce a blank line which doesn't look as nice as no line.

Proleric

Glass half empty, perhaps?

For text not involving tokens (the vast majority?), if we can avoid the need for a custom talk table, that's one huge download less for players.

FreshLemonBun

I would not say that it's useful for replacing a custom tlk. The function needs to be called for each row you replace and I don't think it's a good idea to try and shift that to scripts. The download is not really an issue. This does however allow you to make changes to the dialog.tlk rather than a custom tlk, without getting players to override the dialog.tlk which you obviously don't want to do. If you're only making minor additions to a custom tlk then it could be useful but after a few hundred replacements I think it would get unwieldy to manage.

The glass is not half empty, it's more like that's a pretty necessary feature in the way text is handled. It's also the difference between needing to override the tlk reference each time as opposed to just changing the custom tokens in a template tlk entry. So I really hope they notice that and consider adding the functionality as soon as they can.

In other news...



Here is another use I tested, using onmoduleload. I noticed the first time I tried it the change didn't take, when I tried it a few more times the change did take. So I'm not sure if there are any quirks to onmoduleload but it could be a little unreliable. If this can be done reliably then it's really huge.

ABJECT_SELF

TarotRedhand wrote: »

Nice and all but don't forget that these transforms only apply to the visuals. They don't effect collision detection because the walkmeshes for various things are not altered. Once "moved" the PC can walk straight through them. This renders this feature of limited use.
TR

That's been the case with visual transforms so far. While not ideal, there's a few tricks to get around this, like creating invisible walls or having the object's end location be its actual position in the toolset.
Of course, sometimes you don't need collisions. I'm planning a system with this feature where a trap causes a room to fill with water (like in the early levels of Bioshock), complete with the water level rising over time using visual transform lerping. Can't wait to show that one off

Shadooow

ABJECT_SELF wrote: »

I'm planning a system with this feature where a trap causes a room to fill with water (like in the early levels of Bioshock), complete with the water level rising over time using visual transform lerping. Can't wait to show that one off

CEP flooding trap does that for years.