Jump to content


Photo

MDLOps

mdlops tool md alpha

  • Please log in to reply
82 replies to this topic

#41 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 26 May 2016 - 10:54 AM

I just spent waaaaaaay too long debugging MDLOps and I have a fix for you!

 

Setup: working on character models with blender using neverblender import/export

 

Symptom: recompiled characters don't have shadows in game. if they are playable NPCs (handmaiden say) and you enter combat with them active, the camera freaks out, doing a combination of moving inside the model's head and orbiting them really closely as if some kind of collision were happening.

 

Cause: neverblender exports models with classifications in ALL CAPS. It took me *so* long to figure this out. I tried just about everything else (returning weights, tverts, faces, orientations, all things neverblender changes on a simple import/export).

 

Solution: in MDLOps.pm change line around 1795:

    } elsif (/\s*classification\s+(\S*)/i) { # look for the model type
      $model{'classification'} = $1;

to

    } elsif (/\s*classification\s+(\S*)/i) { # look for the model type
      $model{'classification'} = ucfirst lc $1;

This is similar to how keys are used in the nodelookup hash.

 

Anyway, I hope this will save some blender character modders some grief somewhere down the line. Thanks for maintaining this essential software!

 

This is pretty cool that you tracked it down. I may have to pick your brain on blender import/export and some of the things to make sure are right before export. One of my biggest obstacles is skinned models and weights. Since you use neverblender, like I do, I think it is worth a discussion. Incoming PM.



#42 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 33 posts

Posted 27 May 2016 - 09:22 PM

@ndix UR and xander2077

 

 

What version of blender are you guys using? I only use the old 2.49B, mainly for other games I have, but I could never get the Neverblender export made back in 2003 to work with the 2.49B version. And when was the NeverBlender import created? I thought the 2003 Neverblender export was all that was made long ago and that was it. 

 

I've been using 3Ds Max 7 for a while now as a 3d editor, but I would much prefer Blender to edit the character models and put them back in the game, if that's possible?



#43 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 27 May 2016 - 11:50 PM

@ndix UR and xander2077

 

 

What version of blender are you guys using? I only use the old 2.49B, mainly for other games I have, but I could never get the Neverblender export made back in 2003 to work with the 2.49B version. And when was the NeverBlender import created? I thought the 2003 Neverblender export was all that was made long ago and that was it. 

 

I've been using 3Ds Max 7 for a while now as a 3d editor, but I would much prefer Blender to edit the character models and put them back in the game, if that's possible?

 

 

I use blender 2.8 native to linux and i also have blender 2.49b portable that i use in wine. 2.8 is the one i have neverblender in, and it is a simple zip file install from within blender, so it is really easy to install.

 

For blender 2.49b, i cant figure out either how to get even the old version of neverblender working... so instead, i use a 2.49b blend file that opens the script window properly so i can run the import script for Kotor mdls, and this is the one i use only for problem mdl files that i have to force into blender. Most of them import fine into 2.8 with no issues. Once i open problem files in blender 2.49b, i can then save them and open them again in 2.8

 

If you want both you can also look for the portable app version of 2.49b and then do a full install of the latest version, that way you have both.

 

You can move files between new and old blender, but beware, if you save them in old blender they will work in both, but if you save them in new blender they will screw up in old blender... UNLESS: you save the file in new blender as a "legacy blend" file, however this destroys any animations and sometimes skin weights and bones. If you try to open a 2.8 file in 2.49b, it will import only the edges with no faces, and the rest of the things that were with the model will be gone, and sometimes whole sections of model will be missing. Also convert to tris before saving as a legacy because any quad faces will be deleted on opening in 2.49b.

 

Also the 2.49b import method i use, for some reason assignes a bijillion materials and other weird things in the file, so it has to be cleaned up before it will work as an aurora model.



#44 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 33 posts

Posted 28 May 2016 - 04:36 PM

Ok, I think see. I take it somebody in the blender community made or updated NeverBlender import\export files for Blender 2.8? Which comes with the blender 2.8 package? And you can import the Kotor mdl model characters into Blender 2.8, edit them however you wish (but not all of them), then export them out, putting them back into the game?

 

But with the few models that won't work when you try to edit them in Blender 2.8 and put them back in the game, with the usual way of importing and exporting through Blender 2.8, you still import those models into Blender 2.8, but instead export them out of Blender 2.8 as a old blend file, so you can import them into the old blender 2.49 and then edit them in that old version of Blender, while also removing the ungodly amount of assigned materials to that model. Then you export it back out of blender 2.49 as a old blend file again and back into Blender 2.8 to export the model as a mdl file with the latest version of the NeverBlender for 2.8.

 

Is that right?



#45 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 28 May 2016 - 05:02 PM

no lol, i only use old blender (2.49b) to import some mdl files that wont import with the new (2.8) blender plugin.

 

There are two version on the neverwintervault site. one is for 2.6 (but is supposed to work in 2.49b even though it does not) and the newest one which i believe will work in 2.7 and up.

 

I would probably not want to export anything from blender 2.49b. The new blender plugin seems to handle export better in my opinion , unless you have better results than i do, but YMMV. It probably also depends on which operating system you have, since i can only use one import script and the rest will not work for me in linux. If you use a different script then your OS probably has a lot to do with the success rate of a plugin.

 

What happens when importing it to old blender (with the plugin i use) is a lot of extra materials get added to the model that dont belong. so i only use it in extreme cases and immediately save it as a blend and open that in blender 2.8. then i do my work there and export only from blender 2.8. the reason i even tried going the other way was because of the vertex paint feature in 2.49b that i really like which is the fake ambient occlusion. but when i open it again in 2.8 that is wiped so it was pointless to save it as a legacy blend file.

 

I just made mention of all that nonsense because i was trying out different things and so i know what will happen if you pass the model between the two versions of blender. best to import in 2.8 and export, and only import in 2.49b if you absolutely need to. Now there are plugins that 2.49b has that 2.8 does not (yet) but i use that more for morrowind and my workflow for that is the exact opposite. But that is a moot point for Kotor.



#46 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 33 posts

Posted 28 May 2016 - 06:33 PM

Ah okay, I see what you're saying now. Well I have XP and that's about all I can use as a operating system for right now - been trying to save up and get a better computer with Win 7 or build one that I can put Win 7 on.

 

But meanwhile, I'm going to browse over to the NeverWinterVault website and look at those NeverBlender python scripts, probably download both versions you mentioned and then try messing with the Kotor models with the latest NeverBlender import\export python script version in Blender 2.8. 

 

I suspect the reason why the 2.6 NeverBlender import\export script would not work in the old blender 2.49 is because the programming writing format for python had changed since Python 2.6, because Python 2.6 is what the old 2.49 Blender runs on; and I think that change may have occurred when they introduced Python 3.0. several years ago. Which I think was about the same time Blender 2.5 or 2.6 started coming out. So the Blender community adapted to Python 3.0. for the latest versions of Blender.

 

Anyway, I'll take a look at the NeverBlender 2.6 in Python's Idle editor and see how the author wrote the import\export python scripts and see if he\she wrote it with python 3.0.

 

Thanks for taking the time to respond and explain all that, Xander2077. I appreciate that. If I can at least get some Kotor models in Blender 2.8 and edit them to where they will work in the Kotor games, that will be very helpful to me somewhat, because I'm a Blender fan and was a Blender user long before I ever fiddled with Gmax and 3Ds Max. Blender has always been my favorite 3D editor.  ;)

 



#47 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 28 May 2016 - 06:45 PM

Ah okay, I see what you're saying now. Well I have XP and that's about all I can use as a operating system for right now - been trying to save up and get a better computer with Win 7 or build one that I can put Win 7 on.

 

But meanwhile, I'm going to browse over to the NeverWinterVault website and look at those NeverBlender python scripts, probably download both versions you mentioned and then try messing with the Kotor models with the latest NeverBlender import\export python script version in Blender 2.8. 

 

I suspect the reason why the 2.6 NeverBlender import\export script would not work in the old blender 2.49 is because the programming writing format for python had changed since Python 2.6, because Python 2.6 is what the old 2.49 Blender runs on; and I think that change may have occurred when they introduced Python 3.0. several years ago. Which I think was about the same time Blender 2.5 or 2.6 started coming out. So the Blender community adapted to Python 3.0. for the latest versions of Blender.

 

Anyway, I'll take a look at the NeverBlender 2.6 in Python's Idle editor and see how the author wrote the import\export python scripts and see if he\she wrote it with python 3.0.

 

Thanks for taking the time to respond and explain all that, Xander2077. I appreciate that. If I can at least get some Kotor models in Blender 2.8 and edit them to where they will work in the Kotor games, that will be very helpful to me somewhat, because I'm a Blender fan and was a Blender user long before I ever fiddled with Gmax and 3Ds Max. Blender has always been my favorite 3D editor.  ;)

 

Yes the decision to focus on python 3.0 dependency is something i disagree with entirely. And this effected Nifscripts in a bad way, but Neverblender actually works right in spite of that misdirection. In linux, the distro has the default python set to 2.6 or 2.7, but it has provisions for 3.0 even though it is still largely in the beta stages for supporting older applications.

 

The problem comes in when older apps that need a lower version of python call for that version, and even if it is present (because linux keeps them all in separate directories and does not overwrite older versions) for some reason applications cannot "see" that version of python and fail.

 

While it is ok for blender to support 3.0, some of the scripts still depend on 2.6, and the way it is handled is so different there is no way to patch between the two reliably. So when some applications decided to move exclusively to 3.0, they jumped the gun before the bugs were worked out, and the python 3.0 dev team had to backtrack and try to figure out backward compatibility that they overlooked terribly, since some of the scripts that we all use were still dependent on lower versions. and even then the way they try to convert the python scripts to work in older versions is terrible. So there is a huge mismatch in versions and how fast people update their applications or scripts to the new language, nobody seems to be in line yet completely. they are all over the place. and then to top it off, some of the scripts have dependencies that have been omitted from the linux base, so they wont work any more, so it seems like to me that the application developers would try and bundle everything with the dependencies and older version of python but that is hit or miss...

 

Plus they did not foresee the issues that 3.0 would cause, and i think they are pretty much fixed now, but becuase they changed so much in python and because of the way linux handles python, it can be a huge hurdle to get everything working in concert.

 

i have suggested to them that they make some kind fo a library that can tell what version of python an app or script needs and direct it to that version without just brick walling, but i am not sure if they took it into consideration. In windows there may not be an issue with python, since you can always just install the necessary stuff in the same directory as the exe and get it working. Linux is not always so easy. sometimes they discard things before they should be becuase they assume everyone is up to speed, but that is never he case when it is open source you are talking about.



#48 LiliArch

LiliArch

    Jedi Knight

  • Members
  • PipPipPipPip
  • 374 posts

Posted 29 May 2016 - 09:13 AM

Ah okay, I see what you're saying now. Well I have XP and that's about all I can use as a operating system for right now - been trying to save up and get a better computer with Win 7 or build one that I can put Win 7 on.

Well I don't know about Blender 2.8, but 2.7 runs fine on XP (after installing that C++ runtime or whatever it was, if it's not installed already). I'd suppose the new neverblender should work with it.


