68 réponses à ce sujet

[ffbj]

Here is one for EK to look at:

void main()
{
object oPC = GetLastAttacker();
object oDatabase = GetItemPossessedBy(oPC, "database");
object oKey = GetItemPossessedBy(oPC, "KeyHovelKey");
object oDoor = OBJECT_SELF;
string sHovelOwner =  GetName (oPC,FALSE);
string sDoorName =  (sHovelOwner + "'s Hovel");
string sDoorName1 =  GetName (oDoor,FALSE);
    {
      if ((sDoorName1 == sDoorName) && (GetIsObjectValid (oKey)))
                  {
                  FloatingTextStringOnCreature("Your hovel door opens!", oPC,TRUE);
                  SetLocalInt(oDatabase,"HovelO", 1);
                  ActionUnlockObject(oDoor);
                  AssignCommand(oDoor, ActionOpenDoor(oDoor));
                  AssignCommand(oPC, ClearAllActions(TRUE));
                  return;
                  }
         //if the door name and the owners name match and they have the key open door.
         if ((GetLocalInt(oDatabase, "HovelO") < 1) && (GetIsObjectValid (oKey)) && (GetName (oDoor) == "Door"))
                  {
                  FloatingTextStringOnCreature("Your hovel door opens!", oPC,TRUE);
                  SetLocalInt(oDatabase,"HovelO", 1);
                  ActionUnlockObject(oDoor);
                  SetName (oDoor, sDoorName);
                  AssignCommand(oDoor, ActionOpenDoor(oDoor));
                  AssignCommand(oPC, ClearAllActions(TRUE));
                  }
        //key and Hovel Ownership ownership ok.  Now check that the door is fresh
        //that is unowned by another owner.  Thus the check for the Door name.
        //Original name of door must be Door.
       else if ((GetLocalInt(oDatabase, "Hovel0") > 0 ) || (sDoorName != sDoorName1))
         {
         {FloatingTextStringOnCreature("You already own a hovel, or wrong hovel!", oPC,TRUE);
         return;
         }
         //name on door an PC don't match plus local int indicates Hove Ownership

 }
}
}
This is not persistent, it is though with the rent a hovel program. So your get your name on the door temporarily. I just used bashing instead of on fail to open.

Modifié par ffbj, 31 août 2010 - 11:33 .

[Calgacus]

Thanks,
Mabe I'll go with this algo:
1)when the labyrinth gets initailized all doors get cloased and locked -
2) labyrinth gets craved by unlocked some doors,
3) when player opens a door a var gets set on them - DoorControl = 1
4) when a player enters a room-trigger the var gets checked
4b) if the var ==1 then the players number of moves left gets decremented and the var gets reset to 0.

No more need to mess with the doors.

The alternative is to check the var whenever a door is opened and then close the door immediately if DoorControl == 1.  Then if the player entes a new area ( ie other than the last area trigger he was in) then that means the player has backtracked and will need to have his moved decremented twice ... UNLESS the area moved to was through the door but was also one that had been visited before ( but how would my script know? ) in which case his moves gets decremented once.  If I put the decrement move call in the door onopen script then a player could backtrack a long way through all those previously opened doors.

Seems the simplest solution is the first mentioned in this post. The trouble with it is that the players will need to understand how that rule works or they could lose many turns just by pacing about idly.
Moves? Turns? Yes, After every so many player moves (going from one room to another is a move) the dungeons monster moves and tries to hunt down the player. The player gets so many moves per turn, then the gets its turn but the monster moves fewer rooms per turn than the player but can move through locked doors and sniff the player out.

Thanks again, I'm sure those tricks you all gave me will come in handy later.

Modifié par Calgacus, 31 août 2010 - 11:47 .

[ffbj]

Just something else to add to the long and fabled history of messing with doors. How many have , been iviserated, mangled, mutilated, murdered, and otherwise messed up by doors? When you go into the dungeion in my world and see a locked door you stop, and that's what you should do, mostly...hehehe.

I must digress briefly to recapitulate an amusing antidote from my first campaign world.  We had a locked door to deal with and I started bashing it.  My companion began taking damage and continued to do so, and ran down the hall.  I continued to bash the door having no idea that I wasl damaging him every time I hit the door.  Well he never came back, though he survived as we finally figured out what was happening.  He healed up and I bashed the door once more just for fun.  That's when he left.  That was one of my early scripts.

