First attempt

** failed attempt **

Commit 1a6d7a2 attempts to satisfy @spawn/edit as synonym of @spawn/olc and @olc.

That throws exception during @spawn/edit BALL: prototype = spawner.search_prototype(key=key, return_meta=True) function doesn't not exist.
(Other tests behave differently too)

======================================================================
ERROR: test_spawn (evennia.commands.default.tests.TestBuilding)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/henddher/Documents/github/evennia/evennia/commands/default/tests.py", line 473, in test_spawn
    '')
  File "/Users/henddher/Documents/github/evennia/evennia/commands/default/tests.py", line 99, in call
    ret.next()
  File "/Users/henddher/Documents/github/evennia/evennia/commands/default/building.py", line 2916, in func
    prototype = spawner.search_prototype(key=key, return_meta=True)
AttributeError: 'module' object has no attribute 'search_prototype'

Commit 387a244 massages the tests so they pass again. Basically, I assert that AttributeError is thrown from @spawn/edit BALL and @spawn/edit NO_EXISTS.

diff --git a/evennia/commands/default/tests.py b/evennia/commands/default/tests.py
index be47a06a..0007a84e 100644
--- a/evennia/commands/default/tests.py
+++ b/evennia/commands/default/tests.py
@@ -461,21 +461,21 @@ class TestBuilding(CommandTest):
         self.call(building.CmdSpawn(), "/list", "Key ")
 
         # @span/edit (missing prototype)
-        self.call(
+        msg = self.call(
             building.CmdSpawn(),
-            '/edit',
-            '@spawn: Extra switch "/edit" ignored.|Usage: @spawn <prototype-key> or {key: value, ...}\n (2 existing prototypes. Use /list to inspect)')
-        # assert 'Prototype wizard' in msg
+            '/edit')
+            # '@spawn: Extra switch "/edit" ignored.|Usage: @spawn <prototype-key> or {key: value, ...}\n (2 existing prototypes. Use /list to inspect)')
+        assert 'Prototype wizard' in msg
 
         # @spawn/edit with valid prototype
-        # with self.assertRaises(AttributeError):
+        with self.assertRaises(AttributeError):
             self.call(
                 building.CmdSpawn(),
                 '/edit BALL',
                 '@spawn: Extra switch "/edit" ignored.|Spawned Ball(#13).')
 
         # @spawn/edit with invalid prototype
