- Site Map >
- Modding and Creation >
- Sims 2 Creation >
- Modding Discussion >
- Research & Development >
- Combining objects in one package
- Site Map >
- Modding and Creation >
- Sims 2 Creation >
- Modding Discussion >
- Research & Development >
- Combining objects in one package
Lab Assistant
#26
30th Apr 2005 at 12:03 AM
Posts: 174
Thanks: 1652 in 10 Posts
Numenor, I hope this time I got it. I’m sorry for misleading you before. First, I was only looking for a solution to the placement problem and didn’t test if the doors were working properly. Then, I forgot to test the diagonal door!
First of all, I have to say I was wrong. The names in text list 0x90 are in fact quite important to the correct functioning of the doors (as you guessed!). They are the filenames of “cObjectGraphNodes” in “cTransformNodes” in the Resource Node. Now, I opened your package in DatGen and, according to it, each slot in the Slot File points to a bone (one of the strings in list 0x90). Tweaking the package in this program and analysing the effects in SimPE I was able to identify I9 as the pointer to the bone.
So, I tried this: I added again the two strings to the Text List 0x90, as you originally did. Then, as I had done before, I imported the Slot file for the diagonal door, changed its instance number to 0x81 and changed the field 0x14 in the two object data files for the diagonal door. But now, I also changed the type I9 in the new slot file so it would point to new bones in text List 0x90. And it seems everything is working fine now. I tested both doors in game and they can be placed correctly and also open and close in the two directions.
I’m attaching the modified package so you don’t have to reproduce all the changes before testing.
First of all, I have to say I was wrong. The names in text list 0x90 are in fact quite important to the correct functioning of the doors (as you guessed!). They are the filenames of “cObjectGraphNodes” in “cTransformNodes” in the Resource Node. Now, I opened your package in DatGen and, according to it, each slot in the Slot File points to a bone (one of the strings in list 0x90). Tweaking the package in this program and analysing the effects in SimPE I was able to identify I9 as the pointer to the bone.
So, I tried this: I added again the two strings to the Text List 0x90, as you originally did. Then, as I had done before, I imported the Slot file for the diagonal door, changed its instance number to 0x81 and changed the field 0x14 in the two object data files for the diagonal door. But now, I also changed the type I9 in the new slot file so it would point to new bones in text List 0x90. And it seems everything is working fine now. I tested both doors in game and they can be placed correctly and also open and close in the two directions.
I’m attaching the modified package so you don’t have to reproduce all the changes before testing.
Attached files:
Numenor_WallWindow-Door_straight+diag.rar (17.5 KB, 14 downloads) - View custom content | ||||||||||
Size Packed Ratio Date Time Attr CRC Meth Ver ------------------------------------------------------------------------------- Numenor_WallWindow-Door_straight+diag.package 96520 17824 18% 29-04-05 23:19 .....A. C797CF41 m3b 2.9 ------------------------------------------------------------------------------- 1 96520 17824 18% |
Advertisement
#27
30th Apr 2005 at 10:53 AM
That is a great discover! In the window, there are three "route" slots in TL 0x90 (numbered 1,2 and 3), and I9 values match them, too. I wonder what is the I10, then...
#28
21st Feb 2006 at 7:29 AM
Posts: 4,403
Thanks: 10660 in 115 Posts
I know this thread is old and it was mostly about Numenor's wall-windows.
Yet, I just wanna say some similar custom contents can be packaged together even with different catelogues.
For example, terrain paint/ ground covering and tiles, I can save a set of texture... when I'm making a set...
However, seemingly, it appears that the terraint paint itself has 2 identical textr, I wonder if there's a way to reference them all back to one txtr file. They're different in name only by a interfix "_detail_" right before the suffix "_txtr".
Can there be a fake and linker txtr file that can relink either one to the another one? and how if so?
Thanks in advance..
Yet, I just wanna say some similar custom contents can be packaged together even with different catelogues.
For example, terrain paint/ ground covering and tiles, I can save a set of texture... when I'm making a set...
However, seemingly, it appears that the terraint paint itself has 2 identical textr, I wonder if there's a way to reference them all back to one txtr file. They're different in name only by a interfix "_detail_" right before the suffix "_txtr".
Can there be a fake and linker txtr file that can relink either one to the another one? and how if so?
Thanks in advance..
#29
21st Feb 2006 at 8:50 AM
Posts: 11,682
Thanks: 9680 in 11 Posts
Yes, you want to search out the thread on "repository" technique which is on MTS2 somewhere. It's how they did the Grand Trianon set.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
#30
21st Feb 2006 at 12:20 PM
Last edited by niol : 21st Feb 2006 at 1:42 PM.
Posts: 4,403
Thanks: 10660 in 115 Posts
I guess I've not got it from that tutorial well, coz I thought it can help borrow texture from another object or package.
But in this case, I've two txtr files in the same package, They have similar names with one of them has the interfix before the suffix "_txmt" The grapical contents ar identical to my eyes.
What I'm looking for is to combine the texture files into one by re-referencing links if possible.
Surely, i'm also thinking to do the repository method for some slave packages.
The file structure is like:
Directory of compressed files
floor XML
Material Definition
Object XML
Text List
and then the 2 Texture Images
I've no idea on how to apply that to it.
If possible, I guess I'd better ask that in that thread. But please, at least let me know, so I can do things accordingly.
Thanks...
Note:
1. I've already linked the object xml to the texture originally for the floor xml., it's just that there're 2 txtr files come along with the floor xml.
2. Attached is the template file, coz i want to do a pilot template to show I can do it first before I fool around with the texture or else.
Update2:
Just a brainstorm, I wonder if theLIFO reference can do a repository re-referencing in this case.
I did yet another search, but found nothing about LIFO that seems to be relevant to this usage.
But in this case, I've two txtr files in the same package, They have similar names with one of them has the interfix before the suffix "_txmt" The grapical contents ar identical to my eyes.
What I'm looking for is to combine the texture files into one by re-referencing links if possible.
Surely, i'm also thinking to do the repository method for some slave packages.
The file structure is like:
Directory of compressed files
floor XML
Material Definition
Object XML
Text List
and then the 2 Texture Images
I've no idea on how to apply that to it.
If possible, I guess I'd better ask that in that thread. But please, at least let me know, so I can do things accordingly.
Thanks...
Note:
1. I've already linked the object xml to the texture originally for the floor xml., it's just that there're 2 txtr files come along with the floor xml.
2. Attached is the template file, coz i want to do a pilot template to show I can do it first before I fool around with the texture or else.
Update2:
Just a brainstorm, I wonder if theLIFO reference can do a repository re-referencing in this case.
I did yet another search, but found nothing about LIFO that seems to be relevant to this usage.
Attached files:
Moi_98-12-10-ori-phase1-ori000-ori090-ori180-ori270-1xfade_terrainPaint_71053b19.rar (5.1 KB, 20 downloads) |
#31
21st Feb 2006 at 12:54 PM
Posts: 11,682
Thanks: 9680 in 11 Posts
Ok maybe it's different for ground textures and floors. I think you could have applied the repository technique to object textures even in the same package - using the naming guidelines for the resources. But I'll shut up now and leave it to someone more experienced in terrain to post.
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
"You can do refraction by raymarching through the depth buffer" (c. Reddeyfish 2017)
Lab Assistant
#32
3rd Mar 2006 at 11:37 PM
Posts: 203
Thanks: 10251 in 33 Posts
Ref this see http://forums.modthesims2.com/showthread.php?t=133570
I live vicariously through my Sims. This is a sad reflection on my life and theirs.
I live vicariously through my Sims. This is a sad reflection on my life and theirs.
#33
11th Mar 2006 at 11:46 PM
Last edited by niol : 11th Mar 2006 at 11:52 PM.
Reason: typos...
Posts: 4,403
Thanks: 10660 in 115 Posts
Alright, I think the LIFO re-referencing works in my case.
I basically deleted both the textures in the txtr files and linked the newly created LIFO file back to the txtr files while kicking the common texture into the LIFO file. And now, it seems both txtr files are merged in terms of the graphical data.
The resultant file seems to work well without crashing the game at least... unless I've overlooked something...
I basically deleted both the textures in the txtr files and linked the newly created LIFO file back to the txtr files while kicking the common texture into the LIFO file. And now, it seems both txtr files are merged in terms of the graphical data.
The resultant file seems to work well without crashing the game at least... unless I've overlooked something...
Who Posted
|