id Tech Forums

Zeroth's work on the HUBs for Hexen was really more of the initial stuff.  Since release, Solarsplace really did a lot more to it with fixing the bugs we had and adding in a lot more data that's now saved.  He'd be one to ask if he recalls the overview of it.

The FX system in id tech 4 is a great way to create an effect that is essentially a multi-layered effect using any combination of media types you'd like.  While you can typically create the same type of effect using various scripting methods, it's often easier and more efficient to create an FX declaration.

The types of actions you can call within a single FX decl. are lights, particles, models, entities, sounds, decals, and projectiles.

You can set these in DEF entries as well as call them directly in scripts.  An FX declaration is contained within a .fx file placed in your /base/fx directory.

Keywords include(table from iddevnet.com):

delay <time>	How long (in seconds) after starting the effect before this action happens
shake <time> <amplitude> <distance> <falloff> <impulse>	Shake the player around a bit.
ignoreMaster	Don't shake the entity this effect is attached to
random <min>, <max>	A random time added to the delay.
fire <sibling>	Causes the sibling action to happen when this action does. This is a way of synching two random actions.
duration <time>	How long the action lasts before it is killed or restarted
restart <bool>	Set to 1 if the action starts again after the 'duration' has run out
fadeIn <time>	Fade in the RGB of the light or model over <time> seconds
fadeOut <time>	Fade out the light/model. Ignored if fadeIn is set, you can use 2 separate actions (tied together with uselight) if you want a light to fade in and out.
offset <x>, <y>, <z>	Offset from the origin of the entity (or bind point) this action is located at
axis <x>, <y>, <z>	Axis of the model, mutually exclusive with angle
angle <pitch>, <yaw>, <roll>	Alternate way of setting the axis of the model
light <material>, <red>, <green>, <blue>, <radius>	Create a light
noshadows	The light in this effect doesn't cast shadows
attachlight <light>	Attach to external light (a light not defined in the effect) for fading.
attachentity <entity>	Attach to an external entity.
launch <entity>	Launches a projectile.
uselight <sibling>	Modify the light values in a sibling action. Can be used to fade out a light that faded in earlier.
useModel <model>	Modify the model in a sibling action. Can be used to fade out a particle in a sibling.
model <model>	Creates (or fades in) a model
particle <model>	Creates (or fades in) a particle
decal <material>	Applies the specified decal to the ground (and anything else in the area)
size <int>	Size of the decal
trackorigin <bool>	Move around with the entity (vs stationary after spawning)
sound <sndshader>	Start a sound (on any channel)

Example FX entry:

fx fx/velch_death
{

     {
      name "gibpart1"
      delay 0
      duration 3.0
      particle "hex_gib_eoc_01.prt"     
   }
   
     {
      name "velchdecal"
      delay 0
      duration 25
      decal "textures/decals/dsplat2"
      size 96
   }     
}

This a basic 2 part FX used when monster_velch dies.  When the decl is called it spawns two different entities.  The first named "gibpart1" is the dense blood particle you see in the image.  With a 0 delay and 3.0 duration the particle spawns the specified particle immediately and is removed after 3 seconds.

The second part named "velchdecal" is the splatter you see on the floor.  Again we spawn it immediately using a 0 delay but we leave the decal on the ground for a duration of 25 seconds.  We use the material declaration "textures/decals/dsplat2" scaled at 96x96.

In ai_monster_velch.script, we simply call it during "state_killed":

void monster_velch::state_Killed() {
     startFx("fx/velch_death");

   animState( ANIMCHANNEL_TORSO, "Torso_Death", 0 );
   animState( ANIMCHANNEL_LEGS, "Legs_Death", 0 );
   
   waitAction( "dead" );
   hide();
   
   sys.wait( 4 );      //give sounds time to fade out
   stopMove();
   stopSound( SND_CHANNEL_ANY, 0 );
   setState( "state_Dead" );
}

I would love a little community input on a new modwiki.  In early March, 2011 our programmer at the time did an HTML scrape of the modwiki site while it was still up.  I've had it this whole time and just remembered about it not too long ago.

It needs cleaning up as the scrape turned the menus/headers/footers of the wiki template into HTML.  I've spent the last week cleaning out all of the menu/footer stuff and am just about done.  Another week and I can probably have it mostly clean to just the information.  The scrape also did not include image files, but I've been able to collect a lot of them from web.archive.  They don't have all of them, but they have a lot of them and I've been successfully able to get things back in order from the tests I've done.  thankfully, most of the interwiki page linking all works and doesn't need any work.

So my question is what to do with the information that makes it useful to the community again?  I figure there's 3 primary options - HTML site, downloadable PDF or back to a wiki.

The HTML site is the quickest, but crudest.  I could probably have the full site up in another 1-2 weeks and be mostly functional.  There would be broken links and they will have to stay that way.  There wouldn't be any type of community updating, no search feature.  It would essentially just be a cleaned up dump of the old information so it's at least kind of accessible to people.

A PDF would basically be me taking the clean HTML directory and compiling it all in a full PDF to download and use locally.  It's a bit nicer than a static site because you should get search capabilities back through the PDF format.  Updating still wouldn't be sensible and it would remain mostly as-is.

Putting it all back in a wiki would allow for long term maintenance and community updating.  It certainly would be the most robust route as we would gain all of the nice features of a wiki.  It also might take the longest to implement as I'm not familiar at all with getting an HTML site imported into a wiki.  I've read there are scripts and it seems possible but I ultimately have zero practice in it.

The initial package of data contained about 6000 files.  I removed 4000 which were just blank stubs, 1 for each game entity which seems useless at least in current scope.  With 2000 files left, it's been more manageable in terms of cleanup.

I think my ultimate goal would be to have a wiki back, and also the ability to export it all to PDF for a local download(either monthly or quarterly).  However, if that's just not useful for anyone and the community mostly feels like something like that isn't needed I won't waste my time on it.  I'll just dump the HTML site up and we can call it a day.

What's the general desire of the old information?