Cross-Project Coordination

48 posts / 0 new
Last post
Infragris's picture
Infragris
Interior Developer
Joined:
2016-01-17 14:03
Last seen:
5 months 2 weeks ago

Hello TR,



I thought it would be finally time to step forth and ask for your opinion on a few things regarding resource-sharing and establishing more consistency between TR and the projects hosted at project-tamriel.



At the moment we are discussing a common Tamriel-Data for S:HOTN and P:C that will either by dependency or by merging include all of the objects in TR_Data.



You can read up on the respective discussion here:

http://project-tamriel.com/viewtopic.php?f=67&t=451



In extension, I thought. it could make sense to speak about a common set of general design directions and lore with TR. Our mods are designed to fit into the same worldspace with Tamriel Rebuilt, so it would only make sense to make it fit together in all other respect.



As there has been some resource-exchange with TR in the recent time, I hope that TR is interested in making our projects consistent with each other, too. In particular, I would like to promote some of our Cyrodiil-lore, as I believe it might hold up to TR's high standards. You can read up on some of it in the following links (I hope, Infragris will not choke me for this):



http://project-tamriel.com/viewtopic.php?f=144&t=318

http://project-tamriel.com/viewtopic.php?f=144&t=194

http://project-tamriel.com/viewtopic.php?f=144&t=329

http://project-tamriel.com/viewtopic.php?f=11&t=382

http://project-tamriel.com/viewforum.php?f=142



Also, much of the internal lore established at TR, will probably have implications on the other provinces. If we know about these things, we can stick to them, over there aswell. This can go from meta stuff all the way down to trivial thingsl like plants. For example, I remember Sload militating against the Nirn Root as a plant? If TR's version of Tamriel, for whatever reason, omits things like these, we should do the same thing over there, of course.



Lastly, we have updated some of the imperial-related assets from TR_Data, like the Colovian Bread and the wines, which is also something that TR might be interested in. At the very least, we could try to have a set of common trade goods that are consistent across the provinces.

More discussion on the subject can be found here

Not's picture
Not
Developer EmeritusInterior DeveloperQuest Developer
Joined:
2015-12-18 12:06
Last seen:
3 years 1 month ago

Well, that IS a lot of threads to comb through, but I’ll see what I can do. As I’ve mentioned earlier on the old forums, I do like the idea of having one data file for all province mods. We’ll do our best to cooperate on that front and help you guys out, although I have no idea who’s going to be the sorry soul to sift thrugh everything and make sure everything is fine with the other province mods (so not looking forward to that.)

As for Nirnroot…..I THINK Sload mentioned it because it shouldn’t be found in Morrowind…? So maybe it’d still be okay to find in other provinces….? I don’t know, don’t quote me on that, I really have no idea. As for trade goods and whatnot, I think we definitely need to keep on top of that so they feel like one big landmass mod instead of multiple ones.

Incidentally, what are your stances on factions? I ask because if you guys are doing something along the lines of “The Skyrim Guild of Mages” or something, then I think we should comply and do “The Morrowind Guild of Mages” (just a rough example.)

I will check out the threads in my spare time and offer my input. I must say I’m definitely looking forward to working more closely with the other provinces and will give input from TR’s end as soon as I can :)

Not another memory

Biboran's picture
Biboran
Joined:
2016-01-23 11:05
Last seen:
6 years 4 months ago

I have always been for the that the projects need to unite and mora coordination!

Infragris's picture
Infragris
Interior Developer
Joined:
2016-01-17 14:03
Last seen:
5 months 2 weeks ago

worsas is looking into the viability of a common data set, or at least the best way of making files availible for multiple projects. We have a decent pile of generic objects, like colored candles, silks, wool, generic ingredients, … that should make a basic common data set worthwhile. I’m also reminded of some expansions to vanilla tilesets, like the common interiors, that are used in almost every province. The subject of Imperial resources also came up in the Third Empire thread, a while back. But, as you said, it’s a daunting project.

I’m also unsure of what the nirnroot problem is? We will probably implement it for Cyrodiil as just another random plant/ingredient, without any associated quests.

