Jump to content
The Dark Mod Forums

Particle bounds


Springheel

Recommended Posts

Is there any way to see what bounds a particle effect will spawn inside of? I'm having problems with dust particles being visible from the wrong side of windows, but without understanding how the "distribution" and "direction" spanwargs work, I can't figure out how to keep that from happening.

 

Alternatively, is there a way to turn particle effects off if they're in a visleaf that isn't visible to the player? That would also solve the problem.

Link to comment
Share on other sites

You could have a trigger that turns off the particle when the player leaves the area where the particle is.

 

I had to do this in Transaction. IIRC, I used location system to disable rain particles when the player went into the derelict house, otherwise there would have been rain in the basement where the player was supposed to sleep.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Can particles be turned on/off by a trigger or do they have to be teleported away?

Link to comment
Share on other sites

Can particles be turned on/off by a trigger or do they have to be teleported away?

Yes, func_emitters are toggled by triggers. I've used that for several custom lamp setups.

Link to comment
Share on other sites

Can particles be turned on/off by a trigger or do they have to be teleported away?

This reminded me of something amazing Dram did in the old Blackheart manor map, all func_emitters and light entities would be turned off when a player left an area/leaf. I never did figure out how he it because it was done by script.

 

Rather than trying to learn how he did it, in this instance my question is similar toi Springs in that can a func_emitter by turned on/off by being targeted from an info_location entity..? My idea is to check in-game with "r_showtris 2" and check for any entitys being drawn, is a Func_static I can hide it and if a Func_emitter turn it off.

Link to comment
Share on other sites

I'd be worried about using trigger_multiples for this, since the player could, for example, walk into the doorway trigger, turn the particles inside the house on, then back out of the house and then enter again, turning them off.

 

Using an info_location entity would be much better, but is that possible?

Link to comment
Share on other sites

The trick to using trigger_multiples in this situation is to have one just inside the door and one a bit aways, deeper in the building.

 

Let's say the emitters are outside.

 

