Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: TrashMan on December 30, 2005, 09:02:45 am
-
On some of hte more recent 3.6.6. versions and the 3.6.7. texture replacement doens't wrok by me.
I use it mostly fro nameplates but it doesn't change (it did in older versions)
Has this been fixed?
-
Are you using Duplicate Model mode?
-
$Duplicate Model Texture Replace:
+old: nameplate
+new: NTCMylae
does work. They other method does not.
-
I just set the texture replacement in FRED. that SHOULD wrok but it doesn't...
-
Texture replacement has two modes. Make sure Duplicate model is selected. Then it will work.
-
Use the duplicate model replacement type, not the regular texture replacement type:
(http://img.photobucket.com/albums/v106/NelsonAndBronte/FS2/TextReplace.jpg)
-
I see...
Why doesn't hte normal texture replacement work?
-
Bugs. Bugs and a lack of coders to fix them.
-
Bugs, a lack of a coder to fix them, and a perfectly viable alternative with exactly the same functionality, hus preventing anyone from getting any serious motivation to fix what can be, more or less, relegated to a backup alternative I'd say.
-
What is the difference?
-
I've never really been able to figure that one out.
How about we just remove the radio buttons in FRED until the bug is fixed? At least that way everyone thinks that texture replacement is working as designed :D
-
The words 'duplicae model' bother me, because it sounds like it's creating a new model in memory with different texture values, thus adding a fair amount of data that is totally unneccessary.
-
Hell, and it's not working either! :mad:
I use standard PCX for nameplates and allways only the original nameplates show up (GTD Orion on a orion insted of GTD Liberty, that is set in FRRED)
-
The words 'duplicae model' bother me, because it sounds like it's creating a new model in memory with different texture values, thus adding a fair amount of data that is totally unneccessary.
This is exactly what happens. "Duplicate model" creates a new instance of the original ship model and then reskins it. "Regular" simply switches in the new texture during rendering.
"Regular" worked when it was first released, but at some point early on it stopped working and I haven't gotten around to finding out why. It's possible it has something to do with the HTL upgrade.
The reason for the two modes is for efficiency's sake. "Regular" should be sufficient for most situations, like nameplates, but if you have a whole bunch of textures replaced (like the Orion/Hatshepsut in JAD2) then "Duplicate" might be a better strategy. I've never conducted any benchmark tests, but here are the tradeoffs:
"Regular" pros:
Uses less memory, because it doesn't need to copy the model
"Regular" cons:
Very slightly slower, because it has to do a texture check every time it renders the model. This probably doesn't matter for simple one- or two- texture jobs, but the more textures you replace, the more checking and switching you have to do.
"Duplicate" pros:
There's no slowdown at all during the mission, because once the duplicate model is created, it's rendered exactly in the same manner as an unmodified model
"Duplicate" cons:
Significant increase of memory because of all the model data (an entire polymodel struct) that's copied.
-
Er...that's a little ridiculous.
You're talking some sizable portion of a MB of video card memory in exchange for, what, a couple nanoseconds per frame? :no:
Drawing the lead indicator probably takes at least six times that long.
-
As I said, I've never conducted any benchmark tests. :)
-
So basicly, when there are big battles involved, with 5-6 nameplated ships, which approach ould be best?
and is anyone planning on fixing hte regular replacement?
-
Obviously duplicate model replacement, since it's the only one that works :p
However, in that instance it really means that "normal" texture replacement is the best option. That doesn't mean that it works though and until the Mantis bug gets dragged back up and people start clamoring to get it fixed I wouldn't expect it to be given much thought since there's already a working method.
-
I don't mind having a look at fixing it if someone can post a mission that demonstrates the problem. I'd bet that one has been posted before but it's not attached to the Mantis bug and I don't care to hunt around for it.
-
I made two missions to test it myself a while ago. I uploaded them to Mantis. :)
-
It's working now. I think that's some kind of record. :D
Should hit CVS tomorrow. Oh and it's actually quite fast to use the replacement texture this way. It's nothing special and the code has to go through all of these checks before trying to use the normal texture anyway. It should be as fast, if not slightly faster than accessing the original texture.
-
Is there really any reason to keep the duplicate model thing around, and not just default to 'regular'?
Edit: Although, if there's a simple function to make a specific ship use a duplicate model, I may have a use for that.
-
Should I go through the missions for the FS2 nameplated campaign and replace the duplicate with regular style for Media VP inclusion? Would take 5 mins with find and replace.
-
Should I go through the missions for the FS2 nameplated campaign and replace the duplicate with regular style for Media VP inclusion? Would take 5 mins with find and replace.
That would be great...
I have an
Athlon Thunderbird 1.333 MHz
with an GeForce 3 (64 MB DDR-RAM)
and 512 Non-DDR-RAM (133 MHz CL-2, Infineon).
FS2_Open runs fine... But it takes its time to load- and "modify" (duplicate) the models...
So the missions hang for a time...
-
It's working now. I think that's some kind of record. :D
Much thanks. :) What was the problem? Was it HTL related, or just some screwup on my part?
-
What was the problem? Was it HTL related, or just some screwup on my part?
Just a screwup on your part. ;) It didn't know how to figure out what texture to use. The Interp_replacement_bitmap wasn't needed, and wouldn't have worked properly anyway. And then getting the correct value from the Interp_replacement_textures array was wrong too. It should work properly for HTL and non-HTL now with a minimum of fuss. I've debugged through all of that model code quite a few times at this point so when I got that far in figuring out what was wrong it was pretty apparent what the problem was.