Let anything use guns = {} attribute

Things that we aren't going to implement
Post Reply
Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Let anything use guns = {} attribute

Post by Honktown »

I was messing with a problem someone else and I were privately talking about - that a turret only takes one ammo category. It got me thinking, why does anything need an attack_parameters with specific attack behavior at all? I understand for legacy reasons. Vehicle logic already exists for multiple guns available to an entity, and a turret or other entity could iterate over guns with which it can fire, and use the first with available ammo.

In relation to other games I've seen (blah blah no offense intended) they have things categorized by thing->hasweapons->weaponis->properties->useproperties. Factorio clearly has that an entity can have multiple guns, and they can even be filled with ammunition from inserter, though it doesn't get limited like a turret (let any entity also use automated-ammo-count, or better, the property is owned by the weapon).

Biters for example don't have a weapon that is their melee nibbles, but instead use attack_parameters.ammo_category. In a simple case, each weapon can be unique and be in-lined. I've seen a moddable game that went the full shebang, with each weapon having a re-usable targeting mechanism, fired a projectile, the projectile definition had a warhead, the warhead definition held the effect and damage, etc. Doesn't need to be that complicated, but a 1:1 mapping of some of the existing attack_parameters to a weapon definition, and the handling of a "guns", "offenses", "weapons", etc whatever you want to call it table that can have multiple values. This could be done mod side, to fill attack_parameters.ammo_category, if there were multiple entries permitted.

This is an idea, but it's not related to the game in itself, so I figured to post it here instead of in ideas and suggestions.

