Sorry for the delay. I'm hoping to put the new compiler up tomorrow. I don't know about posting source code, and as of this point in time, I won't be posting the original .smd files yet.

However at some point tomorrow, unless more network poop happens, I'll have the compiler up.

Sorry for the delay

It's been along time coming, but thanks all the same, lets hope things PickUp around here....:D

those are great news! I´m going to post that on my website so that all the custom stuff peeps will go worship you :>

RE: The source,

Is it just a political issue at Valve over releasing it?

As I mentioned before, Im running into problems with my face animations because i may need to up some of the limits but my own efforts with the source have been rather ineffective and hence the reason for wanting to see yours.

While I know politics can be wierd at times, I cant figure out why Valve would not release the source for a piece of code which doesnt allow cheating and is already in the SDK anyway.

- Jed

Great news PIU, indeed it is about time.

Im very sad it took so much time to release but good times are ahead of us :-)

GJ PickItUp... Finally something is done :)

WWOOOHOOO

Praise the Lord!!

Finally i will have SS Trenchcoats with gasmasks back in my dod once more..hallelujah:D

w00t!

/me dances through college rez building ;)

HUZZAH! Did my PM help remind you? :D

/me seks PIU

yeah finally.... too bad pokemart isnt open

Its Christmas all over again! And Jed, I cant wait for those models your talking about. Are they going to be something like those models where the mouth moves when you use the mic?

Glad to hear your still around JED:D

Yeah, Jed's updated para's are on top of my wish list too...the brits dont feel right unless there donning red beret's!

Last time i saw, his anims had the guys face closing one eye, and peering down the sight with the other whilst firing..or something similar. Like this;)


:P

Iron sights would go good with Jeds's model.

*donce donce donce*

But just when my three day break is over!! Oh well, there's always this coming weekend to play some DoD finally.

Joy to the World, release has come,
The latest compiler is free,
Old defaults will be gone,
Customs will live on,
Compile models with glee,
Compile models with glee,
Compile, compile, compile with glee.

<3 PickItUp

Originally posted by Silverghost
Joy to the World, release has come,
The latest compiler is free,
Old defaults will be gone,
Customs will live on,
Compile models with glee,
Compile models with glee,
Compile, compile, compile with glee.



O..M..G.. That's just awesome ;)

lmao

Will this new version fix the problem where you decompile and then recompile the textures are all misaligned.

Expect Russians fairly soon after this thing is released...

Why dont you post us a pic of those Russians? My mouth is waterin':o

PLEASE POST THIS PROGRAM IN THE MODELING FORUM AS A STICKY WITH A RELIABLE LINK THAT WONT GO DOWN.

Thanks DoD Team

VoodooChild


Get back to work modelers, I expect some good stuff.

Are the 3.1 models smaller than 1.1 models?:confused:

Originally posted by Silverghost
Joy to the World, release has come,
The latest compiler is free,
Old defaults will be gone,
Customs will live on,
Compile models with glee,
Compile models with glee,
Compile, compile, compile with glee.

<3 PickItUp

*Claps* lol nice one.

And great news about the compiler. I'll finally be able to get my Axis pack working lol

- Ska

Weeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee!

About time too!

Oh your back then Ska_Warz.

ya tart... :P

- Jed

Strider we can get those player models happenign now.

Originally posted by Grain
Will this new version fix the problem where you decompile and then recompile the textures are all misaligned.

Nah, that's a general compiling thing, even the original compiler had it. Compiling a model shifts textures over in certain cases.. re-compiling "decompiled" textures rather than the original source textures makes the problem worse. (Since it shifts them over twice)

I actually figured out exactly what causes the shift but by the time I got my head around the math involved it caused a stroke and I forgot it.

- Jed

Originally posted by Trp. Jed
I actually figured out exactly what causes the shift but by the time I got my head around the math involved it caused a stroke and I forgot it.

- Jed

Yeah, me too. Figured it out but forgot it.

:)

isnt it rounding of numbers?

If I didn't already owe my soul to Jed and his iron wit, I'd give mine to you, PIU.

