Friday Facts #266 - Cleanup of mechanics

[Oktokolo]

Why not post a paragraph like that in FFF 267? Why not respond with such constructive information 10 or 15 pages earlier of this thread of sadness?

Everyone should, by now, have come to the conclusion, that Wube is way better at making a really great game even better, than at communicating what exactkly changes (or not).
And i am pretty sure, that it is better this way around than the other.

Some of the team also seem to like trolling their audience a bit, as topics like Bots versus belts (yes, this thread even got locked!) or #224 - Bots versus belts clearly show.
But this FFF was definitely one of the more informative and less trolling ones.


So, if you are easy to trigger, better avoid the FFF altogether and be positively surprised by the final product.
It will be great.

Mods will not die. Some really seem to believe, that the dude, that made Wube give him source code access and add quite a chunk of his code in the game although they do not plan on using it in vanilla will consider stopping to mod. That will not happen. He will not quit modding just bedcause they are not always doing exactly, what he wants. Most likely, there will be updates to make all the great mods work with 0.17. I myself am ready to fork stuff, that allows forking and improves my gameplay. And everyone can do that - updating a mod for API changes most often is way easier than making a new one.
Even the axing of axes can be compensated by using items hold in hand / inventory or armor grid equipment.

[quyxkh]

[...]
I realize we are not super accommodating when it comes to modding interface requests

Tell the truth, that's about the last criticism I'd level. (or, was that the point, there? a thoroughly appreciative "heh" if so)

[eradicator]

Some devs hate unnecessary mod breaking changes (even in between major updates), others make mod breaking changes without second though (at least in between major updates) ... so it's a mixed bag.

Haha. Yea. i can sing a song about that. I know in which of those two groups a certain someone in the modding interface request section is. Can be quite frustrating at times when being the one on the requesting side. Personally i'd really like to have some of the inconsistencies of the api "straightend out" for new and old modders alike. But i can also understand not wanting to break mods over spelling errors. I'm still greatful for every breadcrumb i can get from my requests, even if it doesn't always sound like that.

EDIT:
@eradicator: don't know if anyone responded to you - you can define more damage types in your mod if you need to.

Nope, sadly my questions in FFFs usually go unanswered. Quite relieved that this part still works :).

[pyanodon]

I'm just going to go sit in the corner and cry now...

same

[Oktokolo]

But i can also understand not wanting to break mods over spelling errors.

Spelling errors are the worst - they should be fixed as soon as they are detected regardless of whether the change breaks mods or not. That HTTP refer(r)er thing still confuses me every time...

[bobingabout]

My standalone 0.16 folder now has a permanent spot on the PC for myself and my close friends. We can enjoy the game before it was dumbed down and destructive to the mods that define Factorio for us.

This is because:

I have source access, remember? I downloaded the latest version of 0.17, and everything they said in the FFF is already done.
I'm not saying it can't be undone, but from what I've seen on the source access discord... it won't be undone.

So thanks for the fun experience while it lasted, Wube. There's no way that the mods can work around poor decisions to restore the game to what we love about it if these changes are forced upon us without at least consulting the community for feedback on such major changes first.

I was hoping that FFF 267 was going to be "We rushed the gun and we're sorry. We left the code in for mods as most requested." but I wasn't surprised to see that it was swept aside, with little hope that it will be revisited in the future.
---

Keep in mind that while the mechanic for ore hardness and mining tools is gone and unlikely to come back... All the changes not related to mining CAN be undone by mods. efficiency and fuel values are just numbers in data, and maximum ingredient limits of machines can just be re-added, and damage types is again, just data.

[pleegwat]

How much of what you could do on a mining tool could also be done as armour equipment? And can you have armour equipment whose effects don't stack?

[Reika]

Restricting player from mining non-resource entity is not possible at the moment.

Wait, what? Are you saying that setting minable = nil in the prototype no longer does anything, that entities can no longer be made not mineable at all? What are we supposed to do about technical entities, that the player should be able to select but not destroy (example: my circuit connection entities on the EGCombat shield domes)?