We’re not messing with faction names, just “Mages Guild, Fighters Guild, etc.” Most of these can be explained as provincial branches or franchises, so it makes sense for rank progression to not carry over between provinces. This is a lot easier for other province mods, since they don’t have to account for Vvardenfell technically being a part of Morrowind. 

 

One specific matter: TR currently has a number of imported Imperial wines in its database. I believe one or two of them even play part in a minor quest somewhere. P:C has its own set of Colovian wine resources. I was wondering if you would be willing to adopt these, as they have (imho) an imporved mesh and texture quality. This would also require some dialogue tweaking, I think. I’ve included the relevant stuff in the attachment below.

AttachmentSizeDate
File PC_Wines.7z223.48 KB2016-03-03 00:43
Seneca37's picture
Seneca37
Developer EmeritusExterior DeveloperInterior Developer
Joined:
2015-07-05 20:55
Last seen:
3 years 11 months ago

This was discussed before. http://tamriel-rebuilt.org/old_forum/viewtopic.php?t=25052

Unfortunately there is a lot to be considered, planned for, and work to do in order to implement this.

If Worsas has the time, I’d be willing to work with him on this.

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

We could work on this common data files slowly but piece by piece. At first we need a clear naming convention for the new ids. An then make lists which of the old objects become what in the new data. Identical objects from the various data files should get merged and objects that would fit into thematical groups, should be grouped together. Here is what I wrote on a possible naming scheme at the PT-board when there weren’t plans to do a common data files with TR yet:

Edit : See further below

Gnomey's picture
Gnomey
Asset DeveloperWriterExterior DeveloperInterior Developer
Joined:
2015-08-10 20:50
Last seen:
2 weeks 5 days ago

Right, while it’s certainly taken me long enough I’ll be getting around to properly replying to this again.

Already working on basic preparation for the eventual common data file sounds like a good plan. Your suggestion for IDs looks pretty good to me, but I’ll have to take another look tomorrow.

The differences in graphics are still worth keeping in mind; we use lower resolution textures and vanilla bodies, so textures and body parts will probably need to be kept separate in some way, though there are plenty of possible solutions there. Again, we will create low-resolution textures for any PT models we’re planning to use, and will hopefully provide high resolution alternative textures for our assets, or at worst you’ll have to make them for any of our assets you’re planning to use, which again is no worse than the current situation.

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

A few details on this data merge:

- We will use a common esm-file.

- We should probably use two bsa-files: TR_Data.bsa and PT_Data.bsa. Reason: TR modders only need to download PT_Data.bsa once and can otherwise stick with downloading updated TR_Data.bsa, resulting in less download size. Two bsas seem like a good tradeoff between too many bsas to register in your morrowind.ini and having to download an excessiely large bsa on each update. It might also prevent potential hashmap-collisions in the bsa. At the moment SHOTN and P:C use separate bsas, after this merge they wouldn't.

Problem:  Long, difficult-to-navigate statics- and container-list in the common esm-file.

Using the naming scheme quoted in my above-post would soften this issue, by grouping furn- ex- and in- assets of a thematical group (eg. dwemer assets) in a single place, so you won’t have to scroll between in, furn and ex anymore while you are dealing with this particular thematical group. I still think it’s a good solution to the statics- and container-list-navigation-problem.

However, if we use that naming scheme. there will be a further detail to settle on: Should TR- and PT-assets get grouped under a common prefix (just using T_ infront of all ids would be one possibility) or will PT_ and TR_ remain two separate prefixes? The first approach would offer the advantage that many common-purpose objects would not have to be separately searched for under the prefix of the other project. You would only have to scroll to a candles-group, for example, and you would have all candles that exist right there.

The second approach, opposedly, would make it more easy for TR to keep their own versions of objects separate they wish to be different from the versions from PT_Data. That said, I would like to prevent the situation that TR wants to use an object from PT_Data but feels the need to retexture it for its own purposes. I'd personally rather find a good middle ground for assets like the nordic wooden kitchenware that would be usable for both projects. Though, it's not like I necessarily want to enforce the common prefix. I just think that separate versions could be circumvented, in many cases. There are many assets I would rather see tweaked to look less offstyle and I don't necessarily see the solution in just downsampling textures.

