Simple-Force-Entity

[Earendel]

This is a request to add an entity with the following properties:

As simple-entity but with the following additions:
The entity can have a force.
The entity is included in blueprints by default (but not if blueprintable flag excludes it).

Example use case:
I'm working on a 'zones' system where you can mark area as a zone for various reasons. [MOD 0.14] Programmable Warfare - command units via signals.
The zones need to have no collision and be on a specific low-level rendering layer so they act more like radius visualization than a normal object. I've tried using the decorative type but that has undesirable side effects when placing concrete over it. Simple-entity is better but is excluded from blueprints. Wall can be blueprinted but has undesired interactions with walls. There are a number of other types I could choose but they all have various downsides and overheads.

It could be called 'Simple-Force-Entity', 'Generic-Entity' or something else that might make more sense. The important thing is a force-based blueprintable entity with minimal overhead and minimal hard-coded interactions with other entities.

[Earendel]

Another use case can be seen here:
viewtopic.php?f=93&t=34935&p=217749#p217749

Currently letters are using the constant combinator type because it has the least unwanted side effects, but still has an undesired UI.

[aubergine18]

You can turn off the UI with `someEntity.operable = false` during the `on_entity_built` event

[Earendel]

Are there any other side-effects of doing that?

[aubergine18]

Not that I'm aware of, as far as I can tell it only prevents default GUI appearing when you click the entity.

The entity can still be:

* selected (prototype property `selectable_in_game` can change that, or create it as neutral/enemy force)
* active (LuaEntity.active can be set to disable if required)
* minable (LuaEntity.minable can be set to stop mining)
* destructible (LuaEntity.destructible ...)
* rotatable (LuaEntity.rotatable ...)

[Earendel]

That's good to know, thanks.

That does improve the situation when using a few of the entities like Text Plates, but I worry about the overhead of adding millions of constant combinators to a scene if they are used for zones. I think it's likely that someone will at some point think it's a good idea to cover their base in a massive home zone.

[aubergine18]

If you set their '.active = false' then the game will still render them but not process any of their game logic, at which point they are almost as lean as a simple-entity.

There's also a debug mode (F4 menu) for showing entity active state - any with green circle are running game logic, any with no circle aren't currently running game logic but are active, and any with red circle are disabled. (I think, lol)

[Earendel]

That is really useful information, thanks.

[Earendel]

So the last critical issue with using a constant combinator in place of a dedicated simple-force-entity is that a constant combinator does not support Types/RenderLayer. Does anyone have a workaround for this too? I can't just make it invisible and put a decorative underneath because it would be invisible in blueprints.

[aubergine18]

I've just run in to something similar with pipe-to-ground - the render_layer property appears to be ignored (or maybe it's limited to certain layers)... I was trying to set it to "floor" but no joy.

[Rseding91]

What all properties would you imagine such an entity type would support?

[aubergine18]

Doesn't setting `.active = false` more or less turn any entity in to a simple-entity (in terms of CPU usage)? If that is the case, I'm not sure if simple-force-entity is required?

Would be good if all entities could handle the `render_layer = "floor"` setting (or any equivalent that has similar effect).

[Earendel]

Would be good if all entities could handle the `render_layer = "floor"` setting (or any equivalent that has similar effect).

I think there would be problems for things like inserters and power poles. The only way I can see that working is if render_layer was supported on the sprite object and render_layer on the entity just defines the default for any sprites without a defined render_layer.

What all properties would you imagine such an entity type would support?

I'll try and make a complete list tonight.

[Earendel]

Here are the properties I would image a Simple-Force-Entity might support.

Supports force and inclusion in blueprint unless "not-blueprintable"
Can support orientation but with a single sprite image there would be no difference. Maybe require a rotate = true to activate orientation?
(No default UI)

Example entity definition:

Code: Select all

