Post tutorial RSS Hijacking the whm for internalizing textures:

A way to make textures internal to the whm instead of floating around in texture_share.

Posted by on - Intermediate Players Modelling

First off a comparison::

External textures:
User Posted Image
Internal Textures:
User Posted Image

Now onto the process.... :P

The RSH:
User Posted Image

As you can see by the architecture of the rsh...

it will be these two chunks we need. to either save and load the chunks or copy and paste. :P Into the whm of course above the other SSHR textures.

chunk'd into the whm:
User Posted Image

when copied across into the whm either via chunk or the good old copy and paste chunk method.
As can be easily seen the two chunks in above the sshr in the whm. :P

SHDR Work:

Naming conventions:
User Posted Image

The internalized SHDR must have the name for the MSGR/MSLC-Data to link too. :P
Internal address work:
User Posted Image

the 1st chunk contains the address of the TXTR that it calls on.
textures_share addition into the name with the name of the shdr at the end.

TXTR work:
User Posted Image

The TXTR's name must be the address of the texture with the exception of the textures_share addition into the name with the name of the shdr at the end.

Linking it to the MSGR/MSLC-Data:
User Posted Image

The MSGR/MSLC-Data must contain the name of the SHDR you want the texture to apply to the UV.

All done and should work internally without any issues.
First issue will always be typos. :P

this is designed for non team colour things like the daemons as the example.
I do not know if there is a way to do wtp work like this. But I think not.
Haven't confirmed if the wtp works if the texture is applied this way.

Something about DOW II. :P

What did I miss?

Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.