79 réponses à ce sujet

[The Fred]

You could also store it as a local on all of the party members. This might still give odd behaviour if you, say, pick up another party member, and/or require more work, but it'd probably be more realistic (since only members who *did* meet the NPC would be able to get the special behaviour - though you might want the NPC to, say, check all members when meeting them the (possibly) second time - again, more work, unfortunately).

[Shallina]

The good solution for a VAR that don't need to go out of the current module is to stock it in the object related to the event if you need that VAr only when the object is "up", and don't need it when tehe object is destroyed.

If you need that VAr all the time in that mod but not outside the mod, depending the context, it's good to store it in the Area or in the Module, since they can't be destroyed.
Be carefull with name and use a naming convention.

If you want that Var to be accessible everywhere in the campaign you got 2 solutions :

Use a GlobalVar, or Attach it to a travelling object between the module. The most obvious beeing GetFirstPC(). the danger with GetFirstPC() is that if the player or character change you are screwed.

By using GetFirstPC() you close the door to a Flawless MP mod. But for some things you can't do without it.

Also keep in mind that NWSCRIPT is slow, when you start to have hearbeat+ complex script runing at the same time you might have slowdown.
 if your only way to access something directly is GetFirstPC() or else you have to use a loop, it's probably better to screw a little the MP component.

Nevers forget that loop are something "perf killing".

A loop in a loop in a loop means generally that you are 100% screwed for the performance, and games are real time application, having "delay" is really really bad in games.

Modifié par Shallina, 28 avril 2011 - 03:56 .

[Lance Botelle]

Shallina wrote...

Basically 2 brothers that play their solo run at different hours on the same computer would be screwed.

Hi Shallina,

Not strictly true .... The only way two brothers on the same PC could be "screwed" are if ....

a) They are using the same account and ...
They are using a PC with exactly the same name in each game.

That is the only time a warning comes up in my use of campaign ints because my campaign vars are stored according to PC name and player account name. This would be rather unusual to say the least. That's why even the same player would have to use a PC with the same name and be starting again before they would encounter such a warning.

As I say, it's all down to how many checks you want to code into the module when using campaign variables. I stopped my checks at comparing player name with a particular named PC. You could, in theory, add more tests to make sure the vars are not being overwritten.

Regards,

Lance.

EDIT: I just saw what The Fred said, which is what I was saying above and agree with:

The Fred .... IIRC, you can specify a player to whom the campaign variable applies (at least, you could with NWN1 database variables), so unless someone did a second run with the same char or loaded up from a saved game, you wouldn't have issues from havign two runs on the same PC. Of course, given the save-independant behaviour of these variables, I can't see many instances where I would want to use them, but if you did have one, there's nothing wrong with doing so... so long as you know what you're getting into.

Modifié par Lance Botelle, 28 avril 2011 - 04:03 .

[Lance Botelle]

M. Rieder wrote...

I have exclusively used local variables mainly because I do not completely understand global variables and have a vague recollection of reading somewhere that for some reason, they were not preferable to local variables.

Could someone please discuss when a global variable may be better than local and what (if any) dangers there are with using global variables.

Hi Matt,

There are no dangers using a global variable as long as you stick to the same rules of care as you do with any variable holder. i.e. Make sure you are using unique names to hold the variable.

The only difference between the two is that:

GLOBALS: Store a variable in a single variable name holder and are not attached to any specific object. Think of the format as attaching the variable to your campaign rather than a module. So, when you do somthing like, SetGlobalInt("PartyLikeDonuts", 1); Think of this as attaching a variable to your campaign in a format that might look like this (but is not the case as far as I am aware): SetLocalInt(oCampaign, "PartyLikeDonuts", 1); It's a bit like saying it is a local variable for  your campaign.

LOCALS: Local variables always require an object to attach the variable to which it associates. You know about these already, so I won't bore you with examples.

In the days of NWN1, we never had SetGlobalInt and so had to mess around with transferring local ints stored on the current module onto the next (via a PC who may be transferring) or temporarily use campaign ints. At the end of the day, if you know what variables are going to be required across your whole campaign, think GlobalInts and be sure to name them carefully.

Regards, Lance.

[M. Rieder]

