You know, the way you guys pounce on anyone using C, trying to coerce them into using C++, really makes it look like some kind of freakish cult. Do I have to start calling you the Plus's Witnesses? :tongue:
.. That's what this is? *runs back to C*
30 Jan, 2009, quixadhal wrote in the 23rd comment:
Votes: 0
Excuse me, Sir? Would you please accept these lovely object-oriented flowers? They'll help you forget your procedural woes and find encapsulated happiness. May the light of Stroustroup brighten your day!
The first one is just from my base, where I utilize encapsulation. Which is possible to some extent in C. I just don't think you can do member functions in C where you can in C++.
Encapsulation? What did it buy you if you have getters and setters? ;-)
It shouldn't… unless you're pussing the 'post' button twice.. Your two posts (#24 & #25) are made 2 minutes apart.. usually double posting's are seconds apart. Hrm. Also doesn't seem to be happening to anyone else, but I'll take a look at the logs.
Also, how do you get color in the chargen again? It's been so long since I've done it I forgot. I'm using send_to_desc_color, but it's still showing color codes. The greeting is color coded, but not the actual chargen. I want it to assume and force ansi during the chargen, not ask before the greeting if they want it or not.
Shouldn't 64 bit integers be big enough for everyone? I've never really ran into anything a long long couldn't handle. Especially with languages, what game needs more than 64 of them?
The first one is just from my base, where I utilize encapsulation. Which is possible to some extent in C. I just don't think you can do member functions in C where you can in C++.
Encapsulation? What did it buy you if you have getters and setters? ;-)
Ease of use, I don't have to type the same 4 or 5 lines in every command? I dunno. Encapsulation is a good thing. Just a pain in the ass to convert an existing base to use. >.>
Banner said:
Also, how do you get color in the chargen again? It's been so long since I've done it I forgot. I'm using send_to_desc_color, but it's still showing color codes. The greeting is color coded, but not the actual chargen. I want it to assume and force ansi during the chargen, not ask before the greeting if they want it or not.
You need to make sure that when the character is made you set the ANSI flag on them so it knows to parse colors.
Shouldn't 64 bit integers be big enough for everyone? I've never really ran into anything a long long couldn't handle. Especially with languages, what game needs more than 64 of them?
That wholly depends on the game in question and what is being done with/within it. I see no reason why someone should limit the number of languages they have. If a person were running a sci-fi space game, for instance, there's nothing wrong with having something where there may be alien races generated automatically, each having their own specific language or even multiple languages if you want to reproduce a multi-cultural setting within other such species.
Of course, that's just one example. I can think of many others. It's usually best to just not assume that "one size fits all". Unless the size is limitless/dynamic, anyways.
30 Jan, 2009, David Haley wrote in the 31st comment:
Votes: 0
So, use a set object, instead of bit vectors. Make the problem go away with some modern engineering…
Where are there 64 at? It says in mud.h you only have 32 and can't add any more.
EDIT:
Kayle said:
Banner said:
Also, how do you get color in the chargen again? It's been so long since I've done it I forgot. I'm using send_to_desc_color, but it's still showing color codes. The greeting is color coded, but not the actual chargen. I want it to assume and force ansi during the chargen, not ask before the greeting if they want it or not.
You need to make sure that when the character is made you set the ANSI flag on them so it knows to parse colors.
That works if you do it right when they make a character, but not for returning characters, nor did I see that code in SWGI. Is there a way to set it on the descriptor and not the player or any other way to do it?
31 Jan, 2009, quixadhal wrote in the 35th comment:
Votes: 0
Don't use a "long long". You'll be sorry when you upgrade (or when your host upgrades) to 64-bit hardware and it doesn't work the way you expect it to anymore. We've had this discussion elsewhere, and my lazy-foo > my search-foo. Suffice it to say, all the built-in integer types are foolishly NOT fixed in size, but can and have changed from the days of 8-bit CPU's to 64-bit CPU's.
In fact, I'd even hazard a guess that on the original PDP-8 that UNIX and C was developed for, a "short" was 8-bit, an "int" was 12-bit, and a "long" was 16-bit? Why 12? The PDP-8 used a 12-bit CPU.
If you don't want to join the C++ mafia, you can use a C bit-field structure. It won't be pretty, and people here will try to assassinate you, but that IS what the language feature was designed to allow (access to individual bits or clumps of bits by named elements).
long long works fine on 64 bit platforms, make sure to use LL in your flag definition: for example #define BV33 1LL << 32
It however does not work well in nongcc compilers, and also, it is not fully supported by all the primitives.
SMAUG' extended bitvector system should work just fine here, and the stock version handles 128 bits and the interface is in line with the normal 32 bit system (one thing though, the int should be changed to unsigned int in the struct, and for that matter all 32 bit flag sets).
That works if you do it right when they make a character, but not for returning characters, nor did I see that code in SWGI. Is there a way to set it on the descriptor and not the player or any other way to do it?
It works for mine. I'd show it to you, but since I rewrote my entire nanny nothing would match up. And would potentially just add to your problem.
(one thing though, the int should be changed to unsigned int in the struct, and for that matter all 32 bit flag sets).
Correct me if I'm somehow wrong here, but I've always been under the impression that the signed-ness of the variable has no significance considering the use of bitwise operations since the sign bit is used as a flag as well. I.e, you're going to have 32 bits, thus 32 flags, available to use no matter if its signed or not.