The most radical way, I see for these data files, would be to put all objects ever used by TR and PT under a single prefix and naming scheme, including vanilla assets, in a way that our assets would seamlessly continue the vanilla objects in the statics-list. Like that everything could be found in the same way. Though, it would require stuff like armor-rebalancing mods to be patched to affect our vanilla duplicates. That would be a considerable drawback. The way I see it TR will probably not want to take this radical route, although it would be the cleanest solution to the navigation-problem by entirely doing away with assets needed to look for under a different prefix and categorization.

In any case, vanilla assets would remain in their bsas, likewise TR- and PT- assets.

Some feedback would be appreciated. What do you all think?

Seneca37's picture
Seneca37
Developer EmeritusExterior DeveloperInterior Developer
Joined:
2015-07-05 20:55
Last seen:
3 years 11 months ago

I’ll have some feed back in the next day or two.

Oh, and glad to see you’ve got some free time to work on this. I know that this will be a huge undertaking for all involved, but I do agree that, in the long-run, this will be beneficial to developers, modders and players.

Gnomey's picture
Gnomey
Asset DeveloperWriterExterior DeveloperInterior Developer
Joined:
2015-08-10 20:50
Last seen:
2 weeks 5 days ago

Right, so let’s try your naming scheme with a few TR examples:

TR_ex_dres_pl_01 → T_Mor_Dres_X_PlatLarge_01 (prefix=T_category=Morrowind_set name/additional category=Dres_static set suffix=X_object name=PlatformLarge_counter=01)

Saltstrap core: T_Mor_FloraDP_SaltstrapCore_01 (prefix=T_category=Morrowind_object type and region=FloraDeshaanPlains_object name=SaltstrapCore_counter=01)

This naming scheme would work for me, at any rate; as a developer it will naturally take a bit of getting used to, but that shouldn’t take too long as the structure of the names is pretty clear and logical. It also doesn’t seem too hard to figure out what ID a given object should get.

 

My first inclination would be to aim for a common prefix. I think it’s more likely our developers will think to use each others’ assets that way, naturally where appropriate. Using ‘T’ as the prefix is one possibility, but I wouldn’t be against using PT as the prefix either. Really, the main thing I consider here is the saturation of vanilla IDs starting with the same letter, assuming we’ll be keeping the vanilla IDs. It’s always bothered me a little that TR statics shared real estate with terrain statics, as that often resulted in more scrolling. PT would share real estate with picks, probes, potions and little else, and so may be preferable. This is a very minor concern, though.

 

I’m less enthusiastic about the idea of renaming vanilla objects to fit the naming scheme for two reasons: I’ve personally memorized and gotten used to the position of the majority of vanilla object IDs by now, so having them repositioned would disorient me personally for a good while, however logical the new naming scheme may be. That’s a minor inconvenience, however, and a personal one, so not overly important. The greater concern for me would be the practicailty of doing so and the issues it might create. That is something I don’t really feel equipped to properly assess though, so I’d tend to defer to the opinions of those I consider more qualified to provide them. (For this project probably Seneca first and foremost).

 

Just to be clear on what I was suggesting for textures, I was basically suggesting a texture replacer. Let’s say we make the PT textures the default textures. If we feel any PT objects we’re planning to use would look out of place among our assets, we would (as we have been doing so far) provide alternative textures, which could be in their own zip folder or a separate download or whatever. As I said we might also provide high-resolution textures for our own stuff, in which case, for the purposes of the unified data file, those textures would be the default textures. I’m not suggesting doubling objects in the actual data files, which I think would be counterproductive and cluttered.

I’d be perfectly fine with trying to aim for unified visuals, but that will probably require a lot of coordination (not bad, just means another thing to sink energy into) and I’m concerned it might end up holding PT’s visuals back.

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

TR_ex_dres_pl_01 → T_Mor_Dres_X_PlatLarge_01 (prefix=T_category=Morrowind_set name/additional category=Dres_static set suffix=X_object name=PlatformLarge_counter=01)

Saltstrap (link is external) core: T_Mor_FloraDP_SaltstrapCore_01 (prefix=T_category=Morrowind_object type and region=FloraDeshaanPlains_object name=SaltstrapCore_counter=01)

