Fomenting Mutiny

[Legacy_Shadooow]

               

3RavensMore wrote...

ShaDoOoW, I think I'm going to pass on being a beta tester for this. With my limited time at the moment, I'm trying to learn a few new skills while putting any new building and story writing on hold.  Sifting through thousands of placeables isn't really something I'm keen on doing right now.  

As for the use of what Zath is doing, I completely agree with Pstemarie on all points (especially the last line.)

uh

Zarathustra217 wrote...

I completely understand if you do
not feel you have the time. That said, what I'm suggesting people to do
is simply to install the updated haks and then keep doing what you
usually do, but report if you encounter any issues, strange behaviour or
loss of visual quality.

this

All you have to do 3RavensMore, is to download new haks that Zarathustra217 prepared and play with them for a while. Or if you dont play and just build then, revisit some of your older areas in toolset (is this change visible in toolset?) whether something changed. Or assign this job to one of your players/testers. Its client-side content so you will not screw up the module.

Plus and this is serious drawback you havent considered 3RavensMore, if this is going to be ever included in CEP, fact that you dont update doesnt matter. Anyone who does update will see things suddenly differently because newer CEP version will still allow them to play your module and because this is client-side content in the first place. A server doesnt even have this, what matter is what players have in their haks.
               
               

               

                     Modifié par ShaDoOoW, 19 février 2014 - 04:18 .
                     
                  

            

[Legacy_Shadooow]

               I was about to write it on the new CEP wiki, but its actually not bugged, just completely bad designed so I rather write here how others look at this issue before I suggest to do anything about it.

Heartbeat scripts in a CEP placeables. (zep_torchspawn, zep_doorspawn)

This is an issue from CEP1 that was inherited, and afaik almost every PW builders are removing this sooner or later as this is especially when builder uses these placeables a lot draining lot of resources.

Problem is that this looks to be intented and used in conjuction with the OnUse scripts.

Now to the details, one of those scripts is zep_doorspawn.

Ive checked this and this seems to be the only way to enforce the correct behavior of this placeable door concept itself. Wonder if someone actually found a usage for this but this can be hardly removed.

Second is the famous zep_torchspawn.

This is adding a light visual effect at day/night, not exactly clever from the code myself and ingame I have never noticed this. Maybe someone know more about this?

BTW, cannot be the lightning that the heartbeat script is adding added directly in the model itself somehow?

BTW2: if this will be eventually decided to be removed it won't change the functionality of the placeables placed inside older modules. Just fyi as this knowhow has big impact on the decision itself.



Indirect proposal: Remove the zep_use_chair script and replace it with the x2_plc_used_sit.
               
               

               

                     Modifié par ShaDoOoW, 19 février 2014 - 05:06 .
                     
                  

            

[Legacy_Zarathustra217]

               I must admit that I've always felt that the inclusion of most scripts into the CEP was a mistake.  The main incentive for using the CEP is that the merging of content is already done for you, and that your end users will have most of the custom content you want to use already in place (assuming they've installed the CEP). Scripts, however, can just as easily be acquired on the vault based on the module builders preferences and needs, and then be included inside the module itself without it needing to go into any external hak.

It's just more things to manage and maintain for the CEP.

But no matter how I and others feel about this, I fear that the overarching concern here has to be backward compatibility. We can cease implementing it further, but If we remove those scripts from the CEP or change their behaviour, we would break all the modules that currently use it.
               
               

               
            

[Legacy_The Amethyst Dragon]

               

Zarathustra217 wrote...

I must admit that I've always felt that the inclusion of most scripts into the CEP was a mistake.  The main incentive for using the CEP is that the merging of content is already done for you, and that your end users will have most of the custom content you want to use already in place (assuming they've installed the CEP). Scripts, however, can just as easily be acquired on the vault based on the module builders preferences and needs, and then be included inside the module itself without it needing to go into any external hak.

It's just more things to manage and maintain for the CEP.

But no matter how I and others feel about this, I fear that the overarching concern here has to be backward compatibility. We can cease implementing it further, but If we remove those scripts from the CEP or change their behaviour, we would break all the modules that currently use it.

My plan for scripts is to leave cep2_add_sb_v1.hak as a legacy hak for those that use it already while copying any CEP scripts into several script/blueprint .erf files for those that want to be able to import them and modify them for their own uses.
               
               

               
            

[Legacy_Michael DarkAngel]

               

Zarathustra217 wrote...

"Oversight" may have also been a poor choice of word from my part earlier, as I think most of it is probably the result of unawareness of what the full implications are, i.e. what the settings really do and mean. I imagine a lot of people who have modelled have tried to increase the default settings a bit because it seems really dark, but didn't know what settings were then the ideal. I also imagine though that it's not a coincidence that the exporter plugin now change those settings for you by default, but as far as I'm aware, that's a more recent addition (relatively recent, anyway), meaning many models exist from before that. That OldMansBeard made it an option in CM3 to set the ambient/diffuse settings of all models to 1 isn't just a coincidence either. It's a very common issue.

No, I think oversight is a good word.  Because, if the defaults, set by 3DSMax/gMax when creating a new material, are left as is, then your texture may not appear as you intended.  And you could be left scratching your head wondering why.  That is probably why the exporters (NWMax and NWMax Plus, not sure about MDL Suite or the BioWare exporter) give you the option to override those values.  But as I just said, that is an option.  Something the artist has to physically do in order to override the Material Editor settings.

