Resolved a 2da name resoultion conflict by combining ambientsound.2da with AmbientSound.2da (see below for more info)
Added the missing lines 162-255 from the Beamdog ambientsound.2da, the 2da file is now padded correctly
Added missing Ossian reserved lines to the end of appearance.2da, the 2da is now padded correctly
Added missing columns IsMonkWeapon and WeaponFinesseMinimumCreatureSize to baseitems.2da
Updated the TemplateResRef references for lines 5105 and 5106 in doortypes.2da - Ossian doors
When I opened up TAD’s cep_top_2_65 I found that AmbientSound.2da and ambientsound.2da both existed in the HAK. I was able to determine which one was newer and combine them into one file.
Once I’ve tested and cross-checked my work, I’ll compile the Base Modules and see what breaks. Once all the bugs are squashed, my intention is to post a new cep_top_2_66 tophak to the main CEP page.
That initial post requires me to ask - what does v1.69 do with the added columns in the EE 2da files such as baseitems.2da - does it ignore them or choke to death on them?
By the way reading 2da works it shouldn’t matter, cause when you get a 2da string you actually have to give the function the column and line parameters.
I use custom 2da for handling listas of items, Creatures and dialog tokens and as long I don’t meses with an existing col, or the row order it just don’t give a crap.
That was my thinking too. Unfortunately, I don’t have 1.69 installed to test it for myself just to make certain for my own piece of mind. I’d hate to put a hak out there and tell someone it’ll work with 1.69 only to have it fail.
As long as you don’t change any column’s name (excluding text case in its header), it will read the whole table with no problem, exposing the whole table to the script with no issue. I have a custom column in my iprp_feats.2da and everything reads fine.
Thanks, but I’m very much aware of what I’m doing when it comes to 2da files. I just wanted to make sure 1.69 wasn’t going to choke to death - haven’t really played around with it since EE came out and adding columns was the one thing I’d never done with a 2da.
As an aside, for those of you not aware, I have a long history of CC creation that goes back to 2004 - though I didn’t start posting content until 2007 or so. My initial foray into large projects was with Neverwinter Nights Enhanced (NwnE) - Neverwinter Nights Enhanced | The Neverwinter Vault.
From there, I joined the Project Q Team, taking over that project in 2014. That’s pretty much where I’ve been since then, although I suspended production/development on Q in 2020.
Adding columns is fine. CEP might even have extra columns in appearance.2da for tracking some of the content source. I’ve used extra columns in parts_*.2da to mark appearances that were race or gender specific. No problems in 1.69.
The only potential issue is a support burden when people do their own maintenance and the column count is different from other sources. But, people need to learn to deal with this anyway, imho, with EE kicking around, and also for old CEP if it has the extra appearance.2da column in there that I vaguely recall.
Placeables.2da has presented a bit of dilemma as, after adding Ossian’s lines, all the Daggerford placeables now appear twice - not a big deal, but not exactly the desired outcome. I’m loathe to omit the Ossian references in the 15000 range as they are used in templates that are now part of the core game assets. Likewise, I’m loathe to remove the CEP references to them as God knows how many people have module content reliant on them.
Thus, I’m left with essentially two options:
Leave both sets of references in (the easy way out).
Replace one set of models with an alternate reskinned set of models that matches the color palette of the original Bioware tilesets. I won’t change the basic color pattern - e.g., red parts will still be red, blue will be blue, etc. But which set to reskin?
Lemme know here what you all think via this poll.
Leave in both CEP references and Ossian references - Daggerford placeables will appear twice
Make alternate models reskinned to match older Bioware tilesets - Replace CEP references
Make alternate models reskinned to match older Bioware tilesets - Replace Ossian references
They may appear twice in the 2da which can appear untidy, so try this. As the game uses the internal line number you should be able to edit the placeables names without screwing up modules already built with either version. I would just add “(old)” to the old CEP version of each. Builders of new modules should be steered to use the newer Ossian versions by doing that. Try it one at a time to be on the safe side though.
That’s another good idea. I also just thought of problem number 2 related to the Daggerford placeables. The models included in the CEP Haks are older than the ones included with the base game. Thus, if I leave those original models in whatever CEP Hak they’re in, newer/updated versions of the models are being overwritten with older models. I know Bill Harper did a lot of work on the models - shadow fixes, pwk fixes, etc. - before they became part of the core resources.
In light of the above, I’m inclined to remove the Daggerford models from the CEP. Then the CEP 2da lines would just point to the updated models anyway.
EDIT - No longer a concern. At some point I’ll put forth to Beamdog about putting these models in the CEP haks, BUT only if they are actually improved from what is there already.
Extracting assets and creating a content repository on my HDD. Have come to cep_add_sb_v1.HAK.
I’ve updated loadscreens.2da - grumble grumble…how many copies of loadscreens.2da does CEP need? …grumble grumble - BUT will be leaving the scripts compiled against v1.69.
I have added them directly to a test module and they do compile under EE 8193.32. However, if I add these scripts to the HAK, that’ll break 1.69 compatibility for that hak. While I said I wasn’t planning to add new stuff, should I add an optional cep_add_sb_EE.HAK to the mix?
You could decompile them instead. With todays machines getting the players machine to compile them in-game isn’t going to add any but a tiny bit of lag and the smaller scripts may well be even smaller decompiled. This way you don’t need to add a new hak.
Well they’ve got both the NSS and NCS in the HAK, but you can’t overwrite scripts in a HAK. Hence my preference for just leaving them as is, as being at 1.69 level compilation, they should work in EE as they can be compiled using the 8193.32 compiler.
Won’t really know for sure until I test a module with that HAK attached - which should be later today as I’ve finally got all the source extracted from the HAKs.
I understand the case for this. Problem is that 1.69 modules need the CEP models, so simply removing them isn’t an option.
A lesser issue is whether 1.66 is just a simple bolt-on top hak + whatever (preferred) or a refresh of the core files (tedious and risky).
Since CEP already had permission to use the old models, maybe Beamdog would sanction adding the new models to the 1.66 top hak so that everyone gets the latest.
Failing that, from the module building perspective, having to use the old models with tiny defects is vastly preferable to breaking the module.
please don’t. there are still quite a few members of the community who use 1.69 with or without EE, and removing actual content from the CEP will break modules. fiddling about with 2da’s is a different story, because it’s an easy task for modders to include their own versions of 2da’s in a top hak, but it’s quite a different story to have to track down obscure errors because the ‘latest and greatest’ release now longer includes the models you need…
or did i misunderstand your intentions ? they seem to go against what you said in the other thread :