Thank you. I've had not in mind, that this API may limited to internal use only.mOoEyThEcOw wrote:This is a simplified explanation. ...TheRaph wrote:I've got a question ...ChoMar wrote:...
That would be nice.OvermindDL1 wrote:I use Corsair RGB keyboard/mice and Phillips surrounding lighting, so I doubt this will work with any of those...
Can you 'please' make a way to call a secondary custom program that is fed data via stdin of what colors should be set at any given location with a documented interface? This will make it utterly trivial on linux to let Factorio plug in to any system, especially as controlling the colors of the Corsair stuff on Linux is as simple as just sending simple text formatted data commands to the appropriate device calls, and controlling the Phillips surround lighting is as simple as just sending formatted data to the appropriate local TCP pipe, setting up all this in Factorio is overkill, and focusing just on Razer stuff (which had absolutely no official linux support last I saw so I doubt your code will work here) is kind of blegh, however just sending the appropriate color commands to a secondary program that the user can specify would allow anyone to hook into anything they want (and even over time perhaps more features could be added such as controlling the phillips fans, vibration bars, etc...).
If such an interface were made I'd happily make the Corsair and Phillips programs (if anyone even still uses this phillips ambx stuff, though I know many use Corsair things) and put it up on github for any linux users to use it with. I even have a Razer Naga with color controls here and I could figure out how to plug into it as well or accept PR's for it.
....
It would be *awesome* to write a program to listen to stdin for events happening in the game and be able to do things like appropriate lighting effects on the phillips lights and keyboard with ripples and waves and all such. In addition to writing the code and putting up on github I'll take a movie of it in action as well. In addition I could turn on the fans based on, say, life level, and the vibration bar when under attack (in addition to lighting effects and ripples and such). That would be quite nicely immersive and a good example of what a generic 'game event' interface could do instead of just a single-manufacturer's lights. ^.^
(Plus I really *really* hate proprietary, single-platform interfaces, and Razer's community-built linux drivers are a bit more... troublesome than anyone else's, because Razer does a lot of stupid stuff in their USB protocols...)
Which is the point at which I said to myself, "wait a second, clusterio somehow transfers data.. how do they do that?". Any way that a mod could use to get data out of Factorio could be used to build an API like this. It might be super cumbersome, but it should at least be possible.mOoEyThEcOw wrote: This is a simplified explanation. The main problem is input and output - which is a fundamental part of programming - e.g. where can we get data and where does it go, every kind of program has these properties. The existing factorio API is designed for mods, a kind of program. The input of mods is the factorio API and the output of mods is the factorio API. For a lot of reasons (user safety and security, stability, etc), mods are designed to be limited to just that. The factorio API isn't (currently) available - for a lot of good reasons - to any other kinds of programs.
However the keyboard and mouse are both controlled by the operating system and it's drivers (e.g. the output and input of the operating system is the hardware itself and the user space programs it runs). At the very least the output of any program that messes with the lighting needs access to the "user space" (kinda like an API; but different and more complicated) of the operating system, this rules out mods. The stdin/stdout stuff described above is one way of providing factorio information as part of user space; alternatively they could wrap parts of the API in a way that it would be accessible to user space programs.
Instead of writing to a file if it could instead write to a named pipe at the same location then this would indeed be pretty trivial to implement with very low overhead (the time to write to a named pipe if already open and the reading program getting the data is measured in milliseconds in the worst cases, so perfectly fine for such a lighting interface).zebediah49 wrote: It turns out that the answer is game.write_file. From that, I present a whopping 21-line proof-of-concept mod Health Report. It continuously keeps a file, `script-output/health.txt` updated with your current health. That's all.
I'm not saying that a non-disk-based IPC interface wouldn't be better, but we can do this with the current tools.
Really? There's still 2 hours of hope left!Proxy wrote:2. there won't be any more FFFs?