Thank the lord. I can play DoD once more.

:P

Its to do with normalisation of the UVW co-ordinates and the rounding down of number to be values between 0 and 1.

If a UVW co-ordinate for a point is say

X = 234.5
Y = 127.6

and the texture is 256 x 256 then after normalisation they become:

X = 0.9160
Y = 0.4984

When you de-compile it and try to get your original UVW co-ordinates back you end up with.

X= 234.496
Y = 127.5904

Its not *much* of an error but depending on to how many degree's of accuracy the modelling program stores UVW co-ordinates, it start's to nudge your UVW co-ordinates away from the original position.

Decompile and re-compile the same model over and over again and the mapping co-ordinates shift more and more and more.

- Jed

Originally posted by Skullz_Vandal
If I didn't already owe my soul to Jed and his iron wit, I'd give mine to you, PIU.


You might of corrected my grammar in your sig Skullz :(

- Jed

Originally posted by Trp. Jed
:P

Its to do with normalisation of the UVW co-ordinates and the rounding down of number to be values between 0 and 1.

If a UVW co-ordinate for a point is say

X = 234.5
Y = 127.6

and the texture is 256 x 256 then after normalisation they become:

X = 0.9160
Y = 0.4984

When you de-compile it and try to get your original UVW co-ordinates back you end up with.

X= 234.496
Y = 127.5904

Its not *much* of an error but depending on to how many degree's of accuracy the modelling program stores UVW co-ordinates, it start's to nudge your UVW co-ordinates away from the original position.

Decompile and re-compile the same model over and over again and the mapping co-ordinates shift more and more and more.

- Jed

yes jed, thats exactlly what i was thinking:shocked: :P

thank the lord for guys like you!

Originally posted by Warlord-Sco-
thank the lord for guys like you!

"Thank" isn't the word I would of chosen...

- Jed

lol, sorry, is Praise more fitting?
:D

so is this released?

Originally posted by Flammenwerfer
so is this released?

Do you mind? Cant you see theres a hijacking in progress? :mad:

- Jed

Yeah, can you beleive that??

the cheek of some people now-a-days:p

BAH! YOU AND YOUR DEMANDS!

....ok.

im guessing there is a slight delay, thats ok, i think all of us expected something, its not your fault PIU, its a Valve thing :p

by tomarrow he means today's tomarrow if not tomarrow's own tomarrow

soon

:)

Originally posted by Trp. Jed
Its to do with normalisation of the UVW co-ordinates and the rounding down of number to be values between 0 and 1.

- Jed

That's what I figured.

Now, can you figure out why recompiled textures get posterized too? :D

Seems to me, it'd be the same problem. Discrepencies between rounded numbers and such. As much as I liked some of the content in Ernst Rohm's big pack of stuff, some of the player models had been recompiled a few too many times [but I could see why; some of those textures were really nifty and unique], ending up with something like ten colours per map, which was a really big shame.

I can't tell you i know the math involved nor the coding but i can tell you after millions of compiling and decompilings i found that bug to and i also find another thing.

you take a model, decompile it.
in the decompile folder you now have diffrent files than the files the creator had in his.

Now once you decompile the "damage" is done, you can compile again and again and again and it will look the same, decompile again, then compile again will cause more **** ups.

what i found really wierd is that sometimes it really changes things.
I released 2 weeks ago a conversion to bruta's tommy to marzy's tommy, nm... anyway marzy's tommy had a in/out clip trick, when you reload you see the clip coming out empty and when reloading it's full with bullets, now after several times i compiled it and decompiled it the whole thing was gone and it looked full all the time.

I hope you guys figure out how to over come this problem, anyway... do you recommend compiling weapon models with this compiler too or just player models ? or it doesn't matter for weapons (and others) ?

How about always have the originals :)

Perfectly sound advice, Silverghost.

Unless you didn't create the model and are modifying an existing one by creating a hack job or improving something or other.