iriaz_sig.jpgBFix0.gif
Lady Arch, the Carrier of Northern Nights, the Harbinger of Iriaz and the Dark Lord of Orth.

#49 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 33 posts

Posted 29 May 2016 - 06:11 PM

Well I don't know about Blender 2.8, but 2.7 runs fine on XP (after installing that C++ runtime or whatever it was, if it's not installed already). I'd suppose the new neverblender should work with it.

 

 

Yeah I found both 32 bit and 64 bit versions of the Blender 2.69 and downloaded that first. Learning the in's and out's of 2.69 right now, as I type this reply. Hmmm...probably should have downloaded Blender 2.7 instead. 

 

LiliArch, have you tried both versions? - and if you have - In your opinion, is there much difference between the Blender 2.69 and 2.7 version? 

 

Thanks for giving me notice about 2.7 running fine on XP, BTW. 



#50 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 29 May 2016 - 08:19 PM

To me there is a difference. It seems like every version of blender is different, and they only stayed the same for a very short time. (Maybe the period was somewhere between the 2.4 to right before 2.6.) The basic controls are the same, but they still need to refine the controls a bit. so that is why certain key combos don’t do the same things any more, or they stopped using certain functions that were good and adoped some that were similar but not as good, but overall the changes have been decent, better than it used to be. I just wish they would make it so you could drag the controls on the mesh and it was more interactive like max, but they have already been told they need to do that way back in 2.6 and it is now 2.8.

