So, I’m currently in the process of finalizing the PT_Data.bsa and afterwards preparing an esp with the objects of PT with some activators being turned into statics. Are we still on a page about how the new data.esm is going to be created (by auto-changing the ids based on the data-input of the textfile)?
The duplicate water layer objects that are already in TR_Data will just remain activators in the esp, I’m making. I don’t want to put effort into those objects, if they will get collapsed into the water statics of TR anyway. But there are two new waterfalls in Skyrim-Data, for example, that I will turn into statics, so they are in the right place in the new data.
I also want to point out, in case it wasn’t clear, that the PT-files will retain their filestructure and names for the time being. Our focus should be entirely on the ids in the esm right now and the objects in the bsa can be addressed later, if it must be.
If I want to change ids, am I supposed to edit the above-ods file and upload it again?
Two more things: - The abbreviation ‘Hig’ for Highrock has been critized. We could use ‘Hr’ instead or really any better abbreviation. - I propose splitting the current com-objects into ‘com’ (human-made, but not really specific to any particular race or just a general westerner asset) and ‘Glb’ ( meaning global, for terrain objects, creatures, creature spells and plants)
Using the textfile is fine, so all changes should be made to the text file. My spreadsheets are just for testing out how things will look when sorted in the CS by new IDs.
As for the PT files, I agree, our focus should be on the IDs for now. Moving the files around will not impact the player, so they can be done at a later date.
Hr instead of Hig - fine
Glb - hmm could work, I'll need to see the new ID names.
I like the ones that describe the spell, i.e. T_Const_SwiftSwim15TR. This helps the designer easily pick the correct enchantment. For enchantments that have multiple effects, maybe a “+” could be added to the end of the ID. Not clear why there are TR/SHOTN designations.
Ingredient:
Suggest removing the Ing. Just wondering if a province designation should be used here.
Misc
Not sure why all the broken bottles have the Var designation, couldn’t they all just be T_Com_Brokenbottle...
Spells
I think it would be bette if spell IDs followed the patterns used throughout.
T_[Race]_[School]_(Name)
Where [School] would be one of the following
Res = Restoration Spell
Alt = Alteration Spell
Mys = Mysticism Spell
Cnj = Conjuration Spell
Des = Destruction Spell
Ilu = Illusion Spell
Dis = Disease
Pow = Power
Ab = Ability
Not real happy with the ID containing the spell name. This causes the designer to have to look up what the spell does.
Static
There are quite a few statics that do not have new IDs. I still need to look through these better.
What is the reasoning behind the static candles? Usually all candles would be in Lights, whether they are lit or not.
Weapon
If Unique: T_[Race]_UNI_(Unique Weapon Name)
If Enchanted: T_[Race]_[Material/Usage]_(Weapon Type)_[Spell]
else T_[Race]_[Material]_(Weapon Type)_[##]
The above rules seem ok, again the usage of the spell name just makes more work for the modder.
After going through our TR_Data.esm file, I see that there are some addition sections that will need to be incorporated. They are
Scripts
Sound Generators
Sounds
These may need to be added
Character Classes
Factions
Land Textures
Regions
The following probably should be removed from TR_Data.esm and put into TR_Mainland.esm
Dialog
Dialog Responses/Info
Global Variables
NPCs
We should also setup a series of Testing Cells. I would like everything that ends up in the Data file to be in a test cell so that the items can be 1) easily checked out in-game, and 2) a place for modders to easily find items that relate to specific places (such as Nord Homes, Caves...).
I like the ones that describe the spell, i.e. T_Const_SwiftSwim15TR. This helps the designer easily pick the correct enchantment. For enchantments that have multiple effects, maybe a “+” could be added to the end of the ID. Not clear why there are TR/SHOTN designations.
The project designations were just added to enable people to keep track of what is from where. I don’t know if that designation is truly needed, though. We can probably discard it.
Suggest removing the Ing. Just wondering if a province designation should be used here.
Using Crea instead of IngCrea as a prefix for animal-related ingredients mixes them up with the creatures themselves, increasing the likeliness of id-intersection. IngCrea, IngFood etc. is a very easy way to have ingredients cleanly separated. But we could abbreviate ‘Ing’ to ‘I’, which would also free some letter space for adding a province abbreviation infront.
Not sure why all the broken bottles have the Var designation, couldn’t they all just be T_Com_Brokenbottle...
Those have the var designation because they are the new ids of the broken bottle statics from TR_Data (the broken bottle misc items will get collapsed into them). If they were to remain misc items, I’d agree that the var-designation didn’t make sense.
I think it would be bette if spell IDs followed the patterns used throughout.
T_[Race]_[School]_(Name)
Where [School] would be one of the following
Agreed. It would make the naming much more consistent without losing the main advantages of the naming scheme at hand.
Not real happy with the ID containing the spell name. This causes the designer to have to look up what the spell does.
May I request keeping it like that? Many spells have too many effects to effectly put them into the id. I’d rather have the ids consistently refer to the names of the spells rather than listing the contained effects. The name characterizes the spell and often gives a hint on the intended context. In any case you will have to check the entry anyway, as the id can barely contain all relevant information, such as duration, strength, target/self/touch, etc. having the id mention the spellschool should offer enough guidance next to the name.
What is the reasoning behind the static candles? Usually all candles would be in Lights, whether they are lit or not.
Aren’t unlit torches statics aswell? Usually, I think unlit lightsources will be in light when they are also carriable. Then again, I agree that there is a practical advantage in having these unlit candles under light, even if they can’t be carried. I don’t mind eitherway. Though, it could be changed anytime later, if need be.
The following 2 IDs to not match the above rules
T_Com_BottleWeapon_01
T_Nor_WerewolfboneDagger_01
Yes, they will be fixed.
After going through our TR_Data.esm file, I see that there are some addition sections that will need to be incorporated.
Would you mind proposing a naming scheme for these?
We should also setup a series of Testing Cells. I would like everything that ends up in the Data file to be in a test cell so that the items can be 1) easily checked out in-game, and 2) a place for modders to easily find items that relate to specific places (such as Nord Homes, Caves...).
Yes, definitely. This will be an important addition and offer developers some much-needed orientation. We should set them up as last step as soon as the data.esp as such is complete.
Unlit light sources are actually still lights in the CS. There’s a checkbox where you can show if a light is lit or not.
I also vote for having book and spell names in the ID, because while sometimes you want to find a destruction spell, a lot of times you mainly just know the name of the thing.
Does: concepts, textures, youtube vids, admin stuff e.g. PR, handbook, assets, small website things. Activity level: wildly unpredictable. Still active. Find me on Discord.
I still need to go through these better, and fully document what’s what in there. At this point I’m thinking just change the prefix to T_, but it might also be helpful to know where the scripts come from. So these are still up in the air.
Sound (SOUN)
If Creature: T_(Creature Name)_[Sound Type]
Else: T_(Sound File Name)
Sound Types (Index)
Land (0007)
Left (0000)
Moan (0004)
Right (0001)
Roar (0005)
Scream (0006)
SwimLeft (0002) could use SwimL
SwimRight (0003) could use SwimR
The index numbers are used in the Sound Gen IDs below.
Sound Gen (SNDG)
Sound Gen IDs are automatically created by the system. These will have to be updated to match the new Creature IDs.
A new version of the translation file. I changed all clothing- and spell- ids according to your suggestion. Also split up com into com and glb as discussed earlier.
Ingredients and books remain unchanged at this point. For the books, I’m not sure if we can really scram any more information into the ids, even though some kind of thematical categorization would still be nice. I also hesitate about changing the ingredient-ids. What exactly did you have in mind about them.
Sounds, scripts, classes, etc are still untouched so far. Let me know, which of these you want me to take care of.
Fauna is animals, crea anything that can’t be put into any of the other categories. One of the birds accidentally ended up in the crea-category. Still needs to be fixed.
The following items do not follow the inferred rules, or have NOT been converted to the new ID naming system. I have provided a possible new ID name for some.
Almost all of the statics you list are pointing to vanilla objects, by intention. those are just retexes that are supposed to get autoreplaced by vanilla-counterparts. So, if you come across an id without T_ at the beginning just disregard it.
T_Imp_Chapel_F_AltarCure_01 is correct. T_He_Direnni_Alembic_01 needs to be T_He_DirenniAlembic_01 (analogous with the misc objects) T_He_Direnni_Mortar_01 -> T_He_DirenniMortar_01 T_FatherOfTheNibenSHOTN → T_Bk_FatherOfTheNibenSHOTN T_AylCyr_Chest01_RandomPos is correct. i have, at some point, for clearness sake, specified that all race containers additionally need a province abbreviation. The padlocks are a very special issue. It would be better to leave the id as I had it, even if it contradicts a bit.
All the other corrections are good.
Edit: You are actually completely right about the altar. T_Imp_Chapel_F_AltarCure_01 → T_Imp_SetChapel_AltarCure_01 it needs to be. I forgot that there are different rules for the activators. And just i changed chapel to setchapel, as it should be.
Here is the spreadsheet version of the lastest translation file. Note that I have not made the changes mentioned above.
I’ve been looking at the exceptions. For instance, the Activators use a [RACE] designator almost exclusively, but there is a MW and a few Sky [PROVENCE] designators used. I can not see how to remove them, in fact there will probably be alot more added over time. I can see that a lot of effort went in to using the [RACE] designators, but if [PROVENCE] designators can be used, then I’m wondering about the Com_SetMW items. Would they be better named T_Mw_Com? The same would be true for the Com_SetCyr → Cyr_Com.
Alchemy, Armor, Clothing, and Weapon categories all use the [RACE] designators exclusively.
Misc has 1 item sky_misc_orc_goat_fur_01:T_IngCrea_GoatPelt_01 that does not fit.
Activator, Door, Light, and Static use a mix of [RACE] and [PROVENCE] designators.
I can see that a lot of effort went in to using the [RACE] designators, but if [PROVENCE] designators can be used, then I’m wondering about the Com_SetMW items. Would they be better named T_Mw_Com? The same would be true for the Com_SetCyr → Cyr_Com.
The idea behind not using [provence] for human-made structures is simply that you can access all human-made things in the same way right now, either behind com or behind one of the race-designation. On the other hand you can now exclusively find flora- fauna- and terrain-assets behind province-designations.
We could start mixing that up, but I see the danger of people not knowing for sure anymore, whether they should look for something man-made under MW or under DE then, for example. The clear definition would be muddled up and would lead to additional need of guesswork, whether something is now behind a province-designation or a race-one.
Misc has 1 item sky_misc_orc_goat_fur_01:T_IngCrea_GoatPelt_01 that does not fit.
I have turned it into an ingredient, so it’s analogous with other small pelt-objects.
Edit: I generated these textfiles some time ago to get an idea of how the result would look like in the object lists, after duplicates and vanilla ids are cropped away and everything is sorted alphabetically.
What do you guys think about adding a subforum for cross-project coordination around here? There are far more relevant topics to it than just Tamriel-Data and we are squashing it all into this tiny thread at the moment.
It would also be a good place for Anonytroll to post his maps and anything regarding his Blackmarsh stuff he’s doing.
Seneca, I think I’ll go over the translation text file once more and address the errors you pointed out aswell as a number of further errors I have come to notice. How does your esp-api go so far?
A quick overview of new and updated content can be found in your dashboard. If you are interested in our ongoing development, check out the claims browser and the asset browser.
2016-01-26 12:34
2 weeks 1 day ago
So, I’m currently in the process of finalizing the PT_Data.bsa and afterwards preparing an esp with the objects of PT with some activators being turned into statics. Are we still on a page about how the new data.esm is going to be created (by auto-changing the ids based on the data-input of the textfile)?
The duplicate water layer objects that are already in TR_Data will just remain activators in the esp, I’m making. I don’t want to put effort into those objects, if they will get collapsed into the water statics of TR anyway. But there are two new waterfalls in Skyrim-Data, for example, that I will turn into statics, so they are in the right place in the new data.
I also want to point out, in case it wasn’t clear, that the PT-files will retain their filestructure and names for the time being. Our focus should be entirely on the ids in the esm right now and the objects in the bsa can be addressed later, if it must be.
If I want to change ids, am I supposed to edit the above-ods file and upload it again?
Two more things:
- The abbreviation ‘Hig’ for Highrock has been critized. We could use ‘Hr’ instead or really any better abbreviation.
- I propose splitting the current com-objects into ‘com’ (human-made, but not really specific to any particular race or just a general westerner asset) and ‘Glb’ ( meaning global, for terrain objects, creatures, creature spells and plants)
I would be happy to hear further feedback. :)
2015-07-05 20:55
3 years 4 months ago
Using the textfile is fine, so all changes should be made to the text file. My spreadsheets are just for testing out how things will look when sorted in the CS by new IDs.
As for the PT files, I agree, our focus should be on the IDs for now. Moving the files around will not impact the player, so they can be done at a later date.
Hr instead of Hig - fine
Glb - hmm could work, I'll need to see the new ID names.
2015-07-05 20:55
3 years 4 months ago
Additional Comments
Enchantment:
I like the ones that describe the spell, i.e. T_Const_SwiftSwim15TR. This helps the designer easily pick the correct enchantment. For enchantments that have multiple effects, maybe a “+” could be added to the end of the ID. Not clear why there are TR/SHOTN designations.
Ingredient:
Suggest removing the Ing. Just wondering if a province designation should be used here.
Misc
Not sure why all the broken bottles have the Var designation, couldn’t they all just be T_Com_Brokenbottle...
Spells
I think it would be bette if spell IDs followed the patterns used throughout.
T_[Race]_[School]_(Name)
Where [School] would be one of the following
Res = Restoration Spell
Alt = Alteration Spell
Mys = Mysticism Spell
Cnj = Conjuration Spell
Des = Destruction Spell
Ilu = Illusion Spell
Dis = Disease
Pow = Power
Ab = Ability
Not real happy with the ID containing the spell name. This causes the designer to have to look up what the spell does.
Static
There are quite a few statics that do not have new IDs. I still need to look through these better.
What is the reasoning behind the static candles? Usually all candles would be in Lights, whether they are lit or not.
Weapon
If Unique: T_[Race]_UNI_(Unique Weapon Name)
If Enchanted: T_[Race]_[Material/Usage]_(Weapon Type)_[Spell]
else T_[Race]_[Material]_(Weapon Type)_[##]
The above rules seem ok, again the usage of the spell name just makes more work for the modder.
The following 2 IDs to not match the above rules
T_Com_BottleWeapon_01
T_Nor_WerewolfboneDagger_01
2015-07-05 20:55
3 years 4 months ago
After going through our TR_Data.esm file, I see that there are some addition sections that will need to be incorporated. They are
Scripts
Sound Generators
Sounds
These may need to be added
Character Classes
Factions
Land Textures
Regions
The following probably should be removed from TR_Data.esm and put into TR_Mainland.esm
Dialog
Dialog Responses/Info
Global Variables
NPCs
We should also setup a series of Testing Cells. I would like everything that ends up in the Data file to be in a test cell so that the items can be 1) easily checked out in-game, and 2) a place for modders to easily find items that relate to specific places (such as Nord Homes, Caves...).
2016-01-26 12:34
2 weeks 1 day ago
The project designations were just added to enable people to keep track of what is from where. I don’t know if that designation is truly needed, though. We can probably discard it.
Using Crea instead of IngCrea as a prefix for animal-related ingredients mixes them up with the creatures themselves, increasing the likeliness of id-intersection. IngCrea, IngFood etc. is a very easy way to have ingredients cleanly separated. But we could abbreviate ‘Ing’ to ‘I’, which would also free some letter space for adding a province abbreviation infront.
Those have the var designation because they are the new ids of the broken bottle statics from TR_Data (the broken bottle misc items will get collapsed into them). If they were to remain misc items, I’d agree that the var-designation didn’t make sense.
Agreed. It would make the naming much more consistent without losing the main advantages of the naming scheme at hand.
May I request keeping it like that? Many spells have too many effects to effectly put them into the id. I’d rather have the ids consistently refer to the names of the spells rather than listing the contained effects. The name characterizes the spell and often gives a hint on the intended context. In any case you will have to check the entry anyway, as the id can barely contain all relevant information, such as duration, strength, target/self/touch, etc. having the id mention the spellschool should offer enough guidance next to the name.
Aren’t unlit torches statics aswell? Usually, I think unlit lightsources will be in light when they are also carriable. Then again, I agree that there is a practical advantage in having these unlit candles under light, even if they can’t be carried. I don’t mind eitherway. Though, it could be changed anytime later, if need be.
Yes, they will be fixed.
Would you mind proposing a naming scheme for these?
Yes, definitely. This will be an important addition and offer developers some much-needed orientation. We should set them up as last step as soon as the data.esp as such is complete.
2015-12-12 23:47
2 years 7 months ago
A few notes:
Unlit light sources are actually still lights in the CS. There’s a checkbox where you can show if a light is lit or not.
I also vote for having book and spell names in the ID, because while sometimes you want to find a destruction spell, a lot of times you mainly just know the name of the thing.
Does: concepts, textures, youtube vids, admin stuff e.g. PR, handbook, assets, small website things. Activity level: wildly unpredictable. Still active. Find me on Discord.
2015-07-05 20:55
3 years 4 months ago
I have to agree with W, on the spells/enchantments etc.... Most have multiple effects and therefore would still require the developer to look it up.
One thought, is to list all the spells (and their effects) on a Uesp.wiki page. At least then, the designer would have an easy to look at list.
2015-07-05 20:55
3 years 4 months ago
Scripts (SCPT)
I still need to go through these better, and fully document what’s what in there. At this point I’m thinking just change the prefix to T_, but it might also be helpful to know where the scripts come from. So these are still up in the air.
Sound (SOUN)
If Creature: T_(Creature Name)_[Sound Type]
Else: T_(Sound File Name)
Sound Types (Index)
Land (0007)
Left (0000)
Moan (0004)
Right (0001)
Roar (0005)
Scream (0006)
SwimLeft (0002) could use SwimL
SwimRight (0003) could use SwimR
Sound Gen (SNDG)
Sound Gen IDs are automatically created by the system. These will have to be updated to match the new Creature IDs.
[Creature ID][Sound Type Index].
2016-01-26 12:34
2 weeks 1 day ago
A new version of the translation file. I changed all clothing- and spell- ids according to your suggestion. Also split up com into com and glb as discussed earlier.
Ingredients and books remain unchanged at this point. For the books, I’m not sure if we can really scram any more information into the ids, even though some kind of thematical categorization would still be nice. I also hesitate about changing the ingredient-ids. What exactly did you have in mind about them.
Sounds, scripts, classes, etc are still untouched so far. Let me know, which of these you want me to take care of.
2015-07-05 20:55
3 years 4 months ago
In the Creature catagory, what is the difference between Fauna and Crea designations?
2016-01-26 12:34
2 weeks 1 day ago
Fauna is animals, crea anything that can’t be put into any of the other categories. One of the birds accidentally ended up in the crea-category. Still needs to be fixed.
2015-07-05 20:55
3 years 4 months ago
Problems
The following items do not follow the inferred rules, or have NOT been converted to the new ID naming system. I have provided a possible new ID name for some.
Activator
pc_furn_imp_altar_cure_01:T_Imp_Chapel_F_AltarCure_01
Apparatus (Note: If these are considered ok, then the TR items and the rule needs to be fixed)
sky_apparatus_dirennialembic_01:T_He_Direnni_Alembic_01
sky_apparatus_dirennimortar_01:T_He_Direnni_Mortar_01
Books
sky_bk_iv_fatheroftheniben:T_FatherOfTheNibenSHOTN
Containers
ssky_contain_corpse_01:contain_corpse00
sky_contain_corpse_02:contain_corpse10
sky_contain_corpse_02_c:contain_corpse10
sky_contain_corpse_03:contain_corpse20
sky_contain_drawers_02_01:de_drawers_02
sky_chest_02_03_empty:de_p_chest_02
sky_chest_03_03_empty:de_p_chest_02
sky_contain_chest_02_03:de_p_chest_02
sky_chest_02_03_loot_01:de_p_chest_02_pos3
Sky_Contain_Closet_02_02:de_p_closet_02
sky_contain_desk_02_01:de_p_desk_01
pc_contain_ar_chest_01:T_AylCyr_Chest01_RandomPos
Creatures
tr_cr_parastylus_vendis:T_Mw_Fauna_ParastylusVenomDis01
New ID: T_Mw_Fauna_ParastylusVenDis_01
Doors
sky_in_altmer_padlock_01_x1:T_He_DngDirenni_Padlock_01x1
New ID: T_He_DngDirenni_Padlockx1_01
sky_in_altmer_padlock_02_x2:T_He_DngDirenni_Padlock_02x2
New ID: T_He_DngDirenni_Padlockx2_01
Lights
sky_logpile_01_256:light_logpile10
tr_light_de_lantern_15_128:T_De_Set_SetInd_Lantern01_128
New ID: T_De_SetInd_Lantern01_128
Misc
sky_misc_wooden_cup_01_01:misc_com_wood_cup_01
sky_misc_wooden_cup_01_02:misc_com_wood_cup_01
Static
sky_ex_exit_cave_ice_01_01 bm_ex_ice_exit03_ice
sky_ex_exit_cave_ice_01_02 bm_ex_ice_exit03_ice
sky_ex_exit_cave_snow_01_01 bm_ex_ice_exit03_snow
sky_ex_exit_cave_snow_01_02 bm_ex_ice_exit03_snow
sky_ex_exit_cave_snow_02_01 bm_ex_ice_exit03_snow
sky_ex_exit_cave_snow_02_02 bm_ex_ice_exit03_snow
sky_ex_exit_cave_snow_03_01 bm_ex_ice_exit03_snow
sky_ex_exit_cave_snow_03_02 bm_ex_ice_exit03_snow
sky_ex_exit_cave_snow_04_01 bm_ex_ice_exit03_snow
sky_ex_exit_cave_snow_04_02 bm_ex_ice_exit03_snow
sky_ex_iceberg_01 bm_ex_iceberg
sky_ex_iceberg_collapsed_01 bm_ex_iceberg_collapsed
sky_ex_iceberg_shard_01 bm_ex_iceberg_shard01
sky_ex_iceberg_shard_02 bm_ex_iceberg_shard02
sky_ex_ice_castle_01 bm_ex_karstaag
sky_ex_nord_foodhut_01 Ex_S_FoodHut
sky_ex_snow_drift_01_01 ex_Snow_drift
sky_ex_snow_ledge_01_01 ex_snow_ledge
sky_ex_snow_roof_01_01 ex_snow_roof
sky_furn_anvil_01 furn_anvil00
sky_furn_cauldron_01_01 furn_com_cauldron_02
sky_furn_table_01_03 furn_com_r_table_01
sky_furn_table_02_03 furn_com_r_table_01
sky_furn_ex_bench_02_01 furn_de_ex_bench_01
sky_furn_ex_stool_02_01 furn_de_ex_stool_02
sky_furn_ex_table_01_01 furn_de_ex_table_02
sky_furn_ex_table_02_01 furn_de_ex_table_02
sky_furn_ex_table_01_02 furn_de_ex_table_03
sky_furn_ex_table_02_02 furn_de_ex_table_03
sky_furn_bench_01_05 furn_de_p_bench_03
sky_furn_bench_02_05 furn_de_p_bench_03
sky_furn_bench_01_06 furn_de_p_bench_04
sky_furn_bench_02_06 furn_de_p_bench_04
sky_furn_table_01_02 furn_de_p_table_06
sky_furn_table_02_02 furn_de_p_table_06
sky_furn_bench_01_03 furn_de_r_bench_01
sky_furn_bench_02_03 furn_de_r_bench_01
sky_furn_bench_01_04 furn_de_r_bench_02
sky_furn_bench_02_04 furn_de_r_bench_02
sky_furn_table_01_01 furn_de_table10
sky_furn_table_02_01 furn_de_table10
sky_furn_rail_broke_01 furn_rail_broke00
sky_furn_rail_cart_01 furn_rail_cart00
sky_furn_rail_elbow_01 furn_rail_elbow00
sky_furn_rail_end_01 furn_rail_end00
sky_furn_rail_slope_01 furn_rail_slope00
sky_furn_rail_straight_01 furn_rail_straight00
sky_terrain_ice_01 Terrain_BM_ice_01
sky_terrain_ice_02 Terrain_BM_ice_02
sky_terrain_ice_03 Terrain_BM_ice_03
sky_terrain_ice_04 Terrain_BM_ice_04
sky_terrain_ice_05 Terrain_BM_ice_05
sky_terrain_ice_06 Terrain_BM_ice_06
sky_terrain_ice_07 Terrain_BM_ice_07
sky_terrain_ice_08 Terrain_BM_ice_08
sky_terrain_ice_09 Terrain_BM_ice_09
sky_terrain_ice_10 Terrain_BM_ice_10
sky_terrain_ice_chunk_01 Terrain_BM_icechunk_01
sky_terrain_ice_chunk_02 Terrain_BM_icechunk_02
sky_terrain_ice_chunk_04 Terrain_BM_icechunk_04
sky_terrain_ice_chunk_05 Terrain_BM_icechunk_05
sky_terrain_ice_chunk_06 Terrain_BM_icechunk_06
sky_terrain_ice_chunk_07 Terrain_BM_icechunk_07
sky_terrain_ice_chunk_08 Terrain_BM_icechunk_08
sky_terrain_snow_01_01 Terrain_BM_snow_01
sky_terrain_snow_02_01 Terrain_BM_snow_01
sky_terrain_snow_01_02 Terrain_BM_snow_02
sky_terrain_snow_02_02 Terrain_BM_snow_02
sky_terrain_snow_01_03 Terrain_BM_snow_03
sky_terrain_snow_02_03 Terrain_BM_snow_03
sky_terrain_snow_01_04 Terrain_BM_snow_04
sky_terrain_snow_02_04 Terrain_BM_snow_04
sky_terrain_snow_01_05 Terrain_BM_snow_05
sky_terrain_snow_02_05 Terrain_BM_snow_05
sky_terrain_snow_01_06 Terrain_BM_snow_06
sky_terrain_snow_02_06 Terrain_BM_snow_06
sky_terrain_snow_01_07 Terrain_BM_snow_07
sky_terrain_snow_02_07 Terrain_BM_snow_07
sky_terrain_snow_01_08 Terrain_BM_snow_08
sky_terrain_snow_02_08 Terrain_BM_snow_08
sky_terrain_snow_01_09 Terrain_BM_snow_09
sky_terrain_snow_02_09 Terrain_BM_snow_09
sky_terrain_snow_01_10 Terrain_BM_snow_10
sky_terrain_snow_02_10 Terrain_BM_snow_10
I’ll have more comments in a couple of days
2016-01-26 12:34
2 weeks 1 day ago
Almost all of the statics you list are pointing to vanilla objects, by intention. those are just retexes that are supposed to get autoreplaced by vanilla-counterparts. So, if you come across an id without T_ at the beginning just disregard it.
T_Imp_Chapel_F_AltarCure_01 is correct.T_He_Direnni_Alembic_01 needs to be T_He_DirenniAlembic_01 (analogous with the misc objects)
T_He_Direnni_Mortar_01 -> T_He_DirenniMortar_01
T_FatherOfTheNibenSHOTN → T_Bk_FatherOfTheNibenSHOTN
T_AylCyr_Chest01_RandomPos is correct. i have, at some point, for clearness sake, specified that all race containers additionally need a province abbreviation.
The padlocks are a very special issue. It would be better to leave the id as I had it, even if it contradicts a bit.
All the other corrections are good.
Edit: You are actually completely right about the altar.
T_Imp_Chapel_F_AltarCure_01 → T_Imp_SetChapel_AltarCure_01 it needs to be. I forgot that there are different rules for the activators. And just i changed chapel to setchapel, as it should be.
2015-07-05 20:55
3 years 4 months ago
Here is the spreadsheet version of the lastest translation file. Note that I have not made the changes mentioned above.
I’ve been looking at the exceptions. For instance, the Activators use a [RACE] designator almost exclusively, but there is a MW and a few Sky [PROVENCE] designators used. I can not see how to remove them, in fact there will probably be alot more added over time. I can see that a lot of effort went in to using the [RACE] designators, but if [PROVENCE] designators can be used, then I’m wondering about the Com_SetMW items. Would they be better named T_Mw_Com? The same would be true for the Com_SetCyr → Cyr_Com.
Alchemy, Armor, Clothing, and Weapon categories all use the [RACE] designators exclusively.
Misc has 1 item sky_misc_orc_goat_fur_01:T_IngCrea_GoatPelt_01 that does not fit.
Activator, Door, Light, and Static use a mix of [RACE] and [PROVENCE] designators.
2016-01-26 12:34
2 weeks 1 day ago
The idea behind not using [provence] for human-made structures is simply that you can access all human-made things in the same way right now, either behind com or behind one of the race-designation. On the other hand you can now exclusively find flora- fauna- and terrain-assets behind province-designations.
We could start mixing that up, but I see the danger of people not knowing for sure anymore, whether they should look for something man-made under MW or under DE then, for example. The clear definition would be muddled up and would lead to additional need of guesswork, whether something is now behind a province-designation or a race-one.
I have turned it into an ingredient, so it’s analogous with other small pelt-objects.
Edit:
I generated these textfiles some time ago to get an idea of how the result would look like in the object lists, after duplicates and vanilla ids are cropped away and everything is sorted alphabetically.
2016-01-26 12:34
2 weeks 1 day ago
What do you guys think about adding a subforum for cross-project coordination around here? There are far more relevant topics to it than just Tamriel-Data and we are squashing it all into this tiny thread at the moment.
It would also be a good place for Anonytroll to post his maps and anything regarding his Blackmarsh stuff he’s doing.
Seneca, I think I’ll go over the translation text file once more and address the errors you pointed out aswell as a number of further errors I have come to notice. How does your esp-api go so far?
2015-07-05 20:55
3 years 4 months ago
Closing this topic. This topic is now being discussed HERE.
Please start new topics for any new cross-project discussions.
Pages