Can't DML modify shotgun slug/pellet damage properties?

[6647166b3f3f4voodoo47]

well what do you know, that seems to be the case. I'm guessing the contained object needs to be in a connected cell then (I did quickly test this with a different contained object I've moved a few rooms away, and it worked. ah Dark, don't ever change).

looks like you'll have to hide them inside the crates for the time being.

[6647166b3f5d3ZylonBane]

Contains links can be to objects anywhere on the map. I just tested it with a manually created link. No idea why the script-created link is failing. Anyway, try this. Not heavily tested but it seems to work.

Code: [Select]

// Create an object and add it to a container
// Parameters in Editor/Design Note:
// - addToContainerTo: Name or ID# of container to add to; optional, defaults to self
// - addToContainerAdd: Name or ID# of object to add
// - addToContainerStack: Optional, sets a stack count on the created object
class addToContainer extends SqRootScript {
function OnBeginScript() {
local objAdd = getParam("Add");
if (IsDataSet("done") || !objAdd) {
return;
}
SetData("done", true);
local objTo = getParam("To", self);
local objStack = getParam("Stack");
local obj = Object.BeginCreate(objAdd);
Property.SetSimple(obj, "HasRefs", false);
if (objStack) {
Property.SetSimple(obj, "StackCount", objStack);
}
Object.Teleport(obj, Object.Position(objTo), vector());
Object.EndCreate(obj);
Link.Create("Contains", objTo, obj);
}

function getParam(keyRaw, defVal = 0) {
local key = "addToContainer" + keyRaw;
return key in userparams() ? userparams()[key] : defVal;
}
}

[6647166b3f986RoSoDude]

The Contains link is not failing -- the object is just visible outside the container as well. The link is properly deleted when the object is either frobbed from in-world or from the container inventory, so it's just a visual annoyance. For what it's worth, I started getting the same bug after I turned on a bunch of my other mods (I was originally testing on just SCP + my SS2-RSD mod). I'm not sure which one is tripping it up. I'll consider moving to your script anyway, since it's more fit for purpose.

Another question -- I decided to strip out all of the special recoil/degradation properties from all weapon pickups, and I wanted to make sure it's okay to simply remove the "GunKick" and "GunReliability" properties from the concrete IDs of affected pickups so they inherit the base properties from their abstract IDs. For example, in medsci2.mis.dml:

Code: [Select]

////Removes special recoil/degradation status from all weapon pickups
-ObjProp 621 "GunKick" //A Pistol
-ObjProp 621 "GunReliability" //A Pistol
-ObjProp 1372 "GunKick" //An Assault Rifle
-ObjProp 1372 "GunReliability" //An Assault Rifle
-ObjProp 607 "GunKick" //A Shotgun
-ObjProp 607 "GunReliability" //A Shotgun
-ObjProp 1377 "GunKick" //An EMP Rifle
-ObjProp 1377 "GunReliability" //An EMP Rifle

Everything seems fine to me, I just wanted to make sure this won't break something else.

[6647166b3fb4evoodoo47]

yeah, should be safe to remove those two from a concrete.

the problem with the NVscript created contained object is that the link is getting created with the Has Refs flag set to TRUE, while the correct value that makes the object not rendered is FALSE (it's been reported, hopefully it's something that can be fixed within the script). seems like this doesn't matter when you just start the game and run to the container straight away, but as soon as you save and reload, the values get refreshed, the flag kicks in, and tadaa, a levitating prism.

so basically, always make sure your modifications can survive save and load without breaking. welcome to Dark, where everything is weird, and every duct tape solution you implement will come back to haunt you later.

[6647166b3fcbbRoSoDude]

Another confusing issue with shotgun DML - for some reason my new modify script isn't getting loaded in game, but it works in the editor, like the issue I was having with the conflicting gamesys.dml from patch_ext. Only this time I'm testing my changes in the DMM subfolder, and I searched the whole directory for any conflicting script slots to no avail. Any clues? Is there any way to apply the full mod load order from BMM to the gamesys in ShockEd to see what's going on?

Code: [Select]

