Friday Facts #218 - Import bpy, Export player

Regular reports on Factorio development.
TheRaph
Fast Inserter
Fast Inserter
Posts: 221
Joined: Sun Sep 24, 2017 6:31 pm
Contact:

Re: Friday Facts #218 - Import bpy, Export player

Post by TheRaph »

mOoEyThEcOw wrote:
TheRaph wrote:
ChoMar wrote:...
I've got a question ...
This is a simplified explanation. ...
Thank you. I've had not in mind, that this API may limited to internal use only.
So FACTORI⚙-API is more like "javascript" (which is limmited to browser enviroment only, but can not use system resoureces) and not like Office-VBA (which also work most in MS-Office, but are also capable to execute external programs and interact with most OS-funktions).

kamegami
Manual Inserter
Manual Inserter
Posts: 2
Joined: Thu Jun 08, 2017 3:42 pm
Contact:

Re: Friday Facts #218 - Import bpy, Export player

Post by kamegami »

I was curious if you guys could add Discord Rich Presence https://discordapp.com/rich-presence

Triaxx2
Inserter
Inserter
Posts: 30
Joined: Tue Nov 14, 2017 8:06 pm
Contact:

Re: Friday Facts #218 - Import bpy, Export player

Post by Triaxx2 »

Anyone else notice the life bar doesn't work on the mouse in the GIF? It's full even as the bar on the keyboard fades. (And the shield bars sync perfectly.)

zebediah49
Fast Inserter
Fast Inserter
Posts: 119
Joined: Fri Jun 17, 2016 8:17 pm
Contact:

Re: Friday Facts #218 - Import bpy, Export player

Post by zebediah49 »

I'm going to add another voice to "well I guess it's nice if you happen to own that particular brand of proprietary hardware, but the rest of us consider it a waste of time".
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...)
That would be nice.
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.
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.

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.

OvermindDL1
Fast Inserter
Fast Inserter
Posts: 192
Joined: Sun Oct 05, 2014 6:12 am
Contact:

Re: Friday Facts #218 - Import bpy, Export player

Post by OvermindDL1 »

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.
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).

Polling the player data and game events and attacks and such via lua is significantly less performant though, but still doable. :-)

User avatar
Proxy
Fast Inserter
Fast Inserter
Posts: 165
Joined: Mon Mar 30, 2015 11:10 am
Contact:

Re: Friday Facts #218 - Import bpy, Export player

Post by Proxy »

1. FACTORI⚙
That gear is a thing... holy hell that is awesome.

2. there won't be any more FFFs?
what point does firday have anymore? what point does Life have anymore?!?

ske
Filter Inserter
Filter Inserter
Posts: 411
Joined: Sat Oct 17, 2015 8:00 am
Contact:

Re: Friday Facts #218 - Import bpy, Export player

Post by ske »

Proxy wrote:2. there won't be any more FFFs?
Really? There's still 2 hours of hope left!

EDIT: Just as I was clicking Submit, they posted it. FFFs can't stop, won't stop.

Rubicell
Manual Inserter
Manual Inserter
Posts: 1
Joined: Sat Jan 06, 2018 10:02 am
Contact:

Re: Friday Facts #218 - Import bpy, Export player

Post by Rubicell »

I loved what you guys did with the Razer Chroma! I was curious if you guys have plans for Alienware support too maybe? Thanks! :D

Post Reply

Return to “News”