#51 LiliArch

LiliArch

    Jedi Knight

  • Members
  • PipPipPipPip
  • 374 posts

Posted 30 May 2016 - 03:05 PM

LiliArch, have you tried both versions? - and if you have - In your opinion, is there much difference between the Blender 2.69 and 2.7 version?

Well, I've run both versions, but I don't exactly know how to use them, so. By the time I found out I need to use a wheel mouse instead of touchpad to be able to do anything reasonable, I had already sort of hurt my mouse-arm and as such, I was unable to try to learn how to use the program. They have a different picture in the splash screen, that's all I know. I'm still only trying to learn how to do 3D.
 

It seems like every version of blender is different

That's usually the point in releasing a new version, isn't it? If it would be exactly the same, they wouldn't raise the version number...
...sorry, I feel snarky. Bad day.


iriaz_sig.jpgBFix0.gif
Lady Arch, the Carrier of Northern Nights, the Harbinger of Iriaz and the Dark Lord of Orth.

#52 xander2077

xander2077

    Jedi Knight

  • Members
  • PipPipPipPip
  • 288 posts
  • LocationCyberspace

Posted 30 May 2016 - 03:20 PM

That's usually the point in releasing a new version, isn't it? If it would be exactly the same, they wouldn't raise the version number...
...sorry, I feel snarky. Bad day.

 