The trigger (let's call it 'A') near the door (just before you step outside) calls a script that turns on the emitters AND sets a variable saying they're ON. If the player stands inside A and it fires again, the script checks the variable and if it says ON, the emitters aren't triggered and nothing happens.

 

For the trigger deeper inside the building (let's call it 'B'), it calls a different script that turns OFF the emitters AND sets the variable saying they're OFF. If the player stands inside B and it fires again, the script checks the variable and if it says OFF, the emitters aren't triggered and nothing happens.

 

So what happens?

 

The player walks into the building from outside, and passes through A then B. A does nothing because the emitters are already ON. B turns the emitters OFF.

 

If the player leaves the building, he passes through B then A. B does nothing because the emitters are already OFF. A turns the emitters ON.

 

If the emitters are INSIDE the building, then swap the two triggers.

Link to comment
Share on other sites

Using an info_location entity would be much better, but is that possible?

 

Yes. The location entities can be set up to fire "entry" and "exit" targets. (I don't remember if they target entities, or if they call a script. Can't check atm.)

 

When the player enters the building, the location entity outside fires its exit targets. (The inside location entity doesn't need to trigger anything.) It could target a trigger_relay that targets the unwanted emitters, turning them off.

 

When the player leaves the building, the location entity outside fires its entry targets. It could target the same trigger_relay, which turns the emitters on again.

 

One problem with this is that if the player leaves the outside location at a different point, the emitters will be turned off. If the player is moving from one outside location to another, and can still see the emitters from his new outside location, then the new location entity will need to turn the emitters back on. If you're watching the emitters, they might toggle, which--depending on the type of emitter--might not look correct.

  • Like 1
Link to comment
Share on other sites

That sounds like it will do what I need, thanks.

 

The Transaction example seems to call a script? I can't find an entity called "thunder switch"

 

edit: Yes, it's a script, and handily described on the wiki.

  • Like 1
Link to comment
Share on other sites

If I want to trigger more than one entity, which parts of this script do I need to reproduce?

void yourscript(entity old_zone){sys.println("script yourscript running..");sys.trigger( $entity_name );}void main(){}

Also, should I replace "old_zone" with the name of the zone the player is entering?

Link to comment
Share on other sites

So I think, you need to have on the location where you have the particle effect

"call_on_entry" "toggle_particle"

and

"call_on_exit" "toggle_particle"

 

Now, if the player starts in the area where the particle is, you need to have it ON when the map starts. If otherwise the particle needs to be initially OFF.

 

The script looks like this:

void toggle_particle(entity old_zone)
{
sys.println("toggling particles!");
sys.trigger( $entity_name_of_particle );
}

If you need more things to trigger, keep adding lines

sys.trigger( $entity_name_of_thing1);

sys.trigger( $entity_name_of_thing2);

etc

 

No need to rename (entity old_zone). I think you do not even need it, because no parts of you script need to know anything about the "old_zone." Having the call_on_exit and call_on_enter will have the particles triggered each time the player moves in or out the zone.

 

That is:

*if the player starts in the zone and the particle is ON, the particle goes OFF when the player leaves and goes ON when the player comes back.

*if the player starts outside the zone and the particle is OFF, the particle goes ON when the player arrives and goes OFF when the player leaves.

  • Like 2

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

If otherwise the particle needs to be initially OFF.

 

 

What's the spawnarg that does this?

Link to comment
Share on other sites

Or was it "start_off 1" ?

 

You can usually see what is available by right clicking entity inspector spawnarg list and choose add spawnarg. Or check if the spawnarg lists in the inherited spawnargs. These do not necessarily show all spawnargs, though.

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

This reminded me of something amazing Dram did in the old Blackheart manor map, all func_emitters and light entities would be turned off when a player left an area/leaf. I never did figure out how he it because it was done by script.

There are two ways that come into my mind to do this, either by using the stim/response system and/or by using a custom script.

 

With the first one, the player stim would activate all nearby func_emitters and keep them in that state. If the func_emitters are not receiving the stim anymore, they are disabling themselves. For this effect to work they need a custom script, though.

 

If you are only using a script you would have to let every func_emitter rund an update loop which checks the location or (which may works out better) checks whether they player is close enough and can see the func_emitter (or vice versa whether the func_emitter see's the player). Using the locations could cause particles to be turned off although the player is seeing them, just because he stands behind a vp seperating his location from the particles one.

 

The script could look like this (not tested):

object custom_emitter
{
    void init();
    void updateLoop();
    float updateTime;
    float visDist;
    float state;
};
void custom_emitter::init()
{
    //set the time to wait before each check
    updateTime=getFloatKey("updateTime");
    if (!updateTime) //no time specified via spawnarg
    {
        updateTime=0.1;
    }
    // set the distance at which the particle should become invisible
    visDist=getFloatKey("visDist");
    if (!visDist)
    {
        visDist=300;
    } //this could be adjusted to become lod-dependent
    if (!getFloatKey("start_off")) state=1;
    updateLoop(); //run the loop

}
void custom_emitter::updateLoop()
{
    while(1)
    {
        /*
        this block gets executed if the state does not represent the state condition:
        1. the particle is on but the player is too far away
        2. the particle is off but the player is close enough
        */
        if ((distanceTo($player1)<visDist) != state) 
        {
             state=(state+1)%2; //change the state variable
             sys.trigger(self); //chenge the actual state
        }
        wait(updateTime);
    }
}
  • Like 1

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

I'd be worried about using trigger_multiples for this, since the player could, for example, walk into the doorway trigger, turn the particles inside the house on, then back out of the house and then enter again, turning them off.

 

Using an info_location entity would be much better, but is that possible?

 

Yes, definitely. The location system supports running a script when the player enters one location, and one when he leaves the location -no matter how the player actually enters or leaves the location.

 

Use one or two of these on the info_location separator entity:

 

 

        "editor_var call_on_exit"                               "Name of global script function to be called when the player exits this zone."
        "editor_var call_on_entry"                              "Name of global script function to be called when the player enters this zone."
        "editor_var call_once_on_exit"                  "Name of global script function to be called exactly once when the player exits this zone."
        "editor_var call_once_on_entry"                 "Name of global script function to be called exactly once when the player enters this zone."

Inside the script you can do whatever you want, activate triggers, dim lights or teleport entities etc.

 

If you need help with that, I'm happy to provide script snippets.

  • Like 1

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

 

There are two ways that come into my mind to do this, either by using the stim/response system and/or by using a custom script.

 

With the first one, the player stim would activate all nearby func_emitters and keep them in that state. If the func_emitters are not receiving the stim anymore, they are disabling themselves. For this effect to work they need a custom script, though.

 

If you are only using a script you would have to let every func_emitter rund an update loop which checks the location or (which may works out better) checks whether they player is close enough and can see the func_emitter (or vice versa whether the func_emitter see's the player). Using the locations could cause particles to be turned off although the player is seeing them, just because he stands behind a vp seperating his location from the particles one.

 

The script could look like this (not tested):

No need to make it this compliated, running a script function when the player leaves/exits a zone is much safer - it even works with noclip :)

 

Edit: Although I like your idea of distance-based emitters, this should really be built into emitters and turned into a C++-supported spawnarg. Running a script function on each emittier will use a lot of resources if you have lots of emitters, plus it adds quite some memory overhead for the script objects that need to be bound to each emitter.

Edited by Tels

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

Springheel, the solutions posted above use only one function, that calls "trigger" on the entities. Which means, they are toggled. You could also use two different functions, and one calls

 

 

$entity.On();

 

while the other one calls:

 

 

$entity.Off();

 

It would be even safer if you have a function that runs through all emitters, and only disabled the ones in the old_zone, and enables all in the current zone. Then you would not need to adjust the scripts everytime you add/delete or rename an entity. (The last one is a potential source of errors!)

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

@Bikerdude: can do

 

@Tels: Using the location system can cause the above mentioned effect. As well, it would in that case make much more sense to use a custom script anyway instead of triggering each particle "manually", which is tiresome to setup and not very error-prone.

 

It may be possible to use lod, though. I'm not sure whether the func_emitters are supporting this system, as I've never tested it, but it could be the easiest way.

 

EDIT: Bikerdude, he uses triggers. The script is just there for enabling/disabling them.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

@Bikerdude: can do

 

@Tels: Using the location system can cause the above mentioned effect. As well, it would in that case make much more sense to use a custom script anyway instead of triggering each particle "manually", which is tiresome to setup and not very error-prone.

 

It may be possible to use lod, though. I'm not sure whether the func_emitters are supporting this system, as I've never tested it, but it could be the easiest way.

 

 

 

The "effect" you mention is toggling (which can be solved with two scripts) or "see emitter even when not in zone"? That would need a more complicated setup, which is indeed cumbersome.

 

And yes, the manual listing of entities in the script is very error prone.

 

Anyway, I think it would still make sense to add support for "max_view_distance" spawnarg on emitters - then they could toggle themselves off with little resources.

 

There is still the problem that a lot of emitters could be near the player, but not visible (think "one floor above the player"), or they could be far away, but need still to be visible (otherwise there is popping when the emitter comes into the distance). So its probably not safe to set default values, but instead use "-1" as "inifite view distance".

 

In any event, are we sure that turning off emitters actually improve performance in a visible way? Edit: Oh, yeah it was for emitters that should not be visibe from outside - in that case a distance base check would not work, anyway (outside/inside of house is the same distance, but in one case the emitter is behind the wall and should be off).

 

So, yeah, I guess location zones + scripts to toggle the emitters is the one method which must be used here.

 

Still, I could provide a script that toggles all emitters in a certain zone - that way you would not have to list all the emitters in the script manually.

Edited by Tels

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

You can usually see what is available by right clicking entity inspector spawnarg list and choose add spawnarg. Or check if the spawnarg lists in the inherited spawnargs.

 

 

I knew about inherited spawnargs, but what is the entity inspector spawnarg list?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 0 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
    • nbohr1more

      Please vote in the 15th Anniversary Contest Theme Poll
       
      · 0 replies
×
×
  • Create New...