An idea of ridiculous proportions - Page 2

Commander Gizmo · 09-22-09, 10:55 AM

Actually, I write software professionally and already have a universal parser program that uses the backend and plug in library partially built in a csv. I would be offering this community a version that will be locked to only SH plugins for free rather than the commercial version. Since it is really just an app that can take COM and command line commands to parse files as ordered, it would meet all of your given suggestions. Since this app could easily be improved and expanded to handle SH4/5/6/etc I think it is very much still very much in demand and worth the effort.

I will say it again:
If you think it can't be done keep it to yourself. If I want to waste my life attempting such a project, it is my life to waste. Does anyone have any desire to use this thing, or should I just release the commercial version and ignore this community's release?

Stiebler · 09-23-09, 07:25 AM

Commander Gizzmoe's program seems to be an excessively complicated solution to a problem which could be made simple. It is *not* necessary for the programmer to have any information about the mod, although it is essential that the modder has the correct knowledge. But if the modder does not already have the knowledge, he could not make the mod anyway!

SH3 and SH4 (and, doubtless, most or all other games) have a fixed set of files necessary to run the game. Some are text files, such as the many .cfg files, some are data files, such as the many .dat, and .sim files.

All that the modder really needs to do is to write a simple script, which states:
a) which files need to be altered.
b) which parameters need to be located, and changed to what values.
Such a script could easily replace the common system we have now, where a modder hands out a bunch of modified files which may or may not be compatible with other files created by modders.

Let us take a concrete example. Let us pretend I have created an imaginary submarine simulation, 'SilentHunterStiebler', which requires only ten text files to run: text1.cfg, text2.cfg, ... text10.cfg, and also just ten data files to run: data1.dat, dat2.dat, ... data5.dat plus data1.sim, data2.sim, ... data5.sim.

The modder writes a simple script as follows:

COMMENT: text files first
FILE: data\cfg\text1.cfg
COMMENT: only one occurrence of submarine depth
CHANGE: submarinedepth=
TO: submarinedepth=20
CHANGE: crashdepth=
TO: crashdepth=150
FILE: data\cfg\text2.cfg
CHANGE: maxdestroyerspeed=
TO: maxdestroyerspeed=25
COMMENT: change 3rd occurrence of 'No_of_torpedoes'
CHANGE: No_of_torpedoes[3]=
TO: No_of_torpedoes=5
COMMENT: (and so on for all text files, ignoring any which do not need to be altered)

COMMENT: now the data files
FILE: data\library\data1.dat
COMMENT: change 1st occurrence of maxrange (4-byte floating variable)
CHANGE: FLOAT: maxrange
TO: FLOAT: maxrange=2000
COMMENT: change 7th occurrence of 'ArmorLevel' (4-byte integer)
CHANGE: INT: ArmorLevel[7]
TO: INT: ArmorLevel=200
FILE: data\submarine\data3.sim
COMMENT: change 3rd occurrence of 'TorpedoDoorOpen' (BYTE, probably true or false, but 16 alternatives)
CHANGE: BYTE: TorpedoDoorOpen[3]
TO: BYTE: TorpedoDoorOpen=1

This is all fairly simple, is it not? The comments are optional.

