27 Jan, 2010, triskaledia wrote in the 1st comment:
Votes: 0
I had a player point out that once items go into their container (in inventory) their item count in their score doesn't go down, preventing them from gathering more items. So here's what I tried to do:

/*
* Move an object into an object.
*/
void obj_to_obj (OBJ_DATA * obj, OBJ_DATA * obj_to)
{
obj->next_content = obj_to->contains;
obj_to->contains = obj;
obj->in_obj = obj_to;
obj->in_room = NULL;
obj->carried_by = NULL;
//CHAR_DATA *ch;
if (obj_to->pIndexData->vnum == OBJ_VNUM_PIT)
obj->cost = 0;

//FUCKER
for (; obj_to != NULL; obj_to = obj_to->in_obj)
{
if (obj_to->carried_by != NULL)
{
obj_to->carried_by->carry_number += get_obj_number (obj);
obj_to->carried_by->carry_weight += get_obj_weight (obj) * WEIGHT_MULT (obj_to) / 100;

/*********Causes a nasty crash, possibly because of the call to CHAR_DATA.
if(obj_to->item_type == ITEM_CONTAINER)
{
stc("Deducting item count info from ch", ch);
ch->carry_number -= get_obj_number (obj);
}
Attempted to deduct item count from the player if it's in a container.*********/
}
}

return;
}


That was attempted in handler.c and the only place I found where items are deducted from the player so I gave it a shot there. If anyone knows how to make it so items don't count towards the player once in a container, or could point me towards the correct file to modify it'd be appreciated.
–Silence Tyire of Reanimation

Edit by kiasyn to add code tags
27 Jan, 2010, Zeno wrote in the 2nd comment:
Votes: 0
What codebase is this?

And yes, using CHAR_DATA won't work because it wasn't set to anything. You want to use obj_to->carried_by
27 Jan, 2010, triskaledia wrote in the 3rd comment:
Votes: 0
It's a QuickMUD. I was just thinking about trying that way, so now I will.
–Silence Tyire
27 Jan, 2010, Zeno wrote in the 4th comment:
Votes: 0
This should probably moved to the correct forum section then, under Rom.
27 Jan, 2010, triskaledia wrote in the 5th comment:
Votes: 0
Didn't realize there was a forum dedicated to ROM code, I've always just used this forum. Will do next time. Thanks for the help, items go down now when placed into the players container.
27 Jan, 2010, Skol wrote in the 6th comment:
Votes: 0
Yeah, trisk it's stock in rom/diku for total items carried to be that number. What I'd suggest is having actually two numbers, rather than just saying they have less.
IE.
Items: 2343 Inventory: 13

I've actually considered having an 'inventory' number, as the original games often had 'you can't carry anything more without dropping something' type approach. Rather than the 1500 items some people carry 'on hand' now in some games.

It does come down to a realism vs play vs lame though. But maybe 10-15 items 'in hand' (meaning closely grabbable, ie belt, hand, shirt pocket etc).
27 Jan, 2010, kiasyn wrote in the 7th comment:
Votes: 0
Moved to ROM forum.
28 Jan, 2010, triskaledia wrote in the 8th comment:
Votes: 0
This is what I've ended up doing:

/*
* Move an object into an object.
*/
void obj_to_obj (OBJ_DATA * obj, OBJ_DATA * obj_to)
{
obj->next_content = obj_to->contains;
obj_to->contains = obj;
obj->in_obj = obj_to;
obj->in_room = NULL;
obj->carried_by = NULL;
if (obj_to->pIndexData->vnum == OBJ_VNUM_PIT)
obj->cost = 0;

for (; obj_to != NULL; obj_to = obj_to->in_obj)
{
if (obj_to->carried_by != NULL)
{
obj_to->carried_by->carry_number += get_obj_number (obj);
obj_to->carried_by->carry_weight += get_obj_weight (obj) * WEIGHT_MULT (obj_to) / 100;

/***Thanks to Zeno for the code change.***/
if(obj_to->item_type == ITEM_CONTAINER)
{
obj_to->carried_by -= get_obj_number (obj);
}
}
}

return;
}


