Need Help!
Silencer9
Candidate for B.Sc. Join Date: 2003-08-05 Member: 18967Members, Reinforced - Shadow
<div class="IPBDescription">I have a question:</div> How can I make smokes which come out of pipes?
This is that what I mean: (Screenshot from 'ns_bast')
<span style='color:red'>+++ I REALLY NEED HELP +++ PLEASE POST SOMETHING HELPFULL +++</span>
This is that what I mean: (Screenshot from 'ns_bast')
<span style='color:red'>+++ I REALLY NEED HELP +++ PLEASE POST SOMETHING HELPFULL +++</span>
Comments
On second thought, the particle system is a bit more advanced than most newbie questions... so... meh...
<a href='http://pstutorial.tripod.com/' target='_blank'>the link</a>
I can't really be bothered to make and test a particle system to be identical to what you already have there, so i'll make a point based steam system that can be easily tweaked to however you want it to be.
The particle system used by NS, to be honest, is confusing at first, but when you have made your first system, it's really easy from then on.
Ok, here we go. I trust you're using VHE....
<span style='font-size:21pt;line-height:100%'><span style='font-family:Impact'>Esuna's crappy particle tutorial</span></span>
<span style='font-size:8pt;line-height:100%'>Don't blame me if it screws up!</span>
First off, let's make a box room with three things in it. An info_player_start, a func_resource and a env_particles_custom.
<img src='http://www.btinternet.com/~diesirae/tutorial1.jpg' border='0' alt='user posted image'>
You may be wondering why the func_resource.... This is because it uses a particle system of it's own, so you can see when the particle systems "turn on" some 20 seconds or so from the start of the map. Basically it's an indicator.
There's two ways that the env_particles_custom entity can work.
-Point based: This will generate the particles from the exact centre of the env_particles_custom entity.
-Brush based: This will generate the particles from a target brush based entity, they will be created randomly and is good for hazes and atmospheric effects.
Ok, now we have a testing room, let's get to work on the particles themselves. The format i'll do this in is i'll list each aspect of the env_particles_custom entity, what i have it set as and a brief description of what it means and what it changes. Some things i'll leave out because they're not relevant. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<li> Teh attributes!!11
<b>Name:</b>
Well, this is kinda obvious really. Name your particle system. I called mine Geoff.
<b>Generation Entity:</b>
For steam, you want to leave this blank. This tells the particle entity to generate the particles at the specified brush based entity as opposed to the env_particles_custom entity centre, for steam you don't want to do this since you want it to be generated from a single point.
<b>Generation Shape:</b>
Set this to point. No, i don't really know what this does. Lol.
<b>Generation Shape Parms:</b>
Leave this one blank. I think it's used by strippers to get more money.
<b>Generation Rate:</b>
Ok, this is how many parts per second you want created. Mine is currently set at 40. It's wise not to go too overkill with this number since if you set it really high you'll start to get some noticeable framerate loss. But basically, if you want the steam to be thicker, set it to generate more, if you want it to be thinner, set it to generate less.
<b>Particle Sprite:</b>
This is where you define what sprite you want the system to generate. I don't know of any others, but i'm using "sprites/co_dawn/steam.spr". I recommend you search through your sprites directory and find small steam looking sprites to use. They don't have to be animated, that's your choice. Sorry i can't offer much more help than this, but search and you shall find one.
<b>Animation Frames In Sprite:</b>
This is where you define how many animation frames there are in the sprite. My sprite has 1 so i've set mine to 1.
<b>Maximum Particles:</b>
This is the maximum amount of particles generated by this system that can exist in the world. When it hits this limit, it destroys an old one and creates a new one. Mine's currently set to 50. As with the generation rate, the alteration of this number has pretty much the same effects.
<b>Particle Size:</b>
This is where you set the starting size of each particle. If you set it to 1.0 it will be the same size as the sprite, if it's set to 0.5 it will be half the size and 2.0 will make it double the size. Pretty simple to work out. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<b>System Lifetime:</b>
This does exactly what it says on the tin. This is how long your particle system will last in seconds from the first time it's fired. I recommend you set this to -1 (Infinite) so it won't get destroyed at all.
<b>Particle Lifetime:</b>
This is the amount of time until a particle disappears, timed from when it's created. My system's set to 1, meaning that 1 second after each particle is created, it is then destroyed.
<b>Starting Velocity Shape:</b>
*Shrugs* You got me, but it works fine without me knowing what this is. Oh, and mine's set to Box.... whatever that does. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<b>Starting Velocity Params:</b>
This is where it gets annoying. I don't like this attribute. What you'll see is 8 numbers. With a new entity it will appear like so "<span style='color:red'>0,0,0,</span><span style='color:orange'>0,0,0,</span>0,0". Ok, so lets cut these up.
The first 3 numbers (The red ones) are the starting point of the particle system in the format of x,y,z,. I strongely recommend you leave them at 0,0,0,. This will mean that the particles will be generated exactly in the centre of the env_particles_custom entity.
The next 3 numbers (orange) are the target of your particle system, again in the format of x,y,z. This is calculated in worldcraft units, if i remember correctly, although i could be wrong. I find this is the point where trial and error comes into it, just enter numbers in the group of numbers (orange) and experiment where you want them to go. Remember, they're x,y and z, the same as in worldcraft (VHE).
My particle system uses the numbers "0,0,0,0,-80,-30,0,0". The second group are set as 0,-80,-30. This means that the particles will end up 0 units across (x), 80 units down (y) and 30 units vertically down (z). Put in those coordinates as a base if you like and tweak them as you test.
The last 2 numbers, leave them at 0,0,. Apparently things start to break if you tinker with those numbers. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<b>Scale Particle Over Lifetime:</b>
This multiplies the size of each particle relative to the number you enter. If you put in 2.0, it will gradually scale the particle to two times it's size over the duration of it's life, same as if you set it to 10.0 (which mine is set at) it will scale it to ten times bigger over it's lifetime.
<b>Particle Max Alpha:</b>
This sets the alpha level of each particle. The lower the number is, the more transparent it will be. 0.1 will be very transparent while 1.0 will be comletely solid. Just use trial and error to find the level that suits you. I'm currently using 0.4.
<b>Render Mode:</b>
You absolutely must leave this as "Additive -> (src*a+dest)". It breaks things otherwise. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
<b>Generate System On Collision:</b>
This is handy for things like water drops and so on. Basically when a particle hits a brush, it will generate a second system. For example. If you created a water drop, when it collided with a brush, you'd have it generate a splash system or the like. Since we're creating steam here, there's no real point to setting this to anything, so leave it blank.
<b>Animation Speed:</b>
This is the amount of frames per second (fps) that the animation will play for each particle. This is only really relevant if you're using an animated particle, which i'm not (so it's set at 1). But if you have a 16 frame sprite playing at 16 fps, the animation would be over in a second, simple.
<li> Teh flags!!11
<img src='http://www.btinternet.com/~diesirae/tutorial3.jpg' border='0' alt='user posted image'>
I don't really know what any of these do, but this is my current setup. If someone does know, then feel free to add a reply saying so.
The only ones i do know, however, are the "start on" and "collide" flags. The "start on" flag will cause the particle system to start on map load, i suggest you set this flag on, otherwise you'd have to target and trigger the system by some other event. The "collide" flag destroys a particle when it collides with a brush, this is handing for culling the number of particles when they're not required, i suggest you turn this on too.
<li> Teh end!!11!!111111111!0_-
Well, hopefully, after all of that, you should have a working particle system! If anyone has anything they'd like to contribute or add to this little tutorial, then please reply saying so.
I know i haven't gone in depth into the workings and i know i don't know exactly what everything does, but i do have a working knowledge good enough to create particle systems and know how to configure them how i want. So that's good enough for me. <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
Start on - Checking this flag means that the particle system will be on when the map starts. If you do not check this flag, you must trigger your particle system if you want it to turn on.
Particle density - Checking this flag will result in certain calculations being performed to determine the total number of particles allowed at any one time. Basically, it will produce more particles than the max particles value for large generation entities and less for small generation entities. This tends to cause more realistic particle numbers than trying to figure out a number on your own.
Fade in - Checking this flag means that the particle will generate with an alpha of zero and increase to the value set in Particle max alpha over its lifetime. This causes the particle to become more opaque until it dies. Note: this flag does not work with particles with infinite lifetimes.
Fade out - Checking this flag means that the particle will generate with an alpha equal to the value set in Particle max alpha and will decrease to zero over its lifetime. This causes the particle to become more transparent until it dies. Note: this flag does not work with particles with infinite lifetimes. Also note: Checking both fade in and fade out will cause the particle to fade in for the first half of its lifetime and fade out for the second half of its lifetime.
Use world grav - Checking this flag means that particles in your system will be subject to the gravity settings. This means that particles will constantly accelerate downwards during their lifetimes.
Tri, not quads - Checking this flag will help alleviate performance issues by using triangles instead of quadrilaterals. Basically, it will help make the system run more smoothly on lower-end computers with a small loss in quality.
Constrain pitch - Checking this flag means that the particle will not orient vertically to correspond with the player's view. Normally sprites will rotate so that the player sees them directly. Checking this means that they will only rotate along the horizontal, and not vertically. This is basically so the commander won't end up seeing sprites at a weird angle, such as fire sprites.
Collide - Checking this flag means that the particle will die when it collides with an object in the world. This means that particles that hit the wall will die. This flag will tend to protect your particles from traveling through the void and into a room that they shouldn't be in. Note: For generate system on collision to work, this flag must be checked.
High-detail only - Checking this flag means that this particle system is not "essential to gameplay," and will therefore only be drawn for players who have selected the option to have these particle systems drawn. Basically, checking this flag will help speed up performance for older systems (which likely won't have the high detail option on) by not drawing this particle system.
From the <a href='http://pstutorial.tripod.com/pstut/index.html' target='_blank'>Natural Selection Particle System Guide</a>
Thanks to everyone!
I now readed esunas Tutorial and finaly now am having an entity from
that i don't know: will it work or wont it...
Lets see......
<!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
The next 3 numbers (orange) are the target of your particle system, again in the format of x,y,z. This is calculated in worldcraft units, if i remember correctly, although i could be wrong. I find this is the point where trial and error comes into it, just enter numbers in the group of numbers (orange) and experiment where you want them to go. Remember, they're x,y and z, the same as in worldcraft (VHE).
My particle system uses the numbers "0,0,0,0,-80,-30,0,0". The second group are set as 0,-80,-30. This means that the particles will end up 0 units across (x), 80 units down (y) and 30 units vertically down (z). Put in those coordinates as a base if you like and tweak them as you test. <!--QuoteEnd--></td></tr></table><span class='postcolor'><!--QuoteEEnd-->
I'm pretty sure that the first three numbers are the minimum values, and the second three are the maximum values. HL randomly picks a value between the minimum and maximum, and that determines how far the particle goes.
Edit: Just checked; what I said is true when you use the box velocity shape.
Warning: long-winded post ahead <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->
I'm pretty sure that half-life uses a local randomizer that isn't synchronized and direct calls to the local multimedia timer. To have a coherent system across multiple client machines, you either need to store all of the information that affects the system locally and use deterministic functions (like an RTS does) or communicate all of the state information about individual particles to every client.
[tangent]
This is one reason why Half-Life demos are large files -- they need to store the state of every object the client interacts with becuase those states can't be reliably reconstructed under different client environments. Doom / doom2 demos just stored player inputs and used doom's locked-to-30fps internal clock to recalculate deterministic monster reactions same way every time. If you played back a doom demo on the wrong map version, you'd see the correct player actions played out in the wrong environment and the demo would diverge from what originally happened. This made it basically impossible to splice demo segments into movies, which is one advantage of the Quake/HL demo system.
[/tangent]
Sending the state of individual particles doesn't really gain much advantage over sending multiple sprite entities, so it shouldn't be considered as a solution.
Adding predictablility to particle systems in the Half-Life engine would be a pain. The easy part would be writing deterministic timers and randomizers--the hard part would be porting all of the code that affects the system to the deterministic functions and ensuring that clients remain in sync. You would have to make sure the randomizer was called an identical number of times by the same sequence of inputs for each timeslice, and also keep each client's timer returning an identical value within a timeslice as synchronized by the server. It's not impossible to convert a system that wasn't designed to be synchronized, but it isn't simple either.
RTS games use immediate user feedback (acknowledgement sounds, instant selection feedback) to hide the fact that their synchronization mechinisms require a full round trip before user input is factored into the game (having the unit start moving, etc). They also use a set delay from command to execution (usually around half a second) so that the game doesn't appear more sluggish over a slow connection--a client with a 250 ping should have plenty of time to process its inputs echoed back from the server during the half second pause and remain in sync.
For a game that uses prediction (like Half-Life), you wouldn't be able to have any interaction between predicted actions and synchronized actions -- if a player could affect a particle system by turning it on without a round trip, the prediction would screw up the local client's perception of the event for the duration of the round trip required by everybody else to see it activate. You could just insist on an RTS-style minimum delay for synchonized systems to activate to circumvent the problem, and most Half-Life triggers have a delay anyway, so it might not be an important problem.
For some reason when I try to answer a technical question it turns into a 500 word essay <!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
I tend to see my posts more as ramblings than rants, though. I guess I've gotten worked up about copyrights a few times... <!--emo&:p--><img src='http://www.unknownworlds.com/forums/html/emoticons/tounge.gif' border='0' style='vertical-align:middle' alt='tounge.gif'><!--endemo-->
As DarkATi well knows.
~ DarkATi
I often see marines shooting through funk_walls
with this textures which are having some blue, you know hat i mean...
but when i test my map the func_wall is always like a normal SOLID object
and the shots will be blocked if I shoot against the wall!
Is the render mode (solid) with 255 FX amount wrong?!
please tell me! But solid 255 works great with textures which are particulary
transparent! (fence-textures with blue parts)
Or is a func_wall the wrong entity?!
<span style='color:red'>!!! HELP !!!</span>
I often see marines shooting through funk_walls
with this textures which are having some blue, you know hat i mean...
but when i test my map the func_wall is always like a normal SOLID object
and the shots will be blocked if I shoot against the wall!
Is the render mode (solid) with 255 FX amount wrong?!
please tell me! But solid 255 works great with textures which are particulary
transparent! (fence-textures with blue parts)
Or is a func_wall the wrong entity?!
<span style='color:red'>!!! HELP !!!</span> <!--QuoteEnd--> </td></tr></table><span class='postcolor'> <!--QuoteEEnd-->
Make it a func_illusionary with render mode solid and fx amount 255, then if you don't want marines or aliens to be able to walk through it, make a clip brush which will block player movement but not bullets.
How to build???
clip brush is a brush textured with "clip" texture (it's the name of the texture and it comes invisible in game) ; it allows bullets to cross it but not players.
I wait for the resource node to start to produce particles. when it start, I can't see any particles of mine...
after some seconds the map closes and in the console:
Host_Error: PF_MessageEnd_l: Refusing to send user message Particles of 205 bytes to client, user message size limit is 192.
I can't understand... any tip? (please!! <!--emo&:)--><img src='http://www.unknownworlds.com/forums/html/emoticons/smile.gif' border='0' style='vertical-align:middle' alt='smile.gif'><!--endemo-->)
It works like it should!
But there are still problems with the env_particles_custom!
I see the smokes, but they wont move the right way,
and there where the smoke should be 100%ly transparent,
there is only black!
Please help!
<!--emo&???--><img src='http://www.unknownworlds.com/forums/html/emoticons/confused.gif' border='0' style='vertical-align:middle' alt='confused.gif'><!--endemo-->
EDIT: Thanks to tseepra, too!
using another render mode! But now there is still the problem that
I dont know how do say that damn env_particles_custuom
in which direction it should blow the sprites!
please help now with an short but all important having coment!