{
	type = "simple-force-entity",
	name = "example",
	flags = {"placeable-player", "placeable-neutral", "placeable-enemy", "placeable-off-grid", "player-creation", "not-on-map", 
		"breaths-air", "not-repairable", "building-direction-8-way", "not-blueprintable", "not-deconstructable"},
    icon = "iconpath.png",
    subgroup = "subgroup",
    order = "a[example]-bexample]",
    collision_box = {{-0.45, -0.45}, {0.45, 0.45}},
	collision_mask = {"Types/CollisionMask", "Types/CollisionMask"}
    selection_box = {{-0.5, -0.5}, {0.5, 0.5}},
	drawing_box = {{-0.5, -0.5}, {0.5, 0.5}},
    max_health = 200,
    healing_per_tick = 200,
	emissions_per_tick = -0.0005,
	weight = 5,
	corpse = "medium-remnants",
	dying_explosion = "medium-explosion",
	selectable_in_game = true/false,
    minable =
    {
		mining_particle = "stone-particle",
		mining_time = 8,
		result = "stone",
		count = 20
    },
    loot =
    {
		{item = "stone", probability = 1, count_min = 5, count_max = 10}
    },
    mined_sound = { filename = "__base__/sound/deconstruct-bricks.ogg" },
    render_layer = "Types/RenderLayer",
    resistances =
    {
		{
			type = "fire",
			percent = 100
		}
    },
    autoplace =
    {
		order = "a[example]-b[example]",
		max_probability = 0.25,
		peaks =
		{
			{
				influence = 0.0002
			},
			{
				influence = 0.002;
				min_influence = 0,
				elevation_optimal = 30000,
				elevation_range = 23000,
				elevation_max_range = 30000,
			}
		}
    },
    pictures =
    {
		{
			filename = "__base__/graphics/entity/decorative/stone-rock/stone-rock-01.png",
			width = 76,
			height = 60,
			frame_count = 4,
			animation_speed = 1.5,
			direction_count = 16,
			shift = {0.1, 0}
		},
		{
			filename = "__base__/graphics/entity/decorative/stone-rock/stone-rock-02.png",
			width = 83,
			height = 86,
			frame_count = 4,
			animation_speed = 1.5,
			direction_count = 16,
			shift = {0.2, 0}
		},
		or...
		layers =
		{
			{
				width = 102,
				height = 86,
				frame_count = 2,
				direction_count = 64,
				shift = {0, -0.1875},
				animation_speed = 8,
				max_advance = 0.2,
				stripes =
				{
				{
				 filename = "__base__/graphics/entity/car/car-1.png",
				 width_in_frames = 2,
				 height_in_frames = 22,
				},
				{
				 filename = "__base__/graphics/entity/car/car-2.png",
				 width_in_frames = 2,
				 height_in_frames = 22,
				},
				{
				 filename = "__base__/graphics/entity/car/car-3.png",
				 width_in_frames = 2,
				 height_in_frames = 20,
				},
				}
			},
			{
			  width = 100,
			  height = 75,
			  frame_count = 2,
			  apply_runtime_tint = true,
			  direction_count = 64,
			  max_advance = 0.2,
			  line_length = 2,
			  shift = {0, -0.171875},
			  stripes = util.multiplystripes(2,
			  {
				{
				  filename = "__base__/graphics/entity/car/car-mask-1.png",
				  width_in_frames = 1,
				  height_in_frames = 22,
				},
				{
				  filename = "__base__/graphics/entity/car/car-mask-2.png",
				  width_in_frames = 1,
				  height_in_frames = 22,
				},
				{
				  filename = "__base__/graphics/entity/car/car-mask-3.png",
				  width_in_frames = 1,
				  height_in_frames = 20,
				},
			  })
			}
		}
    }
}

LuaEntity support:

Code: Select all

damage(damage, force, type) → float
destroy() → boolean
die()
has_flag(flag) → boolean
revive() → uint (as ghost)
name :: string [R]
ghost_name :: string [R] (as ghost)
localised_name :: LocalisedString [R]
ghost_localised_name :: LocalisedString [R] (as ghost)
type :: string [R]
ghost_type :: string [R] (as ghost)
active :: boolean [RW] (can switch on/off, however there would be no logic attached so would not make any difference)
destructible :: boolean [RW]
minable :: boolean [RW]
rotatable :: boolean [RW]
operable :: boolean [RW]
health :: float [RW]
direction :: defines.direction [RW]
supports_direction :: boolean [R]
orientation :: float [RW]
prototype :: LuaEntityPrototype [R]
ghost_prototype :: LuaEntityPrototype [R] (as ghost)
time_to_live :: uint [RW] (as ghost)
color :: Color [RW]
last_user :: LuaPlayer [RW]
unit_number :: uint [R]
bounding_box :: BoundingBox [R]
valid :: boolean [R]
teleport(position, surface) → boolean
surface :: LuaSurface [R]
position :: Position [R]
force :: LuaForce [R]	

[aubergine18]

The ability to repair it, or have robots rebuilt it if destroyed, would be very desirable.

In terms of sprite image, if it works like simple-entity (ie. multiple images can be specified and it chooses one at random when built) that would be great Like simple-entity, the sprite would only have one orientation.

The usual sound properties - including built_sound, etc., would be desirable.

localised_description would also be desirable.

It's difficult to say what's needed, because I'm not entirely sure what properties a simple-entity has...

Is .weight property available on all entities?

[Earendel]

Just to be clear, the values in the example flags don't represent the default, it just represents the flag options that it could support.

I.e. "not-blueprintable" means that it would be blueprintable by default but the "not-blueprintable" flag could switch that off.

[Rseding91]

I added "simple-entity-with-force" and "simple-entity-with-owner" for 0.15.

[aubergine18]

Awesome! Assuming there are no examples of these entities being used in the vanilla prototypes, would it be possible to get a list of the properties they support (or the properties they add, compared to simple-entity)?