Author Topic: object vs object#33272  (Read 2975 times)

Offline someshta

  • Acquaintance
  • *
  • Posts: 2
    • View Profile
object vs object#33272
« on: March 04, 2010, 03:09:15 pm »
Using ds3.0

I'm using an invisible object (mojo) to add an affect to the player as long as a particular object is worn.  The worn object, upon removal, calls a function in the invisible object which restores the player's data and destroys the invisible object.  It works great, except for when the player quits and logs in again.  I have it to where the invisible object remembers all of its data from the previous session, but the worn object fails to call the invisible object to run the removal function.  It uses:


What I've found is:

Before the quit, the invisible object is identified as: 

OBJ( mojo <path>/mojo)

After the quit and login, the invisible object is identified as:

OBJ(mojo <path>/mojo#33272) (for example)

If I, as the target of the enchantment, after the quit and login, type: 

call mojo->release()

It works perfectly!  The worn object, however, behaves as if it can't find the invisible object, which means the player is not enchanted, which means there's nothing to release, so it doesn't run release(), as designed.  I can find it, why can't my worn object?

Offline someshta

  • Acquaintance
  • *
  • Posts: 2
    • View Profile
Re: object vs object#33272
« Reply #1 on: March 04, 2010, 04:05:14 pm »

It works great, except for when the player quits and logs in again while wearing the worn object.

Offline chaos

  • BFF
  • ***
  • Posts: 291
  • Job, school, social life, sleep. Pick 2.5.
    • View Profile
    • Lost Souls
Re: object vs object#33272
« Reply #2 on: March 04, 2010, 05:24:39 pm »
1) Some of the problem, it sounds like, is that the player inventory persistence system does not understand the way you're using a blueprint object (/path/mojo) instead of a clone (/path/mojo#33272).  But you probably shouldn't do that anyway.  You should clone your mojo object instead of using the blueprint.
2) As far as I can tell, you're keeping an object variable in the worn object that points to the mojo object, and basically expecting that to hang around through save/restore.  This is a lot to expect from a serialization system, and I'm not surprised that it's not working.  You might want to simply make sure the mojo object is torn down and the affect removed before the player quits, and put it back again when they log in.  Or you could make a way for the worn object to find its mojo object if its pointer to it has gone away (maybe by a serial ID that's stored in both).

Offline cratylus

  • Your favorite and best
  • Administrator
  • ***
  • Posts: 1022
  • Cratylus@Dead Souls <ds> np
    • View Profile
    • About Cratylus
Re: object vs object#33272
« Reply #3 on: March 04, 2010, 06:03:04 pm »
Right. What's happening is that when the player quits and logs back in,
the invis object and the worn object are restored but they have different
instance numbers (the thing after the #) and the object references in
the code aren't restored.

So, here's what your worn item should do. Assume that ob is the
variable with the pointer to the invis object. Some pseudocode:

Code: [Select]
if(!ob && env = environment(this_object())) ob = present_file("/secret/path/to/mojo.c", env);
This says:

1) If the variable pointing to mojo is empty, AND

2) If worn object has an environment, THEN

3) let ob be a pointer to the first object in the environment's inventory that is cloned from the blueprint file of mojo

I'd put that somewhere in any function that tries to talk to mojo, before talking to mojo.


Offline Raudhrskal

  • BFF
  • ***
  • Posts: 214
  • The MUD community needs YOUR help!
    • View Profile
Re: object vs object#33272
« Reply #4 on: March 05, 2010, 02:34:07 am »
Actually, I'd put a clone of the mojo IN the inventory of the worn object, so it gets saved and restored properly and automatically... but it might be just me.
*disappears again*
I think, therefore i may be wrong.
Please note that if you met a Raudhrskal in a place that's not related to muds, it wasn't me. *sigh*... back when I started there was zero hits on google for that name...