How to set a modded entity to a force that is untargetable

[Barerock]

I'm attempting to make IR3's Big Wooden Pole entity untargetable for Rampant's AI. Previous discussions show that making [entity] invulnerable is not an option that works well; however, that same discussion failed to note how they made [entity] neutral, which fixed the issue to an acceptable degree.

I have looked through the lua resource for Factorio and realised I very much do not know what I am doing, and the Force tool in the ingame editor seems limited to manual changes that don't persist or automatically become assigned to things when placed.

I know there's a way to do this, but I don't know the tools or language to make it happen. After a brief discussion with Deadlock, I know that entities are not preassigned forces and use the AUTO mechanic.

Thanks for any help offered.

[Pi-C]

I'm attempting to make IR3's Big Wooden Pole entity untargetable for Rampant's AI. Previous discussions show that making [entity] invulnerable is not an option that works well; however, that same discussion failed to note how they made [entity] neutral, which fixed the issue to an acceptable degree.

You can set entity.force.

I have looked through the lua resource for Factorio and realised I very much do not know what I am doing, and the Force tool in the ingame editor seems limited to manual changes that don't persist or automatically become assigned to things when placed.

If you look at the top of the description of LuaEntity, you'll find "Class LuaEntity extends LuaControl" -- which means that LuaEntity inherits the properties of LuaControl. Now, LuaControl "is an abstract base class containing the common functionality between LuaPlayer and entities (see LuaEntity)." This class provides access to LuaForce, so you can use all of these variants to set it in control.lua:

Code: Select all

local neutral = game.forces.neutral

entity.force = neutral
entity.force = neutral.name
entity.force = neutral.index

[Barerock]

This is all incredible information that would solve my problem in a jiffy if I knew how to use it, instead, I am a pleb. Could you be so kind as to define the tools by which I can implement your heroic information?

EDIT: I totally skipped what control.lua meant when I read this, but reading it out loud got me where I needed to go. I know exactly where control.lua might be.

[Barerock]

Okay, I'm more informed about a few steps I tried before asking for help here, but I am still unaware of where this information could possibly be in IR3's files. Searching for "pole" in the control luas doesn't reward me with anything relevant. I'm afraid I am a complete novice (an overstatement, really) when lua is concerned. There is no code\control\control.lua, if that clarifies where this step is going wrong.

Now that I know where I should maybe be looking I will try to ferret out the locations/method of action tomorrow when I have more time. It's currently quite late.

Thanks again.

[Qon]

https://lua-api.factorio.com/latest/

all the info you need with tutorial etc

[Barerock]

https://lua-api.factorio.com/latest/

all the info you need with tutorial etc

I know where modding resources are, what I need is a hand to guide where I go from there outside of: "here's a dictionary, learn the entire thing," when what I want is to know the definition of one word and I don't speak the language. Pardon my directness, but that isn't helpful.

[Deadlock989]

Qon's habitual rudeness aside, this is not a simple request. In your analogy, this isn't just a word, it's a whole paragraph. There's no one "setting" or property in IR3 that will make big wooden poles less appealing to Rampant AI. As I said to you elsewhere, in vanilla, biters are focused on destroying things that have the is_military_target property set to true in their prototype or by script. Vanilla biters can also sometimes deliberately attack things if they are completely obstructing their path. But IR3 big power poles aren't military targets. If the Rampant AI is targeting power poles willy-nilly, it's because that's what Rampant is scripted to do. There's nothing you can change in IR3's code that will change that (and it would be overwritten the next time you update IR3 anyway).

You've read somewhere (not seen where) that setting an entity's force to neutral stops Rampant AI from targeting it. That sort of makes sense because by default the neutral force isn't enemies with anyone, but it's a definitely using a sledgehammer to crack a walnut. What you are really asking for is a separate small mod with a control stage script (control.lua) that listens to every event that handles entities being built, and changes the entity to the neutral force if it is a big power pole. There are several different ways things can get built (by player, bot, script, cloning in editor) so that's at least five different handlers. Something like this:

Code: Select all

local function built_handler(event)
	local entity = event.created_entity or event.entity or event.destination
	if entity and entity.valid and entity.name == "big-wooden-pole" then
		entity.force = "neutral"
	end
end

script.on_event({
	defines.events.on_built_entity,
	defines.events.on_robot_built_entity,
	defines.events.script_raised_built,
	defines.events.script_raised_revive,
	defines.events.on_entity_cloned,
}, built_handler)

You will need to create a new mod (follow the tutorial) and put that in a control.lua script. Not tested, no idea if it will have the desired or any effect, but it's roughly what you've asked for.

I don't know what the consequences on an electric network are of having a mixture of different forces for its power poles. Maybe it's completely fine. Maybe it will cause side effects, maybe you can live with those effects, maybe it will screw everything up. I don't know, someone else might. I do know that you can't mark other forces' structures for deconstruction and your own bots won't touch them. So personally I would never use this method to try and influence Rampant AI's behaviour. I hear it's supposed to be difficult anyway.