The Saltstrap-Example is correct, assuming that ‘Mor’ is used as abbreviation for Morrowind. I would prefer ‘Mw’. It feels more intuitive and would leave a bit more space in the id.

The Dres-object, however, would be named T_De_Dres_X_PlatLarge_01. The province abbreviation is usually only used for flora and terrain-objects. Anything mer/man-made happens under the prefix of the respective race or under Com, if it is a very unspecific asset.

The exceptions from this rule would only be things like province-specific, generic containers like barrels and sacks or retexes of imperial fortresses that are province-specific. I even wonder, if it made sense to switch the order for these and put the race-abbreviation or com infront of the province-abbreviation, in order to have human-made things found in a more consistent manner. The details of the naming scheme are surely up for discussion and can be altered at need.

I would favour T_ as abbreviation, purely for the reason that it would give us a further letter left for the rest of the id. We only have 32 letters, including the invisible end-character, so practically only 31 letters to make ids.

10Kaziem's picture
10Kaziem
Asset DeveloperInterior Developer
Joined:
2015-12-12 23:47
Last seen:
3 years 2 months ago

Generically, I support the idea of eventually using a common data set. For resolutions of objects, as a texture artist, I think we really ought to have high-res versions of our TR textures, eventually. Then we could also have low-res textures for people with performance issues.

 

I have not gotten a chance to actually read most of the stuff in this thread and respond to it.

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.

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

There is an updated and more-detailled draft of the naming conventions at the PT-forums now. I’d posted it here aswell, but this forum doesn’t seem to handle large posts very well, so I’ll only link you to it and hope you will have some feedback:

http://project-tamriel.com/viewtopic.php?f=67&t=583&p=4504#p4504

Templar Tribe's picture
Templar Tribe
Joined:
2016-01-17 16:36
Last seen:
5 years 6 months ago
 

Took the liberty of making it forum-friendlier. ~Gnomey

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

It’s probably best to refer you guys to the original post at the PT-forum again, as there have been some minor changes to the naming scheme. I’m at a point where I can’t think of major improvements to the naming patterns anymore. Though, feedback is still welcomed, as always.

And there are some good news, too. We can probably save ourselves most of the manual work involved in the data move, even the manual setting up of ids for the data.esm. In particular we can also circumvent having to deal with the id-limit of (I think) 27 letters the CS imposes. I have searched for a tool that can do search&replace tasks in an esp- or esm-file and I found tes3cmd and figured out and tested some commands that I could use for just that. All we need now, is a text-file with an id-translation list that I can iterate with a simple program which invokes tes3cmd to set up the file for us.

I’m not 100% sure, but we might not even have to look for old object ids in script commands afterwards. I haven’t tried, but I think that tes3cmd can even patch savegames.

10Kaziem's picture
10Kaziem
Asset DeveloperInterior Developer
Joined:
2015-12-12 23:47
Last seen:
3 years 2 months ago

The name scheme looks fine to me. Do we have quality standards for models, textures, etc, or is that yet to be set up?

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.

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

With the vast amount of assets existing across the projects, it is probably difficult to enforce any hard rules for them. We could set up some purely technical rules for now, like enforcing dds-format for textures and similar things. Anything else would be best handled as a set of recommendations that should be followed as much as possible, but shouldn’t be able to act as a showstopper for anything. To put it short: It’s too much work to fix all oddnesses that exist across the data files directly for the merge. We’d best only tackle the worst things at any given time. Some of the container plants in PC_Data, for example, are of terrible quality and should definitely be worked on sooner or later.

I’m currently working on a few shotn -assets to give them a more vanilla-friendly feeling. But I see it more as a process of including designs or proportions seen in vanilla than reducing polygons or pixels to vanilla level, which is something I’ll not be prepared to do at any given time.

When we speak about asset quality standards, I’m thinking of such things as lightness, contrast, saturation and coloration of textures and the general feeling an object invokes. Though, it is also something that needs to be considered in the context of the intended environment. P:C uses a lighter color scheme than vanilla pretty much consistently throughout all of their assets, which works just great in its respective environment and helps to show some difference. But it also uses many elements that visually tie it with the vanilla game and I’m quite happy with it all myself. Though, it’s naturally a subjective matter.