that aint snarky, i get your point, but what i mean is that some things that were nice features or really useful and worked, got canned for no reason while they still ignore user suggested improvements and call it an upgrade to the program. and they could not make up their minds what key combinations to keep for a while, confuses the user.

 

once it levelled off the program became eaier to use, and it finally started looking like an improvement with each version, but then some stuff that could have been ported to the new version were inexplicably removed for no good reason, and blender still has its bugs and weirdness in a few places. like the texture paint mode. why is it that i need something extra to download for it to work but there is nothing to download to make it work? should they not have included some default brushes and things in that part of the program just like in sculpt mode? why did they change the faked ambient occlusion to only work with a texture now? it used to work fine without a texture before since it was based on the native blender lighting rendering the shadows on the model. now i cant use it unless i have already baked an ambient occlusion layer, so it kind of seems counterintuitive. so some of the version 'upgrades' come with a bunch of unsecessary downgrades as well. i guess they seem to think that they have to punish users for making blender so much better each version by removing really nice features, or making some things impossible to use when they worked fine before. or making things more convoluted in some cases. sure there are some nice new features but some of the nice old ones got taken away when they could have just as easily been ported to the new python. it is easier to port old to new than new to old.



#53 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 33 posts

Posted 30 May 2016 - 05:52 PM

We'll thanks for both your inputs on the subject, guys. I'm going to try my hand with the 2.69 Blender and the import\export scripts. See if I can produce anything worthwhile. Lol. Then again, probably not, knowing my luck with 3D editors. 

 

But thanks again!



#54 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 33 posts

Posted 09 June 2016 - 01:56 AM

