Added an example of use to the module descriptions, as well as fixed a couple of bugs where the at_get() hook wasn't functioning right and clothing with custom wear styles didn't appear correctly.
Adds a new contrib module, providing a system for wearable clothing objects that are appended to one's description. From the module itself:
Items of clothing can be used to cover other items, and many options are provided to define your own clothing types and their limits and behaviors. For example, to have undergarments automatically covered by outerwear, or to put a limit on the number of each type of item
that can be worn. Characters can also specify the style of wear for their clothing - I.E. to wear a scarf 'tied into a tight knot around the neck' or 'draped loosely across the shoulders' - to add an easy avenue of customization. The system as-is is fairly freeform - you can cover any garment with almost any other, for example - but it can easily be made more restrictive, and can even be tied into a system for armor or other equipment.
The unit tests have not been put in for this module yet, but I thought I would share it first to get people's thoughts!
Put in a line of code to stop the turn handler script when the tests are completed, as I think the script lingering and attempting to iterate causes problems with the Travis build.
I added all of the turn handler script's methods to the unit tests (excluding at_creation, at_repeat, and at_stop) - so I think with the exception of those, my module is now fully covered by unit tests!
Changed the order of the code in CmdAttack, so that it does not try to search for a target until it's established that it's a valid time to attack. This is so it doesn't raise a 'not found' error message along with the other error messages given.
With the help of Cloud_Keeper and vincent_lg in chat, I made the combat help command work much better - it doesn't copy swaths of code from the original help command anymore, and instead simply calls the default help with super() when the conditions for combat help aren't met.
I also moved a line from combat cleanup to the turn handler script, since combat cleanup is called when a character is initialized in combat and could remove the needed reference to the turn handler on the room prematurely, resulting in various errors if more than one fighter joined a fight in progress.
Some of the code for joining a fight in progress was imported from my project, The World of Cool Battles, but was not implemented completely. The turn handler script now properly puts a reference to itself in the current fight's room, and joining a combat in progress that one isn't already a part of now works properly.
Added a new command, 'CmdCombatHelp', which inherits from the default help command. Its behavior is identical to the normal 'help' command, except that it'll return a short list of combat commands when used in combat with no arguments. If there's a better way to implement this functionality, let me know, since it did involve copy-pasting a huge chunk of code from the Help command just to change one thing!
I also fixed a glaring oversight where using the 'fight' command while already in a fight would start a second fight.
I merged all the battle commands into a command set together, which makes the module easier to install. The installation instructions have been changed to reflect this.
Reworked the way the turn timeout countdown works - it's now less precise but also no longer gives errors. There may be a problem in the Evennia codebase with the default script object's force_repeat() method, but I was unable to figure out what.
Fixed the header for the character code section, now that the command set is gone. Also, I forgot to mention, last commit I also fixed a bug where the timer wouldn't give a full 30 seconds for each characters turn if the turn progressed mid-interval.
Created a number of new functions for redundant code, including to initialize characters for combat and spending actions - also changed the suggested method of import, having the user import and add the commands. Adding the command set to BattleCharacter at creation was not persistent across reloads.
It turns out that changing the turn handler script to react to turn-ending commands instead of check for the end of the turn every single second was actually super easy. The script's interval has been increased from 1 second to 10 seconds, so it should fire off ten times less often now, AND instantly cycle the turn once a player has used all their actions.
Restores some minor fixes I committed and accidentally reverted when I failed to update my local copy of the module. Note to self: start actually using GitHub correctly.
Implemented most of Griatch's requested changes, including documentation of every class and function, adherence to Google and Evennia's style guides, re-ordering of methods to show them defined before they are used, and a less intrusive install process. Tested before committing and found to function the same way as before. More changes to come, particularly to rework the turn handler script to be more efficient.
This adds a new contrib file, a module that provides a simple framework for a tabletop style turn based battle system. From the module itself:
This is a framework for a simple turn-based combat system, similar
to those used in D&D-style tabletop role playing games. It allows
any character to start a fight in a room, at which point initiative
is rolled and a turn order is established. Each participant in combat
has a limited time to decide their action for that turn (30 seconds by
default), and combat progresses through the turn order, looping through
the participants until the fight ends.
Only simple rolls for attacking are implemented here, but this system
is easily extensible and can be used as the foundation for implementing
the rules from your turn-based tabletop game of choice or making your
own battle system.
Griatch - "That way it can still be parsed by the protocol if so needed, but it is also be passed on so the client can do custom stuff with it if it can."
Including a type kwarg for the say, whisper and pose commands allows the receivers of those messages to treat them differently depending on type. IMO This is a wide enough concern that it goes beyond a game specific requirement.
