An idea of ridiculous proportions

[Commander Gizmo]

Thanks for the feedback Stiebler. I don't understand part of your thought process though. How do you intend the software to know how to find and edit the values in the files? Many are not ASCII files, but rather binary files with values that are not locked to a specific location within the file. Further, additional files may be added or old files removed in order to provide the functionality desired. I am not following how you would intend for this to work.

In fact, quite contrary to your opinion, I think the logging is the trivial part. Parsing many files of different type into their base objects and those objects' properties can be quite a task indeed. I do not intend to be argumentative with the responses I get, but I apparently posses a method of software design uncommon among my friends here at SubSim.

As for scripts, that is the intended (or at least one of) way for this software to work, thus allowing the exact functionality you describe. It would also except command line functions however, which would permit someone to write a small program to execute them in order if they really desired some secrecy as to what changes were made. Personally, I think it is ridiculous to try to keep things secret as I only have to use a file compare program to see each and every change made by any program. It is also possible to use debugging tools to trace all operations performed in a folder/registry hive in order to deconstruct an installer. Trying to keep secret the changes in a MOD is in practice impossible. You can only make it more work than it is worth to find them. I think my suggested software would permit either method that was desired.

When it comes to making mods, this software would function as a one stop shop for changing any value or file in SH3/4/5/6, whatever. It would permit you to access all known data for the game in a categorized listing and change whatever value you wanted to any possible range for the value type. Changing art would have to be done by file copy in most cases since the locations in these files are set by the config files and not standardized. In that case, the software could even give you a preview of the file and copy it into place much as S3D does now.

MODS would need meta data not so that the software knows a great deal about them, but rather so that the user is informed as to what they are using. More of a convenience than anything. If this is to work, a non modder would have to be able to use it with a similar knowledge base as is required to use JSGME.

What is more, if it were properly designed, it could probably construct a script file by doing a comparison between a fresh install and a changed folder and find all differences. A modder could then just tell it to build a script rather than have to do so themselves. At the very least, a script building UI would not be that hard to make if a bit time intensive for the programmer (myself in this case).

However, since it appears that this community prefers the current method of mod application for this and future versions of the game, I am content to only release the commercial version of the software. I can always use it on my system regardless of what everyone else does. You are welcome to purchase it and write your own plugins for SH3/4/5/6+ files or any other game for that matter.

[Commander Gizmo]

I feel I should point out that I am mostly offering to build the UI for all of this, which would then accept plugins to handle the actual grunt work. I would be happy to write the main plugins for the app, but the community could create their own as well.

For those of you unfamiliar with how programming with plugins works, here is a quick review: The application exposes an interface which specifies what commands it will accept. A plugin can either give commands, handle commands, or both.

For example, if someone wrote a plugin that knew how to parse and change the data in a *.dat file for SH5, it would register to handle commands sent to the application for that data type. However, if the plugin wanted to create some dynamic data prior to loading the game (such as randomizing a value like the crush depth), it would send the command to the application to edit a particular file, at which point the application would call the plugin that knows how to handle that file. That could even be the same plugin (though I would hope whoever writes them knows enough to separate them as they should).

Another plugin type could simply request data from the application about certain files in order to verify that they match what is desired. This would permit someone to write code to find particular issues or problems commonly experienced by users and then resolve the issue. An example: The flat sun fix. Many users report an issue with a flat sun and the cause is known. In the process of installing a mod or resolving common issues for a user, it could ask if they are experiencing this issue and then change the values accordingly to resolve it.

These are simply a few ways that this sort of open ended modular design permits. Because the software does not limit what changes occur, but rather just exposes the data to be altered a user can set up things however they want. And because the software simply exposes the data in a modifiable form with automation available, it would be possible to programmaticly handle just about whatever you wanted to do with that data. Basically turning the SH3 data files into a database.

What is more, the intent is to make the application COM accessible (why not?) which means that it would accept a basic command set from other software should someone care to make use of it.

[Stiebler]

How do you intend the software to know how to find and edit the values in the files? Many are not ASCII files, but rather binary files with values that are not locked to a specific location within the file. Further, additional files may be added or old files removed in order to provide the functionality desired. I am not following how you would intend for this to work.

It is very easy to find and edit the values in the files, both for text files and binary. The program just searches from the top of the file downwards, looking for the requested variable named as a text string (which will be case-dependent). It often happens that there is more than one occurrence of a variable, such as 'ArmorLevel', so the program neeeds to keep counting each occurrence until it finds the correct occurrence requested.

I have used this principle to release executables which stamp new data over existing SH3 files, while making a back-up of the original file, see for example my 2005 Radar_Detection mod, or the 2008 'RealWeatherFix'. The idea is not new. The talented TimeTraveller used the same principle to alter many files with his MiniTweaker and FileAnalyzer mods back in 2005. Both these programs contain sample script files with instructions for the user to create his own. FileAnalyzer, in particular, can locate variables in data files that are not dependent on their precise locations.

You are correct to say that, if the files have been lengthened (or shortened), or new files (such as new ships) have been added, then this scripting principle will be unreliable. But I thought the whole point of your proposal was to allow the user to install compatible mods? Once the number, or size, of game files has been altered, then compatibility becomes impossible, although it might be possible to create scripted files solely for NYGM, or GWX, or WAC or other popular super-mods.

For example, NYGM contains its own extended file zones.cfg to implement its unique 'slow-sinking ship' model. All other ships (merchants and warships) have had to be adapted to fit this new zones.cfg file. No scripting principle, nor your proposed new program, nor any bunch of changed files, can get round this problem, because who knows what other new ships the user may have added to his set-up? These kinds of unique changes will still have to be made the old-fashioned way, with JSGME.

However, let me make clear that I am not advocating the scripting principle that I have outlined in this and my previous post.
It would be nice to have, but no-one wants it for the reasons stated previously.

Stiebler.

[Commander Gizmo]

First of all, thank you for the feedback. I am happy to finally have some dialog on the subject.

Just because you were unable to accomplish a solution to the problem, you assume no one else can either. How sadly close minded of you.

There is indeed a simple solution. Rather than blindly and clumsily looking for the x numbered occurrence of a value, a parser can take an object oriented approach. Find all the objects (which would have to be unique to function in almost any file) and then the properties there of. Rather than needing to know that a ship is the fourth or hundredth one in a file, you reference the unique identifier for the object and then the desired property. Because all files of a type follow a format, new files added can also be easily parsed using this high level parser rather than a best effort approach.

Coupled with a scripting language or plug-in functions with if...than...else statements and pattern matching, you could add, remove, and change any value in any file with confidence.

The very fact that the files exist and are read from by the game proves it is possible to parse them this way. How do you suppose Ubisoft created the files? Surely they did not open notepad to add a new ship. The game must have some method of parsing these files at a higher level or adding your new ships would be pointless.

Are you saying that all known SH3/4/5/6+ files store the value identifiers as plain text? There are no truly binary formatted files?


Stop trying to place your own limitations upon me. Does it help to know that I own an IT firm and don't have to write my software on my own? I do this professionally people.