[*]Resistances/Damage types - no engine change, mods can add more damage types if they need to
[*]Assembling machine ingredient limit - minor engine change = AssemblingMachinePrototype::ingredient_count is now optional and defaults to 255, everything else were changes in base mod

This certainly helps reassure me.

[posila]

Restricting player from mining non-resource entity is not possible at the moment.

Wait, what? Are you saying that setting minable = nil in the prototype no longer does anything, that entities can no longer be made not mineable at all? What are we supposed to do about technical entities, that the player should be able to select but not destroy (example: my circuit connection entities on the EGCombat shield domes)?

I am sorry, I explained wrong again. Specifically, I had in mind following use case: 63130
Setting minable = nil still has the same behavior as in 0.16. But let's say you had a mod that prevented you to mine mining drills until you had some high tier pickaxe. You would do that by setting big mining hardness to the entity and than later on allowed player to make a tools with large enough mining power. So, as far as I know there is no easy way to achieve the same behavior at the moment.

[Lastmerlin]

I am perhaps a bit late to the party (and read only the first 15 pages), but need to throw in my personal opinion as well...

Pickaxe removal: I like it. In the base game, this was just annoying. I really like the proposal of AntiElitz of making it a research. The praise for the steelaxe should be preserved.

Assembler slot restriction: Actually, I am not as upset as many others. In my opinion, the distinction was unlogical (example: rails vs fusion reactor) and had way too little impact. Its mainly relevant for inserters and for lazy bastard, but thats it. On my first playthrough I did not even discover the limitation, because you get AM2 to quickly and so few items need AM3 (you handcraft them all). I just build everything with AM2 (except megabases) and I believe most players do. Even for Bobs mod, I hardly ever felt this limitation. You always upgrade because you want more module slots or more speed. However, revamping could be better than just removing. Several ideas have been mentioned, like limiting AM1 to red/green science recipies and AM3 unlocks hightech. That would be something meaningful.

Mining hardness: This is a really counter-intuitive and strange value. It really not obvious how it is used for computing the mining speed. I like, that it is thrown out of the base game. Its sad for modders of course. However, my experience from bobs mod is, that this has no big impact either. You just use the best mining drills you currently have and dont feel any serious limitations. Changing this to *you need a specific special drill* might be even more interesting.

Damage types: For the base game, this makes sense, but for the modders its really sad.

Burner efficiency: I don't like this. Efficiency is a concept that is easy to understand and that every engineer already knows. Right now, it is used rarely, just because we have few burners overall. But the concept is good. The extensive use in mods also demonstrates this.

Overall: The majority of the changes make sense in the context of the current game. In some cases, changing the context would be better than outright removal. Something that is really sad, is the amount of work of modders that is invalidated with these changes. In my opinion, mods are the main factor for longterm replay value, especially these big overhaul mods. Completely frustrating these contributors is really not a good idea. Even if only 10% of the players are really keen on heavily modded play, remember, that these 10% contain most of the youtubers, speedrunners etc. In other words: The people who contribute to the visibility of the game and provide essentially free advertising.

[QGamer]

I've been thinking about the damage type streamlining and I have some thoughts to share:
Kovarex suggested 4 damage types: generic, impact, heat, and acid.

One think I like about this is that "fire" is changed to "heat" --when you think about it, there are some non-flammable substances that still don't do well in the heat.

But explosions...I believe that explosions (like grenades, artillery, tank cannon, etc.) should deal 2 types of damage: generic & heat. (Maybe impact also for artillery & shells...)
If you have an explosion, some of the damage dealt is heat-based, and some is dealt by the shrapnel created by the blast. In other words--2 different types of damage. My point is don't make grenades only do heat damage or only do generic damage--make them deal multiple kinds of damage at once. This can make resistances more interesting if enemies have resistance to, say generic damage but not heat--then they resist a part of the grenade damage but not all of it.

[Nova]

The change to the first post did break the link to the FFF blog post. There is a ¨ at the end of the link.

[posila]

The change to the first post did break the link to the FFF blog post. There is a ¨ at the end of the link.

Fixed, thanks

[eradicator]

• Resistances/Damage types - no engine change, mods can add more damage types if they need to

