Closed vandervecken closed 6 years ago
@kevL some questions about these recipes: 1) why do we have 3 different sets of identical recipes for tags 3,4,5, when we could do 1 set for all 3 tags? 2) Why is there no +1d6 acid? 3) How does this recipe even work? The property is "61,X,0,0,0" and 61 points to IPRP_AmmoType which is 0,1,2 for arrows/bolts/bullets. I don't even see how the numbers in the second parameter correspond to bonuses like +1d6 fire.
you know most of this but bear with it ...
right, looks like they can be consolidated. (as a legacy note, the subtype 2da for UnlimitedAmmo is Iprp_AmmoType. Or, was. maybe, don't know for sure. And that 2da specified, surprise, the ammo-type. It's rather the cost-table that decides power. Am guessing that the wise folks at Obsidian realized that the ammo-type could be checked in hardcode and did so, rendering Iprp_AmmoType obsolete at some point -- but perhaps there was a time when it had to be passed into the ip-constructor.) almost definitely not needed anymore.
don't know. There's no sonic either (elemental damage sonic was added later though). In any case I'm pretty darn sure those things are hardcoded. (note that in the subtype 2da costtable 2da, there are other weird types along the lines of Nature's Rage (as you've seen...) not sure if those were ever implemented though -- need tests, but i doubt they were)
Because, remember what i was saying about SavingThrowBonus and SavingThrowBonusSpecific? My theory is that for some IPs they have bypassed the subtype 2da files and implemented, or redirected some IPs' values and/or value-tables by hardcode, or they substituted the CostTable for the subtype ... they could have done anything, it's code(!). In other words, just because most IPs follow the rules (IP->subtype->costtable->par1value) we can no longer expect them all to follow those rules. So far, the two SavingThrowBonuses and now UnlimitedAmmo are on my "these do not follow standard rules" list ...
2 & 3) Do you think we should consider shipping a replacement iprp_ammocost.2da to add acid?
Also, while we're here do we want to overhaul the balance for these recipes? A Beljuril for basic unlimited ammo is excessive, and having the +1 recipes start with a King's Tear is a bit much too. Thoughts?
@kevL and @Aqvilinus: ^^
Do you think we should consider shipping a replacement iprp_ammocost.2da to add acid?
test whether unlimited acid-arrows even work?
do we want to overhaul the balance for these recipes?
am sure you've got a better sense of balance ... but yes i've lessened gems in my old Crafting.2da
Acid Arrows exist but Acid bullets do not, and for Bolts we have Poison, Mild Poison and Paralytic I see several options: 1) Poison and Mild Poison arrows exist too, and we could make it a bows/xbow only Poison bolt, no bullets 2) Acid Arrow and Poison Bolt, no bullets 3) Create acid bolts and bullets 4) Acid arrow only, no bolts or bullets.
Opinion?
BTW the gem rebalance is here: https://github.com/kevL/TccScripts/commit/49a52318a43cbe2b2d7e67337f38f8b139302d47
@Aqvilinus I'm out of my experience level re. crafted Ammo ... any opinions here?
I'm not an expert here too, whatever you decide, @vandervecken.
I was looking into creating a new Acid Bolt, but I think that would require a new StringRef for the description. Is that something complicated? I've never created a new item before.
There's nothing hard here. Create a copy of any existing bolt blueprint, type in a new tag/resref/etc. And it's not necessary to use StringRefs for descriptions. As with names, you can store the description directly on a blueprint.
Ok guys, I created an Acid Bolt item and enchanted it. The only broken thing here is the string that is listed on the bow itself. Can someone explain what is happening here?
![Uploading Screen Shot 10-23-18 at 01.34 PM 001.PNG…]()
Here is the bolt:
The code is all up on the unlimited_ammo branch so you can see what I did.
Oh, I bet it's the "1646" here: https://github.com/kevL/TccScripts/blob/unlimited_ammo/2da/iprp_ammocost.2da#L20
Does that mean I do need a name for this property?
More specifically, it looks like the stringref here is a reference to dialog.tlk, and I don't think adding a new string there is within our scope is it? There is no existing relevant string I can use in dialog.tlk.
yep it's the "1646"
(we're getting closer and closer to distributing Dialog.Tlk :(
you can try this though: in Iprp_AmmoCost.2da ... leave the Name blank "***" and the engine might* use the Label string ... ( Placeables.2da works like that, except the Name col is actually "StrRef" and this behavior might be unique to Placeables -- but i figure it's worth a shot )
I'd rather can this idea than distribute dialog.tlk.
When I replace 1646 with **** I get:
Crafting TestWizard: PC Spawn script run! .DoMagicCrafting() Workbench, Magic ( PLC_MC_CBENCH03 ) . id= 107 . crafter : Crafting TestWizard . oItem : Masterwork Light Crossbow ( NW_WBWXL001_mast ) isTypeMatch() ( Masterwork Light Crossbow BaseType= 7 ) sTypes= 3,4,5 . search by TCC-type . TCC iType= 4 . . . oItem is TCC_TYPE_XBOW . iRecipeMatch= 640 . iCasterLevel= 20 . iCasterLevel required= 12 . iTccType= 4 . iFeat= 1092 . iGPCost= 0 . iXPCost= 0 . sResrefList= . bEnchant= 1 . . sEncodedIps= 61,16,0,0,0 . . bPropSetRecipe= 0 . . . iPropType= 61 ERROR : DoMagicCrafting() ipEnchant is invalid ( 61,16,0,0,0 ) for iRecipeMatch= 640 ...
ah, y can it unless there's a better idea
Better ideas: 1) Caveat the recipe by saying that the string will be wrong and there's nothing we can do to fix it. The actual gameplay effect should work. 2) Have the same recipe create different types of arrows/bolts - maybe acid arrow or paralytic bolt (there may still be string issues, I'm not sure, but maybe not since we're not creating new ammo types) 3) Standardize everything on Poison not Acid (there may still be string issues, I'm not sure, but maybe not since we're not creating new ammo types)
BTW, Kaedrin's PrC Pack has a string in Dialog.TLK for this type of ammo, it's 242649. ("Ammo: +1d6 Acid")
And I'm working on the epic traps extension now and there seems to be no way to avoid distributing Dialog.TLK...
/just a note.
That's good to know. Suggests we leave the string as bad and make a note in the Recipe files, pending a possible future effort at making them compatible.
The problem with distributing dialog.tlk is that you cause a lot of trouble for users, since they have to figure out how to merge dialog.tlk. I don't want to distribute it for 1 line.
suggest -- leave it for possible merge w/ kPrC Pack
(my Dialog.Tlk is massively customized, btw -- used Kaedrin's as a base)
Ok folks, I think this one is ready. Would appreciate an actual review here I think. I went with the "note the known bug" path. On the plus side we now have Acid Bolts and Bullets, along with recipes for them!
All recipes here (including Gnarlthorn) need to be in the various readmes. https://github.com/kevL/TccScripts/commit/7c4cfb3ea07997d29e92db2fe106173a95991ef9