Cross-Project Coordination

48 posts / 0 new
Last post
worsas's picture
worsas
Developer Emeritus
Joined:
2016-01-26 12:34
Last seen:
11 months 1 week 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. :)

Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks 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.
 

Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks 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

 
Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks 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...).

worsas's picture
worsas
Developer Emeritus
Joined:
2016-01-26 12:34
Last seen:
11 months 1 week ago

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.

10Kaziem's picture
10Kaziem
Lead DeveloperDeveloperInterior Developer
Joined:
2015-12-12 23:47
Last seen:
5 months 1 week 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.

Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks 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.



 

Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks 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

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.

[Creature ID][Sound Type Index].





 

worsas's picture
worsas
Developer Emeritus
Joined:
2016-01-26 12:34
Last seen:
11 months 1 week 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.

AttachmentSizeDate
Plain text icon Translation.txt730.4 KB2016-05-06 23:00
Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks ago

In the Creature catagory, what is the difference between Fauna and Crea designations?

worsas's picture
worsas
Developer Emeritus
Joined:
2016-01-26 12:34
Last seen:
11 months 1 week 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.

Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks 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

 

worsas's picture
worsas
Developer Emeritus
Joined:
2016-01-26 12:34
Last seen:
11 months 1 week 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. blush
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.

Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks 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.

AttachmentSizeDate
File Translation_3B.ods1.77 MB2016-05-15 22:37
worsas's picture
worsas
Developer Emeritus
Joined:
2016-01-26 12:34
Last seen:
11 months 1 week ago

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.

AttachmentSizeDate
File lists.7z40.68 KB2016-05-16 12:00
worsas's picture
worsas
Developer Emeritus
Joined:
2016-01-26 12:34
Last seen:
11 months 1 week 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?

Seneca37's picture
Seneca37
Developer EmeritusDeveloperExterior DeveloperInterior DeveloperReviewer
Joined:
2015-07-05 20:55
Last seen:
2 months 4 weeks ago

Closing this topic.  This topic is now being discussed HERE.

Please start new topics for any new cross-project discussions.
 

Pages

Topic locked