Okay, so I understand the difference between globals and locals now. It is actually pretty simple. Here's my next question:

I hear the term Campaign Variable being thrown around. I have never seen this before in the toolset or otherwise. Apparently these variables, based on previous comments in this thread, are somehow stored on the campaign and will be the same for different players? I don't fully understand this.
Lance, I also don't fully understand your warning screen and its implications.  Does it only relate to campaign variables?

Modifié par M. Rieder, 28 avril 2011 - 04:32 .

[painofdungeoneternal]

Campaign variables use the in game database. Which is a really strange and odd system. It is good for storing variables which can be used across various games, the dm tool for example stores itself here so it only has to be gotten once. You can store both creatures and items in this. You should not do this very often as the in game database is very slow.

If you use these, it is helpful to know that this is actually touching on NWNX features. With nwnx installed, using the campaign database name of nwnx tell NWNX that it can intercept campaign calls, thus storing the data in sqlite which is probably the fastest database in existence, or mysql which is a much more well rounded storage engine. Basically if you run a PW you really should use mysql as it allows you to remote into the database from the database editor, and is easier to backup as needed. SQLlite is the default because it basically is included with nwnx, and is good for those running lan games or just are not technical enough to get mysql running. Compared to the in game database these are a must have.

Note that the NWNX function wrappers allow direct use of the database, mysql or sqllite if it's available, but in single player use the campaign database. This allows the best of all worlds for your code for a small amount of overhead. It also wraps the various functions soas to make them store strings which i suspect sidesteps quite a few bugs. Because these functions are very buggy, i would strongly suggest putting a wrapper in so you have a single spot to fix any issues that crop up.

Have not really gotten into why the bugs exist though. I know akavit on SOD was trying to make players store locations, and i think there was an issue where variables names have to be padded to diffrentiate between them ( hoping that is fixed ). If you ask about it on the IRC channel you will basically get a collective moan based on a lot of bad memories going back to nwn1.

[Lance Botelle]

M. Rieder wrote...

Okay, so I understand the difference between globals and locals now. It is actually pretty simple. Here's my next question:

I hear the term Campaign Variable being thrown around. I have never seen this before in the toolset or otherwise. Apparently these variables, based on previous comments in this thread, are somehow stored on the campaign and will be the same for different players? I don't fully understand this.
Lance, I also don't fully understand your warning screen and its implications.  Does it only relate to campaign variables?

Hi Matt,

As Pain says, Campaign variables are those stored in an external database. They are NOT stored on the campaign as you say. Do not let the name "campaign" in the name confuse you though. As I say in my last post, the ability to save campaign variables came with NWN1, so at the time, it was a method of storing variables across modules, like a campaign. However, we have the SetGlobal command sthat do a better job of this now.

Unless you have any reason (and knowledge) of what you are doing and need campaign variables, you will not need to use the SetCampaignXXX functions at all. You certainly won't need to use a 3rd party app like the one Pain mentions, as that can get even more confusing - and is best reserved for  serving persistent world modules.

LocalInts and GlobalInts are all you need.

I have used CampaignInts, which my database warning screenshot refers to, to make sure players are not reloading a game to get around a problem without paying the cost. e.g. Player learns the code to a puzzle is "Fred" after paying 100gp to learn the answer. They then load the game and have the answer without paying the 100gp. Keeping track of such activity via campaignints (which cannot be done any other way because as we have said campaignints are the only way to keep track of variables between saves and is the desired result) is the only way to do this.

Regards, Lance.

Modifié par Lance Botelle, 28 avril 2011 - 06:01 .

[The Fred]

I think more is preserved between mods in NWN2. Back in my NWN1 days, I used campaign variables to send info from one module to the next. Campaign variables have a lot of issues, though (as mentioned); my solution was to have a variable devoted to telling the next module that a player had just come from the previous one. This would be cleared right afterwards and so if a player started the second one from scratch, it would know (and not load redundant data from, say, a previous playthrough). I also loaded all the campaign variables into local variables because campaign variables are basically useless for "everyday" variable storage, for the reasons noted above (they persist between saves etc). I don't think there's any need for them in NWN2, though, which is designed for players to move to and fro between modules.

[Lance Botelle]

