...
- They default to Plot (invincible). Use SetPlot(FALSE) if using DestroyObject() on them. This renders it immune to spell AOE damage.
- Cannot play animations (eg; turning a flame on/off) since this requires it to be non-static
- However can be have permanent animations such as danglymesh on the model itself
- Cannot be created, sort of:
- In NWNX you can create static placeables but it will only appear if a player re-enters the area for it to be "baked in" and graphically load.
- Outside of NWNX CreateObject() will run a UTP file and strip the static flag off. This means it defaults to a non-usable placeable as per below properties. This means you don't necessarily have to have multiple blueprints for static versus non-static versions in a SP module.
- Can be destroyed (use DestroyObject() if the plot flag is removed) however it will not be removed from the geometry until the player re-enters an area. Outside of NWNX this is not recommended unless you want to make permanent level changes.
- They do not load LOD files and are always at maximum quality
- They cannot be visually scaled or transformed (although their location can be set to any arbitary one). To scale use a tool like CleanModelsEE to scale the MDL file and create a new placeables.2da line for it.
Choosing between using Dynamic vs Statics
While dynamics allow for more flexibility with visual transforms, etc., there's three things to consider in which static and non-static differ with regards to performance:
- On the client, the rendering of the static placeable is slightly more performant in some cases, because it gets baked into the giant mesh. This is a lot more noticeable when you have a lot of the same static placeables, so they can be combined into a single draw call.
- On the network (both client and server), static placeables have minimal overhead once during area load. Non-static ones have an overhead every time they enter or exit the view. This is where the visible distance comes into play. If something has the visibility distance set to 1000m, then it's effectively the same as a static placeable in this regard because it never leaves the view.
- On the server, non-static placeables are regularly checked for 'did anything change and should we send an update to clients?'. This is very CPU intensive. The very first thing that is checked is 'Is this placeable within visible distance of that client?' - if the answer is 'no' then no further checks are done.
Considerations: (1) is barely noticeable in general case. (2) happens virtually never for the individual thing. Even if you constantly move in/out of view, that's at most once per second, which is nothing. It also doesn't really matter what the actual visible distance is, you can have the same happen at 45m or 90m or 5m (3) can be massive when you have a lot of objects and lot of clients in the area. This can easily add up to 50% of all the CPU time ever done by a PW server. This is why the development team didn't recommend raising the visibility in general. If you raise it across the board from 45m to 60m, you've basically doubled (r*r*pi) the number of objects that a client sees and that need the complex checks now.
Another way to look at all this is to imagine two identical 8x8 areas with 1000 placeables stacked in there and the player at the center. In one case, placeables are static, in the other they're not. If playing in multiplayer, the client will probably not notice any difference in fps whatsoever.
If playing in singleplayer, the non-static version will have half the fps of the static one.
Moving Placeables
You can either clone the placeable (CopyObject) or use the effect EffectDisappearAppear on them. This won't change the facing but SetFacing works on placeables.
...
View file name fx_placeable01.mdl height 250
See also: placeables.2da ("https://nwn.wiki/display/NWN1/placeables.2da?preview=/38175210/38175586/fxpa_flare%20usage.txt")
Placeables and the Toolset
...