[ 110 Asian IMP Citizen (NoCorp) ] Tarian
and if you are in a gang but not a corp, or vice versa, it says:
[ 110 Asian IMP Citizen FrstBnk ] Tarian
I would like it so that if you are in either a gang or a corp (you can't be
in both) to show only that gang or corp name like:
[ 110 Asian IMP FrstBnk ] Tarian
And if in neither a gang nor a corp, to say:
[ 110 Asian IMP PRIVATE ] Tarian
Or something like private. I was wondering if that would be possible and if
anyone knows how to code that...cuz I cant seem to figure it out right now.
I tried using some of the string operators like ? and :, but that sorta
screwed things up and I realized that I'm going to need to use some if()'s
and for's...which I suck at...if anyone knows and could send the format part
of do_who to me or to this list, it would be great!
-Tarian (Mistr...@attbi.com - http://everyday.web-wurks.com )
----------------------------------------------------------------------------
------------------------------------------
Hi,
I'm running Rom2.4b6 and it's fairly modified. I'm using Lope's Colour v1.2
or something. It's an old version, but I like it better than the newer
versions. How do I add colour to the greeting that you see in the
connection? Because that is sent to the player through write_to_descriptor,
where colour only applies to send_to_char and act(). If you know how, that
would be great....my email is mistr...@attbi.com, or just respond on this
mailing list. Thanks.
-tarian
The easiest way I can figure out is to define the (NoCorp) and Citizen
strings
to something like "", then if (Gang != "") then org = Gang, else if (Corp !=
"")
then org = Corp, else org = "PRIVATE, then just use the org instead of Gang
or Corp.
Now, if you have a gang, then the corp get's never checked, if you have
neither
you get "Private" ..
- Mystran
Oh, dear.
Well, the best thing is to try to make you unsuck at control structures,
otherwise you will never be able to anything non-trivial.
Write out the function how you think it should look ON PAPER, and then
carefully simulate its behaviour line by line by hand, inventing test
values for your simulation.
If it doesn't work they way you want, try revising your function and going
through it by hand again.
By the time you end up with somethan that works, you'll have a much better
understanding of loops and conditionals!
ms
--
Covenant MUD: "Under Development for Fewer than One Hundred Years!"
In addition to all this, I'd suggest you spend a few days to familiarise
yourself with a debugger of your choice (i.e. read the manual, write a
simple 5-10 lines C program, and learn how to run it from the debugger,
single-step through your program, set the breakpoints, examine
variables, examine the stack, and so on). You're *really* going to need
the debugger, and the sooner you start learning it, the better.
Miro
> Miro
*laugh*
I think most of us started learning the debugger about 5 minutes after
trying to run our first compilation with modified code. I know I did and
the worst thing about it was that the problem was not so much code but
design. I had made an unstable function worse without at first realising
why.
Regards
Andy
--
----- ~~~~~ ====== ~~~~~ -----
Lands of Stone UK based Mordor variant
http://www.landsofstone.org/ telnet://mud.landsofstone.org:4801
Enjoy! (Remove .invalid from address when emailing replies)
Oh, I know that 'use the debugger' is the *DUH* type of a no-brainer
advice. Except that I've met an uncomfortably large number of people who
didn't get it yet, most of them still learning how to program.
The idea is to learn how to debug -first-. It shouldn't be something you
begin doing when you get burned. In particular, one good practice is
that whenever you change something, plonk a breakpoint there, run, and
then watch what's happening. Since it (axiomatically) won't work the
first time, you save the effort of having to run it twice. :)
Miro