-        #`with self.assertRaises(AttributeError):
+        with self.assertRaises(AttributeError):
             self.call(
                 building.CmdSpawn(),
                 '/edit NO_EXISTS',
@@ -491,7 +491,8 @@ class TestBuilding(CommandTest):
         self.call(
             building.CmdSpawn(),
             '/examine BALL',
-            '@spawn: Extra switch "/examine" ignored.|Spawned Ball(#14).')
+            # '@spawn: Extra switch "/examine" ignored.|Spawned Ball(#14).')
+            '@spawn: Extra switch "/examine" ignored.|Spawned Ball(#13).')
 
         # @spawn/examine with invalid prototype
         self.call(

I would guess that @spawn/edit doesn't really equate to @spawn/olc (and @olc) ... ignoring what it looks like path of execution that wasn't updated in 0.8.0? (perhaps it's now dead code that I am executing because of the synonym command). No?

I think this issue boils down to requirements ... don't you think, @Griatch?

What should the expected behavior be for the /edit and /examine switches when no prototype, invalid prototype or a valid prototype is provided?

• @spawn/edit

• @spawn/edit VALID_PROTOTYPE

• @spawn/edit INVALID_PROTOTYPE

• @spawn/examine

• @spawn/examine VALID_PROTOTYPE

• @spawn/examine INVALID_PROTOTYPE

It's incorrect to adjust the unit tests to assume exception raises, those are clearly bugs that need to be resolved and are due to changes in directory structure between 0.7 and 0.8.

spawn/edit is the same as @olc and should open the OLC.

@spawn/edit VALID_PROTOTYPE should enter the OLC with that prototype loaded. A malformed prototype should give an error.

@spawn/examine VALID_PROTOTYPE should show a visualization of the prototype; I don't recall if the @spawn command itself has that visualization mechanism - otherwise evennia/prototypes/prototypes.py or spawn.py certainly does. If the prototype is invalid, an error should be returned.

At no point should an exception be rasied.

Thank you @Griatch!

Now that the expected behavior is clear, I'll try to fix these 2 switches as you depicted.

It's incorrect to adjust the unit tests to assume exception raises, those are clearly bugs that need to be resolved and are due to changes in directory structure between 0.7 and 0.8.

Right, that was clear to me - sorry I wasn't explicit abut my approach.

The point of me using assertRaise(...) was to falsely pass those failures and allow all subsequent tests to execute until completion. Otherwise, the first test would fail and reveal none of the other problems in the following permutations. Sorry I didn't explain my approach up front.

At any rate, now that the requirements are clear, it should be straight forward to adapt the tests to the requirements and then 🤞 fix the bugs in @spawn until these tests pass.

@Griatch, I need a bit of help :(

When testing @spawn/edit testball, the prototype is found successfully. However, when the OLCMenu is fired with old_prototype, the menu seems to load correctly but it gives no indication of testball being edited.

Here is the ipdb session showing some of the steps and what some local variables contain. I stepped through until OLCMenu is about to be invoked.

ipdb> n
> /Users/henddher/Documents/github/evennia/evennia/commands/default/building.py(2917)func()
   2916                 prototype = protlib.search_prototype(key=key)
-> 2917                 if len(prototype) > 1:
   2918                     caller.msg("More than one match for {}:\n{}".format(

ipdb> p prototype
[{'prototype_locks': 'spawn:all();edit:perm(Admin)', 'prototype_key': 'testball', 'prototype_tags': [], 'key': 'Ball', 'typeclass': 'evennia.objects.objects.DefaultCharacter', 'prototype_desc': ''}]
ipdb> n
> /Users/henddher/Documents/github/evennia/evennia/commands/default/building.py(2921)func()
   2920                     return
-> 2921                 elif prototype:
   2922                     # one match

ipdb> n
> /Users/henddher/Documents/github/evennia/evennia/commands/default/building.py(2923)func()
   2922                     # one match
-> 2923                     prototype = prototype[0]
   2924                 else:

ipdb> n
> /Users/henddher/Documents/github/evennia/evennia/commands/default/building.py(2928)func()
   2927                     return
-> 2928             olc_menus.start_olc(caller, session=self.session, prototype=prototype)
   2929             return

...
> /Users/henddher/Documents/github/evennia/evennia/prototypes/menus.py(2461)start_olc()
   2460                 }
-> 2461     OLCMenu(caller, menudata, startnode='node_index', session=session,
   2462             olc_prototype=prototype, debug=True)

ipdb> p prototype
{'prototype_locks': 'spawn:all();edit:perm(Admin)', 'prototype_key': 'testball', 'prototype_tags': [], 'key': 'Ball', 'typeclass': 'evennia.objects.objects.DefaultCharacter', 'prototype_desc': ''}

Stepping over OLCMenu(...) returns None. Immediately after, the command enters muxcommand .at_post_cmd().

ipdb> n
--Return--
None
> /Users/henddher/Documents/github/evennia/evennia/prototypes/menus.py(2462)start_olc()
   2460                 }
   2461     OLCMenu(caller, menudata, startnode='node_index', session=session,
-> 2462             olc_prototype=prototype, debug=True)

ipdb> n
--Call--
> /Users/henddher/Documents/github/evennia/evennia/commands/default/muxcommand.py(41)at_post_cmd()
     40 
---> 41     def at_post_cmd(self):
     42         """

After that, back in the test case, self.call() is producing the following output:

It resembles the olc menu but it's preceded by Room(#1) and description but it doesn't seem to give any indication of the testball prototype being edited.

Does that output look correct?

"Room(#1)\nroom_desc\nExits: out(#3)\nYou see: a Char2(#7), an Obj(#4) and an 
Obj2(#5)\n______________________________________________________________________________\n\n 
--- Prototype wizard --- \n\nA prototype is a 'template' for spawning an in-game entity. 
A field of the prototype\ncan either be hard-coded, left empty or scripted using $protfuncs
 - for example to\nrandomize the value every time a new entity is spawned. The fields whose
 names start with\n'Prototype-' are not fields on the object itself but are used for prototype-
inheritance, or\nwhen saving and loading.\n\nSelect prototype field to edit. If you are unsure, 
start from [1]. Enter [h]elp at\nany menu node for more 
info.\n______________________________________________________________________________\n\n
Validate prototype  | SAve prototype | SPawn prototype | LOad prototype | SEarch 
objects | Quit\n\n 1: Prototype-Key     6: Attrs         11: Home             \n 2: Prototype-Parent
   7: Tags          12: Destination      \n 3: Typeclass         8: Locks         13: Prototype-Desc
   \n 4: Key                9: Permissions   14: Prototype-Tags   \n 5: Aliases            10: Location
     15: Prototype-Locks"

I'm referring to commit 15c940f

Specifically:
15c940f#diff-f21151d8793220c905e0b764e67a8c2bR492

@Henddher To check, I locally fixed the simple mis-call of search_prototype and ran olc goblin. It loads the goblin prototype just fine (check for example the prototype-key or typeclass menu entries). So check that, maybe you are just not realizing it's working.

The OLC header is admittedly not updated when a new prototype is loaded; it could be updated to show this by all means, as a usability improvement.

.... So check that, maybe you are just not realizing it's working.

I don't know how I could do that from the test-case :(

The OLC header is admittedly not updated when a new prototype is loaded; it could be updated to show this by all means, as a usability improvement.

That's a good idea and if a header was added somewhere near the "Prototype wizard" title, the test case would validate that the prototype is loaded via string checking the title.

I'll see if I can patch OLCMenu and display the prototype key - at least.

Will keep you posted @Griatch! Thanks again!

@Henddher It's pretty hacky to examine the text field of the olc header in the test suite anyway; better would be to analyze what prototype was loaded into the olc. You can do that like this (where caller is the caller used to launch the olc command):

if hasattr(caller.ndb._menutree, "olc_prototype"):
    prototype = caller.ndb._menutree.olc_prototype    

If this prototype exists and has the right prototype_key you are ok.

hacky

Indeed ... but "ok" (I thought) as the majority of tests just validates string messages sent to the command caller (caller.msg(...)) ... I'll go with both approaches 👍

if hasattr(caller.ndb._menutree, "olc_prototype"):
    prototype = caller.ndb._menutree.olc_prototype    

If this prototype exists and has the right prototype_key you are ok.

Nice! will try that first and then modify the OCL title as a UX enhancement that can be asserted in the test

Thanks! @Griatch

if hasattr(caller.ndb._menutree, "olc_prototype"):
    prototype = caller.ndb._menutree.olc_prototype    

If this prototype exists and has the right prototype_key you are ok.

Worked as a charm! 👍 👍

@Griatch, I just realized another error:

@spawn/examine <valid prototype>

The current implementation spawns a new object after warning that the switch /examine has been ignored.

> @spawn: Extra switch "/examine" ignored.|Spawned Ball(#13).

According to your clarification #1699 (comment), I will try to print the prototype instead.

diff --git a/evennia/commands/default/tests.py b/evennia/commands/default/tests.py
index 8dce5ccc..f285cc96 100644
@@ -518,6 +522,8 @@ class TestBuilding(CommandTest):
         self.call(
             building.CmdSpawn(),
             '/examine BALL',
+            # FIXME: should this print the existing prototype
+            # instead of spawning it?
             '@spawn: Extra switch "/examine" ignored.|Spawned Ball(#13).')

I think that's the last the last outstanding issue originally reported by @kaleara

Hi @Griatch

With commit 79a64ce, I think this issue is ready for code review and hopefully merged. 🤞

Please note that I added one extra line to the OLC header as UX enhancement (9d800aa):
It displays something like this (colorized of course):

 |c --- Prototype wizard --- |n
 --- Editing: |y Ball(testball) |n --- 

Don't know if there is a Wiki that should be updated as well?

Looks good - thanks for the help! I don't think there is any wiki doc to update for this.

Looks good - thanks for the help! I don't think there is any wiki doc to update for this.

Evennia is lots of fun so it’s a pleasure to help out

Closes #1684