Well, I just found out why. As it turns out, canOnlyTargetStructures FALSE is totally ignored in the entity file for ships if you have the roletype of AntiModule for the AI to read. If the ship has that, it can only attack structures anyways.

This means nothing for similar roletypes so far, because AntiFighter and Carrier roletypes are being happily used by various battlecruisers at this moment that don't have any anti-fighter weapons or fighters at all. Blargh.

/e I did figure out a sort of workaround for the "Reform Fleet" issue for the AI. That is to make the base unit ranges as high or higher than that of capitals. They seem to auto-acquire that way and it performs better. Still messy, but the best I can do.The Undead... will be harder.

Wow, I didn't realize that. That is rather helpful to know about antimodule frigates and cruisers...

Epiphany!

I was trying to figure out how to solve the Reform Fleet issues for the Undead. Most of their corvettes and frigates are really small, usually <20km. The smallest Anahn ship I have in the game is the Thunderhead, also around 20km. But thunderheads still have insane range. Undead ships have long range as well, but they much prefer super close combat so they can relish in the emotions of mortal minds. I was at a crossroads for this. Because the big ships need big range, but the stupid AI and their bloody "REFORMING FLEET LOL" means over half of their ships, especially the small ones, just flat out weren't attacking anything.

Why not turn all of the UD corvettes and frigates into Strike Craft? That way they'll always engage at any range, there can be tons of them (make them respawn really fast somehow), and it frees up precious frigate slots for bigger ships!

Is there a limit on how many strike craft types you can have? I'm thinking 10-15 types for Undead alone right now. They have a lot of different ship types, many of them very small, perfect to abuse for strike craft. In the new recording conditions there shouldn't be too much more of an overhead from reactivating fighters. I need to do it eventually, anyways. I haven't figured out where to spawn them from, yet - maybe I can make every UD ship a carrier that holds individual squadrons that are all individual ships? Or something like that? I haven't messed with fighters yet. UD ships don't have dedicated Carrier classes, their fighters jump directly into the battlefield from the Abyss. But I can mask all of this in silly cinematic voodoo.

Also, how do Fighter trails work? UD ships don't have engines, so trails don't really work out for them. Actually, I was curious if I could attach trails to missiles instead. I think I'd have to spawn way too many particles to have a solid trail going on for a projectile.

iskatumesk, from what I know the limit for strike craft is FOUR types per ship, and each of the ships can have different strike craft, so with 5 different caps and a carrier frigate that would give a possible 24 different strike craft, but if each of the frigates were to carry strikecraft then assuming you have 9 frigates,9 cruisers & five caps you would have 23 x 4 =92 strikecraft PER race,

the only reason you would not do this is the texture and mesh counts using up all the ram and dumping from over 2gb used.

harpo

Well, they'd be using the same textures as everything else. I'm pretty low (last I checked, <900mb) on the memory limit right now. It's good to know what the exact limits are. Thanks

Fighters don't have any extra limitations in terms of weapons, do they?

I have discovered two new things. I think the triangle limit is actually a vertex limit of 50k. I'm not completely sure, but my updated Leviathan was constantly throwing VERTEX CHECKSUM ERROR for all day until I managed to squeeze the vertexes just below 50k. And by below 50k, I mean below 25k, because the converter always ends up with monstrously more vertexes than it should when it converts regardless of polycount (unoptimized it sometimes claims as high as 140k wtf?!)

The second discovery is that if the converter reports weapon_3 it means you have forgotten to give a hardpoint a unique name back in max and it went up by one... or something. Anyways, those hardpoints didn't have unique names. As much as I wish I could give a ship more than 3 weapons...

Work is in full steam to Episode 1. Today, I started with some generic engine glows for the Anahn.

You'll have to wait for Episode 1 to see their animations in action, but they look pretty decent so far if may say.

I am getting ready to shift all of the UD frigates to fighters. Since no one has said anything about weapon limitations on fighters I just assume they'll work 1:1 with all 3 weapons. Unfortunately, they'll have to use the dynamic fighter AI, which might make a mess of things.

The Hatred is fully rigged and ready to be put in.

The hangars for the various larger Undead ships just float off in nowhere. Should be amusing to watch. I wonder if I can have the fighters make a particle effect when they spawn?

That last Anahn ship looks really sweet.

Wow nice texture/skin job there O_o

Thanks bro! Although it's not really skinned or textured. I just threw on a tiling metal plating texture. That's about all I can do. If I could at least give it smoothing akin to what I can do in max I'd be content...