On the entity side, entities already own their attacking animations contained within attack_parameters, and the attack_parameters category is mostly defined like it is a weapon - which suggests to me that this might be doable with minimal changes to parsing and logic (there's some other values like cooldown which are outside attack_parameters, but I don't know if that's for other stuff and not an attack-refire cooldown).
I have mods! I guess!
Link

Pi-C
Smart Inserter
Smart Inserter
Posts: 1639
Joined: Sun Oct 14, 2018 8:13 am
Contact:

Re: Let anything use guns = {} attribute

Post by Pi-C »

Honktown wrote: ↑
Thu Dec 12, 2019 4:05 am
I was messing with a problem someone else and I were privately talking about - that a turret only takes one ammo category. It got me thinking, why does anything need an attack_parameters with specific attack behavior at all? I understand for legacy reasons. Vehicle logic already exists for multiple guns available to an entity, and a turret or other entity could iterate over guns with which it can fire, and use the first with available ammo.
If one turret could use different ammo types, you'd also have to find an algorithm deciding when it's time to switch weapons. Using weapons from left to right and switch once one weapon runs out of ammo may be the most simple, but obviously not the best choice. I tried that when trying to fix some issues with Autodrive (which has an option to auto-attack enemies in its range), and I wasn't quite content with a tank wasting shells on small biters and having nothing but bullets left when it came close to worms. So what should a static turret do if it's attacked by, say, some spitters out of bullet range and some biters? Attack the biters first with bullets and ignore the spitters? Load long-range ammo and kill the spitters first while the biters happily nibble at it? Switch ammo and target after each shot, and risk that one shot may not be enough to kill, and the attacker may regenerate between hits?

With Autodrive, I made it that the first weapon with ammo available would be selected by default, which works but may lead to wasting expensive ammo on cheap targets. Best case was if there was a player inside a tank: Then the player could switch weapons while the tank would aim and shoot. But you usually don't have human operators sitting in Factorio turrets. :-)
A good mod deserves a good changelog. Here's a tutorial (WIP) about Factorio's way too strict changelog syntax!

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Let anything use guns = {} attribute

Post by Honktown »

Pi-C wrote: ↑
Thu Dec 12, 2019 6:23 am
But you usually don't have human operators sitting in Factorio turrets. :-)
Funny you say that, I was playing with some data.raw and tried to convert a turret into a stationary vehicle with multiple guns. The results were about as good as you would expect.

In most games, you just have to deal with burning the wrong ammo or attacking the wrong units. The player doesn't auto-switch weapons for example. I've had a lot of times I wish it would, because wasting high-power rounds on small biters sucks. I know of plenty of RTS games where the attack logic is "attack nearest", which ends up with exactly what you're describing - the unit they're good against just keeps hammering them, while they burn their ammo/time on something they're weak against.

I wouldn't mind a simple last weapon = n, and the turret just loops over for 0..#weapons, i + last weapon % weapons. Honestly I really wouldn't mind if it even never changed weapons (not a vanilla mechanic? let modders deal with it). The benefit would be a script could use differently loadable ammunition, by going over the weapons table.

Speaking of spitters, a simplistic range model could make combat more interesting: if spitters are forced within short range, they try to nibble, pitifully, or run away, because their long-range has a minimum range.
I have mods! I guess!
Link

PyroFire
Filter Inserter
Filter Inserter
Posts: 356
Joined: Tue Mar 08, 2016 8:18 am
Contact:

Re: Let anything use guns = {} attribute

Post by PyroFire »

I don't really understand what you are suggesting, so i hope this is on the right track.

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.

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?

And second - there are some technical limitations involved with using guns and attack parameters that you may not be aware of or understand, such as:

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.


And the final nail in the coffin;
For a turrets gun, the turret has an internal target finder so it can "detect" and actually shoot at things.
Without this internal target finder, .attack_parameters and .guns would do literally nothing.
What are you are suggesting entails putting a target finder on literally every entity in the game (including trees).
And if you're talking about having multiple different weapons for a single entity to choose from... how are you going to swap that entities weapons?

You're insane.

-1.



*Edits
Honktown wrote: ↑
Thu Dec 12, 2019 6:37 am
I know of plenty of RTS games where the attack logic is "attack nearest", which ends up with exactly what you're describing - the unit they're good against just keeps hammering them, while they burn their ammo/time on something they're weak against.
This is target finder code, not "attack logic", and it's doing exactly what it was designed to do.
You can't just ducttape a target finder onto a tree.

Honktown wrote: ↑
Thu Dec 12, 2019 6:37 am
I wouldn't mind a simple last weapon = n, and the turret just loops over for 0..#weapons, i + last weapon % weapons. Honestly I really wouldn't mind if it even never changed weapons (not a vanilla mechanic? let modders deal with it). The benefit would be a script could use differently loadable ammunition, by going over the weapons table.
Well if you're going to do that and say "let modders deal with it"... Modders can already deal with it by seamlessly swapping entities & prototypes around during runtime and using composite entities.

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Let anything use guns = {} attribute

Post by Honktown »

PyroFire wrote: ↑
Thu Dec 12, 2019 6:51 am
I don't really understand what you are suggesting, so i hope this is on the right track.

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.

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?

And second - there are some technical limitations involved with using guns and attack parameters that you may not be aware of or understand, such as:

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.


And the final nail in the coffin;
For a turrets gun, the turret has an internal target finder so it can "detect" and actually shoot at things.
Without this internal target finder, .attack_parameters and .guns would do literally nothing.
What are you are suggesting entails putting a target finder on literally every entity in the game (including trees).
And if you're talking about having multiple different weapons for a single entity to choose from... how are you going to swap that entities weapons?

You're insane.

-1.



*Edits
Honktown wrote: ↑
Thu Dec 12, 2019 6:37 am
I know of plenty of RTS games where the attack logic is "attack nearest", which ends up with exactly what you're describing - the unit they're good against just keeps hammering them, while they burn their ammo/time on something they're weak against.
This is target finder code, not "attack logic", and it's doing exactly what it was designed to do.
You can't just ducttape a target finder onto a tree.

Honktown wrote: ↑
Thu Dec 12, 2019 6:37 am
I wouldn't mind a simple last weapon = n, and the turret just loops over for 0..#weapons, i + last weapon % weapons. Honestly I really wouldn't mind if it even never changed weapons (not a vanilla mechanic? let modders deal with it). The benefit would be a script could use differently loadable ammunition, by going over the weapons table.
Well if you're going to do that and say "let modders deal with it"... Modders can already deal with it by seamlessly swapping entities & prototypes around during runtime and using composite entities.
Have you seriously never modded an RTS? Here's the specific example I'm referring to, from Red Alert 2, rules.ini:

Code: Select all

; GI
[E1]
UIName=Name:E1
Name=GI
Image=GI
Category=Soldier
Primary=M60
Secondary=Para
Occupier=yes ; I can Occupy UC buildings
Prerequisite=GAPILE
CrushSound=InfantrySquish
Strength=125
Pip=white
Armor=none
TechLevel=1
Sight=5
Speed=4
Owner=British,French,Germans,Americans,Alliance
Cost=200
Soylent=150
Points=10
IsSelectableCombatant=yes
VoiceSelect=GISelect
VoiceMove=GIMove
VoiceAttack=GIAttackCommand
VoiceFeedback=GIFear
VoiceSpecialAttack=GIMove
DieSound=GIDie
Locomotor={4A582744-9839-11d1-B709-00A024DDAFD1}
PhysicalSize=1
MovementZone=Infantry
ThreatPosed=10	; This value MUST be 0 for all building addons
ImmuneToVeins=yes
ImmuneToPsionics=no
Bombable=yes
Deployer=yes
DeployFire=yes
; DeployTime=.022  ; PCG; Unused for now.  Was maybe going to make its way in if we did
; a more explicit state machine for deploying b/c of autodeploy.
VeteranAbilities=STRONGER,FIREPOWER,ROF,SIGHT,FASTER
EliteAbilities=SELF_HEAL,STRONGER,FIREPOWER,ROF
Size=1
Crushable=yes
DeploySound=GIDeploy
UndeploySound=GIUndeploy
ElitePrimary=M60E
EliteSecondary=ParaE
IFVMode=2
GI is General Infantry i.e. a generic human soldier.

Here's it's weapon, the M60:

Code: Select all

[M60]
Damage=15
ROF=20
Range=4
Projectile=InvisibleLow
Speed=100
Warhead=SA
Report=GIAttack
Anim=MGUN-N,MGUN-NE,MGUN-E,MGUN-SE,MGUN-S,MGUN-SW,MGUN-W,MGUN-NW
Here's the warhead:

Code: Select all

; general multiple small arms fire
[SA]
;CellSpread=.3
;PercentAtMax=.5
Verses=100%,80%,70%,50%,25%,25%,75%,50%,25%,100%,100%
InfDeath=1
AnimList=PIFFPIFF,PIFFPIFF
;Bright=yes
Bullets=yes
ProneDamage=70%
The verses determines the effectiveness against the games 11 different armor types.

Here's the projectile:

Code: Select all

; PCG; Use this for weapons that are invisble but are subject to cliffs, elevation and walls.
[InvisibleLow]
Inviso=yes
Image=none
SubjectToCliffs=yes
SubjectToElevation=yes
SubjectToWalls=yes
This is from an RTS that could handle thousands of units all in combat at the same time. The unit settings were even loaded on map init, not at start It was simple: the definitions are const'd somewhere in memory, and all the different units use the same definitions. Originally the game ran on Windows 95, on 64MB ram machines. On a 256MB ram machine with >1 GHz single core it ran great.

If you're trying to tell me Factorio can't handle doing things a game released just shy of 20 years ago could manage, are you insane?
I have mods! I guess!
Link

PyroFire
Filter Inserter
Filter Inserter
Posts: 356
Joined: Tue Mar 08, 2016 8:18 am
Contact:

Re: Let anything use guns = {} attribute

Post by PyroFire »

Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
Have you seriously never modded an RTS? Here's the specific example I'm referring to, from Red Alert 2, rules.ini:
Red alert 2 is not factorio.
They are obviously set up in different ways to do different things.
Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
GI is General Infantry i.e. a generic human soldier.
Or in other words, here's an NPC/AI entity that has a built-in target finder and navigation system.
I very much doubt you can put the weapon on a tree in Red Alert 2 without defining the tree as a "GI", so the irony there is no, Red Alert 2 also can't / doesn't do it.
Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
Here's it's weapon, the M60:
This isn't relevant but ok..?
Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
Here's the warhead:
About as relevant as the weapon itself.
Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
The verses determines the effectiveness against the games 11 different armor types.
And projectiles are just dumb entities that are waiting for a collision.

Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
This is from an RTS that could handle thousands of units all in combat at the same time.
And factorio can handle thousands of turrets all in combat at the same time.

But it's only turrets.
Trees don't have weapons.
If you made 100,000 turrets (the number of trees a factorio forest might have up to, or several) it would be a very different story.
Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
The unit settings were even loaded on map init, not at start It was simple: the definitions are const'd somewhere in memory, and all the different units use the same definitions. Originally the game ran on Windows 95, on 64MB ram machines. On a 256MB ram machine with >1 GHz single core it ran great.
This is not comparable to factorio.
Factorio can operate on maps that can range up to the 1000's of times larger than Red Alert 2 could ever dare to dream of handling.
Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
If you're trying to tell me Factorio can't handle doing things a game released just shy of 20 years ago could manage, are you insane?
I'm trying to tell you that it's not that simple to just put a target finder on literally everything.
Sure it can be done but that is not to say it should be done.
The performance hit for every tree searching for a target would be absolutely insane, as insane as this suggestion.

------------------------------------------------------

To better illustrate the problem, feel free to load up a fresh, brand new save and run this code using the console, and you might yet understand why i'm saying this is an insane idea

/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)




