[Chrisadams3997]

Yep, the problem is c.p. used a very different approach than the one I adopted in the rendering script itself.  While it worked fully at the time, it was very dependant on the material type and thus only supported the few that where part of Max when the original Bat4Max was written.  The number of material types since then has increased dramatically and using the same method isn't practical.  Given the changes, I half figured it would prevent night windows working in older versions as well, you've just finally confirmed that .  However the improvement in how nightlighting is dealt with, as well as greater capabilities of night libraries anyway overshadows that I think.

For now in that case, I'd just change the option in the Bat4Max ini file for night windows which will remove the ui for it.

Chris

[SimFox]

Chris! nice to see you back!

But about Jeronij problem you're, unfortunately wrong. Actual culprit is your script... In GMAX BAT, as well as in BAT4Max 2 it was possible to add nitelite prefix not only to lights but to the geometry as well. And it would be recognized as such by the script and nightwindows textures would be applied to it. Well technically it is a bit different, Texture isn't applied but underlaid and cut-outs are made, but anyway it worked.
It doesn't work anymore because you do collect wrong objects, or you collect objects on the wrong basis.
You do it on the basis of name, while you should have done so on the basis of object type eg collect only lights and then in selection made check for lights with specific property - namely prefix nitlite.

You're right though that it is easy to fix. All it takes is to take one word in a script... And since you're back now i hope you'll do it.
I would also like to exchange some ideas with you about reintegration into one development and compatibility with MR3.6+
I'm quite busy at the moment, but would have more time in about 10 days...
Hope you'll be around and not disappear again!

[Chrisadams3997]

Ah, that's something I didn't know.  But even if you did allow geometry, the night window textures still wouldn't work, so it might be a moot point.  It's my personal opinion to move forward from night windows and, if anything were to be done on that front, increase the ease of using night libraries.  But given they work fine now, that's awfully low priority.

