18 réponses à ce sujet

[Tazzvon]

So i am always tinkering with building a PW and i know the community has come up with a lot of altered scripts to fix the original NWN. I am wondering is anyone can give me an idea of what needs to be fixed and maybe where i can find the scripts already made to fix these items. I am looking at such things as spells which i guess are not correct as originally designed by Bioware as well as a lot of exploits i guess people use to take advantage of errors in the original build. I will only be running everything through HOTU, no CEP or other haks (unless someone can prove to me this is neccessary for a successful PW now a days). I really just want a great PW starter mod with all the neccessary fixes to make it enjoyable and less exploitable. I will probably be running NWNX2 as i see this to be a great addition that doesn't effect the client (no extra stuff the client has to do to play).

[henesua]

Fixes are a matter of taste so only you can know what you will need for your PW.

With that said, ShaDoOoW has done a great deal of work on a community patch which I have found useful,

[Tazzvon]

I was always curious about the community patch. If i run it on my server side doesn't that mean the client has to run it also, basically like a HAK?

Nevermind, I took the time to read about it. Should of done that before i questioned it LOL.

Modifié par Tazzvon, 06 octobre 2013 - 02:43 .

[Shadooow]

EDIT: eh so you got it answered by documentation already, nvm

To answer your first question however. Define need for a fix, everything can be solved via punishing which is what majority of PWs does. But imo if you just started CP is great value as you wont need to spend time to fix things you would sooner or later find out yourself.

Also check my PW starter module: http://nwvault.ign.c....Detail&id=6161
(though its mission one update because old vaut no longer lets me update the files..., but Im going to repost on new vault soon)

Modifié par ShaDoOoW, 06 octobre 2013 - 04:03 .

[EzRemake]

The amount of actual changes that need to be done before opening a PW are actually quite considerable, even without personal tastes being a factor.

-You need some sort of system to protect player accounts

-Something to clean up dead bodies and trash loot on the ground when the area is empty of PCs

-Something to clean merchants out so they don't stockpile non-default goods

-Something to stop monsters from leaving their areas and following players (players do this to grief)

-Something to make sure base stats and modified stats of a level 1 aren't ridiculous (exploiters)

-Something to do with the spawning/re-spawning of monsters

-99% of the time you''ll want a custom experience script that doesn't so harshly punish parties

-You need to know how you're going to store information about a PC for persistence, either using local variable storage on PC items, campaign variable database, or MYSQL databases

Those are just off the top of my head. You can probably find different scripts that do some of these things, but they will most likely need alterations due to their date.

Modifié par EzRemake, 07 octobre 2013 - 02:35 .

[Tazzvon]

Thank you for all the replies. EzRemake, thanks for the details. If anyone can think of anything else i would love to hear it. I would like to get the basics put in before i start actually making anything so i don't have to go back and change half the mod for something i forgot.

ShaDoOow, Can you give me an idea of what is not needed in your starter mad (i know the ares and conversation but are all the scripts needed, it looks like a few may be for demo only.)

[FunkySwerve]

ShaDoOoW - It's not letting me message you for some reason, but I was curious if you could please explain to me how to fix the "server cr@ash du(ping ex&plo^it fix (by exporting character at Acquired events)", as I am well past the need for a base module.

You save when the character unaquires something (though you want to be a little more sophisticated about it). Otherwise, they can transfer it to another character, save that character (assuming you provide that functionality in something like a 'saving pen', or onrest), and cr%ash the server if they know an ex#plo@it to do so. The unsaved character is not saved as a result of the cr)ash, so they have all the items they transferred back again. Here's a code snippet from unacquire:

    /* the object/area/possessor valid checks here are to ensure that
     * barter doesn't break with onunacquire saving */
    if (nItType != BASE_ITEM_POTIONS          &&
        nItType != BASE_ITEM_ENCHANTED_POTION &&
        (!GetIsObjectValid(oItem) ||
         GetIsObjectValid(oArea)  ||
         GetIsObjectValid(GetItemPossessor(oItem)))) {

        ForceDelayedSave(oLoser);
    }

