First off, I completely understand why some would want to keep this a trade secret, or even a personal one. And I agree with both actually, it's best to allow people to learn it on their own so they UNDERSTAND it, than it is to spoon feed them.
However... Being that I'll never host my own server due to bandwidth and wife issues, the next best thing is to give people who WILL host servers as much help as I can so they can make the game I want to play.
**edit**
Uli's reply reminded me that I need to qualify this guide by saying it's not an absolute 100% guarenteed fix / mod for adding all structures.
**edit**
That said... Quick guide to adding a house:
#1 read and review this! I'm going to assume you have done this already, or are familiar with exporting asset tre's to include all necessary data.
#2 Pick a house.iff file to work with. all player houses are contained in objects/building/player/*
#3 Each house you add will need a deed to spawn it into the world. the deeds are found in objects/tangible/deeds/player_house_deeds/*
#4 Each house should require an .LOD file. You'll have to use treexplorer to track down this asset, it's usually stated in the POB file, which is stated in the building .iff file. Some buildings have more than one .LOD file so you need to track them all down. Export all the LOD's to a folder (I name mine housestest) and maintain the folder architecture: housetest/appearance/lod/*
#5 Edit each .LOD file and change the 0008FORM node to 0007FORM. don't forget to save the .LOD file once you've made the edit.
#6 deed. Ok first off, the deed is just an object that allows you spawn your house into the zone environment. You DON'T have to use the deed that matches the house you're trying to use. As a matter of fact, I use the same shared_naboo_small_house_deed.iff for all my structures. I just rename it and plug it into my housetest directory: object/tangible/deed/player_house_deed/mynewdeed.iff
However, if you choose to use a deed that's post 14.1, then you'll need to make sure the nodes have been renamed properly. I believe that most TCG deeds and windowed house deeds use the 0010PCNT node, and it should be 0007PCNT. And in all actuality I have not tested weather the client will load the newer 0010PCNT or not. It might work without changing it all. IMO it's always best to just use a 14.1 deed tho.
#6a there's information inside the deed you can edit if you want to change things up a bit, but it's optional. as long as you use a 14.1 deed version you don't "HAVE" to edit the file at all. but these entries can be modified:
objectName...deed..naboo_house_small_deed.XXXX...:detailedDescription...deed_detail..naboo_house_small_deed.XXXX....lookAtText......
Each sets a pointer than is looked up in a .STF file. The STF's give you the nice Readable text when you examine the deed.
#7 CRC's. In order for the server and client to work with the objects you're adding they need the proper CRC. So once again, you'll want to add a new folder to your housetest directory, called "misc". inside this folder you want to copy the latest "object_template_crc_string_table.iff" file you're using. If you've not made any modifications to this file in the past, then just pull it out of the 14.1 .tre files. Otherwise just use the one you're already modified. Add two entries:
object/building/player/(whateverhouseyouchoose.iff)
object/tangible/deed/player_house_deed/(whateveryoucalledyourdeed.iff)
Don't forget to save your crc table file.
#8 the newer NGE houses will require you to use the most recent door_style.iff file located in datatables/appearance/door_style.iff. Make sure this gets added to your housetest directory is it will need to overwrite anything provided in the 14.1 asset version.
#8a datatables/appearance/door_style.iff is needed if you want your doors to work & look proper. You can use the NGE TOC version if you wish, but you have to load it AFTER the 14.1 .tre's load. otherwise the 14.1 data will remove all the door info for the NGE structures.
#9 Take your housetest directory and pack it into a new .tre file. Let's call it housetest.tre for the sake of this example. Copy your new .tre file to your SWGEMU directory, and to the CORE3 .tre folder. Modify the SWGEMU_LIVE.cfg file to include the new .tre, modify the core3 conf to do the same, and you're now done with the .tre work
My example custom .tre to be used in the below section. Use for reference:
object/tangible/deed/player_house_deed/shared_my_house_deed.iff
object/building/player/shared_my_house.iff
appearance/lod/lodfile1.lod
appearance/lod/lodfile2.lod
datatables/appearance/door_style.iff
misc/object_template_crc_string_table.iff
#10 Time to modify your server. While the process might seem complicated or overwhelming, what's actually getting done is quite simple. You're telling the server that your new house.iff is a building object, thus creating a buildingObjectTemplate for your new house. You then refactor this Object giving it details (maint rates, required lots, child objects, etc...) as well as a new clean file name.
Setting up the house:
#11 bin/scripts/object/building/player/objects.lua
This file identifies your new building IFF file, and declares it an object template. so below I have an example of my own. object_building_player_shared_my_house is the full as is name for the object we're creating. It can be anything you want but this format works well and I would stick to it. SharedBuildingObjectTemplate:new is the type of object we're creating, new just means it's not already declared somewhere else. clientTemplateFileName = "object/building/player/shared_my_house.iff" is the path to the Iff we created in our custom .tre file. The last line is telling the server to add a new object template, and giving it the SBOT template we declared in the first section, and it's path.
Your code should model this:
object_building_player_shared_my_house = SharedBuildingObjectTemplate:new {
clientTemplateFileName = "object/building/player/shared_my_house.iff"
}
ObjectTemplates:addClientTemplate(object_building_player_shared_my_house, "object/building/player/shared_my_house.iff")
#12 bin/scripts/object/building/player/my_house.lua
this file sets up the actual object we'll load into the game. same premise as above, you're declaring the object: object_building_player_my_house as a new object_building_player_shared_my_house (which we declared earlier) but we're dropping the shared_ from the new object & file name. Inside the {} we can now set some useable values for our house object. finally the last line adds another new object template (same as step 11) but with the shortend object name and file name. see the below example:
object_building_player_my_house = object_building_player_shared_my_house:new {
lotSize = 1,
baseMaintenanceRate = 1,
allowedZones = {"naboo", "taanab"},
publicStructure = 0,
skillMods = {
{"private_medical_rating", 300},
{"private_buff_mind", 300},
{"private_med_battle_fatigue", 15}
},
childObjects = {
{templateFile = "object/tangible/terminal/terminal_elevator_up.iff", x = -4.1, z = 1.8, y = -.1, ow = 0, ox = 0, oy = 1, oz = 0, cellid = 1, containmentType = -1},
{templateFile = "object/tangible/terminal/terminal_elevator_down.iff", x = -4.1, z = 6.4, y = -.1, ow = 0, ox = 0, oy = 1, oz = 0, cellid = 1, containmentType = -1},
},
constructionMarker = "object/building/player/construction/construction_player_house_corellia_large_style_01.iff",
length = 5,
width = 7
}
ObjectTemplates:addTemplate(object_building_player_my_house, "object/building/player/my_house.iff")
Couple things, the child objects are setup within the building cells, and are different for each building. I usually remark these out to avoid any oddities, I'll explain how to manage a house without a terminal at the end of this guide. once you decide where these items should be in your new house then you can un-remark them, and try to get them to load into your new house. I've not been very successful with this part up to this point. I'm working on it tho.
#13 bin/scripts/object/building/player/server_objects.lua
open up your server_objects.lua file and add the lua file that we just created in step 12.
includeFile("building/player/my_house.lua")
Setting up the deed:
#14 bin/scripts/object/tangible/deed/player_house_deed/objects.lua
same basic premise as above with our house object. no need to reiterate it here:
object_tangible_deed_player_house_deed_shared_my_house_deed = SharedTangibleObjectTemplate:new {
clientTemplateFileName = "object/tangible/deed/player_house_deed/shared_my_house_deed.iff"
}
ObjectTemplates:addClientTemplate(object_tangible_deed_player_house_deed_shared_my_house_deed, "object/tangible/deed/player_house_deed/shared_my_house_deed.iff")
#15 bin/scripts/object/tangible/deed/player_house_deed/my_house_deed.lua
same as above, but I'd like to point out that this:
generatedObjectTemplate = "object/building/player/my_house.iff",
points to the building IFF we created in our .tre file. This basically tells the deed what it's going to spawn into the world.
object_tangible_deed_player_house_deed_my_house_deed = object_tangible_deed_player_house_deed_shared_my_house_deed:new {
templateType = STRUCTUREDEED,
placeStructureComponent = "PlaceStructureComponent",
generatedObjectTemplate = "object/building/player/my_house.iff",
}
ObjectTemplates:addTemplate(object_tangible_deed_player_house_deed_my_house_deed, "object/tangible/deed/player_house_deed/my_house_deed.iff")
#16 bin/scripts/object/tangible/deed/player_house_deed/server_objects.lua
same as above, not much going on other than telling it to load your new deed lua file.
includeFile("tangible/deed/player_house_deed/my_house_deed.lua")
This should do it. as long as your .tre data is available, and the above code is added to the lua files, you should be able to generate the deed in game and place the house no problem. I would locate where you want to put your house terminal, use the CTRL+SHIFT+G debug window to get the proper coordinates & cell name, then modify the code for the child objects above to try and add it. a Quick hint, the cell name you see in the debug window can be looked up directly in the POB file. the POB file lists the cells in order (should be easy to see when you look at the file), so you can cross reference the simple cell number to the cell name that way. I tried it and my mustafar bunker is now working 100%.
Tips:
The debug coords are in x z y format, not x y z. also, the cell number is some really long number that DOES NOT represent the cellid that your core3 scripting uses, it's just what the client uses I guess. either way you can use that long cell number to teleport into cells that you can't access because of missing elevator terminals. also, usually elevator cells are much taller than you can actually see, granting you the different levels of course.
Example for the Mustafarian bunker.
/teleport 0 0 naboo 0 123biglongcellnumber123 puts you into the main entrance level.
/teleport 0 0 naboo -26 123biglongcellnumber123 puts you into the 1st sub level floor
/teleport 0 0 naboo -33 123biglongcellnumber123 puts you into the 2nd sub level floor
you can also add or subtract from the big long number to move from cell to cell within the structure to get a decent map of what goes where. so you can change 123biglongcellnumber123 to 123biglongcellnumber122, 121, 120, etc... until you can find your z level for each floor.
terminals work fine, the trick is destroying the structure you're working on and placing a new structure after you make changes to the lua script, and restart the server. changing the scripts does not change existing objects. I'm guessing thats because player structures are persistent and save to the DB as is. Not sure if there's a structure reload command or not, but either way, the cell's do work just like they should, you just have to drop a new structure to see any new changes.
****Update for non-rendering interiors and CDT problems****
to preface this, I removed the consolidated TOC data from my latest testing to track down some specific Issues i was having. Having done this I've come across a few tid-bits that may help you out if you don't wish to use all the TOC data as a blanket fix...
If you run into a structure that doesn't render the interiors correctly, OR causes a CDT, then from I've been able to find so far it's one of the following problems:
1) You need to double check all your LOD files and make sure they've all been changed from 0008 to 0007. Door LOD's can sneak up on you if you're not paying attention. (usually causing a CDT).
2) A shader is calling an effect that's calling a pixel or vertex program that's not compatible with the pre-cu client. (Usually causing interiors not to render)
3) You're missing a shader file. (usually causing a CDT)
I solved #2 by simply taking an effect that does work, copy / renaming it to the effect that's causing the problem. As Timbab has stated in other threads, that's not the real solution, but a work around. The real solution would be to find out what psh and vsh files the effect is using, then fix those programs. that's a bit beyond my knowledge at the moment so I'm going the less effective route for the present time. it works, and I can't really tell the difference even with graphics maxed.
If you're not using the NGE TOC files as stated in the above guide, #3 above is a common problem I've run into. Tre Explorer's export file chain doesn't grab all the necessary files more times than not. I've found that to get all the necesary files I have to export the file chain on EVERY file that it exports from the original iff file chain, and then repeat the process on all the additional files. Lengthy and tedious process but it will net you all the necessary files and should avoid the CDT problem.
along those lines, if you're not using the TOC data you'll need to make sure all your door LOD's and meshes export as well. they don't export by default usually. Using the TOC data avoids this issue, HOWEVER, you will still need to make sure ANY called LOD file has been modified.
another quick pro-tip is if you do encounter a problem, and can't get your character to zone back in, and are unfortunate enough to have your server run a save routine before you can kill it, if you remove the shader folder from your .tre file you can "sometimes" get back into the game WITH the structure loaded so you can /destroystructure. I've found that most of the houses will load up just fine when the shader folder is removed entirely (or renamed to something unknown to the client & server). they look aweful but they do load. Again, this doesn't work so well if you're using the TOC data as originally stated.
-Duff
However... Being that I'll never host my own server due to bandwidth and wife issues, the next best thing is to give people who WILL host servers as much help as I can so they can make the game I want to play.
**edit**
Uli's reply reminded me that I need to qualify this guide by saying it's not an absolute 100% guarenteed fix / mod for adding all structures.
**edit**
That said... Quick guide to adding a house:
#1 read and review this! I'm going to assume you have done this already, or are familiar with exporting asset tre's to include all necessary data.
#2 Pick a house.iff file to work with. all player houses are contained in objects/building/player/*
#3 Each house you add will need a deed to spawn it into the world. the deeds are found in objects/tangible/deeds/player_house_deeds/*
#4 Each house should require an .LOD file. You'll have to use treexplorer to track down this asset, it's usually stated in the POB file, which is stated in the building .iff file. Some buildings have more than one .LOD file so you need to track them all down. Export all the LOD's to a folder (I name mine housestest) and maintain the folder architecture: housetest/appearance/lod/*
#5 Edit each .LOD file and change the 0008FORM node to 0007FORM. don't forget to save the .LOD file once you've made the edit.
#6 deed. Ok first off, the deed is just an object that allows you spawn your house into the zone environment. You DON'T have to use the deed that matches the house you're trying to use. As a matter of fact, I use the same shared_naboo_small_house_deed.iff for all my structures. I just rename it and plug it into my housetest directory: object/tangible/deed/player_house_deed/mynewdeed.iff
However, if you choose to use a deed that's post 14.1, then you'll need to make sure the nodes have been renamed properly. I believe that most TCG deeds and windowed house deeds use the 0010PCNT node, and it should be 0007PCNT. And in all actuality I have not tested weather the client will load the newer 0010PCNT or not. It might work without changing it all. IMO it's always best to just use a 14.1 deed tho.
#6a there's information inside the deed you can edit if you want to change things up a bit, but it's optional. as long as you use a 14.1 deed version you don't "HAVE" to edit the file at all. but these entries can be modified:
objectName...deed..naboo_house_small_deed.XXXX...:detailedDescription...deed_detail..naboo_house_small_deed.XXXX....lookAtText......
Each sets a pointer than is looked up in a .STF file. The STF's give you the nice Readable text when you examine the deed.
#7 CRC's. In order for the server and client to work with the objects you're adding they need the proper CRC. So once again, you'll want to add a new folder to your housetest directory, called "misc". inside this folder you want to copy the latest "object_template_crc_string_table.iff" file you're using. If you've not made any modifications to this file in the past, then just pull it out of the 14.1 .tre files. Otherwise just use the one you're already modified. Add two entries:
object/building/player/(whateverhouseyouchoose.iff)
object/tangible/deed/player_house_deed/(whateveryoucalledyourdeed.iff)
Don't forget to save your crc table file.
#8 the newer NGE houses will require you to use the most recent door_style.iff file located in datatables/appearance/door_style.iff. Make sure this gets added to your housetest directory is it will need to overwrite anything provided in the 14.1 asset version.
#8a datatables/appearance/door_style.iff is needed if you want your doors to work & look proper. You can use the NGE TOC version if you wish, but you have to load it AFTER the 14.1 .tre's load. otherwise the 14.1 data will remove all the door info for the NGE structures.
#9 Take your housetest directory and pack it into a new .tre file. Let's call it housetest.tre for the sake of this example. Copy your new .tre file to your SWGEMU directory, and to the CORE3 .tre folder. Modify the SWGEMU_LIVE.cfg file to include the new .tre, modify the core3 conf to do the same, and you're now done with the .tre work
My example custom .tre to be used in the below section. Use for reference:
object/tangible/deed/player_house_deed/shared_my_house_deed.iff
object/building/player/shared_my_house.iff
appearance/lod/lodfile1.lod
appearance/lod/lodfile2.lod
datatables/appearance/door_style.iff
misc/object_template_crc_string_table.iff
#10 Time to modify your server. While the process might seem complicated or overwhelming, what's actually getting done is quite simple. You're telling the server that your new house.iff is a building object, thus creating a buildingObjectTemplate for your new house. You then refactor this Object giving it details (maint rates, required lots, child objects, etc...) as well as a new clean file name.
Setting up the house:
#11 bin/scripts/object/building/player/objects.lua
This file identifies your new building IFF file, and declares it an object template. so below I have an example of my own. object_building_player_shared_my_house is the full as is name for the object we're creating. It can be anything you want but this format works well and I would stick to it. SharedBuildingObjectTemplate:new is the type of object we're creating, new just means it's not already declared somewhere else. clientTemplateFileName = "object/building/player/shared_my_house.iff" is the path to the Iff we created in our custom .tre file. The last line is telling the server to add a new object template, and giving it the SBOT template we declared in the first section, and it's path.
Your code should model this:
object_building_player_shared_my_house = SharedBuildingObjectTemplate:new {
clientTemplateFileName = "object/building/player/shared_my_house.iff"
}
ObjectTemplates:addClientTemplate(object_building_player_shared_my_house, "object/building/player/shared_my_house.iff")
#12 bin/scripts/object/building/player/my_house.lua
this file sets up the actual object we'll load into the game. same premise as above, you're declaring the object: object_building_player_my_house as a new object_building_player_shared_my_house (which we declared earlier) but we're dropping the shared_ from the new object & file name. Inside the {} we can now set some useable values for our house object. finally the last line adds another new object template (same as step 11) but with the shortend object name and file name. see the below example:
object_building_player_my_house = object_building_player_shared_my_house:new {
lotSize = 1,
baseMaintenanceRate = 1,
allowedZones = {"naboo", "taanab"},
publicStructure = 0,
skillMods = {
{"private_medical_rating", 300},
{"private_buff_mind", 300},
{"private_med_battle_fatigue", 15}
},
childObjects = {
{templateFile = "object/tangible/terminal/terminal_elevator_up.iff", x = -4.1, z = 1.8, y = -.1, ow = 0, ox = 0, oy = 1, oz = 0, cellid = 1, containmentType = -1},
{templateFile = "object/tangible/terminal/terminal_elevator_down.iff", x = -4.1, z = 6.4, y = -.1, ow = 0, ox = 0, oy = 1, oz = 0, cellid = 1, containmentType = -1},
},
constructionMarker = "object/building/player/construction/construction_player_house_corellia_large_style_01.iff",
length = 5,
width = 7
}
ObjectTemplates:addTemplate(object_building_player_my_house, "object/building/player/my_house.iff")
Couple things, the child objects are setup within the building cells, and are different for each building. I usually remark these out to avoid any oddities, I'll explain how to manage a house without a terminal at the end of this guide. once you decide where these items should be in your new house then you can un-remark them, and try to get them to load into your new house. I've not been very successful with this part up to this point. I'm working on it tho.
#13 bin/scripts/object/building/player/server_objects.lua
open up your server_objects.lua file and add the lua file that we just created in step 12.
includeFile("building/player/my_house.lua")
Setting up the deed:
#14 bin/scripts/object/tangible/deed/player_house_deed/objects.lua
same basic premise as above with our house object. no need to reiterate it here:
object_tangible_deed_player_house_deed_shared_my_house_deed = SharedTangibleObjectTemplate:new {
clientTemplateFileName = "object/tangible/deed/player_house_deed/shared_my_house_deed.iff"
}
ObjectTemplates:addClientTemplate(object_tangible_deed_player_house_deed_shared_my_house_deed, "object/tangible/deed/player_house_deed/shared_my_house_deed.iff")
#15 bin/scripts/object/tangible/deed/player_house_deed/my_house_deed.lua
same as above, but I'd like to point out that this:
generatedObjectTemplate = "object/building/player/my_house.iff",
points to the building IFF we created in our .tre file. This basically tells the deed what it's going to spawn into the world.
object_tangible_deed_player_house_deed_my_house_deed = object_tangible_deed_player_house_deed_shared_my_house_deed:new {
templateType = STRUCTUREDEED,
placeStructureComponent = "PlaceStructureComponent",
generatedObjectTemplate = "object/building/player/my_house.iff",
}
ObjectTemplates:addTemplate(object_tangible_deed_player_house_deed_my_house_deed, "object/tangible/deed/player_house_deed/my_house_deed.iff")
#16 bin/scripts/object/tangible/deed/player_house_deed/server_objects.lua
same as above, not much going on other than telling it to load your new deed lua file.
includeFile("tangible/deed/player_house_deed/my_house_deed.lua")
This should do it. as long as your .tre data is available, and the above code is added to the lua files, you should be able to generate the deed in game and place the house no problem. I would locate where you want to put your house terminal, use the CTRL+SHIFT+G debug window to get the proper coordinates & cell name, then modify the code for the child objects above to try and add it. a Quick hint, the cell name you see in the debug window can be looked up directly in the POB file. the POB file lists the cells in order (should be easy to see when you look at the file), so you can cross reference the simple cell number to the cell name that way. I tried it and my mustafar bunker is now working 100%.
Tips:
The debug coords are in x z y format, not x y z. also, the cell number is some really long number that DOES NOT represent the cellid that your core3 scripting uses, it's just what the client uses I guess. either way you can use that long cell number to teleport into cells that you can't access because of missing elevator terminals. also, usually elevator cells are much taller than you can actually see, granting you the different levels of course.
Example for the Mustafarian bunker.
/teleport 0 0 naboo 0 123biglongcellnumber123 puts you into the main entrance level.
/teleport 0 0 naboo -26 123biglongcellnumber123 puts you into the 1st sub level floor
/teleport 0 0 naboo -33 123biglongcellnumber123 puts you into the 2nd sub level floor
you can also add or subtract from the big long number to move from cell to cell within the structure to get a decent map of what goes where. so you can change 123biglongcellnumber123 to 123biglongcellnumber122, 121, 120, etc... until you can find your z level for each floor.
terminals work fine, the trick is destroying the structure you're working on and placing a new structure after you make changes to the lua script, and restart the server. changing the scripts does not change existing objects. I'm guessing thats because player structures are persistent and save to the DB as is. Not sure if there's a structure reload command or not, but either way, the cell's do work just like they should, you just have to drop a new structure to see any new changes.
****Update for non-rendering interiors and CDT problems****
to preface this, I removed the consolidated TOC data from my latest testing to track down some specific Issues i was having. Having done this I've come across a few tid-bits that may help you out if you don't wish to use all the TOC data as a blanket fix...
If you run into a structure that doesn't render the interiors correctly, OR causes a CDT, then from I've been able to find so far it's one of the following problems:
1) You need to double check all your LOD files and make sure they've all been changed from 0008 to 0007. Door LOD's can sneak up on you if you're not paying attention. (usually causing a CDT).
2) A shader is calling an effect that's calling a pixel or vertex program that's not compatible with the pre-cu client. (Usually causing interiors not to render)
3) You're missing a shader file. (usually causing a CDT)
I solved #2 by simply taking an effect that does work, copy / renaming it to the effect that's causing the problem. As Timbab has stated in other threads, that's not the real solution, but a work around. The real solution would be to find out what psh and vsh files the effect is using, then fix those programs. that's a bit beyond my knowledge at the moment so I'm going the less effective route for the present time. it works, and I can't really tell the difference even with graphics maxed.
If you're not using the NGE TOC files as stated in the above guide, #3 above is a common problem I've run into. Tre Explorer's export file chain doesn't grab all the necessary files more times than not. I've found that to get all the necesary files I have to export the file chain on EVERY file that it exports from the original iff file chain, and then repeat the process on all the additional files. Lengthy and tedious process but it will net you all the necessary files and should avoid the CDT problem.
along those lines, if you're not using the TOC data you'll need to make sure all your door LOD's and meshes export as well. they don't export by default usually. Using the TOC data avoids this issue, HOWEVER, you will still need to make sure ANY called LOD file has been modified.
another quick pro-tip is if you do encounter a problem, and can't get your character to zone back in, and are unfortunate enough to have your server run a save routine before you can kill it, if you remove the shader folder from your .tre file you can "sometimes" get back into the game WITH the structure loaded so you can /destroystructure. I've found that most of the houses will load up just fine when the shader folder is removed entirely (or renamed to something unknown to the client & server). they look aweful but they do load. Again, this doesn't work so well if you're using the TOC data as originally stated.
-Duff