MU Soapbox

    • Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Muxify
    • Mustard
    1. Home
    2. Griatch
    3. Posts
    • Profile
    • Following 0
    • Followers 1
    • Topics 23
    • Posts 375
    • Best 172
    • Controversial 0
    • Groups 2

    Posts made by Griatch

    • RE: Brilliant Breakthroughs and Impossible Projects

      @faraday said in Brilliant Breakthroughs and Impossible Projects:

      @Griatch said in Brilliant Breakthroughs and Impossible Projects:

      Splitting that into optional easy-to use components make's it easy to do any extra fluff on a case by case basis.

      Yeah definitely different layers of abstraction. The Ares engine does similar parsing to what you're talking about. crack is for figuring out args. So you just leave that up to individual commands to figure out, splitting the string as needed? Nothing wrong with that, btw, I just codified that as a separate step.

      In principle every individual command class could exactly control it's own parsing, yes. In reality commands end up being parsed so similarly they all inherit one or two parsers with only very few requiring individual extra parsing on top of that.
      .
      Griatch

      posted in MU Code
      Griatch
      Griatch
    • RE: Brilliant Breakthroughs and Impossible Projects

      @faraday

      naybe you are right and we work at different abstraction levels, yes. All Evennia hands over to the command is

      cmdnameargs
      

      Where cmdname is the key or alias of the command used and args is everything after it, with no added space.

      At least from what I learned about the base "MUX-like" command set we use in Evennia, some 80% of commands can efficiently be parsed hereon by understanding

      cmdname[/switch[/switch]...] [arg[;alias]...] [= arg[;alias...],...]
      

      Splitting that into optional easy-to use components make's it easy to do any extra fluff on a case by case basis. As said we have one more base class (inheriting from this one) that also handles commands with syntax for assigning variables etc; but that's basically all we need, and all other default commands in Evennia inherits from this.
      .
      Griatch

      posted in MU Code
      Griatch
      Griatch
    • RE: Brilliant Breakthroughs and Impossible Projects

      @faraday

      So if I understand you correctly, when the correct command key (or alias?) has been identified, it jumps to the given handler class and then fires in turn the cracks, checks and handle methods?

      This sounds pretty reasonable to me, (although 'cracks' is a strange name to me - some sort of mush/ruby-ism?).
      You should not be doing this for ease-of-use only though I think; it will then only increase complexity just as you fear. The main motivation should be to encourage handler inheritance: allowing devs to implement parsing for a whole group of commands at once.

      In Evennia we do a similar thing; when a Command has been identified; we in turn call the Command's at_pre_cmd, parse, func and at_post_cmd -methods in turn. Of these, only parse and func are implemented with any regularity (the pre/post methods are needed by those wanting to plug in custom stuff without changing default command functionality).
      The parse method was implemented once for almost all our "mux-like" commands and a second time for certain more advanced admin commands. Most devs never touch it but gets the parsing for free, implementing only func for every new Command, that is the actual actions performed on the already parsed input.

      So as long as you emphasize that command handlers are classes that can be inherited, you can get rid of a lot of boiler plate for your users with parsing only needing to be coded once for big swathes of commands.
      .
      Griatch

      posted in MU Code
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @Thenomain said in What is out there? Hard and soft codebases of choice.:

      Christmas Eve, not much time, still requesting: Evennia have its own help files for people who do not know how to or understand how to pour through code, let alone understand what directory structures mean what. I still facerub when I have to find which library a function or object or template structure lives in, because it is not fun at all for anyone ever period, even people who've been coding Mush softcode for years/decades and "where is it?" is a painfully frequent question.

      I can't ask that Evennia devs do anything for the common Python code, but for the Evennia structures they can sure as heck do something as simple as a searchable wiki. Have you seen how well-organized the Oracle SQL and PL/SQL docs and even some of the other interface docs are? PyDoc, maybe?

      The wiki is searchable by wiki page-name, by a google-seach (from the "search" link on the right hand side). It can also be read and printed as PDF on readthedocs and finally directly downloaded.
      ... But that said, I agree that the API doc section of our wiki is, while complete, not necessarily aimed at someone just diving in: it lists also systems that a normal user would most likely not be concerned about ever, or at least not until at an advanced level of understanding or when contributing to Evennia itself. So a good idea would be to make a stricter selection as to what is presented there and hide away the details except for those with a particular interest.

      Thinking out loud, there.

      Appreciated and point taken. Merry Christmas!
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @Lithium

      Python knows nothing about mushes, it's just a language. That is what Evennia is for - it supplies the resources relevant for use in a mu environment. If resources are missing we can add them or have them as optional contribs.

      It's quite clear that Python has many, many more help resources than mushcode has as a language, simply because so many more people use Python in the world than mushcode. But there is no denying that by comparison very few use Python for the specific use of creating a Mu - as far as Python goes, Evennia is one of the few runners in that race. Here mushcode has decades of lead; it's after all the only thing mushcode is used for, anywhere (as far as I know?).

      Now, I personally agree with @faraday that someone who mastered something like mushcode should be well in place for learning something like Python or Ruby. The workflow may be the more jarring aspect (as has been discussed at length here). So if you know mushcode already and it fulfills all your needs for the games you want to create, I agree you may very well be best off sticking to it. The toolboxes offered by Evennia (or Ares) and the workflow they work best with is not necessarily the right fit for everyone.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      Sorry for the double-post but I'm on my phone and it's a little hard to track all the text.

      Step 1: Recognize a built-in function from a defined function.

      • In Mushlikes: Is it a u()? No: Is it in 'help'? No: @function/list.
      • In Mainstream Languages: ...?

      I assume the answer to 1b is to hope the people who put the framework together have made it easy to find out.

      In python: help (module.funcname)
      In evennia (nicer if ipython is installed-colors and tab-completion):

      $ evennia shell
      # Python shell starts
      > import evennia
      > evennia.<TAB>
      evennia.Object evennia.Command ... #contents of the most common Evennia components to use
      > evennia.Object?
      # documentation for Object class
      > evennia.Object??
      # source code for Object class
      > evennia.Object.msg?
      # documentation for msg method
      

      And as I think was already agreed upon, if you use a coding IDE you will get this info popping up in a separate pane while you are typing. It will even make code completion suggestions if you like (I don't, I use VIM with few frills but that's just me).

      Also, before I get complaints about it, I know that what I quoted is the definition of 'switch_set', but what about 'msg()'? How does a beginning coder know where to find the help file on this function

      This particular one would, as said, be up to Volund to document. Normally a search through the code base would find the function. All functions, classes and methods-on-classes are heavily documented in Evennia; some 45% of all lines are in fact documentation (according to Ohloh).

      The lack of this document is probably why WTFE's "professionals only" statement came in; sure a pro will know where to find what 'msg()' is, starting with context which is so bloody critical in OOP, but even though Mushers bathe in list-based and OOP-based coding it's going to take some Beginner's Guide education to smooth the transition.

      But, I mean, you know that.

      The Evennia beginning tutorials cover the use of msg() and there are whole wiki sections dedicated to it. But sure, if one is going in blind and are not familiar with OOP concepts nor Evennia's overall layout it may well be tough to get anywhere.
      I can only say that I see plenty of very much "non-pro" hobbyist people not having any issues with finding this info. I'm willing to concede that this may be a selection effect though and that we just don't hear from those that fall off.

      Edit: We have a standing request for people from different codebases to write "Evennia for <mu codease>" type documents. So far my own article here on musoap box may come closest to a mush one; no musher have stepped up to do a more detailed one yet (I don't feel competent enough to write it myself since I'm not a musher)
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @Thenomain said in What is out there? Hard and soft codebases of choice.:

      @faraday and @Thenomain on opposite sides of an issue. It should be a podcast!

      Anyhow, I wholeheartedly agree with my compatriot, but I will say that to learn any "real" programming language involves learning some insanely important concepts. Even if you frankencode (definition: taking bits of code from other sources and mashing them together hoping they will work), you have to understand what goes where, a few brief OOP concepts, how stuff gets called, and how to find the help files so you can translate def switch_set(self, target, files, rhs, isadmin): into English. I mean, sure, you have to do the same with iter(), but 'help iter' and boom, done.

      Does Evennia have a 'help switch_set'? If not, it desperately needs one!

      It does not, because that code is Volund's custom example created for his own needs. In all of Evennia's core code you will find the full documentation of the function directly under the function- or class definition.


      Incidentally, the code comes from https://github.com/evennia/evennia/wiki/Soft-Code, which I have some ethical problems with, mainly how it compares some pretty horribly written softcode in a horribly unformatted manner to elegant and also formatted code. (Yes, I know it's @Volund's code, and I know he is a damn good psychocoder.)

      The main thing would be that both codes are written by the same guy, the mushcode one after years of experience, the second one after only a short while of learning Python/Evennia. And the Python one is not "formatted" in some unethically incomparable way: Python must look this readable to be valid Python. You could in principle make Python code look as compact and (to me) unintelligible as the mushcode above, but you'd have to work very hard at it and know a lot more Python than Volund did at the time.

      Out of curiosity; the nicer-formatted form of mushcode you show, can you edit it like this in-game or do you need an external editor that you copy & paste from?
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @faraday said in What is out there? Hard and soft codebases of choice.:

      @Griatch said in What is out there? Hard and soft codebases of choice.:

      The default Evennia commands are inspired by MUX and that's where the @ comes from. Consistently, all commands related to building or administration use @ while in-game commands like look, get, inventory etc. do not. It would be simple to have the default commands accept both @ and -not though; just have an alias for the non-@ version. Does Ares list the commands with @ (but accept without too) or are they listed without @ (but accepts one anyway) ?

      Ares lists all commands with no prefix at all in help files and whatnot. Unless you explicitly make a command look for a prefix (@, &, /, +), Ares just ignores it completely.

      This is, incidentally, why the default Ares config renamed the public chat channel to "Chat" instead of "Public", to avoid the obvious mav-prone confusion of p for page and +p for public ๐Ÿ™‚

      Edit to add: Codewise Ares breaks the command up into (prefix)root(page#)(/switch) (args). So all the built-in commands only look at cmd.root but you could make one look at cmd.prefix if you really wanted.

      How do you handle single-letter shortcuts, like ":" for emoting?
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @Roz said in What is out there? Hard and soft codebases of choice.:

      As someone who has now used Evennia a good deal as a player on Arx and Ares a little bit as a brief player on Faraday's game, I'd LOVE if Evennia had the same thing as Ares where all the commands don't have prefixes. Like, even the basic globals set up in Evennia now have some with @ by default and some without. Just knock everything off. Why not at least standardize so they all start the same?

      The default Evennia commands are inspired by MUX and that's where the @ comes from. Consistently, all commands related to building or administration use @ while in-game commands like look, get, inventory etc. do not. It would be simple to have the default commands accept both @ and -not though; just have an alias for the non-@ version. Does Ares list the commands with @ (but accept without too) or are they listed without @ (but accepts one anyway) ?

      There are some touches in Ares like that that really seem to be specifically about "Making things easier/simpler/more streamlined for the user."

      (Also, letting players set a color for quoted text like Ares officially does now would be the bEST.)

      The default Evennia commands are pretty low on coloration, admittedly. They are intentionally bland since they are intended to be customized per-game. So technically you should direct this request to @Tehom if you want it in Arx. ๐Ÿ™‚ But that said - since all is in place for allowing players to customize things like that, maybe it would be an idea to support it out of the box in vanilla Evennia too.
      ยท
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @faraday said in What is out there? Hard and soft codebases of choice.:

      As for merge conflicts - absolutely those can happen. But I think by making it pluggable you're just trading one kind of headache for another. For starters, it's more complexity for the designer to worry about. Also, if someone makes a custom version of the Bob command and you make an upstream change to the core Bob command, then they've got a philosophical merge conflict whether they've modified BobCmd or overridden it with MyBobCmd. Editing in place allows you to use the built-in git merge tools to resolve trivial conflicts automatically, and gives you help in resolving more complex ones.

      Sure, I can see both points of that argument. I can certainly see a nice hacking potential your way (in a good way). The thing with the "philosophical" merge conflict is however that if there are things that don't work you can always revert to "vanilla" Evennia to figure out if the problem you are having is in your code or not. Likewise, since we offer (defacto) user help and support, it helps a lot to be able to say "I'm using the same Evennia version you are and I can't reproduce your problem" - and be sure of the boundaries between upstream and custom code.

      Also we've got different user bases. A lot of my target audience won't be modifying the commands at all (since they're using Ares because they lack a coder) or just won't bother upgrading. So it's quite possible that your strategy works best for Evennia. It's a question of tradeoffs.

      Certainly. Ares (from what I gather) uses a command syntax that your user base already knows and expects and may not be likely to change as you say. If you don't expect heavy customization of your command structure or syntax there is little need to cater for it.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @faraday

      Going full-on global commands is an interesting take. The example looks very clean! The concept of looping over all commands to find one that matches is simple to explain and use; do you do any pre-parsing to weed the loop or is it simply so fast it doesn't matter (I presume the number of commands is not big enough to be a problem). Does the system complain if there are multiple same-named commands (in different plugins, say) or will it take the first one every time?

      Having people edit the core in-place makes me a little twitchy though I admit. Many years ago Evennia had things set up so it was natural for people to edit things in-place (the game folder was a part of our repo instead of being created on-demand). We found that we couldn't make changes to upstream without users seeing merge clashes all over and reporting errors we could not reproduce - since their version of core was slightly different from ours. These days we make things pluggable and tell people not to mess with core until they are making an Evennia PR. A lot less headaches for everyone involved.

      @Thenomain said in What is out there? Hard and soft codebases of choice.:

      @Griatch

      So passive conditions can't trigger command assignment? Leading to a third answer: The coder creates a system that loads all the possible "bob" commands, via a walk thru of the directory looking for 'bob-Werewolf.py', etc., maintaining add-on flexibility. Even that leaves my mouth dry, but I can envision too many scenarios where waiting even one minute for a command to become available is a downfall.

      The way to do this is to catch when the passive condition changes. Evennia has something called a MonitorHandler one could use for this, but here's a pure-Python solution, assuming the property in question is .wolf_form.

      from evennia import Character
      from commands.wolf import WolfCmdSet
      class Wolf(Character):
          # [...]     
         # create a property .wolf_form that updates the cmdset when assigned
          def _get_wolf_form(self):
              return self.cmdset.has(WolfCmdSet)
          def _set_wolf_form(self, do_swap):
              is_wolf = self.cmdset.has(WolfCmdSet):
              if do_swap:
                  if not is_wolf:
                      self.cmdset.add(WolfCmdSet)                   
              elif is_wolf:
                  self.cmdset.remove(WolfCmdSet)           
          wolf_form = property(self._get_wolf_form, self._set_wolf_form)
      

      You will now be able to do character.wolf_form = True/False and have the cmdset state swap on-demand for you. You will also be able to do stuff like if character.wolf_form: ... to check if they are currently in wolf form (that is, have the WolfCmdSet on them).

      Edit: But if with "passive condition" you mean something like "at the moment of entering bob, if this condition is True then get back this version of the command, otherwise this other version", then you need to do a little more work:

      You could solve this by adding all your conditional commands to the cmdset and tell them not to merge but to remain separate (but same-named) in the set. You then plug in your own MULTIMATCH_ERROR handler. When you use "bob" you will then get multiple possible command-matches. The normal result on a multimatch is to give you a list of commands and let you pick the one you want to use (it may matter if you are using the "push" command on the red or blue button after all). But your multimatch handler could instead check the condition and run only the command the condition dictates.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      Ah, ok. So I'll give two possible ways to do this; first the in-command "head-on" way and then using cmdsets.

      Head on way - command with ifs

      This means simply that we create the command Bob and have it check if we are in the given time slot or not. Since presumably the Wolf race has unique features (code-wise) we assume it's created as a separate Python class (let's say its path is typeclasses.wolves.Wolf). If Wolves were, say, just members of some biker gang (so human like other humans, code-wise) we could have instead just used a Tag to tag them as "Wolf" to identify them.

      # in a module, say, "commands.bob.py"
      from evennia import Command
      from evennia.utils import gametime
      
      def check_full_moon():
          # let's assume every 30 days in game-time is a full moon
          # I can't be bothered doing the logics for limiting it to 0-3AM but
          # it would happen here.
          return (gametime.gametime() * 3600 * 24) % 30 == 0
      
      class CmdBob(Command):
          key = "bob"
          def func(self):
              if self.caller.is_typeclass("typeclasses.characters.Wolf") and self.caller.check_full_moon():
                  # do Wolf stuff 
              else:
                  # do non-Wolf stuff
      

      Next just add Bob to the Character Command set, which all characters start out having. Again, most of the code was already filled out by Evennia from the start, so one plugs in the command where indicated.

      from commands import bob
      class CharacterCmdSet(CmdSet):
          # [...]
          def at_cmdset_creation(self):
              # [...]
              self.add(bob.CmdBob())
      

      After a @reload the "bob" command is available and will behave differently for wolves. Now this is straight-forward and may well be enough for your needs. It has some maintenance problems though. Say you have other classes like Druid, Fae and Moon dragon that all have special things happen during a full moon. You now have to expand CmdBob to account for all those. What if it's not just bob, but a whole slew of commands that should change like this? You would need to update them all. So far it's certainly doable. But then what happens if Wolves lose their special Bob when someone casts a spell or hits them with silver? You would then have to expand on your if statements. To be clear - this may well be ok for your game. But it may also be easy to forget to update a particular condition and the code could become hard to read and maintain.

      CmdSet way

      This will instead implement two versions of the Bob command, the normal one and the Wolf one.

      # in a module, say, "commands.bob.py"
      from evennia import Command, CmdSet
      class CmdBob(Command):
          key = "bob"
         def func(self):
             # do normal bob stuff
              
      class CmdBobWolf(Command):
           key = "bob"
           def func(self):
               # do wolf-bob stuff
      
       class CmdSetWolf(CmdSet):
           def at_cmdset_creation(self):
               self.add(CmdBobWolf())
      

      Note that if CmdBobWolf shared a lot of features with the normal CmdBob we could have inherited from it and just replaced some things. We also create a new cmdset CmdSetWolf only holding this single command (for now). We add the normal CmdBob to the CharacterCmdSet as shown earlier.

      Next we will use a Script to track time. A Script is a sort of virtual object that has no existence in-game. It can store data etc like an in-game object but also has an in-built timer.

      from evennia import Script
      from typeclasses.wolves import Wolf 
      from commands import bob
      class  MoonScript(Script):
          key = "moonscript"
          interval = 60 * 60  # calls self.at_repeat every hour
          persistent = True # will survive a shutdown
          self.db.is_full_moon = False
      
          def at_repeat(self):
               # fires every self.interval seconds
               if check_full_moon():                
                  if not self.db.is_full_moon:
                      self.db.is_full_moon = True
                      # find all wolves and let the wolf-bob cmdset merge onto
                      # the existing one. All this will do is to change how "bob" works.
                      for wolf in Wolf.objects.all():
                          wolf.cmdset.add(bob.CmdSetWolf)
              elif self.db.is_full_moon:
                  # the full moon passed.
                  self.db.is_full_moon = False
                  for wolf in Wolf.objects.all():
                      wolf.cmdset.remove(bob.CmdSetWolf)
      

      So what the Script does is that it will check every hour if there is a full moon, and if so add the CmdSetWolf to all wolves in the game. When the check fails it removes it again, restoring the default "bob" command. In a real game you will probably let your Weather or Calendar script do this job, alongside announcing to the world that the full moon has risen.

      Using cmdsets rather than if statements in one command has the advantage of containment: You could store everything wolf-related in one place, in relative isolation from others. Sure, there may be details that still require some if checks but by replacing the entire command you could plug in the command in new situations without changing of the command code.

      So if a Druid casts a spell on the Wolf, all you now need to do is to call wolf.cmdset.remove(bob.CmdSetWolf) on the wolf to have it loose all its moon-given powers at once. Importantly, if the wolf meanwhile has sipped a magical potion having it gain the AwesomeFlyingCmdSet (giving say the "fly" and "leap" commands), removing the CmdSetWolf will only remove that cmdset. The normal "bob" command will be used but "fly" and "leap" will remain until the Druid uses their next spell ...

      This also exposes a limit with the CommandSet system - you operate on Cmdsets, not on individual Commands (one Command could go into many different cmdsets). So if you have many commands in CmdSetWolf but only wanted to remove one of them, you'd be out of luck. For that level of precision you'd either have to fall back to doing if-checks in the command, use cmdsets with one Command each or overload the cmdset anew with the changed command structure.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @Ashen-Shugar said in What is out there? Hard and soft codebases of choice.:

      @Griatch said in What is out there? Hard and soft codebases of choice.:

      It's normally easy to overload a default command by name. Since we in this case want to replace the default command with the same functionality but with a different name (key) we need to unload the old and then add it again with the new key.
      [snip]

      Hum. While it does seem fairly straight forward, I can say without reservations that unless I had a fairly good grasp of how Evennia worked at the under-hood I would have spent some time digging into how to do this.

      Sure, this is why one of the first beginner tutorials cover how Commands and Command sets work and tie together. And if you just wanted to replace the functionality of the command (not change its main identifier) you wouldn't need to remove the old command but just add the new one - it will then simply replace the old same-named one.

      How much harder would it be to overload a default command by evaluation?

      With "evaluation", do you mean to overload it conditionally? This is one of the purposes of Command sets - you can add and remove them non-destructively to build up the set of commands a user have available at any given moment. To add a new command set (with any number of commands in it), to a character for example:

      character.cmdset.add("commands.command.myCmdSet")
      

      (rather than giving the path you could also add the actual cmdset if you have it imported). This you can put in a condition as you please.

      The commands in that command sets will now dynamically replace same-named commands already available to character. You can control this replacement in detail using different merge strategies and merge-priorities (often not needed though). An example is the tutorial Red Button, which when you press it blinds you (for a short while) by replacing your command set with one whose commands only echo back that you can't see anything.

      Say I want 'command' to do this 'other command' but only on these set of conditions?

      Is that possible or would it add a lot more complexity to this?

      You mean, having one Command fire up another Command? That is just a matter of using execute_cmd on the one using the command (self.caller) .

          from evennia import Command
          class ThisCmd(Command):
              key = "thiscmd"   
              def func(self):
                  # if (say) our location has some
                  # particular flag set, run another command
                  if self.caller.location.db.do_othercmd:
                      self.caller.execute_cmd("othercmd") 
      

      Of course, func can hold any code. All details about the Command (like who called it, what string was used, its arguments etc) are set as properties directly on the Command at run-time, making them easily accessible without any boilerplate.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @Thenomain said in What is out there? Hard and soft codebases of choice.:

      @Griatch said in What is out there? Hard and soft codebases of choice.:

      Allow me to update @Thenomain's list of "things". The list of things you need to know to be a beginner Evennia user is, IMO, as follows:

      [...]

      • You need to know how to use a text editor and how to switch between windows in your OS. For seeing the results in-game you need a web browser or telnet client of your choice.

      This is such a strange addition to the list, and I at first thought you were being a bit sarcastic and/or bitter. I'm pretty sure you're not, but, well, this is Soapbox. I never know.

      The need for a text editor is a difference to what is needed for writing mushcode, hence the inclusion. I guess the need for the browser/telnet client is a bit superfluous though.

      I did have one question: How easy is it to remove @ from some of the global commands? The more I purge '+' from my own code, the stranger it seems. I'm guessing "bloody easy".

      It's normally easy to overload a default command by name. Since we in this case want to replace the default command with the same functionality but with a different name (key) we need to unload the old and then add it again with the new key.

      First overload the original implementation of, say @reload. All we need to change is the Command's key.

      # in, say your commands/command.py module
      from evennia import default_cmds
      class CmdReload(default_cmds.CmdReload):
          key = "reload"  # instead of @reload
      

      The @reload command is by default made available through the Player command set. So we remove the old command from the command set and add in our new renamed one. This file is already pre-filled when you install Evennia, we just have to add the lines doing what we want:

      # in commands/default_cmdsets.py 
      # [...]
      from commands import command
      class PlayerCmdSet(default_cmds.PlayerCmdSet):
          def at_cmdset_creation(self):
              # [...]
              # remove the default one, add our custom one:
              self.remove(default_cmds.CmdReload)
              self.add(command.CmdReload())
      

      Then do @reload (for the last time) and you will henceforth be using reload instead.

      UPDATE (2018): These days you can simply tell evennia to ignore the initial @ (or any other set of characters) so people can use @reload or reload etc interchangeably without any code changes.

      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @faraday said in What is out there? Hard and soft codebases of choice.:

      @Griatch said in What is out there? Hard and soft codebases of choice.:

      Could you elaborate more on what you refer to by the "web template interface" here?

      We were just talking about web UIs for MUSHes. I mentioned my painful experiments with Ares' web UI, we both sort of said "I wonder how Evennia does it" and went on a scavenger hunt through the code and docs before finally finding this.

      Now I know that nothing in Evennia is stamped "for professionals only" but there's HTML and Javascript stuff, python stuff, Django templates, plus a separate web client and web server, plus SQL... you gotta kinda admit it's a lot to learn, yeah?

      Just to explain what you are seeing - that page contains HTML with Django template markers, like {% ... %}. Those are used for "importing" other HTML pages and to populate the page with the contents of game variables like number of players etc without the need for embedded Javascript.

      If you want to create a website, yes you'll need to know HTML and CSS, most likely with some Javascript thrown in. Do you have to know these to be proficient with Evennia though? No; it's all set up to run for you. There is no need to learn SQL (that's after all one big point of Django) nor how to handle a web server apart from opening the right ports. If you wanted to customize the Javascript client code then yes you'd obviously need to know Javascript, but we are aiming to make this more pluggable so you don't have to but can structure the interface more graphically (that's in the future though).

      Is it a lot of stuff to learn? If you wanted to tweak and master everything we have already created, yes certainly. You don't have to though, certainly not for replicating a traditional MU*.

      Allow me to update @Thenomain's list of "things". The list of things you need to know to be a beginner Evennia user is, IMO, as follows:

      • To install you need to know how to install packages / dependencies in your OS of choice. You also need to know to use a terminal line / console.
      • You need to be able to blindly ape one command of GIT (to clone Evennia).
      • You need to know to activate the virtualenv to get access to the evennia command before you do anything.
      • Basic Python. That is, the ability to write syntactically sound Python and be able to read example code with classes, functions and variables. Know how to import things from other modules and what a traceback is ... those kinds of things.
      • You need to know how to use a text editor and how to switch between windows in your OS. For seeing the results in-game you need a web browser or telnet client of your choice.

      With this you will be able to pick your way through most of the beginner code tutorials with your locally-running Evennia, including creating your own commands, new object types and creating a small mini-game with placeholder game mechanics. You'll be learning how to interact with the Evennia API along the way. No Django knowledge is required, no SQL is (ever) used.

      It will not be an immediate success. You will make errors, you will not understand why things don't work, you will miss those indents that Python requires. Evennia will complain and spit out tracebacks left and right at the weird stuff you throw at it. You will (hopefully) ask for help and get it. But eventually you will have a feel for what goes where and how things connect.

      ... Then you may want to learn some few lines of Django to build database queries not covered by Evennia's normal search routines. You may want to put your code under version control if you want to collaborate on a code base. You may want to take your game online. Maybe tweak some HTML to make your game home page prettier. At some point it's your ambitions and game-goals that define what you want to go and learn next.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @Thenomain

      The db is thankfully set up in the main install. Faraday and I looked briefly at the web template interface, though, and both said "aw hell naw!"

      Could you elaborate more on what you refer to by the "web template interface" here?
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @Thenomain said in [What is out there?

      You seem to be taking it as an attack on Evennia, @Griach, at the very least defending the differences between Mushlikes and Evennia, differences that do not need defended. Explained, maybe, but you've explained them already.

      I don't see any of this as an attack or I would have stopped posting here a long time ago. I'm genuinely interested in rational feedback and opinions from you folk coming from a very different end of the mu* experience spectrum than most mud/mushers using Evennia. Do I have to agree or care enough about the feedback to make changes? No, of course not (but I'm not alone developing Evennia either btw, We do accept PRs...). Mush is only one subset of the game types people use Evennia for. Doesn't make it any less valuable to hear it though.

      If other people don't think those differences are valuable, why do you care? If you do care, why don't you change them?

      Of course I care. I'm a "hobbyist" too you know. I like it when people use my stuff. That doesn't mean I have to agree to please everyone or neglect to try to correct things I perceive as misunderstanding's though.

      Edit: I agree this is off topic from the original question though, Apologies for my part in that.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @faraday said in What is out there? Hard and soft codebases of choice.:

      @Griatch said in What is out there? Hard and soft codebases of choice.:

      I could personally not imagine writing a full game in anything lisp-like, but that just shows my bias. All the more power to you.

      I think it depends on what you consider a "full game". +finger, +who, room parent descriptions... those are relatively easy to customize and learn once you learn a few MUSHcode basics. Where the gap exists is in the more advanced systems - sophisticated chargen, combat, economy, etc. There I respectfully disagree with @krmbm that you do have to be a pretty advanced MUSHcoder to accomplish. That's why a lot of people use Theno's WoD system or my FS3. Of course, many games don't need those things.

      I refer to the complex stuff primarily yes - the chargens, the combat systems, the space systems, the economics etc .

      If you just want your players to be able to do simple things you don't need a full softcode language; you just need powerful build commands with some aliasing and object slots for the player to customize. My impression from previous discussions on this matter is that this limited use would fulfill most of the needs many mush players actually use softcode for today.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @krmbm said in What is out there? Hard and soft codebases of choice.:

      @Griatch said in What is out there? Hard and soft codebases of choice.:

      @krmbm said in What is out there? Hard and soft codebases of choice.:

      @Griatch said in What is out there? Hard and soft codebases of choice.:

      This is a very important point. For all the "bridging power" of mushcode, how many can actually use it to the level of, you know, creating a new game from scratch? I am not familiar enough with the MUSH community to know this number, but I suspect that it's not a large number.

      You'd be surprised.

      I know several people just within my one tiny subset of MUs that could get a game up-and-running themselves quickly. Partially, this is because installing MU (as has been noted) is generally super easy, especially if you go to a MU* host, where they give you a working environment and all you have to do is upload, extract, and start your MUSH.

      That is great and a good boon. It's not what I asked though (or intended to ask). Just starting a server is one thing. The question was how many can then build a full game in mushcode off what the server offers with that download. Maybe the better question would be how many @Thenomain 's and @Volund 's are around these days? It''s not a retorical question - it would be interesting to know.

      I'm not sure where I didn't answer that? Maybe I just wasn't specific?

      I know several people (myself included) that could install and code a game that they could open to the public, without borrowing someone else's soft-code. You don't have to be a psycho-coder to make a functional MUSH.

      Which is pretty much what I think everyone in this thread has been saying: Evennia seems cool! But it seems like it might be a little steep on the learning curve for the average MUSHer.

      OK, then I misunderstood you. Fair enough then!
      I could personally not imagine writing a full game in anything lisp-like, but that just shows my bias. All the more power to you.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • RE: What is out there? Hard and soft codebases of choice.

      @krmbm said in What is out there? Hard and soft codebases of choice.:

      @Griatch said in What is out there? Hard and soft codebases of choice.:

      This is a very important point. For all the "bridging power" of mushcode, how many can actually use it to the level of, you know, creating a new game from scratch? I am not familiar enough with the MUSH community to know this number, but I suspect that it's not a large number.

      You'd be surprised.

      I know several people just within my one tiny subset of MUs that could get a game up-and-running themselves quickly. Partially, this is because installing MU (as has been noted) is generally super easy, especially if you go to a MU* host, where they give you a working environment and all you have to do is upload, extract, and start your MUSH.

      That is great and a good boon. It's not what I asked though (or intended to ask). Just starting a server is one thing. The question was how many can then build a full game in mushcode off what the server offers with that download. Maybe the better question would be how many @Thenomain 's and @Volund 's are around these days? It''s not a retorical question - it would be interesting to know.

      I think everyone acknowledges that MU is archaic, but it's also got a very low barrier to entry, and that's what Evennia lacks for me.

      What interests me is how big a part of that "low barrier" is due to familiarity and how much this colors perceptions and comparisons. Because, as someone who has used lisp but is not a mush user, the mush softcode system is one heck of a barrier.
      .
      Griatch

      posted in MU Questions & Requests
      Griatch
      Griatch
    • 1
    • 2
    • 9
    • 10
    • 11
    • 12
    • 13
    • 18
    • 19
    • 11 / 19