Actually, if I could get some of these models to convert at all I might already be close to the recording phase of the project. The last two days nonstop have been put into trying to rid ships of the FAILED VERTEX CHECKSUM error. This error seems to be ridiculously broad and extremely hard to identify. Ugh.. I spent over 15 hours yesterday alone working on just one ship trying to rid it of those errors. I expect today to be the same.

Come on. If I can throw a ship into the game with 50-sided polygons and overlapping meshes all over the place without a single error, why does this one give me an error even if I manually weld and destroy everything that is so much as bent a funny way?

Wow, nice looking ship, good work there iskatuMesk.

Okay, I finally "fixed" the Ruin's FAILED VERTEX CHECKSUM errors. Checklist-

Re-apply the tangent to the exact same thing it's already pointing to in XSI. This solves 3 of the errors.

Randomly collapse over half the mesh. This fixes a few more. Also utterly destroys the model.

Remove two vertexes attached to a single edge that somehow refused to get welded. Fixes last two.

This took me over 20 hours to figure. All to fix a beam weapon hardpoint that STILL for some reason fires through the hull. Ugh!

I'm usually a patient person when it comes to modding. I've dealt with Homeworld 2 and Supreme Commander, both utterly wretched games in their own right. But sins really knows how to drive me into a blood-boiled rampage of baby-punching liver-ripping table-crunching homicide. It doesn't help that it's this exact kind of precision work that antagonizes my advanced CTS to the point of becoming unbearably painful.

Come on, sins. Max says the hardpoint is facing in the right direction. XSI says it's facing in the right direction. The .mesh says it's facing in the right direction! So why are you firing through the hull to the other side with it, and not attacking right-side targets??? What have I missed that is so stupidly obvious yet not? The left beam hardpoint works fine... it doesn't shoot to the right side... so why do you refuse to work in kind?

Nope... not that...

Not that either...

...

Sigh.

I am starting to think that ConvertXSI just doesn't like XSI 2010. But it's not like I can use an older version. I run on Windows 7. Well, back to work I guess. I still have two dozen plus ships to model and get into the game before Episode 1 is ready to start the real work - making the video.

/edit

A friend sent me a base fighter model I have been mangling into second-generation Anahn fighters. Here's the first three classifications, all are WIP.

From left to right -

Chimera Mark 2 Interceptor -

The lightest of the Chimera MK2 variants, armed with high-velocity Gauss cannons and nuke-launching snub cannons. The goal of the Interceptor is to swoop in with a frontloaded attack and destroy other strike craft, and then escape. It is equipped with minimal armor. Nuclear weaponry is generally incapable of damaging Tiran plating present on even the smallest Anahn craft, but the EM interference can disrupt older communications and navigation. They are fired in a spray preluding an attack run.

Chimera Mark 2 Fighter -

Standard Fighter variant. Heavier Tiran plating than the Interceptor, and exchanges Gauss cannons for Powerguns that can fire either liquid Tiran, Tiran Slugs, or explosive DU shells. As an idea of the kind of damage this thing can do, its Powerguns were originally intended to destroy installations hidden kilometers deep underground planetside. They are effective against capital plating but mostly intended for general dogfighting. The snub cannons from the Interceptor variant remain.

Chimera Mark 2 MRF -

Multi-role Fighters by the Anahn classification are those fighters equipped with multi-variable weaponry. Which is to say, they are intended to fight both capital ships and fighters. They are typically more heavily armored than Fighters and Interceptors, larger, slower, and have turreted weaponry as well. This is the most incomplete of the models. It is currently equipped with Powerguns rated higher than the Fighter variant that fire Slugs exclusively as well as a second weapon set that usually fires shaped Fusion shells, designed to trigger fusion reactions with impure Tiran plating, iron, and other non-elemental metals. Even if they don't trigger fusion the energy released in a localized region outscales that of standard nuclear weaponry. True energy weaponry remains difficult enough to make that most Chimera MK2 variants are void of it, but these shells are generally easy to create using Tiran power. The side effect is that the fighter itself is highly explosive should something hit it hot enough to react (other Fusion shells).

Chimera MK2s originated as surface craft, but were adapted to space combat when the majority of planets in Anahn space were rendered dust by shelling or radiation. They retain maneuverability but their structure has changed little. They are still capable of entering and leaving atmospheres of most planets.

"Hatred is vast, yet delicate. So gentle are the tides to greater futures... malice, despair, hysteria. Yet so easy it is to hate. Hate is eternal. Hate outlasts all other primal instincts of mortals."

"In glory comes ruin, and in ruin comes destruction so absolute thee shall never grant glory harbor in thy heart ever again."

Good reading material, and some yummy pics.