:The part following my appreciation is what was added to the standard QuickMUD code.
Adding another "max_items" to a character is a good idea to prevent "pack-muleing".
On other MUD's I've played through the years, I've found that weights on objects
haven't been realistic, and with those observations, I've pushed my builders to try and
enter reasonable weights for objects. I also found during some of my trials that the Ivan
OLC combined with the stock QuickMUD does a bogus math equation for the weights
dividing the weight that was set by 10. Instead of messing with that part of the code
and messing things up with that, I've simply added a weight = arg1 * 10, in the editors
for weight, so that the objects come out as their true weight intended.
But for more realism, how to define where realism comes into play in a fantasy world?
As a level 42 with a character I created to test for bugs, I can hold 100+ items, and 500+
pounds (or whatever your weight is determined in). Searching the code a while back when
I was upping the max stats to 50, I found that your max weight/items is determined by
your strength. So, I figure most beings can hold at most 100-200 pounds for a short
period, and then have to rest, but for the most part, 10-25 pounds is a decent weight
to be carrying around by hand. Another 50-100 in a container without too much strain.
Which brings in other options, is it a decent idea to create a "weight strain" option that
drains move per second/tick/etc etc?

Edit by kiasyn: added code tags again
29 Jan, 2010, triskaledia wrote in the 9th comment:
Votes: 0
I think I had a terrible oversight, once again, when I dropped my finished code bit in here.
After running the MUD for a while, I kept running into a crash when players would log the
mud. Now if I'm reading this correctly:
obj_to->carried_by -= get_obj_number (obj);
if the object targeted by the player to put the objects into it subtracts the object out almost
mimicking the drop command, so the item becomes NULL because it no longer exists, but is
still being read in the container. I believe the best solution now is to change the "thanks to Zeno part to:
/***Thanks to Zeno for the code change.***/
if(obj_to->item_type == ITEM_CONTAINER)
{
obj_to->carried_by -= 1;
}
This makes it so the item counter on the player goes down by one, but doesn't cause a nasty log report.
29 Jan, 2010, Skol wrote in the 10th comment:
Votes: 0
On the 'encumberance' issue, what I did was to make it lag you if you're overloaded with items. If you get _really_ weighted down, it gets really slow to move. Makes things fun ;).
29 Jan, 2010, kiasyn wrote in the 11th comment:
Votes: 0
triskaledia said:
I think I had a terrible oversight, once again, when I dropped my finished code bit in here.
After running the MUD for a while, I kept running into a crash when players would log the
mud. Now if I'm reading this correctly:
obj_to->carried_by -= get_obj_number (obj);
if the object targeted by the player to put the objects into it subtracts the object out almost
mimicking the drop command, so the item becomes NULL because it no longer exists, but is
still being read in the container. I believe the best solution now is to change the "thanks to Zeno part to:
/***Thanks to Zeno for the code change.***/
if(obj_to->item_type == ITEM_CONTAINER)
{
obj_to->carried_by -= 1;
}
This makes it so the item counter on the player goes down by one, but doesn't cause a nasty log report.


wow wait, that really works?

obj_to->carried_by should be a ptr, if you're doing arithmetic operations on it, it is going to have hugely undesirable effects.
29 Jan, 2010, KaVir wrote in the 12th comment:
Votes: 0
Skol said:
On the 'encumberance' issue, what I did was to make it lag you if you're overloaded with items. If you get _really_ weighted down, it gets really slow to move. Makes things fun ;).

Do you mean it makes certain actions slower to perform, or that it literally lags your connection? If the latter, won't newbies (who love to load themselves up with lots of gear) just think your mud is really laggy?
29 Jan, 2010, ATT_Turan wrote in the 13th comment:
Votes: 0
kiasyn said:
wow wait, that really works?

obj_to->carried_by should be a ptr, if you're doing arithmetic operations on it, it is going to have hugely undesirable effects.


Indeed. obj_to->carried_by is a pointer to a CHAR_DATA structure, and you do not want to be modifying what character it's pointing to. Instead, you want to modify that structure's carry_number field - or prevent it from being modified in the first place. What you should do is:

/*
* Move an object into an object.
*/
void obj_to_obj (OBJ_DATA * obj, OBJ_DATA * obj_to)
{



if (obj_to->carried_by != NULL)
{
if (obj_to->item_type!=ITEM_CONTAINER)
obj_to->carried_by->carry_number += get_obj_number (obj);

obj_to->carried_by->carry_weight += get_obj_weight (obj) * WEIGHT_MULT (obj_to) / 100;

}



}
29 Jan, 2010, Skol wrote in the 14th comment:
Votes: 0
KaVir said:
Skol said:
On the 'encumberance' issue, what I did was to make it lag you if you're overloaded with items. If you get _really_ weighted down, it gets really slow to move. Makes things fun ;).

Do you mean it makes certain actions slower to perform, or that it literally lags your connection? If the latter, won't newbies (who love to load themselves up with lots of gear) just think your mud is really laggy?


It won't normally let them get that loaded down, but if they land like a BIG fish or withdraw thousands of coins or such heh. It just lags moving though, and tells them that they are struggling under the strain of weight etc. Rare, but I caught a shark once and had to drag it room by room, resting every other room lol.
30 Jan, 2010, triskaledia wrote in the 15th comment:
Votes: 0
Quote
wow wait, that really works?
obj_to->carried_by should be a ptr, if you're doing arithmetic operations on it, it is going to have hugely undesirable effects.


You've no idea the undesirable effects this has caused on the code… I've completed commented out what I had, and looking into trying the method ATT_Turan suggested. What I had posted caused random objects to be pulled from pfiles, long lists of in the logs of objects being nonexistant, random crashes, random objects loading into the area's (most of them the Immortal 500d500 weapons), and a stress level I don't even want to discuss. So, taking another shot at it with Turan's idea, and hopefully I get better results.
Also, what is a ptr?
30 Jan, 2010, triskaledia wrote in the 16th comment:
Votes: 0
Well, the problem with ATT_Turan's idea is that it deducts the amount from the player when placing it into objects, but once they take the items out of the container, it doesn't add back to the player. So what I feel I've ran into is a "You can't deduct the total item count from the player because the objects become NULL and you can't just add a item count when the target isn't a container because the item count will begin to bug." It's a mess, but I'll keep trying at it. At least Turan's idea isn't crashing the mud for random reasons and giving me a long log of bugs.
30 Jan, 2010, Zeno wrote in the 17th comment:
Votes: 0
A pointer.
30 Jan, 2010, triskaledia wrote in the 18th comment:
Votes: 0
I don't know where to post this and don't want to start a new post so…
I'm looking for a coder who knows how to successfully run the GDB Debugger
and any other coders who just want to help me code various new things.
It's been 4 years of ups and downs for me, long periods where I would be
coding alone, then have someone log on to push me to code great things
into the game, just to have them split in a few months - or days. Reanimation
was originally a project between me and a friend, both of us knowing little
to nothing about coding to make a MUD similar to the one we used to play
that was shut down (Realms of the Forgotten), just a great place to play
and chat. Then life hit him… bla bla.. and I was left to code alone.
What I code is a lot of trial and error, and I do tend to fall back
and rely on this place for help since I found it a year ago or so. Hit the game
up at reanimation.mcp-server.com:6868 if you want to help, or just point
out all my bugs to me.
30 Jan, 2010, Crelin wrote in the 19th comment:
Votes: 0
I taught myself to code through trial and error on diku derivs, I feel it's one of the better ways to learn and as you can see…8 years later I find myself on this forum asking questions and learning new things each time. On that note, as a less knowledgable coder I feel it would be a great asset to you to learn gdb yourself and not rely on someone else to use it as it will be an exceptional aid in your learnings. This site is a great resource. I guess my other point is that yeah, hiring another coder could be quite useful but I would also suggest keeping at your own pace with your mud so you don't end up with a bunch of complex code you can't understand and therefore have a hard time editing, fixing or changing if that coder decides to leave and the need arises.

Edit: Just logged on…and this is something I see a lot that detracts a LOT of people from playing certain muds. Overuse of color…some of it is decent but when it gets overused like that, you lose the ability to highlight important things with color and therefore substantially benefit from it's organization potential and it becomes quite straining on the eyes and a distraction from the gameplay itself.
30 Jan, 2010, Kline wrote in the 20th comment:
Votes: 0
Crelin said:
I taught myself to code through trial and error on diku derivs

<– This guy, too. That and lots of questions :).
0.0/24