Official Updater Set-Up

[HuninHune]

How to use iRohan loader

First step
Upload this to a web server Website.rar

Second Step(in a hex editor) Edit loader.dll
Replace all the login.playrohan.com links with links to your site/patcher

Third Step
Edit loader.dat
here's a 010 template for it

typedef struct{    char updateserv[60];
    int Port;
    char updatelocation[128];
    char loaderbgloc[256];
    int one;
    char country[8];
} update;




while( !FEof() )
{
    update cfg;
}

Forth step Using my patch maker PatchMaker.rar Create a new update file
NOTES ON THIS
1. Fileinfo.raw MUST BE KEPT you can only use ONE COPY of this file if you use multiples it will fuck shit up it stores old patches and builds off the existing patches so they work.

2. Files must be put in the directories they will be output to IE if you want to update itemcostume.bin you should put a copy of itemcostume.bin in a folder named data in the patchmaker folder
- EXAMPLE -> \PatchMaker\data\itemcostume.bin

3. Once you have put the files in the directories they will be updated to run the flbuilder.exe this will create files within the patch folder

4. Upload the contents of the patch folder to your site then remove them from the patch folder locally so it doesn't mess up your next update

Fifth step is you should be able to run loader.exe and have it update...



FINAL NOTES :
1. Get your loader files from your own client or from the iRohan client
2. This copy of my patch maker has known bugs with files under 3KB in size... either decompile the .exe using .net reflector and fix the bug or avoid patching 3kb and smaller files I don't use this anymore so have no real reason to fix the issue... all it does is it fucks up the final int in the .rp file(file size) by 4 and does same for the fileinfo.lst... you can manually fix this by editing the lengths yourself and running patch maker again on another file larger then 3kb

Here's the 010 templates for fileinfo and .rp files
Rp file

typedef struct{
    char Header[32];
    int Version;
    int always1;
    int idfk;
    int idfk2;
    char data[datalength];
    int outputtype;
	int FileVersion;
	FILETIME modifydate;
	int always1;
    char Filename[64];
    char localfilename[128];
    int sizedecompressed;
    char rpfile[64];
    char outputlocation[128];
    int sizecompressed;
} version;




while( !FEof() )
{
    version list;
}

filelist (the .raw here OR the decompressed blob from a generated list)

typedef struct{
    signed int OutputType;
    signed int PatchVersion;
    FILETIME Time;
    signed int Always1;
    char OutputName[64];
    char LocalPath[128];
    signed int Filesize;
    char rpFile[64];
    char OutputPath[128];
    signed int CompressedSize;
} file;




while( !FEof() )
{
    file list;
}

filelist header

typedef struct{
    char Header[32];
    int Version;
    int numItems;
    int always1;
    int PackedBlobSize;
    int unpackedBlobSize;
    char data;
} version;




while( !FEof() )
{
    version list;
}

This is not a beginners guide I wont be answering questions on this guide... I've done that in the past and it's a huge headache so i'm just dumping this info and you can figure it out from here.

[MentaL]

[Ishtaria]

This goes over my head but I agree with what you say about those who can't understand it. If we don't know what to do with it then we have no business using it.

[PenguinJoe]

I usually prefer building my own loader/updater/patcher setups. I just find it faster than trying to read some Korean dev's mind to figure out what they were thinking when they designed their code.

[HuninHune]

I prefer using official updaters xD With rohan it's nice cause it updates the GEM/GELs out of the box

[Ishtaria]

One thing I would like to ask (not necessarily for it to be done) is how easy would it be to make a gem/gel compiler if one hasn't already been made? Thinking about initial client distribution.

[HuninHune]

It's not hard at all the files arent encoded even a little xD

[Ishtaria]

Thought so. It's just a container (gem) with list of contents (gel) right?

[HuninHune]

Yes thats correct

[Ishtaria]

I'm sure it's something PJ wouldn't mind doing hehe

[PenguinJoe]

Sounds pretty simple to both compile and decompile.

I think Hunin put the GEL format in here somewhere (ah there it is - on the 010 structs page :D) And as you say the GEM is nothing more than a concatenation of .gtx bitmaps.

