04 Feb, 2009, Janus wrote in the 1st comment:
Votes: 0
First thank-you for making a godwars section as i having been playing the codebases for a while and tinkering with the code i feel a certain affection for them.

I've been reading this site for a while now as i have been playing with code on and off for a few years. I finally settled on low4. I dont know why just like the feel of it although i do have a few problems that i could really use some advice on.
I'll admit first of all i am just a tinkerer at present but learning the right way with the books, but these things are a litlle irritating when you dont know how to fix them let alone where to look to find them.

1) Mud Base Colour.

I found it once a while back and i remember physically slapping myself when i found out how to do it. Its the code that changes the mud from its stock green colour. I've plum forgotten where the code is for that let alone how i cracked it. (Old age sucks)
If anyone can help me on this please do!

2) LoW4 OLC

I hate OLC at the best of times but the copy i have seems to have a bug in the redit program.
You can create a new area fine with the vnums set as they should be.
When you go to create a room in that area it changes the vnum 33000 to -32536. Yep thats a negative value.
Which of course the mud doesnt like so it dumps you in limbo when you try to asave and copyover over with the vnum 33000 not existing.
I wondered if anyone else has had this problem and if so where the problem is.

Thanks for taking the time to read this and thanks for any help you guys can give.
05 Feb, 2009, Sandi wrote in the 2nd comment:
Votes: 0
Not sure about the OLC, but I suspect the green is from your client.
In zMUD, it's View/Settings/Colors - the 'default colour' is likely set to green.
05 Feb, 2009, Janus wrote in the 3rd comment:
Votes: 0
Thanks but makes me wonder what i edited before hand to change the colour as i was using zmud both times.
It was on default now i feel daft as never needed to change that for other muds.

I tried increasing the MAX_KEY_HASH to see if the bug was being caused by that being too low.
It had no effect and the same number keeps appearing.
05 Feb, 2009, Janus wrote in the 4th comment:
Votes: 0
I have a feeling that i will be asked for the redit code that i am using so posting it :)

