Placeables and static flag

[Legacy_Shadooow]

               Why certain placeables are not supposed to be static? Is there some reason? Cos I tried to set them static and they worked same in all regards I could notice ingame...
               
               

               
            

[Legacy_Lightfoot8]

               Did you try and place a VFX on them?

Or try and destroy them to see if the GUI on the client updated with a PC in the area?
               
               

               
            

[Legacy_Shadooow]

               Well thats the normal static behavior right? Im asking if there is anything special that might forced the original creator to set these placeables nonstatic in 2da.

More specifically, I found out that almost all placeables from 1.69 are set not to be static by default in 2da and the static flag won't apper in toolset (unless you make some trick, but even then toolset won't display it - so not sure it even works). It was reported to me that tree placeables from 1.69 are lagging - and my tests confirmed it, when I set them to be static it was fine. Anyway Im guessing that maybe the DLA or who created them had some reason to set them nonstatic?
               
               

               

                     Modifié par ShaDoOoW, 25 mai 2012 - 01:57 .
                     
                  

            

[Legacy_Leurnid]

               I am pretty sure this is common knowledge, but, static items assigned VFX won't work, nor will they rotate or play sounds.  I have frustrated myself a few times trying to debug my scripts just to realize that I left something set to static.

I have assumed the static setting conserves resources during play by basically welding static items into the landscape when it complies the mod, ignoring it during play. I don't know the correct terms for these things obviously, but the theory seems sound.
               
               

               
            

[Legacy_The Amethyst Dragon]

               I know of at least one placeable that you don't ever want set as static, as it will cause some players' client to crash out (the mythallar crystal).  I think it has something to do with the emitters and animations or something.  Not sure.

As far as other placeables without the static option made available via placeables.2da, I'm thinking someone at BioWare just forgot to change the 0 to a 1 in most of those cases.
               
               

               

                     Modifié par The Amethyst Dragon, 25 mai 2012 - 11:18 .
                     
                  

            

[Legacy_Shadooow]

               Well all placeables from Patch 1.69 are set to nonstatic by default in placeables.2da.

These seems to be a unfinished (as almost everything from patch 1.69 ) rather than intented. However some placeables are animated (kelp) or has a animation when activated (blade barrier) and I wasn't sure if they are should be static or not and still aren't - can someone clear my concerns?. In toolset it seems that kelp does animate even static. Blade barrier not.

Also I found out that any placeable with Static = 0 in 2da is displayed wrong in toolset. In this case the toolset will show placeable as not static even if the blueprint is set to static (and I think it is static indeed in this case even when toolset shows that not). On the other hand if the Static = 1, then placeable static flag is displayed in toolset correctly. If the blueprint is missing the Static field, then the placeable uses the value from 2DA when placed.
               
               

               
            

[Legacy_OldTimeRadio]

               "I wasn't sure if they are should be static or not and still aren't - can someone clear my concerns?"

The question you pose is an interesting one and I've been thinking about it off and on since you posted it.  The situation could apply to much more than just the 1.69 placeables.  It would also be a relevant question to ask if someone had created 10, 20, 500, 1000 placeables and was trying to find out the "best" form to distribute them in. 

But the words like "should" and "best" are problematic.

For instance, there's a good argument to be made for setting everything static by default unless there's a compelling reason not to, such as the one Amethyst Dragon gave about the Mythallars.  Non-static/useable placeables consume a great deal more resources than do static placeables.  Instead of having blueprints with bring the placeable into the gameworld in a form which uses so many resources, why not have the blueprints set the placeable in it's least-resource-consuming form and let the builder decide if they want to make it useable/non-static and add that extra overhead to an area?  Same with placeables with activation animations.  Let the builder decide whether or not they're going to actually use that anim and intentionally set it to useable/non-static if they are.  I probably wouldn't set placeables to static if they had default animations on them which played automatically.

On the other hand, if you do it like that you risk less-experienced builders becoming confused about the utility of a placeable, not realizing how much has been "shut off" in its static state.  1.69 has been out for years now and it's probably too late to make a big change like that without plastering the information all over the place so builders knew what to expect.

"It was reported to me that tree placeables from 1.69 are lagging - and my tests confirmed it, when I set them to be static it was fine."
I'm sure it helped but models like the willow tree are simply not fit to be distributed to a mass audience in the shape they're in.  It's a perfect example of what happens when you forget you're modeling for a video game.  A model like that should at least be compiled.  I don't recall a lot of stuff in 1.69 being compiled, actually, which is a shame.  Hope I'm wrong about that.

"These seems to be a unfinished (as almost everything from patch 1.69 ) rather than intented."
Despite my criticisms above, I thought they did a pretty good job overall.

"In toolset it seems that kelp does animate even static. Blade barrier not."
The reason why the kelp animates when static is that it's not actually animated.  All the movement comes from danglymesh.  Danglymesh still animates when static.  That kelp is an awesome example of danglymesh, IMO.

"Also I found out that any placeable with Static = 0 in 2da is displayed wrong..."
Thank you!  Very useful!
               
               

               

                     Modifié par OldTimeRadio, 03 novembre 2012 - 05:07 .
                     
                  

            

[Legacy_Failed.Bard]

               What I found with placeables, was setting the usable flag, and then unsetting it allowed any placeable to be made static, even if it wasn't normally an option.
 Likely most figured out this little trick already, but I figured I'd add it to the thread anyways.
               
               

               
            

[Legacy_Shadooow]

               

OldTimeRadio wrote...