Modifié par ffbj, 31 août 2010 - 11:53 .

[ehye_khandee]

I think the efficient way to handle it is ->

LOCK all doors, and require NO key, setting each to an impossibly high DC for unlock.

Don't sweat having the door make clunky noises (some doors are just noisier than others).

Use the OnFailToOpen to check for a var on the PC named the same as the TAG of the door. If TRUE, open the door.

Use the OnAcquire script to set the respective vars on the PC when they pick up the right 'key/item' and destroy same in inventory to keep all inventories cleaner.

This means one brief script on the door, maybe 2-4 lines at most, and maybe 3 lines per door in the OnAcquire script. Pretty minimal in code, minimal in inventory; easy meat.

If you want to justify the noise of the door, - if it opens, just have it put text above the PC informing them that the door is a tight fit in the frame and gave some resistance, which the PC overcame.

My 2 cents worth.

 

[ehye_khandee]

ffbj wrote...

Here is one for EK to look at:

This is not persistent, it is though with the rent a hovel program. So your get your name on the door temporarily. I just used bashing instead of on fail to open.

Friend, 
   That script seems suspect to me. A bit of overkill in this instance, but more, you are using

AssignCommand(oDoor, ActionOpenDoor(oDoor));

oDoor = OBJECT_SELF

Never use AssignCommand on OBJECT_SELF as it can cause issues in a module. Commands not assigned execute on the OBJECT_SELF anyway.

*salute*

:innocent:




Still more efficiency can be had by not declaring the oDoor variable and just using OBJECT_SELF in its place where needed.

Modifié par ehye_khandee, 01 septembre 2010 - 12:13 .

[ffbj]

OH, you are going to tell me how to script. That's a laugh.  Well no-one and I mean no-one, at least not to my knowledge ever said you did not have Hutzpah! 

Modifié par ffbj, 01 septembre 2010 - 12:25 .

[ehye_khandee]

ffbj wrote...

OH, you are going to tell me how to script. That's a laugh.  Well no-one and I mean no-one, at least not to my knowledge ever said you did not have Hutzpah! 

Um, you DID ask me to look at that, unless there is another EK here. So, please, don't act like I stepped on your toes.

Facts are facts, check them out and see if I'm wrong on the OBJECT_SELF. By all means, let me know if I've erred somewhere in that post, but don't take the reply wrong, it sure looked like you asked for an evaluation.

Live and learn, eh?



I guess the Hutzpah is on the other foot eh?

Modifié par ehye_khandee, 01 septembre 2010 - 12:47 .

[Calgacus]

ffbj wrote...

Just something else to add to the long and fabled history of messing with doors. How many have , been iviserated, mangled, mutilated, murdered, and otherwise messed up by doors? When you go into the dungeion in my world and see a locked door you stop, and that's what you should do, mostly...hehehe.

I must digress briefly to recapitulate an amusing antidote from my first campaign world.  We had a locked door to deal with and I started bashing it.  My companion began taking damage and continued to do so, and ran down the hall.  I continued to bash the door having no idea that I wasl damaging him every time I hit the door.  Well he never came back, though he survived as we finally figured out what was happening.  He healed up and I bashed the door once more just for fun.  That's when he left.  That was one of my early scripts.

OK, funny door stories, I can think of two, even three...

1) Back in the day, nad I mean the Day - 1986ish - when we were playing pen n paper D&D, we came up to a dorr in a castle we were looting, and found it locked.  So our hero Paul - who sported a big Fro and called his character the Black Knight thus causing us to conclude that he really wanted to be a brother in an age when it wasn't hip or hop for a teen to pretend to be from da hood - announced "I kick the door in!!"  to which our DM replied "What kind of boots are you wearing?" ....  "BooOOOTS?!?!"  
2) our hero, Greer the wizard (David's character) was all that was left of not so merry band of adventurers parading through the Shadowlands.  He was in fact run up against a great door to a strange dark Keep whilst a pack of unnatural wolves descended upon him.  He called out "help, let me in blah blah"  and then tried to bash the great door to no avail.  He tried a Knock spell from a scroll to find magic was unreliable in the shadowlands, he tried to fend off the wolves but knew he had a derth of power left and all but gave up hope until.... another player (the player of the dead PC being carried by our hero leaned over and whispered something in Daves ear.  Then Dave sheepishy said "I open the door and go in."  and the great unlocked door was conquered at last.
3) we were a band of many, and we had made our way into the Mentors lair unto the door to The Room Of The Ten Doors ( not counting the one in presumably ).  And there we weare stymied.  We tried pushing and pulling and picking and bashing, we tried spells and passwords until at last - our old freind the Black Knight stepped forward and pronounced "Open" ...

