MDLops in wine or playonlinux?

[xander2077 80]

i had this working before, i already extracted the mdls and mdx from kotor1 that i wanted to work on, then used mdlops to convert them to ascii-mdls, now i have them imported into blender, however i am missing one of the models i want to modify. since it is a mdl file from a mod i simply copied and pasted it into my work folder with the rest, from my override folder, then i went to try and run mdlops and it wont run any more. either that or the install i had working is gone and im trying it the wrong way. does anyone know how to get the mdlops exe working in wine or playonlinux? trying to track this down in the official wine db is not giving me any results. since wine doesnt give the same functionality as windows exactly, it is a bit different trying to get the program running. even with the libraries i suspect it needs to run installed, it crashes every time. i also have to install the perl differently than windows, so this is going to be a headache. it wont interact with my perl installation in linux at all, since it is an isolated virtual drive. playonlinux is my go-to wine interface, since winetricks is not really working well for me (too confusing and restrictive) and q4wine is not much better but i have used it before in some cases. does anyone know what dependencies mdlops has (assuming windows does not have the proper libraries installed) or if there is an installer for perl that will work in wine?

[DarthParametric 3,784]

MDLOps is a self-contained exe. You don't need a Perl install for it to work, at least under Windows. Whether you can run the Perl script directly under Linux with a Perl install, I don't know. It should be feasible, in theory.

[LiliArch 115]

Yeah, mdlops.exe doesn't require Perl being installed. On the other hand, if you do have Perl installed, you don't need the exe, and thus, you should be able to run it on Linux without faking the program to think it is running on Windows. There's some Windows-specific libraries, but switching them to Unix ones should be pretty straightforward.

[xander2077 80]

Yeah, mdlops.exe doesn't require Perl being installed. On the other hand, if you do have Perl installed, you don't need the exe, and thus, you should be able to run it on Linux without faking the program to think it is running on Windows. There's some Windows-specific libraries, but switching them to Unix ones should be pretty straightforward.

 

ok, well i have not been able to figure out how to do that. the reason it would be cool is because im having errors with some of the models i try to write as ascii.mdls. usually the player made ones. now i had it working before, but for some reason i misplaced the models i already converted and had working in blender, that i wanted to edit or view (for texturing) and trying to recreate them works (to a degree) but blender wont read them. it will import tons of other models except a few that seem to have something go wrong during the mdlops conversion. as always i think the majority of the problems i have with compatibility of plugins and programs goes back to wine, maybe some missing library or more likely a dotnet problem.

 

anyway, i thought maybe it was a problem with the plugin in blender 2.74, but that one at least works. i cant figure out how to install the import/export plugin into blender 2.49 (which i do have running in wine as a portable exe already packaged with lots of game model importers, everything it seems except for K1 &K2 models?) anyway. i cant get my Ktool working again either. it was going good for a while and now it will not even work, at one point it worked and would not recognize the game directories when it had previously. so i have no shortage of compatibility issues when it comes to native windows programs.

 

if what you say is true and mdlops can run natively in linux using perl, i wish i knew how to get it working. wish there was a native port of ktool for linux too but that project seems to have died long ago.

 

let me try and break it down. wine is sort of like a bridge between whatever windows code there is and how linux works. every time there is a security update, it can negatively effect wine because it may or may no longer know how to talk to linux and emulate a windows environment properly. what can occur when there is this coding mismatch, where wine calls for a function that changed in a linux update, is this, there can be stack overflows, memory errors, and other anomalies that will not allow a program that used to work to function the same way. so wine is not an ideal solution 100% of the time. and the worst part is that there is not always an error window that will pop up to let you know there is an issue, sometimes it just crashes with no explanation or hangs. sometimes the program never opens. sometimes a debug will not reveal the issue or is very technical with hexidecimal and googling that leads nowhere.

 

