XML talk:BINA/PAR3

Particle subtype investigation

TXMP was shown to have 3 types. Similar can be expected from particle.

Due to their huge number a statistic approach might be suitable.

This would be best to be carried out with an programmed tool.

We could look for common trait (tags and tag values).

Expected types

• decal
• lensflare
• 3d object
• contrail
• damage dealer
• General purpose particle (helper particle for location, orientation, attractor, emitter, event, used as emitter or in between a chain)

Beside that there are optional features like "owning damage" which requires the property to be set in each file of the particle chain.

So particles are best to be seen as "teams" not "individuals".

Decals

For example files with <HasDecalState>True could be investigated for shared structure and values.

The result will be probably that Attractors, Emitters, Events aren't not only used for them but disabled (proof by testing).

So only appearance and maybe variables apply for them.

Seems to be always the same with decals:

       <Properties>
           <HasDecalState>true

       <Appearance>
           <DisplayType>Decal

Properties based on observation:

• hosting 3d surface must be in tolerance range (10 units)
• <CollideWithChars> .. is ignored by decals
• <TexGeom> .. links to TXMP file
• <Alpha> .. alpha level is ignored when TXMP has adaptiveAlpha flag
• <Tint> .. is ignored by decals

Exploring Mad Bomber particle

What triggers Mad Bomber's explosion?

ONCCmad_bomber.xml

<DeathParticle>mad_e01</DeathParticle>

Particle structure

mad_e01 from ONCC <DeathParticle>, self: <TexGeom>count3 ( <Invisible> true )
 |
 +-- mad_p01 from <Emitters><Emitter><Class>, self: <TexGeom>count3
 +-- mad_p04 from <Emitters><Emitter><Class>, self: <TexGeom>count1 ( <Invisible> true )
 +-- mad_e02 from <Events><Lifetime><CollisionEffect><Effect>, self: <TexGeom>count3 ( <Invisible> true )
      |
      +-- mad_p02 from <Emitters><Emitter><Class>, self: <TexGeom>count2
      +-- mad_e03 from <Events><Lifetime><CollisionEffect><Effect>, self: <TexGeom>count3 ( <Invisible> true )
           |
           +-- mad_p03 from <Emitters><Emitter><Class>, self: <TexGeom>count1
           +-- mad_x01 from <Events><Lifetime><CollisionEffect><Effect>, self: <TexGeom>lensflare01 (really visible?)
                |
                +-- mad_f01 from <Emitters><Emitter><Class>, self: <TexGeom>lensflare01 (rally visible?)
                +-- mad_f02 from <Emitters><Emitter><Class>, self: <TexGeom>smoke
                +-- mad_f03 from <Emitters><Emitter><Class>, self: <TexGeom>bloodyfoot
                |    |
                |    +-- mad_f05 from <Emitters><Emitter><Class>, self: <TexGeom>smoke
                |
                +-- mad_f04 from <Emitters><Emitter><Class>, self: <TexGeom>w5_fireball

Add screenshots of all <TexGeom> content.

Add screenshots of total scene and illustrate the parts.

Questions:

• Why invisible textures?
• Are lensflare01 textures really visible?
• ...

Random observations:

• Each "count" textured particle comes with its own timer sound
• "x" particle holds an sbg sound
• "e3" seems to provide a safety distance towards level geometry: <WallOffset>0.2</WallOffset>
• ...

Naming:

e - emitter particle (usually used for positioning)
p - particle (holding the TexGeom of interest)
f - "fire" particle
x - "explosion" particle


h2h - hand to hand combat (contains child with health indicator?)
c - ?
env - environment (permanent non-decal)
d - decal (permanent texture)
w - weapon (moving)
...

The Scarlett case

Scarlett bound mad_x01 to a character animation which spawns the particle at global 0; 0; 0.

I don't know yet what's wrong with the spawning but obviously its supposed to work differently.