To further, further illustrate the problem, feel free to load up a fresh, brand new save and run this code using the console, and you might yet better understand that factorio definitely can't handle the thousands of turrets you thought it could

Step 1.

Code: Select all

/c for k,tree in pairs(game.player.surface.find_entities_filtered{type="tree"})do
	local tur=tree.surface.create_entity{name="gun-turret",position=tree.position,force=game.forces.player}
	tur.insert{name="firearm-magazine",count=50}
	tree.destroy()
end
Step 2. place a bunch of biters with /editor

Step 3.



Though it is to be said, this is pretty impressive:
Image
No real drain on idle turrets.

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Let anything use guns = {} attribute

Post by Honktown »

Or in other words, here's an NPC/AI entity that has a built-in target finder and navigation system.
No, the targeting system is owned by the weapon and projectile. It is why the weapon has a range, and although that projectile didn't have it, the projectiles can have what they target: anti-ground, anti-air, anti-sea, etc. No unit in RA2 determines how it attacks. Not one.
Factorio can operate on maps that can range up to the 1000's of times larger than Red Alert 2 could ever dare to dream of handling.
The algorithms for finding targets are exactly the same, whether the map is statically or dynamically allocated. Do you honestly think Factorio checks the whole map every tick for every possible thing?
/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)
Do it with your turrets. Factorio has optimizations to put shit to sleep while they don't need to shoot at anything.

