38 réponses à ce sujet

[Tchos]

I've been tinkering around, and found some things that I haven't seen described here.

 

During my work on my last module, I had occasion to write several utility scripts for my use in-game.  One of them was to report the tags of the placeables around me for reference and later manipulation in areas that I couldn't easily open in the toolset.  Something I noted, but did not confirm until my more recent experiments in making 0HP placeables functional again, was that static placeables were also reporting for duty. 

 

I had been told that static placeables aren't affected by script, and so for cases in which I wanted to make a static placeable usable in a module update, I had been planning on doing something I had earlier confirmed to work, which was to spawn a usable copy of that placeable on top of the original, scaled and/or offset to cover it up, so that it could be used.

 

However, the scaling and imperfect covering of the static original will not be necessary, because DestroyObject() works just fine on static placeables.  If the player is currently in the same area as the placeable when the DestroyObject command is fired, then the static placeable will only disappear after the area is reloaded, either by exiting and re-entering the area or by loading a saved game.  Thus, when possible, static placeables should be destroyed when the player is in a different area.  The usable copy can be spawned in its place at any time.

 

Again, these experiments are mainly to increase the methods at hand to add to, change, or otherwise manipulate existing content in a module so that the changes take effect in a saved game in progress.  As it stands, almost everything can be changed or expanded.

[Dann-J]

I've never had much luck getting static placeables via tag in a script (probably because they don't have tags at all). Did you manage to pick them up indirectly, such as via a get nearest function, or within a spell shape loop?

[Tchos]

They do have tags.  They reported their tags to me.  I destroyed them using the tags they reported, using ga_destroy_object run from the console.  Would it help to show a video?

 

Edit: Sorry, meant ga_destroy, not ga_destroy_object.

[Dann-J]

How does the script get hold of them as objects in the first place?

 

Knowing a static placeable's tag wouldn't help in most instances, since the builder is unlikely to have changed the tags to be unique, and most static models tend to be used more than once in a module (houses, wall sections, etc).

[Tchos]

To report their tags?  The script that reports the tags of the placeables around me uses GetNearestObject, with a loop to report the tags of the 3 nearest placeables to my current location.  I first saw the static ones reporting their tags when I was trying to get the tag of a posted notice I had placed on a door, and found it reporting the tag of a nearby static pillar.

 

In these recent cases I tested, I used a series of placeables, both static and non-static, usable and unusable, environmental and environmental-converted-to-placeable, to test various properties and actions, and gave them each unique tags.  When I'm using these methods to affect actual module areas in scripts that are run within the module instead of conveniently-tagged test situations and scripts run from the console, when it is indeed as you describe, with placeables with default tags, I use GetNearestObjectByTag to get the ones closest to uniquely-tagged objects in known nearby locations, such as door waypoints.  Knowing the tag is indeed useful in those cases to narrow down the selection, since I can say "get the 3rd nearest placeable whose tag is 'PLC_MC_STONEWALL' to waypoint x".

 

As an added note unrelated to your query, I also checked to see if the "usable" property had any bearing on whether a placeable that is also marked as "static" could or could not be affected by script.  It didn't matter.

[Dann-J]

Interesting. It would seem that the GetObjectByTag() function deliberately filters out static placeables. It's good to know you can define them as objects in a script using alternate means.

 

I assume their ghosts still haunt the walkmesh after they've been destroyed though. Do they no longer block line-of-sight, or is that also baked into the area somehow?

[Tchos]

I don't think I've tried the normal GetObjectByTag().  The scripts I've used have either used one of the GetNearest* scripts, or (in the case of the ga_destroy) GetTarget(), whose function uses a multitude of functions to try to return a valid object, which as I'm sure you know but which I include here for other readers, begins with special identifiers, and then moves to GetNearestObjectByTag() before it resorts to GetObjectByTag() if it still can't find anything.  I'll try to confirm that GetObjectByTag() won't work for this.

 

