Strange behaviour of console output

[Artentus]

So, it's me again with another automation problem (this introduction would have fit perfectly into the gameplay help aswell, lol ).

My plan is to automate the updating process of Factorio from within my mod manager using --apply-update.
To know in what stage the update process currently is in I am trying to read the console output of Factorio (so I can know when it's done and close Factorio). However, I have now noticed that it appears to be impossible to redirect Factorios standard output.

When redirecting stdout I just did not get any feedback inside my mod manager which made me do some testing.
First I tried redirecting the output of other command line applications and my code worked fine.
Then I tried to redirect Factorios output directly to a file using the standard redirect feature of the consele ('factorio.exe -h > file.txt') and that did not work either.

At this point I am pretty much out of ideas. It appears that Factorio somehow writes to the console without using stdout, if that is even possible. Also I have noticed that the console does not properly display the working directory again after Factorio has terminated like it should do (you have to press enter once to get it to show).
Maybe one of the devs can enlighten me about what is going on with Factorio and the console.

[posila]

You know, it is the same behaviour as with Windows applications in C#, if you do Console.WriteLine() won't write to console.

For purpose of headless server, we call AttachConsole(-1) which makes the program attach to parent console window if it exists. It only attaches, but doesn't take control over the console as Console application would. Cmd won't wait for factorio process to exit and will continue executing other commands. For that reason we strongly recommend to run headless server on windows using command "start /wait factorio.exe <command-line-arguments>".

What do you need to detect update stage for?

[Artentus]

we call AttachConsole(-1)

Alright, that probably explains this strange behavior.
Funnily enough I'm using exactly the same hack in my mod manager but I didn't know it caused this problem.

What do you need to detect update stage for?

Well, I really only need to detect when the update has been applied.
I am showing a dialog to the user to signal that the update is still in progress. When the update has been applied the dialog should be closed so the user can take other actions.
I would just wait until the Factorio process has terminated but during the update multiple different processes are started that I have no control over.


So I do understand that what I wanted to do seems to be not possible.
In my other post you said the integrated auto updater doesn't use --apply-update. Do you think it would be possible to imitate the behavior of the auto updater so I don't have to start Factorio at all?
I'm just thinking if there were like a FactorioUpdater.exe I wouldn't have to bother with calling Factorio.exe --apply-update. If there were a documentation on how updating works exactly I would gladly develop such a FactorioUpdater.

[TrevorLaneRay]

Is this why I can't log the console by redirecting output to a file?
Since the current logging system doesn't include chat, I needed some way to record it...
But when I try to do this, the file just ends up empty.

Here's the .bat file I use to launch it, and specify a datestamped file for logging the output.

Code: Select all

@echo off
SET parent=%~dp0

REM - Here we just create a date/time string for naming the log file.
for /F "usebackq tokens=1,2 delims==" %%i in (`wmic os get LocalDateTime /VALUE 2^>NUL`) do if '.%%i.'=='.LocalDateTime.' set ldt=%%j
set ldt=%ldt:~0,4%-%ldt:~4,2%-%ldt:~6,2%--%ldt:~8,2%-%ldt:~10,2%-%ldt:~12,6%

%parent%bin\x64\factorio.exe  --start-server %parent%data\saves\game.zip --server-settings %parent%data\server-settings.example.json > %parent%logs\%ldt%.txt

EXIT

[Artentus]

It most likely is. As I said, the '>' operator does appear to not work at all with factorio.
The output seeems to be not redirectable.

[posila]

So I do understand that what I wanted to do seems to be not possible.

Hmm, there might be some way how to detect update finished. Reading factorio-current.log or monitoring factorio/temp/ folder for deletion of Factorio.exe.

Do you think it would be possible to imitate the behavior of the auto updater so I don't have to start Factorio at all?

It is possible, and probably not that hard. Beware we may change how updating works for 0.15 or 1.0.

I don't have any specification, but it works in kind of obvious way (except for diffs). If you look at info.json, there is "files" array containing instructions what to do with files. There are 3 possible actions "removed", "added" or "differs". The actions are self explanatory, I think. For diffs we use library called open-vcdiff (I think you'll be able to find implementation/wrapper for C#). "differs" action also contains "old_crc" and "crc" values. Old crc is CRC of a file before update, the other one is after update. CRC mismatch or original file missing is considered fatal error. For CRC we use function from zlib, so I guess it uses some standard (or well known) polynomial.

And that is it ... just open update.zip and apply changes as described in info.json. Windows version of Factorio does double restart, because it needs to copy itself to temp to be able to update executable at original location.

@TrevorLaneRay: Maybe you could use RCon to connect to server and read/write to game console from external application

[Artentus]

Thank you, I will give it a try then.

Beware we may change how updating works for 0.15 or 1.0.

No problem, thats just what you have deal with when using unofficial ways.

[mickael9]

@posila

There is this interesting function in Chromium that does exactly what's needed to have a console from a GUI application and be able to redirect its output
It uses AttachConsole like you said, the difference is that it does it only if there is no already open file descriptor.

https://chromium.googlesource.com/chrom ... win.cc#136

I have created a test application improving on this idea: http://pastebin.com/3xVkg9D7
It only reopens the file descriptors that are not already associated. I think this is the desired behavior.