Incorrect, the target finder is owned and operated by the hosting entity, and it applies properties to the target finder based on what the weapon gives it.
Even if your AI had 100 weapons, it would still only use one target finder.
No. There is a single function which determines whether we can attack and to initiate it, owned by
nobody, which is hopefully the same in Factorio: for entities to check within range, see if we can target them and initiate attack behavior. That's it. No unit has a unique method of finding targets.
And the projectile - as i said - is just a 'dumb' entity waiting for a collision, so i'm not sure why you're mentioning that, it's fairly irrelevant to anything here.
The projectile owns what can be attacked. It's a difference of whether or not the entity type owns variables for the targeting mechanics, or the weapon does. In even the most retarded way Factorio could implement an even slightly more modular weapon system, the weapon could determine the range, as it does now. Even though vehicles have their own weapons with different ranges, there's no need for it in a definition where all we want is different ammo categories.
By the way, Factorio
already supports a modular weapon definition: "artillery-wagon-cannon" is used by artillery turrets and artillery wagons, every single user-equippable weapon, and defense equipment. The system exists to use a weapon with parameters not explicitly described in the entity. Let me repeat that: THE SYSTEM ALREADY EXISTS. The only relevancy to what I want is A) whether the weapon is inlined into attacking logic and B) that it's a read-only value.
Not sure if delusional or just doesn't understand the issues i'm raising.
They are quite different.
Specifically, not the distance checking part (that's just basic trig), but the caching part so that you don't need to iterate the whole map every tick.
In fact, you yourself have specified an example of where factorio's and red alert's target finder stuff differs:
Red Alert 2 has optimizations as well. Otherwise you wouldn't have tens of thousands floating around, and then the FPS tanking hard when something gets within range. And I'm not joking. It was easy enough to crash the game by speeding up your unit building (without any modding) and overflowing a presumably 16-bit limit in unit selection when selecting all of them (not sure if signed or unsigned, but lol when it happened).
I ended up doing that.
see the edits above.
It's pretty impressive while idle, but tanks hard when there's a bunch of biters attacking.
I don't see you doing:
Code: Select all
/c script.on_event(defines.events.on_tick,function() for k,tree in pairs(game.surfaces[1].find_entities_filtered{type="tree"}) do local enemy=tree.surface.find_nearest_enemy{force=game.forces.player,position=tree.position,max_distance=20} end end)
but with turrets. You spawned a bunch of units and the FPS tanked, as is expected, but you didn't initiate a scan every tick for every turret as you did with trees. Even that shows even with thousands of turrets existing, they're put to sleep when they're not targeting. Even if you literally made every tree a turret, by your own admission and testing, it wouldn't create preposterous lag. That is not what I asked, that every entity should be able to become a turret, yet you went and did it and still can't show there's a performance reason to not let thousands of units actively have guns (which is in no way what I asked, for god's sake, I don't know how you're missing this).
"Anything" includes trees.
Your misrepresentation of your own suggestion is not my doing and doesn't really change the key points so far.
It's not a misrepresentation per-se. Anything which can have a weapon should be able to use guns = {}. If you don't get that, only cars can have the guns attribute, and everything else except artillery turrets are stuck with the "weapon must be defined here" attribute. The only reason they can't handle abstracting that is their parser doesn't handle multiple weaponry categories (even though it clearly does for vehicles, and weapons can be referred to by name in artillery, with the weapon containing the ammunition categories). It literally needs no logic from one weapon to the next, as there is never a reason under normal conditions to even switch weapons automatically.
Meaning your fallacies are:
https://yourlogicalfallacyis.com/the-fallacy-fallacy - i did not strawman your argument, and even if i did, it does not change the truth in my raised points.
It is entirely possible to make a claim that is false yet argue with logical coherency for that claim, just as it is possible to make a claim that is true and justify it with various fallacies and poor arguments.
https://yourlogicalfallacyis.com/ambiguity - you did not reasonably express your idea in a way that it could be widely understood, leading us down this apparent tangent. (So if you're not talking about turning literally everything into a turret... what
Are you talking about then?)
You used a double meaning or ambiguity of language to mislead or misrepresent the truth.
https://yourlogicalfallacyis.com/composition-division - Factorio has nothing to do with Red Alert 2, and you're suggesting that, "because weapons!", that principles in one can be applied to the other. That's simply false, particularly in this example.
You assumed that one part of something has to be applied to all, or other, parts of it; or that the whole must apply to its parts.
https://yourlogicalfallacyis.com/appeal-to-nature - You have suggested that because Red Alert 2 can naturally and inherently have a turret-like entity that can carry multiple different weapons, that the same should be true for Factorio. This is untrue.
You argued that because something is 'natural' it is therefore valid, justified, inevitable, good or ideal.
https://yourlogicalfallacyis.com/anecdotal - The only examples you have given so far to justify your reasoning and idea here is fairly isolated, comprising of only "Red Alert 2 can have multiple weapons on its units, so why can't factorio!". This is simply untrue.
You used a personal experience or an isolated example instead of a sound argument or compelling evidence.
Strawman 1:
You're making an assumption here that, because .guns appears to you to be a self contained program (which it isn't), that .guns should be put on anything.
I never suggested that.
Strawman 2:
First - you haven't defined the parameters here very well, e.g. what does a transport belt need a weapon for? What does a pipe need a weapon for? what does an assembler need a weapon for?
I didn't say they needed a weapon. I said I want the attribute to be usable.
1. For a players gun, he can manually fire it.
2. For a vehicle gun, the player can enter the vehicle and manually fire it.
I never said I wanted multiple weapons automatically fireable.
Someone else suggested the weapons be automatically switchable, so I offered an implementation.
Reread what I typed 1000x, and you will never see I wanted them automatically switchable.
You have claimed my proposal is something that it is not, and are claiming it is invalid from arguing against that. That is literally the definition of a strawman.
I have expressed my proposal succinctly: I wanted multiple guns to be available to an entity definition (which would require multiple variables for how much ammo, an expectation of inserters to insert ammo, which for vehicles they already can). I did not ask of them to do anything but exist in the prototype. The reason is for reasons of abstraction, and for scripts to act on. It's a
bad model to have weapons specified with three different sets of requirements based on the entity: see small-biters, artillery, and vehicles. These require three separate abstractions, which are incompatible with each-other in programming, to describe the same information.
Red Alert 2's and Factorio's
implementation of what they
do with their scripting is not at question here. What is worth calling into question is Factorio's
limitations compared to a more thorough model, which is able to unify the three different behaviors of describing a weapon that Factorio expresses.
Factorio clearly
can have multiple weapons inherent to an entity, and have ammunition be insertable. For other entities to not have this ability is either exceptional, or it is the norm and vehicles are exceptional. I'll note again, I never said I wanted turrets to be able to act on multiple weapon types, but that multiple weapons can exist as information, which already exists for other entities, and that the model be unified to an abstractable form.
I never said because Red Alert 2 can do it, Factorio should be able to, except when YOU began strawmanning my proposal under that condition. I used it as a model of why this model is good, and why the current implementation has surprising limitations.
Now, i'm not saying your idea is neccessarily bad, what i'm saying is the way you have presented your idea makes me horribly disagree with it because it is not thought out at all, and draws from comparisons / source material that fundamentally doesn't apply to Factorio.
Between technical limitations to how do you implement the control scheme, I believe your idea is not really well thought out at all and should not be implemented, but that's just my $0.02.
Perhaps try giving some concrete examples of the types of outcomes you are hoping to see.
And when i say "types of outcomes", i mean to specifically describe what you want factorio to do because so far all i see is "Make it so every entity can be a turret with infinite weapons because i saw this other game do that this one time".
I have exactly said what I wanted Factorio to be able to do. You have misunderstood, distorted what I said, and could not specifically address the issue: WHY SHOULD OR SHOULDN'T A THING HAVE A GUNS TABLE INSTEAD OF HARD-CODING A SINGLE WEAPON WHEN THE MECHANISMS EXISTS TO HAVE MULTIPLE.
That certainly is very impressive...
