Feature request: Modified invisible targets

[Tinter]

As I am not sure whether this is really within the scope of CBA nor can I really find a proper way to figure out who or how to contact, I'm opening this feature request. Description:

• The vanilla game has these classes.
  • B_TargetSoldier
  • O_TargetSoldier
  • I_TargetSoldier They have problems namely with being hidden and phyiscally blocking bullets. My suggestion would be to add modified classes which changes their models and doesn't hide them, so they're more versatile for mission and mod makers. I have made my own example, however classnames should be different and requiredAddons might also need to be different.

    class CfgPatches
    {
    class tint_targets
    {
    units[]={
    "B_TargetSoldier_tin",
    "O_TargetSoldier_tin",
    "I_TargetSoldier_tin"
    };
    weapons[]={};
    requiredVersion=1.0;
    requiredAddons[]=
    {
    "A3_Structures_F_Training"
    };
    };
    };
    class CfgVehicles 
    {
    class B_TargetSoldier;
    class O_TargetSoldier;
    class I_TargetSoldier;
    class B_TargetSoldier_tin: B_TargetSoldier 
    {
    model = "\A3\Structures_F\System\ClutterCutter_small_F.p3d";
    scope = 2;
    };
    class O_TargetSoldier_tin: O_TargetSoldier 
    {
    model = "\A3\Structures_F\System\ClutterCutter_small_F.p3d";
    scope = 2;
    };
    class I_TargetSoldier_tin: I_TargetSoldier 
    {
    model = "\A3\Structures_F\System\ClutterCutter_small_F.p3d";
    scope = 2;
    };
    };

    I'm not sure what the stance would be add to add new classes. If this is appropriate for CBA I would be happy to try and rewrite it to conform to CBA standards. And just for completeness sake, I have my whole rant that inspired me to discuss this. https://forums.bohemia.net/forums/topic/219853-the-invisible-targets-you-never-knew-existed-and-how-they-could-be-so-much-better/

Edited: Changed the requiredAddons to actually point to the addon containing the original definitions.

[commy2]

They have problems namely with being hidden

Aren't they supposed to be invisible?

and phyiscally blocking bullets

hideObjectGlobal should hide the FIRE GEO LOD as well, making the object unable to block bullets.

[Cuel]

hideObjectGlobal should hide the FIRE GEO LOD as well, making the object unable to block bullets.

Doesn't that make them non-targetable by AI?

[Tinter]

Aren't they supposed to be invisible?

Yes in game of course, I meant hidden as in you can only spawn them with commands, not by placing them down in the editor.

hideObjectGlobal should hide the FIRE GEO LOD as well, making the object unable to block bullets.

That would hide them completely, as if they weren't there, so AI won't target them either.

I tested it and it does hide their FIRE GEO LOD, but also everything that makes ai spot them.

[commy2]

I meant hidden as in you can only spawn them with commands, not by placing them down in the editor.

Oh, you mean "protected" scope. Hidden sounds like it refers to hideObject.

[Tinter]

Yeah, I'm talking about the scope.

[commy2]

It appears that AI still shoot at hidden crewed objects, but only after they fired once. They probably cannot be revealed since they have a hidden VIEW GEO LOD, but still be shot at. Maybe we can give the dummy object a big VIEW GEO LOD and no or a tiny FIRE GEO and it would work better.

[Tinter]

Well in my config I've given them the grasscutter model and the AI fires at it, with the bullets just passing through. That would be my suggested solution. I'm not actually sure how a big view geo would work against a tiny. I could imagine that it would make the ai fire at all of the view geo, but I don't actually know what point AI aims at. (Just on target, the middle, just some random point or super complex algorithm based on what they can see?)

[commy2]

Pretty sure AI always aims at the center of the object, but never bother to check for myself.

[Tinter]

I'll run a small test(small vs large cluttercutter) and see if I can find some conclusive results.

[commy2]

The problem I have with using the grasscutter model is, that the invisible target would waltz down the grass below it.

[Tinter]

You're right, hadn't noticed. Making a model from scratch should be fairly simple, but I'm not entirely sure about LOD specifics. As far as I know it should have no fire geo and a view geo, not sure about anything other than that.

[commy2]

Nothing else than that comes to mind atm.

I noticed a problem with the grasscutter model. If the grascutter model is placed at default height z(ATL) = 0, the object is below the ground and AI can't spot it. You have to manually raise it. Definitely not the model I'd use for this.