I get textures shifting to the left weather i'm decompiling or compiling, due to the UV map/maps moving. I've found that if i make a model and it's UV map/maps in Lightwave, and then import the model into Milkshape, the UV map/maps have stayed in place. But when i assign the bones and save it out as a reference SMD file and compile it, the UV map/maps have shifted to the left. So to get around this problem, i have to offset the UV maps in Milkshape to the right a little, so when i do compile the model, the shift to the left brings the UV maps inline again.

It would be very useful and time saving if this problem was fixed.

You cant fix it *that* easily.

I don't believe its down to StudioMDL/MDLDec - its just happens to be the datatypes used to hold the UVW co-ordinates inside the MDL format and Milkshape and normalisation.

Bear in mind, MDL creation was designed to be a one-way process. Valve/ID have the source, conversion takes place and the MDL is created.

Decompiling was the work of some talented individuals and errors are bound to creep in due to the mathematical convertion of data types required. Its like JPEG format - once you compress, you can get the removed data back even though you can convert it back to a BMP.

As for posterization or decompiled textures, while I'm not saying it doesnt happen - why defies all logic. I've seen from the guts of StudioMDL and HLMV that the BMP's are added to and read from the originals without any modification. I can't believe that the decompiler modifies the data during the output stage.

Speaking of textures - don't know if you knew this or not but when you tell Photoshop to convert and RGB picture to a Index colour, if your drag one or more selection boxes over area's of your image before you select to convert, the final palette it created is biases towards the colours inside your selections.

- Jed

P.S Can anyone lend me a dollar? I had to put water on my cereal this morning.

Well i've found the conversion from Lightwave to milkshape using the lightwave plugins made by CCCP seem to be spot on, like i said the UV map is ported over in an identical position to that of how it appears in lightwave. I don't think it's caused when saving your model out as an SMD, because if you import the SMD file back into Milkshape, all seems fine with the UV map/maps position. So it would seem the compiler is the problem. I've tried many ways to try and get over the problem, using different MDL formats etc, but have never found a solution other then offsetting the UV maps a little to the right before compiling.

It's very annoying when you have a perfect positioned UV map only to compile the model it belongs to, only to find it's shifted to the left a little. So you end up offsetting UV maps, or parts of them, then compiling the model again, and viewing it in HLMV to see if all has lined up correctly. If not, i have to keep repeating the process until it does line up, pain in the arse springs to mind.

I'm sorry for the way things are going. There are just some things that are out of my hands. I'll leave it at that. I'm trying to get the new compiler up as soon as possible. My plan is to update the "1.0 compiler" sticky thread with the new compiler link. I'll post when I have done it.

Originally posted by PickItUp
I'm sorry for the way things are going. There are just some things that are out of my hands. I'll leave it at that. I'm trying to get the new compiler up as soon as possible. My plan is to update the "1.0 compiler" sticky thread with the new compiler link. I'll post when I have done it.

Your a good man PickItUp, and must feel like SH@T after posting that, i understand there is a big control freak in the house. Big thanks for trying your best, but this is just getting silly now.


I hope they realize how much damage they are doing to this Forum and the community, i just don't see why.

Forums dying
Host sites dying
Creativity dying

It's like there trying to kill the mod, has anyone heard of mutiny.

hope im not getting off subject,

but, does the model compiler have a texture lock feature? If not perhaps this could be implimented.

I keep reading on textures misaligning, is that just the nature of the beast, compiling/decompiling?

Originally posted by MaRzY
It's like there trying to kill the mod, has anyone heard of mutiny.

Yarrrrr! Ye be walking the plank Mr Valve, or wud ye prefer a short drop and a sudden stop from the yard arm Yarrr!

Oh your back then Ska_Warz.

ya tart... :P

:p lol

- Ska

Ok it should be up! Let me know if you guys still have problems with it. If you do, I'll probably vomit.

