NorthWolf wrote...
I really hate jumping into these things because it's always a no-win, but it seems silly to pretend this isn't happening...
Honestly, guys? Neither side is painting a pretty picture of themselves because of the pointless and thinly veiled jabs going about. A complete discussion of this particular topic would've simply explained the nature of toolset-placed and script-placed statics and the differences. Though this is hardly the first discussion in here that could have avoided a lot of bickering, really.
While I admire your attempt to stay out of the fray, it also creates a false leveling. What is happening in this thread isn't two groups of people bickering, it's one person (though not the first, as you note) saying wildly inaccurate things, others correcting them, and that person attacking them for it. I won't even attempt to speculate at the why.
eeriegeek wrote...
Invisig0th wrote...
Your best performance for a placeable is always going to be when the placeable is placed in the toolset and flagged as static. The fact that the game engine only expends minimal effort dealing with these has severe drawbacks, however. You cannot create or destroy these placeables, or interact with them in any way. For all intents and purposes, they treated as part of the tileset during gameplay. They are indeed "static" in the strictest sense of the term.
However, static placeables that are created via a script from a blueprint are treated very differently by the NWN Game engine. For starters, you can create and destroy such placeables. If your need to manipulate the placeable via script is limited to these and a handful of other basic scenarios, and if you really can't achieve the desired effect using static placeable placed ahead of time in the toolset, then using this technique may be useful. And if someone is very serious about ratcheting down placeable lag as much as possible, like we are discussing here, the fact that spawned in static placeables involve less overhead than non-static, non-usable placeables can also make a big difference.
An example would be creating a tree placeable that can't be interacted with directly by PCs, but which will "burn" and be destroyed if a fireball goes off nearby. Static placeables placed in the toolset at design time definitely will not work, since you literally can't destroy them using a script. A non-static, non-usable placeable would certainly work, but that's an awful lot of extra overhead when all you are doing is applying a brief VFX and then destroying the placeable. With spawned-in static placeables, it's quite easy to do all this with minimal overhead.
Can you expand a little on how one goes about creating spawned-in static placeables from a script? I tried to create a placeable blueprint in the toolkit to test it out, and intially the static checkbox is greyed out. By checking and unchecking the usable flag I can select the static flag, but every time I save and re-open the template, the static box is unchecked again. My toolkit doesn't seem to want to create a static template. How did you go about implementing this? Any help appreciated.
You can spawn in static placeables quite easily, as well as make them. If the wizard doesn't like you doing it, you can simply pick a standard palette object to spawn in for testing, or make a copy of it, and change the appearance to the one desire, and the static flag will not revert. That, however, misses the point.
Without meaning to be rude, he really has no idea what he's talking about - heed him at your peril. To rattle off the mistakes I see off hand in the above-quoted material:
1) You can destroy statics, as kal already pointed out.
2) You CAN interact with statics in any number of ways other than destruction: looping through objects turns them up, you can make them speakstring (though it appears in combat log and not above them), you can even set and get variables on them. One of the few things you CAN'T do to them is apply VFX. Another is SetUseable (as per the function notes - they are correct).
3) The notion that using a non-static placeable spawn-in as opposed to a static one is an " awful lot of extra overhead" is laughable. So far as I know, spawned-in static placeables are like non-statics in every salient way. Heck, you can even SetUsable them, which you cannot do to true statics. The only reason I agreed with his recommendation that they be spawned in as static is an abundance of caution - in almost all cases, there's no reason NOT to spawn them in static, and there's a chance (far from a demonstrated certainty) that they cause less overhead (as opposed to pre-set statics, which DEFINITELY cause less overhead). The only time when it's pointless to do so is when you plan to interact with them further anyway. In any event, any such difference in overhead would be miniscule, if not completely negligible, as has already been said.
This is another one of those areas kal pointed out where goth contradicts himself - remember that the person claiming that spawning placeables in as non-static generates 'an awful lot of extra overhead' is the same person who began posting in this thread saying instead that 'there may be benefits to spawning them in nonstatic.' Unless he has some uncited source of new knowledge - doubtful, from the mistakes noted above - he's simply making this up out of whole cloth. Again, I won't speculate as to why, but I can say without any speculation that he's simply wrong.
Funky
Modifié par FunkySwerve, 27 décembre 2010 - 06:52 .