A program to implement this kind of script would have just a few requirements:
1. The user must be able to set the path to the root folder, called 'data' in this example.
2. The program must then check that the requested files are found at their expected paths - if not a warning must be given.
3. The program must then make the requested changes, and report any failures (for example, if the 3rd occurrence of 'TorpedoDoorOpen' does not exist, it must generate an error report.)
4. [The only truly difficult part.] The program must make a record of the changes, for the purpose of restoring the original values on request. (Rather like JScones' JSGME, but that program remembers files altered, we need to remember files and new values altered.) One solution would be for the program to make a copy of the original script, writing in the original values it found. For example: CHANGE: BYTE: TorpedoDoorOpen[3] could be written back to a copy of the script as CHANGE: BYTE: TorpedoDoorOpen[3]=0.

To write a program that would execute scripts like the example I have shown would be really rather trivial - the only part in which I lack personal experience is the restoring of values, so I'm not clear about the best way of remembering values put in by several scripts.

But let me emphasise again: the program writer needs NO knowledge of the files that are being written to, only the modder needs it.

Having said all that, there is little chance that anyone will adopt this simple modding system. Because:
1. For reasons that elude me, there are a lot of modders out there who like to grab all the low-lying fruit of a brand-new mod (eg SH5) before anyone else does. They will release mods of altered game files as soon as they can - and then move on to the next newly released game.
2. Some modders like to keep secret what they have done. Think GWX, for example. So they won't be releasing script files.
3. There are also a lot of modders who seem to lack interest in testing their own work before they release it as a 'beta'. Creating scripts would force them to test their own work, and then they would have to waste their own time, and not someone else's, on making the fixes.

Stiebler.

Commander Gizmo · 09-23-09, 08:09 AM

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 · 09-23-09, 08:10 AM

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 · 09-24-09, 07:55 AM

Quote:

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 · 09-24-09, 10:38 AM

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.

Commander Gizmo · 09-24-09, 11:26 AM

Quote:

Originally Posted by JScones

So you intend completely re-writing/re-developing SH3Gen, SH3Cmdr, JSGME, S3DEditor, JTxE, SH4MenuMaker, the Terrain Editor and many other tools that collectively have taken over 10 years to develop in various languages (let alone .NET or Win32) and in some instances by very experienced developers, into one "super application" covering both SH3 and SH4? What's your anticipated implementation date? I mean, have you considered that by the time you're ready to release such a beast, people may not only have moved on from SH3, but they may even have started moving on to SH5?

Just to clarify, I do not envision this thing offering the more in depth capabilities of some of these tools. For instance, the terrain editor (which I haven't even heard of) no doubt has a 3D view of some sort to permit you to see the changes you are making. While a plug-in for my app could be built to handle this, it might make more sense just to use the tool that already exists. However, once the desired changes have been made with the existing tool, my app could find these changes and build a script to make those same changes in any user's game files.

My app serves mainly as a database connection to all the variables used in all the data files rather than a fully featured editor for each data type. So another app could be written as a front end to mine which could use the database to access and change all the data desired. Thus the developer is freed from the trouble of finding and parsing the files in order to get and set the data therein.

Again, with a proper command set available in the plug-in interface a person could write a plug-in for my app that would handle the in depth editing of a program by means of their own forms, UI, etc. As to whether anyone would take the time, that is unknown at this point. I mght even undertake to write them all over time. The fact that my app could find the changes in the files and then write a script means that current tools can still be used to make changes and then my app used to apply them to the end user's game files.

Basically, although it could handle everything if we took the time to write the plug-ins, it isn't necessary for the program to serve it's purpose. Like I said before, I don't really intend to reinvent the wheel, just offer one source for all known game variables.

GlobalExplorer · 09-25-09, 11:35 AM

Quote:

Originally Posted by Stiebler

COMMENT: text files first
FILE: data\cfg\text1.cfg
COMMENT: only one occurrence of submarine depth
CHANGE: submarinedepth=
TO: submarinedepth=20
CHANGE: crashdepth=
TO: crashdepth=150
FILE: data\cfg\text2.cfg
CHANGE: maxdestroyerspeed=
TO: maxdestroyerspeed=25
COMMENT: change 3rd occurrence of 'No_of_torpedoes'
CHANGE: No_of_torpedoes[3]=
TO: No_of_torpedoes=5
COMMENT: (and so on for all text files, ignoring any which do not need to be altered)

COMMENT: now the data files
FILE: data\library\data1.dat
COMMENT: change 1st occurrence of maxrange (4-byte floating variable)
CHANGE: FLOAT: maxrange
TO: FLOAT: maxrange=2000
COMMENT: change 7th occurrence of 'ArmorLevel' (4-byte integer)
CHANGE: INT: ArmorLevel[7]
TO: INT: ArmorLevel=200
FILE: data\submarine\data3.sim
COMMENT: change 3rd occurrence of 'TorpedoDoorOpen' (BYTE, probably true or false, but 16 alternatives)
CHANGE: BYTE: TorpedoDoorOpen[3]
TO: BYTE: TorpedoDoorOpen=1

Interesting idea, but why not use something like SQL?

UPDATE <section> SET <value> WHERE <condition>

The game data could either be stored in a database and manipulated via the dbms, or it could be directly manipulated with a dedicated SQL interpreter (needs to be implemented of course).

Commander Gizmo · 09-25-09, 12:00 PM

Quote:

Originally Posted by GlobalExplorer

Interesting idea, but why not use something like SQL?

UPDATE <section> SET <value> WHERE <condition>

The game data could either be stored in a database and manipulated via the dbms, or it could be directly manipulated with a dedicated SQL interpreter (needs to be implemented of course).

Now you are getting it! That is just about the way the software would work out; although I'm not sure if SQL style lanuguage for scripting would be best, or something more custom. Heck, we could even do it with actual SQL.

The trick is that you would reference the actual files rather than have a real SQL database.

Another difference, rather an trying to store text stings everything would be key/value pairs so that you can change the value (or even the key I suppose) directly rather than trying to replace a string like "key=value". That's just way to clumsy for professional software.

When a value is changed, the data is altered in the matching file. This is handled through a plug-in that knows how to handle that file. If new file types are added to a new version of the game, you just create a new plug-in or change the existing one to handle it. The core program does not need updated.

Does any of this make sense yet?

JScones · 09-25-09, 11:00 PM

Quote:

Originally Posted by 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.

...

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.

<pictures Gizmo stamping feet and shaking fists like spoilt child> And your point is?

Does it help you to know that in my younger days I was a professional/qualified software engineer (Assembly, Basic, C, C++, CICS, Clipper, COBOL, Fortran, JCL, LISP, Pascal, Object Pascal, VB, .NET), before I escalated through the ranks of (project/program) management? I have owned my own software development business since 1984. I have entered into contracts with multi-national businesses to implement multi-million dollar software systems. I have led teams of upwards 120 staff throughout all stages of the systems development lifecycle. Software I have both developed and led development of is used in Governments and large financial institutions worldwide. My software has been favourably reviewed worldwide in magazines and newspapers. Even the simple freeware stuff I throw on my website has made its way onto many coverdiscs around the world over the years...

And yet there are other guys here who are much better coders than I am. So I fail to see the relevance of your point, other than as a misguided way of "demanding" some kind of respect... FAIL.

Indeed, maybe there's a reason why these other very good coders haven't walked down the path that you are embarking upon.

Now, having said that, how does your idea differ to the static and randomised events features that have been part of SH3Cmdr since 2006? These features already give the user the ability to alter ANY value (without needing to know what type it is) in ANY game file of ANY file type (except .XML) and with full reversal. Randomisation within user-defined boundaries, changes based on user-defined date ranges, user-defined probability, it's all been done. And all in less than 150 lines of code. With very limited instruction Hemisent used the feature quite successfully with his malfunctions and sabotage mod which is now an inclusion in SH3Cmdr.

It's not perfect and needs a few improvements to bring it up-to-date, most specificially the replacement of the static binary file offset searching with dynamic searching (I have half done this, but only for internal binary file changes), but it's there, working now and can be used by anyone who reads the instructions.

As it's completely self contained with no game dependencies, the code is portable. I gave it to the prospective developer of "SH4 Skipper" to plug into it. And I will plug it into SH5Cmdr, with my improvements, if there's a need for it there.

Now I see you've taken a year and are still fluffing around with the concept yet getting shirky with very knowledgable guys like Stiebler and GlobalExplorer who are simply trying to highlight the potential pitfalls. Not an overly effective way of engendering community support now, is it?

Commander Gizmo · 09-25-09, 11:06 PM

That comment wasn't directed at you man. Nor was I hoping to garner some sort of respect. It was merely an attempt to explain that I wasn't looking at a pipe dream and have actually written this type of thing before.

You say that it already exists, yet I still have to apply mods without these features, so something doesn't make sense.

No matter though. If the community doesn't want it, I'll keep it to myself.

Thanks for the information you guys have provided. I really do appreciate the knowledge that you have, and sincerely apologize for not showing it very well.

09-23-09, 07:25 AM	#17
Stiebler Fuel Supplier Join Date: Oct 2005 Location: London, UK Posts: 1,237 Downloads: 29 Uploads: 4	Commander Gizzmoe's program seems to be an excessively complicated solution to a problem which could be made simple. It is not necessary for the programmer to have any information about the mod, although it is essential that the modder has the correct knowledge. But if the modder does not already have the knowledge, he could not make the mod anyway! SH3 and SH4 (and, doubtless, most or all other games) have a fixed set of files necessary to run the game. Some are text files, such as the many .cfg files, some are data files, such as the many .dat, and .sim files. All that the modder really needs to do is to write a simple script, which states: a) which files need to be altered. b) which parameters need to be located, and changed to what values. Such a script could easily replace the common system we have now, where a modder hands out a bunch of modified files which may or may not be compatible with other files created by modders. Let us take a concrete example. Let us pretend I have created an imaginary submarine simulation, 'SilentHunterStiebler', which requires only ten text files to run: text1.cfg, text2.cfg, ... text10.cfg, and also just ten data files to run: data1.dat, dat2.dat, ... data5.dat plus data1.sim, data2.sim, ... data5.sim. The modder writes a simple script as follows: COMMENT: text files first FILE: data\cfg\text1.cfg COMMENT: only one occurrence of submarine depth CHANGE: submarinedepth= TO: submarinedepth=20 CHANGE: crashdepth= TO: crashdepth=150 FILE: data\cfg\text2.cfg CHANGE: maxdestroyerspeed= TO: maxdestroyerspeed=25 COMMENT: change 3rd occurrence of 'No_of_torpedoes' CHANGE: No_of_torpedoes[3]= TO: No_of_torpedoes=5 COMMENT: (and so on for all text files, ignoring any which do not need to be altered) COMMENT: now the data files FILE: data\library\data1.dat COMMENT: change 1st occurrence of maxrange (4-byte floating variable) CHANGE: FLOAT: maxrange TO: FLOAT: maxrange=2000 COMMENT: change 7th occurrence of 'ArmorLevel' (4-byte integer) CHANGE: INT: ArmorLevel[7] TO: INT: ArmorLevel=200 FILE: data\submarine\data3.sim COMMENT: change 3rd occurrence of 'TorpedoDoorOpen' (BYTE, probably true or false, but 16 alternatives) CHANGE: BYTE: TorpedoDoorOpen[3] TO: BYTE: TorpedoDoorOpen=1 This is all fairly simple, is it not? The comments are optional. A program to implement this kind of script would have just a few requirements: 1. The user must be able to set the path to the root folder, called 'data' in this example. 2. The program must then check that the requested files are found at their expected paths - if not a warning must be given. 3. The program must then make the requested changes, and report any failures (for example, if the 3rd occurrence of 'TorpedoDoorOpen' does not exist, it must generate an error report.) 4. [The only truly difficult part.] The program must make a record of the changes, for the purpose of restoring the original values on request. (Rather like JScones' JSGME, but that program remembers files altered, we need to remember files and new values altered.) One solution would be for the program to make a copy of the original script, writing in the original values it found. For example: CHANGE: BYTE: TorpedoDoorOpen[3] could be written back to a copy of the script as CHANGE: BYTE: TorpedoDoorOpen[3]=0. To write a program that would execute scripts like the example I have shown would be really rather trivial - the only part in which I lack personal experience is the restoring of values, so I'm not clear about the best way of remembering values put in by several scripts. But let me emphasise again: the program writer needs NO knowledge of the files that are being written to, only the modder needs it. Having said all that, there is little chance that anyone will adopt this simple modding system. Because: 1. For reasons that elude me, there are a lot of modders out there who like to grab all the low-lying fruit of a brand-new mod (eg SH5) before anyone else does. They will release mods of altered game files as soon as they can - and then move on to the next newly released game. 2. Some modders like to keep secret what they have done. Think GWX, for example. So they won't be releasing script files. 3. There are also a lot of modders who seem to lack interest in testing their own work before they release it as a 'beta'. Creating scripts would force them to test their own work, and then they would have to waste their own time, and not someone else's, on making the fixes. Stiebler. __________________ NYGM Tonnage War Mod - More than a mod: it's an experience!

09-23-09, 08:10 AM	#19
Commander Gizmo Watch Officer Join Date: Jan 2007 Posts: 339 Downloads: 76 Uploads: 4	A bit more detail perhaps? 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.

09-24-09, 10:38 AM	#21
Commander Gizmo Watch Officer Join Date: Jan 2007 Posts: 339 Downloads: 76 Uploads: 4	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. Last edited by Commander Gizmo; 09-24-09 at 11:29 AM. Reason: Spelling

09-22-09, 10:55 AM	#16
Commander Gizmo Watch Officer Join Date: Jan 2007 Posts: 339 Downloads: 76 Uploads: 4	Actually, I write software professionally and already have a universal parser program that uses the backend and plug in library partially built in a csv. I would be offering this community a version that will be locked to only SH plugins for free rather than the commercial version. Since it is really just an app that can take COM and command line commands to parse files as ordered, it would meet all of your given suggestions. Since this app could easily be improved and expanded to handle SH4/5/6/etc I think it is very much still very much in demand and worth the effort. I will say it again: If you think it can't be done keep it to yourself. If I want to waste my life attempting such a project, it is my life to waste. Does anyone have any desire to use this thing, or should I just release the commercial version and ignore this community's release?

09-23-09, 08:09 AM	#18
Commander Gizmo Watch Officer Join Date: Jan 2007 Posts: 339 Downloads: 76 Uploads: 4	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.

09-25-09, 11:06 PM	#26
Commander Gizmo Watch Officer Join Date: Jan 2007 Posts: 339 Downloads: 76 Uploads: 4	That comment wasn't directed at you man. Nor was I hoping to garner some sort of respect. It was merely an attempt to explain that I wasn't looking at a pipe dream and have actually written this type of thing before. You say that it already exists, yet I still have to apply mods without these features, so something doesn't make sense. No matter though. If the community doesn't want it, I'll keep it to myself. Thanks for the information you guys have provided. I really do appreciate the knowledge that you have, and sincerely apologize for not showing it very well.