You are not logged in.
- Topics: Active | Unanswered
Pages: 1
#1 GTA Modding » CLEO Sources » 31-03-2008 20:12
- Aschratt
- Replies: 1
Hey!
I thought a thread where you can post some generic sources would be cool and useful.
So I start with a source to read a number out of a textfile.
Generaly it converts a string to an integer... You can modify this to get a StrToI function.
Notes: Create a file and write a number in ".." (Example: "123") it. The Source finds out the start (") and reads the number. if it founds " it returs the read numbers as an integer. If it founds an illegal character it should simply continue calculation.
// --== SCM STRING TO INT CONVERTER ==--
// ---=== (C)2008 - by Aschratt ===---
// ----==== ALL RIGHTS RESERVED ====----
// This function reads a value in ".." out of a file and returns the number as an integer
{$CLEO}
//Your Source
0050: gosub @CONVERT
//Additional Source. 10@ contains the value now.
:CONVERT
0006: 0@ = 0 //File handle
0006: 10@ = 0 //Read buffer
0006: 1@ = 0 //result
:CONVERT_START
0A9A: 0@ = openfile ".\CLEO\blah.ini" mode 0x6272 // Binary Read (TextReading only used for complete strings)
:CONVERT_LOOP_01 //Searching " for starting
0001: wait 0 ms
0A9D: readfile 0@ size 1 to 10@ // store 1 byte to the buffer
00D6: if 0
0039: 10@ == 34 // '"'
004D: jump_if_false @CONVERT_LOOP_01
:CONVERT_LOOP_02
0001: wait 0 ms
0A9D: readfile 0@ size 1 to 10@ // store 1 byte to the buffer
00D6: if 0
8039: not 10@ == 48 // '0'
004D: jump_if_false @CONVERT_CASE_0
00D6: if 0
8039: not 10@ == 49 // '1'
004D: jump_if_false @CONVERT_CASE_1
00D6: if 0
8039: not 10@ == 50 // '2'
004D: jump_if_false @CONVERT_CASE_2
00D6: if 0
8039: not 10@ == 51 // '3'
004D: jump_if_false @CONVERT_CASE_3
00D6: if 0
8039: not 10@ == 52 // '4'
004D: jump_if_false @CONVERT_CASE_4
00D6: if 0
8039: not 10@ == 53 // '5'
004D: jump_if_false @CONVERT_CASE_5
00D6: if 0
8039: not 10@ == 54 // '6'
004D: jump_if_false @CONVERT_CASE_6
00D6: if 0
8039: not 10@ == 55 // '7'
004D: jump_if_false @CONVERT_CASE_7
00D6: if 0
8039: not 10@ == 56 // '8'
004D: jump_if_false @CONVERT_CASE_8
00D6: if 0
8039: not 10@ == 57 // '9'
004D: jump_if_false @CONVERT_CASE_9
00D6: if 0
8039: not 10@ == 34 // '"'
004D: jump_if_false @CONVERT_END
0002: jump @CONVERT_LOOP_02 // illegal character -> GetNext
:CONVERT_END
0A9B: closefile 0@
0051: return
:CONVERT_CASE_0
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 0 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_1
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 1 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_2
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 2 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_3
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 3 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_4
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 4 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_5
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 5 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_6
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 6 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_7
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 7 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_8
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 8 // The number which was found
0002: jump @CONVERT_LOOP_02
:CONVERT_CASE_9
0012: 1@ *= 10 // Add one position to the end number
000A: 1@ += 9 // The number which was found
0002: jump @CONVERT_LOOP_02
#2 Re: GTA Modding » Sanny Builder / CLEO discussion » 20-11-2007 20:06
Well... For example you could create some nice text-inputs or animated text outputs...
It is not necessary, but at least you got more possibillities.
#3 Re: GTA Modding » Sanny Builder / CLEO discussion » 19-11-2007 21:32
Is there an possibillity to create substrings? If not... would it be possible to create one? Or general String-Operations would be cool (IndexOf(), LastIndexOf(), GetLength(),...) ^^
#4 Re: GTA Modding » Cutscenes » 15-11-2007 19:20
Well I found out some new things.
Everything is spawned through IFP. The IFP is related to the offset. So if you want to create an Cutscene you have to do this relative to the point (0|0|0). The time when animations are loaded is very simple handled. That's btw also the reason why those IFPs are as large! So let's try to understand what a cutscene does after it is loaded through SCM:
1st step: Loading the *.cut file. Setting the offset and loading the models. The model-section loads the model (normaly placed in models\cutscene.img) and attaches them to the IFP-Entry. Then it stores the text section to temporaray. The uncompress section uncompresses the used animations. However if it is required it also loads the rest of the sections.
2nd step: after the *.cut-file has been loaded the game parses the camerainformation from the *.dat file
3rd step: The game parses the animation and binds the animation entry to the models. Now the models are moved. Their startposition is defined as the first frame of the animation! Each animation runs from the beginning. that means unused animations got many identical frames. That means if an animation is required later as the beginning the frames until the animation entry point are the same as the first frame.
Well... You can export those IFP's with KAM's IFP IO (Still haven't yet testet ANP3. I think they must be exportet as ANPK).
If the cutscene finished the game sets 02E9 to true.
In fact all Cutscene DFFs are skinned. I haven't yet rigged an PED or tried such jokes, so I can't realy tell you more about this ^^.
However I don't think that cutscene models are defined in IDEs (although I haven't yet found any IDE Entries). I think the TXD needs to have the same name as the dff. I haven't found any coll yet. I don't think that it is required cause cutscenemodels are only used once and only in parts where you can't move through models.
I will now try to code an MaxScript for that. (Maybe I can use KAM's IFP IO as base... got to ask him. But I think I will create a new one!)
Greetings... Aschratt!
#5 Re: GTA Modding » Cutscenes » 10-11-2007 13:38
Great! I will have a look at this. 
Maybe I can find something... Even if I still belive that the actors and objects are not defined in the IFPs!
Greetz!
#6 Re: GTA Modding » Cutscenes » 09-11-2007 19:49
Well actually I haven't realy fund out much about those IFPs...
However the frames itself seem to be bone-related...
Steve once told me that there was an TXT about the structure of the IFP files... however I wasn't able to elicit him the charanimviewer source or this txt 
mmhh... maybe attach just attaches 2 animations? Maybe 2 numbers are to attach IFP entries to a 3rd number (ID). But I am not sure... have to research some stuff!
I think we still got some decoding work left...
Can you send the IFP viewer's source? (Or only the LoadFile-Function as a textfile, cause I am too lazy to install Delphi ^^).
Somehow my tool only reads the first object correctly... dunno whats wrong but I think it is somehow related to ReadString() (Used in KAMs!).
I have to spend some time with this... maybe I will find a few minutes at the weekend...
If you got some time left for me then please send me! I would pay for
#7 Re: GTA Modding » Cutscenes » 08-11-2007 18:32
Well... Your tool helped me... however I haven`t found something about IFPs (I based my reader on KAM's IFP Dump MS). But now I don't need it any more...
Well if I take a look to UNCOMPRESS it seems to parse the animations instead of uncompressing the textures.
REMOVE realy seems to remove static objects. I searched for your example. Exactly at the same coords the same object (It's the door of sweet's home) is mapped. I don't know if the coords must be exactly the same, but I think so. Maybe there is an flag or something like this in the object pool. Doesn't matter, but I think the game first looks what is mapped there and then checks if the name is the same.
PEFFECT stands for ParticleEffect. However I already tried a little bit around with 2dfx. The particle section only uses 24 characters for the particle name. maybe those unknown values are somehow related to the effects.fxp file.
The attach section sounds cool. I don't realy know how to check out where and how such things are working. Do you know which type the numbers have to be?
And do you know how the animations and models are placed? I haven't found anything in SCM yet!
----------
OT: I had russian for 4 years but I never realy understood it . Only have been to belarus time... Was just the greatest time of my life... even if I haven't understood much!
And you are right... Our beer is realy great. Maybe the only good thing on germany 
#8 GTA Modding » Cutscenes » 07-11-2007 22:07
- Aschratt
- Replies: 7
Hey there!
Finnaly I thought it is better to post this here where I hope I can find some scripters who are able to help me ^^. However I know that some great coders are here.
A few days I started to try to understand how Cutscenes work. However I reached a point where I think it will be possible to create cutscenes using a MaxScript. My target is to create such a MaxScript.
However I already talked to steve-m about this. He told me that in GTA III there were 3 lanes for the cameras, but I will come to this later.
(P.S.: I will create an post in the modding wiki when it is working correctly again)
But enought words, now I wan't to show you my findings:
General Stuff:
Cutscenes are located in the "~SA\anim\cuts.img" archive.
Each cutscene consits of 3 files: the "cutscene-data".
These files got the same name but diffrent endings:
- *.cut
- *.dat
- *.ifp
The CUT-File contains information about models, characters and placement of the cutscene. It is loaded as the first file of the cutscene-data through SCM. It is an standart TEXT-File split up into certain sections.
The DAT-File contains information about the camera lanes relative towards the offset (defined in the cutfile). It is loaded second.
The IFP-File is normally an Version 1 (ANPK, not like SA Standart ANP3... dunno if ANP3 will work!) Animation Package. However it contains the data of R*'s motion capturing and thats the reason why the animations are as big!
The CUT-File:
Section #1: INFO
info offset X Y Z end
This defines the point where the cutscene is "placed". Relative towards this point the rest of the cutscene is playing.
Example: (prolog1.cut)
info offset -1833.640015 18.857000 1060.170044 end
Section #2: MODEL
model ?, DFF-File, TXD-Entry end
The Unknown value seems to be allways 1. I don't think that this is a number of files loaded, cause first this wont make sense and second there are some models loaded twice or more times, but they also got one line per model.
The DFF-File defines the name of the model-file. the TXD-Entry seems to be an ID to an Texture of an TXD File or a whole TXD Directory. However there are sometimes only the names of TXD's and sometimes there is an number added.
Example: (prolog1.cut)
model 1, cssuitcase, cssuitcase-1 1, cssuitcase, cssuitcase-2 1, csplay, csplay 1, csstew, csstew 1, cstaxi92, cstaxi92 1, csbogman, csbogman end
Section #3: EXTRACOL
extracol ? end
This contains an Integer-value which is somehow related towards the collisionfiles. However it seems to be a counter of something.
Example: (prolog1.cut)
extracol 3 end
Section #4: TEXT
text StartTime, Length, GXT-Entry end
The StartTime is an Integer-value which defines the time relative to the cutscene start in milliseconds, when the text is displayed. The Length defines how long the GXT-Entry is displayed (in the same way). The GXT-Entry is a string which gives the standart-expression of an text in the gxt-files.
Example: (prolog1.cut)
1596,4066,PRO@01 7215,1397,MOBRING 8739,476,PRO@02 9499,811,PRO@03 10644,1389,PRO@04 12439,2718,PRO@05 end
Section #5: UNCOMPRESS
uncompress Texture end
The Texture-String defines a texture like in the model-section. These textures are DX-compressed textures which need to be uncompressed to be used by the game.
Example: (prolog1.cut)
uncompress cssuitcase-1 cssuitcase-2 csplay cstaxi92 csbogman end
Section #5: MOTION
motion range on X Y quick off Model:AnimationObject(Tag),Animation end
I don't realy know what the range is and if it is the stuff which is disabled by using quick off.
However the rest of the data is related to the IFP-AnimationPackage.
The Model is the model which is loaded. I think the IFP-Animation defines where it is placed relative to the offset. But I can't imagnine, cause I think the coords there are relative towards the pivot of the model. AnimationObject is an Index to an object in the IFP File. (Each animationtree is stored in certain "objects".) I don't realy understand what the tag means. First I have to understand how IFPs are correctly working^^. the Animation is an ID to the Object-Entry. Means it is the number of the animation in the "object".
Example: (prolog1.cut)
motion range on 540.000000 1210.000000 quick off cssuitcase:Root(tag0),6 cssuitcase 1:Root(tag0),6 csplay_x:root,5 csstew:Root,1 cstaxi92:taxi,4 csbogman_x:root,5 end
The DAT-File:
The DAT-File contains data about the camera. It is splittet into 4 Blocks:
- Block1: Rotation relative towards some kind of vector
- Block2: Zoom
- Block3: CameraPositions
- Block5: CameraTargetPoints
Let's take a shot look to the prolog1.dat
4.733000f,51.774010,51.774010,51.774010, 4.733000f,51.774010,51.774010,51.774010, 6.865999f,51.774010,51.774010,51.774010, 6.865999f,51.774010,51.774010,51.774010, 13.018999f,51.774010,51.774010,51.774010, 14.145000f,51.774010,51.774010,51.774010, 15.029999f,51.774010,51.774010,51.774010, 15.033001f,51.774010,51.774010,51.774010, 18.632999f,51.774010,51.774010,51.774010, 18.632999f,51.774010,51.774010,51.774010, 22.299999f,51.774010,51.774010,51.774010, 22.333332f,51.774010,51.774010,51.774010, ; 14, 0.000000f,0.000000,0.000000,0.000000, 0.033001f,0.000000,0.000000,0.000000, 4.733000f,0.000000,0.000000,0.000000, 4.733000f,-0.500000,-0.500000,-0.500000, 6.865999f,-0.500000,-0.500000,-0.500000, 6.865999f,0.000000,0.000000,0.000000, 13.018999f,0.000000,0.000000,0.000000, 14.145000f,0.000000,0.000000,0.000000, 15.029999f,0.000000,0.000000,0.000000, 15.033001f,0.000000,0.000000,0.000000, 18.632999f,0.000000,0.000000,0.000000, 18.632999f,0.000000,0.000000,0.000000, 22.299999f,0.000000,0.000000,0.000000, 22.333332f,0.000000,0.000000,0.000000, ; 14, 0.000000f,1.372110,-3.289650,0.348241,1.372110,-3.289650,0.348241,1.372110,-3.289650,0.348241, 0.033001f,1.374477,-3.285426,0.348313,1.373696,-3.286820,0.348289,1.485693,-3.086910,0.351664, 4.733000f,1.708157,-2.689816,0.358369,1.596942,-2.888333,0.355017,-351435712.000000,996336576.000000,195180544.000000, 4.753000f,0.566675,0.546339,0.992326,351435712.000000,-996336576.000000,-195180544.000000,0.566675,0.546339,0.992326, 6.865999f,0.566675,0.546339,0.992326,0.566675,0.546339,0.992326,0.566675,0.546339,0.992326, 6.885999f,-25.128313,43.978294,-5.243558,-25.128313,43.978294,-5.243558,-25.128313,43.978294,-5.243558, 13.018999f,-25.199257,45.274353,-5.229860,-25.199257,45.274353,-5.229860,-25.199257,45.274353,-5.229860, 14.145000f,-24.704872,45.288445,-5.390404,-24.845209,45.314960,-5.336510,-24.594572,45.267601,-5.432763, 15.029999f,-24.431650,45.152348,-5.518365,-24.522743,45.197723,-5.475703,-25.216389,43.404213,-5.411711, 15.033001f,-26.693468,40.113770,-5.210960,-25.908730,41.861904,-5.317614,-25.883440,40.723061,-5.395410, 18.632999f,-24.263140,41.941826,-5.764365,-25.073168,41.332535,-5.579916,-219697904.000000,-8866951168.000000,843817920.000000, 18.653000f,-27.117434,-73.256783,5.198439,219697840.000000,8866951168.000000,-843817920.000000,-27.893589,-73.229073,5.073773, 22.299999f,-29.458689,-73.173187,4.822388,-29.458689,-73.173187,4.822388,-29.458689,-73.173187,4.822388, 22.333332f,-29.458689,-73.173187,4.822388,-29.458689,-73.173187,4.822388,-29.458689,-73.173187,4.822388, ; 14, 0.000000f,0.355181,0.377279,0.985035,0.355181,0.377279,0.985035,0.355181,0.377279,0.985035, 0.033001f,0.354870,0.377269,0.984592,0.354973,0.377272,0.984738,0.340251,0.376828,0.963785, 4.733000f,0.311009,0.375946,0.922165,0.325628,0.376387,0.942972,81028968.000000,216780560.000000,15418848.000000, 4.753000f,0.574195,1.080061,0.972246,-81028968.000000,-216780560.000000,-15418846.000000,0.574195,1.080061,0.972246, 6.865999f,0.574195,1.080061,0.972246,0.574195,1.080061,0.972246,0.574195,1.080061,0.972246, 6.885999f,-24.415503,44.468201,-5.129688,-24.415503,44.468201,-5.129688,-24.415503,44.468201,-5.129688, 13.018999f,-24.437296,43.236435,-4.954520,-24.437296,43.236435,-4.954520,-24.437296,43.236435,-4.954520, 15.029999f,-25.544277,43.336678,-5.065734,-25.298626,43.249981,-4.968792,-25.884001,42.968060,-5.010449, 15.033001f,-26.523449,42.274227,-4.906388,-26.183725,42.642845,-4.961673,-26.846678,42.200039,-4.777145, 16.033001f,-27.493233,42.051640,-4.518620,-27.170004,42.125828,-4.647863,-27.493233,42.051640,-4.321027, 18.632999f,-26.844765,40.319283,-5.154108,-26.844765,40.319283,-5.154108,-26.844765,40.319283,-5.154108, 18.653000f,-26.181892,-71.569000,-0.250942,-26.178116,8634788864.000000,-0.250942,-26.870512,-71.541290,-0.250942, 22.299999f,-28.522501,-71.485405,-0.626076,-28.522501,-71.485405,-0.626076,-28.522501,-71.485405,-0.626076, 22.333332f,-28.522501,-71.485405,-0.626076,-28.522501,-71.485405,-0.626076,-28.522501,-71.485405,-0.626076, ; ;
Let's start in general: Each Block's end is marked by an semicolon. The eof (end of file) is marked by an additional semicolon. The first number in each Block is the number of entries in it.
Block 1 and 2 are in same structure. Now I have to tell you about those lanes. We actually don't realy know why there are 3 lanes, but they exist. However only the first lane (LANE1) is used. Easily you can set all three lanes to the same.
So you can in general see the structure for each Block like this:
1 TIME, LANE1, LANE2, LANE3 ;
The TIME is stored as single values (float) in seconds.
Block #1: Rotation
The value for each lane contains a rotation as a floating value. It is somehow related to the vector from the camera position to the target.
Block #2: Zoom
This contains information about the zoom. However this is calculated like in optical phyiscs. So negative values are zoom in and positve zoom out.
Block #3: CameraPosition
Thix contains standart floationg point values about the position of the camera relative towards the offset from the cut-file.
Block #4: CameraTargetPosition
Thix contains standart floationg point values about the position of the camera's target point relative towards the offset from the cut-file.
----------
Thanks for your free minutes! However there is still some work left. I tried around with IFPs but somehow the object names are too strange for C# :D (I can't realy read them out).
Would be cool if someone would help me and try to find senses for the unknown parts. However I also haven't realy got time to test this stuff. so if you can try a little bit around with this and report your findings please tell me!
I am sure this will be usefull for scripters. If not: It is for me :D
Greetings and Сбозиво (Is this written correctly? xDDD)... Aschratt!
Pages: 1