These and many other tales of yore and be read at: http://calgacus.game...rum/Library.htm

Modifié par Calgacus, 01 septembre 2010 - 12:52 .

[Calgacus]

ehye_khandee wrote...

ffbj wrote...

OH, you are going to tell me how to script. That's a laugh.  Well no-one and I mean no-one, at least not to my knowledge ever said you did not have Hutzpah! 

Um, you DID ask me to look at that, unless there is another EK here. So, please, don't act like I stepped on your toes.

Facts are facts, check them out and see if I'm wrong on the OBJECT_SELF. By all means, let me know if I've erred somewhere in that post, but don't take the reply wrong, it sure looked like you asked for an evaluation.

Live and learn, eh?



I guess the Hutzpah is on the other foot eh?

Chuzpah!??  you want Chuzpah?    check this out:  http://www.normanfin...eyond-chutzpah/

   ok, maaaay be gettin off topic...

Modifié par Calgacus, 01 septembre 2010 - 12:59 .

[ffbj]

Oh yeah. That's it, Chuzpah! Sorry if you took that wrong EK, just that, what you are suggesting is not the way to do it. Technically it's not wrong, just bad practice, imho. I was not asking you for an evaluation, I just thought you might be interested in the script.

Funny door stories btw, good luck with the labyrinth.

Modifié par ffbj, 01 septembre 2010 - 03:51 .

[ehye_khandee]

ffbj,

You posted "OH, you are going to tell me how to script. That's a laugh."

That was RUDE. And utterly un-called-for.

I've always treated you well. You've even visited my PW and expressed that you were impressed with what my partner and I had accomplished there (sophisticated integrated systems, 1100+ areas, lag free, crash free). While you may feel there are other ways to accomplish the task this thread discusses, even ways you would prefer, THAT WAS RUDE and inappropriate, doubly so as I was on target with the comment about AssignCommand.

Modifié par ehye_khandee, 01 septembre 2010 - 12:05 .

[Calgacus]

ehye_khandee , I thought ffbj was just joking when he wrote that.



Has anyone ever done some sort of psychological research into online flaming? It seems people including myself are extremely sensitive when they are slighted online even when protected behind fake names and no one could possibly know their true identity. might be a legit study.



Anyway, the purpose of this thread has been met.



Thanks for the help everyone. It's good to see the community is still ... passionate.

[Lightfoot8]

Calgacus wrote...
Has anyone ever done some sort of psychological research into online flaming? It seems people including myself are extremely sensitive when they are slighted online even when protected behind fake names and no one could possibly know their true identity. might be a legit study.

Wonder how long it would take for a thread on that topic to get locked.  

[Genisys]

ffbj wrote...

OH, you are going to tell me how to script. That's a laugh.  Well no-one and I mean no-one, at least not to my knowledge ever said you did not have Hutzpah! 

I'll laugh with you, he told me I can't script either...

[ehye_khandee]

Genisys wrote...

ffbj wrote...

OH, you are going to tell me how to script. That's a laugh.  Well no-one and I mean no-one, at least not to my knowledge ever said you did not have Hutzpah! 

I'll laugh with you, he told me I can't script either...

Genesys, Laugh all you like, I've seen your code. Let's review the script I sent back to you corrected... first your original script of 89 lines intended to spawn interference (supercop) on 'improper use of a door' ...