For the most part you can say the same thing about SHOTN, except that SHOTN is more on the dark side of things. However, there are some things like the books. They are larger and thicker than any books in the original game and many of them look oddly modern. I’d rather have them made more vanilla-friendly sooner or later, even if the individual quality of the models as such is very good.

The grass meshes are a completely separate topic from this all. We use them, Many of the exteriors have been made to be completely reliant on them in the past, unfortunately and we have started to rework some of them so you might be able to play the mod without grass, too. But we’ll keep including them and they are somewhat excepted from having to accomodate to a certain vanilla feeling.

In general it’s a topic that has given me some headache up to date. I keep working on things that are not yet quite right, but I try to balance it with effort going into creation of new things. It’s like fixing Telvanni at TR. It needs to be prioritized properly.

10Kaziem's picture
10Kaziem
Asset DeveloperInterior Developer
Joined:
2015-12-12 23:47
Last seen:
3 years 2 months ago

I was thinking in terms of recommendations too, for things like poly-counts and texture sizes.

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.

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

I have written up my thoughts on common asset guidelines here, mostly with regards to style and general approach and less much about technical finickies.

http://project-tamriel.com/viewtopic.php?f=67&t=596

Again, I’ve been meaning to post it here, but some bugs in the forum software kept me from properly formatting the post.

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

So here is the first part of the  id-translations, only covering the objects in TR_Data and a few selected overwriting objects from the other data files, namely the barrow objects and the imperial wines.

Feel invited to give it a brief look. I’ll try to get the id-translations for the other two data files done over the weekend, though, it might be going to be a tough business.laugh

Edit: Added an updated version of the id-translation with some changes to existing ids.

AttachmentSizeDate
Plain text icon Translation.txt232.46 KB2016-04-09 00:41
worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

A new version of the translation-file. This time with all objects from PC_Data and a couple from Skyrim_Data. Also, there have been, once more, some shuffles and changes on the new id-system to address some problems I came across.

AttachmentSizeDate
Plain text icon Translation.txt445.17 KB2016-04-13 23:08
worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

Another wip-file. Probably the last before the final version. Right now there are a few ids too long that I haven’t gotten around to fix. Also, again, many improvements over the previous ids.

AttachmentSizeDate
File Translation.7z75.99 KB2016-04-19 00:30
worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

Weird. Only a day later (felt like an eternity, really) here is a complete translation file of all three datas.
You will find lines like this in the txt-file:

Sky_Terrain_Rock_04_011:T_Sky_TerrRockRE_RockPky_07
Sky_Terrain_Rock_04_012:T_Sky_TerrRockRE_RockPky_08
Sky_Terrain_Rock_04_014:T_Sky_TerrRockRE_RockPky_08
Sky_Terrain_Rock_04_016:T_Sky_TerrRockRE_RockPky_09

Those are not oversights, but intended replacements. Unfortunately we have had a bunch of duplicate objects in the skyrim data files. This will make these objects collapse into one.

AttachmentSizeDate
File Translation.7z82.62 KB2016-04-20 22:50
Atrayonis's picture
Atrayonis
Developer EmeritusInterior DeveloperQuest Developer
Joined:
2015-09-28 20:13
Last seen:
2 years 6 months ago

Cross-posting to Project Tamriel

Right, the Elephant in the room which I feel I must mention is Black Marsh. Progress is currently ongoing on TR's side, so I'm not posting about that just yet.

The topic at hand is TR's Redoran questline and SHotN's Rise of High King Thian.

The Redoran questline (still in discussion) is thought to start as a minor conflict with House Hlaalu, but will eventually evolve into an effort to keep the native Nords, the Nail-Knock Reavers, pacified.
A big part in this will be where the Reavers got the money and arms to stage their uprising from.

The obvious culprit is the Thian's kingdom, Haafinheim (Solitude).

To recap, in TES canon the Kingdom of Solitude:

  • As of The Pocket Guide to the Empire, 3rd Edition, have occupied Roscrea
  • As of The Pocket Guide to the Empire, 3rd Edition, are going after all Imperial Territory they can
  • As of Oblivion in-game dialogue, are in the process of occupying Solstheim and beating the Redoran black and blue
  • As of Skyrim dialogue and books, gave Solstheim to the Dunmer as a show of support, which implies that they owned it as thoroughly as they could prior to the 4th era

