Attachment | Size |
---|---|
![]() | 442.18 KB |
![]() | 3.94 MB |
![]() | 79.91 KB |
![]() | 1.71 MB |
![]() | 1.35 MB |
![]() | 1004.09 KB |
![]() | 31.13 KB |
![]() | 508.01 KB |
![]() | 1 MB |
![]() | 114.68 KB |
![]() | 14.28 KB |
The Aielund Saga Act III - Return of the Ironlord |
90.8% |
Tales of Arterra - The Lost |
85.2% |
Lankhmar Nights |
93.1% |
Honor Among Thieves |
90.3% |
Madness and Magic |
93.2% |
Lords of Darkness 3 - Alanya's Secret (V2.0) |
90.7% |
Shadewood |
96.6% |
Aribeth's Redemption - Chapter Two |
93.1% |
Gladiatrix |
88% |
Demonheart - Chapter I |
97% |
Gladiatrix III - The Hand of Destiny |
86.7% |
The Aielund Saga Act IV - The Fall of Aielund (Part One) |
95.3% |
Bloodright - The Blood Royal |
90.4% |
Snow Hunt |
91.3% |
Vampire – Heaven Defied |
82.2% |
If anyone has trouble using the Training system in this module and hasn't figured out that I uploaded it without having the ModuleOnLevel script in its slot, well... Please go into Module Properties - Events and go down to the blank slot for OnLevel - select "wrap_mod_onlevel". Thanks - I continually surprise myself
Just a note that an update to this basemodule is coming one of these days. Numerous improvements and bugfixes. It will be in two forms, a new basemodule and also an update patch. Be safe!
Uploaded today. I'm sure it will have problems. Please feel free to let me know if something particularly irks you. Be safe
Looks interesting. A few years ago I tried out some of your CRP adaptions so I'll take a gander at this.
On a side note, please zip all files as that preserves the date -- being a poor man's version control system.
Is it compatible with CEP 2.65 ?
And when I export all ressources of your mod, I have missing ressources :
x2_inc_crafold.ncs
start_chk_lv.nss
stage_maker.ncs
sparky_inc.ncs
pwtrap_inc_parts.ncs
pf_facade.ncs
pf_bio_persist.ncs
pf_aps_sql_inc.ncs
mcs_inc.ncs
leveler_inc.ncs
inc_skill_desc.ncs
npcact_wrap1.nss
npcact_wrap2.nss
npcact_wrap3.nss
npcact_wrap4.nss
npcact_wrap5.nss
npcact_wrap6.nss
npcact_wrap7.nss
npcact_wrap8.nss
npcact_wrap9.nss
npcact_wrapa.nss
npcact_wrapb.nss
npcact_wrapd.nss
npcact_wrape.nss
gen_inc2math.ncs
never.nss
dm_sm_inc.ncs
damage_inc.ncs
crp_inc_coins.ncs
00_checklist.ncs
It should be, as it doesn't use any haks or special tlk files. It does contain edited versions of many CEP related scripts and objects, including Malishara's Sparky scripts. As these are I think just in the sample modules or erfs, I would be careful what is overwritten when importing.
As to the missing resources, there may have been a few older blueprints that called to non-existant scripts. As far as I know, none of those are required for the module to run correctly. If I get a chance, I will review the blueprint files and remove any extraneous script (*.ncs or *.nss) or convo calls. Also, many include script files only have the one *.nss file and don't have the other *.ncs file.
edit - I was curious as to who was looking for the npcactivity scripts, and it ends up being the horses in the DM-only "paddock" area. As these are only here to have their horse likenesses be copied for the horse system, the attached scripts are never called in regards to the player. I will go in and edit them for whenever I may upload an update in the future, though.
Thank you for your response and your activity on NWN. I love your work, very clean and very well explained. And so far I haven't seen any bugs on NWN EE, which you should test, it's fun and puts a layer of players back on this wonderful game for the next 10 years ^^
I'm sorry, but I can't get the "training" part of the mod to work. Could you put in the module an example with an NPC doing this?
EDIT after somes tests :
I put the right class to the trainer, the script on trainmod_onlevel seems to work, I have activated the script in module_variables, I get 50PO removed when I ask to be trained,
But, nothing happens with
TrainPC(oPC, nTrClass, nPCLevel, oNPC);
in trainmod_train
Same probleme with placeable and train_dev. On the other hand, with the trigger (train_toggle, train_toggle_x) it works.
Thank you for your work
EDIT 2 :
I found the problem. In trainmod_train, at the end of the script, a small error occured.
change the line with the else to :
// else GenericCoinsMakeChange(oPC, nCost);
EDIT 3 : with the { } after all if or else, it's even better (encoder reflex ;) )
....
if(CRP_USE_COINS!=1)//NWN Gold
{
TakeGoldFromCreature(nCost, oPC);
}
//else {GenericCoinsMakeChange(oPC, nCost);}
TrainPC(oPC, nTrClass, nPCLevel, oNPC);
}
EDIT 4 : Another problem. The impression that you can train with a trainer with a class you are not allowed to take. This will suddenly cause a loss of level because the script then waits for us to level up with the class chosen with the trainer, but this is not possible.
EDIT 5 : Ok that's fine, then just go talk another trainer, this will delete the bad training taken before. Good to know.
Sorry I missed all of this - glad you were able to sort it out. I will need to look at my copies and fix them!
Actually, in hindsight, I had imported the train scripts very early on in my building of this module. The commented out scripts actually don't need to be commented out - they call dummy scripts in the crp_inc_merchant file (via the train_inc and the crp_inc_coins) which I think I added after I got the train scripts into the module.
So that section can look like:
if(CRP_USE_COINS!=1)//NWN Gold
Hi i continue to investigate your scripts. I just tested Placeable Portables, it's really super interesting.
Here is an example of use on my own projects (OnEntering Trigger with Variable "pp_waypoint"). The possibilities are enormous.
Here for add persistance in the scripts
#include "pp_inc"
void main()
{
string sLocation = GetLocalString(OBJECT_SELF, "pp_waypoint");
object oWaypoint = GetWaypointByTag(sLocation);
location lLocation = GetLocation(oWaypoint);
object oPC = GetEnteringObject();
string sTag;
object oItem1 = GetFirstItemInInventory(oPC);
object oItem2;
while(oItem1!=OBJECT_INVALID)
{
sTag = GetStringLeft(GetTag(oItem1),5);
if(GetHasInventory(oItem1))
{
oItem2 = GetFirstItemInInventory(oItem1);
while(oItem2!=OBJECT_INVALID)
{
sTag = GetTag(oItem2);
if(sTag=="ppig_")
{
ppItemGeneric(oPC, oItem2);
pp_createcopy(oItem2, lLocation);
}
}
}
else if(sTag=="ppig_")
{
ppItemGeneric(oPC, oItem1);
pp_createcopy(oItem1, lLocation);
}
oItem1 = GetNextItemInInventory(oPC);
}
}
For persistance, an another script is necessary for respawn placeable and destroy it after delay. See here : https://nwn.fandom.com/wiki/Respawn_chest
I also looked at AID Tools and saw that there was a "canpush" variable too to move a placeable. But I have not yet tested.
EDIT : a little problem, anyway, with this system. When I click on the portable placeable too quickly, I don't produce 1, but 2 items in my inventory (maybe even 3 if I'm very fast). The placeable disappears too slowly and I have time to click on it again before it's destroyed. By doing it several times in a row, by putting them back down, I can therefore multiply the number of placeable units to infinity. It poses a problem.
EDIT2 : The solution with your OffScript variable :
void main()
{
object oPC = GetModuleItemAcquiredBy();
object oItem1 = GetFirstItemInInventory(oPC);
object oItem2;
string sTag;
int iItem = 0;
while(oItem1!=OBJECT_INVALID) {
sTag = GetStringLeft(GetTag(oItem1),5);
if(GetHasInventory(oItem1)) {
oItem2 = GetFirstItemInInventory(oItem1);
while(oItem2!=OBJECT_INVALID) {
sTag = GetTag(oItem2);
if(sTag=="ppig_") {
iItem=iItem + 1;
if (iItem>1){
DestroyObject (oItem2);
iItem=iItem - 1;
}
}
}
}
else if(sTag=="ppig_") {
iItem=iItem + 1;
if (iItem>1) {
DestroyObject (oItem1);
iItem=iItem - 1;
}
}
oItem1 = GetNextItemInInventory(oPC);
}
}
The check with oItem2 (for bottomless bag for example ) is maybe not necessary. But this script resolve the bug.
Thank you for all these great comments! Now that you point it out, clicking the target object twice (or more) before it disappears is a problem. I suppose the scripts could look for a variable if it has been clicked already with a return, followed by setting that variable. I will look at that. The timing of things being destroyed involves making sure the variables (and any inventory) get moved where they are supposed to go before destruction occurs. However, setting a variable makes some sense. I will play with that.
The AID canpush is best used when the targeted object has a unique resref blueprint. Otherwise, non-AID variables will not be copied over as far as I can tell. I have tested it, but not done any serious building with it.
I will look at these other edit ideas, when I get a chance. Thanks again!
Glad to help you. I have a question, still on the portable placeable system.
The generated tag is in the form ppig_xx
Is it possible to have a different TAG for the system with rope (rope_xx for example) and the generic portable placeable (ppig_xx) because that created some problems, one being intended to be kept in the inventory, the other being rather used occasionally I think in games. I tried to modify the scripts, but there is so much that it was complicated, not succeeded without breaking the system.
Thanks
EDIT : A solution, but not very elegant.
- In crpi_rope, change
string sPPTag = "ppig_"+IntToString(nPPCount);
to
string sPPTag = "rope_"+IntToString(nPPCount);
- In pp_inc
copy all function
object PickUpObject(object oPC, int NoOffScript = 0, int NoTest = 0);
to
object PickUpObjectRope(object oPC, int NoOffScript = 0, int NoTest = 0);
and change the following line :
string sPPTag = "ppig_"+IntToString(nPPCount);
to
string sPPTag = "rope_"+IntToString(nPPCount);
- Copie the pp_place_up script to another name and change the PickUpObject function to PickUpObjectRope
- In the toolset build, change the Rope and Hook Placeable to OnUsed your new script
- In wrap_mod_unacq
add
if(sLeft=="rope_")
{
ppItemGeneric(oPC, oItem);
}
And I think I forgot nothing
I am wondering what the particular issue is that you are trying to avoid. If you want to get the rope by a specific tag for another reason, you can get it's resref instead of its tag.
However, in regards to your puzzle the scripts you haven't edited are the "ladderon" and "ladderoff" scripts. They are defined by variables on both the "rope and hook" placeable and the item. The regular version use the PickUpObject function, so you would just need to change the calls to your PickUpObjectRope function. However, this may break non-rope climbing objects (like the portable ladder).
The pp_inc functions look for OnScript and OffScript variable strings on the objects being put down/picked up. If these are present, the system will run these scripts. The ladderon and off scripts are the scripts that run the whole climbing system setup. However, you could make your objects run any script using these variable defined calls. The overall concept was that any portable object from the system could be flexible enough to run a system. The portable ladder and rope/hook process are examples of climbing objects. I endeavored to have all portable objects use the same basic scripts and allow for variation by using the variable calls.
Hello,
OK, thanks for the details. It's not to avoid a bug, you have nothing to do with it, but just that I do not find it practical to have all the portable placeable systems, however different they are, with the same TAG without differentiation. Especially in the case of the implementation of a persistence system in its module, which complicates things a bit.
For example if I want a puzzle using portable placeable to reset I have to check the player's inventory if they don't have the item and put it back in placeable. Except that having the same tags will reset absolutely all portables placeable systems, not just this puzzle, which wouldn't be a problem in itself if some like the rope hook didn't have another use, rather intended to remain in inventory.
Anyway, thanks for the clarification, it helps me.
PS: by the way I'm French, sorry if my English is not perfect
No problem at all - I encountered a similar issue in my designing - instead of checking for the tag to compare to, you can check for the resref:
object oItem = GetFirstItemInInventory(oPC);
sRes = GetResRef(oItem);
if(sRes=="rope_hook")
{
//does have the rope_hook still
}
Don't know if that would work for you, but that is how I went about it.
I hadn't even thought about it. Thanks.
Hello,
I continue to explore your scripts.
A quick question about OMW. On the placeable, in your text you do not give information about High Jump and Long Jump (SKILL 6 and 7). And if not, would there not be, for a simple jump, the possibility of changing the animation? She's awful. The player jumps from 20m high to the ceiling. Not very realistic.
Otherwise, maybe, a suggestion for improvement on the trigger. In the int DSTCheck, add :
location lLocation ;
string sLocation = GetLocalString(OBJECT_SELF, "OMW_WP_LOCATION");
if (sLocation == "") {
lLocation = GetLocation(OBJECT_SELF);
}
else {
lLocation = GetLocation(GetWaypointByTag(sLocation));
}
oCreated = CreateObject(iObjectType, sResRef, lLocation, TRUE);
...
oCreated = CreateObject(iObjectType, sResRef, GetLocation(OBJECT_SELF), TRUE);
Maybe also add the saving throw detail on a success as text info.
Thank you.
Thanks for exploring this module!
I had not noticed that the placeable description was incomplete - I think it was originally the placeable that came with Old Man Whistler's script which I got from the Developer's Companion volume 1 - which now that I look isn't on the vault. I will see if I can find my archive of it and post it. Of course, the description is in the script, but that is an extra step and opens the editor. I will look into updating that in my next version. The real modification I did was change it to an invisible placeable instead of a rock. Looking at my How-To document, it also doesn't talk about options 6 and 7. I will update that document, too.
As to the jump animation called, I don't believe there is a good jump animation in unmodified NWN. One can find them in animation hak files, so the edit of the call would be adjusted to fit that. Since this is a no-hak required thing, the scripts go with the best we can find.
Your edit to the trigger makes sense - my only edit to that section involves calling a script instead of an object so having more control over the location of the created object makes sense. I actually rarely use the object creation option of this script, likely for that reason. What I more often do is use the "vg_trigger" script (the UQS trigger) and use its Sparky options to call additional scripts, including the "trig_skill_desc" script to provide information and such. Then I use the item creation options in the UQS trigger to create objects.
Hi and yes me again ^^
I have some questions about Arcane Spell Components.
First, not all spells are present. I think only half of the spells are listed and therefore require a component. Why ?
Then there are some listed spells that cause concern. Some just don't exist. Here they are :
- CLOAK OF CHAOS
- DARKVISION (it's not a spell, it's a feat)
- SHIELD OF LAW
A few exist, but not in their greater version
- GREATER EAGLE SPLENDOR
-GREATER BULLS STRENGTH
-GREATER CATS GRACE
-GREATER FOXS CUNNING
-GREATER OWLS WISDOM
Finally, concerning the following spells, they do not exist in detailed version, only in version "against the alignments"
-HOLY AURA
-UNHOLY AURA
-PROTECTION FROM CHAOS
-PROTECTION FROM EVIL
-PROTECTION FROM GOOD
-PROTECTION FROM LAW
-MAGIC CIRCLE AGAINST CHAOS
-MAGIC CIRCLE AGAINST EVIL
-MAGIC CIRCLE AGAINST GOOD
-MAGIC CIRCLE AGAINST LAW
Here, I think that concerning these spells it requires some additional explanations.
Thanks...
These are good questions - I was under the impression these were only the spells that needed a material component - verbal or somatic were not involved. I did not build the spell component system, I just imported it (PHB Material Component's System). The script that is concerned is the "x2_pc_umdcheck" lines 85-190. If new spells are to be added this would be where they can be edited. To be honest, I haven't explored what was and was not there recently. I will look into what you pointed out, though.
thanks for the replies, as always. Regarding the components, I did not find these in the palette:
- Skeleton Knuckle (SCARE, CONTROL UNDEAD)
- Fine Agate (DARKVISION)
The knuckles "NW_IT_MSMLMISC13" are a regular NWN item as opposed to custom ones and actually drop from skeletons as treasure. The Fine Agate is the Fine Fire Agate item "cnrGemFine002" and should be there.
Hi, me again ^^
In the death system, maybe specified that if you want to respawn in place (for tests for example), you must put in module_variables
DeathSystem to 1 (not 0)
and
RespawnWP on something, anything, but not nothing "" or the TAG of your respawn WP
because it's not very clear and I searched a bit.
Hmmm. Setting the system to "0" turns it off and runs the normal "nw_o0_death" script. Setting the system to 1 revives at spot - or it should. Did you turn off the death GUI panel and just go straight to respawn, or is it going to the GUI screen and you press "respawn"? When I get a chance, I will playtest what you said above and see. Thanks!
EDIT - So I was able to test your thoughts and found the issues. I will work on them - there are two I can see. In the "wrap_mod_respawn", it should run a check if the death system is on or not. If it is zero, it should run the default NWN respawn script instead. That fixes that issue. However, setting the death system to 1 is having a problem. After futher testing, I have these fixes. In the "wrap_mod_respawn" script, replace it with---
EDIT 2 - Okay, I found the issue, I think. Line 197 of "respawn_ms" should have a logical AND"&&" instead of a logical OR "||".
if ((nDeath >= 2) && GetIsObjectValid(GetObjectByTag(sDestTag)))
Then in the else later on, comment out the if statement
Thanks
I tested and it seems to be ok now
Hi.
In the Climbable Pit Trap Triggers, I think the reset gets stuck when using the grappling hook and rope. It's normal, you will say to me, but the problem is that it does not start again when you remove the grappling hook and rope from the pit. Ideally, the reset would resume, after we remove it.
Thanks
The reset of the pit trap is called from a pseudo-heartbeat in the initial "pit_fall" script. If for some reason you save and load a new game after the pit is created, I could see the reset not occurring - I don't think a save would load the state of the previously called script. However, there could be other reasons the pseudo-heartbeat gets cancelled out; none come to mind right now.
I think I will solve the problem anyway by adding a trigger around the pit, which brings the rope and the grapple back to the player's inventory and will therefore also call this ResetPit () function again.
I specify that I work on a persistent world.
Thanks.
The problem comes from this condition in ResetPit I think : if(oLadder==OBJECT_INVALID && oLink==OBJECT_INVALID)
EDIT : In fact I think that even when you pick up the Climbing Down and therefore your grapple rope, the system considers that it is still present since if I try to put the grapple rope back on top, then I have this message: There is already a climbing device connected here (which is wrong). So the reset can not work either because that considers that there is always an active Climbing Down.
EDIT 2 : The problem only arises in the event that I fall into the pit and then use my rope from the bottom. If I don't fall into the pit and use my rope from above, the system works perfectly.
EDIT 3 : In ladderon : add || GetLocalObject(oTarget, "Bottom")!=OBJECT_INVALID line 107 and 195 fixed the bug
if(GetLocalObject(oTarget, "Top")!=OBJECT_INVALID || GetLocalObject(oTarget, "Bottom")!=OBJECT_INVALID || oLink != OBJECT_INVALID)//One or the other
{
SendMessageToPC(oPC, "There is already a climbing device connected here!");
PickUpObject(oPC,1,1);//Run by this object, on the PC, NoOffScript, NoTest
//We do pick this back up, since we are by a potential target and don't want clutter
return;//this edge is already used
}
...
if(GetLocalObject(oTarget, "Top")!=OBJECT_INVALID || GetLocalObject(oTarget, "Bottom")!=OBJECT_INVALID)
{
SendMessageToPC(oPC, "There is already a climbing device connected here!");
PickUpObject(oPC,1,1);//Run by this object, on the PC, NoOffScript, NoTest
//We do pick this back up, since we are by a potential target and don't want clutter
return;//this edge is already used
}
For the trigger around the pit, once the bug has been repaired, it is immediately easier. Here is what I did (if it can help other people)
void main()
{
object oPC = GetEnteringObject();
string sTag;
object oItem1 = GetFirstItemInInventory(oPC);
object oItem2;
int iItem = 0;
int iRope = GetLocalInt(oPC, "iRopeTrig");
if (GetIsPC(oPC)) {
while(oItem1!=OBJECT_INVALID) {
sTag = GetStringLeft(GetTag(oItem1),5);
if(GetHasInventory(oItem1)) {
oItem2 = GetFirstItemInInventory(oItem1);
while(oItem2!=OBJECT_INVALID) {
sTag = GetTag(oItem2);
if(sTag=="rope_") {
iItem = iItem + 1;
}
}
}
else if(sTag=="rope_") {
iItem = iItem + 1;
}
oItem1 = GetNextItemInInventory(oPC);
}
if (iItem >= 1){
SetLocalInt(oPC, "iRopeTrig", 1);
}
if ((iItem == 0)
// && (GetLocalInt(oPC, "iQueteBospirPlageFalaise") >= 100)
&& (iRope == 1)) {
object oNearestObject = GetNearestObjectByTag("climbtop2", OBJECT_SELF);
AssignCommand(oPC, ClearAllActions());
AssignCommand(oPC,ActionInteractObject(oNearestObject));
SetLocalInt(oPC, "iRopeTrig", 0);
}
}
}
I also changed the ppig_ tag by rope_ (see before)
EDIT : this is better, but sometimes the system is instable. Maybe because therie is a difference between the "Rope and Hook Top" and the "Climb Down". With the pit, it should be the same.
Thanks! I will look at this and fix the scripts accordingly.
Update - So I have worked on these edits (Thank you for the ladderon edits!) and an idea, stemming from your situation above, completed forming in my tiny brain:
In a non-persistent module you trigger a resetting pit and fall down. You save upon landing. The pit resets above you. You exit the module and reload the save. The pit will not reset.So I need a script that checks if a resetting pit is open when a module starts up, the script triggers the pit to reset. I will puzzle this.So after some testing, I found the trap fired correctly without editing the script. However, I started with the pit already set up in this module, adding the RESET variable to it. The trap wouldn't reset and so I started on the editing path. After edits, it still was failing. So I looked at the trigger. I had originally drawn it starting at the middle, going to the edge and making the circle shape. This was because originally the pit was created from the traps location. While the pit trap evolved, the pit would be created at the target's location, then I added the option to mark the pit location with a waypoint. However, I never went back and redrew the trigger for the pit in this basemodule. Once it was redrawn as just a circular structure, the reset started to fire correctly.
Then I found something I must have forgot; the pseudo-heartbeat scripts I use with DelayedCommand calls are included in saved games. For testing, i would trigger the pit and fall down. Pause the game, save the game. I would connect a climbing device to the pit and wait for a period of time for the pseudo-hb to pulse. Then I would remove the climbing device and save another instance. After waiting, the pit reset. I would reload the 2nd save and remove the climbing device. After the time period, the pit would reset. I would load the first save game and see if reset without putting the climbing device on. And finally I would load the first save and put the climibing device on. After waiting, I would remove the device and wait for the reset, which occurred.
Anyway, thank you for your consistent testing and your interest in these systems.
Cool, I can't wait to see it ^^
for the bug I made a mistake in my correction with the ladderon script line 107.
if(top || bottom || link)
This is better :
if ((top || bottom) && link)
Hello,
I think in the "staff_trigger" script making the placeable "plc_weathmark" permanent is not a good idea. Here is a suggestion:
void CleanUpTrap(object oTrap, object oActivator, location lTrap, string sTagTrap)
{
object oMark = CreateObject(OBJECT_TYPE_PLACEABLE, "plc_weathmark", lTrap, FALSE, sTagTrap);
DestroyObject (oMark, 60.0f);
SetTrapActive (oTrap, FALSE);
if (GetTrapDisarmable(oTrap)) SetTrapDisabled(oTrap); // some traps are not disarmable, like pit traps
}
and in void OnActivate, add:
line 79: string sTagTrap = GetTag(oTrap)+"_fire";
line 155: DelayCommand (2.0, CleanUpTrap (oTrap, oActivator, lTrap, sTagTrap));
Good idea!
Hello, in crp_spk_doors, I think that the possibility of being able to spike any door is not compatible with multiplayer ^^
Maybe add a variable test to only be able to spike some specific doors. That's what I did on my side anyway.
int iFlagDoor = GetLocalInt(oDiscover,"SPIKE_DOOR");
if(GetIsObjectValid(oDiscover)) {
if(iFlagDoor==0){
SendMessageToPC(oSearcher, "You can't spike this doors.");
return;
}
else {
if ((GetDistanceBetweenLocations(GetLocation(oDiscover), lLoc) <= 2.0f))// && GetLocalInt(oDiscover, "LISTEN_DC_MODIFIER") != 0)
{
oDoor = oDiscover;
//SetLocalObject(OBJECT_SELF, "PAW_TARGET", oDoor);//this was for PAW scripts
}
...
I was wondering if it was possible with the throw script for a trigger to detect if an object had been thrown on it. The possibilities of mechanisms would be enormous.
I feel like you left the option to do this when I watch the script, but I'm not sure how to do it
For example with :
if (GetTag(GetEnteringObject()) == "throwbag")
{...}
nothing is happenning.
EDIT :
Ok I found the problem. At the very end of the script, add the EnterTrigger function provided for this purpose.
DelayCommand(0.1, MoveItem(oThrow, oDrop, lTarget, oPC));
DelayCommand(0.2, EnterTrigger(oDrop, lTarget));
DestroyObject(oDrop, 1.8);
Now your triggers detect any thrown object. Lots of puzzle possibilities. :D
EDIT 2 sometimes EnterTrigger does not work. I do not understand the reason. In one area it will work and exactly the same elsewhere will not work. Weird.
What you have makes great sense - I had been thinking of it from the other direction - the PC throwing at a target, or the PC throwing at a trigger. I had not thought about throwing at a target inside a trigger. Your fix seems to do that. I will play around with it.
I have been puzzling over the inconsistency with both the throw and the prodding scripts (which basically use the same technique). Basically the prod or the item catcher is a creature who then moves in the trigger. Typically for NWN, even if the creature is created inside the trigger, they have to move to set it off. For the prod, the creature will also attempt to use a trapped object (door or placeable) to set it off. With the item catcher, they then set the object down.
For some reason, the triggers don't always fire. I have done a lot of debug testing and not yet found the reason. There are many strange errors that occur in NWN which sometimes I accept and move on.
However, I have noticed the complexity of the trigger does matter. If the trigger is not entirely flat, or has too many nodes, scripts don't like firing with it. Maybe, try to redraw the trigger and see if it fires more regularly.
Yes thank you for your answer. Sometimes there are very strange behaviors without a consistent explanation with the triggers. In the area where this was a problem, I worked around the problem on my puzzle by using a large invisible placeable and coding directly into the throw script using oTarget = GetSpellTargetObject () instead to detect it. It all comes down to the same thing in the end. It also has the advantage of being able to recover the oPC activator.
Hello,
In map_digitup2, on line 49, remove the "string" declaration.
if(sTag != "map_digitup2")//"map_digitup2_<ident>" it is an extended tag for unique id
{
int nTag = GetStringLength(sTag)-13;//the front of the tag is 13 letters long
string sIdent = GetStringRight(sTag, nTag);//This gets the remainder of the tag
}
otherwise adding with unique tag and IDENTITY will not work.
You are right about the redeclaration being unneeded, but was it actually failing? I recall myself actually able to get this to work in my testing mods. Either way, it is on the list of fixes. Thanks!
With NWNEE the script no longer works with a double declaration. Beamdog is more restrictive.
That is good to know!
Always in map_digitup2, in the script the variable for new tag is ITEM1NEWTAG, ITEM2NEWTAG etc... but in the WP_SHOVEL_MAP it's ITEM1TAG, ITEM2TAG etc...
I took a long time to understand why it was not working. The difference is not immediately obvious ^^
EDIT : There is also a problem with this condition in scripts when you use the extra tag system:
if(GetUserDefinedItemEventNumber() != X2_ITEM_EVENT_ACTIVATE) return;
You must also add what you have added in wrap_mod_onact, otherwise the first use of the item is blocked (return)
Therefore :
object oSelf = GetItemActivated();
string sTag = GetTag(oSelf);
if((GetUserDefinedItemEventNumber() != X2_ITEM_EVENT_ACTIVATE) && (GetStringLeft(sTag, 13)!="map_digitup2_")){
return;}
same with map_digitup and shovelit
Wondered about that! Updated those three scripts.
Hello, I have a problem with your NW_C2_DEFAULT9 modification. The X2_L_SPAWN_USE_AMBIENT and X2_L_SPAWN_USE_AMBIENT_IMMOBILE flags appear to be broken. If I go back to the default nw script, it works, but not with the Mannast script.
Anyway this is a big problem because this flag is also the default behavior of all creatures resulting from an encounter, which does not work.
I checked this is not from nw_c2_default1, even though this line looks weird to me too:
if (GetHasEffect (EFFECT_TYPE_SLEEP) && 0) // disable this if using aww_WalkWayPoints
Have you changed anything on this with AWW?
Besides, the whole description of the "Advanced Walk Waypoints and Puttering" system is really not very clear, I think you should rewrite it and explain it better.
Thanks
EDIT :
Well, I investigated the problem a little.
It comes from this line: SetWalkCondition (NW_WALK_FLAG_CONSTANT);
And I also think that it is not necessary to make aww work, since we have the possibility of triggering this line of script via variable (this being the default value).
Note that I did not understand why the lines
SetSpawnInCondition (NW_FLAG_DAY_NIGHT_POSTING);
SetSpawnInCondition (NW_FLAG_AMBIENT_ANIMATIONS);
are uncommented.
For the first, maybe it's necessary to make aww work, I don't know, but for the second, it duplicates the flag X2_L_SPAWN_USE_AMBIENT which is not logical (especially since I just say so, it doesn't work with the SetWalkCondition line).
I'll look into this - possibly this is my adjustments, but it could be something that was there from the import of AWW.
Have you any date of your new version ? ^^
Wish I could put a finger on it - real life has been very consuming and I have not been able to spend any serious time on anything NWN related.
I understand. I hope I have helped. I haven't finished testing all of your scripts. About half.
Thanks for the changes in v0.3. ;) After a little break, I'm going back to it too :)
Hello,
With the dig and bury persistent system, I think there is an interaction bug with the map WP who creates objects, in some circumstance (open the inventory hole, an item is created, no take the item, close the inventory and re-open the inventory hole, you have now 2 items). So I suggest adding in the shovel_oc script
int nCount=0;
object oWPTag = GetNearestObjectByTag("WP_SHOVEL_MAP",oPC);
string sItem1TAG = GetLocalString(oWPTag,"ITEM1TAG");
if (GetTag(oItem) == sItem1TAG){
FloatingTextStringOnCreature("You see an object", oPC);
SetLocked(oChest, FALSE);
AssignCommand(oPC,ActionInteractObject(oChest));
CevForceCompleteActions(oPC);
return;
}
Perhaps another method would be to not create the object in map_digitup2 if it already exists or to destroy the inventory before creating the object.
Pages