Red Alert 2 has trees:

Code: Select all

[TREE01]
Name=Tree
IsFlammable=no
RadarColor=0,192,0
TemperateOccupationBits=4
SnowOccupationBits=6
Surprise, they don't have weapons. Guess what, if an entity doesn't have a weapon, then the targeting system never has to look at it, because by it's very definition it can't target things. You are literally trying to strawman my suggestion of making the weaponry system parsed differently over GODDAMN TREES.
I have mods! I guess!
Link

PyroFire
Filter Inserter
Filter Inserter
Posts: 356
Joined: Tue Mar 08, 2016 8:18 am
Contact:

Re: Let anything use guns = {} attribute

Post by PyroFire »

Honktown wrote: ↑
Thu Dec 12, 2019 8:20 am
No, the targeting system is owned by the weapon and projectile. It is why the weapon has a range, and although that projectile didn't have it, the projectiles can have what they target: anti-ground, anti-air, anti-sea, etc. No unit in RA2 determines how it attacks. Not one.
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.

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.
Honktown wrote: ↑
Thu Dec 12, 2019 8:20 am
The algorithms for finding targets are exactly the same, whether the map is statically or dynamically allocated. Do you honestly think Factorio checks the whole map every tick for every possible thing?
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:
Honktown wrote: ↑
Thu Dec 12, 2019 8:20 am
Do it with your turrets. Factorio has optimizations to put shit to sleep while they don't need to shoot at anything.
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.
Honktown wrote: ↑
Thu Dec 12, 2019 8:20 am
Surprise, they don't have weapons. Guess what, if an entity doesn't have a weapon, then the targeting system never has to look at it, because by it's very definition it can't target things. You are literally trying to strawman my suggestion of making the weaponry system parsed differently over GODDAMN TREES.
You may want to re-read.
PyroFire wrote: ↑
Thu Dec 12, 2019 6:51 am
I don't really understand what you are suggesting, so i hope this is on the right track.
From the sound of things so far (and still sounds so far), like the thread title:
Re: Let anything use guns = {} attribute
"Anything" includes trees.