So, my mic of 6-7 years finally had enough and decided to start breaking on me. I was forced to purchase a new microphone, settling on the Blue Yeti. It cost me about $166. The quality is significantly higher than my old $50 mic and it has much more utility. Ultimately, this will benefit Black Sun directly since I am voice acting much of Episode 1.

A test run of the Fear with this new mic. It is likely this take will be used in the actual video.

http://www.gameproc.com/meskstuff/BlackSun/FEAR-A3-newmictest.ogg

Whelp, some updates are in order I suppose.

I am taking an extended break from my casting to catch up on my LP work. I've been fairly busy on the video front so very little has been done in actual work to progressing Black Sun itself. However, some notable things regardless.

- I feel I near understanding the pinnacle of what Sins' particle editor is capable of doing. As some things that work in the particle editor don't work ingame, or vis versa, and considering the editor's limitedness, all it falls down to is creativity and major abuse of textures. I began a ripping project to acquire a vast quantity of particle textures. It is only a matter of time until I am able to create every effect I need for this project.

- I have figured out a way to create basey sounds not unlike those in the new transformer movies. These will be a critical step in creating UD explosion sound effects I previous could only dream of making. Sound effects are an exceedingly important part of any mod, just as important as graphics or gameplay. And, for Black Sun, sounds are even more important. With sounds I must fill in the tremendous void left behind by being unable to UV or texture. I need to somehow create that extra level of immersion and power.

- I have many ships modeled for the project that are not yet rigged. However, it is always the ConvertXSI.exe and its vague errors that eats the most time out of introducing content. It takes me maybe 5-10 hours on a good beat to make a ship, and up to weeks nonstop of work to get it to convert if the .exe is feeling exceptionally angsty. This destroys my motivation to work on the project, and my issues with the Ruin, which I left still being unable to fix the unusual hardpoint issue, are what killed my last production string. I loathe the prospect of trying to find extremely vague errors in my newer meshes. Enough to not even attempt them. Thus the project goes nowhere.

To top it all off, I still have no idea why the smoothing for the models looks so terrible. It's like there's smoothing groups applied, so all of the hard edges are really soft, and the lighting is reversed. It looks terrible. Maybe if sins used a real lighting engine this wouldn't happen, but I have a feeling I am missing something and that this is avoidable. I wish there was a max plugin that didn't take 10 hours to export models with. Or that the damn models just utilized max's smoothing groups.

I dug up the carcass of the old LTX-77 I made years ago, based on the SU-47, to finally create the next generation of Anahn and Undead equivalent fighter models that will be necessary for this project...

The ancient Valkyrie, one of my first Anahn models and the first ship to be showed in the Homeworld 2 edition of this project, was revised a bit as well...

And yet, even though these Undead meshes are the lowest poly of all the ships put into the game, they are by far the worst to try to troubleshoot. Anything about them may make ConvertXSI mad. A face bent the wrong way, a T vertex stretched oh so perfectly... and yet the ngons never give any problems.

Above all...

Black Sun was started to get me writing again. In the last day I managed to break past the part of the novel that held me back for one and a half years. Whether I am able to continue writing I don't know yet, but in that sense Black Sun's ultimate goal has succeeded. Even then, I am not yet ready to let Episode 1 die. I have put far, far too many sleepless, rage-flooded nights smashing my face into the converter to let all the work be for nothing. But I am close to giving up.

I have the framework for episode 1 laid out and a clear idea of where I want to go. CTS still hurts, but I am going to push for it anyways.

During Black Sun's progress I have had two independent game comission offers and have turned them both down. I told them, "Sorry, I don't make other people's dreams. I make my own dreams. Money means nothing to me."

Don't give up, Iskatu!

I agree that you have put enormous amounts of work into this project, keep going. If you have lost interest, take a break. Do something else. Come back to this later. Don't throw it away.

-Particle forge. Any questions can be directed to me, as I feel that I have surpassed the pinnacle of PF knowledge, having 3 years of PF know-how under my belt.

-What do you use to make your sounds? I will need to make some for my project at some point.

