I added a "+Weapon" (expects a weapon class name) value to types "Ship" and "Weapon" that triggers the creation of weapons instead of particles. See documentation for more information.
Disclaimer: Creating too much weapons will result in game slowdown and possibly in reaching the maximum weapons number. Now nobody can say I didn't warn you :p.
A number specifying the state in which the
particles will emit. These states are engineintern values that give the current explosion
state. Valid values are 1, 2 and 3.
Looks nice, can't wait to see the patch integrated.
BTW, would that allow for real smoke trails (via scripting, I guess that getting them into table would take a while...) and things such as clouds to be done in FSO?
I'm completely lost on how +Velocity X Off-set is suppose to work thoughOkay, for every one of those three values you can specify either one or two numbers. When a particle gets created a vector is created where every value of the vector (x, y, z) is randomized to be between the specified values or the exact value is used when only value was specified for an axis. After that the vector will be normalized to be of length one (standard mathematical operation) and after that multiplied by the "+Speed" value as specified before. This way you can force the particle to fly in one specific direction, especially useful for weapon-impacts where you want the particles fly in exactly one direction.
Also, I'd like to request +speed for the parent particle or life time min/max, whatever works. Right now all the particles pretty much fade out at the exact same moment (as if they hit an invisible sphere wall)These values are specific to a particle bitmap as these values are computed based on the number of frames and the specified FPS of an effect. I could modify "+Effect" to accept multiple effects where one will be chosen randomly thus creating some diversity.
so, whats keeping this from going into trunk?Most likely just the not existing free time of a coder... :nervous:
I'd really like to use this in Diaspora... this script can create some nice looking fireworks :):eek2:
<snip>
Well, there is one outstanding issue with particles when game is paused (via pause or esc keys).I'm sorry to hear that (although I wasn't able to reproduce this myself) and I don't know any way to work around this bug :(
http://scp.indiegames.us/mantis/view.php?id=2446
For example, if you pause while a capship is exploding and you use this script, then wait a while and resume the game will take significant time before it gets from apprent freeze to jerky fps and finally to smooth fps as it tries to catch up the time that was spent while game was paused.
This is apparent with Wanderer's flashy explosion script as well. If you pause a game for a moment, you will see that upon resuming FSO attempts to create significant number of particles the next frame(s) to catch up. As far as I can tell, the issue happens with tabled particles as well.
Now, this is the first script that effectively can freeze a PC for very long time if you pause at the wrong moment. During testing this script I've had to kill FSO process many times because I couldn't be arsed to wait until it finally resumes for real.
I'd go as far as to say that this script is unusable beyond testing due to the problem with pause and particles.
*BOOM*:jaw:
I further tested the pause problem and I have to correct myself. This doesn't occur with pause, only with esc menu.Confirmed, just ran a test and I can confirm that script execution does not stop when the ESC menu is opened. This way the script will continue to generate particles which leads to the mentioned slowdown.
You see, if you press pause, you get Got event GS_EVENT_PAUSE_GAME (6) in state GS_STATE_GAME_PLAY (2)
If you press it again, you get Got event GS_EVENT_PREVIOUS_STATE (7) in state GS_STATE_GAME_PAUSED (3)
But if you press esc instead, game state does not change. I suspect this means all scripts are left in running state and when you resume the game, everything that your scripts have been working while esc menu was on, is getting thrown in at once. No idea at this time if this is limited to scripts or whether it does affect tabled particle generation too.
Could you play with a debug build and post the log here? Maybe it's not your computer :nervous:
Could you play with a debug build and post the log here? Maybe it's not your computer :nervous:
Here we go.
Ah, good to know. In this case, I hope there will be some improvements.(Especially in performance.)Could you play with a debug build and post the log here? Maybe it's not your computer :nervous:
Here we go.
Doesn't seem to be an error of the script, I'm sorry.
Ah, good to know. In this case, I hope there will be some improvements.(Especially in performance.)Errr, you seem to have missed the point in the very first post in this topic that this feature is not supported by trunk builds and requires the build m!m provided in the same post. Unless you have had someone to compile builds for you.
BTW: I didn't used the revision 7217 because it crashes on startup. I used the Revision 7151.
I further tested the pause problem and I have to correct myself. This doesn't occur with pause, only with esc menu.Confirmed, just ran a test and I can confirm that script execution does not stop when the ESC menu is opened. This way the script will continue to generate particles which leads to the mentioned slowdown.
You see, if you press pause, you get Got event GS_EVENT_PAUSE_GAME (6) in state GS_STATE_GAME_PLAY (2)
If you press it again, you get Got event GS_EVENT_PREVIOUS_STATE (7) in state GS_STATE_GAME_PAUSED (3)
But if you press esc instead, game state does not change. I suspect this means all scripts are left in running state and when you resume the game, everything that your scripts have been working while esc menu was on, is getting thrown in at once. No idea at this time if this is limited to scripts or whether it does affect tabled particle generation too.
m!m, are you familiar with Wanderer's flashy explosions script and how it uses rays for collision detection and to spawn explosion effects on hull where rays have successfully collided? Could this be used to generate these particles effects as well?That would be an option but how should it work? I would propose that the rays are sent from the center of the effect (can be moved) to the borders of the specified box (with +Box Min,...) or just in all direction when "+Box Min" is not set. Would that suit your needs?
http://www.hard-light.net/wiki/index.php/Script_-_Flashy_Deaths_(new)
That would be an option but how should it work? I would propose that the rays are sent from the center of the effect (can be moved) to the borders of the specified box (with +Box Min,...) or just in all direction when "+Box Min" is not set. Would that suit your needs?I would rather have +Box optional, by default I think particles could spawn from impact outwards in 90 degree angle (or whatever is the default when none is given). It'd basically just provide some randomization without having to use +Box option.
BTW: I posted a patch for your bug report, Fury.Cool, thanks. I've pointed it to The E on #scp. It's in 7219.
Okay, for every one of those three values you can specify either one or two numbers. When a particle gets created a vector is created where every value of the vector (x, y, z) is randomized to be between the specified values or the exact value is used when only value was specified for an axis. After that the vector will be normalized to be of length one (standard mathematical operation) and after that multiplied by the "+Speed" value as specified before. This way you can force the particle to fly in one specific direction, especially useful for weapon-impacts where you want the particles fly in exactly one direction.I think I somewhat understand.
I hope that helped, I'm aware that the documentation is lacking at some points but I'm planing to improve the documentation :nervous:
These values are specific to a particle bitmap as these values are computed based on the number of frames and the specified FPS of an effect. I could modify "+Effect" to accept multiple effects where one will be chosen randomly thus creating some diversity.Ah yeah thats how thruster particles work too, weapon particles have life time though so I figured it could be implented for this as well. Cause having to rely on the framerate for each file is kinda icky. If you want to have the same particlesmoke effect, you'd need to have duplicate file entries with different framerates assigned in the .eff files. slightly less than desirable.
Thanks for the report, already fixed it but no new upload yet as I have to test the raycasting that I got implemented :p
Works fine with 7226Damn, I knew that I forgot something. I changed the +Number handling to emit the specified number per second. Before it was dependent on the frame rate which may not be intended.
Though I take it you changed a few things around cause I had to dramatically up the +numbers: and +time: numbers
Well I definitely love this script, it really makes explosions that much more awesome. Using 7226 though it seems like there are some things that don't work as intended.I'll look into this as soon as possible.
+Speed and +Size both can take two integers, a Max and a Min value, and as I understand it the actual speed or size is supposed to be randomized for each particle-trail-emitter thingy. It's not; as far as I can tell only the minimum value is ever used.
Also, weapon creation... doesn't really work. I tried to have a simple near-invisible corkscrew weapon with a large trail attached, and so much stuff went wrong that I can barely describe it. Now that I scaled the particles down to a reasonable size, they're emitting downwards at a ridiculous velocity (I never specify any of the velocity or spewcone fields) on the first cruiser's explosion and dying after one frame in the second cruiser's explosion.I never really tested the weapon creation. Can you post an example with configuration file and the needed weapons table? This will help me to track down this bug.
[EDIT] It seems weapon generation is screwed up for corkscrew or swarm weapons, and those are really one of only two reasons to emit weapons in the first place.
Also, these particles being rendered next to flaming debris shows that these are much denser than flaming debris trails. A way to customize particle density in emitters would be nice.I think that shouldn't be too complicated.
all code in trunk ... fail
It is intended to be that way, you can adjust the moment the particles will be emitted, look at the documentation at the value "+Emitstate"Thanks, looks marvelous.
Hi,
could someone upload their particle config so us noobs doesn't have to create them themself? :)
Thanx
New version with density adjusting uploaded. Short summary: Now you can modify the density of the trail by adding "+Density" to the trail definition. This takes a value that it 0 > x >= 1 that will then specify the trail density (0.5 means that the trail is half a dense meaning that every second frame a particle is created).It's time to make more screenshots.....
Shots?You mean screenshots?
Shots?
All size calculation is based on the size of the ship that is exploding. Actually makes a lot of sense to me. In the very least it prevents needing to have a lot of seperate trail entries!
Shots?You mean screenshots?
Good job Nighteyes, you just gave Battuta a heart attack :yes:We should totally do this more often.
Good job Nighteyes, you just gave Battuta a heart attack :yes:We should totally do this more often.
Wow, what mod is that, Nighteyes?
Diaspora?
Giving Battuta heart attacks?
If so, how many can he survive?
Ship/Weapon trails are done I just need to add it to the documentation, until then:HNNNNNNNGGGGGGG
*Img*
*Img*
Fantastic work, M!M.1. I don't think that this script would be suited to have this feature but I could very well think of a separate script that could do this.
Now I found at least two interesting functions that could be added to this script.
1. Ejection seats, allowing defining the seat model, it's thruster effects, amount of seats and their spawning location on a per-ship basis (it'd also allow making ejection pods on capships).
2. Debris trails, as a replacement for the current, limited system. It'd be great to be able to set them on a per-ship basis.
Are these things possible to incorporate into this script?
another idea I have is generating particles when a specific type of weapon hits, the particles would generate from the hull of the ship flying outwards to space, with option to adjust speed, life, spread... I'm not sure how possible it is to make the generating point stick on the ship where the weapon impacted...That would be possible but a major problem I see is that there is no possibility to get
can be used to have smoke and fire emmit for a few seconds/minutes after a ship got hit by a massive warhead
I also just tested the +Fixed Size, and it looks like its only implemented on the ship particles, and not(more importantly) on the trail particles, can it also be added on trail particles please?Link in first post updated, should be working now :nod:
I coulda sworn we already had a script that does that.That does what?
How are the explosions right now? Still one single salvo of multiple trails, or is there a more complex beautiful design?I'm not exactly sure what you mean with "more complex beautiful design" but think I must disappoint you as I haven't changed anything but you can create quite complex effects by stacking multiple effects on top of each other and adding custom time offsets and lengths. :nod:
I already uploaded a new version of the script only to notice that it required a custom FSO build. I already posted the patch (http://www.hard-light.net/forums/index.php?topic=44821.msg1532010#msg1532010) to be committed to SVN so please wait until the patch has been committed :nod:
I'm ready to lose my virginity on scripts. Is there any kind of written guidelines where I should start, i.e., where should I download the scripts (I mean, where should I put them, how should I arrange them), how they work (heads up), etc.? Or is there an intended vacuum to prevent noobs like me to **** up their installation?When I started to do lua scripting I read through this wiki page (http://www.hard-light.net/wiki/index.php/FS2_Open_Lua_Scripting) but I don't know if the tutorial is still up to date.
One complaint about documentation. The code for defining custom config files is split between two pages, making copypasting it impractical.I'll upload an updated version later today :nod:
I don't do scripting... in fact when I tried to wrap my brain around it a couple of years ago, it gave me insomnia. In any case, while I have thus avoided trying to make sense of this child board, I was impressed with the ship explosion effects as displayed earlier in this thread, so I downloaded the scripts. After browsing through them for recognizable keywords, I have concluded that these scripts allow the inclusion of some fields to ship and weapons table files with which to create these impressive effects, rather than enable them for each ship by default, scaled based on ship size. Is this a correct assumption?Yes that assumption is correct and the rest of the creation code is also quite trivial. I also appreciate that someone else takes a look at my code and I'll gladly answer any code-related question :nod:
The nice part about this forum is that the scripting is done by people who actually know how to script (quite unlike me!)For the record: I actually hate the programming language Lua but you can make so many awesome stuff with it an FSO and when you know how to add to the existing scripting API you can do virtually anything that is not already implemented in the engine :cool:
Actually editing and adding to this script is as easy as doing weapons or ship tables.
Are those part of the death-roll or due to weapon impacts or subsystems being destroyed?Those effects have been created for weapon impacts which is nothing overly new but the new thing is that now it is possible to use normal of the polygon where the projectile impacted.
I'm not talking about flames rising away from the ship like they would in an atmosphere... that'd be just plain stupid. I suggested that for large weapon impacts, the effect would consist of a series of large inter-meshing explosion effects, with smaller ones along the perimeter. Over time, the total effect of the fire area would shrink as the oxygen from the ship in that area is used up. Any chance you guys could simulate that with scripting... or has it already been done?Something like that was the actual intention I had when I implemented that new feature and I plan to do implement that kind of effects next.
Ideally, I'd like to have the particles spawned from the random and hardcoded deathroll surface explosions.Surface explosions can't be accessed by the current scripting interface but you can achieve a similar effect by using "+Creating raycast" with "+Offset" set to some interesting part of the ship and then using "+Box Min/Max" to specify the boundaries of the ray check. You may want to add more of these effects for different parts of the ship.
So I'd have to set up multiple effects entries? I was hoping that there was an option to increase the box controls to encompass the entire model, but have the effects only spawned from within the actual model's perimeter. Would the offset option always use the same distance and direction from the center or would it choose a random direction offset with the selected distance. Also, I think that I could use some more explanation of what the raycast option does... if you please.
The config I'm using had +Creation raycast set to "YES" by default with +Raycast retries set to 5. Should I set this number to something insanely high to prevent the explosions-outside-the-ship effect? Also, for the box settings, do the three figures represent xyz distances for the box diameter? So if I used 50 60 70, then the box would be 100 wide, 120 tall, and 140 long, right?The Box values describe a volume that is defined by the two vectors you specify. So if you specify "100, 100, 100" and "-100, -100, -100" is would mean that the real position of the created particle will be inside the volume which is defined by the two vectors. That means that the X, Y and Z values of the resulting position vector will be randomized where each value will be between the vector values of the specified box vectors.
Also, the config file I started with had the max box set to 200 200 0, and the min box set to -200 -200 0. Will this cause the effects to be created on the surface of a 400 by 400 by 0 box, and not within it?Actually if you use these values the particles will be created on a plane rather than inside a box as the resulting position of the particle can only have a Z value if 0.
Not completely related but I figured this would be as good of a place as any to ask.Yes and it's even quite simple to do, sadly I won't be able to extend the script for the next three weeks as I'm not at home and I'm still waiting for my patch (http://www.hard-light.net/forums/index.php?topic=44821.msg1533160#msg1533160) to be reviewed. But in general it rather easy to detect if a weapon has been created in the current frame and then create the specified effect.
m!m do you have any clue if its easy/possible to spawn particles on weapon fire (muzzleflashes)?
If yes to both and if you are feeling bored/have too much free time. Would you be willing to take a shot at that? :D
If you could define a negative velocity for it, it could be used for backlash from rocketlaunchers too.The script doesn't differentiate between negative and positive velocity entries so it should work just fine.
OK. I decided to adjust the figures that I had to try to expand the area where the particles were being spawned from. I took the -200, -200, 0 and 200, 200, 0 that I had started with (which were in the config file that shipped with the scripts package) and replaced the "0"'s with -900 and 900 respectively. At first things looked good, and from a side view the explosions were coming from most of the length of the Orion. Unfortunately, when I chose an overhead view, I saw that explosions were spawning well out to the sides of the ship. If the third figure in each set is the Z figure, then this shouldn't affect the left-to-right positioning of the spawn space. What am I doing wrong? :confused:The config I'm using had +Creation raycast set to "YES" by default with +Raycast retries set to 5. Should I set this number to something insanely high to prevent the explosions-outside-the-ship effect? Also, for the box settings, do the three figures represent xyz distances for the box diameter? So if I used 50 60 70, then the box would be 100 wide, 120 tall, and 140 long, right?The Box values describe a volume that is defined by the two vectors you specify. So if you specify "100, 100, 100" and "-100, -100, -100" is would mean that the real position of the created particle will be inside the volume which is defined by the two vectors. That means that the X, Y and Z values of the resulting position vector will be randomized where each value will be between the vector values of the specified box vectors.
You also don't need to add the "+Raycast retries" option unless you see a message inside your fs2_open.log which says that no position for a particle could be found which will only happen if you have a very complicated model where a random ray is likely to miss.Also, the config file I started with had the max box set to 200 200 0, and the min box set to -200 -200 0. Will this cause the effects to be created on the surface of a 400 by 400 by 0 box, and not within it?Actually if you use these values the particles will be created on a plane rather than inside a box as the resulting position of the particle can only have a Z value if 0.
OK. I decided to adjust the figures that I had to try to expand the area where the particles were being spawned from. I took the -200, -200, 0 and 200, 200, 0 that I had started with (which were in the config file that shipped with the scripts package) and replaced the "0"'s with -900 and 900 respectively. At first things looked good, and from a side view the explosions were coming from most of the length of the Orion. Unfortunately, when I chose an overhead view, I saw that explosions were spawning well out to the sides of the ship. If the third figure in each set is the Z figure, then this shouldn't affect the left-to-right positioning of the spawn space. What am I doing wrong? :confused:The left-to-right positioning is caused by the X range of -200 to 200. If you don't the particles to spawn to the sides of the ship then you have to set both coordinates to 0 to avoid this effect.
IMO a small change to the script is needed here, remove the bounding boxs completely, and leave us only with 2 options:I don't think that removing that option is a good idea as it can still be used to limit the raychecks to a specific area of the ship. What could be useful is a new option that would set the bounding box options automatically to the bounding box of the ship essentially causing the effects to be spawned from all over the hull when raycast is set to YES or just out of space when it is unspecified or set to NO.
1. particles emmit from the center(or a specific location, set by coordinates, 0,0,0 would mean the center of the ship) of the ship(raycast set to NO)
2. particles emmit from all over the hull(raycast set to YES)
I cant really see a point in emmiting particles from a place outside the ship... and I doubt anyone will ever use this to emmit particles only from a certain point of a ship...
With this entry:The entry looks fine so the only reason I could imagine that particles spawn outside the ship could be that there is a bug in the script but I couldn't find anything that could cause your problems after a quick look at the script. I'm sorry but you will have to wait until I have a properly working FreeSpace install again which will in in less than two weeks.
$Type: Ship
$Class: DD Ranger
+Name: Ranger
+Effect: ExpFlash
+Time: 3
+Emitstate: 2
+Number: 80, 120
+Speed: 35, 105
+Size: 0.5, 2
+Box Min: -200, -200, -400
+Box Max: 200, 200, 400
+Spewcone: 90, 90, 90
+FPS: 1, 3
+Creation raycast: YES
+Raycast retries: 5
+Trail: ExplosionTrail
I've seen particles spawning outside the ship's hull.
The ship in question is about 250m tall, 250m wide and 700m long.
Also, "weapon" type doesn't seem to work,It worked when I did the last updates to the script which are still unreleased and it could be that the type could be broken in the version that is available to download. I will release the update as soon as possible as the necessary code is in trunk already.it always randomly spew dinky particles flying in corkscrew pattern (really!), regardless of actual settings.
EDIT: These dinky particles I mentioned turned out to be trails from tiny debris spawn when hitting ship's hull. So, "weapon" type simply does nothing.
$Type: Weapon
$Class: MDU-57
+Effect: ExpFlash
+Time: 1
+Number: 9, 10
+Speed: 600, 800
+Size: 5, 10
+Spewcone: 90, 90, 90
+Add Velocity: NO
+Trail: ExplosionTrail
This still doesn't spew any particles. With a framerate of 60 FPS you would need to set the number to 60 so one particle would be created. As noted before this will be fixed in the next version.Code: [Select]<snip>This still doesn't spew any particles.
Also, when one of multiple engines is disabled and thruster glow extinguishes, the particles remain.I noticed that too but I currently don't know how get the associated engine subsystem but I can change the script so the particles stop spawning when all engine subsystems are destroyed.
BTW, could you add an option to define offset of a ship trail?Yes, that's possible.
I also thought about a +contrail field, which would allow a trail to be enabled only if contrails are enabled in mission. It could have 3 possible values: NO (no dependancy) YES (when contrails are on) and DISABLE (enabled by default, disabled the contrails are enabled).I don't know if the scripting interface offers access to this kind of information but it could be possible to be added.
It would be great if this was added, as this would allow particle contrails, like in FreeFalcon. Also, contrails is just about the only thing this script can't yet replace with particle trails. One of my new ideas for Aces High reboot would be to ditch bitmap trails almost completely, at least in the "advanced" version (if everything goes as planned, the only use for trail bitmaps would be cannon tracers).You must be careful with the excessive use of particles as the performance of particles if FSO is awful. The script can be configured so it won't spawn new particles and cuts down the calculations of the script if the framerate is below a given value.
BTW, the script would also benefit greatly from allowing +Density: to be used on ship and weapon trails.
Invalid input type "number" should be "string"
stack traceback:
[string "zmisc-sct.tbm - On Game Init"]:14: in function 'stackError'
[string "zmisc-sct.tbm - On Game Init"]:30: in function 'stackErrorf'
[string "converter.lua"]:54: in function '__doConvert'
[string "converter.lua"]:78: in function 'convert'
[string "parser.lua"]:49: in function 'convert'
[string "particleParser.lua"]:1003: in function 'func'
[string "parser.lua"]:216: in function 'handle'
[string "parser.lua"]:248: in function 'handleKeyValue'
[string "particleParser.lua"]:46: in function 'handleKeyValue'
[string "parser.lua"]:239: in function 'processLine'
[string "parser.lua"]:124: in function 'parseFile'
[string "deathPart-sct.tbm - On Game Init"]:61: in function '__doParse'
[string "deathPart-sct.tbm - On Game Init"]:41: in function 'parseConfigFiles'
[string "deathPart-sct.tbm - On Mission Start"]:1: in main chunk
ntdll.dll! KiFastSystemCallRet
kernel32.dll! WaitForSingleObject + 18 bytes
fs2_open_3_6_13r_SSE2_BP.exe! <no symbol>
fs2_open_3_6_13r_SSE2_BP.exe! <no symbol>
fs2_open_3_6_13r_SSE2_BP.exe! <no symbol>
<no module>! <no symbol>
fs2_open_3_6_13r_SSE2_BP.exe! <no symbol>
<no module>! <no symbol>
<no module>! <no symbol>Only these entries had really been changed/added.$Type: Weapon
$Class: MDU-42
+Effect: ExpFlash
+Time: 1
+Number: 3, 5
+Speed: 600, 800
+Size: 5, 10
+Spewcone: 90, 90, 90
+Add Velocity: NO
+Trail: ExplosionTrail
+Use Normal: YES
+Emit Vector: 0, 0, 1
+Emit Variance: 0.3
$Type: Weapon
$Class: AG-132
+Weapon: NukeCloud
+Time: 1
+Number: 1
+Speed: 10000
+Size: 100
+Add Velocity: NO
+Trail: NukeTrail
+Use Normal: YES
+Absolute Normal: 0, 1, 0
+Emit Vector: 0, 0, 1
$Type: Weapon
$Class: NukeCloud
+Effect: ParticleSmoke01
+Time: 10
+Number: 200
+Speed: 1000
+Size: 100
+Spewcone: 90, 90, 90
+Add Velocity: NO
+Trail: NukeTrail
+FPS: 94
$Type: Ship
$Class: DD Ranger
+Name: Ranger
+Effect: ExpFlash
+Time: 1
+Emitstate: 2
+Number: 80, 120
+Speed: 200, 400
+Size: 0.5, 2
+Box Min: -100, -100, -300
+Box Max: 100, 100, 300
+Spewcone: 30, 30, 30
+FPS: 20, 30
+Emit from hull
+Use Ray normal
+Move Outwards
+Trail:
The log looks like that: LibraryManager: Reloading all loaded libraries
LibraryManager: Loaded file "class.lua"
LibraryManager: Loaded file "objectWrapper.lua"
LibraryManager: Loaded file "particles.lua"
LibraryManager: Loaded file "strings.lua"
LibraryManager: Loaded file "parser.lua"
LibraryManager: Loaded file "converter.lua"
LibraryManager: Loaded file "util.lua"
LibraryManager: Loaded file "trailInfo.lua"
LibraryManager: Loaded file "particleParser.lua"
LibraryManager: Loaded file "effectManager.lua"
PARTICLE SCRIPT: Parsing file "particles.cfg"
BMPMAN: Found EFF (ExpFlash.eff) with 86 frames at 24 fps.
BMPMAN: Found EFF (WhiteSmoke.eff) with 24 frames at 30 fps.
ERROR: Invalid input type "number" should be "string"
stack traceback:
[string "zmisc-sct.tbm - On Game Init"]:14: in function 'stackError'
[string "zmisc-sct.tbm - On Game Init"]:30: in function 'stackErrorf'
[string "converter.lua"]:54: in function '__doConvert'
[string "converter.lua"]:78: in function 'convert'
[string "parser.lua"]:49: in function 'convert'
[string "particleParser.lua"]:1003: in function 'func'
[string "parser.lua"]:216: in function 'handle'
[string "parser.lua"]:248: in functiFreeing all existing models...
Size of bitmap info = 760 KB
Size of bitmap extra info = 52 bytes
ASSERTION: "be->type != BM_TYPE_NONE" at bmpman.cpp:1640
LibraryManager: Reloading all loaded libraries
LibraryManager: Loaded file "class.lua"
LibraryManager: Loaded file "objectWrapper.lua"
LibraryManager: Loaded file "particles.lua"
LibraryManager: Loaded file "strings.lua"
LibraryManager: Loaded file "parser.lua"
LibraryManager: Loaded file "converter.lua"
LibraryManager: Loaded file "util.lua"
LibraryManager: Loaded file "trailInfo.lua"
LibraryManager: Loaded file "particleParser.lua"
LibraryManager: Loaded file "effectManager.lua"
PARTICLE SCRIPT: Parsing file "particles.cfg"
PARTICLE SCRIPT: Parsing file "ranger.cfg"
BMPMAN: Found EFF (ExpFlash.eff) with 86 frames at 24 fps.
ERROR: Invalid input type "number" should be "string"
stack traceback:
[string "zmisc-sct.tbm - On Game Init"]:14: in function 'stackError'
[string "zmisc-sct.tbm - On Game Init"]:30: in function 'stackErrorf'
[string "converter.lua"]:54: in function '__doConvert'
[string "converter.lua"]:78: in function 'convert'
[string "parser.lua"]:49: in function 'convert'
[string "particleParser.lua"]:1003: in function 'func'
[string "parser.lua"]:216: in function 'handle'
[string "parser.lua"]:248: in functiFreeing all existing models...
Size of bitmap info = 760 KB
Size of bitmap extra info = 52 bytes
ASSERTION: "be->type != BM_TYPE_NONE" at bmpman.cpp:1640 The config "ranger.cfg" looks like that: $Type: Ship
$Class: DD Ranger
+Name: Ranger
+Effect: ExpFlash
+Time: 1
+Emitstate: 2
+Number: 80, 120
+Speed: 200, 400
+Size: 1, 2
+Box Min: -100, -100, -300
+Box Max: 100, 100, 300
+Spewcone: 30, 30, 30
+FPS: 20, 30
+Emit from hull
+Use Ray normal
+Move outwards
+Trail: ExplosionTrail
$Type: ShipTrail
$Class: DD Ranger
+Effect: ThrusterFed
+Speed: -30, 0
+Size: 95, 105
+Number: 9, 11
+Use thrusters: YES
+Emitstate: Normal
+Use Thruster Strength: YES
+Density: 2
$Type: ShipTrail
$Class: DD Ranger
+Effect: ParticleSmoke01
+Speed: -30, 0
+Size: 130, 150
+Number: 5, 15
+Use thrusters: YES
+Variance: 9
+Emitstate: Always
+Use Thruster Strength: NO
+Damage Trails: YES
+Damage Start Level: 80
+Damage Maximum Level: 40
+FPS: 118
LUA ERROR: [string "particleParser.lua"]:1058: attempt to compare number with nil
------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0
Source: (null)
Short source:
Current line: 0
- Function line: 0
------------------------------------------------------------------
------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------
------------------------------------------------------------------
And the script doesn't do anything.
LUA ERROR: [string "particleParser.lua"]:1058: attempt to compare number with string
------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0
Source: (null)
Short source:
Current line: 0
- Function line: 0
------------------------------------------------------------------
------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------
------------------------------------------------------------------
Using this weapon, $Type: Weapon
$Class: MDU-42
+Effect: ExpFlash
+Time: 1
+Number: 3, 5
+Speed: 600, 800
+Size: 5, 10
+Spewcone: 90, 90, 90
+Add Velocity: NO
+Trail: ExplosionTrail
+Use Normal: YES
+Emit Vector: 0, 0, 1
+Emit Variance: 1
$Type: WeaponTrail
$Class: AIM-92 Talon
+Effect: exp_smoke
+Speed: 0
+Size: 120, 125
+Number: 1
+Use thrusters: YES
+Variance: 0
+Emitstate: Normal
+FPS: 1
+PPS: 480
Causes the trail to look like this:Also, your fix works.
torc has pointed out something cool after testing the script in Diaspora, how easy will it be to add this script to activate for subsystems explosions?It will be a more complicated but it should be possible.
torc has pointed out something cool after testing the script in Diaspora, how easy will it be to add this script to activate for subsystems explosions?It will be a more complicated but it should be possible.
*I know its possible already to do, but I'm saying that by default it should be set up like that, so that people won't have to edit script lines...
some more: debris trail as it is implemented right now is inferior to the version in the mediavps, the particles should grow smaller over time untill the fire completely burns out, it should also generate particles on a few different points on the debris hull, and have them at a randomized size so they don't all look the sameAlright, I'll include an option to specify the lifetime of a particle plume which will be used to let the generated particles get smaller over time. But the two other things you mentioned are already possible by using the "+Size" and "+Number" options.
after quite a bit of trail and error, I take my word back regarding the set size function for the trail particles, it kind of works, but not like I imagined it, currently when a trail particle has a set size, it will use the size from the parent particle that is generating it, basically disregarding the size set it the trail particle field.I'll include an options that will let you control whether you want to have a fixed size or a dynamic (similar to the existing ones)
can they be unlinked please? its much easier to have 2-3 trail types that you know how they will look in-game than to relay on a percentage from the size of a ship... I might also want to have a really small parent particle and a rather large trail behind it, currently, this is not possible...
$Type: Ship
$Class: GTD Orion
+Name: TestEffect
+Effect: capflash
+Time: 1
+Emitstate: 2
+Number: 20, 20
+Speed: 1600, 2200
+Size: 4, 5
+Box Min: 0, 0, 0
+Box Max: 0, 0, 0
+Spewcone: 90, 90, 90
+FPS: 15
+Trail: GenericTrailI am having trouble finding any asset named 'GenericTrail' in the VP files. Where does this come from? Does something special need to be done to set up another particle trail? Specifically, I want to find the necessary files and alter them, to produce similar effects with altered hues (for different colors).The download contains a packaged directory which can be used as a mod or you can just drop the files inside that folder into an existing mod folder.I get this Error
LUA ERROR: [string "parser.lua"]:80: attempt to perform arithmetic on field 'currentLine' (a nil value)
------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: (null)
Name of: (null)
Function type: (null)
Defined on: 0
Upvalues: 0
Source: (null)
Short source:
Current line: 0
- Function line: 0
------------------------------------------------------------------
------------------------------------------------------------------
LUA Stack:
------------------------------------------------------------------
------------------------------------------------------------------
Yes, that will work but you will have to modify the existing configuration files as those only contain some testing entries (look at the PDF file inside the docs directory for information on what to do).
$Type: Ship
$Class: GTC Leviathan
+Name: TestEffect
+Effect: capflash
+Time: 3.5
+Emitstate: 1
+Number: 70
+Speed: 50
+Size: 4
+Box Min: 0, 0, 0
+Box Max: 0, 0, 0
+Spewcone: 90, 90, 90
+FPS: 1.1
+Trail: Leviathantrail
$Type: ParticleTrail
$Name: Leviathantrail
+Effect: Particlesmoke01
+Size: 80
+Time: 11LUA ERROR: [string "trailInfo.lua"]:328: attempt to index global 'deathParticleScript' (a nil value)
------------------------------------------------------------------
ADE Debug:
------------------------------------------------------------------
Name: checkDebris
Name of: method
Function type: Lua
Defined on: 314
Upvalues: 0
Source: trailInfo.lua
Short source: [string "trailInfo.lua"]
Current line: 328
- Function line: 15
------------------------------------------------------------------
------------------------------------------------------------------
LUA Stack:
checkDebris
doObjectInfoRun
------------------------------------------------------------------
------------------------------------------------------------------