Your misrepresentation of your own suggestion is not my doing and doesn't really change the key points so far.

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.

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 will now sign off by quoting myself from earlier pointing out that what you're asking for is already possible anyway.
PyroFire wrote: ↑
Thu Dec 12, 2019 6:51 am
Honktown wrote: ↑
Thu Dec 12, 2019 6:37 am
I wouldn't mind a simple last weapon = n, and the turret just loops over for 0..#weapons, i + last weapon % weapons. Honestly I really wouldn't mind if it even never changed weapons (not a vanilla mechanic? let modders deal with it). The benefit would be a script could use differently loadable ammunition, by going over the weapons table.
Well if you're going to do that and say "let modders deal with it"... Modders can already deal with it by seamlessly swapping entities & prototypes around during runtime and using composite entities.

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Let anything use guns = {} attribute

Post by Honktown »

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.
I have mods! I guess!
Link

Bilka
Factorio Staff
Factorio Staff
Posts: 3123
Joined: Sat Aug 13, 2016 9:20 am
Contact:

Re: Let anything use guns = {} attribute

Post by Bilka »

Anything which can have a weapon should be able to use guns = {}.
Let anything use guns = {} attribute
Which one do you want? Anything, or only things with weapons?

If the latter, what is a weapon? Your small biter example suggests that attack parameters are weapons, would that be the correct general definition?
I'm an admin over at https://wiki.factorio.com. Feel free to contact me if there's anything wrong (or right) with it.

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Let anything use guns = {} attribute

Post by Honktown »

Bilka wrote: ↑
Thu Dec 12, 2019 9:59 am
Anything which can have a weapon should be able to use guns = {}.
Let anything use guns = {} attribute
Which one do you want? Anything, or only things with weapons?

If the latter, what is a weapon? Your small biter example suggests that attack parameters are weapons, would that be the correct general definition?
Technically, using a guns table (as in ownership) and acting on it can be considered two different things. In a general sense, anything which can attack should be able to have a guns table, or some such equivalent. I'm still peeved so much information gets trimmed and hidden away from the transition from data to main-game, including extraneous tables. (and don't yell at me about the guy's vehicle bug, I saw you judging me)

The biter's melee can be considered a weapon, yes. Although we may not normally consider such a thing a weapon, all the concepts attributable to it apply to range attacking. Such as how fish get implemented as healing items by being capsules that do negative damage to yourself. An old trick for signed integer "damage".

