Friday, March 11, 2011
Saturday, October 9, 2010
Friday, October 8, 2010
Bug paintings
Sitting outside with tea from a sock, thinking about what I want to paint.
I know I want this to be a dragonfly, but my previous attempts have all been too busy. I think my goal with this will be to subdue and focus attention to only a few colorful areas, rather than having the entire thing be bright. I have seen plenty of paintings use a dark to ochre blend to bring light to the center, and I think that is what I should attempt to emulate this time.
For the dragonfly, I can find a happy medium between reality and colorful impression, hopefully.
I am torn between wanting to add some sort of backdrop elements, such as dead leaves. On the one hand, if I pull them off correctly it may help to make the whole focus thing more natural. On the other hand, serious danger of becoming too busy.
I think this will work.
I will save the ladybug and stag beetle for collaborating with Zoe. I may try to get the same underlying effect if the dragonfly works out, and Zoe can bring in the color like last time.
- Posted while roaming
I know I want this to be a dragonfly, but my previous attempts have all been too busy. I think my goal with this will be to subdue and focus attention to only a few colorful areas, rather than having the entire thing be bright. I have seen plenty of paintings use a dark to ochre blend to bring light to the center, and I think that is what I should attempt to emulate this time.
For the dragonfly, I can find a happy medium between reality and colorful impression, hopefully.
I am torn between wanting to add some sort of backdrop elements, such as dead leaves. On the one hand, if I pull them off correctly it may help to make the whole focus thing more natural. On the other hand, serious danger of becoming too busy.
I think this will work.
I will save the ladybug and stag beetle for collaborating with Zoe. I may try to get the same underlying effect if the dragonfly works out, and Zoe can bring in the color like last time.
- Posted while roaming
Thursday, October 7, 2010
Thursday, September 30, 2010
A Pair of Warcraft Addons
I've been poking around with Lua a little bit lately, working with Addons for World of Warcraft.
Original TOTTler addon: http://wow.curseforge.com/addons/tottler
My tottler friendly fork/utter rewrite: http://code.google.com/p/obriencj/source/browse/tottler/trunk
To understand why an addon such as tottler exists, you must first understand the rogue ability Tricks of the Trade (also just tricks or tott). Tricks is an ability which a rogue can cast on a friendly target. When the rogue makes a special attack on a creature after casting tricks, the threat which is generated from that attack, and any threat generated for the next six seconds, is passed on to the friendly target. This allows a rogue to help a tank keep their threat high, and it can assist in AOE pulls of many monsters at once.
In addition to the threat transfer, tricks also gives a damage boost to the friendly target for the duration of the transfer.
As if that wasn't enough fun, the tier 10 two-piece bonus makes tricks also cost no energy, and instead gives energy back to the rogue. This makes the ability a massively important tool, as energy is commonly the limiting factor in what a rogue can do.
Tricks of the Trade works as three separate affects. When it is originally cast, the rogue gains a buff that lasts for 30 seconds. After the first special attack happens, that buff disappears, and another buff (which lasts for 6 seconds) appears. This second buff is the one that actively transfers threat to the tricks target.
At the time of the first special attack, third buff is placed upon the tricks target, and this buff grants them their damage boost.
It is possible to cancel the rogue's threat transfer buff. Doing so does not effect the target's damage boost buff.
In essence, this means it is possible to use tricks, get the energy refund from the 2pc t10, give the damage boost to a non-tank (such as another rogue), and NOT give the friendly target any additional threat.
There was a fair amount of consideration over this in the forums, and the original author of TOTTler wrote an addon that would automatically cancel the threat transfer.
What's most interesting is that the original TOTTler also was clever, and permitted the player from deciding ahead of time whether the tricks target should or should not get the threat. For instance, if the target was the tank, you'd definitely want the threat transfer. If the target was a mage, you really wouldn't want to give them even more threat (unless you were trying to get them killed, which is fine by me).
I picked up TOTTler, but I found that its command interface was terribly broken, so I took a look at the code and found a lot of bits of ugly (nothing declared local, unnecessarily using an XML file for the frame description, etc). I decided that I should make myself useful, and contribute some patches back to the original author.
The problem is that the original author isn't very responsive (to me at least). Also, the code for TOTTler wasn't kept in a source control system that I could find.
Luckily, TOTTler was licensed to be in the public domain! So I set about re-writing it as a friendly fork, calling it simply "tottler"
I cleaned up the handling of events and commands. I also added the ability to have the addon notify you when another rogue is giving you the damage-increasing buff.
There are three parts of tottler that I am particularly happy with, and will likely re-use in other addons that I write in the future.
First, and I have already re-used this, I have a very short pattern for creating local functions for subscribing to and handling events. I create a table with keys matching the event names, and values referencing the local function to be called. I then create an empty Frame, and set its On_Event handler to a short function which simply looks up the event in the table and executes it's function with all of the remaining arguments to the event.
The table-lookup can be significantly faster than a if/then/else block checking the string over and over again, and it's much more terse and easier to add new events to... you just put the event name and its handler in the event_handler table and it'll work! See lines 702 through 718.
Secondly came handling the command-line interface for the addon. The original TOTTler would throw an exception of you specified an incorrect number of arguments, or an unknown command. This was something that I really wanted to fix.
I set up a table listing each of the commands, the function that should handle the command, and some short help text. The dispatcher would then unpack all of the arguments into a list, find the correct command (and fail gracefully), and pass the arguments to the correct function.
Again, table lookup being faster than if/then/else, this also permitted me to very easily write a help command that would present all of the known commands and their arguments and descriptions. Adding a new command involves updating the table and writing a handler function. I will definitely be re-using this code in the future. See lines 471 through 566 for the main command handler and commands table.
Finally, I needed a reliable way to detect the application of multiple buffs. For this, I put together a handler for the UNIT_AURA event. Each time the UNIT_AURA event fires, the various buffs on the unit are collected into a table for caching. For each buff that was added to the cache, but which was not in the previous cache, a table is checked. This table is keyed by spell_ids, the value is a handler function to be called when that spell_id is found, but only the first time! So we if we have an aura on the player which wasn't found the last time UNIT_AURA was called, we know it is newly applied. We check if we are interested in this aura (by seeing if there's a function associated with that spell_id), and if so, we'll call the handler function. At the end of the event, the new cache is stored, and the previous cache is destroyed. See lines 594 through 647.
Unfortunately come patch 4.0.1, it will no longer be possible for an addon to cancel a unit's buffs automatically while in combat. This will kill the primary purpose of this addon. It's entirely possible that addons like this are the very reason for the change.
http://code.google.com/p/obriencj/source/browse/whoseaura/trunk
One of the things that often annoyed me when looking at my buffs and debuffs is that I could not easily tell who had applied what spell on whom. The information is obviously available to our game clients (if you watch the combat log, you'll see the name of the original buff casters when the affects are applied and when they fade), why isn't it in the user interface?
So I wrote the simple whoseaura addon, which simply binds to the GameTooltip and watches for the SetUnitAura call. Whenever this is triggered, whoseaura uses the UnitAura function to get detailed information such as the unit_id of the aura's caster.
Now, unfortunately, a unit_id is not always terribly useful. A unit_id will be something like, "player" or "target" or "party3" rather than an actual name. One must use the GetName function to convert a unit_id into an actual meaningful name, rather than a relationship.
Problematically, if there's no ready unit_id to describe the relationship between the caster and the player, UnitAura will return nil for that field! For example: a paladin you are not in party with casts Kings on you. If you target the paladin and mouse-over the Kings tooltip, you'll see their name as the caster. However, if you un-target them, the caster will now display as "Unknown" because UnitAura wasn't able to describe a relationship to that player!
A possible fix for this would be to instead monitor the combat log, which does not use a unit_id, but which instead will always provide the full name (and server) of the casting player or creature. However, this would require some caching and a lot of filtering.
For now, I am alright with whoseaura operating with the limitations of the UnitAura function, because it keeps the addon utterly tiny.
TOTTler and tottler
Original TOTTler addon: http://wow.curseforge.com/addons/tottler
My tottler friendly fork/utter rewrite: http://code.google.com/p/obriencj/source/browse/tottler/trunk
To understand why an addon such as tottler exists, you must first understand the rogue ability Tricks of the Trade (also just tricks or tott). Tricks is an ability which a rogue can cast on a friendly target. When the rogue makes a special attack on a creature after casting tricks, the threat which is generated from that attack, and any threat generated for the next six seconds, is passed on to the friendly target. This allows a rogue to help a tank keep their threat high, and it can assist in AOE pulls of many monsters at once.
In addition to the threat transfer, tricks also gives a damage boost to the friendly target for the duration of the transfer.
As if that wasn't enough fun, the tier 10 two-piece bonus makes tricks also cost no energy, and instead gives energy back to the rogue. This makes the ability a massively important tool, as energy is commonly the limiting factor in what a rogue can do.
Tricks of the Trade works as three separate affects. When it is originally cast, the rogue gains a buff that lasts for 30 seconds. After the first special attack happens, that buff disappears, and another buff (which lasts for 6 seconds) appears. This second buff is the one that actively transfers threat to the tricks target.
At the time of the first special attack, third buff is placed upon the tricks target, and this buff grants them their damage boost.
It is possible to cancel the rogue's threat transfer buff. Doing so does not effect the target's damage boost buff.
In essence, this means it is possible to use tricks, get the energy refund from the 2pc t10, give the damage boost to a non-tank (such as another rogue), and NOT give the friendly target any additional threat.
There was a fair amount of consideration over this in the forums, and the original author of TOTTler wrote an addon that would automatically cancel the threat transfer.
What's most interesting is that the original TOTTler also was clever, and permitted the player from deciding ahead of time whether the tricks target should or should not get the threat. For instance, if the target was the tank, you'd definitely want the threat transfer. If the target was a mage, you really wouldn't want to give them even more threat (unless you were trying to get them killed, which is fine by me).
I picked up TOTTler, but I found that its command interface was terribly broken, so I took a look at the code and found a lot of bits of ugly (nothing declared local, unnecessarily using an XML file for the frame description, etc). I decided that I should make myself useful, and contribute some patches back to the original author.
The problem is that the original author isn't very responsive (to me at least). Also, the code for TOTTler wasn't kept in a source control system that I could find.
Luckily, TOTTler was licensed to be in the public domain! So I set about re-writing it as a friendly fork, calling it simply "tottler"
I cleaned up the handling of events and commands. I also added the ability to have the addon notify you when another rogue is giving you the damage-increasing buff.
There are three parts of tottler that I am particularly happy with, and will likely re-use in other addons that I write in the future.
First, and I have already re-used this, I have a very short pattern for creating local functions for subscribing to and handling events. I create a table with keys matching the event names, and values referencing the local function to be called. I then create an empty Frame, and set its On_Event handler to a short function which simply looks up the event in the table and executes it's function with all of the remaining arguments to the event.
The table-lookup can be significantly faster than a if/then/else block checking the string over and over again, and it's much more terse and easier to add new events to... you just put the event name and its handler in the event_handler table and it'll work! See lines 702 through 718.
Secondly came handling the command-line interface for the addon. The original TOTTler would throw an exception of you specified an incorrect number of arguments, or an unknown command. This was something that I really wanted to fix.
I set up a table listing each of the commands, the function that should handle the command, and some short help text. The dispatcher would then unpack all of the arguments into a list, find the correct command (and fail gracefully), and pass the arguments to the correct function.
Again, table lookup being faster than if/then/else, this also permitted me to very easily write a help command that would present all of the known commands and their arguments and descriptions. Adding a new command involves updating the table and writing a handler function. I will definitely be re-using this code in the future. See lines 471 through 566 for the main command handler and commands table.
Finally, I needed a reliable way to detect the application of multiple buffs. For this, I put together a handler for the UNIT_AURA event. Each time the UNIT_AURA event fires, the various buffs on the unit are collected into a table for caching. For each buff that was added to the cache, but which was not in the previous cache, a table is checked. This table is keyed by spell_ids, the value is a handler function to be called when that spell_id is found, but only the first time! So we if we have an aura on the player which wasn't found the last time UNIT_AURA was called, we know it is newly applied. We check if we are interested in this aura (by seeing if there's a function associated with that spell_id), and if so, we'll call the handler function. At the end of the event, the new cache is stored, and the previous cache is destroyed. See lines 594 through 647.
Unfortunately come patch 4.0.1, it will no longer be possible for an addon to cancel a unit's buffs automatically while in combat. This will kill the primary purpose of this addon. It's entirely possible that addons like this are the very reason for the change.
Whose Aura Is This?
http://code.google.com/p/obriencj/source/browse/whoseaura/trunk
One of the things that often annoyed me when looking at my buffs and debuffs is that I could not easily tell who had applied what spell on whom. The information is obviously available to our game clients (if you watch the combat log, you'll see the name of the original buff casters when the affects are applied and when they fade), why isn't it in the user interface?
So I wrote the simple whoseaura addon, which simply binds to the GameTooltip and watches for the SetUnitAura call. Whenever this is triggered, whoseaura uses the UnitAura function to get detailed information such as the unit_id of the aura's caster.
Now, unfortunately, a unit_id is not always terribly useful. A unit_id will be something like, "player" or "target" or "party3" rather than an actual name. One must use the GetName function to convert a unit_id into an actual meaningful name, rather than a relationship.
Problematically, if there's no ready unit_id to describe the relationship between the caster and the player, UnitAura will return nil for that field! For example: a paladin you are not in party with casts Kings on you. If you target the paladin and mouse-over the Kings tooltip, you'll see their name as the caster. However, if you un-target them, the caster will now display as "Unknown" because UnitAura wasn't able to describe a relationship to that player!
A possible fix for this would be to instead monitor the combat log, which does not use a unit_id, but which instead will always provide the full name (and server) of the casting player or creature. However, this would require some caching and a lot of filtering.
For now, I am alright with whoseaura operating with the limitations of the UnitAura function, because it keeps the addon utterly tiny.
Sunday, July 19, 2009
The Arduino as a Sequencer
There are a number of simple projects that use the Arduino (or another ATmega168/328 platform) as a tone generator and/or sequencer. In a fit of activity one night, I realized that with a broken pair of headphones and some spare wire, I had everything I needed to make my Arduino into a fun noise generator as well.
Thus began work on the sequencer_1 code.
Sequencer_1
The first iteration of the sequencer software that I put together for my Arduino was pretty basic, re-using a lot of existing example code (such as the frequency-output function freqout). It was very simple, with all of the interesting stuff happening in the loop function:
Sequencer_2
The second iteration of the sequencer software started to make use of the internal interrupt handlers. It attached Timer1 at a very high frequency and used it to flip the speaker pin between HIGH and LOW based on a dividing counter. The Timer2 interrupt was used at a lower frequency to service the tempo. The loop method was still used, but now it only performed the recording of the sequence. The input and output were nearly identical to the sequencer_1, except now there was no gap between the steps of the sequence-- a note could be held and would sound like a single solid tone.
Sequencer_3
Both of the previous sequencers had used a minimal number of parts, but had only been capable of outputting a square wave. I wanted to get into some analog action, so it was time to try and output a wave.
First I needed to figure out how to programmatically determine what voltage I should be attempting to produce at any given moment. I would commit an interrupt to updating the output voltage at a sampling frequency of around 10kHz. A second interrupt would act as the tempo handler. Whenever the tempo would update, it would set a global multiplier and divider pair. The divider becomes a counter which decrements each time the sampling interrupt fires. When it reaches zero, an output level is selected from a pre-defined table representing the sine wave. The index into this table is incremented by the multiplier each time the divider counter reaches zero. This has the net result of simulating a sampled wave at the appropriate frequency.
To actually convert the given calculated value into a voltage, a serial-to-parallel chip is fed the byte. When it latches, the eight-bit output is fed into a digital-to-analog converter. In my initial build, a simple R/2R ladder DAC worked out fine, but required a voltage divider on the output (to drop the signal to a normal 1.5V line-level range) as well as a passive low-pass filter to quiet down some component noise.
Code
The code so far is over at my Google Code page
Thus began work on the sequencer_1 code.
Sequencer_1
The first iteration of the sequencer software that I put together for my Arduino was pretty basic, re-using a lot of existing example code (such as the frequency-output function freqout). It was very simple, with all of the interesting stuff happening in the loop function:
- check for the "record" button
- check the status of the scale and note knobs
- put any recorded note/scale combinations into the sequence at the current index
- read the tempo knob
- play the current note/scale for however long the tempo requires it to be played
- set the speaker pin HIGH for a little while
- then set the speaker pin LOW for a little while
- advance the index of the sequence
Sequencer_2
The second iteration of the sequencer software started to make use of the internal interrupt handlers. It attached Timer1 at a very high frequency and used it to flip the speaker pin between HIGH and LOW based on a dividing counter. The Timer2 interrupt was used at a lower frequency to service the tempo. The loop method was still used, but now it only performed the recording of the sequence. The input and output were nearly identical to the sequencer_1, except now there was no gap between the steps of the sequence-- a note could be held and would sound like a single solid tone.
Sequencer_3
Both of the previous sequencers had used a minimal number of parts, but had only been capable of outputting a square wave. I wanted to get into some analog action, so it was time to try and output a wave.
First I needed to figure out how to programmatically determine what voltage I should be attempting to produce at any given moment. I would commit an interrupt to updating the output voltage at a sampling frequency of around 10kHz. A second interrupt would act as the tempo handler. Whenever the tempo would update, it would set a global multiplier and divider pair. The divider becomes a counter which decrements each time the sampling interrupt fires. When it reaches zero, an output level is selected from a pre-defined table representing the sine wave. The index into this table is incremented by the multiplier each time the divider counter reaches zero. This has the net result of simulating a sampled wave at the appropriate frequency.
To actually convert the given calculated value into a voltage, a serial-to-parallel chip is fed the byte. When it latches, the eight-bit output is fed into a digital-to-analog converter. In my initial build, a simple R/2R ladder DAC worked out fine, but required a voltage divider on the output (to drop the signal to a normal 1.5V line-level range) as well as a passive low-pass filter to quiet down some component noise.
Code
The code so far is over at my Google Code page
Friday, May 22, 2009
Arduino Pinball Hacking
My pinball machine does not have a functional MPU. The MPU is the board that has the logic for the rules of the particular game, and it communicates with the phyisical aspects of the pinball machine (the solenoids, the lights, and the switch matrix). Without a working MPU, the pinball machine doesn't do much of anything at all. Luckily for me, replacement MPUs exist for older machines like mine, and are relatively inexpensive.
I've been messing around with the Arduino lately. It's an excellent little embedded platform for hobbyists and goofing around, and you can do serious work with it as well.
I decided that it would be pretty spiffy if I were to create an MPU replacement using an Arduino. The interfaces to the other boards (lights, solenoids) and the switch matrix is documented with great detail in the manual for the machine itself. There are full schematics, as well as a number of repair tutorials available on the internet. There was even a project to create an ISA controller card doing just what I want my Arduino to do.
I envision my project progressing as such:
This would permit me to take off-the-shelf Bally replacement parts and create my own pinball games!
Given the above features as a "version 1.0" of the project, I've already got some "2.0" plans in my head. For instance, the hardware for the controller could act as a man-in-the-middle for an authentic MPU. It could both monitor exactly what the real MPU is doing (and report it to the PC) and it could completely override the MPU. It could trick the MPU by showing fake switch presses.
I've been messing around with the Arduino lately. It's an excellent little embedded platform for hobbyists and goofing around, and you can do serious work with it as well.
I decided that it would be pretty spiffy if I were to create an MPU replacement using an Arduino. The interfaces to the other boards (lights, solenoids) and the switch matrix is documented with great detail in the manual for the machine itself. There are full schematics, as well as a number of repair tutorials available on the internet. There was even a project to create an ISA controller card doing just what I want my Arduino to do.
I envision my project progressing as such:
- get a switch matrix scanning routine and associated hardware working. This will permit me to monitor the ball on the playfield from a PC connected to my Arduino via the USB cable.
- get a lamp refreshing routine and associated hardware working. This will permit my controlling PC to set the state of the playfield lights
- get a solenoid triggering routine/hardware working. This will permit my controlling PC to pop bumpers and play chimes, etc.
- get a score display routine/hardware working. This gets me the ability to set the scores on the back-box, and is the last piece of direct interaction.
- write a simple game rule set that runs on the PC that allows me to play the pinball machine
- figure out how to make the Arduino autonomously follow that game rule set (either a library of the hard-coded game rules, or some sort of super-simple byte-code indicating events to watch for and what to do to the score and bumpers and lights, etc)
This would permit me to take off-the-shelf Bally replacement parts and create my own pinball games!
Given the above features as a "version 1.0" of the project, I've already got some "2.0" plans in my head. For instance, the hardware for the controller could act as a man-in-the-middle for an authentic MPU. It could both monitor exactly what the real MPU is doing (and report it to the PC) and it could completely override the MPU. It could trick the MPU by showing fake switch presses.
Subscribe to:
Posts (Atom)