x2msm.exe frontend?

[HwitVlf]

I expect Verdite is the only one using the Fromsoft command-line tools right now, but I'll still ask everyone:
Would a "front end" tool for x2msm/x2mdo be of helpful?

If anyone doesn't know, a front-end is a tool that lets you run a command line program by pushing buttons etc rather than typing commands into "the black window of confusion".

And if a front end would be helpful, would a "drag and drop" converter or a multiple-file-select window format be more useful. I ask because I'm setting up something similar to a front-end for part of a Map project and it wouldn't be far out of the way to throw one together for MSM/MDO if it would be useful.

[Verdite]

I can see how this would help, it would stop newtimers giving up on using the command line, personally I can output map pieces fast by using the cmd, and its just a case of remembering the names of the msm and mhm files to look for in the map piece editor.

[Holy_Diver]

Yeah it would. Bat files help a lot too. Best to express the "front end" in pure graphical terms. And have it drive a batch file. That itself accesses the command line tools. All of these different levels have important roles to play. In Linux all applications are expected to obey this hierarchy.


PS: x2mdo is going to be obsolete so you should support x2mdl. It's going to output MDO and MDL files together before long. Since MDL is inadequate as a graphical format, and MDO doesn't have animation. I don't know about x2msm but it will need to be ported so that it can be free of Windows. You should make one combined front-end (GUI) for all of them. And separate commandline scripts files for each of them.

[HwitVlf]

x2mdl already supports drag and drop, right? So it seems like a frontend would mostly be useful if using switches or simply to consolidate tool controls. Can you give me a list of the switches etc it supports?

[Holy_Diver]

The switches are in --help. You'll probably see them if you just run it without inputs too (you'll have to look fast if CMD.exe isn't open)

You need scripts to make commandline tools really convenient. And GUIs help a lot too. Its all about keeping everything in separate problem domains. Usually developers are not involved in maintaining scripts and GUIs.


PS: I don't have any plans to work on anything other than x2mdl and like tools for making custom files. I am working on a PalEdit program that can tweak models and save them. But that's a secondary function and it doesn't make models from scratch. I suppose that could be part of the import feature. But the problem domain is not well defined, so I am reticent to interbreed the two. If it did import models it would just call upon x2mdl to do so, and probably with little to no options. Maybe an option to choose an import tool.

I am disappointed that the Assimp project's people are pretty much a lost cause. But I put a lot of work into Assimp, and its a good idea if not a good project. So I'm going to keep using a bastardized version of it for x2mdl. It does more than just import with all of its filters. Cache optimization is really important. If SOM becomes a media darling I might go as far as to encourage programmers to fork the Assimp project to make it a more accessible platform.


PPS: There is a real problem with SOM's x2mdo program. Probably the MPX files too. They are broken into tiny pieces that almost definitely really slow down games. In fact I wouldn't be surprised if this practice is responsible for a lot of the slowness. It's a problem that I intend to look at when I start working with PalEdit again here in a bit. As part of preparing an extension to draw the arm(s) for games...

All that is needed is a Save feature. And I intend for there to be a way to run either PalEdit or Somplayer.dll as a commandline script. It may be a moot point if x2mdl is made to save .mdo files. But opening the models into PalEdit and then saving them should be sufficient to optimize out the many pieces problem. Which should improve performance (ex. a tree model might be 50 pieces when it only needs to be 1, so every piece introduces a restart of the video adapter degrading performance)

[Holy_Diver]

x2mdl already supports drag and drop, right? So it seems like a frontend would mostly be useful if using switches or simply to consolidate tool controls. Can you give me a list of the switches etc it supports?

Also, just for the record, all Windows applications (and scripts too) support drag and drop. The name of the file just becomes the first argument to the program when it starts up. Any program that works with files is setup to work that way. I don't think non-commandline programs are any different.

[HwitVlf]

I don't even have a recent copy of x2mdl, nor the time to track down and figure out all the switches. But I left room in the GUI for adding extra options so I can add support for x2mdl or other later. If you'd like to give me a list of the switches with a brief description of their function, it would certainly speed things up, but perhaps you're as busy as I am.

While theoretically Microsoft may say all command line support drag and drop, I believe if you try drop an x file on x2mdo/msm you'll find why that isn't true. Which is why I thought a front end might be useful. 

Made a simple Helper tool which I'll post in a separate thread. I took a little extra time to add a PRT editor to maybe help the "remember" issue Ben mentioned when making PRTs.

[Holy_Diver]

^There actually isn't a --help option in any version of x2mdl it seems. Because it apparently doesn't have any switches that are not experimental. Although that's no excuse. Just an oversight.

From what I can tell you can drop any number of files onto it. Or that is pass them in a list as arguments. If a number is encountered in the list that number is used for the SOM_MAP pose animation ID.

Experimental options are --x-abe=1 and --x-abr=n. Where n is the blend mode number. And 1 enables the blend flag. The same mode will be used for the entire MDL file. N can be 0, 1, 2, or 3. But I don't know off the top of my head how/if SOM interprets all of those.


I am not sure why x2mdo/msm don't support drag and drop since you didn't say. As I recall x2mdo would popup a graphical drop box or something. But like I said in your announcement thread I couldn't get it to work the last time I tried. Not by any means.


EDITED: Oh yes. You mentioned d3drm.dll in your other post. That alone I think is a good reason to remake x2msm. Do the MHM files need it too? I haven't dug into that format. MSM is a little quirky though. There is a subdivision file structure for vertex lighting.