//Script Name: sc_on_unlock
//////////////////////////////////////////
//Created By: Genisys (Guile)
//Created On: 8/19/08
/////////////////////////////////////////
/*
This will spawn in the Super Cop on
the PC for unlocking something they
were not suppose to!
*/
// GM_ODA NOTE: THE ABOVE DESCRIPTION SHOULD INCLUDE EVERYTHING THIS SCRIPT SHOULD DO
////////////////////////////////////////
#include "setxp_inc"

//Main Script
void main()
{

//Declare Major Variables
object oPlayer;
object oTarget;
object oSpawn;
object oMe = OBJECT_SELF;
location lTarget;

int nInt;
lTarget = GetLocation(oTarget); // GM_ODA NOTE: oTarget has not yet been given a value therefore this location will be invalid

//Let's make sure we define just who killed the NPC clearly..
// GM_ODA NOTE: who's talking about killing a NPC? this is on the on_unlocked script of an object!
if(!GetIsPC(GetLastUnlocked()))// GM_ODA NOTE: flawed code block used in numerous scripts in this set WILL NOT WORK AS INTENDED. Did you really test this stuff? As a PC and as a DM and as a npc possessed by a DM?
{
//if It's a DM stop here..
if(GetIsDMPossessed(GetLastUnlocked()))
{ return; }
if(GetIsDM(GetLastUnlocked()))
{ return; } // GM_ODA NOTE: this will NEVER fire, DM's are considered PCs too so would not be included in this if()'s subjects
// GM_ODA NOTE: it is a bad idea to re-invoke GetLastUnlocked() rather than set a variable to use it ONCE.

//IF It truly was an associate who attacked..
if(GetMaster(GetLastUnlocked())!=OBJECT_INVALID)
{
oPlayer = GetMaster(GetLastUnlocked());
}
else
{
oPlayer = GetLastUnlocked();
}

}
else
{
oPlayer = GetLastUnlocked(); // GM_ODA NOTE: this would mean DMs are possible values for the oPlayer ... not what was intended.
}

if(GetIsPC(oPlayer)) // GM_ODA NOTE: why do this same if() twice?
{

//Only Once Ever 30 Seconds!
int DoOnce = GetLocalInt(oPlayer, GetTag(OBJECT_SELF) + "SC");
if (DoOnce==TRUE) {return;}

SetLocalInt(oPlayer, GetTag(OBJECT_SELF) + "SC", TRUE);
DelayCommand(30.0, SetLocalInt(oPlayer, GetTag(OBJECT_SELF) + "SC", TRUE));


//Penalize the player!
ApplyRespawnPenalty(oPlayer);// GM_ODA NOTE: this was never offered in the description for the script. How is this going to work on your DM Avatar eh?

oTarget = oPlayer;
lTarget = GetLocation(oTarget); // GM_ODA NOTE: reduce this and prior line to "lTarget = GetLocation(oPlayer);"

oSpawn = CreateObject(OBJECT_TYPE_CREATURE, "supercop", lTarget);

oTarget = oSpawn;

int nInt; // GM_ODA NOTE: NEVER declare variables inside a conditional. This one is declared TWICE!
nInt = GetObjectType(oTarget);
// GM_ODA NOTE: regarding the following section, why would a OBJECT_TYPE_CREATURE you just spawned be anything but a OBJECT_TYPE_CREATURE ???
if (nInt != OBJECT_TYPE_WAYPOINT) DelayCommand(0.5, ApplyEffectToObject(DURATION_TYPE_INSTANT, EffectVisualEffect(VFX_FNF_SUMMON_UNDEAD), oTarget));
else DelayCommand(0.5, ApplyEffectAtLocation(DURATION_TYPE_INSTANT, EffectVisualEffect(VFX_FNF_SUMMON_UNDEAD), GetLocation(oTarget)));


AssignCommand(oPlayer, ClearAllActions());

}

//Main Script End
}



// xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Now the replacement/corrected script of 37 lines that I sent you for your edification.

//Script Name: pw_on_unlock ... supercedes sc_on_unlock - redux by GM_ODA
//sc_on_unlock Created By: Genisys (Guile)
//sc_on_unlock Created On: 8/19/08
/* This will spawn in the Super Cop on the PC for unlocking
something they were not suppose to! */