The Fred wrote...

I think more is preserved between mods in NWN2. Back in my NWN1 days, I used campaign variables to send info from one module to the next. Campaign variables have a lot of issues, though (as mentioned); my solution was to have a variable devoted to telling the next module that a player had just come from the previous one. This would be cleared right afterwards and so if a player started the second one from scratch, it would know (and not load redundant data from, say, a previous playthrough). I also loaded all the campaign variables into local variables because campaign variables are basically useless for "everyday" variable storage, for the reasons noted above (they persist between saves etc). I don't think there's any need for them in NWN2, though, which is designed for players to move to and fro between modules.

Hi The Fred,

Yes, I find myself in agreement with you again .... and caching the campaign ints as local ints on the module (or PC) is the same method I would use if I was going to use them in any great amount. However, I probably use them more than most (with respsect to basic module building, not PW building) and I only have about 3-4 uses of them if I recall correctly ... and then to cover potential exploits only - so not much need for caching there. If a builder is not building a PW or checking for exploits (as I am), then I cannot think of another reason to use them with NWN2.

Lance.

Modifié par Lance Botelle, 28 avril 2011 - 06:17 .

[painofdungeoneternal]

Well the one use you should use them for is storing a character. If the player completes your module, you could store their pc as a variable object. Then the next time they play, you can get that players object from the previous play thru and see if it's got the same name, if not put it in as a NPC in town bragging about how he knows the future, or some other silliness. Or perhaps the major villain can be stored this way so if he's damaged in the first module by 50%, the next time you meet him he's still damaged the same amount.

It also is a good idea to store local ints on a item, then store the item as a campaign object, load it once, and save it periodically, perhaps a little bit after area loads.

These only do the 2 things though, not any other type of object.

[Lance Botelle]

painofdungeoneternal wrote...

Well the one use you should use them for is storing a character. If the player completes your module, you could store their pc as a variable object. Then the next time they play, you can get that players object from the previous play thru and see if it's got the same name, if not put it in as a NPC in town bragging about how he knows the future, or some other silliness. Or perhaps the major villain can be stored this way so if he's damaged in the first module by 50%, the next time you meet him he's still damaged the same amount.

It also is a good idea to store local ints on a item, then store the item as a campaign object, load it once, and save it periodically, perhaps a little bit after area loads.

These only do the 2 things though, not any other type of object.

Hi Pain,

Of course, this assumes the modules are built and supplied seperately as opposed to being supplied as different modules in the same camapign at the same time, in which case, global ints would be best again.

However, with the ability to "patch" campaigns with new modules (effectively), it should be easy enough to stick with local and global ints still for the player to simply reload their last saved game and continue into the next mod if it has been made to package into the same campaign. That's what I am hoping to do with my own campaign ... basically, try to think ahead enough to allow me to add new modules to the existing campaign and transfer variables using code compatible with the previous modules.

If the modules are too different, however, and certainly not of the same campaign structure, then what you say is correct - using campaign variables would allow this.

Lance.

[Kaldor Silverwand]

Lance Botelle wrote...
However, with the ability to "patch" campaigns with new modules (effectively), it should be easy enough to stick with local and global ints still for the player to simply reload their last saved game and continue into the next mod if it has been made to package into the same campaign. That's what I am hoping to do with my own campaign ... basically, try to think ahead enough to allow me to add new modules to the existing campaign and transfer variables using code compatible with the previous modules.

That is exactly what I did with King's Festival when I added the Queen's Harvest content.  I didn't have any significant problems.  My only suggestion is make sure that your areas always have on enter scripts defined, even if you don't write the scripts initially. That way you can add in the scripts later as campaign scripts and use them to alter the areas if need be. That will provide some flexibility and prevent the need for players to start over from scratch. This is also a good reason to use spawn waypoints and spawn in creatures using script rather than placing them.

Regards

[painofdungeoneternal]

I think you missed my point, that is not discussing cross module usage, campaigns or any of that, not even sure we are communicating at all here. I was trying to say these function do have a important set of features which adds a lot of value in response to the comment they are of no real use.

This is a feature they enable which allows you to duplicate items, create clones of the player, and quite a few other things which you CANNOT do by any other means. It does not require a campaign or anything else, and things stored will persist in the in game database.

