Remove friendly monsters see distance cap.

[Accensus]

So I had this idea about making a temporary companion that's supposed to act as a fireball thrower at distant enemies, but suddenly found myself capped to a 1280mp sight range, which completely rustled my jimmies in the sense that it is simply too low. Could this restriction be lifted, please?

[Arctangent]

Considering this is a performance thing, removing it seems unwise. However, moving the limit to an actor property or user setting would probably probably fit pretty well.

[Accensus]

If the story I got told is real, it caused a performance issue because someone, somewhere, had decided to spam friendly marines, which tanked performance, so it's sheer lunacy and not an actual performance issue.

As for the property, it's already set by A_LookEx and likely has a default.

[Arctangent]

so it's sheer lunacy and not an actual performance issue.

I take it you don't know about perhaps the biggest user of friendly monsters, which uses quite a lot of them?

[Accensus]

Ah-huh. So hard-capping the entire engine instead of leaving it up to the mod devs to fix their performance issues is perfectly acceptable? Because, like I said, A_LookEx has a seedist parameter.

[Arctangent]

I feel like you don't exactly understand why we have [wiki]A_FireProjectile[/wiki] when [wiki]A_FireCustomMissile[/wiki] could've just been fixed.

It's because ruining compatibility with mods that already exist is generally a bad thing to do.

[Rachael]

I feel like this is straying from the original point too much.

This is getting implemented into QZDoom and may eventually end up in GZDoom at a later date. This is going forward.

There is a caveat, though:

Ultimately I am going to be making it a MAPINFO flag to allow this to happen.
A) This will not affect existing mods. They will have that limitation.
B) If this flag ends up in the wiki, it comes with the warning that using it outside of very specific and special circumstances is a bad idea.

Yes, I am aware that abusive modders are frequently on the scene. After all they're the ones with literally hundreds of garbage threads in Closed Feature Suggestions asking the developers to limit or remove some fundamental features from the engine just for their own niche sakes. I know this flag will be abused by said people, as well. Fuck them. Let them have that flag, and I will be the first to say "at least I had the option not to play that." It's not like I can stop them from abusing it, or stop them finding any other way to cause problems.

This is being implemented for people (like Lud) who have legitimate uses for it. And Lud will know that there are restrictions to how this feature will work. Having this flag means you can have 1, maybe 2 friendly monsters on your map, max. Or else it becomes lag city. I know there are people who can be responsible when using this. I know I have the option to avoid those that aren't.

So yeah, I hope we can stop this argument over the feature, now.

[Arctangent]

This is being implemented for people (like Lud) who have legitimate uses for it. And Lud will know that there are restrictions to how this feature will work. Having this flag means you can have 1, maybe 2 friendly monsters on your map, max. Or else it becomes lag city. I know there are people who can be responsible when using this. I know I have the option to avoid those that aren't.

I'm not sure why you're phrasing this as if the very first thing I said wasn't about it being fine, just not as something that's on by default rather than being an override.

[XxMiltenXx]

I don't know how feasible or easy to implement it is, but I think an actor flag would be better instead of a MAPINFO flag, simply because you can then actually limit the amount of actors that can be spawned that have this flag.
E.g. the max is 2 actors with said flag, if a 3rd one with it is attempted to be spawned, it will either remove the first or simply cannot spawn until one of the others are gone (dead/destroyed/removed). This flag should only work if the actor is not dead.

This way no one could abuse this as there is simply no way to spawn more than 2 (or whatever limit is reasonable)

[Accensus]

What if you want to spawn 4 actors at 2048 see instance instead of 1 at max distance? The idea is to leave the performance issues in the hands of the modder rather than cap them for everybody. I don't intend to use 15 actors with 10000 view distance. More like 3 at 2048.

[Rachael]

I don't know how feasible or easy to implement it is, but I think an actor flag would be better instead of a MAPINFO flag, simply because you can then actually limit the amount of actors that can be spawned that have this flag.
E.g. the max is 2 actors with said flag, if a 3rd one with it is attempted to be spawned, it will either remove the first or simply cannot spawn until one of the others are gone (dead/destroyed/removed). This flag should only work if the actor is not dead.

This way no one could abuse this as there is simply no way to spawn more than 2 (or whatever limit is reasonable)

This was brought up before - but making it an actor flag is simply 100% out of the question. I need to keep my actor's flag lists matching GZDoom as much as possible. If GZDoom picks this up itself then we can change it to being a flag. If you understand both the ZDoom source concerning actors, as well as how Git handles it, you understand why.

Actually from a technical standpoint making it a flag would be about the same difficulty as putting it in MAPINFO anyway. I just don't want to deal with the ensuing merge nightmare.

[Xaser]

I'm confused by this discussion about MAPINFO and flags. The distance cap is a number -- it would make the most sense to add it as an actor property.

[Rachael]

I was thinking that as a possibility, too.

[Xaser]

Yeah, that'd be the most flexible way going forward -- make it a property, default it to 1280 (or whatever the current cap is), then let folks customize it at will. Plus it lets you avoid Flag Hell(tm) on the dev side of life.

[Rachael]

I don't know if I can really do the distance cap of 1280 as-is, because that's not how it works internally. What actually happens internally is it's a blockmap scan of 128 map units per, at a maximum of 10 blockmap units. That is probably what the customizable part will be.