I feel it would be helpful to coordinate how Haafinheim develops during Shotn's questline and how it would fit into the timeframe of TR's Redoran questline. As Oblivion (its fractal terribleness aside) is still the best view into Tamriel's future, I think Haafinheim's slow digestion of Roscrea and slow grasping towards Redoran territory (and Solstheim) is something that we could bounce off each other.

Ateiggaer's picture
Ateiggaer
Joined:
2016-03-14 17:47
Last seen:
1 year 2 months ago

I don’t now if this is the right place to ask, but since you seem to discuss how some of the lorecan be consistent over the different projects, I wanted to know if you have some plans, gameplay-wise for players regarding leveling, getting insanely rich and to powerful, in a relativley short amount of time. Do you have any plans for that? I mean concerning the landmasses getting bigger and bigger with so much to do, would it be wise to somehow increase the requirements for leveling up? Will you still have some creatures and quest that are not leveled to the player?

This propably has been asked before, so, sorry for the inconvenience, but I’m really curious about this.

 
 
 
 
 
 
Seneca37's picture
Seneca37
Developer EmeritusExterior DeveloperInterior Developer
Joined:
2015-07-05 20:55
Last seen:
3 years 11 months ago

Worsas – you’ve made a number of changes from the inital naming conventions that you had posted before. Would you provide us with the new naming conventions?

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

I have updated the first post here to reflect the changes to the naming scheme. It’s only missing some examples yet.

Seneca37's picture
Seneca37
Developer EmeritusExterior DeveloperInterior Developer
Joined:
2015-07-05 20:55
Last seen:
3 years 11 months ago

Here is all that data in a spreadsheet. Each tab is a differnent section. The “U” column indicates what was updated from the initial list.

 

AttachmentSizeDate
File Translation_2.ods270.5 KB2016-04-23 00:29
Ateiggaer's picture
Ateiggaer
Joined:
2016-03-14 17:47
Last seen:
1 year 2 months ago

Ok, I just saw the discussion between TemplarTribe and Zaric Zhakaron and this fully answers my question, so don’t bother to write an answer to my comment. laugh

Seneca37's picture
Seneca37
Developer EmeritusExterior DeveloperInterior Developer
Joined:
2015-07-05 20:55
Last seen:
3 years 11 months ago

I’ve gotten about half way through looking at the new naming convention. Here are my comments so far. These are general comments, I haven’t really gone through the lists looking to look at each item yet.



1) I would prefer the unique items to be seperated more from the rest of the items. A designer should have to go find these items, since they should rarely appear in-game. At first I thought maybe adding a UNI prefix, to the front of the name, would be good. However, this would cause the unique items to be before the Wood Elf stuff; T_UNI_… comes before T_We. What if unique items started with TU_. This would place the items outside the T_ names.



2) Activators are special for 2 reasons. First the Name of the item is displayed when the cursor is on it, and second they can have scripts attached. There are several items within the Activator catagory that do not use either function. Things like T_Com_Furn_BathHalfbarrel_02, and all the water models really should be over in the Static catagory. I know that TR have some of these problems too, but since we are going through this effort, why not fix the locations of items as well.



3)I am not really happy with the "Com" designation. It has caused some confusion with TR modders. “Com" to me, and most others, reads as common. Even in the Race designation "Com " is listed as  "Not specific to any race". However in Morrowind, this is not true. "Com" generally means "Imperial", or as some might say, "Outlander" or “Westerner". So, having to tell our designers what "Com" objects can and can not be used, sort of defeats this renaming system. I am not sure how to fix this. If we change "Com" to mean "Not specific to any race except the Dunmer", then we must make sure all Dunmer items do not use "Com".



4)I think we should keep to the same abbreviations throughout the lists. Looking at the armor I see  T_Imp_StuddedLeather_PauldrL_01, and T_Imp_Newtscale_PauldronL_01 . If there is a need to shorten a catagory name (eg Pauldron to Pauld) then that shortend version should be used through out.



5) Naming Rules. Each catagory should have a rule as to how it’s ID name is created. This is not only needed now, but in the future when new items get added. Below is a possible example for Activators.

