For every project I started so far I ran into the same problem:
The standard fog distance of 45 is also the maximum rendering distance for dynamic objects and personally I find everything below a fog distance of 65 unbeareable, especially when I take a lot of effort to create a good-looking nature or city scene.
Most blueprints are by default non-plot, non-usable but also non-static, so I try to make all the non-interacts like trees, plants, building adornments etc. static in the properties window - but it just doesn’t work on 90% of the vanilla stuff (CEP and PQ did better with their additions): Only after I check and uncheck again usable, the static box becomes checkable - but checking it doesn’t stick, clicking it again it has retained its default non-static status. It makes no difference if plot is checked or unchecked and I even tried to take a static placeable like a Boulder and change its appearance to a banner…resulting in the static boulder-disguised-as-banner suddenly becoming non-static and invisible beyond 45.
Now what baffles me most, is that some of the vanilla stuff has identical properties, but some appear to be static because they are visible beyond the rendering distance. For example the Flag, Bane, Hanging is visible at 65 while the Flag, Cyric, Hanging only becomes visible at 45.
I’ll be thankful for any helpful advice.
EDIT: I found nothing in my nwn.ini to raise the rendering distance but if there is something in the EE that can solve my problem, I’ll be willing to switch.
1 Like
You don’t use community patch, do you?
Is 65 meters the maximum rendering distance for static objects?
Afaik 45 meters is the maximum rendering distance for dynamic objects in vanilla 1.69 NWN. To my knowledge static objects have no rendering distance, the engine treats them like tiles in this regard.
More questions so far but no solution. If there is none I’ll find some workaround.
CPP should fix this, 1.69 placeables have their static settings fixed with CPP
however, since you started building without CPP and the area already contains vanilla blueprints I am not sure whether installing it will fix it automatically or you will need to replace the placeables
additionally, this is a 2da-based fix in placeables.2da and therefore if you also use CEP2 or Project Q (or your own custom haks with placeables.2da file modified), as both projects decided not to support CPP, then it will not work without merging the CPP 2das changes first.
Also, since it seems you are another one who doesn’t want to use CPP at all, I will just tell you how to fix it so you can have it without using CPP.
In placeable.2da set column Static to 1. Just be careful that few specific placeables are causing clients crashing when used in this way.
EDIT: clarification, the change in 2da only let you set placeable blueprints to static (it won’t reset after), CPP changes not just the 2da but also blueprints themselves so they are automatically static and you don’t need to set them static manually - which is probably the part which won’t work on pre-placed vanilla blueprints in area
2 Likes
Thanks @Shadooow that sounds like the simple fix I was hoping for.
Just to be sure, if I change the placeables.2da, I’d have to change it in the .hak I use on top, right?
I ask because I have 3 projects I am working on, one in no-hak 1.69, one in CEP and my main in ProjectQ. And assuming I take an area with “fixed” placeables from the no-hak module to a CEP or PQ module, I’d have to change the respective placeables.2da again and set everything to static manually, right?
EDIT: And regarding your CPP, I have nothing against it.
I checked out the vault page several times (who hasn’t?) and to be honest what I did read there gave me the impression that it’s mostly about fixing classes, skills, spells etc. which is just nothing I am interested in. It’s all about landscape and story for me, no matter if I play or tinker a module. Rules mechanics, balance or how the stuff translates from D&D never interested me.
Another approach is to use moneo to make non-plot placeables static, allowing exceptions as required.
Of course, some placeables need to be dynamic, so that they can be used, animated or appear / disappear. In these cases, the 40 (45?) m rendering limit is a pain.
I’ve asked for a fix in EE, but I’m not sure whether it was adopted.
Note that the 40m is measured from the centre of the model, which can be offset from the contents (appearance, nodes, walkmesh). If the placeable is against a wall or edge tile, offsetting the centre by 40m renders the placeable visible at 80m. However, this trick is no good if the placeable can be approached from the other side, as it will be invisible until the player is right next to it.
1 Like
Hoping everyone will take a moment to vote for this EE fix.
2 Likes
Did it yesterday. You can sign up to be notified as soon as changes are made to both trello boards. That’s how I knew about this already. There were 3 others added of which I also voted on one of those as well.
TR