ALE lurker
-
Ah, that’s where you’re wrong I’m afraid. Parenthesis and pairing (or who-uses-what, as in what particle emitter uses, etc) are entirely independent, in fact they have no relation whatsoever. You certainly can set one emitter instance to be a parent of another. So then if you have animation on parent it’ll of course affect the ‘child’ emitter since parenthesis (the second argument of each node instance listed in ALEffectLib) simply means that the child node instance inherits its parent node instance transformation matrix, better yet you can nest them for many levels like that. You can drop off say radialfield, by giving it 32768 for parent and it’ll be now in relation to scene or system rather than where effect is.
On my video above it’s actually just one CubeEmitter and one FLBeamAppearance. In ALEffectLib there are four instances of same emitter, and four instances of same particle. CubeEmitter has simple rotation loop in its NodeTransform block. If that emitter instances were attached to root then they’d simply all shoot at same angles, effectively quadrupling beam intensity since the beam particles just overlap. However if goes like this:
instanceID, parentID, type, name
1, 32768, 1, 0xEE223B51
2, 1, 0, beam.emt
3, 2, 0, beam.emt
4, 3, 0, beam.emt
5, 4, 0, beam.emtyou get what you see in that video because transformation matrices stack for as many parent nodes you have in chain, with the last beam.emt node essentially multiplying all of its predecessors and then of course applying its own.
-
I see what you mean. So I was describing that pair hierarchy. That still works that way. But you were talking about that node transform hierarchy.
I really mixed them up into one in the ALE Editor. That’s a problem here, as you say. -
Yes, pairing hierarchy is somewhat that, but there are few interesting tidbits. Just to be clear on what I mean I imply instances that are defined in ALEffectLib as there can be multiple instances of same node from AlchemyNodeLibrary. Here’s what I had observed. Like mentioned earlier a single particle instance can have multiple emitters spawning it (same instances or even entirely different nodes), although one emitter instance can spawn only one particle instance. One particle can be affected by multiple field instaces, although some fields will override almost every other, like AirField, but some can have combined effect on same particle. Also one field instance can affect multiple particle instances.
I don’t have xml from that particular effect since it was just a test one I did a long time ago, but here’s more recent and using same, if not more advanced, approach: grab from pastebin. And you can see it in action at this video when the door starts to open (it’s the one from another thread).
-
Yes, that 1 emitter to n appearances relationship etc. is already implemented. Just the transform matrix stack has to be made separate.
One question for you: Have you any idea what those four additional float parameters in version 1.1 ALEs (right at the head) do? That should be called “unused” in the xml.
Edit:
To get a clear view on the transform matrix stack: Do only emitter nodes stack their transforms, or can I parent an emitter to an appearance (which wouldn’t make any sense to me)? -
Effectively any node can be stacked to any other node, this is because any node can have own transformation matrix. Heck I even use FxNode which does absolutely nothing at all but can be used for something like a rotation pivot for other nodes (see code in pastebin link above). And you might be surprised what interesting effects can be accomplished by rather unorthodox things like setting appearance to be parent for emitter when you start to animate them all together, so yeah there’s definitely use for that too.
Four floats in effect header in ALEffectLib seem do absolutely nothing, at least no matter what values I set there I couldn’t see any observable difference. Probably unused stuff, much like the unfortunate MeshAppearance and several other properties like NodeClass that kinda do nothing.
-
Very good to know. Thank you! I will have to change some code and the GUI itself to make all those combinations useable.
Edit: I saw in your documentation those loop types for Curve Animations are missing:
0 - no loop
16 - jump to first key after last key
32 - backwards to beginning
48 - set last key as first key (keeps transform of last key and adds transformation of first key etc). -
Thanks. Although I did find them a while ago but then simply forgot to add them to the doc as well, it (doc) hadn’t seen much use beside myself unfortunately, as a result had been rarely updated.
Here’s the crazy map effect from first post to test your editor. Just replace particle sprite names with your own since I use my own sprite library and not vanilla txms.
-
Treewyrm wrote:
MeshAppearance is in few effects in vanilla but they’re never actually used and having them spawned by emitter simply crashed the game. … But it is kinda unclear what MeshName is supposed to refer to.
Without actually trying anything, it does seem the “intro_volcanoplanet” meshes would be used - they’re part of the template in [c]SCRIPTS\INTRO\intro_volcanoplanet.thn[/c], the asteroid band around the sun. In this case, it would appear MeshName refers to asteroids in [c]SOLAR\asteroidarch.ini[/c].
Skotty wrote:
One question for you: Have you any idea what those four additional float parameters in version 1.1 ALEs (right at the head) do? That should be called “unused” in the xml.
IIRC, I set breakpoints on them which were not triggered; since they’re read, but not apparently used (seemingly backed up by Treewyrm’s findings), that’s how I stored them.
-
Thanks for that, adoxa.
@Treewyrm:
In your documentation some small detail is missing: As soon as there is no root (usually 0xEE223B51) in the <fx>part of the effect, all nodes which have parent 32768 will use the hardpoint as coordinate center. Else it is 0, 0, 0 of the whole star system.</fx> -
And enabling them just crashes the game.
Actually no, it’s not missing, it is briefly explained in EffectInstance section. In fact it’s not related to presence or absence of root node (the one with type set to 1). Simply put parent 32768 is world coordinates, except for type 1 root node which serves as a proxy to wherever effect coordinates are and whatever it might be attached to. This is why say particles with parent 32768 wouldn’t move with effect, their transformation matrix doesn’t inherit from root node, instead it is world space. And similarly nothing stops you from having emitters and fields at world coordinates instead, in fact it can be used to create interesting features, like a world gravity for particles which would be unrelated as to what orientation the effect has if attached to something. Or say a radial field placed in world space, and say it may attract particles from your dust effect, like say around some anomaly. Of course that would make effect rather specific to a system as translation offset for radial field would have to match coordinates of where you had placed some anomaly object in system, but there it is.
One more suggestion for edit. You have a time slider at the bottom. Add another slider there for sparam as well. That would help to test things like engine effects, to simulate how they would change in game based on engine usage, cruise mode. Thrusters too use sparam, and finally you can add “use_throttle” for AttachedFX to make attachable effect to be dependent on your engine (but sacrificing 0.9 - 1.0 sparam range that would be used for cruise mode).
-
In version 1.0 ALE files there are additional parameter of BeamAppearance:
<effect type="bool" crc="0x03503B61">true</effect> <effect type="bool" crc="0x0ABE0402">false</effect> <effect type="xform" crc="0x0BA0B3BB">0x435</effect>Same for SphereEmitter:
Any idea what they are about? I couldn’t find them in any version 1.1 file, so I guess they are obsolete. -
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.