"These seems to be a unfinished (as almost everything from patch 1.69 ) rather than intented."
Despite my criticisms above, I thought they did a pretty good job overall.

It might sound really harsh from me, but I mean it. I can imagine how many work it took to make it, compete it, etc. (as its me now who continues to updte this game) yet still the ammount of issues is really enormous.

- too loud sounds (compared by vanilla sounds)
- white texture DDS/TGA issue
- weapon focus (trident) doesnt work
- (few) monsters missing certain animations
- placeables set not to be static by default
- almost all models not compiled
- missing heavy model for new armor heavy model for new armor is same as for normal pheno
- textures on new shields are messed up
- new dragon wings causing lags
- missing tilefade in the rural/castle tileset
- needlessly high poly models such as this willow tree - causing really bad performance in game
and maybe could also mention that the rural/castle is my least favorit tileset at all since takes ages to load area, but nvm, seems to be very popular there

and thats probably not all of them - I dont know if the betatesters failed to find this, or just wasnt time to correct this, but the final product quality is mediocre, give us this as final and last patch, well not nice:sick:
               
               

               

                     Modifié par ShaDoOoW, 03 novembre 2012 - 08:34 .
                     
                  

            

[Legacy_Pstemarie]

               With the exception of the Horse scripting, given that the 1.69 patch was largely the work of two Bioware employees who took it upon themselves to compile and release as much content as they could before all support was tanked, I'd just be thankful we got anything.

ShaDoOoW, you sometimes come across as if you think that Brian's and Craig's sole responsibility at Bioware was working on NWN - which couldn't be further from the truth. Both were heavily involved in the development of games at Bioware - Mass Effect series, Dragon Age, etc. NWN had been side-lined and according to Bioware's "official" stance, patch 1.68 was supposed to be the FINAL patch. There shouldn't have been a patch 1.69, and I applaud Brian's and Craig's efforts to get that stance changed.

Throughout the development of patch 1.69 the Community was enlisted to develop the Horse system and test it along with the other content. Inevitably some things were missed, but the final product, IMO, is far from mediocre. As to your bullet list...

- I agree about the sounds. Could have been better, but no sound engineer on 1.69 patch.
- Never seen the texture issue so can't comment.
- Its one weapon, but should have been fixed.
- The animations you reference probably aren't necessary, as most people haven't noticed or complained.
- Placeables not static by default? Not a big deal since most Builders make their own templates anyway or alter the default blueprints once placed.
- Compiling models is still debated by the Community. I for one oppose it since the game compiles on the fly anyway and have never noticed performance issues.
- New armor should have been fixed.
- Shield textures should have been fixed, but were never reported in development.
- Never noticed lag with the new dragon wings.
- Tilefade in Castle/Rural is OFF by design. Ask the guys from DLA that built the tileset. Furthermore, tileset loads fine - at least on my system.
- Compared to some of the older models - I'll take the "needlessly hi-poly models" anyday. As for that Willow Tree, doesn't cause an issue unless you are placing a ton of them around.

I know this will be probably get me in trouble with the Forum, but oh well...someone has to say it. Quit whining about how bad everything is and just enjoy what you've got and what you've made. All the ceaseless complaining does is drag other people down.
               
               

               
            

[Legacy_Shadooow]

               dont worry you are the hero here, and im the badass here

now to the list

Pstemarie wrote...
- Never seen the texture issue so can't comment.

im not expert for this but there are files on vault that fixes this, its something that textures from 1.69 doesnt have their DDS conterpart or something like that

- Its one weapon, but should have been fixed.

one and only weapon added in 1.69 actually, this is important to remember

- The animations you reference probably aren't necessary, as most people haven't noticed or complained.

still point, older vanilla monsters all have these

-
Placeables not static by default? Not a big deal since most Builders
make their own templates anyway or alter the default blueprints once
placed.

I dont know who is making copies of placeables from default palette? what would that be for? never heard of this technique.

- Compiling models is still debated by the Community. I for
one oppose it since the game compiles on the fly anyway and have never
noticed performance issues.

Well, older bioware models are all (or 99%) compiled. The game compiles them anyway you said, but if it does it there must be consequences. The on the fly compiling must take some time/resources afterall.

- Never noticed lag with the new dragon wings.

I havent made this up, this has been reported on PvP arena servers, also new helm is lagging, even more actually

-
Tilefade in Castle/Rural is OFF by design. Ask the guys from DLA that
built the tileset. Furthermore, tileset loads fine - at least on my
system.

well i think you know my opinion on tilefading, why turn it off by design when there is tile-fading option on client side, no vanilla bioware tileset has tilefading turned off by design
(now please i dont talking aout castle - i know the reason why castle/walls tiles doesnt fade, im talking about tree terrain)

not sure what you trying to prove, all my points are still points, and thank you that you brought the horse system, remind me other issues related to the horses and the scripting:

- horse menu causing custom monsters created after installing 1.69 to stuck when fighting
- something horse related is causing buginess of the polymorphs
- PC properties appears in loot


Im just trying to defend my point. Seems just saying that "Patch 1.69 is unfinished" is crime here. I dont forget all those good things comes from patch 1.69, but as I said already, ammount of issues raised by 1.69 is overwhelming.
               
               

               

                     Modifié par ShaDoOoW, 04 novembre 2012 - 01:53 .
                     
                  

            

[Baaleos]

               Some placeables outright crash the client - if set to static.
(mythrallar - or however you spell them)
If set to static, they crash any client who enters the area.

Just incase that was missed.