Author Topic: FF8 Models, How did Qhimm rip them?  (Read 68148 times)

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #50 on: 2009-10-09 20:06:06 »
whoa whoa whoa! Don't say you haven't had much luck! I can tell the first one is Quistis!

You've obviously made some progress!

It looks like you're having a problem determining which verts are attached to which bones, how much weight they have, or some similar issue.

I have some very high hopes for all this now.

Vehek

  • *
  • Posts: 215
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #51 on: 2009-12-30 22:31:54 »
In case anyone's wondering, I messed with my script too much and didn't keep backups, so I can't reproduce those results from before.  :oops:
I've attempted to recreate it, but I don't know how close I've gotten. I've fixed the misplacement of vertices though.

Current results:


I suppose it's working better skeleton-wise than my other version of the script, which uses Blender's Pose module.


However, the first method can only do one frame from one animation.


(I don't know much about 3D.)


Animation Test Image
« Last Edit: 2010-01-12 00:47:47 by Vehek »

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #52 on: 2009-12-31 02:45:34 »
It may or may not look like much to you, but it looks very promising in my opinion.

I can't say I remember too much about the state of the previous script... but this certainly looks like progress to my eyes.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #53 on: 2010-01-07 22:34:58 »
In case anyone's wondering, I messed with my script too much and didn't keep backups, so I can't reproduce those results from before.  :oops:
I've attempted to recreate it, but I don't know how close I've gotten. I've fixed the misplacement of vertices though.

Current results:

However, the first method can only do one frame from one animation.


(I don't know much about 3D.)


The polygon placement looks about right actually. I believe that the models might have been permanently lit though.  The UV data should also be with the polygons as I remember something like that it was straight forward poylgon data from the PS1 GPU system.

Cyb

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #54 on: 2010-01-07 23:19:35 »
Oh how I wish I had he skill at spotting the relevant patterns for data structures like you guys have... Even with well documented headers I can't seem to make my bytes fit right... nonetheless find a vertex pool...

but regardless, I'm glad to see I'm not the only one still interested in getting a good look at 8's graphics.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #55 on: 2010-01-09 15:50:52 »
Oh how I wish I had he skill at spotting the relevant patterns for data structures like you guys have... Even with well documented headers I can't seem to make my bytes fit right... nonetheless find a vertex pool...

but regardless, I'm glad to see I'm not the only one still interested in getting a good look at 8's graphics.
For me it's sort of like this, "I'm working on an LED luminary, how far is that half bridge from the OSMC 4.1XX, ok I have this AT91SAM7S dev kit is the JTAG drivers installed, I need to install YAGARTO to develope for the micro why is ECLIPSE CDT wiping out the ZYLIN CDT used with YAGARTO, we have 30cm of snow in the drive way. Ok which to do first" sadly that's just today. That didn't include eating getting up and the myriad of other things I think of in a single day etc.

I would spend more time on this stuff if I had more time I guess is the best way of looking at it.

The best way to look at graphics data is that it IS data. Data must be arranged in a uniform manner. Data must have certain information in it for it to function.  What does FF8 do? It has polygons textures, and a skeletal system. We know this by observing the game output.  So it must have UV data to map the texture. It must have a texture. It must have a list of vertex information. It must have a polygon list.  I believe FF8 used all quads I can't be positive because it's been almost 3 years and 9 months since I looked at it. Unlike FF7 it's all the same data type.  FF7 had a rather complex setup where it drew quads triangles and then textures. FF8 just does textures. Of course the reason why FF7 looks quite good still is because of the complex method of rendering.You are a bit further along than I was I was about where you were at the post on 2009-10-09 14:31:2.

Side ramblings, I have more FF9 data now. I suppose I should finish gathering the FF8 data as well. I need several hundred saves with detailed notes on them basically to verify what bit does what and when. One LONG boring play through.

I may put up a detailed CRC explanation as well (hmmm).

Erstwhile with the FF8 data I suggest taking a bit map and drawing on it while you render, the polygon data or while you traverse it.  This technique allowed me to find and understand  the UV data in FF7. IE you feed the UV coordinate data into a vector drawing routine and plot the UV drawing out on a bitmap. IF it looks right then you are probably correct in analysizing the data. Do note they do mirror the data. If you wish to get fancy you can also include numbering for each polygon drawn as well. I started doing that just to know what was done when. (I was nuts I admit).

IF you detail all of this better than I can remember good, if you have the time put it in the wiki (LOL) maybe Qgears will get FF8 functionality sooner than later.

Cyb

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #56 on: 2010-01-09 23:55:38 »
So what you're saying, is that once I have a potential vertex pool, I start plotting two of the coords per vertex in paint... If it starts to look like a model shape, I probably have the right stuff. If not I may be looking at something else entirely...

Is that what you're describing?

(And on the subject of busy life stuff... that I can fully understand... it isn't easy being a fulltime student with a part time job and no method of self-transport...)


However, I should note that I'm not simply working on FF8... I'm on FF9, both .hack series' and a number of other games on and off at any given moment, as well as being a 3D modeler for my own games... If I devoted all my time to one format... I'd probably be able to crack it at some point(or have a severe mental break).

However, my previous statement was referring mainly to the fact that I still can't get my headers to read properly even when they are fully documented...

When I read a header that tells me a file should start or end at a certain point in the data... I look at that part and it's either well after the end of the file or it is in some random spot after the file has already started... so instead I look at a relative point to the beginning, or end of that header, or the main header, or the end of the previous file, etc... but for some reason, even though I know the documentation is good, the headers don't seem to point me to where they should... (meaning I'm somehow reading them wrong...)



In any case... none of this helps the FF8 formats so I guess I'll stop.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #57 on: 2010-01-10 19:31:53 »
So what you're saying, is that once I have a potential vertex pool, I start plotting two of the coords per vertex in paint... If it starts to look like a model shape, I probably have the right stuff. If not I may be looking at something else entirely...

Is that what you're describing?

(And on the subject of busy life stuff... that I can fully understand... it isn't easy being a fulltime student with a part time job and no method of self-transport...)


However, I should note that I'm not simply working on FF8... I'm on FF9, both .hack series' and a number of other games on and off at any given moment, as well as being a 3D modeler for my own games... If I devoted all my time to one format... I'd probably be able to crack it at some point(or have a severe mental break).

However, my previous statement was referring mainly to the fact that I still can't get my headers to read properly even when they are fully documented...

When I read a header that tells me a file should start or end at a certain point in the data... I look at that part and it's either well after the end of the file or it is in some random spot after the file has already started... so instead I look at a relative point to the beginning, or end of that header, or the main header, or the end of the previous file, etc... but for some reason, even though I know the documentation is good, the headers don't seem to point me to where they should... (meaning I'm somehow reading them wrong...)



In any case... none of this helps the FF8 formats so I guess I'll stop.

I'm now curious when I get time I'll dig through what's left of my FF8 experimentation.  I have to remember the media data as well. FF7 was much easier to deal with than FF8 and FF9 in that regards. In the mean time it will be a bit of time before I can have some useful data from my mad ramblings eons ago.

As for your interpretation of the headers, I believe if you can find the data on for example 15 different models, then compare the header information with regard to the information to the location of the data in the model section that will help. That's basically what I've always had to do. It's how I discovered that the model file in FF7 is actually a large number of files with character files having 16 weapon files (including blank ones) and the weapons were treated as part of the character's skeleton in animations. :D

If you plot the 3d data as you decribe you can get an idea. It also works with the UV data for the 3d data as well. That will get a few textures on your models. Also be aware of the way the PS1 renders quads and triangles. They are not obvious. In fact I suggest you read halkun's 'everything you wanted to know' document he wrote in regards to the organization of the GPU data. Follow carefully the use of the coordinates in the polygon. The PS1 renders the quads as 2 triangles. This is how I got them to work in data FF7 with quite good results. The same will go with the data likely in FF8. If you think about 2 triangles being rendered to make a quad. 2 points are adjacent. That's the big clue on how they rendered the data.  You will have your polys look like bow ties if you don't realize this. :D

UV data has coordinates in a bit map (texture).  If you take a blank bit map and draw the UV coordinates on it while traversing the associated polygons you can plot the triangles and polys on the bitmap as they are rendered.  This also helps when you have your quad coordinates not in order.

Cyb

Vehek

  • *
  • Posts: 215
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #58 on: 2010-01-11 03:03:55 »
FF8 UV data is one of the thing that's been at least partially documented before, and so far it mostly seems to work.

Example using my first method of applying rotations.


I still need to figure out how to properly apply the rotations. Even this method is a bit off, more than this particular model shows. There are also some things I need to do for ease of use.

I admit I'm rather ignorant on how the PSX actually draws things.
« Last Edit: 2010-01-11 03:14:35 by Vehek »

Cyberman

  • *
  • Posts: 1572
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #59 on: 2010-01-12 01:29:39 »
Those gaping holes infer that the surface has the inverse normal it should have hmm you may have mostly triangles and those might be quads? This may indicate you are not traversing those particular vertexes in the correct order. The right foot looks slightly incorrect. It's better looking than my spaghetti was to be honest.

I found my old source code but it looks like the DFM file (form layout description language) got hosed. It seemed to do quite a bit it appears to have used GLPanel which... isn't on the net anymore :)

I remember I was moving to GLScene. However GLScene is vehemently Delphine in nature as well as not very well supported by BCB. I can't build the components essentially. (Puzzle).

Well anyhow it appears to be a similiar panel to what NeHe assistants used in the BCB examples. So I'll see what I can do with those variants.

The biggest problem is I am missing half the descriptor for my form.

Erstwhile as I said it looks like you have missordered some of the vertexs and that might be what is causing the 'holes' the rotation issues might be directly related although I doubt it. The foot appears to have been rotated the oposite direction. My mistake was not taking the vertex pool seriously enough. Maybe I can fiddle with the old FF8 model traversing code.


Cyb

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #60 on: 2010-01-13 02:48:02 »
I have some documentation about quads and strips pertaining to PS2 rendering, they may not help much, but I'm posting them here just in case they might be of use...

Quote from: Codeman
Synopsis
A triangle strip is a speed- and space-efficient way of storing a set of triangles on a computer, usually for computer graphics.

Detail
Take, for example, a modern graphics processor, capable of drawing millions of polygons per second. One of the major limiting factors is not the triangle-drawing ability of the processor; without triangle strips often the limiting factor is the data bus between the graphics processor and the memory storing the triangles1. Triangle strips reduce the memory bandwidth needed by a graphics processor by not transmitting redundant information. Each triangle is comprised of three separate vertices, but in many cases you can find a set of topologically connected triangles which share common edges. Triangle strips exploit this fact. So what does this mean?

Consider a simple square, which would be stored as two triangles:

0--1
| /|
|/ |
2--3
Thus, the square is made up of the triangles (0, 1, 2) and (1, 2, 3)2. A naive storage format for this square would just store both those triangles, costing 6 (2 x 3) vertices. Notice how in both of those triangles, the edge (1, 2) is specified. A triangle strip simply stores that square as (0, 1, 2, 3), where the two constituent triangles share the middle edge (1, 2). In a triangle strip of length N, there are (N-2) triangles; with each triangle being a vertex and its two previous vertices. This means the square is now stored in 4 vertices, and if we wanted to add another connected triangle (sharing edge (2,3) with triangle (1, 2, 3)) we only need to add an extra vertex:

0--1
| /|
|/ |
2--3
| /
|/
4
This is extremely space efficient; in a perfect strip each extra triangle costs us only another vertex.

If you imagine a typical polygonal mesh, for example a triangulated teapot, you can see that the majority of the triangles share edges with other triangles around them. This makes finding long strips of connected triangles relatively easy, and indeed such shapes can be stored very efficiently using strips.

Given an arbitrary polygon soup, finding the perfect set of triangle strips which represent it is a difficult problem. There is a potentially infinite number of different strips you could choose to represent an object, but for efficiency's sake the strips used must be as long as possible. In fact, this process (known as triangle stripping or sometimes stripification) in an NP complete problem. However, armed with some simple heuristics you can usually come up with a near-perfect solution. There are a number of GPL libraries around for performing stripification, including a particularly good one called Stripe.

As you've seen, strips are space-efficient; it takes less vertices to specify a mesh using strips. However, it is also speed-efficient. In rasterizing a triangle, a graphics processor has to perform a fair degree of calculations, particularly if it supports something like programmable vertex shaders. When rendering a strip, if the previous two vertices are cached, then after the first triangle has been drawn, the next only requires one extra vertex calculation.

There's another trick that can be used; normally there's a set up cost associated with starting a strip on modern graphics hardware. So reducing the total number of triangle strips is beneficial too - this can be achieved using degenerate (zero area) triangles. Given two strips, you can stitch them together by duplicating the last vertex of the first strip, and the first vertex of the second strip, and then concatenating them. Consider two separated squares:

0--1 4--5
| /| | /|
|/ | |/ |
2--3 6--7
These squares can be expressed as a single triangle strip (0, 1, 2, 3, 3, 4, 4, 5, 6, 7) with four degenerate triangles (2, 3, 3), (3, 3, 4), (3, 4, 4), (4, 4, 5). As the triangles have zero area (which is quick to detect), they usually cost very little to process, and in most circumstances these long concatenated strips are more efficient than lots of small strips3.

Any task involving large numbers of triangles can benefit from triangle stripping, for example collision detection, or ray tracing.

1.Indexing vertices and storing vertex data separately to topology information is another common way of reducing the bandwidth, which is compatible with stripping.
2.Usually triangles are stored with a consistant winding order, I ignore winding issues here for clarity. Where winding order is important (e.g. on graphics processors) note that every other triangle's winding order is opposite, and this is taken into account by the hardware.
3.Some specialist applications (e.g. the PlayStation 2's rendering system) store an extra piece of information with each vertex: whether that vertex and its previous two vertices should be considered a valid triangle. This allows an even more efficient way of stitching triangles together; you can simply concatenate strips together and ensure the first two vertices are not marked as valid triangles. For example, using an asterisk to mark valid triangles, the two squares can be expressed as (0, 1, 2*, 3*, 4, 5, 6*, 7*) using such a system.



also, as I don't think any of that mentions normals, it should be noted that most systems use clockwise vertex orientation as one type of normal (usually facing the camera) and counterclockwise numbering denoting a the other(usually reversed, with the invisible side pointed at the camera)


So most quads, being drawn as two triangles, will be half invisible. Since one triangle is drawn as

Code: [Select]
1. .2 and the next triangle being  .1(2)
3.                           2(3). .3(4)

Thus making triangle 2,3,4 counterclockwise and having an inverse normal.


Does any of that help? (If you already knew that, I apologize, I'm not trying to belittle you. I just get so few opportunities to really do anything helpful)

Vehek

  • *
  • Posts: 215
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #61 on: 2010-01-15 07:50:37 »


 :-D

I don't actually know how what I did works, but I'm now very close to proper bone rotations. Still need to fix the other issues though.

Some issues
  • Gaps in UV
  • Textures don't show up in render (Need to associate it correctly or something.)

Hmmm, I've come a long way since I started, when it had no skeleton at all and was just a clump of parts stuck together. (Those are stages which I didn't show here.)


Edit: Didn't notice that the parts of the body (noticeably the hands) were flipped. I think I've fixed it in the script now.
« Last Edit: 2010-01-15 08:59:22 by Vehek »

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #62 on: 2010-01-15 18:38:59 »


 :-D

I don't actually know how what I did works, but I'm now very close to proper bone rotations. Still need to fix the other issues though.

Some issues
  • Gaps in UV
  • Textures don't show up in render (Need to associate it correctly or something.)

Hmmm, I've come a long way since I started, when it had no skeleton at all and was just a clump of parts stuck together. (Those are stages which I didn't show here.)


Edit: Didn't notice that the parts of the body (noticeably the hands) were flipped. I think I've fixed it in the script now.

I've never liked Rinoa as much as I do in this post...

What is that black line coming out of her thigh? a bone?

Also I think you have the bones in the waist reversed; the rotation looks correct, but the bones themselves have the wrong legs weighted to them. I think after you fix that you can probably start finalizing little details... It certainly looks near completion in that image sequence.
« Last Edit: 2010-01-15 18:41:26 by Satoh »

Grimmy

  • *
  • Posts: 499
  • Join in my tarnished light.
    • View Profile
    • GrimmyGames
Re: FF8 Models, How did Qhimm rip them?
« Reply #63 on: 2010-01-16 00:33:44 »
Actually it's the arms and hands also. Depending on your purpose once you get the mesh and the UV it's easy to fix the rest.
« Last Edit: 2010-01-16 00:45:28 by Grimmy »

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #64 on: 2010-01-16 01:05:17 »

Edit: Didn't notice that the parts of the body (noticeably the hands) were flipped. I think I've fixed it in the script now.

Sorry, I misunderstood that the first time I read it... you may ignore my comment about reversed bones...

mariokart64n

  • Guest
Re: FF8 Models, How did Qhimm rip them?
« Reply #65 on: 2010-01-22 01:49:50 »
 :-o arg, we still can't get models from FF8?

I wonder, the PC game is dx8 or dx6 based?

obesebear

  • *
  • Posts: 1389
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #66 on: 2010-01-22 04:04:59 »
:-o arg, we still can't get models from FF8?

I wonder, the PC game is dx8 or dx6 based?
On the contrary, it is quite possible to get the battle models (eventhough they are somewhat twisted, it's easily fixed)  It is reportedly possible to also get the field models, but I have yet to do it or see it being done.

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #67 on: 2010-01-23 06:13:48 »
:-o arg, we still can't get models from FF8?

I wonder, the PC game is dx8 or dx6 based?
On the contrary, it is quite possible to get the battle models (eventhough they are somewhat twisted, it's easily fixed)  It is reportedly possible to also get the field models, but I have yet to do it or see it being done.

Beg pardons, but if you can get battle models, could you explain how? I've tried a few programs but most fail miserably to even run at all...

Also, this thread is currently concentrating on the field models, so far what you see here is the progress... I haven't looked around the web in depth lately, but it seems from the sites I visit, that we're the only ones actively pursuing this... or at least the only ones on a site I've ever seen...

It's entirely plausible that some tiny unknown site is off doing this very thing, but they are just that... small and unknown to me.

In the end, any information you may have is a possible benefit.


And I completely forgot MK64 was even here... I was honestly quite surprised to see him... (here anyway... there are a few other modding/3D exploration sites I see him at regularly XD )

...I really need to learn to recognize headers... one of these days I'll get something done...

obesebear

  • *
  • Posts: 1389
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #68 on: 2010-01-24 19:35:02 »
On the contrary, it is quite possible to get the battle models (eventhough they are somewhat twisted, it's easily fixed)  It is reportedly possible to also get the field models, but I have yet to do it or see it being done.

Beg pardons, but if you can get battle models, could you explain how? I've tried a few programs but most fail miserably to even run at all...

Sure, this will be the quick version though because I have a lot of stuff to get done today.

Somewhere on this site you will find a link to a program that can display the battle models.  Try searching "FF8 Models" or something similar.   The post will say something about a guy from another site having success, but his program doesn't display them 100% (they are twisted).  When you click on the link and download his program, it comes with all of the .dat battle files, so you don't even need to go through the trouble of ripping them yourself.  I think the post may have been made by Mirex... but I'm not positive.

Then you will need 3dvia to rip them from his program (he doesn't have an export function).  After you download that you will have to google a program made by a guy that I think is called Koichi Senada.   His program uses 3DSMax to convert the 3dvia format to a .max format.  And from there obviously you can convert it to anything else.

Like I said, some of them are pretty badly twisted, but with a little 3D knowledge it's a pretty easy fix.

Proof  :-D
« Last Edit: 2010-01-24 19:36:49 by obesebear »

Satoh

  • *
  • Posts: 386
  • Assuming this statement is correct, I'm alive.
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #69 on: 2010-01-24 20:57:28 »
I see... I hadn't thought about using 3dvia on kvaks...

Thanks for the heads up, I'll definitely be using that info for great justice.

obesebear

  • *
  • Posts: 1389
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #70 on: 2010-01-25 02:01:30 »
Great!  I know nothing about the battle or field models, but if they are composed the same way, you might be best off waiting for Vehek to finish since he seems to be making leaps and bounds in progress, and his viewer will undoubtedly be better than KVAKS

mariokart64n

  • Guest
Re: FF8 Models, How did Qhimm rip them?
« Reply #71 on: 2010-03-14 08:25:35 »
the models are very lowpoly.. I can't imagine it be that too hard to extract.
I think it's largely due to how old these models are.. they are outdated.. so whats the point cracking a heavily optimised/condensed format..

it just sucks that no reliable viewer has ever been made considering that FF8 is just one of those lagacy games

ohwell guess it's time to start re-modeling so of these characters right ;)

obesebear

  • *
  • Posts: 1389
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #72 on: 2010-03-14 19:32:17 »
the models are very lowpoly.. I can't imagine it be that too hard to extract.
I think it's largely due to how old these models are.. they are outdated.. so whats the point cracking a heavily optimised/condensed format..
I guess just to show we can.  All the information is there (I think) and Qhimm is supposed to be the mecha of 90's FF modding.

it just sucks that no reliable viewer has ever been made considering that FF8 is just one of those lagacy games

ohwell guess it's time to start re-modeling so of these characters right ;)
Well Vehek was making awesome progress, maybe he'll decide to take it back up.

I don't know about remodeling though... No one likes FF8 THAT much lol

Timu Sumisu

  • *
  • Posts: 1850
  • The Master
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #73 on: 2010-03-15 05:08:11 »
giving the graphics a boost could be fun if 1. there were a tool to weigh the mesh to the bones, and 2. you could completely hack the gameplay to eliminate or otherwise make drawing enjoyable. (along with a rather long list of poor gameplaymechanics plaguing ff8)


 ;D

Wutai Clan

  • *
  • Posts: 115
    • View Profile
Re: FF8 Models, How did Qhimm rip them?
« Reply #74 on: 2010-08-27 10:31:52 »
I would love to see progress made on this game, I'm one of it's few fans. :)

Here is a tool that is capable of ripping 3d data directly from games, maybe it could help you, it offers a different method of getting data. (Ie, it hooks DX, when the model is drawn, it can dump that data directly, rather than bothering with figuring out the file format.. I've used this myself, it's not perfect, but it can get the models out of otherwise undocumented game formats.)

It basically takes a 3d screenshot.

3d Ripper DX
http://www.deep-shadows.com/hax/3DRipperDX.htm
« Last Edit: 2010-08-27 11:22:26 by Wutai Clan »