Btw, could we have an option to hide certain resistances? I'd be fine with a flag on the damage type itself, so resistance to $my_named_damage_type is never visible on anything. Would be useful both to prevent screen clutter and to hide "damage" types that are really just hacks to achieve something else.

[bobingabout]

Restricting player from mining non-resource entity is not possible at the moment.

Wait, what? Are you saying that setting minable = nil in the prototype no longer does anything, that entities can no longer be made not mineable at all? What are we supposed to do about technical entities, that the player should be able to select but not destroy (example: my circuit connection entities on the EGCombat shield domes)?

I am sorry, I explained wrong again. Specifically, I had in mind following use case: 63130
Setting minable = nil still has the same behavior as in 0.16. But let's say you had a mod that prevented you to mine mining drills until you had some high tier pickaxe. You would do that by setting big mining hardness to the entity and than later on allowed player to make a tools with large enough mining power. So, as far as I know there is no easy way to achieve the same behavior at the moment.

Even just doing the same filter with ores isn't possible anymore. AFAIK there is no way to change the mining filter on the player entity mid-game, so you either have the option of "Can always mine all ores" or "Can never mine certain ores", previously you could use the hardness as a filter to unlock the ability to mine more higher tier ores by upgrading your mining tool. Now you can't!

[posila]

Even just doing the same filter with ores isn't possible anymore. AFAIK there is no way to change the mining filter on the player entity mid-game, so you either have the option of "Can always mine all ores" or "Can never mine certain ores", previously you could use the hardness as a filter to unlock the ability to mine more higher tier ores by upgrading your mining tool. Now you can't!

I am aware. I mentioned that in my summary from which Reika was quoting. Honestly, it doesn't sound like super big deal to me - high tier ores can be mined using only machines; that makes sense to me, but I feel like it would be fair to move some of the pickaxe modifiers to armor item (or an equipment item). Until I went to look at the commit that removed pickaxes, I didn't even know it could modify anything more than just mining speed and mining power.

[ratchetfreak]

Even just doing the same filter with ores isn't possible anymore. AFAIK there is no way to change the mining filter on the player entity mid-game, so you either have the option of "Can always mine all ores" or "Can never mine certain ores", previously you could use the hardness as a filter to unlock the ability to mine more higher tier ores by upgrading your mining tool. Now you can't!

But it should be simple enough to make this researchable. Make when you start mining if the tag is in the force's can_handmine list doing research can add a tag to the list.

There is a bit of cascading tot he bonus screen to show which ores you can mine and which ones you cannot.

[eradicator]

Even just doing the same filter with ores isn't possible anymore. AFAIK there is no way to change the mining filter on the player entity mid-game, so you either have the option of "Can always mine all ores" or "Can never mine certain ores", previously you could use the hardness as a filter to unlock the ability to mine more higher tier ores by upgrading your mining tool. Now you can't!

I am aware. I mentioned that in my summary from which Reika was quoting. Honestly, it doesn't sound like super big deal to me - high tier ores can be mined using only machines; that makes sense to me, but I feel like it would be fair to move some of the pickaxe modifiers to armor item (or an equipment item). Until I went to look at the commit that removed pickaxes, I didn't even know it could modify anything more than just mining speed and mining power.

Not having done much with the players mining_category i do think it would be awesome to be able to modify a characters crafting_category, and if that's similar maybe we could get both. I.e.
character_additional_crafting_categories = {}
character_additional_mining_categories = {}
With or without a force-wide variety of each. Would that be possible?

[driver]

Pickaxe removal: In most games you can cycle through some weapons or empty hands with one button (tab), which makes sense especially if you play a gamepad (which is possible with factorio, too).
Instead of using an extra button (F), you could use "empty hand" and if you need to mine, a pickaxe could show up automatically in your hand if you move your cursor on a mining patch (or another tool)
In reality one of the first steps normally would be to build some kind of building (concrete, walls, copperwire). This could be all easier without the assembler slot restrictions and and maybe reduced research in the beginning.

[posila]

@eradicator: Please create topics in modding interface request subforum. Your requests are reasonable, but I am here just to try to clarify things, and the ideas might be forgotten.