This could mean you could set up a chest in one module, then another module made by someone else could allow the player to retrieve the same stuff, limited by character name or just a free for all. You could use it to store creatures the player has killed periodically then later on he could run into them as ghosts while he visits hell, or have to fight them again when the enemy does his undead army. ( imagine the player, who prides him self on not killing opponents and instead using cleverness, on learning his tactic actually pays off for once. )

That is just a few ideas though, what you can do with it is limited only by your creativity.

Beyond this sort of thing i would basically avoid them entirely, or use it for features aimed at PW's which i'd like to keep working in SP as well. There are some big advantages to have code in use on both SP and MP, lot more bugs are fixed and there is a lot more talented people able to build on what you do.

[Lance Botelle]

painofdungeoneternal wrote...

I think you missed my point, that is not discussing cross module usage, campaigns or any of that, not even sure we are communicating at all here. I was trying to say these function do have a important set of features which adds a lot of value in response to the comment they are of no real use.

Hi Pain,

I reread your comment and see that I did mistake what you said. I see you are saying if a player runs the same module again that you could represent the old PC as a new NPC in the next play through.

This is a feature they enable which allows you to duplicate items, create clones of the player, and quite a few other things which you CANNOT do by any other means. It does not require a campaign or anything else, and things stored will persist in the in game database. <SNIPPED>

That is just a few ideas though, what you can do with it is limited only by your creativity.

Got you now.  Not the sort of thing I would personally cater for, as it seems more aimed at PW like stuff where a player is more likely to replay the same module. (I know players do replay the same mod, but surely less than a PW environment.)

Beyond this sort of thing i would basically avoid them entirely, or use it for features aimed at PW's which i'd like to keep working in SP as well. There are some big advantages to have code in use on both SP and MP, lot more bugs are fixed and there is a lot more talented people able to build on what you do.

Agreed.

Lance.

[painofdungeoneternal]

Lance Botelle wrote...

painofdungeoneternal wrote...

I think you missed my point, that is not discussing cross module usage, campaigns or any of that, not even sure we are communicating at all here. I was trying to say these function do have a important set of features which adds a lot of value in response to the comment they are of no real use.

Hi Pain,

I reread your comment and see that I did mistake what you said. I see you are saying if a player runs the same module again that you could represent the old PC as a new NPC in the next play through.

This is a feature they enable which allows you to duplicate items, create clones of the player, and quite a few other things which you CANNOT do by any other means. It does not require a campaign or anything else, and things stored will persist in the in game database. <SNIPPED>

That is just a few ideas though, what you can do with it is limited only by your creativity.

Got you now.  Not the sort of thing I would personally cater for, as it seems more aimed at PW like stuff where a player is more likely to replay the same module. (I know players do replay the same mod, but surely less than a PW environment.)

Beyond this sort of thing i would basically avoid them entirely, or use it for features aimed at PW's which i'd like to keep working in SP as well. There are some big advantages to have code in use on both SP and MP, lot more bugs are fixed and there is a lot more talented people able to build on what you do.

Agreed.

Lance.

Actually people in SP do replay things. The OC is replayed over and over, and so are modules. The persistent chest is something you might see on a PW, but it also is something people playing the OC requested to store their loot when they change their companions.

It is a mistake to think how we play things is the norm, generally it's almost always a minority, and what people do is generally something between pure SP and MP. There are far more differences between each PWs playstyle than there is between SP and MP as a whole. The SP modules i can guarantee you are put on LAN games, and when they don't work it just makes the players decide the game itself sucks making them move on. A SP purist, who likes a linear game, only plays thru once, never goes on a PW or plays with anyone else is a very limited group.

Some people do like features which are classified as MP, but they don't really like being on a PW at all. I have players who DO NOT want to talk to anyone, they just want to solo, but they like my PW for what it offers. To me those people are not wanting a PW, they are just not able to find what they are looking for in SP modules. The entire thought of someone dismissing an idea because it's classified as SP or MP is very short sighted, there is an assumption that those on the other side of the fence are fundamentally different when there is very little difference.

