badgamernl wrote:Plss make the mod-gui scenario friendly, it would help my server allot! It would also be cool if there was a way to make server side and client side code and the communication between the client and the server. Take for instance garry's mod it has client and server side code and a way to communicate with a database. This would add the possibility to make a ranking system that will in return get you a more stable player base. Or add a permissions system, but wy make it yourself when the community can make it! The problem with factorio now is that when you make a server and want admins on it they can run commands and then the achievement system says console command used in return players will leave because of it. It would also be cool if there was a server list ranking system and a bookmark system to make the life of players easier!

Factorio doesn't have a concept of client vs. server when it comes to mods.

Mod devs can't even get the basic system we have now correct and frequently cause desyncs. Making them client vs. server and leaving it up to the mod author(s) to do it correctly just sounds like a horrible idea.

Mod GUI? mmm is it a good idea to have mod sets, that when you join different multiplayer servers ,or just play different singleplayer maps you select a set of mod with a click of a button, so you dont go over selecting and deselecting mods manually. Which would be ok, but its becoming difficult to remember mod names.

I cannot express to you guys how much I appreciate the work that happens on this game. The constant updates, tweaks and full blown additions to this game is awesome. It's obvious that this product is a labor of love for you all. The changes you make really are about bettering the game and the community at large. I am always surprised at how much more awesome this game gets with every change. Thank you. Thank you. Thank you.

badgamernl wrote:Plss make the mod-gui scenario friendly, it would help my server allot! It would also be cool if there was a way to make server side and client side code and the communication between the client and the server. Take for instance garry's mod it has client and server side code and a way to communicate with a database. This would add the possibility to make a ranking system that will in return get you a more stable player base. Or add a permissions system, but wy make it yourself when the community can make it! The problem with factorio now is that when you make a server and want admins on it they can run commands and then the achievement system says console command used in return players will leave because of it. It would also be cool if there was a server list ranking system and a bookmark system to make the life of players easier!

Factorio doesn't have a concept of client vs. server when it comes to mods.

Mod devs can't even get the basic system we have now correct and frequently cause desyncs. Making them client vs. server and leaving it up to the mod author(s) to do it correctly just sounds like a horrible idea.

Here is a flowchart of how I think it should works.

Factorio-Modding.png (196.43 KiB) Viewed 2949 times

Almost everything can be put in those part already for prototypes, like all visual thing in prototypes are client side, and shouldn't affect checksum and synchronisation, I simply can't see a server side entity for now.
So the only thing needed would be that when registering mods, it would temporary crop every esthetic information and do the checksum, mods that modify nothing that needed for synchronisation could be marked as safe for synchronisation.

Almost all gui are either a informative one the client could hold, a sensitive one the server could handle in conjunction with the client side one, and the other scripts with are common to client and server.

client side control could be naned : control-client.lua
server side control could be naned : control-server.lua

y.petremann wrote:Almost all gui are either a informative one the client could hold, a sensitive one the server could handle in conjunction with the client side one, and the other scripts with are common to client and server.

client side control could be naned : control-client.lua
server side control could be naned : control-server.lua

You seem to be missing 2 major issues:

If a given GUI is persisted between save/load it must be part of the game state and must be present on all peers

If a mod can read information about a GUI existing or read information from the GUI then that information must be part of the game state and must be present on all peers

If not, then it will cause desyncs when mod A on peer 1 says "I've got a GUI so I'll do X" and mod A on peer 2 says "I have no GUI so I won't do X" and the 2 simulations now aren't the same and it desyncs.

Hi, I am quite new to Factorio modding but I've made some addons for wow. I have to say the Ace library is great for making guis in wow. You guys seem to know what you're doing already, but I would definitely take inspiration from that library if I could, as it is quite easy to use for addon creators.

Can you make the style an optional parameter? so in the API do a
if(style == nil)
style = mod_gui.frame_style
end

I only say that because then the 99% of modders will just automatically fall into the default style guide. If someone wants a different behaviour then they can read up on the parameter and do what they currently do.

y.petremann wrote:Almost all gui are either a informative one the client could hold, a sensitive one the server could handle in conjunction with the client side one, and the other scripts with are common to client and server.

