Hi! I'm a bit concerned about your mod showing all forces in a game. Mods may create forces because they need them for special purposes. Such forces are not meant to be joined by other players, and mod authors probably have thought about the relation (ally/enemy/neutral) of their new force(s) to other forces. Here's a list of the forces I have in a newly created single player game:

 397.746 Script =(command):1: player
 397.747 Script =(command):1: enemy
 397.747 Script =(command):1: neutral
 397.747 Script =(command):1: radioactivity
 397.747 Script =(command):1: radioactivity-strong
 397.747 Script =(command):1: wisp
 397.747 Script =(command):1: wisp_attack
 397.747 Script =(command):1: player-trainControllerForce
 397.747 Script =(command):1: radioactivity-trainControllerForce
 397.747 Script =(command):1: radioactivity-strong-trainControllerForce
 397.747 Script =(command):1: wisp-trainControllerForce
 397.747 Script =(command):1: wisp_attack-trainControllerForce
 397.747 Script =(command):1: WT-fire-dummy

All forces listed after "neutral" are just such forces that shouldn't be visible. WT-fire-dummy, for example, is a force I created for Water Turret. I use it in order to be able to extinguish fires with the water turrets. If a fire is created, I place a dummy on it; when the dummy is killed, I destroy the fire entity. The dummies currently are combat bots that will attack enemies in a 1 tile radius around them (yes, playing with fire will hurt). I've set this force to be an enemy of every player (so their turrets will attack the dummy, i.e. extinguish the fire) and to be neutral to the force "enemy" (so biters won't attack the dummies and extinguish the fires for the player and also won't attack the player in revenge for attacking the dummy by trying to extinguish the fire). With your mod, players could make themselves an ally of my dummies and pass through fire without harm from them.

Please provide a way to exclude forces that players shouldn't see from the GUI! Three ways I could imagine:

• You already have a blacklist of forces in your mod that won't appear in the GUI (currently "player", "neutral", and "enemy"). So add compatibility with other mods by adding their meant-to-be-hidden forces to the blacklist.

Pro: It would take care of mods by modders who don't know about your mod.
Con: You would have to check every existing mod for newly created forces. This is next to impossible because a mod is created or updated almost every hour.

• Provide a remote interface that other mods can use to add their special-purpose forces to your blacklist.

Pro: Modders will know best which of their newly created forces they want to keep hidden from players. Also, if they decide to rename a force, they can take care of this on their own, without additional work from your side.

Con: Modders need to know about your mod -- otherwise they can't use your remote interface.

• Include some magic in your mod: You could check each force if it has players connected to it. If a force exists that doesn't have any players, add it to your blacklist.

Pro: Would work even if other modders don't know about your mod and therefore don't use your remote interface to add their new force(s) to your blacklist.

Con: It's guesswork, and may lead to unintended results.

A combination of the latter two suggestions might work to a certain degree:
Add forces without players automatically to your blacklist: do this when the game is created, when the configuration changes because new mods are added to the game, and when a player changes the force (these are the events that I first thought of, there may be others). Also provide a remote interface so other modders can add their forces to your blacklist. (Coming to think of it: you could also make a whitelist where mod authors can place forces that always should be visible to players.)

Moreover, I think you should present your mod on the forum, so other modders have a chance to learn about it and can take care of blacklisting the forces created by their mods.

If you take care of not exposing forces that are meant to remain hidden, I guess your mod may be quite useful to players. I hope you'll consider my concerns/suggestions -- your cooperation on this issue would be really appreciated! :-)

Please also see this forum thread for another example of why I'm concerned your mod may cause problems.

(Apologies, this is my first mod)

I really just created this for my friend group and have no idea how to actually behave with other mods since I'm coming from vanilla. Looking at your post, this definitely breaks the heck out of anything using forces and I'm not sure if there's a way to fix all those issues.

The biggest thing I can think of is just whitelisting my forces for this mod and only displaying those. I'm not very familiar with the factorio API but I'll read into persisting data that'll help me do this between saves/loads.

I think the whitelist would prevent breaking other mods that create empty proxy forces without having those mods need to opt into a blacklist.

I should have fixed internal forces being exposed in 0.1.6. Try running that and see how it goes.

Thanks, I just downloaded 0.1.6 from Github, and the special purpose forces are now hidden. By the way, are you aware that only the source has been updated? On the mod portal (and therefore, in the game), 0.1.4 is still the latest version, so many people probably won't see the update.

As this is your first mod, I want to make two further suggestions: "Heck." really isn't a good mod description. The description field is there so that people looking at the mod lists in the game's mod manager will get a general idea what a mod does, so it should contain a short summary (usually, one or two sentences will be enough).

Also, it would be nice if your mod contained a changelog. The Changelog Tools can help you in getting the syntax right. The mod contains a python script that needs to be run outside of Factorio. There are still some errors that the script doesn't find yet, and some things are still reported as error although the in-game changelog parser accepts them, so testing in game is still required! I'd recommend to run the script with the "--zorro" option, which will output a line-by-line analysis of your changelog file.

Finally, I think I may have found a bug. I created a new multiplayer game (with some of the mods creating new forces) and declared independence for player A. Then I logged in as another user, started Factorio, joined that game as player B, and declared independence as well. Thereafter, in both GUIs I could see the other player as an enemy. Then, I set the other player B as "ally" of A on the host. After I switched back to the client, closed and reopened the GUI to update it, A was still shown as "enemy".

I don't have experience with multiplayer games (just used them for testing with two instances of Factorio running on the same computer), so please correct me if I'm wrong! My expectation was that if B is an ally of A, A would also be an ally of B. If that really is the case, I guess you should update the state for both forces if a different state is set in one GUI.

What the … Your latest reply wasn't there when I started with mine, so forget about the mod not being available outside of Github! I'll download the latest version (in case anything changed) and test again.

OK, you did make more changes, and they still work. State of forces still isn't synced, though (still not sure if that really is a bug).

Alliances are one way, the other person can decide to not ally you even though you have them allied. The UI doesn't update though if a new player joins, that's a bug I guess, but getting the UI working so far has been a pain. I spent a while tracking down desyncs the other day...

Alliances are one way, the other person can decide to not ally you even though you have them allied.

Makes sense, kind of: Forcing somebody to be your ally isn't nice. On the other hand, the way it's now also is strange, think of Gandhi befriending Hitler, helping him out every which way and getting beaten up each time in turn. Who'd want to do that? Or the other way around: Somebody choosing to be your friend so they can pass your perimeter defenses and once inside, turn around to be your enemy again and destroy your base -- who wants friends like that? Perhaps I don't understand this correctly, or perhaps you need some kind of safeguard (which would complicate your mod considerably).

How about if one party couldn't decide to be friends with or neutral to the other, but A has to offer neutrality or an alliance to B and the status wouldn't be changed until B has accepted the offer? Another way would be that once you've turned neutral or ally of somebody else, you can't change back to enemy status for a certain time. (This could be problematic if there are more than just two players and you made an alliance with somebody you didn't want to because you clicked into the wrong row in the GUI.)

The UI doesn't update though if a new player joins, that's a bug I guess, but getting the UI working so far has been a pain.

I know what you mean. Only one of my mods has a GUI, but luckily ownership of that mod was transferred to me (I've been collaborating on that mod and fixed several bugs before that happened) when the original GUI was already in place. :-)

I spent a while tracking down desyncs the other day...

When I made GCKI, I didn't know how I should test it in multiplayer mode, so I just ignored multiplayer games -- and reports of desyncs came in only a short time later. Fixing those desyncs was hell! Then again, I learned a thing or two… :-D