[Qon]

Pardon my directness, but that isn't helpful.

I can pardon your directness, np. I can't forgive your attitude though.

https://lua-api.factorio.com/latest/

all the info you need with tutorial etc

I know where modding resources are, what I need is a hand to guide where I go from there outside of: "here's a dictionary, learn the entire thing,"

"I refuse to read the tutorial, now tell me what it says"

The page I linked is just a few sentences. If that is "the entire thing" and you can't even read that then why should I bother helping you?
Or if you don't read the tutorial so you can't understand the basic terminology, why come here and complain about not understanding the words and saying that we should explain it to you. If you want to skip the tutorial and documentation then you should be fine on your own. And if you can't progress without help then you don't deserve it, if you skipped the help that was offered.

I never said "read all documentation pages".

If there's anything confusing after you have tried reading the page I linked and the tutorial then you can ask questions then.

But if you had just read the pages I linked instead of just dismissing them before reading you would have seen that the tiny amount of text has "Runtime stage - control" as a header. Guess what link you should click?

Runtime Stage - control

The runtime stage takes place alongside normal gameplay, and allows interaction with the game world in a number of ways. It is based on events being fired for mods to react to, with the API functionality being provided via objects of various classes.

If you click the link you see this page:

Runtime API Docs

During the runtime stage, the game fires events for mods to react to, with functionality being accessible via the methods and attributes of various classes. To access instances of these classes, a handful of global objects are provided, as listed below.

The runtime stage is the game's third and final stage, taking place after the settings and prototype stages. All important details are explained via the Data Lifecycle.

The data lifecycle link has a lot more info, this page is densely packed with pretty much everything on how a mod is structured. This is required reading imo, if I was the dictator of the world I would force modders to read this page and give very cruel punishments to those who ask questions as a direct consequence of not bothering to look at it. But the tutorial teaches you the basics as well.

when what I want is to know the definition of one word and I don't speak the language.

You don't want the definition of one word. You don't understand the difference between prototype and runtime stage, so if I tell you the answer you wont understand and will just ask about the "next word", and so on. You are trying to trick me into writing your mod for you without knowing what it takes to do it. I see the whole sentence, you are lost.

control.lua is directly in the mod directory. If it doesn't exist then you create it and write your runtime code there. Though if you are making a mod to fix things then don't edit anything within someone elses mod, do your edits from your own mod. The pole prototype is read-only in this stage, you can't make the prototype "pole" change force into neutral here. But you can change the force of individual entities, like poles, as they are built in the game. For this you need the runtime events API.

Now I've taught you many "words" and you have many sentences left to learn. So show me that you can do that without help...

[Pi-C]

… what I need is a hand to guide where I go from there …

Did you find the Modding tutorial section of the wiki?

[Barerock]

You've read somewhere (not seen where) that setting an entity's force to neutral stops Rampant AI from targeting it. That sort of makes sense because by default the neutral force isn't enemies with anyone, but it's a definitely using a sledgehammer to crack a walnut. What you are really asking for is a separate small mod with a control stage script (control.lua) that listens to every event that handles entities being built, and changes the entity to the neutral force if it is a big power pole. There are several different ways things can get built (by player, bot, script, cloning in editor) so that's at least five different handlers. Something like this:

Code: Select all

local function built_handler(event)
	local entity = event.created_entity or event.entity or event.destination
	if entity and entity.valid and entity.name == "big-wooden-pole" then
		entity.force = "neutral"
	end
end

script.on_event({
	defines.events.on_built_entity,
	defines.events.on_robot_built_entity,
	defines.events.script_raised_built,
	defines.events.script_raised_revive,
	defines.events.on_entity_cloned,
}, built_handler)

You will need to create a new mod (follow the tutorial) and put that in a control.lua script. Not tested, no idea if it will have the desired or any effect, but it's roughly what you've asked for.

This info is exactly what I needed, thank you super duper; you've been quite courteous elsewhere as well. I am currently experimenting with Rampant's AI and have found that the military target flags definitely are normal here. Expanding the distance between walls and power poles negates attacks and the expected vanilla behavior persists. I had quite a few issues experimenting with it and thought I'd follow an alternate route in downtime to see if one or the other solution was best.

Also, as far as I can tell, neutral power poles that are still using "player-creation" in their flags are linked and able to transmit fine, and also be used in the player tools. The caveat is that that flag is what allows them to be targeted at all by enemies, so technically removing that flag would absolutely work, but the drawbacks are extreme. Neutral poles without "player-creation" connect their wires to player-force structures, but I didn't check if they could transmit via the power interface.

Now that I have a better grasp of how exactly Factorio delivers instructions and whatnot, I can use this in the future with far more serious issues, and maybe just for fun.

Again, Deadlock, you're too kind!