the culprit is usually dotnet. so what i suspect happened is that wine no longer knows how to get dotnet working in a linux environment, and the compatibility patch between linux and windows programming is borked now, since the coding in linux base changed several times and wine has not caught up with those changes yet. why? well i think it has to do with security, and something similar to the SSL fiasco going on. but it is a dotnet issue. just as they get it working it seems like it gets ruined after every update. so i think i will have to wait til an updated version of wine comes along to fix those issues. that is going to be a long shot though. linux coders are paranoid about dotnet and other parts of microsoft code with blatant exploits, so they usually have to work overtime to come up with a workaround to fix the issues, and as a result dotnet can have reduced functionality, or even not work well enough for windows programs to behave properly. windows programs that depend on the actual windows version of dotnet tend to misbehave in most cases in the wine version, because they are so thoroughly picky, and it is not always possible to fix that by actualy installing the real dotnet from microsoft. sometimes it works and sometimes it dont.

 

so in short a native version of mdlops would be highly desireable, since i think the problem with converting the models to ascii in some cases is effected by these errors producing the wrong output in the ascii model. and as a result blender (running natively) does not know how to read the model so it gives a bunch of errors and imports nothing.

[LiliArch 115]

I must admit, I'm with the Linux coders in this. .NET is terrible (no offence, C# programmers on board). Luckily, MDLOps doesn't require it. KTool does, though, and even as I'm not exactly capable of troubleshooting that one, one thing to consider: it uses an ancient version of .NET, so maybe it is possible that new versions of Wine don't support it anymore? Perhaps you could try older version for that one? (If I recall correctly, the version of .NET that KTool uses is 2.0.)
 
But lucky for you, that's the beauty with Perl (no offence to those on board that hate it). It is natively cross-platform compatible.
 