+ObjProp -19 "Scripts" //Shotgun
{
    "Script 0" "rsdStandardModify" //was ShotgunModify
    "Script 1" ""
    "Script 2" ""
    "Script 3" ""
    "Don't Inherit" false
}
+ObjProp -4073 "Scripts" //Hybrid_Shotgun
{
"Script 0" "rsdStandardModify" //was ShotgunModify
"Script 1" "TrashedShotgun"
"Script 2" ""
"Script 3" ""
"Don't Inherit" FALSE
}


[6647166b3fde7voodoo47]

do you have RealSG active? make sure it has lower priority than your mod.

also, that dml will kill RealSG - to make the code compatible, try this:

Code: [Select]

ObjProp -19 "Scripts" //Shotgun
{
    "Script 0" "rsdStandardModify" //was ShotgunModify
}
ObjProp -4073 "Scripts" //Hybrid_Shotgun
{
    "Script 0" "rsdStandardModify" //was ShotgunModify
}

this basically means "just edit Script 0 if it exists, nothing else".

[6647166b3ff0fRoSoDude]

Ah, I was only searching gamesys.dml files. The dbmods\shockscp.gam.dml in RealSG overwrites my Shotgun script in gamesys.dml (even though mine is a higher priority) because dbmods are loaded on top. I'll have to be more mindful of that in general (I had the same issue with dbmods\maintain.dml in SS2 Repairman overwriting my new maintenance tool changes).

[6647166b3fff3voodoo47]

why is there a shotgun script overwriting shockscp.gam.dml in a dbmods folder? RealSG has no shockscp.gam.dml, and no dbmods folder..

[6647166b400e1RoSoDude]

Er sorry, no dbmods folder, but there is a shockscp.gam.dml in RealSG 1.03, which is what I had installed. I see that RealSG 1.04 doesn't, but I guess I should make sure both are compatible.

[6647166b4025dvoodoo47]

no need, old versions are not supported. still, as long as your mod has a higher priority, a shockscp.gam.dml that modifies the shotgun script in a modfolder will not cause a problem.

the point - don't use the dbmods folder unless you absolutely have to.

[6647166b40399RoSoDude]

What is the point of the dbmods folder, by the way?

EDIT: Also, should I also make sure to overwrite the same script slot set by shock2.gam.dml in RealSG 1.04? I don't really understand how the DMLs are prioritized.

[6647166b404bfvoodoo47]

dbmods folder loads all dmls it contains regardless of their filenames, and with a higher priority than a regular modfolder. useful if you need some special shenanigans to make things work, but you need to be aware of this (as mentioned, if you need to override something that already is in a dbmods folder, you need to place it into your own dbmods folder, and give that a higher priority in the manager).

shock2.gam.dml is only active for vanilla, and can be ignored in this case.

[6647166b405e6RoSoDude]

Is there any way to make edits to psi power descriptions in strings\psihelp.str without fully overwriting any lower mods? I know you can do it in DML with ObjLookS and so on for typical archetype strings but I'm not sure about psi powers.

[6647166b406f4voodoo47]

feel free to dig around, but I'm positive that you can't dml overwrite some strings (psihelp, emails/logs, goals) - had the same issue a while ago, and had to modify strings in the end.

[6647166b408fcRoSoDude]

Something's up with the "Propagate Source Scale?" field. I was trying to figure out why SCP/ADaOB frag grenades were obliterating everything to the point that they're more effective than EMP grenades or incendiary grenades on the proper targets, and I discovered that they're actually getting damage bonuses from Heavy skill, Sharpshooter O/S, and weapon modifications (which if you recall are 2.00x and 2.28x for the grenade launcher) even though ADaOB set "Propagate Source Scale?" to FALSE. I tried to figure out why this was the case for the frag grenades and not the other types, and I noticed that frag grenades have an explicit value (FALSE), while the other grenades simply have no value for the field at all.

https://imgur.com/a/SKbS2Ee

If I add a "Propagate Source Scale?" = FALSE value to one of the other grenade projectile's Corpse links, I get damage scaling on those too. The field is totally busted! As far as I can tell, there's no way for me to replicate this effect via DML, since I can't remove the field on existing or new Corpse links.

[6647166b40a61voodoo47]

both vanilla and the latest SCP use TRUE everywhere if memory serves (the only difference is that SCP has the disruption grenade fix applied), the very reason for this being any other value causing weird things to happen.

so yeah, set to TRUE and don't touch.