The ability to create persistence is of course not a core thing people are looking for, but i am pretty sure that when a player sees their previous character, it will act as a badge or accomplishment, and players seem to really like earning those. The emotion of pride, of accomplishment is something you really want to give people if it's at all possible. Imagine doing this in the cemetary, which often includes beta testers, but you could include the names of players used on previous play thrus as well. It's doing the details well like that, that make the difference between a regular module and a module you remember and vote on to be in the hall of fame.

[Lance Botelle]

painofdungeoneternal wrote...

Actually people in SP do replay things. The OC is replayed over and over, and so are modules. The persistent chest is something you might see on a PW, but it also is something people playing the OC requested to store their loot when they change their companions.

Hi Pain,

Perhaps I am missing something here, but why do they need a persistent chest? Can't they just remove the items they want from the companion before dismissing them? Or, if you mean between each play, then isn't that a form of cheating, by effectively giving their PCs equipment too powerful for the module? I'm not judging their actions here, just asking if the module is worth playing with such equipment that alters the balance of the game.

It is a mistake to think how we play things is the norm, generally it's almost always a minority, and what people do is generally something between pure SP and MP. There are far more differences between each PWs playstyle than there is between SP and MP as a whole. The SP modules i can guarantee you are put on LAN games, and when they don't work it just makes the players decide the game itself sucks making them move on. A SP purist, who likes a linear game, only plays thru once, never goes on a PW or plays with anyone else is a very limited group.

I must admit, I did think there were still more SP players than MP ones, even though I am planning a MP module myself. I cannot see why a person would try a SP game on a LAN unless it has been specified as MP ... unless they are prepared for some potential problems.

Some people do like features which are classified as MP, but they don't really like being on a PW at all. I have players who DO NOT want to talk to anyone, they just want to solo, but they like my PW for what it offers. To me those people are not wanting a PW, they are just not able to find what they are looking for in SP modules. The entire thought of someone dismissing an idea because it's classified as SP or MP is very short sighted, there is an assumption that those on the other side of the fence are fundamentally different when there is very little difference.

I agree that any game could be played SP or MP from a gaming point of view, BUT, the problem is, people do not code for MP very well. The only reason that I am able to do what I do is because I am blessed with more than one computer and more than one pack of NWN2, so I can test all the MP aspects myself. NB: I am not talking about actual gameplay, but parts of the code that must check for multi-player interaction. Personally, I believe the reason why some people play a MP game (and PW in particular), will be because MP games (if done thoroughly) tend to be better coded than a SP game, simply because of the amount of checking required for a MP game. That's not to say that some MP games will be better in content as well ... from what you say, then it sounds like yours is one of them.

The ability to create persistence is of course not a core thing people are looking for, but i am pretty sure that when a player sees their previous character, it will act as a badge or accomplishment, and players seem to really like earning those. The emotion of pride, of accomplishment is something you really want to give people if it's at all possible. Imagine doing this in the cemetary, which often includes beta testers, but you could include the names of players used on previous play thrus as well. It's doing the details well like that, that make the difference between a regular module and a module you remember and vote on to be in the hall of fame.

I suppose if a player did replay a module, then what you describe could be appealing to some. Personally, it would not encourage me to play again ... I would rather start another moudle or even the next one in the series if available.  Each to their own I suppose. I do, however, agree that "attention to detail", no matter what form in comes along in, is the most important aspect to excite a player enough to perhaps vote it into the Hall of Fame.

Regards,

Lance.

Modifié par Lance Botelle, 28 avril 2011 - 08:50 .

[painofdungeoneternal]

I have no idea why they need anything, i don't really do much LAN play, i just talk to a lot of people who see it as their playstyle of choice. Note that my playstyle of PVP PW play is often seen as a reason to completely dismiss everything i am doing, but when what i am doing is looked at beyond the labels it actually is seen as offering value. I do try to understand why different people like what they like, and when i design things i take it all into consideration -- adding things to my PW that a SP person brings up to me just adds value for whoever happens to be playing my world.

They probably wanted to just not carry anything and treat their castle as their home -- often the roleplay axis vs the action player axis also seem to be at odds. SP and MP are akin to law and chaos, and roleplay and action are also akin to good and evil, and everyone thinks their choice of the two is lawful good ( if you are a mp person sp is evil, if you are a sp person mp is evil ). These things are not exclusive nor should they be, nor is either one any more evil than vanilla ice cream.

