compile_object and clones

[William Edsall]

Hello,

 I'd like to customize my virtual objects by making a function call to the object being created during the compile_object routine. This seems to work fine for blueprints like rooms but if I clone an object from compile_object, that object is not the clone I was expecting. 

 Am I doing something wrong or is this expected? Here is an example of how I'm setting it up:

master compile_object -> vmaster compile_object

from vmaster:

compile_object(string filename)

{

    object retval;

    retval = clone_object("/path/to/some/armor.c");

    retval->set_wc(10);

    return retval;

} 

while this clone may be armor#74 what I'm getting back is armor#75. and wc is not being set.

[Gnomi]

Hi William,

William Edsall wrote:
> I'd like to customize my virtual objects by making a function call to the
> object being created during the compile_object routine. This seems to work
> fine for blueprints like rooms but if I clone an object from
> compile_object, that object is not the clone I was expecting.
>
> Am I doing something wrong or is this expected? Here is an example of how
> I'm setting it up:

> [...]

>
> while this clone may be armor#74 what I'm getting back is armor#75. and wc
> is not being set.

Did you consider recursive calls? That while you are setting up armour#74,
compile_object() is somehow called again and sets up armour#75 in the
meantime?

If you're not sure, I would suggest to log the backtrace
(driver_info(DI_TRACE_CURRENT_AS_STRING)) for armour#74 and armour#75.
The driver does not clone another object itself, so I think there must
be another call.

Regards,
Gnomi.

[William Edsall]

Hi Gnomi,

After some testing I'm certain there is no recursive calls happening. I do think that either there is a bug, or I'm misunderstanding the use case of compile_object.

When using efun::load_object and compile_object is called, everything seems to work as expected. When using efun::clone_object, if I provide a cloned object as the return for compile_object, the driver does seem to then clone my cloned object. What I was expecting is the driver to simply use the cloned object that I returned from compile_object.

Here is the driver_info output as suggested. I am only reporting the driver_info if the object is a clone. As you can see it clones twice - the first is my clone within compile_object, then I'm assuming the second is from the driver then cloning my cloned object.

     558 '    bin_command' in '        obj/player.c' ('       obj/player#95')

line 927

    5562 '    bin_command' in '         bin/bin_d.c' ('           bin/bin_d')

line 82

    5927 '         _clone' in '    bin/wiz/_clone.c' ('      bin/wiz/_clone')

line 43

    7929 '          CATCH' in                        ('      bin/wiz/_clone')

    8082 ' compile_object' in '     secure/master.c' ('       secure/master')

line 1161

    8252 ' compile_object' in 'players/test/virtual/arm.c'

('players/test/virtual/arm') line 5

    8258 <lambda 0x55d1a26e5e92> in 'domains/areas/testarea/gear/test.c'

('domains/areas/testarea/gear/test#4287') offset 8

    8301 '    _create_fun' in '     secure/master.c' ('       secure/master')

line 564

    8305 <lambda 0x55d1a2902112> in 'players/test/virtual/arm.c'

('players/test/virtual/arm') offset 6

   14813 '          reset' in 'domains/areas/testarea/gear/test.c'

('domains/areas/testarea/gear/test#4287') line 26 

     558 '    bin_command' in '        obj/player.c' ('       obj/player#95')

line 927

    5562 '    bin_command' in '         bin/bin_d.c' ('           bin/bin_d')

line 82

    5927 '         _clone' in '    bin/wiz/_clone.c' ('      bin/wiz/_clone')

line 43

   18770 '          CATCH' in                        ('      bin/wiz/_clone')

   18776 <lambda 0x55d1a26e5e92> in 'domains/areas/testarea/gear/test.c'

('players/test/virtual/arm:testie2#4288') offset 8

   18819 '    _create_fun' in '     secure/master.c' ('       secure/master')

line 564

   18823 <lambda 0x55d1a2902112> in '    bin/wiz/_clone.c' ('

bin/wiz/_clone') offset 6

   25331 '          reset' in 'domains/areas/testarea/gear/test.c'

('players/test/virtual/arm:testie2#4288') line 26 

[Zesstra]

On 15.08.20 19:10, William Edsall wrote:
> When using efun::load_object and compile_object is called, everything seems to
> work as expected. When using efun::clone_object, if I provide a cloned object
> as the return for compile_object, the driver does seem to then clone my cloned
> object. What I was expecting is the driver to simply use the cloned object
> that I returned from compile_object.

If you clone an object, the driver will first load the blueprint. Using this
blueprint, a clone is created. Thus, you will have to calls: one creates of
clone, which the driver renames to the blueprint, then a second clone ist
created which is also renamed by the driver and returned.
Therefore, for cloning an object if the blueprint is not existing yet, the
driver always creates two objects.

Bye,
Zesstra
--
MorgenGrauen -
1 Welt, mehr als 200 Programmierer , mehr als 16000 Raeume,
viel mehr als 7000 unterschiedliche Figuren, 90 Quests, 13 Gilden,
ueber 5000 Waffen und Ruestungen, keine Umlaute und ein Haufen Verrueckter.
Existenz: mehr als 25 Jahre
http://mg.mud.de/