-Concerning smoothing, try to use an airbrush to darken the textures on the inside of creases and folds. That REALLY makes them more visible and nicer-looking. Conversely, try to lighten sharp corners with an airbrush, that(I haven't tried it.) I guess would also make them look a little smoother? Experiment around with stuff. Your problems may be with the sins engine, but you could also complicate the textures a little more for a nicer-looking ship.

I am willing to help with anything.

If you want, I made an annotated guide to Particle Forge for -Ue_Carbon, I could post it for you.

Nevermind, I will post it anyways.

Have fun!

PARTICLE FORGE ANNOTATED GUIDE:

Particle Forge, the easiest thing to use to make particle effects. EVER.

I shall start from the beginning, in the off chance that you are doing it wrong.

1, download particle forge from the downloads section on the Sins site. (If you fail this, I will shoot myself)

2, unzip it on to your desktop. DO NOT PUT IT INTO YOUR SINS DIRECTORY!

3, copy the following from your Sins directory into the Particle Forge 3 folder: Particle, textures, textureanimations, pipeline effects, and mesh.

4, go into the Entrenchment folder and copy and merge the contents of the appropriate(above) Entrenchment folders.

5, repeat with Diplomacy.

6, copy the 3d3fx.dll or something like that, (I am doing this from memory, so don't sue me) from the main sins directory into the PF 3 folder.

7, start particle forge.

I have copied the contents of the sins wiki in order to better remember the things contained therein. I shall annotate these things for better understandings.

You should see a black screen in the middle with two axes, green and red. Green is y, and red is x.

Drag the window to the right until you see the control window.

Zoom out a little with the scroll wheel(There is no other way to zoom in/out) and rotate the screen with the right mouse button. You should see the blue, red, and green axes. Green = y, red = x, and blue = z. Z aligns itself with the way the particle effect is facing, e.g., a muzzle will face along the Z axis.

Right click the thing that says emitter and add a new point-type emitter.

You should see this in the pane: (my notes will look like this in parenthesis)

It's a good idea to know what you want to make beforehand, and practice definitely makes perfect, so good luck.

• Design
  • Enabled: Provides a quick way to disable an emitter without erasing it. (turns on and off the emitter)
  • Name: Use this to rename the emitter for clarity. (Name your emitters. A good way to keep track of what your emitters are. Do not name them things like Point, point, ring, Ring, Sphere, sphere. You will get very peculiar errors if you do. (Bailknight did it, bad Bailknight))
  • Type: Cannot be changed. Displays whether the emitter is a point, sphere, or ring. (Stupid, really, you shouldn't care about this.)

• Emitter
  • EmitCount.IsInfinite: Allows the emitter to ignore EmitCount.Max & emit an unlimited number of particles. (True or false, do you want this emitter to emit an infinite number of particles as long as it is alive?)
  • EmitCount.Max: Sets the maximum number of particles to emit. (If the above is false, then you can have a set number of particles.)
  • ImitIntervals.HasInterval: Enables the following ImitIntervals values, allowing particle creation in periodic bursts. (This is very complicated, and does not seem as straightforward as it looks. True or false, do you want your emitter to release particles in spurts?)
  • ImitIntervals.RunDuration: Number of seconds to emit particles. (If you want to use it, and the above is false, how long do you want each interval to emit particles for? This is dependent on the emitRate and the emitCount)
  • ImitIntervals.WaitDuration: Number of seconds to wait before emitting particles again. (Just as it says, how long do you want it to wait in between spurts?)
  • EmitRate: Number of particles emitted per second. (Exactly as it sounds. If you have an infinite emitcount, it will just release whatever number you put in here, e.g. 10 particles per sec, for the lifetime of the emitter. If you have a set emitcount, it will release the number of particles you have set for the amount of time you tell it. e.g. 10 particles per sec with 100 particles will last for 10 secs)
  • Position: Position of the emitter's center in x,y,z coordinates. (in that order, x,y,z, the origin of the emitter is placed on the axes. Negative to move it negatively along those axes)
  • Rotation.Cross: ? (These don't ever work the way I want them to, but they theoretically rotate around different rotational axes. Cross rotates the emitter around the Z? I think.)
  • Rotation.Forward: ? (Rotates the emitter around the Y?)
  • Rotation.Up: ? (Rotates the emitter around the X? Type in 180 in one of the above in order to flip your emitter around.)
  • Texture.Primary: The texture file that gives the particle its appearance. (Get a .tga or .dds file and put it in. The emitter will emit particles of this texture.)
  • Texture.Secondary: Secondary texture file, used only when the GsExhaust shader is selected. (As it says, with the pipeline effect gsExhaust, this secondary texture will be tiled over the previous texture.)
  • TextureAnimation.FPS: If a texture animation is selected below, the number of frames per second the animation is played at. (Don't mess with this unless you want to use a Textureanim. Set this to 0 for static textureanimations)
  • TextureAnimation.Name: A texture animation file. (The name of the .textureanimation file to use)
  • TextureAnimation.SpawnType: If a texture animation is selected above, whether it plays sequentially from the first frame (FirstFrame), sequentially from a random start frame (SequentialFrames), or randomly from a random start frame (RandomFrames). ((Or is FirstFrame playing randomly from the first frame & SequentialFrames playing sequentially from the first frame??? Need clarification!)) (See, this is confusing, because the Wiki don't know what they are doing and they use parenthesis to declare it. The last statement was not mine. This just defines whether the texanim plays from the first frame, a random frame, or sequential frames. First frame plays the slides in order at the above speed. Random plays them without order at the above speed. Sequential frames plays them in order, but starts on sequential frames from previous particles. e.g. the first particle will start and play on frame 1, the second on frame 2, etc.)
  • Time.Duration: Number of seconds the emitter lasts. (This will cut your emitter short)
  • Time.IsInfinite: Allows the emitter to ignore Time.Duration and last forever. (Do you want it to be cut short? True or false)
  • Time.Start: Number of seconds to delay the start of the emitter. (exactly as they said it. If you want an emitter to wait 5 seconds before beginning, put it here.)
• The following differ between emitter types.
  

  • Point

    • Emitter:Point
      • AngleVariance: How many degrees a particle's velocity can vary from the emitter's forward direction. (How the particle's direction is restricted. To lock a particle's direction, set this to 0. e.g. if you want a bullet or a stream of particles)

     

    Sphere

    • Emitter:Sphere
      • RadiusX/Y/Z - Min/+ Max: The minimum and maximum radius in which particles will spawn. Using equal minimums and maximums forms a thin shell, while using minimums of 0 forms a full sphere. (Yep)
      • SpawnAngle.Latitudinal/Longitudinal - Min/+ Max: Controls in what angles of the sphere particles will spawn. Values in degrees. This is where you would form, for example, a half-sphere by restricting one set to 0 through 180 degrees, while permitting the other set to be a full 0 through 360. (Yep)
      • Speed.AzimuthalTangential/PolarTangential: Gives particles velocity away from the center of the sphere, on the equatorial (azimuthal) or polar planes. (I wish that these had more randomness. But they do what they say.)

     

    Ring

    • Emitter:Ring
      • RadiusX/Y - Min/+ Max: The X & Y radii allow creation of rings that have a wider or longer radius -- ovals. The Min and Max specify the inner & outer rings that the particles will spawn between. (yep.)
      • ScaleStartSpeedsByRadius: (Even I, the great Krdax, have no idea what the heck this does.)
      • SpawnAngle - Min/+ Max: Degrees between which particles can spawn. (Kinda like the sphere spawn angle and the angle variance)
      • SpawnControl.IsAngleRandom: (Sets the spawn angle to random or organized. If false, the particles will spawn around the ring in order along a number of points specified below.)
      • SpawnControl.NonRandomLoopParticleCount: (Set this to define the level of detail that you want your controlled ring to have.)
      • SpawnDirectionIsParallelToPlane: (Set this to the non-default if you want your particle directions to not follow an outward force from the ring origin.)
      • SpawnHeight - Min/+ Max: Used to turn the ring into a cylinder of specified (Max minus Min) length. (yep)
      • Speed.AlongNormal/Tangent: Gives particles velocity away from the center of the ring, either in the direction normal (perpendicular) or tangent (same) to the ring's plane. (yep.)

     

• Particle
  • Billboard.Anchor: Controls how the 2D particles are anchored. (Wow, this is one of the most important things. No description? There are many different choices, but it anchors the particles by the selection, center is default, for example, if I set this to bottom right corner, it would emit and rotate the particles by that corner)
  • Billboard.Facing: Controls the direction the 2D particles face. (Even more important, three choices, Parallel, Perpendicular and Camera. Parallel locks the texture onto the 3D plane, for example, puts the texture down flat. Perpendicular locks the 2D particle along one axis, but leaves it camera-facing for the rest. This is used for bullets, sparks, etc. that require a specific direction. The default, camera, locks the particle to always follow the camera.)
  • Color: The color of the particle in RGB. This will also filter the colors of the primary texture. (filters the first texture by the mentioned color. Only the first, not the second. Pick the color that you want)
  • IsAttachedToEmitter: Uncertain of the importance of this parameter. (Wow, this one is very important. It tells sins whether or not the particle is attached to the emitter. For example, smoke in bailknight's graphical mod, or a missile trail or something. If the emitter is moving in Sins space, will all of the particles move at the same relative speed?)
  • Lifetime: Number of seconds each particle lasts. (Starts once emitted, each particle lasts for the specified time.)
  • Mass: ? Probably only needed when using Force affectors. (Yep.)
  • Rotation.Direction: Controls which direction(s) the particle can rotate. (Rotates the individual particle without regards to orientation or emitter rotation.)
  • Rotation.Enabled: Enables or disables rotation. (Do you want rotation? true or false)
  • Rotation.Speed - Min and Rotation.Speed + Max: Particles will rotate at a speed between the minimum and maximum. Values in degrees per second. (exactly)
  • Rotation.Start - Min and Rotation.Start + Max: Particles will start out rotated at an angle between the minimum and maximum. Values in degrees. (This will define the starting rotation of the particle. Set the min to 0 and the max to 360 if you want randomly rotated particles. Don't touch this if your billboard is set to perpendicular as it will mess it up.)
  • Shader: How the particle is rendered. In most cases, leave it at ParticleAdditive. To prevent particles from being influenced by the background light, use ParticleNotAdditive. When using non-additive rendering, make sure the texture uses transparency or you will end up with a rectangular particle. To achieve a higher-contrast "glowy" particle, you can use GsExhaust. Note that this shader requires a secondary texture and diminishes the filtering effect of the Color value above. (Exactly. ParticleAdditive is the default, and will not stack alpha values, but will ignore black and the darker the texture, the darker the particle. ParticleNotAdditive makes the particle display black and gray and things. It will display the entire texture, but it will not stack. The GSExhaust makes an additive particle with the secondary texture. If you want this emitter to emit meshes, set this to ParticleMeshOld)
  • Size - Width and Size + Height: The dimensions of the 2D particle. (The size in sins units. I think...)
  • Speed Linear - Min and Speed Linear + Max: Particles will spawn with a velocity between the minimum and maximum (relative to the emitter). (If you want random velocity, greatly vary your values.)

• ParticleMesh data: Used when a particle effect also consists of a mesh, such as in a missile travel effect.
  • FileName: Name of the .mesh file. (If you set the Shader to particleMeshOld, you can select a mesh to emit.)
  • RotationAxis: (Advanced setting, don't mess with this unless you really know what you are getting in to. It changes how the mesh rotates in relation to its individual axis.)
  • RotationAxisType: (This changes its relative axis to something else, another advanced setting.)

 And that is emitters. Once you have emitters, you can assign things to them called affectors. Affectors will apply forces or fade particles. You must attach an emitter to an affector in order for it to effect it. Right click on the affectors to attach emitters.

I shall explain.

The properties below are present in all affector types.

• Design
  • Enabled: Provides a quick way to disable an affector without erasing it. (You can turn them on and off for debug purposes.)
  • Name: Use this to rename the affector for clarity. (useless for affectors)
  • Type: Cannot be changed. Displays which of the below types the affector is. (duh.)
• Affector
  • Attached: (I believe this only effects certain affectors, but it refers to the above isAttached modifier.)
    
  • OnlyAfter.Enabled: Enables or disables OnlyAfter.Time. (Do you want the particle effect to wait before applying this affector? true or false)
  • OnlyAfter.Time: Start affecting particles after they are this many seconds old. (Exactly as it appears.)
  • OnlyBefore.Enabled: Enables or disables OnlyBefore.Time. (Do you want the affector to be cut short? true or false)
  • OnlyBefore.Time: Stop affecting particles after they are this many seconds old. (Yep)
  • Time.Duration: How many seconds the affector lasts. (The duration of the affector. It's not redundant, see below.)
  • Time.IsInfinite: Ignores Time.Duration if set to True. (Default true)
  • Time.Start: Number of seconds to delay the start of the affector. (Delays the actual start of the affector. The difference between this and the onlyafter and the onlybefore modifiers is that the time.start is relative to the particle effect time, and the onlyafter and onlybefore are relative to the affected particle's lifetime.)

 These are unique to each type of affector.

Color Oscillator (Changes the color and/or alpha of the particle relative to its spawn and lifetime, this overrules fade.)

• Affector:ColorOscillator
  • Alpha.Begin/End: Opacity values to cycle between. Values can range from 1.00 to 0.00. (The transparency from start of the cycle to finish)
  • Color.Begin/End: Colors to cycle between in RGB. (Color from start of the cycle to finish)
  • TransitionPeriod: Seconds for one cycle. (The amount of seconds in one cycle.)

Drag (drags on particle movement relative to the particle effect.)

• Affector:Drag
  • DragCoefficient: (How much to drag by. 1 is complete stop, 0.2 is a little drag)
    

Fade (One of the more important affectors, fades a particle in or out at its spawn and/or death)

• Affector:Fade
  • FadeIn.Enabled: Enables or disables FadeIn.Time. (Do you want it to fade in?)
  • FadeIn.Time: Seconds it takes the particle to fade in. This value can be larger than the Lifetime value. (yep)
  • FadeOut.Enabled: Enables or disables FadeOut.Time. (Do you want it to fade out?)
  • FadeOut.Time: Seconds it takes the particle to fade out. Uses the particle's end of lifetime as the end of the fade, NOT the start of the fade. This value can be larger than the Lifetime value. (Yep)

Jitter (Random noise generation on a particle's individual movement)

• Affector:Jitter
  • Force: (How much jitter)
    
  • UseCommonForceDirection: (Do you want all particles to jitter together(true)? Or separately?(false))
    

Kill Particles Near Point (Particles entering the threshold are instantly removed)

• Affector:KillParticlesNearPoint
  • DistanceThreshold: (The distance from the origin that affected particles are removed)
    
  • Point: (Where the origin of the threshold is.)
    

Linear Force In Direction (Forces particles in the direction specified.(Useful for particles that need to be moved in a strange direction that they are not facing.))

• Affector:LinearForceInDirection
  • Direction: (The direction to apply the force)
    
  • Force - Min/+ Max: (The force to apply. Apparently it is not random.)
    

Linear Force To Point (Pulls affected particles in to the point with the specified force)

• Affector:LinearForceToPoint
  • Force - Min/+ Max: (The amount of force to apply. Can be negative to force particles away.)
    
  • Point: (The origin of the pull or push.)
    

Linear Inflate (An affector that effects the size of particles at a constant rate.)

• Affector:LinearInflate
  • InflateRate.Height/Width: Increase of the particle's dimensions in distance-units per second. To decrease size, use negative values. (Exactly as it appears.)

Linear Bounded Inflate (It doesn't work)

• Affector:LinearBoundedInflate
  • Height/Width - Min/+ Max: ???

Rotate About Axis (Rotates attached particles around a specified ring)

• Affector:RotateAboutAxis
  • Axis: (the axis that the ring is oriented to.)
    
  • Origin: (the origin of the ring.)
    
  • Radius: (The radius of the ring.)
    
  • Speed: (The speed at which particles will gather/rotate around the ring. For some reason the speed is proportional to the size of the radius. Beware, 1000 speed could crash your computer if the radius is too small.)
    

Size Oscillator (Cycles the size of the particle between the values. Pulsating particles. This will override linearinflate affector)

• Affector:SizeOscillator
  • SizeX/Y.Begin/End: Particle dimensions to cycle between. (Specify the start size and the end size of each cycle)
  • TransitionPeriod: Seconds in one cycle. (yep)

Global Properties (These are accessed by selecting global properties on the side pane)

• HasInfiniteTime: If true, the particle lasts forever. If false, the particle effect dies after TotalLifeTime seconds. (exactly)
• Length: Only needed for long weapon travel effects. Used to kill the particle when it collides at the given length (rather than the center axis). If left '0' for long weapon projectile effects, the projectile will look like it is going through the target! Value needed is the distance from the center axis to the impact-end of the particle. (used for impact boxes)
• TotalLifeTime: Number of seconds the particle effect lasts. Ignored if HasInfiniteTime is true. (yep.)

PM for specific questions.

As a special note, the key f5 will make your life easy. f5 restarts the particle effect.

I've used the particle editor for around two years or so, not as long but I know my way around - I'll definitely go over that when I wake up, though.

Airbrush? My textures are just tiled, I can't texture or UV so yeah - I think the tangents are to blame for the unusual edge lighting. I just don't know how to make them "unsmooth". In max, I apply a smoothing modifier and turn off smoothing groups entirely through that. That gives the model hard, metallic edges. But smoothing groups don't transition to XSI, and I have yet to figure out, even after going through several topics in this forum, how to give them hard edges in XSI without being able to make my own UV's. With smoothing "on", all of the hard edges and details are lost and the lighting really does weird stuff.

For sounds, I use Audition 1.5 and some directx plugins + some ancient cooledit plugins. I have been using that and the ancestors for around 12 years now. Same program I edit my voice in to produce things like the Fear's voice, posted above.

Cooledit? Intriguing. I'd suggest taking a look at NCH's WavePad Sound Editor, which is free for personal usage. It's a fairly well functional thing, have used it for some non-Sins editing. Only thing is though you'll have to (after the first 30 days) convert to ogg externally, using something akin to dBpoweramp or Foobar2000.

Audition can convert to ogg fine with a plugin, so that's not much of a concern. I'll have to look up WavePad.

Alright, I've laid out the entire framework for Part 1 of the video. All that remains really is the CGI and ingame stuff. I did an assessment of my ingame and to be converted to ingame assets and I think I can start recording rebellion material in two weeks or so if I can at least somewhat focus on my work. As focusing is extremely hard for me, I am now expecting Episode 1 in its entirety to take until the end of 2011 to finish. And that's being modest at best. Chances are I will hit another downspiral of depression and go for several more months with zero activity. If this happens I will probably have to drop the project as it is simply taking too long and becoming a burden.

I have cut the Warlord faction down to 3 unique vessels and the fighters that need to be finished. This, comprised with generalized classes that already exist, should be enough for the Warlord recordings as they are not very long. Of course, each ship needs to have unique particles and SFX, but that's the easy part.

Following this I have a few non-fighter Anahn ships to rig hardpoints and then convert. I have only 2-3 Undead ships ready to rig and convert and really need to pick up the pace on that race to get them done. When these are both done, with SFX and particles, I have enough to record all of Part 1's material. Then I must model the rest of the ships and repeat with those to fill the holes in part 2. That's the easy part.

The hard part is that I need to figure out how to make the Undead material as I envision it within 3ds max for some pre-rendered stuff. I spent time on this on many occassions but I am simply too ignorant to figure out materials. During my next bump with the task I will install Vray and try to find a vray material suitable for the task. Following this I have to use blob meshes, but I already have some experience in blob meshes from working with Age of Wonders 2 sprites in an older project.

The hardest part of all of part 1 of Episode 1 will be the CGI. I need someone to create After Effects material for it. I know a guy, but I somewhat doubt he will be able to create what I need before I finish all of the above work, simply because of past experiences. This doesn't include text and stuff I also need,  but it is possible I can make a public requisition for this specific material on Team Liquid.

The voice work for Episode 1 is almost entirely done, and I have spent a huge amount of time compositing stock footage and random garbage into a workable foundation. All that remains is one or two more Fear recordings and, the toughest one, the Prince of Blood's recordings. I'll worry about part 2 of the project when part 1 is done. I foresee part 2 being easier because it will be almost entirely ingame recordings.

To recap, stuff that is done;

- A sizable chunk of Anahn and Undead ships are already ingame, with SFX and particles functioning at an acceptable level of quality. Will be improved over time. Everything you saw in Episode 0 has been improved upon, especially particles and sounds.

- I have a bloodbath-style testing map and have rigged ingame costs to encourage huge fleet battles, but it works very limitedly due to the passiveness of the AI. I may need to pursue something far more complicated to get the recordings I need.

- A number of Anahn ships are modeled but not rigged for ingame use. Most need touching up.

- A handful of Undead ships are modeled and ready to be rigged/put into the game. This includes the Spirestorm, probably the most complicated of all Undead ships to be added minus the Incubus, but the Incubus is not likely to make it in.

- 3-4 Xy`Kranasha ships are modelled but not finished. One is ingame and semi-functional, the rest currently ingame need revision in some way.

- A single DyiithJhinn ship is modelled but may not make it in as a race.

- Two Templar ships are in conceptual phases.

- I have hundreds of base sound effects created for later mixing and remastering.

- I have spent months formulating and rebuilding the video framework for part 1, figuring out exactly what it is I want the video to be like and look like. At this point I cannot remove anything further, thus it is nearly finished.

Stuff that needs to be done -

The following ships need to be rigged, put into the game, given unique sounds and particles.

^ Anahn Garedexx-Class Destroyer (Warlord)

^ Anahn Razzador-Class Battleship (Warlord)

^ Anahn Patriarch-Class Dreadnaught

^ Anahn Chimera MK2's

^ Anahn Sonsora Battleship

^ Undead Tyranny

UD Spirestorm, shown in previous posts.

+ part 2 stuff.

+ CGI for video.

Things I have no control over -

- I expect to spend a week a piece converting models due to vague errors from ConvertXSI. Every ship I avoid errors on is celebrated with a shot of a non-alcoholic beverage, like anti-freeze.

- I cannot UV or texture so no model is textured.

- The smoothing on every single model is broken. I plan to try to dick around with tangents in XSI but expect failure.

- I don't know anything about video graphics so making the CGI is extraordinarily dependent on what I can scrape up from my contacts. I absolutely hate relying on other people but I can't do the after effects work needed for some of the scenes and I cannot stand the program itself. If I absolutely must, I'll do the cheap way out and make renders out of 3ds max using my garbage AO setup. But I'd rather this not look terrible, so that's an absolute last resort.

I was going to make a second dev log but no one cares about that kind of thing, so I'll save my video editing energy for unrelated projects.

Best regards, I'll keep you updated.

i love the models you make dude

they are all so detailed and perfect 

keep up the fantastic work

Yeah, keep going! I really want to play with this universe.

I fear there won't be much playing as I abandoned the gameplay elements of this project quite a time ago. The game just can't support what I want to do, so I am focusing entirely on Episode 1, which is a two-part video. When that is done I am dropping the project and moving on to the UDK.

Gimme the project once you are done. I want to see if I can make something out of it.

Your name will be sung in all of the future Sins praises.

Yeah would be a shame to let all that awesome stuff go to waste.