//Main Script
void main()
{
//Declare Major Variables
object oTarget,oSpawn,oPlayer,oMe = OBJECT_SELF, oTest = GetLastUnlocked();
int DoOnce;
string sControl;
if(!GetIsPC(oTest))
{
if(GetIsDMPossessed(oTest))return;
oPlayer = GetMaster(oTest);
} // resolve for all NPCs
else{oPlayer = oTest;}// resolve for PC

if( (!GetIsObjectValid(oPlayer)) || GetIsDM(oTest) )return; // exit if DM or object not valid

//Only Once Ever(y) 30 Seconds! - begin
sControl = GetTag(OBJECT_SELF) + "SC";
DoOnce = GetLocalInt(oPlayer, sControl);
if (DoOnce==TRUE) {return;}
SetLocalInt(oPlayer, sControl, TRUE);
DelayCommand(30.0, SetLocalInt(oPlayer, sControl, TRUE));
//Only Once Ever(y) 30 Seconds! - end

int nInt;
location lTarget = GetLocation(oPlayer);
CreateObject(OBJECT_TYPE_CREATURE, "supercop", lTarget);
ApplyEffectAtLocation(DURATION_TYPE_INSTANT,EffectVisualEffect(VFX_FNF_SUMMON_UNDEAD),lTarget);

AssignCommand(oPlayer, ClearAllActions());
} //Main Script End


*scratches head* Now, don't you wish you'd left that can of worms unopened 'Guile'?

// xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx


ffbj - what exactly was it that you say is 'not the way to do it. I only suggested that your use of AssignCommand was incorrect because it targets OBJECT_SELF and I can show you references that say DO NOT DO THIS. If I'm wrong I can accept that but in this case, I think you are confused.

Be well. Game on.
GM_ODA

Modifié par ehye_khandee, 02 septembre 2010 - 01:07 .

[Genisys]

I've decided to just not waste my time with some people...

Modifié par Genisys, 02 septembre 2010 - 02:30 .

[Invisig0th]

Well, ehye_khandee is actually correct on both counts here. Using AssignCommand to assign a command to OBJECT_SELF is poor form, it produces worse performance, and most importantly it is very likely to behave unexpectedly if one does not really understand exactly how the function works (See below). Doing it that way can easily lead people who are new to scripting into big trouble. The NWN Lexicon is very clear on all of these points, and none of these is a matter of personal opinion.

Do not bother to use AssignCommand(OBJECT_SELF, Foobar()), as AssignCommand() is worthless in that situation - the caller of the  script automatically uses Foobar even without the AssignCommand, and it  is only likely to generate more performance issues.

Note that AssignCommand'ed commands get executed AFTER the script finishes.

A common mistake on AssignCommand seems to be to use OBJECT_SELF. OBJECT_SELF is a constant so it is more of a NULL pointer than a "this" pointer. If you  use it in the AssignCommand or similar functions the creature will  attempt to perform the action against itself which most often seems to not be what the person using it intended.

This is the scripting forum, and we do want people to know about and avoid common mistakes, right? Well, this is one of those common mistakes. Personal egos aside, it is correct that not using AssignCommand with OBJECT_SELF here is a better solution.

As for the criticism of the script posted by Genisys earlier -- sorry if that hurts your feelings, but this is the scripting forum. If you post a script that is full of errors and sloppy coding, it is the responsibility of other community members to point out the flaws in what you posted, and explain to you how you could have accomplished your goal with better code.  Scripts that have errors or are confusing make things very difficult for newbies trying to learn by example. Scripts like that will always be critiqued, corrected, and simplified as needed. This helps everyone, especially new scripters, understand how to make scripts work properly. Everyone should be open to suggestions regarding how to improve their scripting skills, because that is the only way to get better at scripting. The very best scripters around are always looking for new ways to do things better, and they welcome suggestions on how to improve their code.

In this specific case, your script really was a confusing mess. You (and everyone else reading this thread) would be very wise to consider the very reasonable suggestions that ehye_khandee has posted regarding ways to fix the problems with your script. The purpose here is not to "say you can't script". The purpose is to fix the script so that other people will not reproduce your mistakes in their own scripts.

If you would like to avoid people correcting your scripts in the future, the solution is very simple -- spend a lot more time improving and correcting your scripts before posting them..