You also have to understand that i don't see LAN play as even closely related to a PW. Almost any module will work in lan play IF they refer to objects correctly and don't do short cuts like getfirstPC. A PW just won't work in SP as it needs other players and DMs for there to be a story, its more of a setting. A module made for SP is the same thing as a module made for SP on a LAN, and if it does not abuse getfirstpc will just work as is, and most players understand the first player who started the session is going to be the "knight captain".

Often people are so set on NOT being MP, they don't realize their module is already working fine enough for what those LAN folks are looking for, and if they were to do a run thru of it with a friend, or across the internet, they'd spot bugs which they didn't before which fixing would improve the experience for pure SP players as well. Remember in fixing bugs, it really helps to get a fresh perspective, to look at things from another point of view especially if you have 3-4 people all looking at the same thing at the same time you can find lots of issues very fast, thus speeding development. This does not mean it has to be done to the level of working for multiple players at once, one person will take the role of the main character and the others can act as companions.

To you it's different because of how it's used, to me it's more about how it was designed. I know i can with very little effort play almost any module and beyond a few issues it will basically just work, and probably better than when i played the OC back at patch 1.06.

[The Fred]

painofdungeoneternal wrote...
Note that my playstyle of PVP PW play is often seen as a reason to completely dismiss everything i am doing, but when what i am doing is looked at beyond the labels it actually is seen as offering value.

It helps to be open-minded. As far as I'm concerned, whatever progress anyone makes is good stuff. A lot of things done for PWs don't really apply to SP, and vice versa, but I often find myself looking at something like, say, the languages system, and thinking "hey, I wouldn't need a lot of that because, but I could take certain bits from it." In the languages case I had already been thinking of making such a system anyway.

painofdungeoneternal wrote...
Often people are so set on NOT being MP, they don't realize their module is already working fine enough for what those LAN folks are looking for...

This can be true, but there are a lot of simple little things like setting variables on the PC speaker (who could change) etc. which need attention... I started off trying to make everything MP-compliant, if unsupported, but eventually decided that I was too lazy to do certain awkward checks and things and made everything SP-only. I do still try to avoid saying, "Oh, this is SP, so it's OK to do this," just in case (though it happens) and put in basic santity checks for other players (the code might get re-used one day, after all), but I for one would not like to try and run any of my projects in MP.

Anyway, we're probably getting off topic a bit (or a lot here) but this is interesting:

Lance Botelle wrote...

This is a feature they enable which allows you to duplicate items, create clones of the player, and quite a few other things which you CANNOT do by any other means. It does not require a campaign or anything else, and things stored will persist in the in game database. <SNIPPED>

That is just a few ideas though, what you can do with it is limited only by your creativity.

Got you now.  Not the sort of thing I would personally cater for, as it seems more aimed at PW like stuff where a player is more likely to replay the same module. (I know players do replay the same mod, but surely less than a PW environment.)

I wonder, could you have some sort of persistant, PW-like SP module? Something where, say, you could play with separate players and interact with them, or where actions taken in one game could affect the course of a later one? I know, for example, Infinite Dungeons used databases, though not in the same way, so I think there's a lot of possibility for them. I'm not sure that a persistant single-player world would have much attraction (what's the point in changing the world for future playthroughs if it's only you who can see it?) but it might make for an interesting experiment. Perhaps you could play as an organisation rather than an individual, and thus play the game with a variety of characters, for example?

[Shallina]

I am the same a Fred, I try to be as much as possible MP for LAN player compatible.

But if it require to much work or if the script needed for it is to "heavy" I skip it for BGR. I have made functionnality that are big trouble to be MP flawless within NWN2.

So I prefer a near Flawless SP module without any compromise, than a SP/MP module where I had to compromise to have the both work. Of course that's only for BGR where I am not free to design things as I wish.

If it was a module where I would be free to do what ever I want I would review the design and extend it so it would be MP compilant. But for the current project I'am tied to the original design.

Modifié par Shallina, 29 avril 2011 - 08:33 .

[Lance Botelle]

The Fred wrote...

