My reasoning for keeping regions in the landmass is that they are always likely to get changed, which is a bit inconvenient, if those have to be changed in the data aswell. But you have some valid counterpoints, so I’m fine with leaving them in. All three projects use the vanilla way of naming their regions, so their naming is something that we don’t need to address.
Non-quest-related scripts need to stay in the data files, as they are used by objects. And other general-purpose scripts are good to be available for all projects that use the data. At SHOTN and P:C we have moved all dialogue out of the data files. Dialogues need to be edited often and it doesn’t make much sense to me to have them scattered between the data files and the content files.
This is a version of the filepatcher program that shouldn’t mess up scripts and shouldn’t cut off the last letter of the result text anymore(if you need to do any further patching in the coming days..) https://dl.dropboxusercontent.com/u/22362022/TR_FilePatcher.jar
I do agree that keeping the regions in the Tamriel_Data.esm will make it a major hurdle to revamp them in the future, which is another reason why I want them in. Incidentally, I don’t know how you aware you are of that, but we’re about done with a major region revamp.
What is easier for you – changing the regions in the Tamriel_Data, or changing the regions in TR_Data and merging anew?
If some of the current regions are supposed to get renamed, we should add translation lines for them so savegames and outside mods get updated accordingly. But I would manually add these changes to the data.esm we have here now along with any other changes that are wanted.
It would help, if someone could summarize all wanted changes to the current data.esm later on this week, maybe after your next skype meeting?
And I need translations for quest-related objects in the landmass.esm and the preview.esp that don’t use the TR_mX_-way of naming. Any object id you would like to have changed should get a translation line in the translation.txt, actually. And when that is done TR_Mainland.esm and TR_Preview.esp etc. need to be patched again, of course and all people can start patching their files after that.
Regarding data updates: Whenever TR or one of the projects at PT want an update, they could submit the new version of their respective bsa-file along with an esp-file containing all wanted additions and changes and the person handling the data updates would just merge the esp into the data esm, exchange the respective bsa-file and upload the new version of the Data Files. That way none of the three projects would have to wait on the other ones to create a new version. This seems like a very flexible approach to me and it would keep distributing the managing work between several people. Creating data updates can really take a lot of effort, which is best not put on the shoulder of a single person.
A considerable improvement for the patcher – I’m still looking through the files, but both the first empty line and the last quote seem to have been fixed.
I’m fairly confident to run it across TR_InDev atm, and bring it live in TR1609.
As for the Tamriel_Data regions, I’ll upload a version when I feel confident that they are hammered down – say, next Monday?
Yesterday Londonrook pointed me to the fact that our way of subdividing ids with underscore is actually not up-to-date. Beginning with Oblivion Bethesda switched to using a so-called camelcase – way of writing and it’s also something common in modern engine editors.
The biggest advantage would be that some letters would be freed and there would be more space to put actual information into the id. On the other hand, it would need to be gotten used to. But for people that are used to the Oblivion or Skyrim CS it would just be about getting familiar with our prefixes.
I’m personally not a big fan of that way of writing, but my mind is too set on the old good morrowind CS to really judge it impartially.
I’m frankly not a big fan, as I think it makes the IDs harder to identify at a glance – basically more intimidating – to those not already familiar with them; it just becomes a jumble of characters. One might certainly be able to get used to it, ButOneCouldAlsoGetUsedToNormalWritingWithoutSpaces. Basically it might be more efficient in the long term, but I think less convenient in the short-term, and I think the IDs should be kept as intuitive as possible for new people.
For containers, in particular, the alternative naming pattern would lead to rather difficult-to-decipher ids like TCyrImpFurnPSidetable01MiscGC. Unless someone brings up really excellent arguments for moving to camelCase, I’ll save myself going through 16,000 translation lines to adjust them to it.
I don’t like them. I understand why they are used (I use these at work), but I find they make asset names too long to properly identify at a glance. Sure, there is a mental “breather” inbetween the words, but it makes it easier to pick out the one substring you are looking for as well.
It might be different to people who are used to them in this context, but for modding newbies (and really, modding newbies are more our target audience than experienced Oblivion/Skyrim modders) will probably find them easier to parse as well. Ergo, I don’t really think we should use them.
No underscores makes IDs easier to search as they’re easier to type quickly.
But...at a glance they’re easier to identify, and they fit the Morrowind naming conventions. And we don’t have to go through and rename a gazillion things, which I think is probably the biggest plus.
Okay, here is an updated Tamriel_Data with the regions, an updated translation.txt and a prototype TR_Mainland.esp.
It’s a first shot, I expect to have a couple more retries to do until this works as it should – I didn’t touch the dialogue in Tamriel_Data yet, neither the scripts or most of the dialogue in TR_Mainland.
Combed through the IDs again, and again not finding a lot to complain about. Only thing that really stood out to me was that ingredients could perhaps use a province identifier; T_IngCrea_ShellParastylus_01 → T_IngCrea_Mw_ShellParastylus_01, T_IngFlor_LadysSmock_01 → T_IngFlor_Cyr_LadysSmock_01, T_IngFood_FishSlaughterDried_03 → T_IngFood_Com_FishSlaughtDry_03. (And that we need to replace all instances of our T_Imp_LegionMw_ChapelWindow_01 with PC’s T_Imp_SetChapel_X_Win and our eye-searing Colovian bread with PC’s).
Well, this is pretty awkward, since I about finished a minimum Tamriel_Data, with the new regions, sans dialogue.
I’ve attached it (plus the updated translation file) in any case. If we don’t change the IDs around (is there even place for a province identifier?), I think this is a good final version to start developing with – all further TR asset changes should be done with a new esp and these then merged shortly before release.
Added myself as developer, but “developer” for merge claims are a farce anyway. Feel free to replace me – and add to the workflow, so it’s not lost in future.
I don’t think any of my last nit-picks were terribly important; addressing them might provide a slight greater degree of convenience, but from all I’ve seen Tamriel_Data is perfectly usable as-is. They might be something to keep in mind if there’s ever work done on the IDs later, but I don’t think we need to worry about them too much. These sort of projects can be optimized to the end of times and still have space for improvement.
So I went ahead and did a few corrections and modifications to this data.esm, none of which will affect the above-posted TR_Mainland.esm. I uploaded the new file along with an updated version of the translation.txt and the filepatcher to Atrayonis’ merging claim. The same files are linked below. Edit: The molecrab bodypart fix by Atrayonis is included.
The filepatcher now won’t require the newest version of java anymore to run. Any version >= 1.6 will suffice. And it should now update region-assignments of exterior cells in dependant mods, if there is a translation line for changed regions in the text-file.
Unless anyone has objections or urgently needed changes, I would like to close in on an initial version of the data and update the working files at P:C and SHOTN to use this data.esm now. Then I’d also be going to upload a new version of PT_Data.bsa with a missing object and a few minor fixes.
That meal → potion – idea discussed yesterday… can we agree to address it at some point in future? Right now I just want to have this move behind myself and take a little break from it all.
Well shit, looks like I forgot to put in the Shipal-Shin region. File attached, please merge. Terribly sorry.
In better news, I’m planning on summarizing my patching work in a howto (will also hopefully be an article for modders). Do you have something planned for that, or would that be appreciated?
In better news, I’m planning on summarizing my patching work in a howto (will also hopefully be an article for modders). Do you have something planned for that, or would that be appreciated?
Sounds good.
I have actually done some slight modifications on the data and the translation again. I have assigned the levelled items used by container plants and animals to the province of the respective animal/container now. But I need to patch the TR_Mainland file with the Quickeditor still, so the respective itemReferences get updated.
There were also some last additions from P:C and I have quickly added a needed animal for the SHOTN – release. But other than that I’m only waiting on the new bsa from TR, before I’ll call it a finished first version and start to patch our contents over there. If you have edited the TR_Mainland.esm, make sure to mention it so I can download the newer version and your changes don’t vanish.
Both archives contain full versions of Tamriel_Data with the only difference being that the BSA-files in the HD-Version contain higher resolution textures.
The TR_Filepatcher.jar can be used to patch esp-files to use Tamriel_Data instead of TR_Data and it should be able to patch savegames to run with the patched TR_Mainland.esm and the other translated content files, if they were previously played with our old TR_Mainland.esm. If you have java installed on your pc, you should be able to open the program by double-clicking the file or otherwise right-clicking → open with → java.
In order to properly use these new data files you will have to register PT_Data.bsa in your Morrowind.ini next to TR_Data.bsa.
Edit: The rug texture path fixes have been included as a hotifx and an updated version has been uploaded, including that fix aswell as fixes to a few other problems I encountered later on today.
It seems there is still an outstanding problem that we'll have to address before we can have a release.
This problem would have been foreseeable and I actually had a vague notion of something not being right about container instances in savegames, but I didn't really investigate about it, since we have had containers exceeding 24 letters in Skyrim_Data for a long time and due to having played with "yes to all" and maybe not having looted containers with these excess letters, this has never been noticed.
Our new container ids need to be cropped to 24 letters, because the game needs to be able to create instances of containers with modified data. I've been hoping this would happen in the regular instance data, but it seems to be similar to how creatures are handled: The game creates a new object with 8 appended digits. This new id can have 32 letters at most and if the base container id exceeds 24 letters the surplus letters are cropped. When the game loads a savegame with such a container instance, it only guesses which object this instance belongs to by its 24 starting letters and in any case it will show an error message and crash, if "yes to all" isn't selected.
Also, the filepatcher does not yet patch these modified container instances in savegames. But adding this functionality is quickly done and it only needs to be there as soon as the release happens and savegames are patched.
The bigger problem at this point is how we can change our container ids to fit into this extremely tight letter limitation. The containers are exactly the kind of object containing more information in their ids than any other thing. Changing them to 24 letters can only result in a cryptic mess and will not allow us to keep our verbose id-naming scheme.
In any case, we'll also have to patch content files again. For files like TR_Mainland.esm, this re-patch can happen with a spare translation.txt, that transfers the new ids to their cropped counterparts without harming the rest. But this is again minor compared to the question of how we'll set up our new container ids.
Though, I'll do anything in my power to save this data move from going to hell. We'll get it managed anyhow. It's just annoying that we aren't done yet.
Here comes a version of Tamriel_Data.esp with updated container ids. Let me know, if these are ok to use.
I have taken the approach of collapsing the rear part of the id and leaving the categorizations on the front like they are in other object lists. Even if that may look a bit imbalanced, keep in mind that one is primarily supposed to find relevant entries in a long list quickly. Also, I didn’t want to introduce a completely new naming system for this list, in particular since I have managed to somehow scram the information into the given space.
These are the abbreviations I have used for often-used container types and contents (especially ones that are often combined with other suffixes). We would have needed to use most of these, even with a camelCase system. But we could still switch to it, if it is still desired.
Bl = Barrel Bs = Basket Cl = Closet Cr = Crate Cb = Cupboard Cs = Chest Ds = Desk Dw = Drawers Ht = Hutch Sk = Sack St = Sidetable U = Urn Vs = Vase
Pos = Random pos Ing = ingredients Dri = Drink Clt = Clothing Wpn = Weapon Arm = Armor Msc = Misc Lgn = Legion
Band = Bandit Smug = Smuggler Bk = Book G = Gold
Ep = Expensive Cm = Common Et = Extravagant Ex = Exquisite
This Data.esp also includes a few minor modifications to other objects. Since the wooden dishes from TR_Data didn’t have stats and icons, I noticed, I have switched them for their SHOTN-counterparts for the time being. I’ll have to upload a modified version of PT_Data.bsa that contains their models again, though.
I have taken these abbreviations from the clothing list. the letters were chosen, so Cm is at the top, Ep is second, Et third and Ex fourth. This is quite simply why it’s ex instead of eq. It’s something seneca came up with and I find it very reasonable. Otherwise I would agree.
The IDing looks fine to me, though honestly, most of the 3 or 4 letter ones could probably be shortened to two letters if needed.
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.
The three- and four-letter abbreviations are for the contents of the container that should be easier guessable than the container type to save one having to open the container in the Cs to see what it contains. Although even some of those are admittedly still cryptic like Lgn or Clt.
It has been proposed using Ch instead of Cs for chests. I will use that as an improvement but other than that, go with what we have now. There is no gain in tweaking this stuff forever. So unless someone objects, I’ll set up the final data along with a permissions.txt until tomorrow or early next week.
No objections on my end. I’ll need to retranslate all five files we have, though. I’d be really grateful if the spectre of book entry reunification is kept off until later. It sounds like a worthwhile idea to go into either one direction or the other (local variants on books, with their own layout and price), but much like the meal->potion debate, not for right now please.
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.
Atrayonis, can you provide me translations for all of the below regions that have been changed? It’s needed for savegame patching to circumvent error messages about missing regions after loading a patched savegame.
Thirr River Valley Region: Alt Orethan Region Aranyon Pass Region: Armun Ashlands: Askkaedh Coast: Boethian Mountains Region: Boethian Mountains Region -Map Grey Meadows: Helnim Fields Region: Inlet Bog Region: Inner Sea Region: Lake Boethiah: Lan Orethan Region: Mephala Valley: Mephalain Mountains Region: Molagreahd Region: Nedothril Coast Region: Northern Velothi Mountains: Old Ebonheart Region: Othreleth Woods: Roth Roryn: Sacred Lands Region: Sea of Ghosts Region: Sea of Ghosts Region -Map2: Telvanni Isles Region: Velothi Mountains:
Thirr River Valley Region: Aanthirin Region Alt Orethan Region: –no change- Aranyon Pass Region: –no change- Armun Ashlands: Armun Ashlands Region Askkaedh Coast: Ascadian Bluffs Region Boethian Mountains Region: Boethiah’s Spine Region Boethian Mountains Region -Map: Boethiah’s Spine Region Grey Meadows: Grey Meadows Region Helnim Fields Region: – no change- Inlet Bog Region: Sundered Scar Region Inner Sea Region: Aanthirin Region Lake Boethiah: Boethiah’s Spine Region Lan Orethan Region: – no change- Mephala Valley: Mephalan Vales Region Mephalain Mountains Region: Mephalan Vales Region Molagreahd Region: – no change - Nedothril Coast Region: Nedothril Region Northern Velothi Mountains: Uld Vraech Region Old Ebonheart Region: – no change - Othreleth Woods: Othreleth Woods Region Roth Roryn: Roth Roryn Region Sacred Lands Region: – no change - Sea of Ghosts Region: – no change - Sea of Ghosts Region -Map2: Sea of Ghosts Region Telvanni Isles Region: – no change - Velothi Mountains: Velothi Mountains Region
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
3 hours 31 min ago
My reasoning for keeping regions in the landmass is that they are always likely to get changed, which is a bit inconvenient, if those have to be changed in the data aswell. But you have some valid counterpoints, so I’m fine with leaving them in. All three projects use the vanilla way of naming their regions, so their naming is something that we don’t need to address.
Non-quest-related scripts need to stay in the data files, as they are used by objects. And other general-purpose scripts are good to be available for all projects that use the data. At SHOTN and P:C we have moved all dialogue out of the data files. Dialogues need to be edited often and it doesn’t make much sense to me to have them scattered between the data files and the content files.
This is a version of the filepatcher program that shouldn’t mess up scripts and shouldn’t cut off the last letter of the result text anymore(if you need to do any further patching in the coming days..)
https://dl.dropboxusercontent.com/u/22362022/TR_FilePatcher.jar
2015-09-28 20:13
2 years 6 months ago
Just saw that now, will try it out tomorrow.
I do agree that keeping the regions in the Tamriel_Data.esm will make it a major hurdle to revamp them in the future, which is another reason why I want them in. Incidentally, I don’t know how you aware you are of that, but we’re about done with a major region revamp.
What is easier for you – changing the regions in the Tamriel_Data, or changing the regions in TR_Data and merging anew?
2016-01-26 12:34
3 hours 31 min ago
If some of the current regions are supposed to get renamed, we should add translation lines for them so savegames and outside mods get updated accordingly. But I would manually add these changes to the data.esm we have here now along with any other changes that are wanted.
It would help, if someone could summarize all wanted changes to the current data.esm later on this week, maybe after your next skype meeting?
And I need translations for quest-related objects in the landmass.esm and the preview.esp that don’t use the TR_mX_-way of naming. Any object id you would like to have changed should get a translation line in the translation.txt, actually. And when that is done TR_Mainland.esm and TR_Preview.esp etc. need to be patched again, of course and all people can start patching their files after that.
Regarding data updates:
Whenever TR or one of the projects at PT want an update, they could submit the new version of their respective bsa-file along with an esp-file containing all wanted additions and changes and the person handling the data updates would just merge the esp into the data esm, exchange the respective bsa-file and upload the new version of the Data Files. That way none of the three projects would have to wait on the other ones to create a new version. This seems like a very flexible approach to me and it would keep distributing the managing work between several people. Creating data updates can really take a lot of effort, which is best not put on the shoulder of a single person.
2015-09-28 20:13
2 years 6 months ago
A considerable improvement for the patcher – I’m still looking through the files, but both the first empty line and the last quote seem to have been fixed.
I’m fairly confident to run it across TR_InDev atm, and bring it live in TR1609.
As for the Tamriel_Data regions, I’ll upload a version when I feel confident that they are hammered down – say, next Monday?
New patched files are here!
2016-01-26 12:34
3 hours 31 min ago
Yesterday Londonrook pointed me to the fact that our way of subdividing ids with underscore is actually not up-to-date. Beginning with Oblivion Bethesda switched to using a so-called camelcase – way of writing and it’s also something common in modern engine editors.
Current underscore way of separation examples:
T_Sky_TerrRockRE_RockSml_11
T_Mw_FloraGM_PuffShroom_01
TSkyTerrrockRERockSmall11
TMwFloraGMPuffshroom01
I’m personally not a big fan of that way of writing, but my mind is too set on the old good morrowind CS to really judge it impartially.
2015-08-10 20:50
1 week 5 hours ago
I’m frankly not a big fan, as I think it makes the IDs harder to identify at a glance – basically more intimidating – to those not already familiar with them; it just becomes a jumble of characters. One might certainly be able to get used to it, ButOneCouldAlsoGetUsedToNormalWritingWithoutSpaces. Basically it might be more efficient in the long term, but I think less convenient in the short-term, and I think the IDs should be kept as intuitive as possible for new people.
2016-01-26 12:34
3 hours 31 min ago
For containers, in particular, the alternative naming pattern would lead to rather difficult-to-decipher ids like TCyrImpFurnPSidetable01MiscGC. Unless someone brings up really excellent arguments for moving to camelCase, I’ll save myself going through 16,000 translation lines to adjust them to it.
2015-09-28 20:13
2 years 6 months ago
I don’t like them. I understand why they are used (I use these at work), but I find they make asset names too long to properly identify at a glance. Sure, there is a mental “breather” inbetween the words, but it makes it easier to pick out the one substring you are looking for as well.
It might be different to people who are used to them in this context, but for modding newbies (and really, modding newbies are more our target audience than experienced Oblivion/Skyrim modders) will probably find them easier to parse as well. Ergo, I don’t really think we should use them.
2016-01-19 19:35
3 weeks 1 day ago
No underscores makes IDs easier to search as they’re easier to type quickly.
But...at a glance they’re easier to identify, and they fit the Morrowind naming conventions. And we don’t have to go through and rename a gazillion things, which I think is probably the biggest plus.
2015-09-28 20:13
2 years 6 months ago
Okay, here is an updated Tamriel_Data with the regions, an updated translation.txt and a prototype TR_Mainland.esp.
It’s a first shot, I expect to have a couple more retries to do until this works as it should – I didn’t touch the dialogue in Tamriel_Data yet, neither the scripts or most of the dialogue in TR_Mainland.
2015-08-10 20:50
1 week 5 hours ago
Combed through the IDs again, and again not finding a lot to complain about. Only thing that really stood out to me was that ingredients could perhaps use a province identifier; T_IngCrea_ShellParastylus_01 → T_IngCrea_Mw_ShellParastylus_01, T_IngFlor_LadysSmock_01 → T_IngFlor_Cyr_LadysSmock_01, T_IngFood_FishSlaughterDried_03 → T_IngFood_Com_FishSlaughtDry_03. (And that we need to replace all instances of our T_Imp_LegionMw_ChapelWindow_01 with PC’s T_Imp_SetChapel_X_Win and our eye-searing Colovian bread with PC’s).
2015-09-28 20:13
2 years 6 months ago
Well, this is pretty awkward, since I about finished a minimum Tamriel_Data, with the new regions, sans dialogue.
I’ve attached it (plus the updated translation file) in any case. If we don’t change the IDs around (is there even place for a province identifier?), I think this is a good final version to start developing with – all further TR asset changes should be done with a new esp and these then merged shortly before release.
2015-09-28 20:13
2 years 6 months ago
Created a merge claim here: http://tamriel-rebuilt.org/claims/tamriel-data-1609
Added myself as developer, but “developer” for merge claims are a farce anyway. Feel free to replace me – and add to the workflow, so it’s not lost in future.
2015-08-10 20:50
1 week 5 hours ago
I don’t think any of my last nit-picks were terribly important; addressing them might provide a slight greater degree of convenience, but from all I’ve seen Tamriel_Data is perfectly usable as-is. They might be something to keep in mind if there’s ever work done on the IDs later, but I don’t think we need to worry about them too much. These sort of projects can be optimized to the end of times and still have space for improvement.
2016-01-26 12:34
3 hours 31 min ago
So I went ahead and did a few corrections and modifications to this data.esm, none of which will affect the above-posted TR_Mainland.esm. I uploaded the new file along with an updated version of the translation.txt and the filepatcher to Atrayonis’ merging claim. The same files are linked below. Edit: The molecrab bodypart fix by Atrayonis is included.
The filepatcher now won’t require the newest version of java anymore to run. Any version >= 1.6 will suffice. And it should now update region-assignments of exterior cells in dependant mods, if there is a translation line for changed regions in the text-file.
Unless anyone has objections or urgently needed changes, I would like to close in on an initial version of the data and update the working files at P:C and SHOTN to use this data.esm now. Then I’d also be going to upload a new version of PT_Data.bsa with a missing object and a few minor fixes.
That meal → potion – idea discussed yesterday… can we agree to address it at some point in future? Right now I just want to have this move behind myself and take a little break from it all.
2015-09-28 20:13
2 years 6 months ago
File attached, please merge. Terribly sorry.
In better news, I’m planning on summarizing my patching work in a howto (will also hopefully be an article for modders). Do you have something planned for that, or would that be appreciated?
2016-01-26 12:34
3 hours 31 min ago
Sounds good.
I have actually done some slight modifications on the data and the translation again. I have assigned the levelled items used by container plants and animals to the province of the respective animal/container now. But I need to patch the TR_Mainland file with the Quickeditor still, so the respective itemReferences get updated.
There were also some last additions from P:C and I have quickly added a needed animal for the SHOTN – release. But other than that I’m only waiting on the new bsa from TR, before I’ll call it a finished first version and start to patch our contents over there. If you have edited the TR_Mainland.esm, make sure to mention it so I can download the newer version and your changes don’t vanish.
2015-09-28 20:13
2 years 6 months ago
http://tamriel-rebuilt.org/claims/trmainland-1609
http://tamriel-rebuilt.org/claims/indoril-thirr-section
http://tamriel-rebuilt.org/claims/section-old-ebonheart-exterior
Those are all fully translated. I was waiting to call InDev ( http://tamriel-rebuilt.org/claims/trindev#comment-1013 ) finished when the new Tamriel_Data was up.
2016-01-26 12:34
3 hours 31 min ago
The first version of Tamriel_Data is finished and uploaded to our google drive. External platforms will follow.
Default version:
https://drive.google.com/open?id=0Bxtf3PaWZqbXelBTOGd0RFM2Zk0
HD – Version:
https://drive.google.com/open?id=0Bxtf3PaWZqbXQ29pdC02VjN6eU0
Both archives contain full versions of Tamriel_Data with the only difference being that the BSA-files in the HD-Version contain higher resolution textures.
The TR_Filepatcher.jar can be used to patch esp-files to use Tamriel_Data instead of TR_Data and it should be able to patch savegames to run with the patched TR_Mainland.esm and the other translated content files, if they were previously played with our old TR_Mainland.esm. If you have java installed on your pc, you should be able to open the program by double-clicking the file or otherwise right-clicking → open with → java.
In order to properly use these new data files you will have to register PT_Data.bsa in your Morrowind.ini next to TR_Data.bsa.
Edit: The rug texture path fixes have been included as a hotifx and an updated version has been uploaded, including that fix aswell as fixes to a few other problems I encountered later on today.
2016-01-26 12:34
3 hours 31 min ago
It seems there is still an outstanding problem that we'll have to address before we can have a release.
This problem would have been foreseeable and I actually had a vague notion of something not being right about container instances in savegames, but I didn't really investigate about it, since we have had containers exceeding 24 letters in Skyrim_Data for a long time and due to having played with "yes to all" and maybe not having looted containers with these excess letters, this has never been noticed.
Our new container ids need to be cropped to 24 letters, because the game needs to be able to create instances of containers with modified data. I've been hoping this would happen in the regular instance data, but it seems to be similar to how creatures are handled: The game creates a new object with 8 appended digits. This new id can have 32 letters at most and if the base container id exceeds 24 letters the surplus letters are cropped. When the game loads a savegame with such a container instance, it only guesses which object this instance belongs to by its 24 starting letters and in any case it will show an error message and crash, if "yes to all" isn't selected.
Also, the filepatcher does not yet patch these modified container instances in savegames. But adding this functionality is quickly done and it only needs to be there as soon as the release happens and savegames are patched.
The bigger problem at this point is how we can change our container ids to fit into this extremely tight letter limitation. The containers are exactly the kind of object containing more information in their ids than any other thing. Changing them to 24 letters can only result in a cryptic mess and will not allow us to keep our verbose id-naming scheme.
In any case, we'll also have to patch content files again. For files like TR_Mainland.esm, this re-patch can happen with a spare translation.txt, that transfers the new ids to their cropped counterparts without harming the rest. But this is again minor compared to the question of how we'll set up our new container ids.
Though, I'll do anything in my power to save this data move from going to hell. We'll get it managed anyhow. It's just annoying that we aren't done yet.
2015-09-28 20:13
2 years 6 months ago
Well, that’s terrible alright.
Reducing the names of only containers seems doable, however. Something like T_MwDe_SI_Culdem02_Emp instead of T_MwDe_SetInd_Culdem02_Empty?
This might also be a reason for switching to camelCase, which would already free up 3 to 4 letters.
2016-01-26 12:34
3 hours 31 min ago
Here comes a version of Tamriel_Data.esp with updated container ids. Let me know, if these are ok to use.
I have taken the approach of collapsing the rear part of the id and leaving the categorizations on the front like they are in other object lists. Even if that may look a bit imbalanced, keep in mind that one is primarily supposed to find relevant entries in a long list quickly. Also, I didn’t want to introduce a completely new naming system for this list, in particular since I have managed to somehow scram the information into the given space.
These are the abbreviations I have used for often-used container types and contents (especially ones that are often combined with other suffixes). We would have needed to use most of these, even with a camelCase system. But we could still switch to it, if it is still desired.
Bs = Basket
Cl = Closet
Cr = Crate
Cb = Cupboard
Cs = Chest
Ds = Desk
Dw = Drawers
Ht = Hutch
Sk = Sack
St = Sidetable
U = Urn
Vs = Vase
Pos = Random pos
Ing = ingredients
Dri = Drink
Clt = Clothing
Wpn = Weapon
Arm = Armor
Msc = Misc
Lgn = Legion
Band = Bandit
Smug = Smuggler
Bk = Book
G = Gold
Ep = Expensive
Cm = Common
Et = Extravagant
Ex = Exquisite
This Data.esp also includes a few minor modifications to other objects. Since the wooden dishes from TR_Data didn’t have stats and icons, I noticed, I have switched them for their SHOTN-counterparts for the time being. I’ll have to upload a modified version of PT_Data.bsa that contains their models again, though.
2016-05-09 13:13
3 weeks 4 hours ago
I would change the abbreviation for exquisite from ex to eq, as it then uses the same naming convention as expensive and extravagant
2016-01-26 12:34
3 hours 31 min ago
I have taken these abbreviations from the clothing list. the letters were chosen, so Cm is at the top, Ep is second, Et third and Ex fourth. This is quite simply why it’s ex instead of eq. It’s something seneca came up with and I find it very reasonable. Otherwise I would agree.
2015-12-12 23:47
3 years 2 months ago
The IDing looks fine to me, though honestly, most of the 3 or 4 letter ones could probably be shortened to two letters if needed.
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.
2016-01-26 12:34
3 hours 31 min ago
The three- and four-letter abbreviations are for the contents of the container that should be easier guessable than the container type to save one having to open the container in the Cs to see what it contains. Although even some of those are admittedly still cryptic like Lgn or Clt.
It has been proposed using Ch instead of Cs for chests. I will use that as an improvement but other than that, go with what we have now. There is no gain in tweaking this stuff forever. So unless someone objects, I’ll set up the final data along with a permissions.txt until tomorrow or early next week.
2015-09-28 20:13
2 years 6 months ago
No objections on my end.
I’ll need to retranslate all five files we have, though. I’d be really grateful if the spectre of book entry reunification is kept off until later. It sounds like a worthwhile idea to go into either one direction or the other (local variants on books, with their own layout and price), but much like the meal->potion debate, not for right now please.
2015-12-12 23:47
3 years 2 months ago
Sounds good to me.
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.
2016-01-26 12:34
3 hours 31 min ago
Atrayonis, can you provide me translations for all of the below regions that have been changed? It’s needed for savegame patching to circumvent error messages about missing regions after loading a patched savegame.
Thirr River Valley Region:
Alt Orethan Region
Aranyon Pass Region:
Armun Ashlands:
Askkaedh Coast:
Boethian Mountains Region:
Boethian Mountains Region -Map
Grey Meadows:
Helnim Fields Region:
Inlet Bog Region:
Inner Sea Region:
Lake Boethiah:
Lan Orethan Region:
Mephala Valley:
Mephalain Mountains Region:
Molagreahd Region:
Nedothril Coast Region:
Northern Velothi Mountains:
Old Ebonheart Region:
Othreleth Woods:
Roth Roryn:
Sacred Lands Region:
Sea of Ghosts Region:
Sea of Ghosts Region -Map2:
Telvanni Isles Region:
Velothi Mountains:
2015-09-28 20:13
2 years 6 months ago
Thirr River Valley Region: Aanthirin Region
Alt Orethan Region: –no change-
Aranyon Pass Region: –no change-
Armun Ashlands: Armun Ashlands Region
Askkaedh Coast: Ascadian Bluffs Region
Boethian Mountains Region: Boethiah’s Spine Region
Boethian Mountains Region -Map: Boethiah’s Spine Region
Grey Meadows: Grey Meadows Region
Helnim Fields Region: – no change-
Inlet Bog Region: Sundered Scar Region
Inner Sea Region: Aanthirin Region
Lake Boethiah: Boethiah’s Spine Region
Lan Orethan Region: – no change-
Mephala Valley: Mephalan Vales Region
Mephalain Mountains Region: Mephalan Vales Region
Molagreahd Region: – no change -
Nedothril Coast Region: Nedothril Region
Northern Velothi Mountains: Uld Vraech Region
Old Ebonheart Region: – no change -
Othreleth Woods: Othreleth Woods Region
Roth Roryn: Roth Roryn Region
Sacred Lands Region: – no change -
Sea of Ghosts Region: – no change -
Sea of Ghosts Region -Map2: Sea of Ghosts Region
Telvanni Isles Region: – no change -
Velothi Mountains: Velothi Mountains Region
Pages