The added checks are to prevent spamming of Exports. ForceDelayedSave is as follows, and does the same:

void ForceDelayedSave (object oPC, float fDelay=2.0) {
    if (!GetIsPC(oPC) || GetIsDM(oPC))
        return;

    int nUptime = GetLocalInt(GetModule(), "uptime");
    int nDelayedSave = GetLocalInt(oPC, "DelayedSave");

    if (nDelayedSave < nUptime) {
        SetLocalInt(oPC, "DelayedSave", nUptime);
        DelayCommand(fDelay, ForceSave(oPC, TRUE));
    } else if (nDelayedSave == nUptime + 1) {
        SetLocalInt(oPC, "DelayedSave", nUptime + 2);
        DelayCommand(10.0, ForceSave(oPC));
    }
}

Obviously that particular function relies on an incrementing uptime timer in mod heartbeat, but there are lots of ways to skin that cat.

If you're nice, you'll also do a FDS onacquire, so that items transferred aren't lost if they forget to save.

That can get a bit tricky, as there may be times when you don't want to autosave, like when they're riffling through their bank items, and it autosaves when they close the chest (another potential ex+pl*oit there). Here are the other two spots where FDS is used in our mod, within a few lines of each other in onacquire:

    /* don't save while transacting in vault */
    if (!GetLocalInt(oLoser, "Vault")              &&
        GetStringLeft(sRes, 13) != "ele_material_" &&
        GetStringLeft(sRes, 13) != "fey_material_")
        ForceDelayedSave(oAcquire);


    string sFound = "&&" + COLOR_LT_GREY + "Found ";
    string sLoser = COLOR_LT_GREY + ".";

    if (GetIsPC(oLoser)) {
        ForceDelayedSave(oLoser);

        if (GetArea(oAcquire) == GetArea(oLoser) && GetLocalInt(GetArea(oAcquire), "NO_PVP")) {
            sFound = "&&" + COLOR_LT_GREY + "Received ";
            sLoser = COLOR_LT_GREY + " from " + GetName(oLoser) + ".";
        }
    }

Funky

[Shadooow]

Tazzvon wrote...

ShaDoOow, Can you give me an idea of what is not needed in your starter mad (i know the ares and conversation but are all the scripts needed, it looks like a few may be for demo only.)