I just spent waaaaaaay too long debugging MDLOps and I have a fix for you!

 

Setup: working on character models with blender using neverblender import/export

 

Symptom: recompiled characters don't have shadows in game. if they are playable NPCs (handmaiden say) and you enter combat with them active, the camera freaks out, doing a combination of moving inside the model's head and orbiting them really closely as if some kind of collision were happening.

 

Cause: neverblender exports models with classifications in ALL CAPS. It took me *so* long to figure this out. I tried just about everything else (returning weights, tverts, faces, orientations, all things neverblender changes on a simple import/export).

 

Solution: in MDLOps.pm change line around 1795:



    } elsif (/\s*classification\s+(\S*)/i) { # look for the model type
      $model{'classification'} = $1;

to



    } elsif (/\s*classification\s+(\S*)/i) { # look for the model type
      $model{'classification'} = ucfirst lc $1;

This is similar to how keys are used in the nodelookup hash.

 

Anyway, I hope this will save some blender character modders some grief somewhere down the line. Thanks for maintaining this essential software!

 

Apparently this new added MDLOps.pm line of code you changed doesn't seem to work for some models exported with Neverblender. I changed the line of code, word for word on line 1795, in MDLOps.pm with Notepad++ and ran the p_juhanibb.mdl through MDLops 07A2, then imported and exported it with NeverBlender, then back through MDLops 07A2 again. Put the new model in the K1 override folder and started up the game. Unfortunately I still get the same problem of no body shadow and the camera flipping out during combat mode, like you did.

 

I may have messed up somewhere, but I tested this several times, but I'm also wondering if this line of code change was for MDLops 07A2 or a older version?



#55 ndix UR

ndix UR

    Jedi Apprentice

  • Members
  • PipPip
  • 53 posts
  • Locationca, usa

Posted 09 June 2016 - 02:51 AM

This change is definitely against MDLOps 07A2 ... Sorry to hear that it hasn't resolved your issue. I haven't seen this issue again since I made the change.

 

Some debug questions:

 

After you changed MDLOps.pm, are you running MDLOps by running the command "perl mdlops.pl" (or by double clicking mdlops.pl I guess) or by running mdlops.exe?  If you are running mdlops.exe, it is extremely unlikely that your change to MDLOps.pm had any effect.

 

My understanding, and people will correct me if this is inaccurate, is that mdlops.exe is a compiled executable that includes perl, Tk, MDLOps.pm, etc. -- all the dependencies. It is completely standalone from the mdlops.pl and MDLOps.pm files.  This is, for example, why you can use mdlops.exe without installing perl (I think! I don't actually have a windows box to test with!).

 

That is my first/best guess as to the problem.  If you're definitely already using mdlops.pl and the modified MDLOps.pm... can you post the 'classification' line from the ascii version of your p_juhanibb.mdl file?

 

Also: speaking to the earlier version questions you had ... I use blender 2.77 and neverblender 1.23a which was released earlier this year i believe. i found it on nwnvault.



#56 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 33 posts

Posted 09 June 2016 - 04:10 AM

This change is definitely against MDLOps 07A2 ... Sorry to hear that it hasn't resolved your issue. I haven't seen this issue again since I made the change.

 

Some debug questions:

 

After you changed MDLOps.pm, are you running MDLOps by running the command "perl mdlops.pl" (or by double clicking mdlops.pl I guess) or by running mdlops.exe?  If you are running mdlops.exe, it is extremely unlikely that your change to MDLOps.pm had any effect.

 

My understanding, and people will correct me if this is inaccurate, is that mdlops.exe is a compiled executable that includes perl, Tk, MDLOps.pm, etc. -- all the dependencies. It is completely standalone from the mdlops.pl and MDLOps.pm files.  This is, for example, why you can use mdlops.exe without installing perl (I think! I don't actually have a windows box to test with!).

 

That is my first/best guess as to the problem.  If you're definitely already using mdlops.pl and the modified MDLOps.pm... can you post the 'classification' line from the ascii version of your p_juhanibb.mdl file?

 

Also: speaking to the earlier version questions you had ... I use blender 2.77 and neverblender 1.23a which was released earlier this year i believe. i found it on nwnvault.

 

Okay, that was exactly what I was doing - clicking or using the mdlops.exe. So that's probably why it wasn't working for me. And I never thought about the Blender and Neverblender version I'm currently using, but yeah, I'm using an earlier version of Blender (2.69) and Neverblender (1.11). So that might also be part of the problem as well, but I've had good results of getting most of my custom edited MDL models into either Kotor games, except for the no body shadow and weird camera effects during combat of course, so I'm not sure if that is part of the problem until I try running the command "perl mdlops.pl" first.

 

So I take it I need to download Perl first and set all that up, in order to use the "mdlops.pl" file with a command? Or can I just simply run that file with a .bat file or something? I did try directly clicking on the file in my windows explorer, under the mdlops folder directory I put all those files in, but all it did was open up the file and show me all the code that was written in plain English. Also, you mentioned that the mdlops.exe is a standalone file? I first thought that as well and tried that, but in my case, if you don't have those .pl and .pm files inside a folder along with the mdlops.exe file, it will just crash when you click on it without having those files along with it in the same folder. So I thought the mdlops.exe was dependent on those other files being there along with it, in order for the whole thing to work? 



#57 ndix UR

ndix UR

    Jedi Apprentice

  • Members
  • PipPip
  • 53 posts
  • Locationca, usa

Posted 09 June 2016 - 06:45 AM

That is interesting that the mdlops.pl and MDLOps.pm files seem to be necessary in the same directory as mdlops.exe. I am not sure how to explain that  :question: ... I have not really experimented with that exe file. The only mdlops.exe I have used is the mdlops.exe that ships in the KotorTool package. It's an older version, maybe a 0.6 or 0.5. It definitely runs without any perl code available.

 

I just re-read all the docs that come w/ MDLOps and yeah, the document you are looking for is 'installing perl.txt'. It tells you how to install a windows-compatible version of perl (in this case, ActiveState's ActivePerl, which I used to use a long time ago also ...), and the dependencies that mdlops will need to run. Basically it covers what you need to do to get to the point where 'double-clicking mdlops.pl' will be a thing that actually works (runs the program, not just opens the code in a text editor).

 

I know that the mdlops.pl code uses Tk (also known as Tcl/Tk) for its interface, but this is not covered by the perl install documentation. There is a thing called ActiveTcl, also by ActiveState, which you might also need to install to get it working. It's been even longer since I have used Tcl/Tk and ActiveTcl, but I will provide any assistance I can...

 

As far as the blender and neverblender version stuff goes ... I can't really speak to that as I am basically a brand new blender user who's never used any other version.

 

OH. I just thought of something you might want to do before you go down this road of installing perl and whatnot. It is actually really easy to determine whether the fix will solve your problem or not. Here's what you can do to test a single model:  open in a text editor your ascii model file that you are about to compile; find the line that says "classification CHARACTER" (usually like 5 lines in or so) and change it to "classification Character". You can then compile it using mdlops.exe and it should be fixed when you try it in game. If you still have the shadow/camera issue, then there's no point in installing perl and all that other stuff anyway.



#58 Purifier

Purifier

    Jedi Apprentice

  • Members
  • PipPip
  • 33 posts

Posted 09 June 2016 - 05:38 PM

Thanks for mentioning that last part, Ndix UR. I opened up the exported ASCII p_juhanibb.mdl in Notepad++ and changed "classification CHARACTER" to "classification Character" on the fifth or sixth line. Sure enough, that did the trick. The model had it's body shadow this time in the game and no more weird camera effects during combat interactions. I also did the same with my custom remade player models, pfbas through pfbal and tested them in the game, sure enough again, the body shadow show up for those as well. But there is a funny thing about those particular models, they never did display any weird camera effects during combat interactions before all this; just the missing body shadow. It may have something to do with how those particular models are written before running them through MDLops and how MDLops and NeverBlender processes them afterwards. Strange how just a simple correction of a word's letters to lower case makes that much difference between two different .mdl model types and one type of model doesn't even have the weird camera effects problem during combat interactions, yet that simple correction will fix the same one problem with both differently written .mdl model types and also fix the camera problem with the one differently written .mdl model type. Very interesting.

 

And yeah, I had already went ahead and downloaded both the ActivePerl-5.22.1.2201-MSWin32 and ActiveTcl8.6.4.1.299124-win32 last night, before I saw your re-edited post again. But I have not installed them yet, but will eventually, not only for the reasons concerning MDLops, but just to see what programming in Perl is like anyway. I've been trying my hand at programming as a novice for years with C++ and Python, so I figured Why not Perl too?. BTW, you wouldn't happen to know any good tutorials on starting out with Perl for a novice like me, would you? There are probably a bunch of tutorials on YouTube, but I just thought I might ask anyway.

 

I appreciate your replies to my posts on this issue, Ndix UR. You were very helpful. Thanks again for helping me find a way to get around the problem.  ;)



#59 ndix UR

ndix UR

    Jedi Apprentice

  • Members
  • PipPip
  • 53 posts
  • Locationca, usa

Posted 10 June 2016 - 01:27 AM

Yeah, I totally noticed that about PC models also, my pfbam never had any combat camera issue, just the missing shadow. I think there's probably something in the engine making the PC models be handled slightly differently in that regard (but not completely differently, because they still lose their shadows ... weird).

 

perl is an interesting language. it is kind of difficult until you understand its data types really well. on the plus side, it only has three data types (unless you consider refs (which are scalars) a fourth type, which i kind of do). a lot of things that are really painful in other languages are a total breeze to write in perl. the issue is that they are not usually very easy to read after that  :pc: . but yeah, i generally keep people nowadays from having to learn perl, pushing them more towards using javascript in node.js instead, which is why i'm not too aware of good learning resources. still though, a lot of systems administrators still use perl for scripting systems and build tasks.  i am loving how much perl source code exists for kotor tools.  it is really up my alley.  now if only 3d geometry stuff wasn't always so mathy i'd be set!

 

It is definitely interesting how a little thing like the difference between CHARACTER and Character can make such a difference. If you feel like subjecting yourself to a bit of excruciating detail on why this is, read on! I figure if you think you might be interested in perl ... hey why not ...

 

The classification in the ascii model only controls 1 byte in the compiled model. MDLOpsM.pm contains a map connecting names with their byte values, it is a hash, %classification around line 196. The names, or keys, in that hash are all ucfirst (upper case first letter). The important values there are 'Character => 0x04' and 'Other => 0x00'. So, the classification is read from the ascii model (that's actually the part I fixed), and then it gets used while writing out the binary file. In this stage, it is used directly as a key/name into the %classifcation hash. perl does not find $classification{CHARACTER}, so it returns 'undef' aka undefined. My guess though, is that, because that undef value is being used in a 'pack' call (the pack call is basically letting you be very specific about how perl interprets different values) that is claiming it should expect an unsigned char (byte), it interprets undef as being 0 (which was Other, rather than Character, which was 4). So basically the bug just makes the game think your model is classification Other instead of classification Character. Honestly, I'm surprised such an issue wouldn't cause more problems in-game.



#60 DarthParametric

DarthParametric

    Dark Lord of the Sith

  • Members
  • PipPipPipPipPip
  • 990 posts
  • LocationOz

Posted 10 June 2016 - 04:12 AM

Interesting. That camera issue sounds pretty much exactly like the problem I encountered (one of several anyway) with a custom astromech model. When combat was initiated, the camera would zoom into the middle of the mesh. Curiously, that model was compiled with KAurora, and was set as a character model (plus on Windows, so presumably no case issues).





Also tagged with one or more of these keywords: mdlops, tool, md, alpha

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users