REDIT( redit_create )
{
AREA_DATA *pArea;
ROOM_INDEX_DATA *pRoom;
char arg [ MAX_INPUT_LENGTH ];

int value, iHash;

argument = one_argument( argument, arg );

value = atoi(arg);

if (arg[0] == '\0' || value == 0)
{
send_to_char("{YSyntax: create [vnum]\n\r", ch);
return FALSE;
}

pArea = get_vnum_area(value);

if (pArea == NULL)
{
send_to_char("{YREdit: That vnum is not assigned an area.\n\r", ch);
{
send_to_char("{YREdit: That vnum is not assigned an area.\n\r", ch);
return FALSE;
}

if (!IS_BUILDER(ch, pArea))
{
send_to_char("{YREdit: Vnum in an area you cannot build in.\n\r", ch);
return FALSE;
}

if (get_room_index(value) != NULL)
{
send_to_char("{YREdit: Room vnum already exists.\n\r", ch);
return FALSE;
}

pRoom = new_room_index();
pRoom->area = pArea;
pRoom->vnum = value;

if (value > top_vnum_room) top_vnum_room = value;

iHash = value % MAX_KEY_HASH;
pRoom->next = room_index_hash[iHash];
room_index_hash[iHash] = pRoom;
set_editor( ch->desc, ED_ROOM, pRoom );
SET_BIT(pArea->area_flags, AREA_CHANGED);
send_to_char("Room created.\n\r", ch);
return TRUE;
}









void do_redit (CHAR_DATA * ch, char *argument)
{
ROOM_INDEX_DATA *pRoom;
char arg1[MIL];

argument = one_argument (argument, arg1);

pRoom = ch->in_room;

if (!str_cmp (arg1, "reset"))
{
if (!IS_BUILDER (ch, pRoom->area))
{
send_to_char ("{yInsufficant security to modify room.\n\r", ch);
return;
}

reset_room (pRoom);
send_to_char ("Room reset.\n\r", ch);
return;
}
else if (!str_cmp (arg1, "create"))
{
if (argument[0] == '\0' || atoi (argument) == 0)
{

{
send_to_char ("{ySyntax : redit room create [vnum]\n\r", ch);
return;
}

if (redit_create (ch, argument))
{
char_from_room (ch);
char_to_room (ch, ch->desc->pEdit);
SET_BIT (pRoom->area->area_flags, AREA_CHANGED);
pRoom = ch->in_room;
}
}
else if ( arg1[0] != '\0' )
{
pRoom = get_room_index (atoi (arg1));

if ( pRoom == NULL )
{
send_to_char( "{yRoom inexsistant.\n\r", ch );
return;
}
}

if (!IS_BUILDER (ch, pRoom->area))
{
send_to_char ("{yInsufficiant security to edit this area.\n\r",ch);
return;
}

if ( pRoom == NULL )
bugf( "do_redit : NULL pRoom, ch %s!", ch->name );

if (ch->in_room != pRoom)
{
char_from_room(ch);
char_to_room(ch, pRoom);
}

set_editor(ch->desc, ED_ROOM, pRoom);
return;
}
05 Feb, 2009, Igabod wrote in the 5th comment:
Votes: 0
Don't know about the color thing, I've been trying to figure that out for a while now. As to the vnums, you've got it set as a short int and it should be set as a long int in the merc.h somewhere, I don't recall exactly where but thats your problem there. The reason it changes anything over 32000 (and a few hundred more) to a negative number is because short int only allows for that. The bug isn't with redit at all. You can use redit with no errors for any room vnum between -32536 and 32536 (the positive number is probably slightly lower or higher, I forget). If you are dead set on having more vnums than that you will have to convert it to long int but I'm not sure exactly where that is, I think it's hinted at in one of my previous posts in this forum. I'll look around for it and edit this post with a link to it if I find it.

[edit to add]ok what you're looking for isn't hinted at but the conversation I was talking about told me where to look. In merc.h you'll want to look around for stuct room_index_data and then find sh_int vnum; You'll want to change that sh_int to int. I'm not sure if you'll need to do this in any other stuct, but this was the only one I could find that would do it. With this knowledge you should be able to figure it out for yourself if more work is needed.

[edit to add links] You may want to check out the following threads from this forum for some additional help with low4. You'll have to skip over a little thread derailment on some of these but don't worry bout that. Here's the links:
http://www.mudbytes.net/index.php?a=topi...
http://www.mudbytes.net/index.php?a=topi...
http://www.mudbytes.net/index.php?a=topi...
http://www.mudbytes.net/index.php?a=topi...

I think these links will be of some use to you.
05 Feb, 2009, Sharmair wrote in the 6th comment:
Votes: 0
To change the vnum to an int, you probably will have to change more then just the vnum member
of your room data structure. You will have to change all members, arguments and variables that
are used for vnums (or make sure they are int already, like value is in your code you posted). Off
hand, I would look at the vnum members in anything that uses vnums (objects, mobs, rooms etc -
probably in the indexes, but I am not sure in your code). All arguments to functions that take a
vnum, and all variables used when working with vnums (meaning ones you assign with a vnum, or
use to set a vnum). Some of this might already be int, like value in your code here, but you should
follow the code flow and make sure.

As far as the color, looking at your code, I see you seem to have some form of color tokens already.
If the place you want to set the color is after the player has a character structure (probably after
they have entered a name on log in) you could just add the color token you want at the start of the
text you want to have colored (make sure you use the send_to_char type functions and not the
send_to_descriptor functions). If you mean you want to change the color right at greeting, you
will have to embed raw ANSI color codes in the greeting (it would be something like "\033To change the vnum to an int, you probably will have to change more then just the vnum member
of your room data structure. You will have to change all members, arguments and variables that
are used for vnums (or make sure they are int already, like value is in your code you posted). Off
hand, I would look at the vnum members in anything that uses vnums (objects, mobs, rooms etc -
probably in the indexes, but I am not sure in your code). All arguments to functions that take a
vnum, and all variables used when working with vnums (meaning ones you assign with a vnum, or
use to set a vnum). Some of this might already be int, like value in your code here, but you should
follow the code flow and make sure.

As far as the color, looking at your code, I see you seem to have some form of color tokens already.
If the place you want to set the color is after the player has a character structure (probably after
they have entered a name on log in) you could just add the color token you want at the start of the
text you want to have colored (make sure you use the send_to_char type functions and not the
send_to_descriptor functions). If you mean you want to change the color right at greeting, you
will have to embed raw ANSI color codes in the greeting (it would be something like "\033[1;37m").
I am assuming you have token parsing in your send_to_char function and not in your
send_to_descriptor function, also, you might have #define s someplace that you can use for those
color codes (like #define ANSI_WHITE "\033[1;37m").
05 Feb, 2009, Janus wrote in the 7th comment:
Votes: 0
Thank you so much for your help guys as i went though merc.h and found a lot of the OLC code hadnt been switched over to int vnum; where had aedit had already been done so thats why it accepted the area creation.
I've prevented future problems by changing it all now and forgetting later why something doesnt work.
I knew it had a limit on the vnums it could handle but didnt go down that path of thinking due to aedit working, I'll try to remember to be a little more objective when debugging so i dont narrow myself to checking one avenue and disregarding where the possible fault could be.

The colour i fixed on my zmud client but i am guessing muds that i play on have done something similar to the above suggested. I do seem to remember playing with the code just after they enter a name on the player login sequence as memory coming back to me i remember getting that working then pondering how to make a colour greeting.

All is well and fixed for now and thanks Igabod i have to chase down that time of day bug but i squashed most the int dam; errors.

My first major project will be implementing a roleplay system where players can create a session and join it. The mud then logs the channel to a file which can be either viewed as part of a webpage or called to display in the mud via a command. I forsee lots of bug and problems for me in the future but thats part of the fun :)

Many thanks again and if i find any bug i fix i'll post them here to help others on a low4 base
05 Feb, 2009, Igabod wrote in the 8th comment:
Votes: 0
Glad I could be of some assistance. I know what you mean with your question on color, I can't really think of a better way to phrase the question, but what sharmair suggested isn't exactly the fix you're looking for. It will change the color but only in certain places, you're wanting to set the default color to something instead of just defaulting though. Hopefully someone can understand the actual question and will be able to post how to do it.
05 Feb, 2009, Janus wrote in the 9th comment:
Votes: 0
I think i can basically say what it is we are both looking for here.

In simplest terms its basically like a default client color override.
I was coding on the deluxe codebase when i actually found where it was so have no point of reference to it now,

Basically everything is green currently in the mud unless altered by using the colour code i have in. This includes the log messages that only imm's see to looking at the room description etc.
I know theres a section of the code somewhere in there that overrides the client default colour and sets it to the colour that you set in the code. Ethereal mists (which when it is running as coders seem to never log on anymore) has it in there and when i was coding Shadows of the Underworld i found it there on the same deluxe codebase. (I now loathe that codebase) i know this because i still play ethereal mists on the rare occasion for sentimental reasons and zmuds default colour for that connection is set to green yet the mud displays in the dull grey colour.
05 Feb, 2009, Cratylus wrote in the 10th comment:
Votes: 0
Quote
LoW4 Asking for pointers please


http://xkcd.com/138/

-Crat
05 Feb, 2009, Sharmair wrote in the 11th comment:
Votes: 0
If your client is not actually displaying an ANSI gray as green (on some clients you can change
what each ANSI code is displayed as), it might be that the MUD is just sending an ANSI color
reset instead of a specific color. Though most clients take a reset to be gray foreground on
black background, I have heard that zmud does use a green foreground instead. The way I
handle this in the MUD code I work with is to just always send specific color codes and never
send just a reset. The reset code is either "\033If your client is not actually displaying an ANSI gray as green (on some clients you can change
what each ANSI code is displayed as), it might be that the MUD is just sending an ANSI color
reset instead of a specific color. Though most clients take a reset to be gray foreground on
black background, I have heard that zmud does use a green foreground instead. The way I
handle this in the MUD code I work with is to just always send specific color codes and never
send just a reset. The reset code is either "\033[m" or "\033[0m". I would replace any resets
with the specific gray code of "\033[0;37m".
05 Feb, 2009, Janus wrote in the 12th comment:
Votes: 0
Just as an addition for the increasing vnums part that might be useful to the next coder.

Not only do you need to change all references to "sh_int vnum;" to "int vnum;"
You also need to change "sh_int home;" to "int home;"

These can all be found in merc.h

The reason is using sh_int cuts off the vnums as well reverting the code to set your home to -32536.
05 Feb, 2009, Janus wrote in the 13th comment:
Votes: 0
I believe you could be right with the resets but where to actually change it i am unable to find.
I believe you are correct as immediatly after the copyover command the code forces you to do_look ("") and the room description then appears as i would expect to see in the very light grey colour. On typing look however it has reverted back to the room description being the stock green colour.

I'll keep trawling though the lines of code whilst making my shell go pretty colours and see if i cant find it.
0.0/13