Why the exporter's defaults are 1 / 1 / 1...  I can't say.  But that would lead me to believe that is the reason CM3 defaults to 1 / 1 / 1.  Not because it is the best, or the most aesthetically pleasing, but because it was the standard set forth by NWMax.


 MDA
               
               

               
            

[Legacy_Zarathustra217]

               Actually, after reflecting a bit on the 1 1 1 setting, I think the explanation is simply that it allows for both either exclusively diffuse lighting or exclusively ambient lighting to still be able to light a texture fully up. In that sense it is the most logical choice, since otherwise it would entail that even the brightest diffuse lighting (dynamic or area) wouldn't be able to make what's white on the texture appear white in game if the area had no additional ambient lighting (such as torch-lit only areas).

But... at a certain point, this otherwise very interesting topic should probably be moved to it's own thread if we want to continue delving into it further.

/Update

Last word from me on this topic, I swear! But did a small test and it turns out that area diffuse lighting and dynamic lighting actually stacks, allowing the combination to light up a (diffuse 0.5 0.5 0.5) model fully up (though only for a vertex in the exact same location as the light source). Mainly a curious detail though, the 1 1 1 setting is still preferable since otherwise dynamic lighting on it's own wouldn't be able to make white appear white (among other things)

Also, even an area diffuse setting of (255,255,255) alone only makes a white texture lit up to roughly 75%, where as ambient lighting with the same settings alone gives 95%. Again, just a curious detail. Perhaps they made it so to leave some more room for dynamic lighting to brighten things? (documentation here)
               
               

               

                     Modifié par Zarathustra217, 20 février 2014 - 11:23 .
                     
                  

            

[Legacy_Michael DarkAngel]

               And we are still talking about different things.

Perhaps as they say a picture is worth a thousand words.

If I were to create a simple placeable with a white texture, and then set the ambient and diffuse of the texture to the following:

ambient 1.0 0.0 0.0
diffuse 1.0 0.0 0.0

This is what I get:


You come along and apply your "fix":

ambient 1.0 1.0 1.0
diffuse 1.0 1.0 1.0

This is what happens:


As you can see from this very extreme case...

You have changed how I intended my placeable to look.

This should not be done unless the ambient and diffuse settings were not changed from the defaults 3DSMax/gMax sets when creating a new texture.

I hope these are my last words on this subject as well


 MDA
               
               

               

                     Modifié par Michael DarkAngel, 21 février 2014 - 03:51 .
                     
                  

            

[Legacy_Zarathustra217]

               Yeah, I've mainly been on the lookout for when it's used to set the hue of something. Even then, it's a poor way of doing that, but I'll elaborate on that in a separate topic, as I figure it's worth documenting all this in itself.

... back to the CEP, Amethyst Dragon, you mention you are planning some things - could I get you to bring it up on the wiki? Just so everyone is on the same page '>

Also, did you receive the last two emails I send?
               
               

               

                     Modifié par Zarathustra217, 21 février 2014 - 09:03 .
                     
                  

            

[Legacy_The Amethyst Dragon]

               

Zarathustra217 wrote...

... back to the CEP, Amethyst Dragon, you mention you are planning some things - could I get you to bring it up on the wiki? Just so everyone is on the same page '>

Also, did you receive the last two emails I send?

Just checked, and yup.  A couple of emails. '>  Sorry, hadn't checked the CEP email in a while.

I'll update the wiki soon.
               
               

               
            

[Legacy_NWN_baba yaga]

               The thing about ambient and diffuse setting is realy a tough question. For me, i always used 1 1 1 settings for everything i have done. But i can understand situations were it might be usefull to change them. The castle interior is another one, they used the settings to change the look for the floor tiles...
So there it is not wise to touch them;)
               
               

               
            

[Legacy_Shadooow]

               

But no matter how I and others feel about this, I fear that the overarching concern here has to be backward compatibility. We can cease implementing it further, but If we remove those scripts from the CEP or change their behaviour, we would break all the modules that currently use it.

Yes I understand. When I wrote remove the script, I meant from the template. It still must be in hak for this exact reason, thats correct.

 

 

 

One more thing, that always bothered me on CEP and this is what was already in CEP1 is messing my custom palette with blueprints. I can always remove them for myself, just thought Im not the only one in this. Since CEP2 added some new palette category couldnt be this moved there?

 

EDIT. Oh I should say Im talking about items. Creatures and placeables are fine, although the inclusion of the blueprints in hak itself is a bad idea its not that uncomfortable to make a copy.

               
               

               
            

[Legacy_Zarathustra217]

               

There's now a poll on the CEP wikia as to whether the CEP should include the ambient/diffuse updates (along with the other fixes):

 

http://nwncep.wikia....ontent_Overhaul

               
               

               
            

[Legacy_Pstemarie]

               

There's now a poll on the CEP wikia as to whether the CEP should include the ambient/diffuse updates (along with the other fixes):

 

http://nwncep.wikia....Content_Overhau

Your poll is bugged - a user can vote multiple times. I just did by mistake. So I put in a "No" vote to counter my extra "Yes" vote.

               
               

               
            

[Legacy_Zarathustra217]

               

Actually it's TAD's poll, not sure what settings you can set for polls. :S

               
               

               
            

[Legacy_The Amethyst Dragon]

               

I've added a couple new poll options for possible content additions.

 

Re: poll security: Not something I can really do much about.  It's just a basic function of the wikia service, and I'm not going to stress about it.

 

Also, since I'm trying to collect documentation into one place, I could use the help of someone (or more than one person) with some spare time and Excel.  If you've got both, can you download this Excel file, then transfer creature source information from this thread into the file?  Thanks!