Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Non-Room objects being counted as Rooms by `@objects` and web context #1845

Closed
strikaco opened this issue May 17, 2019 · 10 comments

Comments

Projects
2 participants
@strikaco
Copy link
Contributor

commented May 17, 2019

Brief summary of issue / Description of requested feature:

Might be related to #251.

Objects that are not actual Rooms are being counted as such by the @objects command as well as the Django web context.

nrooms = ObjectDB.objects.filter(db_location__isnull=True).exclude(
db_typeclass_path=base_char_typeclass).count()

nrooms = ObjectDB.objects.filter(
db_location__isnull=True).exclude(db_typeclass_path=_BASE_CHAR_TYPECLASS).count()

This leads to very skewed object counts; intangible typeclassed "objects" such as economic/transaction handlers or temporary jobs/tasks are counted as Rooms.

Extra information, such as Evennia revision/repo/branch, operating system and ideas for how to solve / implement:

It looks like this happens because the aggregations assume Room objects are anything without a location on the grid. But in the case of intangibles, such objects do not require or use an on-grid location, yet they are classified as Rooms.

It might make more sense to count the number of Rooms as the number of all objects descended from DefaultRoom, or simply count the destinations of all Exit objects?

@Griatch

This comment has been minimized.

Copy link
Member

commented May 17, 2019

Intangibles should never be Objects. If they need a database existence they should be Scripts (which are like OOC Objects). The main argument against this are objects moved to a None location though.

But yeah, this logic is age-old, from a time before typeclasses, even. As you say, it assumes a 'room' is anything without a location. Using the DefaultRoom base would be more generally relevant today.

@Griatch Griatch added this to To do in Evennia 0.9 via automation May 20, 2019

@Griatch Griatch moved this from To do to In progress in Evennia 0.9 Jun 3, 2019

@Griatch Griatch added the implemented label Jun 3, 2019

@Griatch

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

Fixed in develop branch

@Griatch Griatch moved this from In progress to Done in Evennia 0.9 Jun 3, 2019

@strikaco

This comment has been minimized.

Copy link
Contributor Author

commented Jun 11, 2019

Thanks for the fix on this.

The verbiage is now correct on the website, but the ingame @objects command raises a traceback for me due to an invalid date comparison. Not sure if related. Does it work for you?

  File "/home/ubuntu/workspace/evennia/evennia/
    commands/default/system.py", line 472, in func
    latesttable.add_row(utils.datetime_format(obj.date_     created),                                             File "/home/ubuntu/workspace/evennia/evennia/utils/       utils.py", line 576, in datetime_format
    if dtobj.year < now.year:
AttributeError: 'str' object has no attribute 'year'
@Griatch

This comment has been minimized.

Copy link
Member

commented Jun 12, 2019

@strikaco Your traceback looks a bit cropped (it appears to be missing some part of the stack in the middle), but @objects works for me. Maybe you could dig down to see if one object has gotten a weird datetime for some reason, maybe?

@strikaco

This comment has been minimized.

Copy link
Contributor Author

commented Jun 17, 2019

Odd, sorry. Here's a complete traceback:

Traceback (most recent call last):
  File "/home/ubuntu/workspace/evennia/evennia/commands/cmdhandler.py", line 591, in _run_command
    ret = cmd.func()
  File "/home/ubuntu/workspace/evennia/evennia/commands/default/system.py", line 472, in func
    latesttable.add_row(utils.datetime_format(obj.date_created),
  File "/home/ubuntu/workspace/evennia/evennia/utils/utils.py", line 576, in datetime_format
    if dtobj.year < now.year:
AttributeError: 'str' object has no attribute 'year'
@Griatch

This comment has been minimized.

Copy link
Member

commented Jun 18, 2019

@strikaco Still can't reproduce that, sorry.

@strikaco

This comment has been minimized.

Copy link
Contributor Author

commented Jun 18, 2019

@strikaco Still can't reproduce that, sorry.
Maybe you could dig down to see if one object has gotten a weird datetime for some reason, maybe?

19-06-18 17:43:32 [EE] Bad timestamp: 2019-06-19 18:40:23+00:00
19-06-18 17:43:32 [EE] Bad timestamp: 2019-06-19 12:27:38

There are quite a few of these; they were introduced by a database migration on my part.

Evennia accepted them as valid values despite being unable to parse/deserialize them. But that is really a separate issue; once I reset those times I could not reproduce the problem anymore either so #1845 is complete.

@Griatch Griatch closed this in cdd9ca2 Jun 29, 2019

@strikaco

This comment has been minimized.

Copy link
Contributor Author

commented Jul 2, 2019

If they need a database existence they should be Scripts (which are like OOC Objects).

@Griatch I see your logic and am trying to refactor some of my code to follow it, but isn't using Script objects in this manner very risky? There are multiple non-obvious ways to accidentally trigger a lock-bypassing self-deletion of a Script object. Calling the base stop() function will do it, as will start() if stop() hasn't been explicitly overwritten, or if is_valid() returns False for any reason. There may be others I'm unaware of.

Objects aren't this volatile. Is there a better/meta class to inherit from that doesn't implement the full Script interface while also being off-grid? (Or should there be? Using plain Objects has been working for me without these concerns. The in-game manifestation of an economic engine could just as well be one or more "Server" or "Accountant" objects in a locked room somewhere, just like in real life...)

@Griatch

This comment has been minimized.

Copy link
Member

commented Jul 3, 2019

@strikaco: If you create a script without a timer component (for use as an "OOCObject" type), why would you ever start to mess with its stop() method?

I have used Scripts extensively and never encountered a situation where they were "volatile" to the extent you describe. That said, the original purpose of Scripts were for time-keeping and over time their role has expanded since they are now typeclasses and there are other and probably better timer mechanism available (like the TickerHandler). So it makes sense to have their timer components more decoupled from their existence than today. There is a feature request (#1715) to change how Scripts work in order to make its stops and deletions fully explicit and decoupled.

@strikaco

This comment has been minimized.

Copy link
Contributor Author

commented Jul 4, 2019

Some of my objects in question coincidentally implement a "playable" interface via start() and stop() mixin methods. If I don't pay close attention to where those methods are getting inherited from and how super() gets called when inheriting from Script, I am concerned about what the default failure mode might become.

Good to know about the future plans for decoupling timing from Scripts. Generic Scripts without the timer/self-deletion mechanics would be very useful!

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.