M. Rieder is a big boy. If he asks which of A, B, or C is best, I'm confident that he can handle responses that say: A is usually best, but B and C sometimes have their specific uses as well.
In fact, I've been really enjoying the fact that M. Rieder has been really good recently about starting open-ended discussions about scripting, building, and custom content. These kinds of discussions are quite valuable at this stage of NWN2's life-cycle, when people really need to get creative about how to use the tools we have to take things farther then ever. As long as builders start using things with their eyes open as to the potential pitfalls, why not get creative?
Which is more efficient and less bug prone: GetFirstPC() or GetOwnedCharacter() ?
Débuté par
M. Rieder
, avril 25 2011 12:45
Retour en haut
#77
Posté 30 avril 2011 - 09:00
Kaldor Silverwand
-
- Members
- 1 585 messages
I'm partial to goto. And I've been programming long enough to know that it can be useful without being brainwashed by "structured" programmers who couldn't code their way out of a wet paper bag (not talking about anyone here). There is no right or wrong to programming.
Overuse of goto leads to unreadable code. That is true.
Overuse of includes leads to unreadable code. That is also true.
Certain structured programming techniques can also lead to unreadable code. Tricks like last, exit, and early returns are just ways around the lack of goto and also lead to difficult to decipher code. Common C techniques like taking advantage of early exiting from if statements also lead to unreadable code. And they teach these things as if they are a good thing to do.
If you are using C then you are using a language that was designed to be read by compilers, not people. That is why it so hard to write bug-proof C code.
So let's stop the goto hate.
Regards
Overuse of goto leads to unreadable code. That is true.
Overuse of includes leads to unreadable code. That is also true.
Certain structured programming techniques can also lead to unreadable code. Tricks like last, exit, and early returns are just ways around the lack of goto and also lead to difficult to decipher code. Common C techniques like taking advantage of early exiting from if statements also lead to unreadable code. And they teach these things as if they are a good thing to do.
If you are using C then you are using a language that was designed to be read by compilers, not people. That is why it so hard to write bug-proof C code.
So let's stop the goto hate.
Regards
#78
Posté 30 avril 2011 - 11:03
The Fred
-
- Members
- 2 516 messages
My point is that pretty much anything is OK if you understand what you're doing. There's no such thing as "wrong" behaviour, only behaviour you didn't expect and didn't want. Things like breaks and returns are essentially forms of goto anyway, and AFAIK pretty much every C-derived language (and I think a lot of others) has some form of goto in it... but I'm not really that much of a programmer, and these forums aren't really the place for programming language discussions anyway, I guess, and they're even further off topic than what we were on before.
Basically, campaign variables are generally bad practice in much the same way GetFirstPC() is... the only difference is that they're more likely (read: very likely) to cause actual unwanted behaviour. GetFirstPC() is more likely just to be a headache later, for example if you convert to MP. However, both of these have their places and uses, GetFirstPC() more so than campaign variables, I imagine. As MasterChanger says, though, getting creative is good, and I can think of a couple of creative uses of campaign variables... for example, you could replace the whole load/save system to use a campaign database instead, which would allow you to play the same SP game with multiple different characters (or this could be used for MP, I suppose), saving by "world" rather than PC. Maybe you could use a campaign database to store game options or something similar, in the way certain projects use a 2da to let players specify choices. There are a lot of interesting possibilities, there, so I'm quite glad that campaign variables were brought up.
Basically, campaign variables are generally bad practice in much the same way GetFirstPC() is... the only difference is that they're more likely (read: very likely) to cause actual unwanted behaviour. GetFirstPC() is more likely just to be a headache later, for example if you convert to MP. However, both of these have their places and uses, GetFirstPC() more so than campaign variables, I imagine. As MasterChanger says, though, getting creative is good, and I can think of a couple of creative uses of campaign variables... for example, you could replace the whole load/save system to use a campaign database instead, which would allow you to play the same SP game with multiple different characters (or this could be used for MP, I suppose), saving by "world" rather than PC. Maybe you could use a campaign database to store game options or something similar, in the way certain projects use a 2da to let players specify choices. There are a lot of interesting possibilities, there, so I'm quite glad that campaign variables were brought up.
#79
Posté 30 avril 2011 - 11:22
Shallina
-
- Members
- 1 011 messages
Goto actually exist in most lunguage in a form or an other. For only one reason, there are things that you can't do without goto.
But nevers use them when you aren't in those specials cases.
For variable, use the most local variable possible for your situation, that's the rule.
The main reason is mainly to avoid naming conflict on big and long project.
For cross module variable, that could be accessed anywhere anytime global variable are the good way. But if you do thing propely for global var you need a document with an index that refer them to avoid name conflict.
Campaign var have their use for PW I suppose, but for "regular mod" MP or SP, since they aren't saved in the save game they are to be avoided since they could alter a replay and those kind of game aren't supposed to change depending on who use it.
Also if they are stored in the NWN database and not in the campaign directory as some seems to say, it means that multiple campaign could access the same var if they got the same name. Basically campaign VAR are to be avoided in any system where you don't have full control (for exemple the computer of the gamer that download your mod is something you don't have controle, and you shouldn't do anything that could alter his installation).
But nevers use them when you aren't in those specials cases.
For variable, use the most local variable possible for your situation, that's the rule.
The main reason is mainly to avoid naming conflict on big and long project.
For cross module variable, that could be accessed anywhere anytime global variable are the good way. But if you do thing propely for global var you need a document with an index that refer them to avoid name conflict.
Campaign var have their use for PW I suppose, but for "regular mod" MP or SP, since they aren't saved in the save game they are to be avoided since they could alter a replay and those kind of game aren't supposed to change depending on who use it.
Also if they are stored in the NWN database and not in the campaign directory as some seems to say, it means that multiple campaign could access the same var if they got the same name. Basically campaign VAR are to be avoided in any system where you don't have full control (for exemple the computer of the gamer that download your mod is something you don't have controle, and you shouldn't do anything that could alter his installation).
Modifié par Shallina, 30 avril 2011 - 11:23 .
#80
Posté 01 mai 2011 - 12:44
M. Rieder
-
- Members
- 2 530 messages
The Fred wrote...
... just like there are many schools of magic that say never use necromancy.
May it never be so.