The cutting of the walkmesh certainly still stays in place unaltered, so I would use this in cases where I'd be replacing the static one with something else, and preferably not just removing it entirely, so characters wouldn't be taking a detour for no reason, unless the object is sufficiently small that such a detour wouldn't be distinguished from the sometimes bizarre pathfinding that the game uses normally (there's a spot in my module where characters always opt to veer sharply to the left through an alleyway and come back onto the path at an angle rather than run straight ahead, and NPCs always prefer to walk through the middle of the fountain area instead of around it, even when their destination is in the opposite direction).

 

Line of sight bears testing. 

[Tchos]

It's for things that were not anticipated to be needed later, which are being repurposed in modules that people are already playing.  If I were preparing something ahead of time, I would simply do as I normally do and make it unusable until needed, which would make such a description unnecessary, as no one would be able to see it, and nor would it highlight.

 

As a more concrete example, though I haven't yet tested this with static door objects -- imagine you have a static door on an unused building, on a campaign you've released.  You want to make an update to the campaign, adding an interior to that building, so you add a script to the campaign to destroy the static door and replace it with an active door that leads to your new interior.  Now, when someone applies that update to their campaign, no matter how far they've already played it, the new area is available to them.

 

At least, that's my purpose.  Others might find any number of uses for this ability.

[kevL]

Tsongo,

walkmeshes make pathfinding more CPU efficient than having to calculate dynamic collisions in realtime

 

... sorta like Environmental Objects have more overhead than other placeables.

[PJ156]

Sorry off topic but I believe have just got your post title ... very good, if I have read your intention correctly.

 

"Life... is strength. That is not to be contested; it seems logical enough. You live; you affect your world."

 

PJ

[Tchos]

Yes, I was tempted to answer Dann's "Interesting," with: "Yes, interesting -- this function has much untapped power," and reply to Tsongo: "You just don't understand what I'm doing, do you?" solely for the purpose of throwing in more Irenicus quotes, but I'd worry those words would be taken seriously! 

[Tchos]

Irenicus (not to be confused with the theologian Irenaeus, author of Adversus Haereses) is the antagonist of Baldur's Gate 2 -- one of the best villains in fiction that I know of, and very quotable. 

 

I am not a lawyer or solicitor.

[rjshae]

... sorta like Environmental Objects have more overhead than other placeables.

 

...wait, what? How do they have more overhead?

[kevL]

less overhead, more overhead -- i get them confused.

 

the way I learned it is that 'overhead' is technically the free space above -- unused. When mixing on a soundboard, for example, you *want* overhead on a channelstrip.

 

 

that said, the way I first thought of putting it was indeedie 'less overhead' -- perhaps in economics it's different ?

[rjshae]

Okay, well I interpreted your statement in the computing sense. *shrug* Thanks.

[kevL]

ah, my mistake: i meant Headroom. more headroom

 

Environmental Objects have more headroom -- sounds odd but there it is.

[erin3372]

Whatever, I've never played it and I'm unlikely to ever do so.

The BGR team is working on BGR2 both are great games and the BGR team did a great job on Baldur's Gate. 

[rjshae]

Irenicus (not to be confused with the theologian Irenaeus, author of Adversus Haereses) is the antagonist of Baldur's Gate 2 -- one of the best villains in fiction that I know of, and very quotable. 

 

I think he was so effective because he was voiced by David Warner--it pays to have good voice acting talent.

[Tchos]

I've enjoyed many of David Warner's movie villain portrayals, as well.

[erin3372]

David Warner is brilliant and plays the part perfect! there's is something about hearing a voice you recognize in a game, audio book or drama, animated series or movie that just makes it special or pop. seth green - joker, liam neeson, ron perlman, Malcolm McDowell - fallout 3, Vincent price - multiple radio dramas, robin williams (RIP) - the Genie. to name a few. tim curry should do more voice acting.

[kamal_]

Figuring out how to break things in interesting ways is a good way to learn new stuff.