Modifié par Invisig0th, 03 septembre 2010 - 06:06 .

[Lightfoot8]

If I can split straws here second, And get your opinion on this.



ffbj did not use the null pointer in his script with the assign command. He did this:



object oDoor = OBJECT_SELF;

AssignCommand(oDoor, ActionOpenDoor(oDoor));



That is no longer the null pointer being used in the AssignCommand but a object pointer pointint at the object currently running the script. Is this really that big of a deal. Agreed in this case the AssignCommand is not needed. I can however see times when you may want to have the command run on either self or other and change the object pointer to the situation. I myself do not see the problem or where it would cause errors.



Am I incorrect in this?

[Redunct]

Lightfoot8 wrote...

If I can split straws here second, And get your opinion on this.

ffbj did not use the null pointer in his script with the assign command. He did this:

object oDoor = OBJECT_SELF;
AssignCommand(oDoor, ActionOpenDoor(oDoor));

That is no longer the null pointer being used in the AssignCommand but a object pointer pointint at the object currently running the script. Is this really that big of a deal. Agreed in this case the AssignCommand is not needed. I can however see times when you may want to have the command run on either self or other and change the object pointer to the situation. I myself do not see the problem or where it would cause errors.

Am I incorrect in this?

Well, ideally you wouldn't define OBJECT_SELF in such a fashion.

[Redunct]

Invisig0th wrote...

Well, ehye_khandee is actually correct on both counts here. Using AssignCommand to assign a command to OBJECT_SELF is poor form, it produces worse performance, and most importantly it is very likely to behave unexpectedly if one does not really understand exactly how the function works (See below). Doing it that way can easily lead people who are new to scripting into big trouble. The NWN Lexicon is very clear on all of these points, and none of these is a matter of personal opinion.

Do not bother to use AssignCommand(OBJECT_SELF, Foobar()), as AssignCommand() is worthless in that situation - the caller of the  script automatically uses Foobar even without the AssignCommand, and it  is only likely to generate more performance issues.

Note that AssignCommand'ed commands get executed AFTER the script finishes.

A common mistake on AssignCommand seems to be to use OBJECT_SELF. OBJECT_SELF is a constant so it is more of a NULL pointer than a "this" pointer. If you  use it in the AssignCommand or similar functions the creature will  attempt to perform the action against itself which most often seems to not be what the person using it intended.

This is the scripting forum, and we do want people to know about and avoid common mistakes, right? Well, this is one of those common mistakes. Personal egos aside, it is correct that not using AssignCommand with OBJECT_SELF here is a better solution.

As for the criticism of the script posted by Genisys earlier -- sorry if that hurts your feelings, but this is the scripting forum. If you post a script that is full of errors and sloppy coding, it is the responsibility of other community members to point out the flaws in what you posted, and explain to you how you could have accomplished your goal with better code.  Scripts that have errors or are confusing make things very difficult for newbies trying to learn by example. Scripts like that will always be critiqued, corrected, and simplified as needed. This helps everyone, especially new scripters, understand how to make scripts work properly. Everyone should be open to suggestions regarding how to improve their scripting skills, because that is the only way to get better at scripting. The very best scripters around are always looking for new ways to do things better, and they welcome suggestions on how to improve their code.

In this specific case, your script really was a confusing mess. You (and everyone else reading this thread) would be very wise to consider the very reasonable suggestions that ehye_khandee has posted regarding ways to fix the problems with your script. The purpose here is not to "say you can't script". The purpose is to fix the script so that other people will not reproduce your mistakes in their own scripts.

If you would like to avoid people correcting your scripts in the future, the solution is very simple -- spend a lot more time improving and correcting your scripts before posting them..

Agreed, it can be appealing to make your script look "big" and cool, but honestly, you want your script as simple as possible. While you may impress average people with a 500 line code to do something, other scripters will appreciate the ability to do the same thing in as simple form as possible.

[Invisig0th]

My concern is not about with whether it's better to use OBJECT_SELF or an object variable (oDoor). My concern is that you should never use AssignCommand when your intention is to have the object running the current script run a simple command right away. Instead, you should simply call the function to run the command, in this case:

ActionOpenDoor(OBJECT_SELF)

