Aller au contenu

Photo

Controlling placed effects


  • Veuillez vous connecter pour répondre
19 réponses à ce sujet

#1
El Condoro

El Condoro
  • Members
  • 148 messages
I want to be able to activate a torch at night and deactivate it during the day. I can do this for the light object but am confused about what to do with the placed effect (fx_torchglow). There does not seem to be any variables or scripts to set on the object.

Can anyone tell me what function to use or script, please?

Cheers

#2
Shallina

Shallina
  • Members
  • 1 011 messages
you need to destroy it and recreate it with script at the hours you want. For lights it's a little more difficult beceause they loose their tag when you save a game. Wich mean you must store them as local object in order to be able to access them.

For the sound you can't delete them with script. Wich mean you need to set the time when you want them to be on in the sound object.

Modifié par Shallina, 23 janvier 2011 - 12:04 .


#3
kamal_

kamal_
  • Members
  • 5 240 messages
Use the SLS light system, which includes this functionality.

#4
Lugaid of the Red Stripes

Lugaid of the Red Stripes
  • Members
  • 955 messages
For the placed effect, yeah, you'll have to destroy and respawn it. Though I think the torch glow is so faint that it isn't really visible during the day, so I would just leave it.



For sounds, you can't create or destroy sounds via script, but you can start and stop their playing, and you can change their volume (SoundObjectPlay, SoundObjectStop, etc.). Or you can set the hours in their properties tab (play only at day/night I don't think works).

#5
El Condoro

El Condoro
  • Members
  • 148 messages
Yeah lights are fine (SetLightActive()); sounds are fine (Use Hours and set the hours), but the placed effects are the problem. The torch light goes out with what I've done but the flame keeps burning! I'll check out the SLS.

Modifié par El Condoro, 23 janvier 2011 - 09:21 .


#6
Dann-J

Dann-J
  • Members
  • 3 161 messages
You'll want to read this thread about how temperamental lights can be:



http://social.biowar...4/index/5261700



The effects are the least of your problems...

#7
El Condoro

El Condoro
  • Members
  • 148 messages
Yep, tested all beautifully until I loaded from a saved game and all the lights went haywire!



In the forum link there is a reference to making the light object a local object. What does that mean and how is it done?

#8
Shallina

Shallina
  • Members
  • 1 011 messages
object storeObject = (what ever Object you can access, the area is a good choice);
object lightObject = (the light object you want to store);

SetLocalObject(storeObject,lightObject,"mylight");
lightObject = GetLocalObject(storeObject,"mylight");

As I said earlier, light Object loose their tag when you reload from a save game (it's a bug), wich mean you need an other way to access them than the their tag.

Modifié par Shallina, 24 janvier 2011 - 07:46 .


#9
El Condoro

El Condoro
  • Members
  • 148 messages
Great, thanks for the help. After much testing and mucking around (as an inexperienced scripter)...

This approach has worked for me using the SLS2 scripted lighting system.

First, an OnClientEnter script runs at the beginning of the module to set ALL light objects in all areas to be Local Objects with the string value of their original tag. This is useful as the SLS script calls string lightTag, which is this original tag.

Then, line 363 of the ginc_sls2 script needs to be changed to refer to oLight correctly.

Area OnClientEnter event script:

 // Set all light objects to be Local Objects contained by their area.
 // This is required because all light objects in all areas of the module will LOSE THEIR TAG
 // when a saved game is loaded.
 
 int iLightsSet = GetGlobalInt("lights_set");
 if (iLightsSet != 1)
 {
 object oAreaLights = GetFirstArea();
 while (oAreaLights != OBJECT_INVALID)
 {
  object oLight = GetFirstObjectInArea(oAreaLights);
  while (oLight != OBJECT_INVALID)
  {
   string sLightTag = GetTag(oLight);
   int iLightType = GetObjectType(oLight);
   if (iLightType == OBJECT_TYPE_LIGHT)
   {
   SetLocalObject(oAreaLights,sLightTag,oLight);
   }
  oLight = GetNextObjectInArea(oAreaLights);
  } 
 oAreaLights = GetNextArea();
 }
 SetGlobalInt("lights_set",1);
 } 

Line 363 of ginc_sls2 changes
      
      // object oLight = GetObjectByTag(sLightTag,iLightCount);
      object oArea = GetArea(oFitting);
      object oLight = GetLocalObject(oArea,sLightTag);

#10
Dann-J

Dann-J
  • Members
  • 3 161 messages
Another way to get the light object is to use GetNearestObjectByType - as long as the light object you want is the closest one to the object that runs the script. Otherwise you can place a waypoint or ipoint close to the light object you want, and use that as the origin in the GetNearest function.

#11
painofdungeoneternal

painofdungeoneternal
  • Members
  • 1 799 messages
Put the lights inside effects, which you then apply to a placeable is another solution. I would really recommend using a system which has been fully debugged though.

#12
El Condoro

El Condoro
  • Members
  • 148 messages
@ DannJ: that is certainly the quickest method that I can see (and know how to implement!). The only downside, and it's fairly unlikely, is if certain lights in an area are to be called in a script. Even then the placeable could be called and then GetNearestObjectByType. I may yet try your approach! :) Thanks.



@ painofdungeoneternal: I haven't worked with effects much and am not sure how they would fit in the SLS2 but at least it shows that there are more than one approach to this bug. Thanks.

#13
Shallina

Shallina
  • Members
  • 1 011 messages
The problem with dannj method it's removing all the lights of the area.

#14
Dann-J

Dann-J
  • Members
  • 3 161 messages

Shallina wrote...

The problem with dannj method it's removing all the lights of the area.


You don't have to delete the lights. Just use GetNearestObjectByType to find them, then set them to active or not. A light object doesn't need a tag to be turned on or off. You only need the tag to define them as an object in the script via GetObjectByTag.

I've tested it for my upcoming module, where you have to light campfires and braziers, and occasionally set fire to things (which eventually go out). Although in that module the scripts are all called from objects that are right underneath the lights, so I can use GetNearestObjectByType using OBJECT_SELF as the starting point (which makes things easier, as I don't have to add waypoints or ipoints as the tagged origin objects). I can use it to find sound objects as well - doing away with the need for tags altogether in some instances.