Basically, as it is, I believe I could take most of what's in a biter's attack and just throw it in a table, and assign it, and the parser would be fine (haven't tried). However, artillery wagons and turrets have their weapon as a name - a first layer abstraction - and vehicles have their weapon-names abstracted into a table of names - the second layer I'd like to see abstracted for any entity which currently is stuck with a single named weapon or hard-coded attack-parameter table. I don't give a damn if literally nothing had weapon-switching logic. There's a programming argument to be made here in simplifying the code path and representation, but there's game limitations in that one can't assign weaponry with multiple categories of ammunition to anything but vehicles, and even then, it's not multiple categories of ammunition, but weaponry with different categories.
I have mods! I guess!
Link

PyroFire
Filter Inserter
Filter Inserter
Posts: 356
Joined: Tue Mar 08, 2016 8:18 am
Contact:

Re: Let anything use guns = {} attribute

Post by PyroFire »

I've already signed off from this discussion but i thought this was funny.
Honktown wrote: ↑
Thu Dec 12, 2019 9:41 am
I never said because Red Alert 2 can do it, Factorio should be able to
Makes me wonder why you mentioned Red Alert 2 at all if that's not what you were saying.

I guess i must have just imagined you saying this:
Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
Have you seriously never modded an RTS? Here's the specific example I'm referring to, from Red Alert 2, rules.ini

...

If you're trying to tell me Factorio can't handle doing things a game released just shy of 20 years ago could manage, are you insane?
Yep, you're definitely not saying because Red Alert 2 could do it 20 years ago, that Factorio should be able to do it now.
It's totally just my imagination and i'm completely insane.

Sorry friend but there goes your credibility with me :/
Last edited by PyroFire on Thu Dec 12, 2019 10:36 am, edited 2 times in total.

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Let anything use guns = {} attribute

Post by Honktown »

I forgot to add, I don't necessarily even desire an entity be able to switch to another weaponry (as in it doesn't need a variable/offset/address for which weapon it's currently using). On the actual side of using this idea, someone and I were talking about using different ammunition for a targeting remote, and he didn't want the base remote to use the non-mod ammo. If an entity could only ever refer to it's first weapon in existing code, that's 100% fine with me - as long as an entity could have different ammo stocked, which is a change in data needed.
PyroFire wrote: ↑
Thu Dec 12, 2019 10:26 am
I've already signed off from this discussion but i thought this was funny.
Honktown wrote: ↑
Thu Dec 12, 2019 9:41 am
I never said because Red Alert 2 can do it, Factorio should be able to
Makes me wonder why you mentioned Red Alert 2 at all if that's not what you were saying.

I guess i must have just imagined you saying this:
Honktown wrote: ↑
Thu Dec 12, 2019 7:17 am
Have you seriously never modded an RTS? Here's the specific example I'm referring to, from Red Alert 2, rules.ini

...

If you're trying to tell me Factorio can't handle doing things a game released just shy of 20 years ago could manage, are you insane?
Yep, you're definitely not saying because Red Alert 2 could do it 20 years ago, that Factorio should be able to do it now.
It's totally just my imagination and i'm completely insane.

Sorry friend but there goes your credibility with me :/
You said I was insane because of multiple reasons it couldn't be practically possible. Don't say something's impossible when someone's already doing it.
I have mods! I guess!
Link

Bilka
Factorio Staff
Factorio Staff
Posts: 3123
Joined: Sat Aug 13, 2016 9:20 am
Contact:

Re: Let anything use guns = {} attribute

Post by Bilka »

Honktown wrote: ↑
Thu Dec 12, 2019 10:34 am
On the actual side of using this idea, someone and I were talking about using different ammunition for a targeting remote, and he didn't want the base remote to use the non-mod ammo.
So 78576. All the suggestion options given in the first post there are much more likely to happen than this request. Moving to won't implement.

Usually, abstract suggestions to solve concrete problems are unlikely to be implemented unless you give the concrete problem you want to solve, and the reasoning why no concrete solution works.
I'm an admin over at https://wiki.factorio.com. Feel free to contact me if there's anything wrong (or right) with it.

PyroFire
Filter Inserter
Filter Inserter
Posts: 356
Joined: Tue Mar 08, 2016 8:18 am
Contact:

Re: Let anything use guns = {} attribute

Post by PyroFire »

Honktown wrote: ↑
Thu Dec 12, 2019 10:17 am
However, artillery wagons and turrets have their weapon as a name
viewtopic.php?f=28&t=78012

Even if you could change or add guns, it wont necessarily behave how you think it will.
Honktown wrote: ↑
Thu Dec 12, 2019 10:34 am
Don't say something's impossible when someone's already doing it.
For the third and final time,
What you are asking for is not only already possible, it has also already been done before
PyroFire wrote: ↑
Thu Dec 12, 2019 6:51 am
Honktown wrote: ↑
Thu Dec 12, 2019 6:37 am
I wouldn't mind a simple last weapon = n, and the turret just loops over for 0..#weapons, i + last weapon % weapons. Honestly I really wouldn't mind if it even never changed weapons (not a vanilla mechanic? let modders deal with it). The benefit would be a script could use differently loadable ammunition, by going over the weapons table.
Well if you're going to do that and say "let modders deal with it"... Modders can already deal with it by seamlessly swapping entities & prototypes around during runtime and using composite entities.
Proof: https://mods.factorio.com/mod/uniturret

Disagreements are fine.
But getting angry, spamming all caps and acting like i'm personally attacking you is not.

I'm attacking your idea because i believe it is a bad one.
I am not attacking you personally, though i do understand my writing can sometimes come across as arrogant.
It's really not personal.

nosports
Filter Inserter
Filter Inserter
Posts: 274
Joined: Fri Jan 19, 2018 5:44 pm
Contact:

Re: Let anything use guns = {} attribute

Post by nosports »

PyroFire wrote: ↑
Thu Dec 12, 2019 7:38 am
------------------------------------------------------

To better illustrate the problem, feel free to load up a fresh, brand new save and run this code using the console, and you might yet understand why i'm saying this is an insane idea

/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)