Doing it using AssignCommand literally delays the execution of that code until after the current script is done, so there is extra overhead and absolutely no benefit. Even worse, doing this can lead to all sorts of other problems if one expect things to happen in the order they appear in the original script. In this particular case it might have worked just fine, but in many other cases it would have caused things to happen in the wrong order, causing problems that would be extremely hard to troubleshoot.

If the two techniques were roughly equivalent as far as the game engine is concerned, then it might not be a big deal. But as you can see, they actually do two very different things. You definitely should not defer execution of commands unless you have a reason to do so.

Modifié par Invisig0th, 03 septembre 2010 - 09:22 .

[Shadooow]

Invisig0th wrote...

My concern is not about with whether it's better to use OBJECT_SELF or an object variable (oDoor). My concern is that you should never use AssignCommand when your intention is to have the object running the current script run a simple command right away. Instead, you should simply call the function to run the command, in this case:

ActionOpenDoor(OBJECT_SELF)

Doing it using AssignCommand needlessly delays the execution of that code until after the current script is done, so there is extra overhead and absolutely no benefit. Even worse, doing this can lead to all sorts of other problems if one expect things to happen in the order they appear in the original script. In this particular case it might have worked just fine, but in many other cases it would have caused things to happen in the wrong order, causing problems that would be extremely hard to troubleshoot.

If the two techniques were roughly equivalent as far as the game engine is concerned, then it might not be a big deal. But as you can see, they actually do two very different things. You definitely should not defer execution of commands unless you have a reason to do so.

This all you wrote are very relevant informations for beginning scripters, however delaing the function at the end of the script can be sometimes very good feature and its better used on OBJECT_SELF than any other object, also due to action queve.

Also there was issue where some function didn't worked without assigncommand (with any object, no matter if OBJECT_SELF). See here. Nobody yet brought explanation for this and I found another case with the same issue.

Modifié par ShaDoOoW, 03 septembre 2010 - 09:24 .

[ehye_khandee]

Thank you INVISIG0TH!!!!



I am VERY particular about code, absolutely fixated on doing it right, doing it with minimal commands, doing it clean. My own PW is over 1100 areas, runs lag free, crash free, [honest, I average ONE CRASH PER YEAR for the last 3-4 years] and has more numerous (sophisticated) systems than any other five servers combined (that I have seen).



My partner in code is just shy of her Masters Degree, a prodigy, she has been coding since 8 years of age, and now has over 22 years of experience. I am VERY lucky to pick her brain as I do. She tells me my code (though I am self taught largely over the last 35+years in several languages and scripts) is at a Masters Degree level. I tell you this because, though I may be blunt, even to the point of tactless, I earnestly TRY to tell it like it is... my speech is as direct as my code. I get a LOAD of flack for my efforts some times, and frankly it is undeserved.



I have a strange brain. I do not forget. It is bane and boon. I recall all the major details of every book I have ever read, even from my childhood.



If my posts are blunt, it is because I don't waste words. If I'm ever wrong, please do tell me, I can take it, but I assure you it is once in a very blue moon that I get called out on things. Like I said, I have a strange brain that does not loose details (like the rules for coding). Once I read it, it is in there. Not a photographic memory, that would be too easy, but one that is the proverbial elephant. Bane and boon.



Please people, remember, I am trying to help. It is the fool who kills the messenger.



Feel free to test me on this, visit my server and tell me you have not seen 10 wrongly configured servers for every system I have running like a dream.



Be well. Game on.

GM_ODA



aldohral.forumotion.com

66.232.100.90 CEP 2.1 or better required.

[ehye_khandee]

One other thing... the code in my examples of the correction above - I wrote that at the level most scripters could read here. There are large blocks of that thing where I can reduce 8-10 lines into 2 or 3, but you'd all have a hard time reading it that way. On my own server, we write even leaner than what you see here in my posts.

I can tell you the results you get by using AssignCommand incorrectly can cause lag and even crash your server in some cases.

Modifié par ehye_khandee, 03 septembre 2010 - 09:33 .

[Shadooow]

ehye_khandee wrote...

I can tell you the results you get by using AssignCommand incorrectly can cause lag and even crash your server in some cases.

I would wonder, details, proofs...