It helps to be open-minded. As far as I'm concerned, whatever progress anyone makes is good stuff. A lot of things done for PWs don't really apply to SP, and vice versa, but I often find myself looking at something like, say, the languages system, and thinking "hey, I wouldn't need a lot of that because, but I could take certain bits from it." In the languages case I had already been thinking of making such a system anyway.

Actually, there is a "language" system already available that I set up with my Readable Books hak. I cannot take the credit for the original code, but I did make some alterations to allow Comprehend Language type spells.  (I believe Pain did take some inspiration from this.) Since then, I have also designed a Cypher puzzle that verges on a "language" style piece of coding. Both of these will be used in my module, Better The Demon. (Blog link in sig.)

Regards, Lance

[Eguintir Eligard]

Reider you were probably listening to me speak on the issue of variables. Lets just break this down on both issues:

-dont use campaign variables.

I have exclusively used local variables mainly because I do not completely understand global variables and have a vague recollection of reading somewhere that for some reason, they were not preferable to local variables.

Could someone please discuss when a global variable may be better than local and what (if any) dangers there are with using global variables.

I used globals but that was basically a quick cheap solution. They persist from module to module so I used them. But from a computer science approach, if you campaign is constructed with only locals, it is superior.

Global variables have no context... they are attached to nothing, therefore they rely entirely on VERY good working knowledge of what they do, and can be buggered up pretty easy because they can be accessed by anything easily.

Local variables are attached to objects, so they tend to be self documenting as in what they are used for, and tend to be accessed only by scripts that affect that object, and that objects variables. Its a marrying of the data of an object, with the functions of an object. Its less "secure" in nw script than in other languages as you can't hide the objects variables from being accessed externally, but it still promotes the concept.

Bottom line don't strain yourself to avoid a good practice. There are many if not mot schools of programming that say never use globals.

[The Fred]

Eguintir Eligard wrote...
-dont use campaign variables.

I think what we've just been discussing is "don't use campaign variables as a substitute for locals." If you understand how campaign variables work, there's no reason not to use them. I just don't think that someone who understood them would want to, most of the time.

Eguintir Eligard wrote...
There are many if not mot schools of programming that say never use globals.

There are many schools of programming that say never use reflection, or goto, just like there are many schools of magic that say never use necromancy. Do I listen to them?

[painofdungeoneternal]

Use the simplest thing that works, generally that is a local.

"Keep it simple stupid" is something you should follow, it is probably the most important law in computer programming that is often disobeyed.

[Eguintir Eligard]

Considering goto doesnt even exist in any language worth its salt, ya you do listen to them unless you enjoy making garbage, from garbage.

This is part of why this forum is useless at times, some like Reider wants a straight answer he gets it and someone chimes in with something else and has muddied the waters. Not surprised someone had to argue it was just hoping to avoid it. What I have said represents the programming community at large, and there for is the ideal and most sufficient answer for someone who just has a NWScript question and doesn't really care other than making sure he isn't doing something wrong. The individual opinions of a few people who think they know better than everyone else is something he can find on google. Thats all I have to say on the matter.

Modifié par Eguintir Eligard, 30 avril 2011 - 01:16 .

[The Fred]

The problem with these discussion boards, Eguintir, should be obvious from the name... discussion boards. I said we were going off topic, but given that the original question had been answered and that people seemed to be interested in the topics being discussed, I don't see that it actually does any harm. The only point I was making is that we'd also all agreed that campaign variables are bad for general use and that we were discussing novel uses of them.

I don't like people telling me what that I can't use some piece of code point blank, and the reason most of these "bad" things aren't used is because people don't understand them and use them wrongly (I don't mean bad code I mean bad tools). Despite this, my previous statement was actually meant to be light-spirit and - get this - humourous. I would never actually use goto because I don't want to be eaten by a velociraptor. Besides, NWScript is not exactly "real-world" programming - this is hardly the place to discuss whether some of the most widely-used programming languages in the world are worth their salt or whether the opinion that they're not does, in fact, represent the programming community at large, so I won't, but suffice to say that not everything which applies "out there" applies "in here".

I mean, come on, do you really think that someone likening goto to necromancy is really going to "muddy the waters" over whether someone should use a damn local variable or not?