Hacking TNM?

[Chris Rosenkreutz]

I really don't know which of the 3 forums to post this.

So, as with any game, after playing TNM for a while, a few little things started to annoy me that I ought to able to do something about. Things like being on fire without air or that cats don't eat rats like they do in shifter. So naturally I started to wonder about modding TNM. So I did the following:

1. Worked out that I had to use the INI= command line option for unrealed. Then I could look at TNM maps and more importantly get at all the unrealscript.

You can pass INI= to ucc make too, but it doesn't work yet as TNM helpfully mixes code and assets in the same .u packages.

2. Used Hexy's deus ex extractor to get all the assets out of the .u files. I downloaded this useful utility from a Deus ex forum in Cyrillic in a language I don't understand. Fortunately the GUI and documentaion is in English. I once had to use use a command line tool that gave me errors in Chinese to unpack a file from another game so I shouldn't complain. Unlike vanilla Deus Ex, the extractor can't handle TNM's conversations but Jonas was good enough to upload those somewhere in these forums.

So I had all of TNM's assets to play with. I just needed to work out how to use them to rebuild the TNM packages.

3. wrote a quick python script to parse the .uc files for #exec import statements and use them to copy and rename all the asset files into places where ucc could fine them. Easy enough.

4. I had to change the order of the EditPackages in TNM.ini so that any dependencies are earlier. This puzzles me. How does anyone else build them? Do they need to be in a different order for the editor to work well or something? If not, why are they in the wrong order?

5. now ucc make works and I can play with my own version of TNM.

So I loaded it up with a new TNM.u and it worked. Wait, with fists selected I couldn't see my hands. Was I invisible? Apparently not, it was just fists. And I they just flashed at the bottom of the screen when I punched. I was just aiming below the belt. Fortunately, there was another position commented out in the WeaponFists.uc file and that looked fine.

Everything else works: it's just some weapons that are in interesting positions when I recompile TNMItems.u. It's a little disconcerting to fire a pistol that's being pointed at you by your disembodied hands. Does the mesh import script actually modify the model files so the ones in the package are not the originals? Or is it the fault of the extractor utility?

Anyway, if you were generous enough to license all the TNM assets under creatve commons, wouldn't you be kind enough to help people use them safely?

[DDL]

