14 Feb, 2007, gazzy123 wrote in the 1st comment:
Votes: 0
Is there a way to copy a whole struct for example ch->pcdata to a temporary holding variable and then DISPOSE/free the ch and the pcdata structure and still be able to use the "temp variable" to create and fill a new pcdata with that variable?

example (not accurate coding but you get the idea):

CHAR_DATA *ch;
PC_DATA temp_pcdata;

temp_pcdata = ch->pcdata;
DISPOSE(ch->pcdata);
DISPOSE(ch);

ch = new_char();
ch->pcdata = new_pcdata();
ch->pcdata = temp_pcdata;

is this possible someway?
14 Feb, 2007, kiasyn wrote in the 2nd comment:
Votes: 0
in c++ you would overload the = operator

PC_DATA& PC_DATA::operator=( PC_DATA *copyFrom )
{
this->name = copyFrom->name; // etc
return *this;
}


I think thats the syntax - I'm a little rusty.
14 Feb, 2007, Davion wrote in the 3rd comment:
Votes: 0
I think, if you're doing that you can just do
pc_data var;
var = *(ch->pcdata);


That should do what you want. Doing
pc_data var;
var = ch->pcdata;

Wont work because the pcdata is of type (pc_data *) so you have to dereference it to use '='. This, because of the pointers, is a relitively soft copy. It just copies the address of the pointers and assigns that to the new ones. Should DISPOSE(ch->pcdata) also free the values those pointers are pointing too, the ones in the copy would become invalid. But if that doesn't happen, you're pretty safe.
14 Feb, 2007, gazzy123 wrote in the 4th comment:
Votes: 0
Davion said:
I think, if you're doing that you can just do
pc_data var;
var = *(ch->pcdata);


That should do what you want. Doing
pc_data var;
var = ch->pcdata;

Wont work because the pcdata is of type (pc_data *) so you have to dereference it to use '='. This, because of the pointers, is a relitively soft copy. It just copies the address of the pointers and assigns that to the new ones. Should DISPOSE(ch->pcdata) also free the values those pointers are pointing too, the ones in the copy would become invalid. But if that doesn't happen, you're pretty safe.


it didn't even compile.. I'm thinking about memcpy would that work?
like memcpy(temp_pcdata,ch->pcdata,sizeof(ch->pcdata));
14 Feb, 2007, Davion wrote in the 5th comment:
Votes: 0
void do_test(CHAR_DATA *ch, char *argument)
{ PC_DATA var;
char buf[MSL];

var = *(ch->pcdata);

sprintf(buf, "%s\n\r", var.pwd );

send_to_char(buf,ch);
return;
}


That worked fine for me.
14 Feb, 2007, gazzy123 wrote in the 6th comment:
Votes: 0
The function I'm using is more like this:

void do_test(CHAR_DATA *ch, char *argument)
{
PC_DATA var;
CHAR_DATA *target,*newchar;
DESCRIPTOR_DATA *desc1;
char buf[MSL];
char target_name;



if ((target = get_char_room(ch, NULL, argument)) == NULL)
{
send_to_char("that char cannot be found.\n\r",ch);
return;
}

var = *(target->pcdata);

target_name = str_dup(target-name);
desc1 = target->desc;

DISPOSE(target->pcdata);
DISPOSE(target);

newchar = new_char();
newchar->name = str_dup(target_name);
newchar->pcdata = new_pcdata();

char_to_room(newchar,ch->in_room);

newchar->next = char_list;
char_list = newchar;
reset_char(newchar);

target->desc = NULL;

extract_char(target,TRUE);

newchar->desc = desc1;
newchar->desc->character = newchar;
newchar->desc->connected = CON_PLAYING;
newchar->pcdata = var;

return;
}
14 Feb, 2007, Davion wrote in the 7th comment:
Votes: 0
Without actually seeing the errors you're getting I'm simply going to have to guess.

newchar->pcdata = var;


As I explained before, newchar->pcdata is of type (PC_DATA *), and var is PC_DATA. You must dereference the pointer. So!
*(newchar->pcdata) = var;
14 Feb, 2007, gazzy123 wrote in the 8th comment:
Votes: 0
Ok, but after extract char then the var is empty

if I do for example bugf("%s",newchar->pcdata->title); it shows up as Wed Feb 14 15:50:18 2007 :: [*****] BUG: in the log

so I'm guessing there no way of copying the orginal data toa new data and then free the orginal memory and still be able to keep the new data. cause someway the new data is pointing to the old and the old doesn't exist.
14 Feb, 2007, Sandi wrote in the 9th comment:
Votes: 0
I think you're right, the struct is just pointers.

I have an old snip from Dribble, remort.c, and he does something like this:
sprintf( player_name, "%s", capitalize( ch->name ) );
sprintf( player_pwd, "%s", ch->pcdata->pwd );
player_incarnations = ch->clast;
extract_char( ch, FALSE );

then:
load_char_obj( d, player_name );
d->character->pcdata->pwd = str_dup( player_pwd );
d->character->clast = player_incarnations;