What format are the .gtx files? Would be nice to have something that could convert formats from that to some more standard format.

[Ishtaria]

I have one of those (another Hunin tool?). Gtx are tga or dds format but with a slightly different header.

[PenguinJoe]

I tried out this .gtx/.dds converter/viewer. It seemed to barf on Rohan's .gtx files - but that may be because My directx env may not have been just right.

If that works, i'll decompile it and get the .gtx format :D easy enough.

[HuninHune]

Yeah rohans headers are borked up a bit i forget the changes but you can easilly edit them to .dds and edit them then change them back

[PenguinJoe]

OK. I've managed to get some .gfx with matching .tga & .dds files. Since it is just the headers that get changed, it should not be too tough to do a few binary diffs on the headers to see what needs to be jiggered.

Maybe in a short time I will have an improved version of RohanTool that will work directly with .dds & .tga & translates to/from .gfx in the background along with some shell-based compiler/decompilers.

---------- edit ----------
Did some binary compares. Jezuz... Why did they bother ?

For the guys here -

To convert TGA to GFX -- INSERT "GEO" as the 1st 3 bytes if the file.
To convert GFX to TGA -- Check to see if a tga file. If it is, simply save the file from byte offset 3 onwards (delete the 'GEO') as a .tga file.

To convert DDS to GFX -- REPLACE "DDS" with "GEO" as the 1st 3 bytes if the file.
To convert GFX to DDS -- If byte for is 0x7C, REPLACE the "GEO" with "DDS" and save the file as .dds.

Check for TGA vs DDS GFX file.

GFX can be either a .tgs or dds internally. To tell the difference, look at the byte at 0-based offset 4. A Directx 9 DDS file requires this byte to always be 0x7C. A .TGA file will have either a 0x00 or 0x01 in that position.

.tga header: (reference here: http://www.fileformat.info/format/tga/egff.htm ) typedef struct
{
byte IDLength; /* Size of Image ID field immediately following the header*/
byte ColorMapType; /* Color map type - 0x00 or 0x01 depending on ImageType */
byte ImageType; /* Image type code */
short CMapStart; /* Color map origin */
short CMapLength; /* Color map length */
byte CMapDepth; /* Depth of color map entries */
short XOffset; /* X origin of image */
short YOffset; /* Y origin of image */
short Width; /* Width of image */
short Height; /* Height of image */
byte PixelDepth; /* Image pixel size */
byte ImageDescriptor; /* Image descriptor byte */
} TGAHEAD;

.dds header (Reference here: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx)
DWORD dwMagic ("DDS "); // 1st 4 bytes - not part of the actual header.
Note the space char used to pad this to a full 32-bit size)

typedef struct {
int dwSize;
int dwFlags;
int dwHeight;
int dwWidth;
int dwPitchOrLinearSize;
int dwDepth;
int dwMipMapCount;
int dwReserved1[11];
struct DDS_PIXELFORMAT (embedded structure)
{
int dwSize; (32=bit bitfield)
int dwFlags;
int dwFourCC;
int dwRGBBitCount;
int dwRBitMask;
int dwGBitMask;
int dwBBitMask;
int dwABitMask;
};int dwCaps;
int dwCaps2;
int dwCaps3;
int dwCaps4;
int dwReserved2;
} DDS_HEADER;

[PenguinJoe]

Just as an update on my prev post, while doing some work on my 'Grafix Master' tooling listing out the contents of the gel files, it appears the .gem file holds a LOT more than just a collection .gfx files ;) These seem to be the dumping ground for collections of files used by the rohan client there's .txt, db, emu, ui, some bastardized .gfx with underscores and all kinds of other oddball files in there. Hell, even found a .zip in the one I was testing with.

Needless to say there are only two of those types that is particularly editable -- the .gfx and .txt files. The rest are either used for specific internal or utility functions and are meaningless in a graphics editing context. In the context of editing rohan images, you really only need to care about the .gfx (and thir permutations) and .txt files if you want to change/translate them.