To further, further illustrate the problem, feel free to load up a fresh, brand new save and run this code using the console, and you might yet better understand that factorio definitely can't handle the thousands of turrets you thought it could

Step 1.

Code: Select all

/c for k,tree in pairs(game.player.surface.find_entities_filtered{type="tree"})do
	local tur=tree.surface.create_entity{name="gun-turret",position=tree.position,force=game.forces.player}
	tur.insert{name="firearm-magazine",count=50}
	tree.destroy()
end
Step 2. place a bunch of biters with /editor

Step 3.



Though it is to be said, this is pretty impressive:
Image
No real drain on idle turrets.
:o That certainly is very impressive...
I think you should transfere it into a mod.....
At least for some trees when not all trees...

This would be a very hardcore modding of the map when the true enemy bites back... :twisted:
Thought the start would be slow when settling, but after some (short) time all is cleared and should back to relatively normal

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Let anything use guns = {} attribute

Post by Honktown »

PyroFire wrote: ↑
Thu Dec 12, 2019 10:48 am
Honktown wrote: ↑
Thu Dec 12, 2019 10:17 am
However, artillery wagons and turrets have their weapon as a name
viewtopic.php?f=28&t=78012

Even if you could change or add guns, it wont necessarily behave how you think it will.
Honktown wrote: ↑
Thu Dec 12, 2019 10:34 am
Don't say something's impossible when someone's already doing it.
For the third and final time,
What you are asking for is not only already possible, it has also already been done before
PyroFire wrote: ↑
Thu Dec 12, 2019 6:51 am
Honktown wrote: ↑
Thu Dec 12, 2019 6:37 am
I wouldn't mind a simple last weapon = n, and the turret just loops over for 0..#weapons, i + last weapon % weapons. Honestly I really wouldn't mind if it even never changed weapons (not a vanilla mechanic? let modders deal with it). The benefit would be a script could use differently loadable ammunition, by going over the weapons table.
Well if you're going to do that and say "let modders deal with it"... Modders can already deal with it by seamlessly swapping entities & prototypes around during runtime and using composite entities.
Proof: https://mods.factorio.com/mod/uniturret

Disagreements are fine.
But getting angry, spamming all caps and acting like i'm personally attacking you is not.

I'm attacking your idea because i believe it is a bad one.
I am not attacking you personally, though i do understand my writing can sometimes come across as arrogant.
It's really not personal.
I never said they change their ammo they use. I never said the game had to do anything based on the information being available. Stop saying I want the game to DO anything. That is what is offensive, putting words in my mouth over and over.

