[REL] Rockin Robbins EZPlot 2.0

[THEBERBSTER]

Another big and welcome advancement for the SH4 gamer.

[ColonelSandersLite]

Aside from megamods, I totally agree with the concept in theory. The real problem is silent hunter though.

For example, while it will work great if you're just changing a couple of dds files, what happens when your standalone mod edits menu_1024_768.ini or one of the games many sim files?

It will basically mean that you have to maintain a version of the mod for every megamod that you want to support, plus one for stock. It will also not be interoperable with small mods that require the same file unless you maintain a version for all of those as well which will lead to exponential growth on the number of version you need to support. If some of those mods are your own, then the temptation to merge in order to reduce workload is overwhelming.

Basically the silent hunter mod structure is crap. The only real solution I can see is to include clear instructions for manually implementing the mod, which some mods do. I don't really see a lot of people having the inclination to actually do it though.


There is one other way, and that would be to make a patcher program that can make the necessary edits to all the files. All mods would then be required to provide instructions that the patcher can understand, instead of direct file replacements. I have the skills to do that, but don't have the time or inclination so I won't. It's possible that somebody else will, but I very much doubt it.

[Rockin Robbins]

Originally Posted by ColonelSandersLite

Aside from megamods, I totally agree with the concept in theory.

Yes, megamods are the exception. But you'll notice that the mods "compatible" with the megamods aren't. They nerf and change many aspects of the underlying megamod.

Originally Posted by ColonelSandersLite

The real problem is silent hunter though.

Stop! You've just uttered a profundity. Take my EZPlot 2.0. You can't tell SH4 this is the outline for a BB, this for a CA, this for..... You have to find out every ship that can appear in any supermod combination and have a separate names silhouette for each ship that MIGHT appear! That means a separate directory "JBB_Yamato" for instance, containing a separate file "JBB_Yamato_shp.dds" with the silhouette in .dds format. It might be the exact same silhouette for each battleship, but you have to duplicate it for each ship. One letter wrong and forget it. That ship is broken.

In TMO all ships have the same silhouette, a position marker dot--a brilliant concept. But TMOPlot 2.0 will have 150 or so duplications of the dot, each named for the ship and in a directory named for the ship. No spelling errors need apply. A trivial task becomes quite difficult and time consuming to execute. It all starts with the Excel spreadsheet from hell which I will also make available for those who can put it to use.

Originally Posted by ColonelSandersLite

For example, while it will work great if you're just changing a couple of dds files, what happens when your standalone mod edits menu_1024_768.ini or one of the games many sim files?

It will basically mean that you have to maintain a version of the mod for every megamod that you want to support, plus one for stock. It will also not be interoperable with small mods that require the same file unless you maintain a version for all of those as well which will lead to exponential growth on the number of version you need to support. If some of those mods are your own, then the temptation to merge in order to reduce workload is overwhelming.

Basically the silent hunter mod structure is crap. The only real solution I can see is to include clear instructions for manually implementing the mod, which some mods do. I don't really see a lot of people having the inclination to actually do it though.


There is one other way, and that would be to make a patcher program that can make the necessary edits to all the files. All mods would then be required to provide instructions that the patcher can understand, instead of direct file replacements. I have the skills to do that, but don't have the time or inclination so I won't. It's possible that somebody else will, but I very much doubt it.

And that's my position too. Although technically possible, making the tools and making them available would just be opening up new floodgates for error. This stuff is exactly why Kapt Lehmann and GWX went to an installer. And I have philosophical problems with an installer because it's not transparent in function as JSGME is, nor are changes reversible. But I well understand why they used it.

Guys, I appreciate the support. Who'da thought modding a nine year old game would be worthwhile? But it still has some die-hard fans after all that time when contemporary games that were much sexier are gone from the landscape, and deservedly so most of the time. Wish I'd got off my butt in 2009 and done this but I thought at the time I'd be making enemies by doing so.

[ColonelSandersLite]

Originally Posted by Rockin Robbins

Stop! You've just uttered a profundity. Take my EZPlot 2.0. You can't tell SH4 this is the outline for a BB, this for a CA, this for..... You have to find out every ship that can appear in any supermod combination and have a separate names silhouette for each ship that MIGHT appear!

And that's exactly my point. With an object oriented system that's actually properly designed for modding, this would not be an issue at all.

For example, with a good structure, you could define a generic marker in the ship super class to be used if not specified later, define a marker in the shiptype class (i.e. light cruisers), only defining a special marker for individual ships in their specific classes if you really want a specific ship to have something special. Then, if a modder wants to make a change, they only need to change a few files.


But, since the data is not handled rationally under the hood, that's just not an option.

[TorpX]

A universal mod.

Not a bad idea, RR.



About mods trampling other mods features: I'm not too upset about a modder exercising some creative vision over the game; I'm dismayed about all the ways the game's limitations block us from exercising control over the game. There are too many things that are unfixable.

[Rockin Robbins]

EZPlot 2.0 is now certified to work with RFB or RFB/RSRDC with or without the RFB patch. If anyone is interested in a single RFB mod including the patch, let me know. I've merged them as I couldn't see any advantage to keeping them separate.

[xXNightEagleXx]

i don't know if it supposed to work like this but when applying this mod in tmo 2.5 silhouettes return to their original appearance thus not being represented by a dot anymore. Is this correct? I mean by exploring the mod folder, i see that it suppose to be like this, but at this point it invalidates one point of TMO which was reducing map information. Most time i heard you RR talk about this being more realistic than keep map contacts off....i'm so confused.