There is often more than one way to do something. Use whichever method you're most comfortable with. I've never had much use for setting local objects, for instance. Perhaps if I learn more about them, and see clear benefits over other methods, then I might start doing things differently. Until then I prefer the KISS principle.

Modifié par DannJ, 25 janvier 2011 - 03:51 .


#15
Shallina

Shallina
  • Members
  • 1 011 messages
yup but you get all the lghts of the area with tha tmethod, and someone may not want to turn all the light off.

#16
MasterChanger

MasterChanger
  • Members
  • 686 messages

Shallina wrote...

yup but you get all the lghts of the area with tha tmethod, and someone may not want to turn all the light off.


No, that's why he said GetNearestObjectByType instead of GetObjectByType: with GetNearest, you just get the single object that's closest.

In essence, the methods are not really that different. As long as you have some object that you can access, be it the area itself or a series of waypoints/placeables/etc, you can retrieve the lights from those handles (via GetNearestObject or GetLocalObject or what-have-you).

#17
Kheflin Truarc

Kheflin Truarc
  • Members
  • 22 messages
I realize how late this is, but, being a newbie to any kind of module making, I found that UNCLE FB’S NPC CONTROL works great for lights by using the LIGHTKEEPER function on an NPC. He/she simply wanders around turning on and off the lights at given times...I works great! The only messing around I had to do was by adjusting the heights of the objects that needed to be lit, as the NPC couldn't "reach" them when too high...or at least I think that is why.

#18
Kheflin Truarc

Kheflin Truarc
  • Members
  • 22 messages
Not sure if I should start a new thread for this, but going back to:

Shallina wrote...

you need to destroy it and recreate it with script at the hours you want. For lights it's a little more difficult beceause they loose their tag when you save a game. Wich mean you must store them as local object in order to be able to access them.


How does one destroy/recreate an effect like "Floor Fog" to have it show up only at certain times?

If this should be in a new thread, or if it has been covered already, please let me know.

#19
kamal_

kamal_
  • Members
  • 5 240 messages
^^^ Spawn it at an ipoint, run a script on the point checking the time and spawn/destroy as appropriate.

#20
painofdungeoneternal

painofdungeoneternal
  • Members
  • 1 799 messages
cslCore_environment.nss has some examples, find the following functions to see how these things are implemented.

CSLEnviroSetGroundEffect is a function that works with a places effect, a upe file, to make the ground turn to snow. It is largely using custom vfx hooked to placeables. But shows how to distribute over a grid. ( links to entire CSL so you can trace each function easily )

CSLSetNWN2Fog and CSLResetNWN2Fog show how to do fog settings.

Basically to do proper flog of any sort, you do an SEF and a matching fog area effect. Floor fog would be an SEF attached to a placed effect ( a upe file ), and a very light fog setting on the area to make it look right. Using only one or the other tends to not work as well as both in combination, or you kill the users video card if you try to get it dense enough with SEF's by themselves.

CSLEnviroSetWeather does overall weather.

Modifié par painofdungeoneternal, 18 septembre 2011 - 07:16 .