1.1 Player Model Compiler (http://www.dayofdefeat.com/john/studiomdl.exe)

first post since the updated 1.1 compiler!

(someone had to do it)

hey PIU....it dosn't work right!!!








......Kidding....kidding.

*BARF!*

omg woot woot

Muahahaha, you FOOL! You've played right into my hands! GO COMRADES, FLATTEN THE CAPITALIST IMPERIAL DOGS WITH A RED STORM!

does this mean we'll see some player mdls outta you, cheets?

Omg omg omg omg! *runs around in circles while saying omg in a girl voice* Now for some cool player models GET TO WORK! *hehe jk but really get busy with some cool player models!:D *

im gonna sound stupid now, but how do I update my old 1.0 models for 9-way blending using this compiler??

easy u import export those 1.0 models with the 1.1 bones/model that jed or some1 provided in the msa forum
http://www.dayofdefeat.net/forums/showthread.php?s=&threadid=22013

Compilers out right?

yes (last page *edit* err...the page before this:D)

I have a really big smile on my face right now. :D

Uhhh, there seems to be a problem, unless the reference files have changed.

what is that meant to be?

He's Russian.

he meant whats the problem? the model looks fine.

Maybe this'll show better. And it's only these Russians, the Germans I made worked just fine.

Forgot to attach the pic.

It looks like your p_models are a little off. As far as the sten thing goes, the sten animations hold it off to the side all the time, so that player is not doing the sten animations. And in the crawling thing, he's aiming the gun, it's just that the gun is not in proper position.

Thats my take on it anyway.

The p_ models worked fine with the regular Brit models. And I was editing the decompiled QC file from the Brit-Inf. As for the Sten, he SHOULD be using the Sten anims since I haven't touched that bit yet.

About the texture posterizing: it should be a user problem. I had posterized textures in 3dsmax and Jed's HLMV. I uninstalled Rage3d tweak or whatever that Radeon tweaker is, uninstalled opengl sdk, and reinstalled display adapter drivers. That fixed the problem.

Alright this is really odd. I compared my Russian reference to both my working German references (originally made for Beta 3.1 from the Axis-Para) and to the 1.1 British reference. The Russian MATCHES the British reference, but the Axis reference is different, and lower, and it doesn't match. But the AXIS reference does work. Something ain't right.

Cheers PIU for the compiler release.

Tried compiling, as a test, the default models and they recompiled from the non edited decompiled qc. (using Kratisto's 1.2) no problem at all.

However in game I still see grossly "twisted" models at all times. I noticed on compile it states its "version 1.0". and although the file size is the same, the binary is different to 1.0 so I'm sure I downloaded the newly updated file. I'm obviously doing something wrong here as I never had many problems compiling and recompiling before version 1.1. The models look fine in HLMV BTW - only ingame seeing this.

Regards
Musso

I should probably tell you cheeto, that those models (btw) kick mega ass :)

Originally posted by Skullz_Vandal
I should probably tell you cheeto, that those models (btw) kick mega ass :) Thank Devin, he gave em to me, I'm just finishing em up.

JED!!!!!1111 JED!!!!!111 BRIT AIRBORNE!!!! YAY!!!!!

EDIT: Originally posted by MaRzY
Your a good man PickItUp, and must feel like SH@T after posting that, i understand there is a big control freak in the house. Big thanks for trying your best, but this is just getting silly now.


I hope they realize how much damage they are doing to this Forum and the community, i just don't see why.

Forums dying
Host sites dying
Creativity dying

It's like there trying to kill the mod, has anyone heard of mutiny.

Well said, Marz. Beginning to realize we direct our anger at the wrong sources, mainly because they're our only outlet to what the hell's going on behind the scenes. I'd say the damage is significant. Sure it wasn't as good looking or super realistic but by god put some polish on it and it was fun. Oh well, better get my finger in shape, cause 6 round garand kills probably ain't goin anytime soon.

Originally posted by Airborne506
JED!!!!!1111 JED!!!!!111 BRIT AIRBORNE!!!! YAY!!!!!

Been done for ages and my US Airborne and the US Airborne with the lifevest.

Only problem is getting them to my file host because he's in Holland and I'm Sweden and we keep missing each other on ICQ.

Anyway, should be up by tomorrow night.

- Jed

get dodec to host it

Now someone has to convert the skeleton trenchcoat axis guys and other such favourite skins. I would do it, but I'm really to lazy.