ALE lurker
-
0x03503B61 and 0x0ABE0402 appear to be aliases for DupeFirst and DisablePlaceholder respectively.
0x0BA0B3BB also present at beam particles, type of transformation matrix, but seem does nothing.
0xE63AA248 appears in FLDustField, also seemingly no effect.
-
Have you tested if Emitters actually support Fields? Or do Fields only work assigned to Appearances?
-
Yes, I’ve tried and predictably figured out that fields don’t affect node’s transformation matrix, so they wouldn’t have any visible effect on emitters themselves, may not be obvious at first but it is logical since they just affect individual particles vectors. Particle (appearance) nodes are essentially collections of particles, a grouping and instancing mechanism, so transformation matrix in appearance node is applied to them as a whole and not individually. This can be clearly observed when you start to adjust and/or animate scaling.
-
0x03503B61 and 0x0ABE0402 (and BeamApp_UseCommonTexFrame within this context) are explicitly set false.
I was able to trigger a breakpoint related to 0x0BA0B3BB, but all it did was increase a counter.
0xE63AA248 does not even exist in alchemy.dll.
How do I test the mesh?
-
0xE63AA248 probably existed in their effect composition tool, hence its strange appearance in the vanilla file, but I assume it was never coded to be used in the first place.
Test effect for meshapperance is in attachment.
[VisEffect]
nickname = test_mesh
alchemy = fx\misc\test_mesh.ale
effect_crc = -257469979 -
Hey Treewyrm, a quick question:
Is it legal to parent Root (0xEE223B51) to something else than 32768? -
Doesn’t look like FxMeshAppearance is properly implemented. The crash is because it couldn’t find [c]fx\misc(null).3db[/c] (as shown in the spew); but the name is always [c]NULL[/c]. Even creating that file (copying [c]ast_beryl_10.3db[/c]) didn’t seem to have any effect.
-
Interesting find. Any way it could be forced to load anything but null? Also is it literal ‘null’ as in string or is it trying to load file with empty name and extension .3db?
Also what about MeshApp_MeshId property? Is it read, does it attempt to use it anywhere?
It doesn’t seem to work if you set its parent to something else.
Also root node doesn’t have to be 0xEE223B51 actually, it can have any hash, the only thing that matters for it is third property set to 1.
-
Treewyrm wrote:
Interesting find. Any way it could be forced to load anything but null? Also is it literal ‘null’ as in string or is it trying to load file with empty name and extension .3db?It is a [c]NULL[/c] pointer, which gets printed as c[/c] (an empty name would be [c]fx\misc.3db[/c]). It should be possible to load anything, but doubt it’s worth the effort. I tried forcing [c]solar\asteroids\ast_beryl_90.3db[/c], but didn’t notice anything different.
Also what about MeshApp_MeshId property? Is it read, does it attempt to use it anywhere?
It was read, but not apparently used (at least, not with a renamed model).
Also root node doesn’t have to be 0xEE223B51 actually, it can have any hash, the only thing that matters for it is third property set to 1.
0xEE223B51 is tested, though, so it does do something.
-
I suppose then they didn’t finish/fix MeshAppearance and simply removed them from being spawned. Oh well.
Well I guess every node hash in effect instances is read/tested, it’s just when I gave it some other name it didn’t affect anything, the effect still worked, even if there wasn’t any node in NodeLibrary with that name, the only thing mattered is setting type to 1 for root nodes (there can be more than one, not that it is useful for anything) and 0 for everything else.
I think that’s about it, no more mysteries left in ale stuff, heh.
-
Just to give a preview on what we have been working on (work on ale rendering started over a year ago), here is a little screenshot from the first combined version (editor and renderer).
-
Thanks! We hope that it will really help people. But there a still a few things to be done, like cleaning up the GUI. Also the value editing dialog is not good enough yet. It works and you can change the values and see the effects in real time, but it is not yet practicable.
Also the particle system still has a few issues and some minor things are not yet like in FL, mainly beams. Some appearances and fields are also not implemented yet (e.g. collidefield).
So don’t expect a release too soon.
-
-
Thanks! Just keep waiting. It will be released eventually. There have been lots of bugs fixed in the meantime.
-
That’s look awesome. Nice work.
-
Will it have source when it’s released? The FL community seems to have a severe lack of that
-
If we would have used existing sources, then yes. But since this is not the case and it has been a lot work plus the particle system is used also elsewhere, we have to say no. There is no benefit for us in this. For FLHook I have shared all I found, since it is a community project.
I have to agree that there is a lack of sources for a lot of tools, but I can understand that people don’t want to release it if they don’t see a benefit in this. There are not a lot of active programmers.