T_[Race]_[AType]_(ItemName){_[##]}           



If something is enclosed in square brackets [], then that comes from the designated list.

If something is enclosed in parentheses (), then the person creating the name would enter the item’s name, following the pattern used in previous names.

If something is enclosed in {}, this would be optional.

Every catagory should have the “Unique” identifier. There were no unique activators; if there were, I’d propose: T{U}_[Race]_[AType]_(ItemName){_[##]}.

I’d like to see something like this for each category (Activators, Alchemy ….)



6) Books. Books have always been a big problem. Even after having read every book, I don’t always remember what the book was about. Using the name of the book is really not that helpful. I propose doing the book IDs completely different.

Using my rules system above, I suggest the following:

T{U}_[BookPrefix]_][BookCategory]_[Author Race]{_[Spell/Skill]}_(Name/Title)

Book Prefix: 

Bk = plain book

BkSp = book that teaches spell, include _[Spell]

BkSk = book that teaches skill, include _[Skill]

Book Category:

Bio = Biography

Fac = Faction

Fic = Fiction

His = History/Lore

Hum = Humor

Non = NonFiction (Instructional, Research...)

Jou = Journals and Logs

PPR = Plays, Poetry, Riddles

Law = Law & Politics

Rel = Religion/Prophecy

Tra = Travel

[Spell/Skill] would consist of the various spells and skills available.



7) I suggest that the Clothing quality to be a separate designator, and for it to appear earlier in the ID. For example: T_Com_ShirtCm => T_Com_Cm_Shirt

It would be nice if the clothing quality would be ordered to follow pricing/enchanting.

So maybe use the following:

common → Cm

expensive → Ep

extravagant → Et

exquisite → Ex

 

 

more later….

 

worsas's picture
worsas
Developer EmeritusAsset Reviewer
Joined:
2016-01-26 12:34
Last seen:
4 days 41 min ago

Thanks for the feedback, Seneca.

On 1: T_UNI, seems like a bad idea to me for the reasons you already stated yourself. TU_ would be a possibility but opposed to UNI it’s not self-explaining at all. I’m not sure why you have such a big issue about the naming pattern i put up for them. It’s pretty clear that they are unique items, when you see them and they are placed in the cultural space they belong to, aswell, by following the race designation rather than standing completely outside.

On 2: Yes, those are going to be turned into statics.

On 3: From an intuitive point of view it isn’t really that absurd to have com used for both province/race-unspecific objects and general westerner objects at the same time. If something could be assigned to a particular race somehow (including dunmer), I have done so, however. But as said on irc, the assignment of many clothing- and armor-pieces are up in the air and could be reconsidered. The fact that you say that having to give instructions on the usage of objects would defeat the renaming system, makes me think that we are in a fundamental misunderstanding. If I had wanted that nothing ever can go wrong, I would have proposed just putting all three data files in their current state into a common file, so p:c-people can find their stuff under pc_, TR-people their stuff under tr_, etc.  and frankly, we could just have left this whole data move in the first place then.

On 4: I’m fine with adjusting all paudrons to say paudr or just pauld, although it seems like hairsplitting to me.

On 5: Yes, good call.

On 6: I’m against your proposed book prefixes, as for many books it is up in the air, if they will stay skillbooks. I also find it helpful to have written notes and scrolls separated from books, in case you are suggesting to do away with them.I agree that book categories saying ‘novel’ or ‘religious’ would be a useful addition and would help modders to find a suitable piece for the home they are decorating. Not sure how to address the issue of the identical book titles (like king edward eg.) found in different shapes across the projects (using different models and separation of volumes in many cases), when using your proposed scheme. Adding the race of the author seems like a nice idea, even though difficult to pull out for many titles and it’d all in all be a rather thight fit for the 32 letter limitation.

On 7: Would be fine with me.

Edit: I have thought about the com-issue again and I agree that it must be confusing to use com for generic westerner stuff and cosmopolitan objects like waterlayers, bones or cross-province plants at the same time. So how about splitting the current com-objects into two types, so that com only remains used for generic objects of use (like cast iron pots) and westerner armor designs without a specific racial origin. Whereas the other com-objects move into a group of their own?

Pages

Topic locked