As the title states, we cannot do custom tooltips on recipes when we can still do localized descriptions (the old method of custom tooltips)

Since it's on the Prototype I would've expected it to work on at least the major four (Items, Entities, Recipes, and Technologies).
I can concede it maybe not ...

Boskid recently gave pretty good detail about what exactly it means for an entity to be mirrored
I believe it should make it into the documentation


when i was un-messing the entity flipping logic and mirroring logic (and there as a lot of stuff to un-mess), i came up with following rule that ...

Oh... I didn't even notice the latest post was recent :P

I noticed the fact that relative_turret_orientation seems to leave out regular turrets, and then someone shared https://forums.factorio.com/34552 with me

I would assume this is still valid, and if so it should get documented.
Either orientation should expand upon what "smooth orientation" means ...

A number of times people will see "invalid prototype array" and misinterpret that.
Or even just miss those words entirely because of the big block of text that is the serpent.block of what was given

What I want is to reword it into "invalid array of prototypes" to be a little more clear in what it ...

PennyJim wrote: Thu Dec 05, 2024 11:54 pm And while we're talking about it.

Yeah, just bury it in this lesser improvement request past me...

Made a proper separate request for it: 130565

It says "only events generated with LuaBootstrap::generate_event_name and the following can be raised:" and then lists all the 'actual' events that can be raised

This could mislead people to think they have to use generate_event_name despite a prototype having been made for the express purpose of ...

Then... What am I doing wrong..? It's returning false
(though maybe this kinda conversation should move to the discord which can move faster)

Edit: Wait, I'm sure it's related to prototype stuff and `next_upgrade`..?
Edit 2: Or maybe it's the fact that I'm trying to go from ghost assembler to ghost ...

Oh wait nvm... `order_upgrade` doesn't work on ghosts
I just got my wires crossed while testing and forgot which entity I was fast-replacing and which one I had the event upgrade the ghost to

The crux of my problem was that I was fast-replacing a ghost and it was affecting the real entity.

I was not aware of `order_upgrade` (though I should've expected it to exist), and some quick testing shows that it is in fact instant on ghosts.
With a bit of "if ghost then" logic, this should be ...

Now, there's a pretty solid argument that this is an interface or feature request instead. I won't be upset if it just gets moved

If you hover over a chest, and run this command. The original chest will get destroyed (left on the ground).

/c
local entity = game.player.selected
entity.surface ...

Ditto, having it work like a minimum of network limit would be nice.
Would mean there will be a need to police the inputs if you want a full network limit, but that's on the mod creator

Tl;dr it's more work on the backend, especially navigating the full dependency tree, but hopefully they can add it eventually.


I don't think it would need to navigate the full dependency tree, just slap the label whenever a mod is uploaded that adds a dependency with the label or enables a flag ...

+1 I was surprised to realize that hard dependencies didn't pass on the sticker

I've had a couple instances of making a LuaRenderObject to specifically mimic a custom alert. Of course combined with adding the custom alert to every player on a force.

A single static sprite isn't the most obvious, nor does it really mimic alerts all that well. I'd like some way to tap into the ...

Not always. Fluids are usually amount, but items are inconsistent. The most prominent example is that minable and placeable_by uses count, while recipe ingredients and products uses amount.


Hence "generally". I see that specific example more as fluid can take decimals and the Ingredient and ...

Therenas wrote: Mon May 26, 2025 8:27 am I could do "`true` or value of `default_show_value`" I guess, but not sure if that's really clearer.

I personally think that's clearer. Though you'd probably want to swap the order so it more clearly uses the value of the field if set and uses a default if unset.

Oh I love this idea. Would encourage actually adding more damage types.

Problem I see with this, is that (afaik) some things that cause damage don't actually have a force associated with them...

PennyJim wrote: Sat Mar 09, 2024 10:19 pm There's on_research_cancelled, which I wish would include the player that cancelled it (if relevant)

Both a bump and mentioning that I've finally actually made this its own request like it should've been:
129022

The player is attributed in chat to things like starting(?) or canceling research. I'd prefer if the events also had an optional parameter for the player index so we can do similar things.

In my case, I want to explicitly recreate the chat message so my fake layer on top of chat can be accurate ...