//ouch, beta4 still uses the ADaoB setup. geez, we really need to get beta5 out asap. my recommendation - don't try to mess with this for now, you'll be redoing it anyway once beta5 goes public.

[6647166b40bdeRoSoDude]

Is there any way to delete the field, particularly via DML? Since the only working values are TRUE or [null], I mean.

I was going to strongly suggest reverting/reworking ADaOB's grenade setup anyway, so good to hear that's a priority. It's easy to fix the ridiculous modification damage bonuses via squirrel script, so the grenades should definitely be allowed to scale again -- the Heavy skill is less attractive in ADaOB/SCP than vanilla (even with the lame Fusion Cannon) because you get practically nothing from Heavy skill increases until 6.

Even if I have to double my efforts down the line, I think I'll mess around with it now. Irks me too much the way it currently is, heh.

[6647166b40cf4voodoo47]

I'd assume you can dml edit the link value, as long as you target the proper link by specifying the correct link id.

but good luck if you are planning to reset the beta4 setup to vanilla - you will actually have to unlink most of the corpses and relink the original ones.

[6647166b40e68RoSoDude]

Finished yesterday, was no big deal -- restored all grenade projectiles to vanilla explosions (except Disruption grenades) and fixed the crazy damage bonus from modification via script. ADaOB's comprehensive changelist helped a lot. I'll adapt as necessary if SCP does something similar.

Also, to answer my previous question, I found no method of setting a link with a Null value for "Propagate Source Scale?" via DML. No matter what I do it always ends up FALSE -- that includes trying to set an existing link's field to Null, or deleting the link and creating a new one (with brackets empty or trying to set the value to Null). Works in the editor, but not DML. Really ought to be fixed in the next version of NewDark.

[6647166b40ff1voodoo47]

because you shouldn't be setting it to null/unset, it should either be false or true (if I understand things correctly). so the dml system is doing it right.

the current SCP disruption grenade fix is very simple, and is identical to the GOG/steam/tool fix;

Code: [Select]

// fix for the disruption grenades that are supposed to be strong but in fact aren't
-StimSource -1309 "Standard Impact"
+StimSource -1522 "Standard Impact"
{
  Intensity 35

  Propagator Radius
  {
    Life
    {
    "Flags" None
    "Period" 1
    "Max Firings" 1
    "Intensity Slope" 0.00
    }

    Shape
    {
    "Radius" 6.50
    "Flags" Line of Sight (raycast)
    "Dispersion" None
    }
  }
}this basically just finally fixes the original mistake (the stim being assigned on an incorrect archetype), and magically fixes them into what they always were supposed to be - a (much) stronger, rarer version of the standard grenades.

[6647166b41143RoSoDude]

Either "Propagate Source Scale?"=FALSE needs to be fixed, or the DML system needs to allow for Null values. Right now there's no way to link a corpse to a projectile via DML without inheriting damage scaling, which is a problem.

Right, I retained ADaOB's 68 damage on Green Core (though I actually swapped to the SS2Tool patch values for the Shape). The rest I essentially reverted to vanilla.

[6647166b4126bvoodoo47]

I'm thinking you are not supposed to be doing that (not inheriting scaling via the null value).

the 68 is me, not recognizing the underlying issue at the time, eyeballing it into what I thought could output the intended damage. comparing it to the proper fix, I was only maybe 5-10% off, which isn't bad.

[6647166b41406RoSoDude]

ADaOB already moved the Disruption Burst damage stim to Green Core (-1522) with an intensity of 75. The only other difference with SS2Tool is the 8.0 radius and linear dispersion. Isn't that already fixed? Why the need to mess around with the intensity? Or was the dispersion also causing problems?

Regardless, I did some testing and calculation and think 68 damage is around where I want it to be -- Disruption grenades should be able to compete other grenades when they have damage bonuses. Reverted EMP grenades will be a bit more potent vs bots with +45% skill bonus, 15% sharpshooter bonus, and a fixed +25% bonus from mods, and reverted Incendiary grenades will get the edge with all that plus +25% research bonus, which feels just about right to me.

[6647166b4152dvoodoo47]

ah, the radius, right - that had to be increased a bit so the disruption grenade damage could reach the Many brain. apart from that, the values are vanilla, just assigned to the correct archetype as mentioned.

feel free to tweak of course.