Fri Oct 10, 2014 1:47 am by sparcdr
You could go with option C and retrofit the current launcher to use Steam's authentication token in lieu of the username/password bit, stripping out the current download mechanism and forum module, then changing the way parameters work so one could launch Automation with command-line parameters matching the available customizations in the launcher in turn including the launcher as an optional but separate startup option. (See ARMA 3; they added a launcher AFTER release as an option in-Steam)
To those complaining about resources, this is 2014, and all PC's shipped including laptops have at least 4gb inclusive with quad-core laptops costing only $700 USD, and similarly equipped towers the same. Steam in the last year revamped its process model to isolate specific tasks to better take advantage of threading, allowing asynchronous updates if the option is selected in each game's properties menu. The ram usage has been reduced to 70mb in the last update from 100mb, and if you know anything about threading you'd realize that a paused task is inconsequential to the likes of CPU overhead, even if there are 24 of them. RAM is not indicative of usage depending on the type of allocation as indicated by resource monitor. Shared memory is not more memory used just as free memory is just memory waiting to be used. The overhead of a threaded process is relative to the amount of private structure and duplication involved as well as the frequency in which it occurs in and out of sequence, rather the fact that it simply exists appearing to occupy space and time as to the lay.
The only valid argument I can really hear is compression and bandwidth use as the developers are located in Australia where pervasive internet without fair data caps is not a universal option, though I honestly can't see how one could hold on to that argument as one that plays games, as it's just the cost of that luxury. Many people play DayZ Epoch and Overpoch on ARMA 2 OA, which is tremendously more heavy on resources of every kind across the board, and I have never heard anyone I know down under complain about such a notion.
Automation in principle already is incremental in nature, and would require no additional work except learned the use of Steam's SDK tools to make said patches. As work would then process toward removing unnecessary network functionality from the current launcher, one would realize the only really useful or sought after function that would utilize network code in the launcher would be a multiplayer games list counterpart to a Steamquery API solution. An agreement with Valve would allow rapid integration with its native and widely used server browser, which supports games such as ARMA 3 and Natural Selection 2 as well as Source games. Especially considering that Gamespy is in its grave now, it's not reasonable to spew conjecture about bucking this upward trend as many are soon to follow.
I for one strongly disbelieve that this venture will set you back further than a week or two so long as you have your ducks in a row, as you already have the launcher in a working state. I can understand one point about this transition being the settings format and idealistic use of Steamworks API to save cloud data, which includes resolution, quality, profile customization and other parameters. From the get-go these should have been initialized after the game was launched, not before as it is currently.
Having programmed my own XML save formats for various tools in the past, I did so knowing by definition they are JSON compatible, unlike traditional binary payloads. But it's important to note one could still use binary formats encoded as base64 as is a happenstance in common practice, whilst using existing API's and not making duplication risking further quality issues by bugs, with only modest time spent doing so.
Thank you for your time and continued efforts on the project. To those else, thank you for reading.