I guess you just have to do it line by line. :sad:
14 Feb, 2007, Guest wrote in the 10th comment:
Votes: 0
It might be helpful to know exactly why you want to do this. It looks as though you need to make a copy of a player character for some reason, but you're going about it the wrong way. You can't just assign an address to a variable, delete the contents of the address, and expect that to then work when you reassign it to a new character. The contents of the variable are gone at that point. Your variable points to invalid memory.
14 Feb, 2007, gazzy123 wrote in the 11th comment:
Votes: 0
Yeah you are correct. ok I'll explain in more detail.

I'm doing a skill that makes 2 chars combine to one, creating a new char and adding their combined stats for hp/mana/move str/dex/con hitroll/damroll.

the person issuing the command targeting the other player gets "ontop" and it's that players name that goes for the new char, aswell as status/class/race and a few other things.

1. saves the descs to desc1 and desc1 variables to be able to use them later.
2. I create the new char and substruct pcdata
3. adding the combined stats to their places like mergedchar->hit etc.
4. creating a sub char structure named slave (mergedchar->slave)
5. now I save the desc1 and desc2 to mergedchar->desc and mergedchar->slave->desc and extract the ch and target from the game, casue I dont want to send them to a voidroom to be there linkdead (some people suggested this).

so now I figured that instead of doing local variables of every variable I want to save to mergedchar,mergedchar->pcdata,mergedchar->slave,mergedchar->slave->pcdata I figured that perhaps I could save the whole ch->pcdata structure with it's data and variables to later load into mergedchar->pcdata etc

instead of doing like slave_title = str_dup(target->pcdata->title); just to be able to do mergedchar->slave->pcdata->title = str_dup(slave_title);

and the same thing for the rest of the data I want saved.

but how ever I tried I couldn't figure out how to get the structure saved and valid after extraction of the ch and target. and this is why I'm asking for help.

I guess if I cannot get this done I either need to make 10-30 variables to save data or simply not extract the chars but rather move them to a room and let em be linkdead.

I hope this explanation together with my previous post is good enought, to make you guys and girls able to help me if you can and want.

now after all that is set.. I save the original chars and extract them out of the game

===================

OK, tried with moving the 2 chars ch and target to void, then it created 3 instances of ch in some strange way, extract_char seems to be the only thing working correct if you look past the setting of local variables manually
14 Feb, 2007, Davion wrote in the 12th comment:
Votes: 0
Ya know. Most of ROM MUDs tend to have
CHAR_DATA *ch = d->original ? d->original : d->character

I'm pretty sure you could accomplish your goals by simple creating an entirely new character with the combined stats of the two characters, and just point both descriptors at that one character. Using the original/character pointers to your advantage! You could tag a descriptor submissive and then put a check in interpret() to not allow for submissive descriptors to enter commands. Just make sure to unset it when they're no longer combined ;).
14 Feb, 2007, gazzy123 wrote in the 13th comment:
Votes: 0
I've already made it work aswell with both of the players controlling it.
but I'm looking for a more simple way to set the variables in for example pcdata to the merged->pcdata and merged->slave->pcdata
atm I'm using local variables for the merge function such as target_title, target_name etc
16 Feb, 2007, Skol wrote in the 14th comment:
Votes: 0
So, they can merge and split right? But the merged character can't save as a unique one I'm assuming?
What I'd do is have a flag thats like ACT IS_MERGED, then have a structure set up that's MERGED_DATA (basically it would have like merged->name1, merged->name2 (which would then form the 'name' of the beasty) etc.

Or, if you don't want that much, I'd do like you are with linking the descriptor to the new char, simply create a mobile and put the stats of both combined on it, save and unlink the other two, split then reloads the original characters based off the mob (with a check that both are valid etc).

Issue comes in though, items/equipment etc? where does that go? How about damage, if it's hurt and splits, who gets hit, both equally? What room is it in, do both of the creating characters then end up there etc.

The merged data as it's own structure might be the way, just something that popped in mind, as you need two names, two sets of stats etc. Another would be a linked list of each char perhaps, saving/closing them, creating the new etc, but keeping the 2 lists.

One thing though, dynamically named linked lists?
I haven't done that, or even know how/if possible…
17 Feb, 2007, Tyche wrote in the 15th comment:
Votes: 0
gazzy123 said:
Yeah you are correct. ok I'll explain in more detail.

I'm doing a skill that makes 2 chars combine to one, creating a new char and adding their combined stats for hp/mana/move str/dex/con hitroll/damroll.


Mirkwood Mud had a neat feature where all the members of a clan gathered in a room in their clan hall and were merged into a clan avatar which had the skills, hits and mana of all the players combined. The clan leader controlled the movement, but all the players could type commands to invoke their combat actions. The super avatar was then transferred into an arena where one could do battle with another clan's avatar. It was very cool and a lot of fun. :-)
17 Feb, 2007, gazzy123 wrote in the 16th comment:
Votes: 0
Yeah, that was a neat idea.
0.0/16