client side control could be naned : control-client.lua
server side control could be naned : control-server.lua

You seem to be missing 2 major issues:

If a given GUI is persisted between save/load it must be part of the game state and must be present on all peers

If a mod can read information about a GUI existing or read information from the GUI then that information must be part of the game state and must be present on all peers

If not, then it will cause desyncs when mod A on peer 1 says "I've got a GUI so I'll do X" and mod A on peer 2 says "I have no GUI so I won't do X" and the 2 simulations now aren't the same and it desyncs.

In the case if GUI, there is two major parts, client and common gui. They are separated and are not relevant to the other one, they don't even can access to each other unless they use the remote remote call (which could try to call a interface function on a specific part)

If the gui is part of control.lua, then it's totally relevant to the game state and then work like now, clicking in a common gui element wouldn't fire a click event on the client part.
If the gui is part of control-client.lua, then the gui is totally irrelevant to the game state, click on a client gui element wouldn't fire a click event on the common part.
The gui would need to rebuild from scratch at each connection, but could ask the server if it has information for him, here a example :
Finaly if any part want to do something (including geting information), it needs to call a interface of the corresponding part, unless this is exposed informations so each part can access their respective environement, client and server have read-only access to common environement)
Here a quick simplified example of what I had in mind :

remote.client={}
remote.client.call=function(interface,name,client,callback,...)
local ret = nil
local status = remote.interfaces["client_"..interface] and remote.interfaces["client_"..interface][name]
if status then
ret = remote.call("client_"..interface,name,unpack{...})
end
if type(callback) == "function" then
callback(status, ret)
end
end
remote.client.add_interface=function(name, functions)
remote.add_interface("client_"..name, functions)
end
remote.server={}
remote.server.call=function(interface,name,callback,...)
local ret = nil
local status = remote.interfaces["server_"..interface] and remote.interfaces["server_"..interface][name]
if status then
ret = remote.call("server_"..interface,name,unpack{...})
end
if type(callback) == "function" then
callback(status, ret)
end
end
remote.server.add_interface=function(name, functions)
remote.add_interface("server_"..name, functions)
end
remote.common={}
remote.common.call=function(interface,name,callback,...)
local ret = nil
local status = remote.interfaces["common_"..interface] and remote.interfaces["common_"..interface][name]
if status then
ret = remote.call("common_"..interface,name,unpack{...})
end
if type(callback) == "function" then
callback(status, ret)
end
end
remote.common.add_interface=function(name, functions)
remote.add_interface("common_"..name, functions)
end

ALso to have control-client and control-server, I've put a require "control-client" and require "control-server" on the control.lua, but that not the way it should work in the future

Rseding91 wrote:
You seem to be missing 2 major issues:

If a given GUI is persisted between save/load it must be part of the game state and must be present on all peers

If a mod can read information about a GUI existing or read information from the GUI then that information must be part of the game state and must be present on all peers

If not, then it will cause desyncs when mod A on peer 1 says "I've got a GUI so I'll do X" and mod A on peer 2 says "I have no GUI so I won't do X" and the 2 simulations now aren't the same and it desyncs.

In fact if information from the client or the server are given to the other part like controls or chat commands. Here I think what your saying is irelevant since common part don't see client or server things (gui included).
Additionnaly if the server hold sensitive informations, if any player try to save the world localy, it would not get the server side informations, Which is an additionnal layer of security.

So is there a way to copy train schedules? One of the longer parts of setting up a new train outpost is creating all the wait conditions and such for the new train. I would love to just copy from another one, and then just change one little thing.

Crixomix wrote:So is there a way to copy train schedules? One of the longer parts of setting up a new train outpost is creating all the wait conditions and such for the new train. I would love to just copy from another one, and then just change one little thing.

You do it the same way you copy between assemblers, or really anything. Shift Left and Right clicking.

Can I put in a request for Twinsen to do a FFF soon on upcoming 0.15 circuit network/combinator additions and changes? I have many ideas planned combinator-wise and would love to hear exactly what come out of the development proposal thread (viewtopic.php?f=9&t=30853).