Ok, so i'm trying to figure out why if every documentation about ROM out there states that you
can have a portals V0 set to -1 to have unlimited charges, when the code below (from act_enter.c)
says portal->value[0] == -1 "fades out of existence, then at the end it uses (handler.c)'s extract_obj(portal);?

I mean, yeah, i could change it, but first of all, why does it do this, and second, will i screw up everything?

if (portal != NULL && portal->value[0] == -1)
        {
            act ("$p fades out of existence.", ch, portal, NULL, TO_CHAR);
            if (ch->in_room == old_room)
                act ("$p fades out of existence.", ch, portal, NULL, TO_ROOM);
            else if (old_room->people != NULL)
            {
                act ("$p fades out of existence.",
                     old_room->people, portal, NULL, TO_CHAR);
                act ("$p fades out of existence.",
                     old_room->people, portal, NULL, TO_ROOM);
            }
            extract_obj (portal);
        }

Why? Because the author couldn't / didn't read the code or check an appropriate area file?

I don't really know, but I do know the DizzyMUD Area Building Guide is much more accurate.

Dizzy Builder's Guide


For legacy reasons, I'd say don't change the code - it's fine. Just remember to set permanent portals to '0', not '-1'.

once again, thankyou sandi!

yeah, after checking out "Dizzy" I'm totally going to roll with that instead.

-1 is correct for a permanent portal…

You might have built someplace where their code was modified for that to be true, but simply looking at the code that staryavsky posted above shows that, for at least him, it is not. You can't argue with code :grinning:

Hmm, it might be noted that I am using a QuickMud base and not stock Rom2.4
Maybe that is why the above code block is different than the standard rom24.doc in the doc folder? Anyhoo, I guess it dosn't matter, in the end I would have to agree, its all about the code.

From ROM 2.4b, enter.c

/* charges */
	if (portal->value[0] > 0)
	{
	    portal->value[0]–;
	    if (portal->value[0] == 0)
		portal->value[0] = -1;
	}

It would make more sense if it conformed to the behavior of lights and wands, but there it is.

If you're using QuickMud, then I can definitely settle this discussion now on one condition:

if ispc $n 'whereas $n = staryavsky
then
mob echo Portals can be made eternal by leaving the v0 set as 0
mob echo If the portals v0 is set to -1, then it will always disappear after 1 use
mob echo So, leave v0 as 0 and you'll always have an eternal portal! Yay!!!!!
endif

:alien:


Basically staryavsky, that was my lame @$$ attempt to say that when our muds Coder/Owner put up QuickMud, I had the same question. I'm used to the value of -1 being the "eternal" modifier. Unfortunately for some reason, QuickMud has it written it, but it doesn't work. After playing around with it for a little while, I realized that I could just leave v0 as 0 without our Coder/Owner changing anything (at least, to my knowledge he hasn't changed anything as Sandi has suggested) and it works perfectly everytime. Ironically enough, I'm 96% sure you could to the same when making containers to never fill, fountains to never dry up, and drink containers to never empty. I hope that answers your question, but I'm fairly certain that I didn't because from what I gathered from the conversation, you guys were talking about the specifics of the actual code behind it…..hrmm…

Sorry to disappoint, but no, setting V0 to zero just gives you a drink container with no room in it. And fountains don't even check it, they always work.

Yeah, I completely rewrote my fountain code due to that, and then added in update to have them fill up with more fluid. Groovy ;).

So much for the fount of knowledges :P

Nah, I know what the code I'm working with does. It's cool though. Each mud is uniquely different, which is what makes them cool!