...Perhaps just a zoom 3 (do any models have multiple zoom 3 FSH?), we don't need a whole lot of information, just enough to know what the model is, and perhaps its orientation.
Getting the data needed for the preview from either zoom 3 or zoom 5 is the same, programming-wise. The problem is that this is quite a bit of work, requiring restructuring the program internally, since as explained in my previous thread, it currently works with S3D files only.
-Models have a check-box next to them to decide what gets edited.
Hmmm, I have only seen this in web, not desktop applications; and even there, it's meant to compensate for the lack of the ability to select items in some "list control" in browsers. The Shift/Control way for selecting is the standard in desktop applications (and has the advantage of allowing range selection). And then (ie if having both modes) how to determine on which selection should operations applied on? We would need dual commands, like "Resize Selected Items" and "Resize Checked Items", which may be confusing to the user. Could you suggest a desktop application that uses both modes efficiently?
-Sorting options. Models can be sorted by size for easier finding. You could even do Date Created (By ignoring the first digit of the Group ID. If people edit their TGIs, then it's likely that they are already in some type of order)
These are quite easy to make actually, all I need is to add the Size and Date columns. Currently the items are sortable by any of the columns, only that little arrow indicating the sorting order is not shown (I'll add this too).
-Searching. Find models via TGI (the Reader way of "filtering" is quite powerful).
Please note that the list displayed in the MT is generally much sorter than the one in the reader: only the S3D files are displayed, and the 20-Z/R ones are collapsed in a single line.
-Notepad.txt support. Select models based on a list.
That final one might be useful only to me. Basically, I have a Reader script that calculates Occupant Size from a zoom 0 s3d. When I do things en-mass like this I often get snagged when some people rendered, say cars, facing south, while others have rendered them facing west. Then it is a matter of having the script say "if the width is greater than the depth, print the TGI". I then enter MT and re-orient based off this list.
While this feature wouldn't be hard to implement, I have some doubts about its usufulness, not only regarding the effort needed to implement it vs the time it will save custom content developers, but even its efficiency regarding the user alone: one will have to write a script, test and debug it, and finally run it and paste the results into the MT! And all this only to supposedely facilitate the selection procedure! Wouldn't it be more efficient to select the items one by one? Pls take into account that the new version will be displaying the model name, which helps quite a bit.
(MT may could this option built into it: Re-orient to length-wise or width-wise. This is probably just me though.)
Well, this is a quite custom feature, isn't it? Please don't make requests for features that you are going to use only once or twice, instead make requests for features that you will be using more regularly. For this reason, I rather lean towards respectfully declining it, as well as the previous one.
Now, my OS script no longer works after I re-orient. My script looks at two specific Vertices and gets the OS from that.
I could take a look at this script. Btw what do you mean by OS?
I believe that MT changes the order of these Vertices. I admit, I do not know how MT re-orients. I would believe that it doesn't just change the Instance of the s3d, as it works with a model that only has one rotation.
The Reorient operation only changes the instance IDs of the 20 views (S3Ds) of the model. It doesn't renumber the materials, neither changes anything inside the model, just renumbers the S3D instance IDs (in a cyclic manner), and that's why this operation doesn't suffer any crashes. For examplre, if you reorient the model 90° counter-clockwise, the 0x00030#00 model IDs will be changed to 0x00030#10. And these, will of course still be using the 0x00030#00 materials. And the opearation doesn't work for 1-Z/R models (it is disabled). More details in the MT Help (click on the help button and then click on the part of the program for which you want to display context-sensitive help) - it seems nobody is reading it.
Re-orienting X,Y,Z values is not too hard to do as a formula, but there are probably issues with U,V. I could see a way around this: Store the original Vertex values. Calculate the new X,Y,Z values. Find the original X,Y,Z that match the new X,Y,Z, and then set the U,V of the new Vertex to be the same as that old one.
Again, not sure the complexities of the S3D/FSH relationships that MT uses. You must change the MatID when you re-orient, right?
What you call "Re-orienting" here is actually the "Rotating" operation. This one indeed relocates vertices, and again, leaves the materials and UVs unchanged - why change these? This operation can be applied to 1-Z/R models only. Check my
SC4 Automata as Props tutorial to see an example. Actually I wished to have a real "Rotate" operation for 20-Z/R models as well, but unfortunately this is not technically possible (
here is the discussion). Therefore I made the Reorient operation for these models, as a rather poor substitute (effectively "rotating" the model, but in steps of 90° only).
