Page 1 of 3
|
Page 1 of 3
|
Lights and LGHT files
7 Attachment(s)
>>> Modding InfoCenter <<<
LIGHTS AND "LGHT" FILES Some (uncomplete) working notes  Lights and LGHT filesDISCLAIMER: This is NOT a tutorial; it is intended to help average-experienced object creators performing specific tasks, or to give users a deeper in-sight on specific modding-related subjects. So, don't expect to find step-by-step explanations, to be performed "blindly". Please DO NOT REPOST the following info, or part of them, on other sites. -------------------------------------------------------------------------------------
SUMMARY This InfoCenter articles has the purpose to explain how the lights are managed by the game, and what is the meaning and function of the LGHT files. First off, let me state clearly that these notes are far from being complete; the LGHT file format hasn't been decoded completely, yet and some information are still missing or unknown. Every contribute is more than welcome! 
1 - INTRODUCTION In the game there are two types of lights: direct light, that hits the objects and the sims around the light source, and diffusion light, that is the ambient light and is reflected by walls and floors, and bleeds through windows. Every lamp in the game emits both types of light, and therefore people often don't realize that they are managed in a different way by the game. Infact, every object can emit direct light, but only lamps (i.e. objects that use the LampGlobals) can emit diffusion light.
The light is defined and created within the game by means of four different, connected elements: the Lighting.txt file (located in the gamedir), the LGHT file, the TextList 0x8E and the Resource Node.We'll see more in detail the purpose of each of them later on; let's start with an overwiew about the relations between the 4 elements. The Lighting.txt (or better, the custom .nlo file: see part 2) is where both the direct and the ambient lights are created and defined; the settings contained in it will override any other setting. If a light is not defined in the .nlo file, or the definition doesn't set all the needed parameters, the game falls back on the LGHT file contained in the package; but the LGHT file can only define a direct light, and therefore, a missing definition in the .nlo file always prevents the object from casting diffusion light. The Resource Node is where the object is associated with its light definition; in the CRES there is a cLightRefBlock that holds the reference to the light name, as defined into the .nlo file; the cLightRefNode is also used to translate and rotate the light. Lastly, there's the TextList 0x8E. I'm not sure what is its purpose: in my experiments, if an object has a working light, putting a wrong reference in STR# 0x8E doesn't prevent the light from working. Probably it's just another fall-back value, i.e. is used by the game when the primary references to the light can't be found. 2 - THE "LIGHTING.TXT" AND THE ".NLO" FILES As explained above, the Lighting.txt file defines all the lights, in both their "direct" and "diffuse" components. It is located in [GameDir]\EA Games\The Sims 2\Res\Lights. NOTE: there is a "lighting.txt" file for each EP gamedir: all of them are read when the game starts. The "lighting.txt" file can instruct the game to load other external text files. These external files, in turn, can load more files. This is done by specifying in the lighting.txt (or in the external file called by the lighting.txt) an "include" instruction, that can have one of these forms:
 NOTE - The game takes the "Lights" folder as root folder; the additional files specified in the various "include" commands can be located in a subfolder nested into the Lights forder, but not outside the Lights folder. (I've run a test with the downloads folder: unfortunately, the "include" commands can't find a file located there...). Please note that the paths defined in the "include" commands use the normal slash ("/") as separator, and not the backslash ("\").In order to create a custom light, we need to create a text file (conventionally, the additional light definitions have extension .nlo, "New Light Override"). In this file, we need to define our light, by assigning specific values to some attributes. The basic syntax is: lightAttribOverride customLightName_light Attribute Value. The "customLightName" is whatever we decide to call the light; to avoid confusions, I suggest to use the CRES name. The "Attribute" and the "Value" are contained in the following table, that contains all the attributes used in the game light definitions, and the values that Maxis used for them.
Code:
Parameter Name Min Max ------------------------------------------------ intensity n 0 12 color (R,G,B) 0 1 falloffRate n 0 5 coneAngle n 0 150 (degrees) conePenumbra n 0 55 (degrees) range n 1000 1000 diffusionSourceIntensity n 0 3.5 diffusionSourceColor (R,G,B) 0 1 diffusionSourceFalloff n 0.5 15 diffusionSourceMin (x, y) -0.5 0.2 diffusionSourceMax (x, y) 0 2 diffusionSourceFloorIntensityScale n 0.5 1 diffusionSourceWallIntensityScale n 0.9 1.5 diffusionSourceIsDirectional n 0 1 (boolean) diffusionSourceDirectionalFalloff n 0 1 (boolean) As you can see, some attributes define direct light and some others define the diffusion light. The purpose of some attributes is still unknown to me: here is explained what I could understand.
3 - THE "LGHT" FILE First off, let's clear up is that there are four different "LGHT" filetypes in the game: Ambient Light and Directional Light (mostly used in CAS screen), Spot Light (used for doors and windows), and Point Light (used for lamps and other objects that lit up). All the information provided in this article refer to the "Point Lights", though they probably apply to other LGHT types, too (untested). As explained in the Introduction, the LGHT file defines the direct light, but is used only if there isn't a correct definition into the Lighting.txt. The attributes set in the LGHT file are partly coincident with the LightAttributeOverrides that we have examined in the previous paragraph; as far as I could see, only some of the attributes related to the direct light are included in the LGHT file, not all. But again, there are some unknown values in the LGHT, too; so, I can't be sure if some attrivùbutes are really missing from the LGHT file... Opening the LGHT in SimPE we can find (and edit) the following values:
There are several name reference within the LGHT file; though some of them seem only explanatory (i.e. don't have to match the names in the Lighting.txt, or the CRES, or the STR# 0x8E), it's a good habit to follow a strict naming convention:
4 - THE TEXT LIST 0x8E This file holds the reference to the light name, as defined in the .nlo file (i.e. customLightName_light). As said, I'm not sure about the purpose of this TextList: if the reference is wrong, the light will work anyway... 5 - THE RESOURCE NODE In order for the LGHT file to be seen by the game, it must be linked to the Resource Node (CRES): a link to the LGHT file must be added to the CRES, "Reference" tab. Then, a cLightRefNode block must be added to the CRES hierarchy, and attached it to an existing branch (see example in paragraph 6). The name of the cLightRefNode has to be set in the "cObjectGraph" tab: it must match the light name defined in the .nlo file, i.e. customLightName_light. If multiple cLightRefNodes are added to the CRES, and all of them are related to the same light definition, then all of them must have the same name. Once the LGHT file is properly linked to the CRES, it may be used by the object. You might need to adjust the light position, by editing the translation values into the "cTransformNode" tab of the cLightRefNode block. 6 - AN EXAMPLE: ADDING A DIRECT LIGHT TO AN OBJECT - ***UNFINISHED!*** 1) First off, we need a LGHT (Point Light) file: you can extract it from any lamp, or directly from the Objects01.package, located in the GameDir. You can choose any LGHT file, as long as it is a "Point Light": we'll adjust its parameters to match our needs. 2) Import the LGHT file into your package and rename it; the structure of the LGHT filename is the following: CRESname_DiffusionLightName_light_lght. You just have to replace the first part (before the first underscore) with the CRES name of your object. Do this either in the main "Filename" field and in the "Name" field under the "cLightT" tab. Then FIX TGI and commit. 3) Open the CRES, "Reference" tab, and add a reference to the LGHT file: use the Package Selector Form as shown in picture to drag-and-drop the reference into the list. Take note of the position of the added reference in the list; in this example, the Lighting is in position #2 (the positions start from zero). 4) Add one "cObjectGraphNode (cLightRefNode)" block into the CRES ("Edit Blocks" tab). Take note of the number of the added block. 5) Include the newly added block in the CRES Hierarchy, by adding a "Child Node" into one of the existing branches (usually, main Shape, like in picture). Note: while adding the Child Node, the "Unknown 1" value is always "1", and the "Child Index" is the number of the added block, that you have written down in previous step 4. Optionally, adjust the translation (i.e. the relative position of the light compared to the Shape). COMMIT, then CLOSE and RE-OPEN the CRES (so to update the Hierarchy). 6) Select again the CRES Hierarchy and select the (now shown) new light block. Open the "Unknown2" block and set the values as shown in picture (I don't know the meaning of all these values, but they seems identical in all the cLightRefNodes...). In particular, the value [7] must be set to the position numeber of the LGHT file in the CRES Reference list (the one that you have noted down in step 3). 6b) (Added thanks to the info provided by Calidan) In the same tab, just above the "Unknown1" value, there is a "String[] Array" (the name may change according to the localized version of your .NET environment): open it by clicking on the little grey button with the three dots and write Practical in the text field. We are not sure why this is necessary, but probably the "Practical" value is needed to define the type of the block, and to instruct the game on how to manage it. 7) The object is now ready to work. We only need to adjust the parameters in the LGHT file: as explained, you have to set the RGB values for the light colour, the VAL1 for the intensity and the VAL7 for the Attenuation. NOTE - As explained, the object of this example will not cast any "diffusion" light, because we only have added a LGHT file (a "direct" light). In order for the object to cast a diffusion light, we have to import in the package a Text List 0x8E, extracted from a lamp that casts a light that we'd like for our object, too. But the Diffusion light will work only if your object uses the LampGlobals (i.e. it was cloned from a lamp); on the contrary, the Direct light works in every type of object.  7 - CREATORS GUIDELINE FOR A UNIFORM MODDING TECNIQUE :alarmWhen creating a custom object that is intended to emit light, first off you should consider the following: 1) Does the object really need a diffusion light? If you are creating a candle, or a small, "intimate" lamp table, you don't need a diffusion light at all, and therefore a suitable LGHT file contained into the package is more than enough to create the direct light alone. 2) Does your object need a custom diffusion light? The game already contains definitions for a lot of nice diffusion lights: high lights, low lights, coloured lights... You can re-use one of the already defined lights: just clone a lamp that has a light that you like, read the value from the Text List 0x8E and paste it in your package (use that reference also as name for the cLightRefNodes in the CRES!). 3) OK, your object really needs a custom diffusion light. In this case you need to do the following:
NOTE - Some older posts and threads, as well some older coloured light posted here on MTS2 used a different approach, that I strongly discourage: modifying the light definition of an existing (Maxis) light. I discourage it because this way you'll modify the behaviour of all the Maxis lamps that use that light definition. For example, if I create a red wall lamp, and modify the "lightingwallvalue_light", giving it a red tint, every Maxis cheap wall lamp in the game will emit a red light!-------------------------------------------------------------------------------------
OTHER USEFUL RESOURCES Modding Infocenter Index - Comprehensive list of all the InfoCenter threads Object Creation Workshop and Repair Center - If your object doesn't work, no matter what you try The CRES File - To better understand the structure of the Resource Node. ------------------------------------------------------------------------------------- |
Is this guy a genius or what!?! :D
Thank you Numenor! And all along I thought you were putting the potion code in your files!! lol Thanks for sharing with us.. xts |
Problem with Light(LGHT) not turning on
Well, I followed the basic tutorial of Numenors' Modding InfoCenter - Lights and LGHT files but my object still does not want to light up. The object was not cloned from a light initially, but from reading that thread (and others) it seems that this is only 'really' required if I want diffusion light, and in this case I just want it to generate A light (so spot works for my needs).
My object now loads into the game without crashing or generating object errors, sceneograph shows it all there and available, just no light. Do I have to mess with BHAV's to turn it on (tried but that generates errors because I'm most likely doing it wrong anyway), or should it be ON by default? Will I have to import the light semi globals to make it work? Any pointers or suggestions at this stage would be welcome as it's been annoying me for the last couple of days I've even recloned the original item and started from scratch twice still to no avail. Oh. Its a cloned sculpture item that I want to generate a perm. low level light. Thanks for any help/suggestions etc in advance - and while I would prefer to not upload the package (simply because I'm not ready to let others see it as it's something I have not yet seen done, and am protective of 'what' it does) I will IF its the only way to get some closure to this annoying light problem. (is it possible to just upload/email it to someone privately? if needed?) And Numenor, the last image in the tutorial is linked to the wrong attachment just thought I'd mention it.-- Calidan |
Calidan, first off, thanks for the heads up about the wrong image.
So, your objects was not cloned from a lamp... It shouldn't be a problem, but I need to double check my notes and my experimental packages. I will let you know. If I need to look at your packages, I'll give you directions for a "private" delivery |
1 Attachment(s)
Quote: Originally posted by Numenor
The help is much appreciated - thanks Also just another clarification. LGHT(LightRef) is associated with ShapeRef, and as such the textures used on an object should have no affect on lights? ie. The game engine would not have a problem with objects with animated textures? If is does, would I be better using 2 Shape entries and only associating Lights with the non-animated one? (The above questions are irrelevant, but left in as were part of the initial post) EDIT: **UPDATE** Problem Solved It seems I was overlooking 1 (apparently) important setting.. Before the light can actually be emitted by the ShapeRef it is linked to, you must let the game know WHAT that ShapeRef is. Now in Numenors' tutorial at the beginning of this thread, he points out that you must set the Unknown2 Value [7] to the position number of the LGHT Ref. From my testing and experimentation it seems you must ALSO add a reference to the ShapeRef (the one set as 'Practical') into the Strings Array. You do not reference the Shape by its name, but rather simply a pointer to the 'Practical' ShapeRef.  Simply adding this Array item has now allowed my item to emit light (and yes lights are on by default) which I am SO pleased about. Hope this helps and perhaps this could also be mentioned in the tutorial/outline you started the thread with Numenor.-- Calidan |
Thanks Calidan, this is an important clarification!
In my test packages (and actually in all the Maxis LGHT that I've examined), the first element of that String Array is always set to "Practical"; sometimes, a second string, set to "Sims", is added to the array. To tell the truth, I don't know what "Practical" means. I only know that the cLightRefNode has the same structure than the cShapeRefNode, which is labeled as "Practical", too. BTW: what about that "Unknown1" set to zero that I see in the screenshot? In all the LGHT files that I've seen it is always set to 1... |
Quote: Originally posted by Numenor
Yes I have noticed that also and initially thought that both were needed. But when I tested this I found that the light would generate illumination regardless of Unknown1 being Zero or One, so at this stage I have not determined what this setting actually relates to. In this case as I was adding a LightRef to a non-light item, Unknown1 and 2 were all set to Zero by default and as such I left it Zero when I added the string 'Practical' to test. If someone else could shed some LGHT (heh) on what this Unknown1 refers to, and if leaving it Zero will cause any 'instability' in a light object please. (Don't want buggy objects now do we) -- Calidan |
After reading your thread about LGHTs I have yet another question: as the cSpotLight refers to a system file not to a file in the package did I understand u correctly in believing I can replace the 'windowcolonialtallarch' or the 'windowtwotilewideloft' with any of those listed in the blocks starting with 'create' in the windows.txt?
using the windowArtNouveauRound for a round window is very tempting... if I did get u right there does not seem to be any case sensitivity - cSpotLight vs text file... would I need to do anything about the settings in cSpotLight as well ? and how can I figure what the diff between the files listed is? |
Chrissy, as far as I coud see, the label that you can read in the "Name" field (into the LGHT file, "cSpotLight" tab) is only descriptive.
The values in the other 9 fields (Val1 to Val9, including the RGB ones) are the actual values that define the light. Mind that, unlike you might think, doors and windows don't cast any "diffusion" light: they only cast "direct" light, which is defined inside the package, in the LGHT files. If you have created a small, rounded window by cloning a large rectangular one, then probably the LGHT files in your package define too a strong light for such a small window; *and* the position of the source of the light (which is defined in the CRES) is probably out-of-center, compared to the new window. In order to fix these problems (that should be barely visible, anyway), you should:
As for editing the translation of the cLightRefNodes into the CRES, I think that you know how to do it, right? Bottom line: remember that all these info are mostly untested; if the directions given above are inaccurate, let me know and we'll discuss them more deeply. |
Calidan, I've added the info you provided in the article. But I have another explanation (well, sort-of) for that "Practical": it is not a reference to the cShape; simply, both the cShape and the cLight are "Practical" blocks, whatever it may mean.
There are a lot of similarities between the cShape and the cLight (for instance, both refer to the "reference list" set in the CRES, which is a thing that no other block do, except for the cViewer); so, this parameter may simply define the "type" of block. |
Quote: Originally posted by Numenor
You could be right on the mark there. Trust Maxis to 'reuse' a definition But that then poses the question, how does the 'Sim' entry found in some strings arrays relate to a light and since the LightRef seems to be the only block (well not that I've looked too deep) that uses arrays in this form, is it refering to how the light is emitted, or where the light is emitted from. It was this latter thought that made me add it, since the ShapeRef is also considered 'practical' (which I guessed meant the 'actual or usable' shape ingame)Ah well lots of guesswork at this stage, little 'information' Re: The LGHT article. I'm glad my little contribution could be of help. Thanks -- Calidan |
Yes, I wondered about the meaning of the "Sims" entry. I want to look into the "SimsXX.package" to see if the cShapes are qualified as "Sims" there... You know, I'm only expert with objects and the "ObjectsXX.package".
Moreover, I'm not expert in hex editing, so I can't confirm this; but the fact that SimPE represents in a different way the cShape and the cLight doen't mean that the blocks have a different structure. Beside the graphical representation, I find the two blocks very similar, i.e. they contain the same data, more or less. But I agree that there is a lot of guessing work yet to do on this subject |
I have just been playing around with this all day. At least I know what I over looked and where. Alright, I made an object, and it will light up, but not cast any defused light on the wall. I created the nlo file, typed it in the lighting.txt file, but still no defused light. I know I'm doing something wrong somewhere, could you possible break down the nlo and lighting.txt file a little more? Oh, it was cloned off a light. I used the neon strips from NL.
|
My guess is that your custom .nlo file isn't read by the game, because it is "included" in the main lighting.txt.
The lighting.txt file, as said, can instruct the game to load other external text files. These external files, in turn, can load more files. This is done by specifying in the lighting.txt (or in the external file called by the lighting.txt) an "include" instruction, that can have one of these forms:
NOTE - The game takes the "Lights" folder as root folder; the additional files specified in the various "include" commands can be located in a subfolder nested into the Lights forder, but not outside the Lights folder. (I've run a test with the downloads folder: unfortunately, the "include" commands can't find a file located there...). NOTE - The values specified in the text files (the lighting.txt and all the one "included" in it) will override the settings in the LGHT files contained in the packages. SUGGESTION to creators and modders - The "Lighting.txt" file is too an important game file to fiddle with it. In the effort of providing a uniform behaviour to all modders, I suggest to do the following:1) Create a backup copy of the lighting.txt file, located in the base-game dir ([gamedir]\EA Games\The Sims 2\TSData\Res\Lights). 2) Append to the Lighting.txt the following line: wildInclude CustomLights/*.nlo. 3) Create a folder named "CustomLights" nested into the folder [gamedir]\EA Games\The Sims 2\TSData\Res\Lights. 4) Put your custom light definition (that must be a text file with .nlo extension) into the CustomLights folder. The steps 1 to 3 are to be performed only once, and it will enable the custom lights. This way, the game will read and create, when starting, all the custom lights defined into the CustomLights folder. When uploading an object with custom lights, we can then ask the users to put the object in the the Downloads, the .nlo file in the CustomLights and (if they didn't already done it) append that single line to the lighting.txt. I'm still experimenting: more info will be added later on |
Hmmm, I followed the steps to the tea, but the ambient light is still not showing. I was wondering if it had something to do with the editted mesh, so I made a test and didn't change the mesh for the plutonium rods in NL. Changed everything so it wouldn't over-right anything and added the light. I made all the needed changes to the lighting text file, custom nlo file, and it still wouldn't show. I'm gonna try again today because I'd really like to make some custom neon signs, but need to get the ambient light working.
|
Either the nlo file wasn't written correctly, or there is something wron in the internal references of the package.
My experiments show that in the CRES, the cLightRefNod must have a name that match the one of the light defined in the nlo (e.g. if the light name is "MyCustomLight_light", all the cLightRefNode(s) must have, in the cObjectGraphNode, "MyCustomLight_light"). I'm still testing, but if you want to be sure, put the same name ("MyCustomLight_light") in the STR# 0x8E, without adding any prefix: no ##0x1c050000! here; and lastly put "MyCustomLight_light" in the LGHT file ("cPointLight" tab"). Also, the LGHT name should be: cresName_MyCustomLight_light_lght. |
I'm sorry, I'm not the right person to ask about Milkshape: I'm more "amateur" then you at meshing
|
Well, I worked on it, and worked on it some more. Deteled the clone and made a new one, and it's just not getting any ambient light. I followed everything to the letter and still nothing. The item was cloned from the plutonium rods from NL and already has it's own ambient light, but even with nothing changed (text list, lighting.txt, etc) it still won't show with the ambient light.
|
I've been reworking this article for the whole day (it's 3:30 AM, here, and I'm still working...
).Since you are so interested, I'm going to post the new, unfinished version: it is complete with regards to the info provided, but the Example / tutorial is still to be reworked, so don't rely on that. Concentrate on the names: dont's confuse the light name (customLightName_light) with the LGHT filename (cresName_customLightName_light_lght). Pay attention to the crossed references, as explained in the article. |
I guess I am doing something completely wrong somewhere. Lets say you clone a light, wouldn't the clone have ambient light if you didn't change anything? Because even if I just clone a light, it's still not pulling any of the ambient light at all. It will turn on and off and give off the direct light, but no ambient.
|
A cloned lamp should cast diffusion light... I've cloned hundreds of lamps and they all do...
Perhaps you changed something in the TextList 0x8E or in the CRES (the names od the cLight blocks)? |
What the hell is "TEXT LIST 0x8E" in English? Using Hex for descriptors is annoying...
|
1 Attachment(s)
SimPE uses hex to represent the Text List numbers...
The "Text List 0x8E" is the Text List with instance number 0x00008E I could use the textual name (in this case, "Light Names"), but that name is purely decorative, and is often different from object to object, while the instance number (0x8E) is always the same. |
I'm sorry- I was getting frustrated after an evening spent trying to find meaningful information in conversations carried on almost entiredly in hex..it's like showing off by old time programmers who talk about what they had for lunch in OpCodes. SimPE and learning to modify would be a lot less of pain if it substituted function and variable names for fixed known hex identifiers in the first place..it'd certainly be easier to follow what is going on or at the very least there was a published list of codes and their meanings (if there is I haven't seen it) - the words 'user friendly' come to mind
|
Quote: Originally posted by darylmarkloc
|
| All times are GMT +1. The time now is 7:32 PM. |
Page 1 of 3
|
Powered by: vBulletin Version 3.0.14 · Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
This tutorial is also provided in PDF format. To view it, we strongly suggest to download the