The second mod changes a single ammunition, it does not let an entity have multiple ammunition categories exist in it. There is literally no way in the base game for anything other than a vehicle have multiple ammunition in stock. Might be a workaround with stuffing ammo into an inventory, and then checking that.
Bilka wrote: ↑
Thu Dec 12, 2019 10:42 am
Honktown wrote: ↑
Thu Dec 12, 2019 10:34 am
On the actual side of using this idea, someone and I were talking about using different ammunition for a targeting remote, and he didn't want the base remote to use the non-mod ammo.
So 78576. All the suggestion options given in the first post there are much more likely to happen than this request. Moving to won't implement.

Usually, abstract suggestions to solve concrete problems are unlikely to be implemented unless you give the concrete problem you want to solve, and the reasoning why no concrete solution works.
Nothing but a vehicle can have multiple ammunitions stocked, and it is impossible to have a script act on anything other than a singular ammunition stocked [for non-vehicle entities].

I can see how that's not a problem for the vanilla game, but from a modder side it makes some things difficult, and other things impossible. As the above mod shows, it's easy enough to swap out entities for a singularly loaded ammunition, but I can't load multiple different categories into one. I'll have to experiment to see if different ammo prototypes can even be loaded into a single turret (with multiple slots for ammo) as long as they are of the same category, if something has multiple ammunition slots.

@nosports
I'd try out a mod which randomized nearly everything with other-things. The map would probably quickly empty as everything killed each-other... find a way to make it fun and you have a mod
I have mods! I guess!
Link

nosports
Filter Inserter
Filter Inserter
Posts: 274
Joined: Fri Jan 19, 2018 5:44 pm
Contact:

Re: Let anything use guns = {} attribute

Post by nosports »

Honktown wrote: ↑
Thu Dec 12, 2019 11:40 am
@nosports
I'd try out a mod which randomized nearly everything with other-things. The map would probably quickly empty as everything killed each-other... find a way to make it fun and you have a mod
I thought of (some) trees having secretly a gun & sufficient amuniton.
May be a special gun/amunition but for starters i think the just normal would do.

The give the trees (all / some; maybe for rocks also) this definiton, so it would be not as easy to cut dont the trees.

I would view this as brothers of the spiter, who knows hows the wildlife over there sorted out ? :P

Honktown
Smart Inserter
Smart Inserter
Posts: 1025
Joined: Thu Oct 03, 2019 7:10 am
Contact:

Re: Let anything use guns = {} attribute

Post by Honktown »

Semi-related, how is player gun information stored? I went looking for that and it's not in player, and character information redirects me to entities, which I don't see a weapon-inventory for (I can check the prototypes - not for the character).

@nosports
NOT THE BEEEEEEEEEES (it can be a script event, on entity died-> wastree). You could have tree-turrets if you really wanted, some fields are necessary but you could probably populate them with nothing useful. Throw wasps or rocks at people. If a tree falls in the forest, every other tree hears, etc.
I have mods! I guess!
Link

nosports
Filter Inserter
Filter Inserter
Posts: 274
Joined: Fri Jan 19, 2018 5:44 pm
Contact:

Re: Let anything use guns = {} attribute

Post by nosports »

Honktown wrote: ↑
Thu Dec 12, 2019 11:49 am
@nosports
NOT THE BEEEEEEEEEES (it can be a script event, on entity died-> wastree). You could have tree-turrets if you really wanted, some fields are necessary but you could probably populate them with nothing useful. Throw wasps or rocks at people. If a tree falls in the forest, every other tree hears, etc.
Yes so basically a gun-turret as tree was my idea.
some thorns as munition with a sufficient stacksize.
(as long as there is no recipe no one can manufacture this, thought maybe it would be fun for a death-world to gow some trees out of a greenhouse to stop the biter-horedes with converted trees

Post Reply

Return to β€œWon't implement”