I'm actually curious what the fix you've mentioned is, but this isn't a development thread, we'll need to open a new one or continue an existing one(let's keep it on SC4D, I hate trying to post on Simtrop).  I won't be developing script wholesale like before by any means, but given a good discussion, I'd certainly contribute to scripting and integrating scripts in free time.  I've also glanced over the thread on your release, some promising ideas.  Just send me a PM when you're ready.

Chris

[callagrafx]

I'm actually curious what the fix you've mentioned is, but this isn't a development thread, we'll need to open a new one or continue an existing one(let's keep it on SC4D, I hate trying to post on Simtrop). 

Actually here's probably the best place, as it'd be a fix to a reported problem, which is the purpose of this thread.   Welcome back Chris, we missed you over at the Nuthouse.

[Chrisadams3997]

lol, I'll be around there as well Lee, I'm sure.  On the point mentioned you're right I suppose, I was more thinking about this line when making that comment:

I would also like to exchange some ideas with you about reintegration into one development and compatibility with MR3.6+]

Even with a proposed fix to allow the nitelite prefix for geometry though, I'm doubtful it will work in rendering for the reasons I mentioned before.

[callagrafx]

I can't see why anyone would need to use geometry with a nitelite prefix to be honest and I agree it more than likely wouldn't work, I was more thinking about the quick fix to Jeroni's problem that Simfox alluded to but for some reason wouldn't publish...

[Chrisadams3997]

careful Lee, I know how you two are, no instigation...
from either side

[Diggis]

Welcome back Chris.

[jacqulina]

welcome back chris

[SimFox]

Callagrafx:
I didn't say anything because the only thing that I could have said quickly and definitively at the time would have been - don't use this version of Bat4max!  It's author is missing, I myself see a lot of, what I perceive as, inconsistencies and excessive coding in script because of which it is a very difficult to find a way around, and the people who release it have no experience, knowledge needed to provide any kind of meaningful support for such a tool. Because support for such a tool is not telling people what button to press, but ability to fix some errors in code that may and will resurface.

Even if I would have been able to fix one function, and I really mean fix this function not simply replace it with mine, it would have taken me a lot of time and sort of made liable to continue provide support, e.g. basically doing your "job". Problem is that I'm not familiar with internal logic of the whole thing... It's just not time efficient. And giving simple indication of where in the script the problem in question starts wouldn't do you any good, now would it? So there was this dilemma...

Now since the Chris is back situation is radically different. I know I don't need to go and simply redo the thing. It would be sufficient to simply point to the spot...

And so I'll proceed to the task at hand:

Chris I believe that the root of the problem is your collection method. You choose to collect by the name (e.g. $nitelite*) and opened yourself for all sort of possible mistakes, or need for excessive checks, which you, in fact tried to make, but still missed some, which in turn resulted in a mistake Jeronij had encountered.

This issue, I believe would be eliminated if you would, well actually do nothing to the previously available function, or if there is still a need for a new one (although I don't see what would that be) followed the logic of previous ones and collected not names, but types (e.g. $lights). This way you wouldn't have a problem of geometry named nitlite* be in your array. and the existing check for prefix would weed out other lights (say those in light rig if that is present in the scene) and targets.

This is, of course a bit of poking in the dark, as I don't quite understand the logic there (what, for instance that array - gNiteLiteon - is collecting things for?) and Myself don't have Max 7 to run the changes through...

But I've presented my logic so you can consider it...

As to the farther development, yep I think we could and should revive the old thread it would provide a continuity in the process.

edit: fixed a meaning altering typo: "wouldn't" to "would"

[Chrisadams3997]

placeholder post, when I get back this afternoon I'll look over your suggestions as well as explain the changes I've made to the function in question.  It's old design had caused me some problems that led to those changes, but I'll get into it then.

OK, the main reason I changed this function is that it ignores whether a nitelite has been manually turned off in a scene, which may be useful when modelling and previewing the night scene.  With the original implementation, if you wanted to see the scene without a certain placed nitelite, you have to delete it(or manually change the light to not be renderable if I recall correctly).  Having the Bat4Max render and preview reflect the actual state of the scene in this regard is just, in my opinion, better design and more intuitive and helpful to a modeler.  The primary element here is an array varaible, gNiteLiteOn used to save a list of just the nitelites that were turned on before this function turns them off for a night render.

As Simfox noted, by using $nitelite* to collect the array, I'd assumed the user would only name lights with that prefix, if anything else was given it, you'd get Jeroni's error.  Keeping the same principle I just talked about, I've written an alternate implementation using the method Simfox mentioned, and borrowing a bit from his V2.1 release code:

Code: [Select]

fn FnEnableNightLigts shine =
(
if ($lights.count > 0) do -- scene has local lights
(
if not shine then --turning nitelites off
(
--array to save nitelites that are on only, to be turned back on later
gNiteLiteOn = #()
--only "nitelites", remove spot targets, and only those presently turned on
for lt in $lights where (substring lt.name 1 8) == "nitelite" and lt.classID[1] != 4128 and lt.on == true do
(
--save them to array
append gNiteLiteon lt
--turn off the nitelites
lt.on = false
)
)
else --turning back on
(
--remove any lights from array potentially removed after nitelites where turned off
for lt in gNiteLiteon where (isdeleted lt or lt == undefined) do deleteitem gNiteLiteon lt
--turn on the nitelites that were on before
for lt in gNiteLiteon where lt.classID[1] != 4128 do lt.on = true
)
)
)

I've also changed the error handling of lights potentially deleted that exist in the array(a rare but potential scenario). Preliminary tests have had no errors, including with geometry named with the nitelite prefix.

[callagrafx]

Callagrafx:
I didn't say anything because the only thing that I could have said quickly and definitively at the time would have been - don't use this version of Bat4max!  It's author is missing, I myself see a lot of, what I perceive as, inconsistencies and excessive coding in script because of which it is a very difficult to find a way around, and the people who release it have no experience, knowledge needed to provide any kind of meaningful support for such a tool. Because support for such a tool is not telling people what button to press, but ability to fix some errors in code that may and will resurface.

Even if I wouldn't have been able to fix one function, and I really mean fix this function not simply replace it with mine, it would have taken me a lot of time and sort of made liable to continue provide support, e.g. basically doing your "job". Problem is that I'm not familiar with internal logic of the whole thing... It's just not time efficient. And giving simple indication of where in the script the problem in question starts wouldn't do you any good, now would it? So there was this dilemma...

Now since the Chris is back situation is radically different. I know I don't need to go and simply redo the thing. It would be sufficient to simply point to the spot...

And so I'll proceed to the task at hand:

You said:

You're right though that it is easy to fix. All it takes is to take one word in a script... And since you're back now i hope you'll do it.

So what was wrong with posting that "one word" so Jeroni could fix it?  He certainly has the ability to do so, as do many of us.  So tell me, how would that take a lot of time?  My "job" was to provide support on the use of this script in Chris's absence...

Callagrafx:
I didn't say anything because the only thing that I could have said quickly and definitively at the time would have been - don't use this version of Bat4max!

And why say that?  It's a very very very simple thing to use other methods of lighting that work 100% with this script...methods that have been tested and used in actual releases.

[jeronij]

Cal, I please you to keep focused in the technical side of the discussion. If you want to discuss off topic matters, please use the PM system.

I cant hardly see any positive contribution to the discussion in you last reply. SF explained reasonably already why he didnt say that word, and alternatives to circumvent the issue are fine, but they dont solve the issue itself 

So, please again, keep the discussion focused in solving issues, and not in asking why's and how's.

[SimFox]

Callagrafx:
I've posted it, btw
but as I have explained it is dependent on my interpretation of the particular function. I'm sort of sure about it, but since I have no Max7 no Chris's Bat4max installed I can't be 100% sure. But yes it could and probably is as easy as changing 1 word. Understanding which one isn't, though. And in order not to make bigger problems than existing one it is essential to understand. It is sort of fool-proofing thing.
Anyway, since Chris is here I believe he'll sort this thing out now and I'll be helping as I could.

[Kenworth]

I have a question: Is Bat4Max V3.0 compatible with 3ds Max 2009? Because, i have this problem:

[callagrafx]

In a word... no.  When Max 2009 was introduced, it came with a much improved Mental Ray engine, however these scripts are designed to work with older versions of Max that use MR 2.6  Chris hasn't been around to update the scripts to the latest version, so your only alternative is to use the scripts updated by Simfox. 

They can be found here --> http://www.simtropolis.com/stex/details.cfm?id=23088

Also, make sure you read this thread --> http://www.simtropolis.com/forum/messageview.cfm?catid=37&threadid=112233&enterthread=y