30 Jan, 2009, Kayle wrote in the 21st comment:
Votes: 0
Your ways are antiquated and weak. You shall convert. Resistenze is fu…. fut…. Resistenze dun work.
30 Jan, 2009, Banner wrote in the 22nd comment:
Votes: 0
Lobotomy said:
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!
30 Jan, 2009, Tyche wrote in the 24th comment:
Votes: 0
Kayle said:
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? ;-)
30 Jan, 2009, Tyche wrote in the 25th comment:
Votes: 0
Err.. why is MudBytes hanging on me and causing double posts?
30 Jan, 2009, Davion wrote in the 26th comment:
Votes: 0
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.
30 Jan, 2009, Banner wrote in the 27th comment:
Votes: 0
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.
30 Jan, 2009, Scandum wrote in the 28th comment:
Votes: 0
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?
30 Jan, 2009, Kayle wrote in the 29th comment:
Votes: 0
Tyche said:
Kayle said:
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.
30 Jan, 2009, Lobotomy wrote in the 30th comment:
Votes: 0
scandum said:
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…
30 Jan, 2009, Lobotomy wrote in the 32nd comment:
Votes: 0
DavidHaley said:
So, use a set object, instead of bit vectors. Make the problem go away with some modern engineering…

What do you mean by "set object"?
30 Jan, 2009, David Haley wrote in the 33rd comment:
Votes: 0
An object that implements a set container. (Was that your question or did I misunderstand?)
31 Jan, 2009, Banner wrote in the 34th comment:
Votes: 0
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).
31 Jan, 2009, Scandum wrote in the 36th comment:
Votes: 0
long long works fine on 64 bit platforms, make sure to use LL in your flag definition: for example #define BV33 1LL << 32
31 Jan, 2009, Banner wrote in the 37th comment:
Votes: 0
While that's all fine and dandy, can I get a resolution to the question I asked as OP?


EDIT: NVM, seems to be working fine now.
31 Jan, 2009, Sharmair wrote in the 38th comment:
Votes: 0
Scandum said:
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).
31 Jan, 2009, Kayle wrote in the 39th comment:
Votes: 0
Banner said:
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.
31 Jan, 2009, Lobotomy wrote in the 40th comment:
Votes: 0
Sharmair said:
(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.
20.0/77