As you're using Linux, I assume you are familiar with command-line, so bear with me. If something is unclear, please ask for an explanation. I don't use Linux, so I can't really test, but in theory, it should work; I can help you to troubleshoot if needed. In the MDLOps folder you downloaded, you should have a file named "mdlops.pl"; that's the one you need. (Make sure there's a "mdlopsm.pm" in that folder, too, though.)
 
So, here we go. You have Perl installation up and running, and the path variable added? Go to command-line, navigate to the folder where you have your mdlops.pl, and run command "perl mdlops.pl" (or alternatively, don't navigate to the folder, but instead use "perl [path_to_folder]/mdlops.pl", but that requires a whole lot more typing, if you're doing that multiple times in a row, and in any event, it increases the risk of mistyping, which is awful when you get your huge list of parameters typed and then there's a misplaces character that screws the whole thing because it directs to a floder that doesn't exist). If you are lacking libraries, you should get error message that tells which libraries are missing. Install them and try again. After you have everything installed, you should be good to go.
 
If there's some required libraries you can't install, list them here (or PM me, but I would assume that other Linux users - if there are any - might be interested in that, too), and we'll look for alternatives.
 
Out of curiosity, what's that Blender plugin you're using?

[DarthParametric 3,784]

Could be this one (link in second post) - http://deadlystream.com/forum/topic/3105-wip-kotor-model-exporter-for-blender/

[xander2077 80]

I must admit, I'm with the Linux coders in this. .NET is terrible (no offence, C# programmers on board). Luckily, MDLOps doesn't require it. KTool does, though, and even as I'm not exactly capable of troubleshooting that one, one thing to consider: it uses an ancient version of .NET, so maybe it is possible that new versions of Wine don't support it anymore? Perhaps you could try older version for that one? (If I recall correctly, the version of .NET that KTool uses is 2.0.)

 

But lucky for you, that's the beauty with Perl (no offence to those on board that hate it). It is natively cross-platform compatible.

 

As you're using Linux, I assume you are familiar with command-line, so bear with me. If something is unclear, please ask for an explanation. I don't use Linux, so I can't really test, but in theory, it should work; I can help you to troubleshoot if needed. In the MDLOps folder you downloaded, you should have a file named "mdlops.pl"; that's the one you need. (Make sure there's a "mdlopsm.pm" in that folder, too, though.)

 

So, here we go. You have Perl installation up and running, and the path variable added? Go to command-line, navigate to the folder where you have your mdlops.pl, and run command "perl mdlops.pl" (or alternatively, don't navigate to the folder, but instead use "perl [path_to_folder]/mdlops.pl", but that requires a whole lot more typing, if you're doing that multiple times in a row, and in any event, it increases the risk of mistyping, which is awful when you get your huge list of parameters typed and then there's a misplaces character that screws the whole thing because it directs to a floder that doesn't exist). If you are lacking libraries, you should get error message that tells which libraries are missing. Install them and try again. After you have everything installed, you should be good to go.

 

If there's some required libraries you can't install, list them here (or PM me, but I would assume that other Linux users - if there are any - might be interested in that, too), and we'll look for alternatives.

 

Out of curiosity, what's that Blender plugin you're using?

 

wow, im glad someone agrees with me about dotnet. it is atrociaous. now if i get perl running and the modlops installed, im pretty sure i can compile it so that there is a link on the desktop that will run commandline for me instead of typing it all the time. console commands are very powerful tools in linux but if i dont have to use them i would rather not,

 

as far as the plugin goes, it is the newest version of neverblender.

 

it actually is flawless. i have yet to blame that for the issue. well i would not say flawless but it is written to do what it should, which is import actual extracted game models and then export player made ones.

 

actually i found out what the issue really was. i was attempting to import a player made helmet that i had previously converted to an ascii-mdl before, but i forgot i was editing it in max, and 3dsmax is another one of those things that doesnt quite work in linux. i could not do anything in it. just stare at the model, so i gave up on it in max. anyway the nwnmax plugin for that is what i used to import the model to max, so i guess it is much better at forcing models into the program, and i think i remember a button or option that allowed it to be stripped down to just the mesh but anwyay... aside from that i kept trying and trying to get the ascii-mdl to work. i tried downloading the mod again, converting it to an ascii from that folder, and i even tried changing the name and extension to lower case thinking that might help, but nope... what the issue was? well the model had an empty instead of a really tiny cylinder placed as the bone for the goggle hook, and neverblender doesnt know what to do with empties, so it errored out.

 

so i did some reading up and found a forum post where people were discussing different methods of getting models from kotor and other mdl format games, (xentax) and this link took me to a place where there was a zip file containing a blend file for blender 2.49b. this opened up the scripts window correctly and allowed me to run a script from there ( a really old way of doing it) and i was able to run a really really old version of the mdl import plugin to import that ascii-mdl. and once i got it in blender 2.74, i saw it clear as day, there was an empty in the scene. and although it works in kotor like that, (and i dont know how unless kotor only cares about the name of the goggle hook and not what it actually is), neverblender is still not sophisticated enough to import it that way becasue it is not expecting the goggle hook to be an empty. so mdlops was not the issue at all.

 

anyway i sure will look up everything you mentioned and hopefully before long have a working native mdlops. there are other ways i could have done it but i am not really excited about hexidecimal, so hex2obj is something i probably would have tried, but not yet.

 

as far as ktool goes, i have tried re-installing the old version of dotnet and it still doesn't work. the fact i had it working before means i installed it right, but all the recent security updates have borked compatibility between linux and windows for a time so i wont even try to fix that yet. but i also found something very interesting that will hopefully give me an alternative for extracting game models natively in linux. it is called xoreos (sounds greek to me) but anyway. it is an open-engine implementation of NWN with its own set of dev tools so people can manipulate the NWN assets for the engine. i suppose it is somewhat like openmw only for NWN, and as a natural ofshoot of that there would be a whole slough of tools one could use for KOTOR instead of ktool and the others that were designed for windows. interesting stuff...

 

Could be this one (link in second post) - http://deadlystream.com/forum/topic/3105-wip-kotor-model-exporter-for-blender/

 

actually no, i have not tried that pyscript yet, but so far i cant get anything but neverblender working in the dropdowns, and that kmdl script is probably one i will have to try by using the scripts window in blender. i have not had much luck installing scripts in either version of blender i use, and it usually boils down to one of my pet peaves, great tool, terrible instructions on how to use/install it. not saying that script is in that category, just what i have run into a lot the last 8 months.

[DarthParametric 3,784]

By "empty" do you mean a null or dummy object? If so, they are used in all KOTOR models (and basically every other model format) for all sorts of things. In the case of the goggle hook (and head hook, hand/weapon hooks, etc.) it's just a reference point, which the game uses to position additional models. In other cases, they are used as containers if you will, to group objects with a common pivot point/axis. They get used in skeletons in this manner.

[xander2077 80]

By "empty" do you mean a null or dummy object? If so, they are used in all KOTOR models (and basically every other model format) for all sorts of things. In the case of the goggle hook (and head hook, hand/weapon hooks, etc.) it's just a reference point, which the game uses to position additional models. In other cases, they are used as containers if you will, to group objects with a common pivot point/axis. They get used in skeletons in this manner.

well i figured that, but the other mdls i imported into blender did not have dummies, instead they import a tiny cylinder as the placeholder and the mesh(es) are childed to those at a consistent distance from that object. im sure the export script compiles the necessary things to make it work in kotor or NWN, all im saying is the specifically player created dummy being the way it was (which was completely different from the imported vanilla ascii-mdls from the game itself) was what threw off neverblender. whatever was done to make that model work in kotor, was not exactly the format neverblender was expecting, so while it worked in kotor, it was different enough that the import script would not recognize it as the same as the other models. comparing the two (the extracted game models to the player made ones) there is usually some kind of discrepency, some are minor, and some are enough to confuse these import scripts. im all about details, so knowing the rules of what a model has to be in order to work in game is important. that is how they compile these scripts for import/export. by focusing on what parameters the model has, and then putting all those things into a script that looks for that checklist of parameters to find a match. if it finds a square peg trying to fit in a round hole, then it wont import and in many cases wont even export, or will do either with errors. so i guess you could say what i want to accomplish is make the models as compatible as possible with the template of the extracted vanilla models, to avoid problems like this in the future.

 

what i would like to find is a list of what kotor models need to have in them to function in the game, and also what is done for you in the export scripts. but usually tutorials do not get that technical. things like coordinates, scale, units, and what has to be in a scene. consistency is important. that is why all these vanilla goggles/masks have the goggle hook in the same place, which is right about where the bridge of the nose is. it is up to the modder to put the mesh the correct distance from that goggle hook for it to look right. but there is more to it than just filling in the blanks...

 

when i imported one particular model, t didnt hurt anything for the empty to be removed, it actually cleared a lot of headaches up. the orientation of the "empty" xyz was different from the global xyz, so trying to symmetrize or extrude became a pain until i figured out to remove it and apply the transformation and rotation. then it was back to normal and behaved more like the other imported mdl files im working on.

 

another thing is the materials attached to the model are confusing. it has a bajillion of them and i suspect it has to do with the way the model had to be imported differently than the others. im at the point where im not sure if i can work with the model the way it is or if it would be better to just export it as an obj and then reimport it to a new scene with one of the other goggle models to use as a template, kind of like importing a skeleton to build clothing or a suit of armor around.

 

speaking of which, i would love to find a way to add a new set of armor/robes to the game, but i have not been able to extract one from kotor or find a player made one yet. usually they just use scripting and other magic to add a new set of armor using the existing files by reskinning those. but in this case i want to add something completely new, which really needs a new model.

[DarthParametric 3,784]

I'd say the problem was almost certainly MDLOps, rather than anything specific the modder did. It doesn't compile models properly, in the sense that its output is not the same as whatever official compiler Bioware and Obsidian had. A lot of the time it is sufficient to work in the game, but I could easily see how something it did could trip up a Blender script expecting a specific pattern that the official models conform to.

 

As to your desired list, you aren't going to find much in the way of something like that. A lot of it just comes down to trial and error. Adjust, export, compile, test. Repeat until it works (or is proven to be irrevocably broken).

[xander2077 80]

I'd say the problem was almost certainly MDLOps, rather than anything specific the modder did. It doesn't compile models properly, in the sense that its output is not the same as whatever official compiler Bioware and Obsidian had. A lot of the time it is sufficient to work in the game, but I could easily see how something it did could trip up a Blender script expecting a specific pattern that the official models conform to.

 

As to your desired list, you aren't going to find much in the way of something like that. A lot of it just comes down to trial and error. Adjust, export, compile, test. Repeat until it works (or is proven to be irrevocably broken).

nothing is ever irrevocably broken if you 1: save your source file model and isolate it from the game, and 2: make a backup of game files so they are not dameged irrevocably.

 

i figured trial and error is one of the standing methods of modding, its just nice to know details like that, cause it saves a lot of guesswork. what is the point of paving the way if one is not really paving the way? i guess it would be nice to know what works before trying out a billion methods.

 

as far as mdlops being the culprit, it does what it does. it is up to the model to be the format expected or it wont work right. but that was not the issue, it was neverblender, which did not recognize the particular ascii-mdl as a valid file, but recognized the extracted vanilla models just fine. but really the script was not the issue either, it was the model and how the mdlops output ascii-model was different because of how that model was different to begin with. i guess neverblender has to be fine tuned and made to be more sophisticated in the future. so i will let the developer know so maybe they can add some more functionality to the script and force imports if need be. i told them about the issue and asked for an option to import geometry only in the correct orientation and coordinates, and also an option to force one material compatible with the aurora engine.

[DarthParametric 3,784]

nothing is ever irrevocably broken

Clearly you haven't spent enough time with MDLOps.

[xander2077 80]

well that may be true but i like taking precautions, like using a second game directory instead of the one i play, that i use for modding. that way i isolate anything i do to the game to that one folder instead of borking the installation i play. and there is something to be said for the old addage of save, save, save... besides i havent got there yet, so if it really is the all powerful mucker-upper, then i will find out soon enough. i do know that i got it to work fine before, which is how i modified the UVs for a player made helmet before and exported just fine. but again it was in a different directory than my actual play directory. a clone of the one i play but if anything happens to that it is simple as drag and drop and things are back to normal.

[DrMcCoy 40]

it is called xoreos (sounds greek to me)

Hey there, xoreos main dev/lead chiming in.

 

The name is not exactly Greek, no. There's an entry in our FAQ that answers the backstory for the name.

 

i suppose it is somewhat like openmw only for NWN

This is exactly what it's supposed to be, yes. And yes, the xoreos-tools are partially to help the development of xoreos and partially to provide something potentially useful for modders.

 

However, I'm not necessarily striving to replace KotORTool (or any other tool [1]), but add to it and increase the options people have. I'm not going for the hostility/rivalry route here.

 

I'm also approaching things from a more stricter copyleft (GPLv3) and free software perspective, because that's important to me personally. Other modding tools developers might not care as much, or prefer to go either closed or more permissive. I'm also a proponent of staying as wildly portable as possible.

 

As for the model formats, there's currently no xoreos tool to do anything with them (except extracting the binary MDL files from the archives). If you can read C++, the model loaders for xoreos are in the model_* files in src/graphics/aurora/. Not everything is supported yet, though.

 

And lastly, my standard recruiting call: I'm still looking for more contributors to xoreos (and xoreos-tools). There's a long TODO list on our wiki, but it is, of course, non-exhaustive. If you feel up to tackling any of these or have your own suggestions, please contact me and let me know.

[xander2077 80]

Hey there, xoreos man dev/lead chiming in.

 

The name is not exactly Greek, no. There's an entry in our FAQ that answers the backstory for the name.

 

This is exactly what it's supposed to be, yes. And yes, the xoreos-tools are partially to help the development of xoreos and partially to provide something potentially useful for modders.

 

However, I'm not necessarily striving to replace KotORTool (or any other tool [1]), but add to it and increase the options people have. I'm not going for the hostility/rivalry route here.

 

I'm also approaching things from a more stricter copyleft (GPLv3) and free software perspective, because that's important to me personally. Other modding tools developers might not care as much, or prefer to go either closed or more permissive. I'm also a proponent of staying as wildly portable as possible.

 

As for the model formats, there's currently no xoreos tool to do anything with them (except extracting the binary MDL files from the archives). If you can read C++, the model loaders for xoreos are in the model_* files in src/graphics/aurora/. Not everything is supported yet, though.

 

And lastly, my standard recruiting call: I'm still looking for more contributors to xoreos (and xoreos-tools). There's a long TODO list on our wiki, but it is, of course, non-exhaustive. If you feel up to tackling any of these or have your own suggestions, please contact me and let me know.

 

lol, ok so it is X-or (eo) cookies from a greek goddess??? hmmm... must be tasty stuff, does she wear an apron and lab coat while doing differential calculus?

 

well for me being able to extract models with xoreos tools instead of ktool natively in linux is not for the sake of rivalry, but ease of use. for someone like me in linux, who cant get windows tools to always work right, that is H.U.G.E!

 

i am by no means a coder or familiar with C# or C++, or xml, etc, but i do understand that they are important for making tools for games and games themselves. if i can help at all it will be to suggest functionality for the tools from a modders perspective, but i am sure there is a lot to do before the alpha testing of certain things will be done. im just happy these tools are being developed. if i were in windows then by all means i would use ktool and others that i grew to love years ago in windows, but in linux nothing was really viable until you guys started working on the open source versions. thanks a lot for that.

[LiliArch 115]

As far as I recall, MDLOps is actually released under GPL.

 

wow, im glad someone agrees with me about dotnet. it is atrociaous. now if i get perl running and the modlops installed, im pretty sure i can compile it so that there is a link on the desktop that will run commandline for me instead of typing it all the time. console commands are very powerful tools in linux but if i dont have to use them i would rather not,

Well, I'm pretty sure being powerful is what the commandline is for in the first place. Can't believe it would be there just for the fun of it (unless Linux was developed by people who prefer DOS over Windows, hmm). In any event, you don't need to compile anything. If Perl runs on Linux at least half the same way it does on Windows, all you need to do is to double-click (or whatever is the Linux equivalent for Windows double-click) the mdlops.pl and it should run (when you get it running correctly, first). But as long as you're troubleshooting, commandilne is your best friend. After all, if you get a crash, you can't fix it unless you know why it is crashing, right?

[xander2077 80]

As far as I recall, MDLOps is actually released under GPL.

 

Well, I'm pretty sure being powerful is what the commandline is for in the first place. Can't believe it would be there just for the fun of it (unless Linux was developed by people who prefer DOS over Windows, hmm). In any event, you don't need to compile anything. If Perl runs on Linux at least half the same way it does on Windows, all you need to do is to double-click (or whatever is the Linux equivalent for Windows double-click) the mdlops.pl and it should run (when you get it running correctly, first). But as long as you're troubleshooting, commandilne is your best friend. After all, if you get a crash, you can't fix it unless you know why it is crashing, right?

 

well i decided to just forget the idea. heres the thing. if you break into the perl script, it still calls for win32api depemdemcy, and so you have to run it in wine anyway... but it calls for things in windows in such a way that it will brick wall in linux, there is a clue in the script itself which suggests that nobody has ever used this script in linux

use TK::Tree;

and linux is case sensitive while windows is not so the guy that wrote the script doesn't care about that, hes windowcentric. so if i wanted it to run from the perl script in linux, it takes a lot to do... but it is basically a waste of time and overcomplicates it all...

 

now if i wanted to install activeperl anyway, and mdlops perl script, it can be done but it would be redundant since the win32 api dependency would mean im basically trying to clone what wine does only in a strange way. and there was a guy helping me try to get it working but for me it is a non starter. and anyway mdlops works in wine just as good as it does in windows. i just wanted a native linux version and even the perl script is not geared for linux, it is designed to make perl run in windows. and here is what the guy said he did but it still doesnt matter about mdlops... just active perl. but since i wont need it to install anything but mdlops (which already runs in wine) it is a moot point...

 

Just to put this to bed entirely, I've installed ActivePerl (Linux version) just to make sure. The GUI package manager (PPM) that comes with it (which you were originally aiming for) does not show any of the Win32 modules. If you want to check it for yourself, do this:

 

export PATH=$PATH:/home/stealth/ActivePerl-5.22/site/bin:/home/stealth/ActivePerl-5.22/bin
export MANPATH=$MANPATH:/home/stealth/ActivePerl-5.22/site/man:/home/stealth/ActivePerl-5.22/man
~/ActivePerl-5.22/bin/ppm &

You'll get the windowed PPM app, enter Win32 in the filter field and everything will disappear. If you were running ActivePerl in Windows you would see all the Win32 modules listed.

 

Side Note: I simply changed TK::Tree to Tk::Tree in the script to continue with the installation. I just mentioned it to show that the script was written for Windows in the first place.

 

[LiliArch 115]

well i decided to just forget the idea. heres the thing. if you break into the perl script, it still calls for win32api depemdemcy, and so you have to run it in wine anyway... but it calls for things in windows in such a way that it will brick wall in linux, there is a clue in the script itself which suggests that nobody has ever used this script in linux

Nah, you just need to change the win32api to a library that runs in Unix. (I thought I mentioned that already?) It's pretty trivial, really. I can do it for you, if you tell me which version of MDLOps you're using. Does Tk work on Linux?

 

Edit.

If you or the guy who helped you don't believe it is trivial, consider this: The only Windows-dependant things are file-opening dialog (which consists of five lines of code) and a library that is relevant only on Windows (and thus the dependancy can simply be removed from the code). It is not complicated at all. It may be developed on Windows, and there may be a typo about TK instead of Tk (given that it appears only once, I'm quite sure it is a typo, and was unnoticed only because it was never tested on Unix). It doesn't mean it would need more than a minimum effort to be useable on Linux. I'd give instructions here right away (as far as I can see, all you need is two edits) but I'm a bit busy right now.

[xander2077 80]

well if you can remove the dependencies and it will work in linux then by all means. im in no hurry, im sure it still has to use perl, but with it already native (perl) that should be the only dependency i can see.

 

im sure the tk reference was not a typo, since it can be run without it in linux, but he specifically made it dependent because he was focusing on windows use. he just didnt see it as necessary to edit the script to allow for linux use. i dont think it was ever really intended to be a linux script. if it was he would have realized the case sensitivity of linux and made a folder with the isolated script as an alternate without the same dependencies as windows.

 

if you do make a satnd alone perl script i would suggest uploading it into kotor modding tools since it would be of great use to anyone modding in linux.

 

as far as the other tools go, i think xoreos is more than adequate for my needs there (extracting bifs, rims erfs and converting files like tga and 2da) it just has one shortcoming. no Ui front end "yet" but im sure that will come along in time, it just takes some coding and the guys at xoreos have not gotten that far yet. if i knew what i was doing i would whip up a no frills front end for it, but im not really experienced in that sort of thing.

[ndix UR 218]

I am doing the same kind of workflow as you, but on a Mac rather than a Linux machine (both are unix though, and I use a lot of linux). I recently switched from using the MDLOps 0.5 exe that ships w/ Kotor tool (in a wine command shell) to using the 0.7a2 perl code. I am also using Blender w/ newest neverblender for modeling.

 

Because I wanted to use mdlops on the command line the first thing I did was pull out the Tcl/Tk stuff, and of course the Win32 dependency. I haven't posted it yet because I want to actually refactor it properly so that the Tcl/Tk and Win32 stuff is in a separate file (software engineer hat), but I've also gotten bogged down trying to fix some of the weird errors mdlops has and adding features to make the models work better with Blender.

 

To make your own quicky fixed-for-unix version, just open mdlops.pl and delete lines 190-509 (usegui = yes to MainLoop), 540-543 (sub Tk::Error), and 1141-1152 (sub browse_for_file). Also remove the 'use' lines at the top for everything Tk and Win32 related.

 

Make sure you copy or symlink MDLOps.pm into your perl lib directory (get a list using: perl -e "print qq(@INC)" (best practice would be to put it somewhere under 'vendor_perl' from that list) )

[xander2077 80]

I am doing the same kind of workflow as you, but on a Mac rather than a Linux machine (both are unix though, and I use a lot of linux). I recently switched from using the MDLOps 0.5 exe that ships w/ Kotor tool (in a wine command shell) to using the 0.7a2 perl code. I am also using Blender w/ newest neverblender for modeling.

 

Because I wanted to use mdlops on the command line the first thing I did was pull out the Tcl/Tk stuff, and of course the Win32 dependency. I haven't posted it yet because I want to actually refactor it properly so that the Tcl/Tk and Win32 stuff is in a separate file (software engineer hat), but I've also gotten bogged down trying to fix some of the weird errors mdlops has and adding features to make the models work better with Blender.

 

To make your own quicky fixed-for-unix version, just open mdlops.pl and delete lines 190-509 (usegui = yes to MainLoop), 540-543 (sub Tk::Error), and 1141-1152 (sub browse_for_file). Also remove the 'use' lines at the top for everything Tk and Win32 related.

 

Make sure you copy or symlink MDLOps.pm into your perl lib directory (get a list using: perl -e "print qq(@INC)" (best practice would be to put it somewhere under 'vendor_perl' from that list) )

 

Wow, i missed this reply. Thanks! I am by no means a coder, and i have a hard time with the terminal sometimes since im more familiar with command prompt, but i would be delighted to remove the dependencies that dont need to be there! now if i could only do that with Ktool!

 

anyway, this is something i have to try carefully when i have the time and urge to do it. And as a side note, the lightsabers have to be imported and exported (AFAIK) with version 5 of mdlops, so it would be kind of cool to see all of the good features from the last 3 versions combined into one, and the bad stuff eliminated. Maybe make it so the import is a bit more complicated and you can choose to invoke the mdlops version you want as the conversion script? It makes for a more complicated GUI too, so that is why i am wondering if it were even possible.

[LiliArch 115]

Because I wanted to use mdlops on the command line the first thing I did was pull out the Tcl/Tk stuff, and of course the Win32 dependency.

...you do realize that MDLOps has in-built commandline usage, right? There's no need to strip GUI from it to do that. Of course, you may need to strip Tk from it to be able to run it on Mac, but that's another story completely (and in that case, you could rewrite the GUI with another library).

 

Anyway, there's my instructions. Sorry about me not posting them earlier, but deadlines don't wait, and if I need to choose between payed work and a hobby, well...

Assuming Linux can use Tk, this should do the trick (I can't test, so I can't say for sure, but there's all Windows dependencies I can see removed):

 

FIND

use TK::Tree;

REPLACE WITH

use Tk::Tree;

FIND

use Win32::FileOp; # for file browser added by tk102, thanks tk102!
use Win32::Autoglob; # stupid windows shells don't do globbing!

REPLACE WITH

#use Win32::FileOp; # for file browser added by tk102, thanks tk102!
#use Win32::Autoglob; # stupid windows shells don't do globbing!

 

FIND

    my %parms=(
                    title => "Open Model File", handle=>0,
                   filters => { 'Model Files' => '*.mdl', 'All Files' => '*.*'},
                   options =>OFN_FILEMUSTEXIST |  OFN_PATHMUSTEXIST);
    my $dialog_name = OpenDialog \%parms;
    unless (-e $dialog_name) { return; }

REPLACE WITH

    #my %parms=(
    #                title => "Open Model File", handle=>0,
    #               filters => { 'Model Files' => '*.mdl', 'All Files' => '*.*'},
    #               options =>OFN_FILEMUSTEXIST |  OFN_PATHMUSTEXIST);
    #my $dialog_name = OpenDialog \%parms;
    #unless (-e $dialog_name) { return; }
    my $dialog_name = $object{'main'}->getOpenFile(
        -title => "Open Model File",
        -filetypes => [
            ['Model Files','.mdl'],
            ['All Files','.*'],
        ],
    );

That's all! Save and close and run the file. You can also remove the lines where we added the # in front of them, but I hate removing lines when I tweak code like that, so I just commented them out...

 

im sure the tk reference was not a typo, since it can be run without it in linux, but he specifically made it dependent because he was focusing on windows use. he just didnt see it as necessary to edit the script to allow for linux use. i dont think it was ever really intended to be a linux script. if it was he would have realized the case sensitivity of linux and made a folder with the isolated script as an alternate without the same dependencies as windows.

And I believe it is a typo, because "TK" appears only once, while "Tk" appears four times, and all of them refer to the same thing. Or, it could be written by another person.

 

A word of warning - be careful when you install things. Don't install Tk::Tree separately, unless you're 200% sure it's not installed with main Tk. I did that and it screwed the whole Tk library, so I had to install the whole thing again.

[DrMcCoy 40]

Assuming Linux can use Tk

...That's kinda rich, if you consider Tk's history.

[Fair Strides 509]

...That's kinda rich, if you consider Tk's history.

But it's not so rich if the person talking (LiliArch) is not familiar with Linux and doesn't use it...

[LiliArch 115]

Now, now. I've used Red Hat... somewhat twelve years ago. I wouldn't assume to know what Win 10 supports based on knowledge of Win 2000, you know? Nor would I assume Win 10 would be backwards compatible with everything that's done for previous versions of the OS. It's definitely possible OS writers change their minds about what the OS does and does not support, as well as it's possible different builds support different things (they wouldn't be different builds if they wouldn't have differences, now would they?) so I see no reason why there couldn't be a Linux version that doesn't support Tk's windowing system.

 

That being said, I won't assume anything for sure unless I can test it.