Hard Light Productions Forums
Modding, Mission Design, and Coding => The Scripting Workshop => Topic started by: Nuke on May 04, 2008, 10:13:05 pm
-
finally upgraded my old rail effect, now it doesnt stutter as much
heres the script, save as scripting.tbl
#Global Hooks
$GameInit:
[
--effect vars
particle_tex = gr.loadTexture("2_laserglow03")
particle_life = 0.3
deg_per_particle = 5
rot_per_sec = 3
z_vel_factor = 0.08
r_vel_factor = 10
--globals
pih = math.pi * 0.2
pi2 = math.pi * 2
]
$Simulation:
[
for i=1, #mn.Weapons do --loop weapons
if mn.Weapons[i].Class.Name == "Railgun" then --if the weapon is one of these
if mn.Weapons[i]:isValid() and particle_tex:isValid() then --dont work with bad handles
local traillen = mn.Weapons[i].Class.Speed * ba.getFrametime() --distance covered per frame
local arcradis = pi2 * rot_per_sec * ba.getFrametime() --rotation covered per frame
local lifeleft = mn.Weapons[i].LifeLeft * pi2 * rot_per_sec --scale remaining life by rotations per second
for j=0, 1, deg_per_particle * 0.01745329 do
local part_rot = lifeleft + (arcradis * j)
local part_vel_x = math.sin(part_rot) * r_vel_factor
local part_vel_y = math.cos(part_rot) * r_vel_factor
local part_vel_z = mn.Weapons[i].Class.Speed * z_vel_factor
local part_vel = mn.Weapons[i].Orientation:unrotateVector(ba.createVector(part_vel_x,part_vel_y,part_vel_z))
local offset_v = mn.Weapons[i].Orientation:unrotateVector(ba.createVector(0,0,traillen * j))
ts.createParticle(mn.Weapons[i].Position - offset_v,part_vel,particle_life,1,PARTICLE_BITMAP,-1,false,particle_tex)
end
end
end
end
]
#End
and heres a sample tbm, save as railgun-wep.tbm
#Primary Weapons
$Name: Railgun
$Model File: none
@Laser Bitmap: newglo8
@Laser Glow: 2_laserglow03
@Laser Color: 69, 42, 172
@Laser Color2: 69, 42, 172
@Laser Length: 80
@Laser Head Radius: 2.5
@Laser Tail Radius: 5.0
$Mass: 0.08
$Velocity: 1200
$Fire Wait: 2.5
$Damage: 200
$Blast Force: 1500
$Inner Radius: 75
$Outer Radius: 150
$Shockwave Speed: 90
$Armor Factor: 1.3
$Shield Factor: 0.2
$Subsystem Factor: 1.0
$Lifetime: 1
$Energy Consumed: 1.0
$Cargo Size: 0.0
$Homing: NO
$LaunchSnd: 81
$ImpactSnd: 85
$Flags: ( "player allowed" "shudder" "stream")
$Icon: iconNewton
$Anim: Newton
$Impact Explosion: ExpMissileHit1
$Impact Explosion Radius: 75
#end
all the vars at the start of the script are tweakable for different weapons.
particle_tex = gr.loadTexture("2_laserglow03")
you can change what bitmap you want to use by sticking it in the quotes
particle_life = 0.3
how long particle will last
deg_per_particle = 5
number of degrees between particles, higher = faster, fewer particles, lower = slower, more particles, better effect.
rot_per_sec = 3
how many rotations per second, duh
z_vel_factor = 0.08
factor of weapons forward velocity at which particles will move forward
r_vel_factor = 10
the velocity at which the particles will radiate outward from the weapons z axis
-
Cool...
-
.......
So can someone decipher this code and tell me what it will look like?
-
give me a few, im editing a video for youtube.
-
http://www.youtube.com/watch?v=YTlDH0QfYjE
-
mn.Weapons[ i ] could definitely benefit from a handle :p
Very cool...
-
i still need to optimize it abit. its very easy to over-do the number of particles and cripple the frame rate.
-
i thought mn.Weapons[ i ] was a handle
i wouldn't mind having a $script vars: section in various tables. it could be implemented as a list of vars with variable types
$script vars: "rail", 10, 57, true
or as a section list with datatype flags, (which would make more since to parse in c).
$script vars:
+string: "rail"
+number: 10
+number: 57
+bool: true
then that data is stuck into script accessible arrays (one for each type) as part of the weapon or ship class handle. since lua only has 3 data types you'd probably only require 3 arrays, a float array a bool array and a char array. this would allow me to assign script based effects and features to various ships and weapons without alot of hard coding and fewer ugly hacks. would also allow modders to use scripts without knowing how to script.
-
It is, but due to how fs does things, it has to iterate through the array to index it. A handle variable bypasses that.
I agree with the script vars; I had plans for something like that. Getting it coded is another thing entirely.
-
some things i wish i had an absolute reference to. i created a system for ships to store vars but its got to run a chain of nested loops each time i want to look up a ship. each var, like jumpdrive charge, has its own array. and each ship, has its own index. forming sort of a lookup matrix. since each ship has a unique name i use that as my lookup array (an array of name strings).
at mission start a list of names is created by iterating through ships, and a default value is assigned to each section of data.
every few frames scan the list looking for any ships that are no longer in the mn.Ships[] array, and give it a name that markes it for being overwritten. in the process i also look for any new ships that arent in the lookup array, add them to dead fields first and create new ones as needed. then i assign default values for each array.
i then have a lookup function that takes a ship handle, looks for its name in the lookup list and returns an index with which i can get at its vars.
as you can probably tell it requires alot of string processing. alot of doing the same thing over and over again. i don't think it would work for weapons since they don't seem to appear to have a unique naming. its actually pretty fast in the context of the fsrts, which really doesnt need to do alot of xform ops. it worked and even aardwolf was impressed. the system never had more than a couple dead indexes in the lookup list at any time, even after a couple fleets were created and destroyed.
i don't mind using this system, its not alot in terms of code, but it is perhaps alot of processing. i have no idea what kind of cpu drain that sorta thing is. the other problem is i don't have a way to do the same thing with weapons. though the only reason i can think for something like that would be for the tac drones i created. you could fire two at a time, but only receive telemetry from and have control over one at any given time. since they also carried weapons, and i had to track ammo, if i ran out of ammo for one drone, the other drone would also be out. or if i launched another one while the first was still flying, it would inherit its ammo count. if i could tag a variable to a handle i could track such things. also for the railguns, the rotation was a function of the weapons lifetime value, so the railgun would look the same each time it was fired. i wish i could associate a random rotational offset so i can make them start spinning from a different angle. also perhaps a flag that will tell it to rotate in the other direction half the time.
-
MechWarrior 4 anyone?
:nervous::yes:
-
that too :D
-
I think you'd get better performance AND graphics by mapping it to a traditional tiled-bitmap trail such as those currently used for missiles.
-
i tried that and the effect looks hideous
-
Excellent Nuke, thanks a bunch.
(Yes it does look terrible, we tried once upon a time too.)
-
no problem. im looking at implementing this in c, that way it would be easier to assign different parameters for different weapons, make it a little faster, and open the door for the implementation of more particle spew types.
-
This is the same effect you used in your YouTube video, right? I posted there a comment about it.
-
any updates?
-
no not really, too much **** going on, too much work, and im gonna be moving, thought not sure to where just yet
-
uh, how do you get this to work in-game, and does this require a special build to use?
-
Read the first post. It should work in any recent build that supports scripting.