Go Back   Angband Forums > Angband > Variants

Thread Tools Display Modes
Old January 3, 2014, 19:15   #71
Derakon's Avatar
Join Date: Dec 2009
Posts: 8,918
Derakon is on a distinguished road
Okay, I'm pretty sure I didn't completely muck up the merging, so the latest master on my repo should have the spellcasting changes and a new command-handling system that makes use of events and threads instead of coroutines. The spellbook "Magic for Beginners" now has Phase Door and Magic Missile in it, and they should both work. Obviously all the rest of the spells need to be implemented; so do failure rates, mana costs, proper spell display (and spell ordering; currently the book is unordered so the contents show up in a random order each game), etc.

Still, the basics are done, so if you want to implement new player spells, well, now you can. Each spell is its own object:
{"templates": "arcane attack spell",
"nameInfo": {"variantName": "Magic Missile"},
"procs": [{"name": "cast creature spell", "spellName": "magic missile",
    "damage": "(3+level)#4", "triggerCondition": "item use"}],
"spellInfo": {"manaCost": 1, "baseFailureRate": 25, "minLevel": 1}
And the spells are all listed in the entry for the spellbook:
{"index": 460, "subtype": "[Magic for Beginners]",
"templates": "magic book",
"containerContents": [
    ["arcane attack spell", "Magic Missile"],
    ["arcane mobility spell", "Phase Door"]
"nameInfo": {"variantName": "[Magic for Beginners]"},
"allocatorRules": [{"commonness": 50, "minDepth": 5, "maxDepth": -1}]},
The various subtypes of arcane spells all have differing stats; the base "arcane spell" object template establishes some baselines, and then the subtypes modify them:
{"templateName": "arcane spell",
"templates": "spell",
"classToSpellStats": {
    "mage": {"minLevelMultiplier": 1.0, "failureMultiplier": 1.0,
            "manaMultiplier": 1.0},
    "ranger": {"minLevelMultiplier": 1.5, "failureMultiplier": 1.5,
            "manaMultiplier": 1.25},
    "rogue": {"minLevelMultiplier": 2.0, "failureMultiplier": 1.5,
            "manaMultiplier": 2.0}

{"templateName": "arcane attack spell",
"templates": "arcane spell",
"classToSpellStats": {"rogue": {"minLevelMultiplier": 100.0}}
{"templateName": "arcane mobility spell",
"templates": "arcane spell",
"classToSpellStats": {
    "ranger": {"minLevelMultiplier": 2.0, "failureMultiplier": 1.5,
            "manaMultiplier": 1.5},
    "rogue": {"minLevelMultiplier": 1.0, "failureMultiplier": 1.0,
            "manaMultiplier": 1.5}
Derakon is offline   Reply With Quote
Old January 4, 2014, 04:27   #72
Join Date: Nov 2011
Posts: 24
mtadd is on a distinguished road
Sorry about the delay, I haven't checked my email the past couple days.

The command handler driven with coroutines was instituted really early in the project. The choice to use coroutines over threads could've been simply due to my aversion to threads in Python due to the GIL (global interthread lock) and its performance problems, so I was using coroutines to be able to perform asynchronous context switching in a single-threaded environment. Using the events module looks to be a great solution, obviating the need for the clunky nesting of recursed coroutines. Note that in Python 3.3 and later, a new language keyword "yield from" was added to simplify using coroutines in such a manner q.v. PEP 380 -- Syntax for Delegating to a Subgenerator

I haven't tried running your latest update yet, is it working as intended? What GUI platforms are currently supported?
mtadd is offline   Reply With Quote
Old January 4, 2014, 04:31   #73
Derakon's Avatar
Join Date: Dec 2009
Posts: 8,918
Derakon is on a distinguished road
All of the changes were done solely in the CommandHandler class that the various GUI front-ends inherit from, so they should all work. That said, I've only tested the wxPyrel frontend.

Coroutines vs. threads ought to have basically identical performance, GIL or no, since the I/O thread is always blocking on the command thread to complete, or the command thread is blocking on the I/O thread to provide input; either way there's only one thread running at a time. I could well believe that coroutines are ever so slightly more performant when written properly, just because you don't need to invoke the scheduler to allocate resources to the different threads, but I can't imagine it making a noticeable difference.

Put another way: we have far greater performance concerns.
Derakon is offline   Reply With Quote

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Pyrel dev log, part 5 Magnate Variants 114 June 2, 2013 15:10
Pyrel dev log, part 4 Magnate Variants 116 March 11, 2013 19:53
Pyrel dev log, part 3 Derakon Variants 108 November 12, 2012 23:30
Pyrel dev log, part 2 Derakon Variants 126 September 11, 2012 23:03
Pyrel dev log Derakon Variants 64 June 8, 2012 11:58

All times are GMT +1. The time now is 09:18.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.