Yes, quite frequently once a mesh is made, a lot of tweaking is done via import line (as it's vastly easier to simply say "the offset of this mesh is 2000 arbitrary units downward" than it is to manually adjust an entire animated set of meshes or whatever. Drawscale is particularly handy to adjust this way).

Of course, the package doesn't know this post-import, it just has "the mesh", so exporting it will export it 'as it appears in game'. Thus, mesh offsets, rotations and scale alterations can be reset to default values. You'll also notice that in the import lines, a mesh called CustomSniperRifle3 but imported and given a meshname of TNMRifle (made up names, incidentally, not real examples) will be exported as TNMRifle, so you'd have to go through tweaking all the import lines for that.

It's entirely feasible though. Just laborious.

[Chris Rosenkreutz]

Of course, the package doesn't know this post-import, it just has "the mesh", so exporting it will export it 'as it appears in game'.

Does it? Ucc goes to the trouble of replicating the import script and storing it with the mesh. Does "the mesh" include things like textures? If so, why are they stored separately? I wondered then if the script was parsed by the game. I would have thought that some of the animation stuff would do weird things if applied twice. The only thing I can see wrong at the minute is the origin change.

Removing the origin changing lines doesn't work. If I had a way of inverting the transformation, it would be OK. Manually adjusting the origin changes by trial and error would be slow and the result won't be in exactly the same position as the original.

You'll also notice that in the import lines, a mesh called CustomSniperRifle3 but imported and given a meshname of TNMRifle (made up names, incidentally, not real examples) will be exported as TNMRifle, so you'd have to go through tweaking all the import lines for that.

It's entirely feasible though. Just laborious.

You don't have to tweak all the import lines at all. Just rename TNMRifle.a3d to CustomSniperRifle3.a3d . I've got a script to do that. That's needed for textures, sound etc. They all work.

[DDL]

If you're happy to rename hundreds of files rather than rename hundreds of code references, that's fine. Even better if you can get a batch script to do it. I was simply saying how I'd do it, and I lack clever scriptskillz for that sort of thing.

As for the import code in the package, it's included purely so you CAN export it. If you open a .u file in notepad, amongst all the gobbledegook you will find word-perfect copies of all the code that package contains, I assume so it can then be exported as such.

The meshes themselves have their properties 'baked' onto them at import (so to speak), so their offsets, rotations, sizes and texture assignments are all then part of the mesh. Note, not textures, but texture assignments. WeaponMiniCrossbow doesn't care what minicrossbowtex1 looks like, it merely knows that that's the texture for its skin. Change the texture, you change the appearance of the mesh, but the mesh (and its references) is still unchanged. Tell the mesh it's skin property is something else, and that other texture will appear, but the meshes default skin property remains unchanged.
As an example of meshes with no texture assignments at import, look at any of the characters from DX. Without multiskin/skin references in the defprops, they're totally blank.

[Chris Rosenkreutz]

I'm stupid. When faced with code like:

#exec mesh IMPORT MESH=TNMRifle ANIVFILE=MODELS\HCustomSniperRifle3_a.3d DATAFILE=MODELS\CustomSniperRifle3_d.3d X=0 Y=0 Z=0 UNMIRROR=1
#exec mesh ORIGIN MESH=TNMRifle X=5632 ...

I thought that the origin was wrong. I was fooled by the way that fist were out of sight which I fixed by somehow accidentally rotating them by almost 180 degrees. So I didn't notice that they were mirrored. the ORIGIN command doesn't alter the files I can export at all, nor does most of the other mesh scripting stuff. All that's happening is that the IMPORT line was mirroring them.

So I reverted all the weapons scripts I'd been messing with (apart from the line GoverningSkill=Class'SkillWeaponFists' of course), recompiled the packages, then extracted the models again and recompiled using those. Now everything I'm carrying is the right way round. Hopefully evrything else is alright.

If you're happy to rename hundreds of files rather than rename hundreds of code references, that's fine.

I'll have to merge any code changes I make when patch 1.03 comes out. Hundreds of changes would make that harder.

As for the import code in the package, it's included purely so you CAN export it. If you open a .u file in notepad, amongst all the gobbledegook you will find word-perfect copies of all the code that package contains, I assume so it can then be exported as such.

I assume you're right. In the case of mesh import scripts, it contains them twice: once in the original script and once with the mesh. Maybe so that if you want to use the mesh for something, you don't have to dig around for the import script. Of course, you don't need to do that for simpler assets like textures.

Thanks anyway.

[Trestkon]

You are dedicated, Sir! Might have saved you some trouble to just drop by and ask first, though, as we would have thrown all the source files at you Of course, we appreciate your tenacity!

Actually, we've been planning to wait until 1.0.3 (the final version) was complete before we released the "SDK". If you're interested I can upload the current source files, or you can wait a few weeks and we'll post the official source files when we release 1.0.3.

[Jonas]

Note that when Trestkon says "a few weeks", he isn't in fact the person who has to fix or even test all the remaining bugs for the next patch, that would be me, with the help of Shane and Nick and sometimes DDL, and I have no idea when I'll be done

That's not to say Larry can't or won't fix bugs if asked of course, just that it's a job I've taken and it's easier if I handle it myself and leave Larry to oversee the next project in our pipeline.

[Trestkon]

Note that when Trestkon says "a few weeks", he isn't in fact the person who has to fix or even test all the remaining bugs for the next patch, that would be me, with the help of Shane and Nick and sometimes DDL, and I have no idea when I'll be done

That's not to say Larry can't or won't fix bugs if asked of course, just that it's a job I've taken and it's easier if I handle it myself and leave Larry to oversee the next project in our pipeline.

Yes, but the universe bends to my will.

BEND, DAMNIT!

[Jonas]

"Bend over and take it" more like

But yeah I'll do my best.

[Chris Rosenkreutz]

Thanks for the offer. I now effectively have all the source for 1.02. I don't need to use another gig of bandwidth to download them so you needn't go to the trouble of uploading them for my sake.

Would I be right in thinking that the code changes between 1.02, what you all are working with now and 1.03 tomorrow are going to be few and minor, at least outside of the mission scripts? Almost everything appears to be working fine to me.

And I have plenty of time still to report bugs?

[Jonas]

Depends what you mean by minor, but they won't be few.

[that guy]

If everything is working perfectly for you then you're one of the lucky ones .