if you dont use CP you will want also the familiar conversation that is included in the mod, if you do then you dont need it (included in CP as well), all the scripts are required, most of them might be merged though (aka my module event scripts are just a placeholder that executes others so you dont need exactly those scripts and all you need is their content - ExecuteScript(...)

Modifié par ShaDoOoW, 07 octobre 2013 - 06:27 .

[EzRemake]

I looked through the starter module and was under the impression that the fix was

OnAcquired

void main()
{
object oModule = OBJECT_SELF;
object oPC = GetModuleItemAcquiredBy();
if(GetIsPC(oPC) && GetLocalInt(oModule,ObjectToString(oPC)))
{
ExportSingleCharacter(oPC);//server crash exploit fixing
}
ExecuteScript("x2_mod_def_aqu",oModule);
}


OnUnAcquire

void main()
{
object oModule = OBJECT_SELF;
object oPC = GetModuleItemLostBy();
if(GetIsPC(oPC) && GetLocalInt(oModule,ObjectToString(oPC)))
{
ExportSingleCharacter(oPC);//server crash exploit fixing
}
ExecuteScript("x2_mod_def_unaqu",oModule);
}

What you're talking about has me a little bit confused. Are you saying that the server crash exploit is a separate exploit, and that it's just used as a method of duping? Or does exporting a character while acquiring/un-acquiring an item cause a crash and subsequent dupe?

[meaglyn]

FunkySwerve wrote...

The added checks are to prevent spamming of Exports. ForceDelayedSave is as follows, and does the same:

ForceSave presumably just does the ExportSingleCharacter?

[edit: added this one] Is that the item's area or the loser's area in the unacquire test?

That can get a bit tricky, as there may be times when you don't want to autosave, like when they're riffling through their bank items, and it autosaves when they close the chest (another potential ex+pl*oit there). Here are the other two spots where FDS is used in our mod, within a few lines of each other in onacquire:

This other one you mention here is along the same lines. If you take stuff out of or put stuff in the vault
and then cause a crash you get duplicates? Or is this something different?

Thanks,

meaglyn

Modifié par meaglyn, 07 octobre 2013 - 02:32 .

[Shadooow]

EzRemake wrote...

What you're talking about has me a little bit confused. Are you saying that the server crash exploit is a separate exploit, and that it's just used as a method of duping?

yes, another abuse of that is loot reset/merchant gold reset etc, but that module related and if you have something like that you should prevent from being abused by crashing

Or does exporting a character while acquiring/un-acquiring an item cause a crash and subsequent dupe?

from the few crash bugs i know none is related to the acquire/unacquire items

FunkySwerve wrote:

That can get a bit tricky, as there may be times when you
don't want to autosave, like when they're riffling through their bank
items, and it autosaves when they close the chest (another potential
ex+pl*oit there). Here are the other two spots where FDS is used in our
mod, within a few lines of each other in onacquire:

This other one you mention here is along the same lines. If you take stuff out of or put stuff in the vault
and then cause a crash you get duplicates? Or is this something different?

Thanks,

meaglyn

I also didnt understood it. I dont get why would anyone not want to save items when put/get from persistent storage. I dont see any gap when adding items to the chest. If a persistent storage does not save when taking items from it, thats a huge exploit gap (that can be easily exploited even without server crash if its OnClose/OnOpen based) and such system should be avoided. Not saving doesnt help, character just needs to drop that item on a ground and pick it again or someone else can do that and dupe is possible again.

Modifié par ShaDoOoW, 07 octobre 2013 - 03:09 .

[MagicalMaster]

FunkySwerve wrote...

cr%ash ex#plo@it

Pardon my ignorance, but is there a reason we're using weird symbols like this?  Is it to prevent people searching for those terms or something?

[Khuzadrepa]

MagicalMaster wrote...

FunkySwerve wrote...

cr%ash ex#plo@it

Pardon my ignorance, but is there a reason we're using weird symbols like this?  Is it to prevent people searching for those terms or something?

Yes.

[EzRemake]

Hmm, are these other crash related issues fixable? I would much rather fix those instead of preventing dupe caused by them, of course, if that's even possible.

In the meantime, are the basic fix scripts that I posted for OnAcquire/OnUnAcquire sufficient, especially if you aren't using persistent storage?

Modifié par EzRemake, 07 octobre 2013 - 07:06 .

[Shadooow]

EzRemake wrote...

In the meantime, are the basic fix scripts that I posted for OnAcquire/OnUnAcquire sufficient, especially if you aren't using persistent storage?

they should be, i do exactly this in a PW i was admin of and its working without issues

though, Funky little concerned me about saving character, I assume a small efficiency change could be done since when you pick a bag of 50 items, it will run 51x OnAcquire afaik, and then 51x save character at same time... but it never made any lags in my PW and we dont have a persisten storage - players using mules

also saving character while in polymorph results into few issues, first the polymorph duration, if there was one is reset, second, all merged items are lost (because ExportSingelCharacter unpolymorph player first before save and then polymorph him back), character can also get back temporary hitpoints. From these three issues, none is fixed by the starter module nor CP. I guess I could fix that in a start module if there is demand, but its not suitable for CP because its dependant on many module events which CP avoids modifying for easy use/compatibility.

to fix crash exploits... well, all i can say is that those I know are not possible on a Sinfar, so they can be fixed. But, anytime can appear new one so better have everything handled before someone figures that out.

Modifié par ShaDoOoW, 07 octobre 2013 - 07:20 .

[FunkySwerve]

meaglyn wrote...

FunkySwerve wrote...

The added checks are to prevent spamming of Exports. ForceDelayedSave is as follows, and does the same:

ForceSave presumably just does the ExportSingleCharacter?

Sorry, overlooked that. It has a few checks, like the polymorph issue Shad mentioned:

void ForceSave (object oPC, int bDelayed=FALSE) {
    if (!GetIsPC(oPC) || GetIsDM(oPC))
        return;

    if (bDelayed) {
        int nUptime = GetLocalInt(GetModule(), "uptime");
        int nDelayedSave = GetLocalInt(oPC, "DelayedSave");

        if (nDelayedSave == nUptime)
            SetLocalInt(oPC, "DelayedSave", nUptime + 1);
    }

    if (GetLocalInt(oPC, "DebugForceSave")) {
        int nUptime = GetLocalInt(GetModule(), "uptime");

        SendMessageToPC(oPC, "<cþþþ>FORCE SAVE " + IntToString(nUptime) + "</c>");
    }

    RemoveEffectsOfType(EFFECT_TYPE_POLYMORPH, oPC);
    ExportSingleCharacter(oPC);
}

[edit: added this one] Is that the item's area or the loser's area in the unacquire test?

Sorry, here are the declarations:

    object oItem = GetModuleItemLost();
    object oLoser = GetModuleItemLostBy();
    object oArea = GetArea(oItem);
    object oPCArea = GetArea(oLoser);
    string sResRef = GetResRef(oItem);
    int nItType = GetBaseItemType(oItem);
    object oPossessor = GetItemPossessor(oItem);

That can get a bit tricky, as there may be times when you don't want to autosave, like when they're riffling through their bank items, and it autosaves when they close the chest (another potential ex+pl*oit there). Here are the other two spots where FDS is used in our mod, within a few lines of each other in onacquire:

This other one you mention here is along the same lines. If you take stuff out of or put stuff in the vault
and then cause a crash you get duplicates? Or is this something different?

That one is somewhat idiosyncratic to our vault system. We only allow saving at particular junctures during vault use - all by the bank vault system itself, to close du+ping loopholes. It all boils down to the code you're using. Some of the stuff, we only found due to heavy traffic which exposed vulnerabilities. Others are just common-sense coding measures to block easy du*ping tricks.

Funky

[FunkySwerve]

ShaDoOoW wrote...

though, Funky little concerned me about saving character, I assume a small efficiency change could be done since when you pick a bag of 50 items, it will run 51x OnAcquire afaik, and then 51x save character at same time... but it never made any lags in my PW and we dont have a persisten storage - players using mules

If you're not having issues I wouldn't sweat it. We just did it to trim overhead. You likely wouldn't notice lag on your module, since exports are - almost uniquely in nwn - asynchronous - the mod doesn't wait for them (I only know that thanks to letoscript). Saving that many times in such a short span is just really wasteful of cpu in general, but unless you're on a pretty old machine, it's unlikely to make much difference to perceived performance. Enough optimizations like that do add up in the end, however.

Funky

[meaglyn]

Thanks Funky!

FunkySwerve wrote...

    object oArea = GetArea(oItem);

That's what I guessed. The others were unambiguous.

That one is somewhat idiosyncratic to our vault system. We only allow saving at particular junctures during vault use - all by the bank vault system itself, to close du+ping loopholes. It all boils down to the code you're using. Some of the stuff, we only found due to heavy traffic which exposed vulnerabilities. Others are just common-sense coding measures to block easy du*ping tricks.

Okay, thanks. I'll revisit that when I get to putting in a banking/vault system ...

[ffbj]

First I would do it on paper carefully describing my pw with features from the general to the specific. Essentially an outline. for instance:

1.I want Mounts:
a) what types?
what current systems exist that could be used.

Then apply those questions to ever feature you want. Next overview the pre-made systems for pw on the vault and see if any have features you need or want.
Don't get caught up in too much detail. If you ever want to get anything done it is difficult if you get too bogged down in details. Use everything you can that others have made, and perhaps get some help from others. Good Luck!