By (popular) demand, I have planned undo/redo support for the next release. I've already got it working for about 80-90% of the editor. Additionally, you'll be able to copy the undo log to the clipboard, for logging purposes. Obviously, after you close a file the undo/redo history is lost. Changes made can not be undone by S3D using the exported log, so backups of the original file are still recommended. That, or you manually have to undo using the log. Some things can't be undone this way though (deleted chunks, replaced images, etc), hence the backups.

An example log (of materials.dat), with dummy changes:

- chunk 9: int_halo.tga/Opacity, oldValue = 35, newValue = 40
- chunk 35: Properties/ParticleGenerator/GlobalScaleFar/DensityScale, oldValue = 0.1, newValue = 0.2

Brilliant Skwas:yep: Will make stuff so much easier, also when communicating stuff that might have to be put in manually. THANKS!

@skwasjer Would it be feasible to add a function that makes changes to files based on the saved change log? If so, perhaps that would solve the problems involved in consolidating several mods that mod different parts of the same file (scene.dat for instance). I can see it functioning much like a file patcher that only changes one part of a file that may or may not have been modded in other areas. The only problem I see would be in the case where one mod changes the structure of the file (i.e. removes a chunk or changes a chunk size).

Just a thought (I have them every once in a while and, in very rare cases, they are good one :rotfl: )

Keep up the great work on this wonderful tool:rock: :up:

Technically that is possible using my parser. The limitations are not so much deleted chunks, or the size, because the parser reads and writes the entire file and can change/insert/delete data anywhere.

The problem however is indeed still with the structure: not every chunk has an id, so there is no guarantee (neither by offset, or chunk index) that a change is applied to the chunk you want. So when a file is modified with additional inserted chunks before the one you want to patch, and if it doesn't have an id, you have a problem. Both the index and offset will now point to an incorrect chunk, so this won't do...

I'll give it some more thought in the future. For now, this is the best I can do.

:rock: And a good addition it is. Was just carrying it out a little further into wish land:D . You know how it is with us "users" the more you give us, the more we want:lol:


Just being able to see what changes were made is a vast improvement over having to physically write down every change made in order for another person to duplicate the changes. In my case, if I were attempting something like Leo's Living Breathing Ocean, no one would ever be able to decipher the changes I noted nor would I remember to document all of them:rotfl: But, with your change logs, it will all be laid out in a standardized manner.

If I open the scene.dat from SHIII I get the EnvData properties but if I open the scene.dat from SHIV, the tree for EnvData is empty but the values are there because I changed them via MTweaker for my Env-Mod.

What i do to alter already altered files is OPEN in the JSGME MODS folder/Backup/Data (make sure the file types at the bottom you want to open says [All Files *.*] . Then i can open the Scene.Dat.Living Breathing Ocean etc .

Please note: there is a confirmed bug in S3D regarding writing files that contain ObjectParticles. This is being investigated and a fix will be included in the next release and posted here asap. Again, this is why S3D is alpha.

PS: this bug is not related to the last post of Seeadler. I still need info from him to investigate this...

What Seeadler means is if you go to open your scene dat that has been altered via a mod from say Living breathing ocean , then opening from Silent hunter 4 wolves of the pacific / Data / Scene .dat . When you look at Env data / properties nothing comes up on the right hand side . It works thru the Mods folder as i have explained though .

I don't have jsgme and mods installed atm, so I can't check what you mean. I only understand it partially. I'll check it later...

You must be my president :doh:

;)

Another new cool upcoming feature is the ability to define a list of choices for properties. This is a snippet from the config file:

http://sh4.skwas.net/temp/EnumTypesDefined.jpg

I've taken the enumeration from the SHControllers.act in this example. This has to be done for all properties that are based on enumerations, so it will still be tedious work for me. But once this is in place, you won't have to guess for a value or look it up in documentation, or even in an .act... Cool?

Please note I've made the values more readable. In the .act file definitions are less friendly (C-developers style), ie.: DIAL_DEPTH, DIAL_SPEED. Spaces are not allowed though, so don't ask why the underscore is not replaced with a space. ;p

This is how it looks in S3D:
(notice Dial/Display is also showing a 'friendly' value, using same method)

http://sh4.skwas.net/temp/EnumTypes.jpg

Wow :up: is all I can say skwasjer ^^^^


RDP

Hi,

Let's hope, one day, to have a manual for 3Ditor... :rock:

...

Excuse, you has forbidden to me to write reply ... :lol:
DispVal and RealVal not correct ... it's not X and Y ...
You have Display = Circular ...

a) Yea I know. There is no way around this right in S3D now because the only data type available to encapsulate this property is a Vector2. I hope to add scriptable templates soon which allows the use of structures, so more specific types can be defined in the config file (aka struct SomeStruct { float SomeValue; color SomeColor; int SomeInt }. (This is just an example!). Together with the enum functionatility, this will allow any data type to be parsed correctly.
b) The .act says the property has an enum Circular, Linear. What's wrong with it then?

When DivingDuck is back, lets hope he can start work on it next to his other stuff... ;)