And I found another issue with crewed objects with VIEW GEO LOD, and I am not sure how to work around that. In noob mode, the nametag of the object is shown when aiming at it.

This requires some more thought.

[commy2]

And the object is also shown on the map of course.

I think these are the reasons BI stopped bothering with this.

[commy2]

What's the purpose of this anyway? Wouldn't AI just waste all their ammo once they encounter such an object?

[Tinter]

It'd be a way to let ai shoot at things without having to manually script it. It uses the normal ai routines to make them engage it, instead of having to hijack them with a script. It allows you to for example make agents that you attach the target to, so the ai will shoot them. Then you just need to script the deletion to avoid them wasting their ammo. The alternative would be to have a script that orders nearby AI to engage the target, which could be pretty cumbersome, especially if you want the AI to behave normally otherwise.

[commy2]

If so then we should implement the delete-target-once-host-object-is-killed part as well by some init script or something. I have no idea on how to get rid of the nametag and map icon sadly.

[Tinter]

Wouldn't that better be left up to the creator? You could use it for other situations where you might not want to attach it to something specific. I don't know any way either, I fear whatever allows players to see them is tightly coupled to what allows AI to see the object.

[commy2]

Yeah. The thing is, if we would implement the proposal as suggested in the OP, it would likely lead to a lot of confusion and anger :P This seems very clunky to say the least.

[Tinter]

Also my own use case for this has been in trying to script dogs. Due to them not inheriting from "CAManBase", AI will not target them.

[Tinter]

What would you suggest should be different? I will try to experiment with a model from scratch. I tested the large version of the grass cutter, it made no difference. I assume their LODs don't differ much, but I have no way of knowing. Removing the icons, would be nice, if at all possible I will try to look, but I don't know if that's possible. All I can think of is setting the icon and the string that shows up when you look at them to something blank, if they have specific values only for that purpose and they're not shared with as an example, the display name. As for the scripting, I envision these objects being an alternative for the problem of getting the AI to shoot at something, where the major problem is that the object in vanilla blocks the bullets. So the something the ai shoots at, is the target rather than what is behind the target. In this way it's more of a tool, and the person using it would know whether the target is to be deleted when the original object-to-shoot-at is dead.

[commy2]

1x1x1 VIEW GEO for spotting, tiny or empty (not none, because it would default to another LOD) FIRE GEO. Nothing else. Cube center at (0,0,0). No idea how to hide nametag and map icon. Doubt that is possible, aside from empty strings, which would cause problems identifying the dummy inside the editor.

[Tinter]

The name that shows up is directly tied to the displayName, so it's not possible I don't think. I looked at a setting that would avoid that stuff showing up in the first place, but no luck. The icon is directly tied to the icon property, so changing that would also make the icon not show up in 3den.

Here's the model attached, as simple as I could make it. box.zip

Is there any further work to be done?

[commy2]

Does the model work for this? It lacks a FIRE GEO. When omitting a LOD, the game falls back to another LOD. I don't want the game to fall back to the VIEW GEO LOD as replacement for a missing FIRE GEO LOD. There are rules for this, but I don't think anyone ever bothered to try all combinations.

[Tinter]

I've tested it, they do fire. It does let bullets pass through. I also tried with a FIRE GEO LOD and it made no difference, I'd assume because it has no materials assigned to it.

[commy2]

True. Good enough then. As long as the game doesn't complain about it in the RPT of course.

[Tinter]

The only .rpt complains are about hitpoints

20:18:53 Duplicate HitPoint name 'HitTurret' in 'B_TargetSoldier_tin'
20:18:53 Duplicate HitPoint name 'HitGun' in 'B_TargetSoldier_tin'

Which I assume is the base class doing something weird, I don't touch the hitpoint definitions.

Edit: Vanilla classes don't do it, will investigate. Another edit: Nothing obvious seems to be the cause, so I don't have any ideas. Proper edit: I messed up, vanilla does do it.

20:37:09 Duplicate HitPoint name 'HitTurret' in 'B_TargetSoldier'
20:37:09 Duplicate HitPoint name 'HitGun' in 'B_TargetSoldier'

[commy2]

This should fix that:

class CfgVehicles {
    class B_TargetSoldier;
    class B_TargetSoldier_tin: B_TargetSoldier {
        class Turrets {};
        model = "\A3\Structures_F\System\ClutterCutter_small_F.p3d";
        scope = 2;
    };
};