That bug (or new "feature") can be avoided by introducing a new root emitter. For tests I used h2h_powerup_e01a (Syndicate compound level, daodan blast).

For <SelfImmune>1 to take effect, x01 <HasDamageOwner> must be set to "true". (h2h_powerup_e01a has that already. A complete chain of ownage is essential.)

Creating and renaming particle clones would be ideal to introduce the actual changes so that the originals aren't affected. However, over here, the new explosion file isn't recognized which leads to new questions and investigations. But for now, ... not now.

Discussion on <StopIfBreakable />

Controversial phrase:

Within the HitWall PAR3 event, [<StopIfBreakable />] stops the exection of all PAR3 actions listed BELOW this PAR3 action if the HitWall was called against a breakable material (in vanilla Oni, the only breakable material is glass).

Example of <StopIfBreakable /> not stopping a later action:

modified BINA3RAPw8_mbo_p01

           <HitWall>
               <StopIfBreakable />
               <ImpactEffect>
                   <ImpactType>w8_mbo</ImpactType>
                   <ImpactModifier>2</ImpactModifier>
               </ImpactEffect>
               <Die />
           </HitWall>

https://dl.dropboxusercontent.com/u/139715/OniGalore/StopIfBreakable_used.wmv

           <HitWall>
               <ImpactEffect>
                   <ImpactType>w8_mbo</ImpactType>
                   <ImpactModifier>2</ImpactModifier>
               </ImpactEffect>
               <Die />
           </HitWall>

https://dl.dropboxusercontent.com/u/139715/OniGalore/StopIfBreakable_not_used.wmv

Side note: There's no visible effect (like decal) on the breakable glass because of ONIE.

For better visibility we can also repeat the two tests with a plasma effect.

           <HitWall>
               <StopIfBreakable />
               <ImpactEffect>
                   <ImpactType>w3_phr</ImpactType>
                   <ImpactModifier>0</ImpactModifier>
               </ImpactEffect>
               <Die />
           </HitWall>

https://dl.dropboxusercontent.com/u/139715/OniGalore/StopIfBreakable_used_phr3_alt.wmv

           <HitWall>
               <ImpactEffect>
                   <ImpactType>w3_phr</ImpactType>
                   <ImpactModifier>0</ImpactModifier>
               </ImpactEffect>
               <Die />
           </HitWall>

https://dl.dropboxusercontent.com/u/139715/OniGalore/StopIfBreakable_not_used_phr3_alt.wmv

Mercury Bow videos prove exactly what was written, no contradictions.

• "StopIfBreakable_used.wmw" -> mercury bow pellet encounters breakable material. StopIfBreakable prevents the execution of both <ImpactEffect> action and more importantly the <Die /> action. Thus the pellet goes through glass and "dies" later, after colliding with a non-breakable wall (and leaving an ImpactEffect).

• "StopIfBreakable_not_used.wmv" - if the action StopIfBreakable is NOT used, then any collision of the pellet with any kind of a wall (even with breakable glass) will let the <ImpactEffect> and <Die /> execute. The pellet "dies" upon impact with the breakable glass and does not continue through. Also, since there is no match in ONIE, no Impact Effect is left on the breakable glass.

--Loser (talk) 01:13, 12 September 2013 (CEST)

I see, my mistake was to think that particle can only react once. I wasn't aware the events can happen multiple times for an particle because the usual case is "one". With that logic the particle should called hitwall event on glass and keep moving with only the second (impact) action left on the stack. I somehow thought the first impact would not really count since it's not a solid material or whatever.

Also at first I thought <StopIfBreakable /> refers to the particle itself and not the actions.

PS: Regarding other thing on OCF: I don't know how to use mod patches, I didn't found it very intuitive / documented so I never tried it. (The last time I heard from it, Script said he wanted to improve it.) Maybe ask him, Iritscen or Samer whether they have some more examples laying around that could help to understand. --paradox-01 (talk) 19:44, 12 September 2013 (CEST)