Fx Simple Test Environment: A straightforward application of triggers and events to build a simple test environment for .fx effects.
Edit the TestDevice.dp to set the .fx you want to test, start CFS2 and enter the Fx Test mission (day or night): when you start your engine, the chosen .fx will fire just in front of you.
To observe how wind influences the .fx effect, missions provide a 8-12 Kn surface wind blowing from NW.
FxTest-1.0.zip, 5 kb.

Here is an example of use (a test of my phosphorus fires, the engine start message is in Italian, sorry):

Building CFS2 mods is anything but software development. To ideate, implement and release a mod I go through the following phases:

1. inception; have the idea, draw a first draft of the mod requirements;
2. experimentation; be sure of the mod feasibility; carry out experiments, request help through forums;
3. design; define how the mod has to be implemented, which files have to be added or modified, which solutions have to be used;
4. code; write down the first version of the mod files; also build the test environment, generally one or more missions to test the mod;
5. test & debug; install the mod on your system, test, rework, test, rework, system crash, test, rework, ... eventually the mod will work;
6. test & tune; same as above, but the goal is to fine tune the look and the behavior of the mod; less system crashes, hopefully;
7. packaging; write the ReadMe, build the zip, prepare the web page;
8. final test; test the installation, check that ReadMe is correct; check the web page;
9. deliver; upload all, report to the forums, mission accomplished!

The mod software process is a rather classic waterfall with three highly cyclic and evolutive inner phases: 2, 5, and 6. I distinguish between phases 5 and 6 because exiting phase 5 is the true turning point of the project. The whole process is iterated to build a new release of the mod. In a CMM-like evaluation of process enaction, I will rate something less than level 2: the necessary discipline is in place to repeat the process on similar projects, but I don't keep track of costs and schedule (well ... it's a hobby!).

I really enjoy the overall process. But, as all projects, building a mod follows the Conradi rule: each project requires 10% inspiration and 90% transpiration. For mods, most of the 10% inspiration is in the very first phases (and often inspiration is by someone else) and results of experiments are sometimes frustrating. Moreover, test, debugging and tuning are quite boring and so are the final phases devoted to packaging and delivery. So I have many ongoing projects, when I'm fed up with one I move to another and when I'm really fed up ... I dive in some hard dogfight!

Ship smokes: less particles for more efficient smokestacks, different size smokestacks, diesel smoke for submarines and Japanese barges (on phase 2).

Debris 3.0: with more debris and burning oil (on phase 2).

Effects working in multiplay: effects attched to objects as [EXTRA] don't work in multiplay. I tryed to define them as 0% damage, but it doesn't work. Suggestions are welcome.

Bengal lights: after many trials and a discussion with Nibbio, the "light" parameter doesn't have effect on all textures, in particular, it doesn't on ground or building textures. So, my experiments to use this parameter to model the light of a Bengal rocket failed and I stopped the project.

LLights 2.0: same problem as Bengal lights.