Lancersreactor

Yeah, that was what got me started- if FLModel Tool is able to reshape some ALEs, then that tells us something. FLModel tool can´t do its thing without the proper data structures being there in the first place. The fact that it doesn´t work on some ALEs should be a good clue as to where they´re differing... and the fact that there are files and structures we can´t see with UTF Edit explains a lot about why ALEs have always seemed rather odd to me- I´ve been looking at them, and some of them have obvious animation instructions in them, and some of them don´t. Things like engines don´t even register a TXM, so they must be using something else... probably a DX8 edge-blend with some sort´ve simple non-shaded polys serving as the "flames". As for me... I´m going to start some practical experiments to determine which ALEs can be resized with FLModel Tool... if nothing else, this adds the very interesting idea of using resized "engine flames" as small weapon shots, which I may very well use in place of the beams in WOS B2... and if I could resize some of the other "beamlike" ALEs, that´d be super...

After taking a long look... there are several things confusing me, that perhaps Anton´s hex-code spelunking might´ve uncovered. I´ve been looking about with UTF Edit, so this may seem silly, but: 1. Inside many of the TXM files, you can find multiple LODs of each texture. Some have 8, some have 6 (!). How´re these called, and how does an ALE get the appropriate number? 2. ALEs must have <i>something </i> in them referring to the specific filename in the TXM... otherwise, how the heck would an ALE get the right file out´ve a TXM that contains 6 different textures? Whatever that is, it isn´t showing up in UTF edit, unless it´s a number... because that´s all the data structures that I can see are. 3. I can now confirm that engine glows do NOT need a TXM reference in their ALE ini script to function just fine. The animation of their parts (what causes that gentle &quot;wobble&quot<img src=smilies/icon_smile_wink.gif width=15 height=15 border=0 align=middle> is obviously in the ALE itself. 4. The anim_rects... grrr... I was gonna mess with that earlier, and never got around to it. I need to sleep for a bit, after which I´ll see if I can´t figure that out for good and all, and figure out what frame_rects do.

Mephistopheles is totally right, look in FX/effect_types.ini But these aren´t telling us the LOD, they only refer to other things with keywords... I searched a bit for a file containing this... No luck for now. Btw, has anyone looked in the &quot;alchemy.dll&quot; file in the EXE folder? Maybe we could get something like an algorithm from there? The version tells us that DA developped the Alchemy by themselves : &quot;Alchemy Effect Engine&quot; &quot;Digital Anvil Alchemy Effects System&quot; &quot;Way cool particle and other effects engine&quot; This is the dll acting as the .ale files decoder for sure. Edited by - FriendlyFire on 1/30/2005 7:39:51 AM

OK, I´ve taken a look at frame_rects: If you look at the structure, we´re talking about a big integer array: 0 0 1065353216 1048576000 1061158912 0 1048576000 1065353216 1056964608 1061158912 0 1056964608 1065353216 1061158912 1061158912 0 1061158912 1065353216 1065353216 1061158912 0 0 1061158912 1048576000 1056964608 0 1048576000 1061158912 1056964608 1056964608 0 1056964608 1061158912 1061158912 1056964608 0 1061158912 1061158912 1065353216 1056964608 0 0 1056964608 1048576000 1048576000 0 1048576000 1056964608 1056964608 1048576000 0 1056964608 1056964608 1061158912 1048576000 0 1061158912 1056964608 1065353216 1048576000 0 0 1048576000 1048576000 0 0 1048576000 1048576000 1056964608 0 0 1056964608 1048576000 1061158912 0 0 1061158912 1048576000 1065353216 0 My guess as the meaning of the strings: Position 1 (almost always a zero) = rotation X Position 2 = rotation Z Position 3, 4, 5 = position X, Y, Z The one we´re looking at is sparksanim0, so I think that this makes sense- the frame_rects tell it to (basically) rotate it on the Z a bit during the animation, while moving it up and down on the Y in a 2-part cycle. This array has 80 entries... and 80/16 = 5, or the number of positions per frame. The only thing that makes *zero* sense to me is the absurdly huge numbers being used here. I can understand that the rotations must be in radians... but what´s with the gigantic position variables??? The other problem (at least from my perspective) is that the game engine draws these things perpindicular to the viewer. For the specialized purposes I´d like to put one of these things to... I need to find one that´s not rotated automatically. I took a look at Plasmaring, but I´m not sure if that´s going to work, because it doesn´t use frame_rects and is obviously just animated through the ALE.

I´ve been looking at gf_br_transport_engine01.ale tonight with a mind to making a simple info dump program. Here´s what i´ve got to start with (got to get up for work in 6 hours). <pre><font size=1 face=Courier>&lt;font size=1 face=Courier&gt; ALEffectLib : // 3f800000 (unknown 1 - aleffect sig?) 00000001 (unknown 2 - version ?) 001a (length of string to follow including null terminator) string - ´gf_br_transport_engine01´ 26 X unknown dword // //--------------------------------- // AlchemyNodeLibrary : // 3f8ccccd (unknown 1 - nodelibrary sig?) 00000004 (unknown 2 - number of effects nodes?) 0012 (length of string to follow including null terminator) string - ´FxBasicAppearence´ 6 bytes unknown 001a (length of string to follow including null terminator) string - ´gf_br_transport_engine01´ 65 x unknown dword 000c (length of string to follow including null terminator) string - ´planetflare´ 19 x unknown dword // 000e (length of string to follow including null terminator) string - ´FxConeEmitter´ 6 bytes unknown 001c (length of string to follow including null terminator) string - ´gf_br_transport_engine01#1´ 157 x unknown dword // 0011 (length of string to follow including null terminator) string - ´FLBeamAppearance´ 6 bytes unknown 0023 (length of string to follow including null terminator) string - ´gf_br_transport_engine01trail.app´ 309 x unknown bytes // 000e (length of string to follow including null terminator) string - ´FxConeEmitter´ 6 bytes unknown 0028 (length of string to follow including null terminator) string - ´gf_br_transport_engine01trail_Cone.emt´ 120 x unknown dword &lt;/font&gt; </font></pre> +++ out of cheese error - redo from start +++ Edited by - Anton on 2/4/2005 4:45:46 PM

Any news about this?? I´ve looked a little into ALE files and Alchemy.dll, and some parts are similar. There are definitions followed by HEX code, like &quot;FxTurbulenceField&quot; or &quot;FxConeEmitter&quot;. Also, I found that .emt files could mean emitter files? (I heard the extension was used in EverQuest, but I doubt it´s the same thing) FF

The other day I had one of my programmers break down the first code block from gf_br_atransport_engine01.ale to help further the cause. To make things clear this is not a part of the UTF format and therefor should not be editable by any UTF software, you must extract the data and handle it seperately. ALEffectLib code block: <pre><font size=1 face=Courier> Offset Type Purpose *** HEADER ? *** 0000 float unknown, value was 1.00000 0004 int unknown, value was 1, -or- a 1 followed by a 0 0008 int length of coming string?, value was 26 000a string zero terminated? string (gf_br_atransport_engine01) name? can also be int with value 0 *** DATA ? *** 0024 int unknown, value was 5 0028 int unknown, value was 0 (maybe one big 64 bit int) 002b ? unknown, was 0xa8f5ad12 (313390504) (UTF id &gt; gf_br_atransport_engine01) 0030 int unknown, value was 5 0034 int unknown, value was 3 0038 int unknown, value was 0 003b ? unknown, was 0x7b47ff11 (301942651) (UTF id &gt; gf_br_atransport_engine01#1) 0040 int unknown, value was 5 0044 int unknown, value was 4 0048 int unknown, value was 1 004b ? unknown, was 0x513b22ee (3995220817) (UTF id or some other CRC) 0050 int unknown, value was 32768 0054 int unknown, value was 5 0058 int unknown, value was 0 005b ? unknown, was 0x7a69a8ff (4289227130) (UTF id or some other CRC) 0060 int unknown, value was 5 0064 int unknown, value was 6 0068 int unknown, value was 0 006b ? unknown, was 0x8c433408 (137642892) (UTF id &gt; gf_br_atransport_engine01trail.app) *** FOOTER ? *** 0070 int unknown, value was 32768 0074 int unknown, value was 7 0078 int unknown, value was 2 007b int unknown, value was 4 0080 int unknown, value was 3 0084 int unknown, value was 6 0088 int unknown, value was 7 </font></pre> Both code blocks use the same structure and the second block references any textures the effect needs. Hope this helps. Check out the latest beta´s of the <A href=´http://eoa.seriouszone.com/?page=flsdk´ Target=_Blank>Freelancer S.D.K. 1.5</a> and <A href=´http://eoa.seriouszone.com/?page=flexp´ Target=_Blank>Freelancer Explorer v2.x</a>

Hey Argh, those might be four value blocks that are serialized. They could be x,y,z, alpha values. if they are serialized than that might explain the large numbers for x,y,z values as you´d want the same size for each entry to facilitate data access. Just an idea, probably wrong. I´m only a second year programmer so I only know vb and java. Good luck guys.

Just wanted to keep this thread alive. I´ve made some substantial progress on decoding the ALE format. I have been able to adjust effects and change paramters such as size and color. Next step is to hopefully decode the whole format so entirely new effects can be created. Any other information anyone is willing to share to help the cause would be great.

I thought I would just post some sort of &quot;official&quot; documentation on the nature of Alchemy effects and how they are used by the FL engine including answering some lingering questions such as the significance of CRCs (and how some of the &quot;negative&quot; CRCs are generated which I will explain). Here we go:

EFFECTS.INI - Defines effect LODs and creates FINAL names which effects can then be referenced by in other INIs for use. &gt;&gt;name = name of effect which will be referenced in other INIs. &gt;&gt;effect_type = defines effect type of effect as referenced in EFFECT_TYPES.INI &gt;&gt;vis_effect = name of effect as defined in any *_ALE.INI file. &gt;&gt;vis_generic = second &quot;base&quot; effect to be applied in addition to actual effect. &gt;&gt;snd_effect = sound effect played when effect is activated. *_ALE.INI - Defines visual effects which are then referenced in EFFECTS.INI &gt;&gt;nickname = name of effect which is referenced as a vis_effect or vis_generic effect in EFFECTS.INI &gt;&gt;alchemy = filename of alchemy effect &gt;&gt;effect_crc** = effect CRC (usually the same as nickname - THIS defines for Freelancer, what effect to look for in ALE file - the CRC is translated back into a name which is found in the ALE and has code/instructions for effect - this is because as in the case of no_cloakeffect.ale - it has 5 effects in one ALE - the CRCs determine which to use - this has been determined by testing). &gt;&gt;textures = these are listed in the order effects in the ALE will use them (these are essentially parameters of the effect determining the texture file used when generating the effect - since all ALEs were created for specific uses they have predefined instructions on how to use these textures - the fact they are not stored in the ALEs themselves appears merely an oversight on DA´s part though it will make modding easier). **A note on effect CRCs: most effects use UTF CRCs and are computed normally - those that are negative are &quot;reverse&quot; CRCs found by the formula: Reverse CRC = Normal Effect CRC - 4294967295 (0xFFFFFFFF) - 1 I am unknown at this time why reverse CRCs are used at some points and not others. Edited by - Alcander on 6/1/2005 2:21:21 PM

@Alcander GREAT!! work there...Keep it up

So about the CRCs... exactly <i>what </i> named files, in what order, constitute a valid CRC? For example... [VisEffect nickname = br_capgun_01_flash alchemy = fxweaponsr_capgun_01.ale effect_crc = -513500801 textures = fxplanetflare.txm textures = fxsarma.txm textures = fxmissleeffect.txm textures = fxlightning2.txm textures = fxeam.txm Is that effect_crc just the crc of fxweaponsr_capgun_01.ale, or what? I´m a little confused by what you´re saying here. If it´s a CRC generated from the string of the five Texture names named in the TXMs... then why is it that the following is still a working ALE? [VisEffect nickname = br_capgun_01_flash alchemy = fxweaponsr_capgun_01.ale effect_crc = -513500801 textures = fxplanetflare.txm I´ve modified different &quot;base&quot; ALE references and removed texture references without any problems- I just haven´t been able to make new ones. So I´m assuming that the CRCs you´re talking about are for the alchemy entry, not the TXMs. Otherwise, what I´ve done shouldn´t work, I would think. You said above that you´d learned how to change the colors of the particles in ALEs. Please share this... I would <i>love </i> to make a set of different Engine flames in various sizes and rainbow colors <img src=smilies/icon_smile_big.gif width=15 height=15 border=0 align=middle>

Right. I will hopefully be able to share this information soon. I certainly understand many people would love to change effects around =). And as per the CRCs: Allow me to explain better. In the case of br_capgun_01_flash. The nickname is where the CRC is generated from. Now, the nickname actually does NOT matter, it is just that DA choose to use the same nickname for the effect as the &quot;real&quot; name of the effect (internally in the ALE) - obviously for simplicity reasons so one effect wouldn´t have five names. But the nickname could be changed to br_capgun_01_flash2 and the references in other INIs changed and the effect_crc kept the same and it would work. If you use say CRCTool to generate a UTF CRC - br_capgun_01_flash = 3781466495 but as you can see the CRC is negative so this is a &quot;reverse&quot; CRC they used in this instance. Which means you take 3781466495 subtract 0xFFFFFFFF (4294967295) = -513500800 finally minus 1 = -513500801 - the effect_crc they used. The CRC does not even take into account the textures at all.

Thanks for keeping up on this- ALEs are an area I´ve picked at several times, but without much success- and I´ve never gotten enough interesting things going on that it´s been worth it to pursue it in detail. Any results you can generate here will be very useful for the whole community. One thing that may/may not have occured to you about the specific sizes of ALEs is that this could have some very direct uses right away, if it´s really possible to change the frame_rect sizes. I´ve been wanting a smaller version of rh_continuoussmoke for a very long time, for example- the default version is much too large for many ancillary purposes, such as having smoke trail from small ships with belching exhausts. And it´d be very nice to have engine flames that are smaller (that´d be useful in all sorts of places, including custom Thruster sets, Missiles that can actually be seen but are properly scaled), and other things. This line of research is potentially very, very useful, although don´t be surprised if it takes awhile for us game designers to grasp all of things we can do with this- my experience thus far has been that things I did and documented months ago are just now getting used by others <img src=smilies/icon_smile_wink.gif width=15 height=15 border=0 align=middle>

Hmm yes I know exactly what you´re talking about. As an aside, there are a number of things I have personally been able to change about the FL engine (like say tradelane speed - mmm going 10,000K/sec can be fun) - but setting it up so it meets the criteria of not just being configurable but controllable (cheating-wise) is where the difficult arises. That´s kind of my goal is setting up these things in a way anyone could do them - like making ALEs hopefully. Since ALEs don´t really do anything we shouldn´t have to worry about any sort of cheating ;P. But, as you pointed out even changing some things can have immediate purposes and I´ll attempt to document my findings in the next few days so you can get to work on that - since as you also point out integration of work down by us &quot;coders&quot; into mods after they are discovered can be very far apart indeed <img src=smilies/icon_smile_wink.gif width=15 height=15 border=0 align=middle>. Edited by - Alcander on 6/1/2005 11:00:20 PM