Nice
Can we get an exacly explanation of the whole script?
Witch function/command evoke the display of the dds files?
Witch commands couses the bullet holes?
Would be fine, especialy for those who wanna learn scripting(me )
Thanx

Burn the witch!

ParticlesSpawnParticle is the command that causes an image from the .dds file to be displayed at the hit point.

The rest of the script is just "AmenMose' funky math".

Here is a good place to start:
https://forum.game-guru.com/thread/220140#msg2606716

Super Clark - Could be motion blur - mine is set to 3000 by default for some reason. Set bloom to 0 and it disables some of the visual effects.

@Pirate Myke
I ask for help about PP (PublicPreview)

Great, what kind of help. It runs the same way as in the videos already out there. It has more scripts for physics and particles, but other then that, you pick entities the same way, you place rotate and scale them the same way.

Not really sure what kind of video you want.

What am I doing wrong?

https://forum.game-guru.com/thread/220566

First thing is you need to have a dynamic (green) object that you assign this script to. Set it to always active in it properties also.
Secondly you will need to make sure the materials listing in the FPE file is the correct one you want. This will determine the bullet hole used.

Now set the objects you want around. No need to change anything on them at all.

You also need to use one of the weapons listed in the bullethole script, or add the weapon name you want to use.

Run test game and see if that works now.

I always use crates to assign scripts to as they are dynamic by default so you just have to set the always active bit for them.

Did not work out.

"Secondly you will need to make sure the materials listing in the FPE file is the correct one you want"

I did everything, but I don’t know exactly where to write the name of the textures in the FPE file, I did so -

No, it's the materialindex bit that determines which bullethole image it uses.

your doing it all wrong .. your over complicating it … just follow the video
You don't assign the script to the girder … place a dynamic barrel, tree or some object and attach the script to that … Not the girder.
The bullet holes should then work .... Worry about setting up the materials later

Hallelujah!!! it turned out!!!))) Thanks a lot to you!!!

Excellent. Have fun.

@Pirate Myke - Currently the fpe specifies a single materialindex for the whole model but using that girder model in the video as an example it really needs to have two 'materialindex' values, one for the base which is concrete and one for the metal part.

In reality is this a multi-material model from a modelling aspect, and if so can you think of a simple way of assigning the materialindex to teh actual textures such that the engine will return the correct value to the script?

I'm quite happy to make changes to the engine to accomplish this but not sure from the modelling aspect how the 'material' bit works, i.e. is there a standard naming convention or something like that which tells the engine something is metal as opposed to concrete or can it be inferred somehow from the PBR doodahs attached to the model?

Obviously for models with a single texture I would assume it is impossible for the engine to know which parts of a model are a different 'material'.

Multi material is fine until you want to light map, then it will be hit or miss. But yes having only a single material index makes it this way.
I am thinking the EBE stuff does this for materials, but not sure if it is from the floors only.

Material indexes on objects with more then one material have always had to choose the most prominent one you really wanted.

You can always split the model up into its material assigning each part the proper material index, but the majority will not do this and it is not a drop and run solution. I always split my models and then set them from a single point in the editor. For collision mostly, or if I actually need to tile out a material for a long ways.

So this would have to be done by splitting the model and having the correct material index set for each part right now, from a modeller perspective.

But this is my work flow for levels and not the normal for most.

Another way may be to assign the object some bones that you could detect the limb numbers and have the bullet hole chosen from there.
Again not a drop and run solution, but could happen this way with the current system you have in place already.

Let me play with an object that I do this to and set the material index for each one. I will post my results.

It could be texture base, adding index at the end of texture file name (diffuse) ie:
myTexture_D1 = meaning that it is a stone material.
myTexture1_D2 = meaning it is a metal material, and so on.

Most likely some engine code changes could be necessary , But is it worth it.
So Lee just has to run their fpe writter code to update all stock models fpe files.

I wouldn't make it texture based, I'd make it seperate mesh based, when modelling you can create your models with seperate mesh objects within one entity, they place as a single entity, but are made up of multiple objects inside the entity.

If gg could be programmed to read those individual parts, you could set up a way to assign different material indexes ti each one.

groups do kind of work, take glass for instance in a single x file if you do glass as a separate group and put it last it works perfectly, so in theory you could create dummy material groups in an x file and keep your types separate (just group the UV's by type of material) it would still need code in GG to work it out though