[Stratos Burst] Helium Adapter

I have found an appropriate source for helium. After a bit of searching, I found a balloon wholesaler, All American Balloons, right here in Arlington, usually catering to large parties and car dealerships. The shop is well equipped to rent out a 125 cu. ft. tank for about $60, and they have been most helpful by allowing me to look at the tank to make sure I have proper fittings.

Getting the helium out of the tank and into the balloon has taken more planning than I would have thought. I could plan on using a standard balloon valve that comes on rentals from the party store, but that's a pretty small seal when compared to the 2-3 inch neck of the sounding balloon. Instead, I have assembled an adapter that fits the 5/8" valve on the tank, and expands to a 3" collar. The balloon neck fits easily without much extra space. 

Cost: $13

I'm almost there. I just need to sort out the phone, and we're ready to launch!

Game Development Journal #6

Just as I thought. Today I don't hate it so bad. I have brainstormed and added another page worth of material to my ongoing Google doc for the cult game.

I'm going ahead with the card drafting for now, with players buying from the small piles of available cards (as you do). Each card has a numerical "level" on the face, a gate if you will. I have linked madness to not only the hand size, but also to this gate value. In order to buy a card, a player must meet or exceed this gate value in madness, and discard a number of cards that meets or exceeds the purchase cost. Once bought, the player will draft this card directly into his hand.

Additionally, the last card at the bottom of each draft stack is a Cthulhu card. Once the pile is bought out and this card is revealed, the person who revealed it gains one madness (allowing him to buy more powerful cards and drawing a larger hand) and the Cthulhu card goes immediately to the common discard pile. At the beginning of each players turn, they draw up to their hand limit. If they draw a Cthulhu card it is immediately added to a tableau in the middle of the play area; however, if they player begins his turn with a ritual that is fully powered and ready to be completed on that turn (see below), they can opt to channel this card through that ritual. This will generate a side effect (to be determined), wreck the ritual (all cards put in the discard pile), and the cthulhu card itself is put in the discard instead of into play. This was apparently an inauspicious time to be screwing around in the universe. I am still considering making that part a mandatory action; play-testing should show the best way to handle it.

Regardless, if X-number of these cards are put into play, the game is over. The only way to remove a Cthulhu card that is already in the tableau is through specific card actions that allow it (Seal of R'lyeh and Star of R'lyeh)

There is no personal deck or discard pile - everything is handled through one common deck. Used or spent cards are discarded and will be shuffled into the common draw deck for all players to pull from. Whatever forces one cult puts into play may eventually come around to his opponents, but that player has the advantage of using it first! The minor exception to this flow is Rituals. Rituals are drafted to the hand as usual - a player of sufficient madness discards from his hand and buys it. Each ritual has a total power cost (abstractly, these are the components, sacrifices, and energy that must be put into it.) When he chooses to play it, he must back it with another card for its listed power cost. Each turn that player can add cards to it, increasing the committed cost. Once the ritual is fully powered, it must remain in play until the players next turn. After drawing up his hand, the player will set aside the ritual card for it's listed VP value, and discard all of the other cards committed to it. Optionally, if at any time a Ritual loses all power (through actions of other players or perhaps a Celestial Event) it must be discarded to the common pile as well. Hopefully it will come back to you, but it possible for your opponents to nab a free ritual and play it instead!

Keep in mind that the Celestial Events are continuing to roll over every round, fulfilling the prophesy of the return of great Cthulhu and casting global effects over the entire game. You had better hope you can summon your idol to protect your followers before time runs out for everyone.

Eaten by Zombies - A deck-building game

This week, I backed the Kickstarter campaign for the game Eaten by Zombies! from Max Holliday, and brought to the world by Mayday Games. This game appealed to me the moment I started reading through the info. For starters, well...it's zombies. I love zombie games. I don't give a crap that zombies have over-saturated just about every market they have infected. In fact, that's pretty damn meta, if you ask me! From what I have seen so far, it has some high quality production too. Good linen stock cards, fun and colorful art, good use of icons (road signs = awesome), and the ammo can box is just pure win. Sure, it's an exercise in shelf-marketing, but it seems to be a hell of a lot more user friendly than some other recent examples. (I'm looking at you, Quarriors!)

 This morning I realized exactly what the real hook was. This game does several things that I wanted to explore myself. In an earlier development journal, I discussed turning "losing" players into a collective force against the remaining ones, and Eaten by Zombies! does just that. If ever a survivor draws a full hand of six zombie cards from their draw deck, all survivors at the table go insane and the game is considered a zombie win. Players become zombies by losing their entire deck due to the attrition caused by losing fights with, or fleeing from, the growing zombie hoard. Also, the tension in the game is cranked up bit by bit as the hoard grows, and it seems that it isn't a matter of if a survivor will die, but when.


Both of these concepts I previously worked into a prototype zombie board-game of my own, which is untitled and is currently serving a simple study in these ideas. Furthermore, a deck-building game that not only pits you against the other players, but also against a global threat which can can destroy ALL players I have been tinkering with in the latest iterations of a cult themed game.



It is the (hopefully) successful combination of these elements  that has me really excited about the release of this game.

Game Development Journal #5

So back to my cultist game development...

I have made a lot of notes and changes as I've gone over this design, but so far nothing has quite gelled. I got myself to a point where I was toying around with some card blanks to test different turn-orders and base mechanics but nothing quite felt right about it. I had messed around with some card number ratios, printed out some samples, and then promptly forgot how many of each I needed. A bit frustrated, I packed them in a bag and stuck it away for a while.

I pulled them back out today and I've been reviewing my past notes, and I also managed to find where I had noted down the number of each type of card I wanted to test with. Something else has occurred to me though, and all that might be nearly void now -- this game might work well as a deck-building game.

So here are the elements that I am starting with.

Madness: Players will start out with a fairly low hand limit; for this example let's say 3 cards. By increasing your madness, you can increase your hand limit at a rate of 1:1. (A player with madness of 2 draws up to a hand of 5 cards.)

Great Old One: Each player blindly draws a card representing a Great Old One as their cult icon. This is the entity that they are attempting to summon before the coming of great Cthulhu, as only those disciples will be spared. The Great Old One may also impart a unique benefit or ability to the player.

Celestial Events: A small deck of celestial occurrences counts down the coming of Cthulhu. Each complete round, one of these cards is turned over as the prophesied event comes to pass. They will also cast both positive and negative global effects over the game.

Draw Deck: I have not yet worked out a drafting mechanic. Once that is in place the players game area will have a draft deck, discard pile, their hand, and a tableau. A functioning deck-build will have a mix of Disciples (basic cards that operate as the general currency), Artifacts (these stay in the tableau until used and may require the sacrifice of Disciples to aid in culling), Servitors (Player initiated global effects), Rituals (requires a combination of all previous cards to summon your Great Old One), and Cthulhu Cards. There will likely a brand of "instant" type cards to influence other players tableau/hand/madness. The Cthulhu Cards act to dilute and dirty a players decks. They will either be unwillingly drawn during a card draft or inflicted upon a player by his opponents; they cannot be culled or removed except by means of specific card effects.

The first draft of a hand order might go like this:

• Clear all cards currently in your tableau (with exception of unused artifacts), and place them in your discard pile.
• Draw up to your current hand limit. If your deck runs out of cards, shuffle your discard pile and place it as your draw deck.
• If one of these Cthulhu Cards comes up in a hand draw, it is played to the tableau immediately. If three are played to your tableau the game ends; you have inadvertently woken Cthulhu from his slumber.
• Play from your hand directly to your tableau; mechanics and all have yet to be worked out. Draft cards to your deck.
• The first player to play the an appropriate ritual using the cards played to the tableau summons their Great Old One and will survive the rising of Cthulhu.

There is certainly a lot to work out and it's not even near play-test yet, but I think this is a workable direction that I might be happy with.

Edit
On second thought, I think I hate the idea.

For now.

Maybe.

[Stratos Burst] The Parachute

Once the balloon has reached it's burst size somewhere in the stratospheric layer, the payload (in this case a foam cooler with some electronics) will need a parachute to give it a gentle ride back down to the ground. This of course will help keep anything inside from getting banged up, and also keep it from damaging anything that it might happen to fall on. Unless of course it falls on a highway and gets crushed by a car.

Without a parachute handy, I've fallen back on the amateur skills I worked up as a kite-builder and put one together. I once built a stack of 19 diamond kites that was pretty damned impressive to see in the sky. But it was also unstable as hell. Perhaps it was just that the few times I got to launch it was in pretty strong wind. Whatever the reason, it would fly for a good five or ten minutes before taking a hard turn and getting forced to nose the ground. Fortunately it was easy to re-launch, but damn that thing was an armload! So for all that, it never saw much flight time. 

Anyway, you can see here a few of the kites that I have cannibalized from the stack. All of the struts have been pulled out, and I've folded back the bottom tip and secured it with some industrial transfer adhesive that I had laying around to allow for a vent hole when they are sewn together. I have sewn all of the long edges together and attached some high-test kite line to some of the reinforced corners for shroud lines.  All in all it measures about 5.5 ft. in diameter with approximately 8 ft. lines which I have knotted onto a carabiner to clip onto whatever harness I fit to the payload.

Here's another picture of the finished parachute with the shroud lines daisy-chained to keep them from getting tangled and knotted. I have only attached five; it's a very light load, so I'm not too worried, but I do need to test it to make sure it properly breaks the fall.

Cost: $0

Entirely constructed from materials around the house.

[Stratos Burst] Camera Testing, con't.

I have been testing the duration of the camera over the last few weeks. My goal is to reduce the power draw by the camera itself, giving it as much operating time as possible. The longer the camera is able to operate, the longer flight I can plan without worrying about a block of time at the end where the camera is not capturing images.

My first few tests were disappointing in that the camera could only run for about three hours before the batteries died. I adjusted the image interval (currently up to every 3 min.) but that really did not have much effect. I also looked into ways to completely shut off the back-lit screen to keep it from drawing unnecessary power. There wasn't an obvious way to do this right off, so I looked into other scripts that I could load, system settings that might do it, ect. In the end though, I discovered that by just plugging in a video adapter cable into the side, the screen would shut down and feed it's output through that, thinking that I was using an external monitor or something. (I said the solution wasn't obvious, not that it wasn't just stupid easy!) So I ran down to the electronics store, bought a cable for a couple of bucks, and plugged it in, leaving the AV end loose.

Unfortunately this didn't help my battery life. So, up until this point I had been using straight AA Duracell batteries. I have been trying to save my lithium batteries for actual flight -- those are some expensive buggers at approximately $3 each. But in the end I popped them in and gave it a run-through using the intervalometer script. Seven hours I got out of that pair! Brilliant. So now I know how much time I might typically have. I will probably plan for about a five hour flight time if I can, since the temperatures at altitude and the interference from radiation might put a draw on that. I'll do my best to mitigate the effects by including some chemical hand warmers and such to keep the electronics from freezing.


Cost: $7

The balloon we've chosen is a 500g sounding balloon.

Free Lift: 1700g

Payload: 1150g

Gross Lift: 3350g

Inflation Volume: 3.1m(cubic)

Inflation Diameter: 1.8m

Ascent Rate: 400m/min

Burst Altitude: 24.5km

Cost: $57

The stratospheric layer of the atmosphere is typically considered to be from 11km to 50km above sea level. Assuming the range calculations are correct, this should put our burst altitude almost half-way up through the stratosphere when it bursts.

It seems a relative of mine has a daughter with a budding talent in art. I received this image through the grape vine, and I'm sharing it with all of you.

Game Development Journal #4 - SafeHouse Z

I made some time to work on this over the weekend and made some significant progress. Specifically, I managed to coax the concept off of my Google doc and onto tangible pieces of paper that took the approximate shape of a really ugly play-testing set complete with various piles of colored paper (color coded because it was easier than printing card-backs), a "board" printed on tabloid paper decorated with colored boxes, and a few player pieces scavenged from a copy of Zombies!!!

By the conclusion of my play-testing, the neatly stacked card decks were completely mixed together as cards were moved, reorganized, shuffled, written on, re-purposed, etc, and the board had so much red ink on it that I may have done better to open a vein over it and call it done. I expect anyone who has tried to put together a first prototype will know what this all looks like; it's the first time I have done it myself.

In the end, it did what I wanted it to do. Once the pacing was hammered out, survival became other than impossible, yet unlikely and more difficult as players were turned into viral, flesh-eating meat puppets. Supplies in the safe-house dwindled and the accrued building strength dropped as the remaining survivors were not able to loot enough supplies to keep up. Out of all the games played on it throughout the morning, only once did one of the four "players" I had set up manage to survive long enough for rescue, and even then it was by the skin of his teeth.

The game plays fairly quick, and it's not very deep. It boils down to decisions based on what the house has and what does it need, and are there enough supplies to keep all of the installed equipment functioning? I think I have the location decks worked out to a happy ratio, so my next step is to re-build these and reprint everything with the design changes made this weekend. There are a number of tweaks I want to explore, such as reducing the unique items to just two in a given deck, and then it can simmer while I brain-storm inspirations to make the game deeper.

Special thanks to my wife for rocking the beer chicken and sweet potatoes, and generally being fucking incredible while I entertained myself.

Beer bratwurst and roasted corn with a back-yard au-jus!

A quick recipe for you, folks. I've been making brats on the grill like this for a little while, but wait until you read what we did with the corn the other day!

Ingredients
Your favorite bratwurst (5 or 6 for this recipe)
12-16 oz of your favorite dark beer
1 small onion, sliced
6 garlic cloves, minced
Ears of whole corn with husks (clean out the silk and season to taste)

Fire up your grill. Bank the coals to one side and let it all get nice and hot. (If you are using a propane grill, just light up half of your elements, or do what you need to create a "cool" spot.) While you wait, put the brats, beer, onion, and garlic into a grill-safe pan such as a loaf pan. Make sure it's tall enough to cover the sausages. Top it all off with a bit of water or stock until all the brats are just covered.

When the coals are ready, set the pan on the "cool" side of your grill. Take the brats out of the marinade with tongs and put them over the fire; don't poke them with a fork as you will let all the juices out as they cook! Cook them for 3-5 minutes on each side, or until they are browned, crispy, and ready to split. By this time, the marinate may be starting to boil just a bit from the radiant heat; this is fine. Put all the brats back into the pan and leave them to stew.

Meanwhile, toss the ears of corn over the fire to roast, turning occasionally. It is fine of the husk starts to char and blacken; it will keep the corn inside from doing the same, but you'll probably get some char near the tip of the ear. Cut it off later if you want, but it won't kill you. Once the corn is good and cooked, remove it from the fire. The pan of brats should be bubbling nicely; take it off the grill as well.


-<Caution!>-
That loaf pan will be hot, so use mitts or pot-holders, and put it on a heat-safe surface, but leave the brats in there.

Clean the husks off of the corn, cut them down to serving size, and serve immediately. The marinade that you cooked the brats in will stay nice and hot. I usually put this straight on the table and serve them right out of there.

Here's the kicker to the plate. Carefully dip your ear of corn in the marinade as well! You have a nice flavorful bath of beer, onions, garlic, and juice from the bratwurst. This makes an excellent back-yard au-jus that compliments the sweetness of the roasted corn! You can use this as a dip or drizzle over other grilled vegetables as well.

Quick note about the beer.
I recommend using more flavorful beers like dark ales or stout, just nothing too bitter. Avoid using domestic pilsners or "lite" beers; these just won't add anything to the flavor of the juice. I personally like to use a home-brewed milk stout or brown ale.

We have also taken left-over au-jus and used it as a stock in soups, and I recommend stir fry, casseroles, or steamed vegetables. Anything that can use a kick of hearty flavor!

Give it a try and let me now what you cooked up, and what you did with the leftovers!

(I plan to do this again early this week, so I'll follow up with some delicious photos!)

[Stratos Burst] Camera Testing

As I type the camera is perched atop my computer quietly snapping photos of my beautiful mug every two minutes. I plan to let this run until I leave the office today or the batteries run out, whichever comes first.

From this test I hope to gather two pieces of information. First, how long the camera will last on a fresh set of batteries. I'm doing this first test on a set of standard alkaline AA's. The lithium batteries are too expensive to go burning up willy-nilly! But this should give me a ballpark figure under standard operating conditions. (i.e. room temperature, NOT an increase of ambient cosmic rays, etc.) Also, figuring the average image size that will help me calculate how much resolution I should be shooting for when balanced against available memory so I can plan to fill as much of that memory as possible in the time-span I expect to have on the batteries.

This means at X resolution per image, I will be using Y megabytes of memory. If I expect the batteries to last Z minutes, I can divide my total memory to see how many pictures I can fit in, and set an appropriate interval in minutes and seconds.

Make sense? Yeah, thought so.

So I have minimized the power drain. I have set the camera to no-flash as I plan to launch on a sunny day, and that teeny light won't do much good when you're shooting that sexy curve of the earth! I have also turned off all display options such as the picture preview, display stamps, ect. I cannot seem to find a setting that will allow me to simply turn off the LCD screen to save power. I can dial down the usage by setting it to turn off after 10 seconds. I  am looking into a secondary script, LCD backlight, that will allow me to turn the back-lighting off which is probably the most power-hungry part of the display.

Edit: Well that sucked. It ran for maybe two hours before the batteries gave out. That was shooting at intervals of two minutes. I have a secondary intervalometer script that will let me turn off the backlight after the first few shots. Hopefully that will save a bunch of power. I may have to space out my intervals a bit too.

More after I load that script and pop in a fresh pair of batteries.

Game Development Journal #3 - SafeHouse Z

I have been messing with a game design that initially proposed to have players who failed in their objective become active forces against the remaining players; a concept that I am told is difficult to implement and has since been stripped from that particular game draft. But I wasn't done with the idea itself and I wanted to find a way to use it in a game of my own, so here it comes.

You and your fellow survivors must build and maintain a safe-house in the center of a city rapidly succumbing to the rising zombie infection. Scout various locations throughout the city to find tools of survival and building materials to strengthen your stronghold. But watch out! Zed's lurk everywhere, and if you accrue too much of an infection, you will join the hoard as it attempts to break the safe-house!


One area of the board represents the safe-house, and all of the space that you have for tools and equipment. An inner track records it's overall strength. The surrounding zones represent various locations to scavenge materials. Along the outer edge of the board runs a progression track that represents the gross strength of the city's hoard of Zeds, and the effect they have upon the dwindling resources.

The game is played in two alternating phases. During the survivor phase, each player either scouts a location for supplies, indicated by placing their token at that site and draws a card (or cards), or performs an action such as building or remodeling the safe-house, installing equipment (such as a power generator), or hunting Zeds. Any unvisited locations continue to burn cards indicating loss to the Zeds or other survivors. Seeded throughout the decks are infection cards that indicate an unlucky encounter with the undead, as well as antiviral serum to battle infections.

Once all the actions have been performed, night falls and the zombies take their turn. The hoard gets stronger as the track advances. If ever the Zeds become stronger than the safe-house, the house is compromised and everyone inside gains infection.

When a survivor gains too much infection they join the hoard, but do not leave the game! During the zombie phase, the track advances faster for each turned player. They also continue to pull cards from the resources, flipping them around to the Zed specific actions such as draining additional resources or even damaging areas of the safe-house. Additionally, each turned player can place their token at one of the salvage sites. During the next survivor phase, a player may still visit that location for resources, but they will assuredly gain infection for their trouble.

If the remaining survivors can last until the hoard reaches the end of its track, they will be rescued from the city and the swarming Zeds. Between the dwindling and already scarce supplies, and the rising zombie threat, will they be able to hold out?

[Stratos Burst] More Hardware

The Antenna

This last weekend I acquired a couple of old broken wireless routers that I pillaged the antennas from. I will eventually put my hands on an adapter harness that will plug the antenna into the phone going into the payload to give it an extended area of reception during retrieval.

Cost: Free (Thanks, Dan!)


I still need to test the camera as well as start putting together the container for the payload. I also have a supply of kite string in my closet that should serve as cord and shroud lines for the parachute.

[Stratos Burst] Hacking the Camera #2

The Mega Intervalometer script is now installed. It has taken me an hour or so to figure out how to properly set up, initiate, and launch the function, but I believe I now have it sorted. Instead of buying a plug in Intervalometer device for thirty or forty dollars, this script allows me send commands to the camera through the CHDK firmware update. I can set it to automatically initiate the interval sequence on boot-up, the delay before taking the first shot, the time between shots, how many to take, and if the sequence is infinite or not.
What this means is that I can set the camera to shoot every [x] seconds or minutes, and for how long, while also keeping my equipment payload to a minimum by excluding any unnecessary hardware. My next step is to test the endurance; how long will it last with a fresh set of batteries.

The Eye: Fanzine development blog #1

After NeonCon 2010, I was taking a greater interest in finding some projects to work on as a way to get my hands dirty with some layout and project management in the gaming industry. I had met Adam Jury of Posthuman Studios, publisher of the acclaimed Eclipse Phase role-playing game, at that convention. I attended a workshop he was presenting, and we had some great discussion over lunch. So a few months later when Adam posted on Twitter that he would love to see a fanzine for Eclipse Phase, my ears perked. I poked around the official forum and found that some enterprising individuals were already rounding up volunteers for the project, spurned on by the same message.

I joined the crew at firewall-darkcast.com, and immediately volunteered to help with the fanzine. They had some contributors to the design discussion, but were lacking any committed layout artists, so I seized that mantle and took control. Through a series of discussions guided by the more detailed sentiment that Jury posted on his blog, we settled on a pdf format that was optimized for quality printing at home or with a print service (the conversation threads that were involved in this process are publicly viewable on the darkcast forum, so I won't hash over their details here). This decision was made because they carry a sense of permanence. Blogs and site-only fanzines are subject to the tragedies of web hosting; site crashes, data loss, and disappearing through lack of use or because the author is no longer interested and takes it down. A single distributable file can be copied, downloaded, shared, and exist somewhere other than the site that hosts it.

My first step was to gather the required metrics including page size, page arrangement, cover type, etc. and then kick out a mock up page of a cover page and a few content pages that covered most of the expected layout options including sidebars, text, frames, images, headers, footers, and other furniture. I also built the beginning of a complete style guide that could later be distributed to any layout artists that took part so we could all maintain similar standards.

Once that was hammered out and posted, I started building master pages in InDesign, solidifying typefaces and paragraph styles for the copy and set up text grids. I set up several layers for each different type of element including text, art, background, sidebars, and headers that would all be used to create a layered pdf. I also started revising a final style guide that detailed page elements, all pieces of the style guides, color profiles, and all of the various optional page elements such as the frames for side bars and hooks.

While all this was in development, fans and contributors were submitting articles and art to the firewall-darkcast, and editors were commenting and cleaning up the content in preparation for layout. I also started a competition to design the masthead image. I provided the group with sizes and specs, and they had a few weeks to turn out a graphic submission that would announce our fanzine. Once all of the submissions were voted on, the final design came from Trentin C. Bergeron (@trechriron). Once the master pages were done, I began to pull the content and flow it onto the pages, formatting as I went, and pulling the different pieces to their respective layer. Images went in where I had them available, or were requested from the team. As the process continued I made tweaks to the style where I saw things that didn't quite work.

This was initially planned as a quarterly magazine, so there was no rush to a deadline; there was plenty of time to get things on the page and tease it all until it fit and looked fairly good. After all was said and done, I packed off the layered pdf to the dropbox and we posted it. We still had a challenge with generating buzz and site traffic, but we realized that this is a fairly focused demographic that we are shooting at, so we can't expect miracles.

The first issue can be downloaded here.

An open question...

Simply put...

"If you were playing a card/board game about being a diabolical cultist bent on raising one of the Great Old Ones from the depths of the cosmos before another cult does, what would make the experience fun?"

 It's a wide open question, as it is intended to be. I look forward to your responses!

Game Development Journal #2

I recently had a great discussion with friends that have a heavy interest in games and design. One of the topics that came up was the mechanical issue I outlined in a previous post. They gave me some alternate views on the subject, and pointed out areas that I was thinking too aggressviely. I think I now have direction on a workable solution that keeps everyone involved but still puts that tension in the hands of the players, and gives them not one, but two countdown clocks driven by the cards. Just to make them feel warm and all.

The first thing I have done is abandoned the idea of turning any of the players into a collective force against any others. I still like the idea, but it does not seem workable in this case. I may try to build something around that later; a tide that rises as those you fought with join the ranks against you. A zombie apocalypse theme sounds right for that, because we just don't have enough proper zombie games, right?

So what I'm left with is that, although each player is pursuing an independent goal, there is a mechanically driven endgame countdown, as well as a rising threat built into the main draw deck similar to what is used in Pandemic.

With some of those key elements thought out, I am turning to building the various mechanics starting with common and shared resources before getting into the various pieces that will support varied ways to win.

A big thanks to Ben the Game Designer and Dan for hanging around until after 2am and sharing their thoughts.

Adding horizontal/vertical borders to an Excel range selection

I'm cracking my head against another piece of Excel's AppleScript enabled functions.

What I seek to do is turn this












into this













This is part of a larger script and I need to add borders to every cell in the used range. I am really pulling my hair out trying to track down exactly where Excel assigns this property and how to address it's parent object. So far all I have managed to do is add a border around an entire range using...get this...the border around call, but I cannot seem to hit all the horizontal and vertical borders in-between cells.

Does anyone out there have a snippet of code that can handle this succinctly?

[Stratos Burst] Hacking the camera #1

First off, there is a LOT of technical information available on the CHDK wiki, the firmware hack that unlocks many more functions for your camera than might normally be available. I invite you to read as much of it as you can stand, but to shortcut right to the easiest and most direct method for my A480:

I have made a simple text file that is renamed "ver.req",  and copied it to an SD card that I put into the camera. This allows me to access more detailed version information and retrieve the cameras actual firmware version information. With that nugget, I can download the proper firmware hack version from the Autobuild Download site. This information will be useful later.

The site suggests using Card Tricks, downloaded from this forum thread, and it looks like it should be the most reliable way to set up the SD card. Card Tricks didn't like the SD card that I had on hand, though, so I  downloaded the firmware zip file, unpacked it straight into the SD, and loaded it into the camera. By starting the camera in playback mode, and navigating the menu to the Firmware Update command, I can load the CHDK firmware, which will access the intervalometer script later. This seemed to work, and I could have saved myself a lot of time by just trying that first.

Game Development journal #1

So I have an new challenge. I am developing concepts for a card game, and one of the more interesting ideas that I have recorded is, if and when a player fails in their own goal during the game, they are not removed from play, but instead turn into a collective threat working against the remaining players. The more players that fail, the bigger the threat grows while the goal of the new enemies gets proportionately harder to keep them from succeeding based solely on numbers.

I also have a side deck that each player can elect to turn a card from on their turn, the effect of which every player might be able to benefit from. But with each turn the players risk aiding another player, failing their own objective or ending the chance of success for another. The benefits would be effective enough to be an incentive to risk it, but as each one is turned, the risk of not only failure, but increasing the collective threat, rises.

The problem I have come to is how to keep the collective goal from becoming just another way to win. If a player fails, they should fail. But it sucks to lose a hand in the middle of a round and have to sit around watching the rest of the players having all the fun. After all, the best games keep the play interesting to the end, right? So the collective goal against the remaining individual players gives the failed players a continued hand in the game, and adds a dynamic layer of tension for the rest. But I do not feel there is enough incentive to do your best in the first part, rather than go for the second goal. More importantly, there is no overall sense of risk.

For now I have pulled that element from the lineup until I can develop a proper way to make it viable in play. I have also turned the side deck into a table-wide countdown clock, after a fashion. A card is turned at the beginning of each round; it still contains the beneficial cards, as well as some drawbacks, but it also has a number of key cards that fill a losing end-game condition for everyone.

AppleScript for Excel development #2

In this post I mentioned that I was working on an AppleScript to handle an Excel process. I decided to abandon the nested line-by-line evaluation of the two necessary columns as this took entirely too long. In this particular process, I have not yet discovered a way to handle a way around this step, but I have taken a different approach to help minimize the cycles spent.

I managed to get the autofill function to script properly. It was a bit fiddly at first, but once you figure out all the syntax, it becomes more agreeable. This allows me to insert a formula in one cell and populate the rest of the column with the same function. By referencing ranges instead of specific cell address', I can assure that my functions always work, regardless of location. The first instance concatenates the values of the two mentioned columns into one cell, making a combined page & reference number.

5_29460
5_29460
5_30012

The next pass sorts the sheet by this column and then inserts another formula that compares each cell to the one above it, looking for a match. Again, autofill populates the column in seconds. When the compare returns true, the cell takes on a specified value. Afterwards, both columns are copied and pasted back in with the values only (Copy & Paste Special: Values).

The compare column is sorted by value and we begin a loop that handles the inevitable line-by-line evaluation. To control this, I included a single Boolean variable as an exit value. The script will cycle through each row and evaluate the cell. If the cell indicates a previously matched row (duplicate), it deletes the row. Once it reaches a unique row, either indicated by an empty string or a second pre-defined value, it switches the Boolean value, triggering the loop escape. This keeps the script from having to evaluate the rows that are already known to be either unique or the first instance of a row.

AppleScript for Excel development #1

I'm currently working on an AppleScript for another department to handle a piece of heavy lifting in Excel. As I might have stated previously, Excel can be a bit obtuse on how to talk to it until you get to know each other. It really helps, wherever possible, to name each column you expect to use as a range and call them by that name in the script using something like

 tell row x of range myRangeName

 end tell

The current project is intended to perform some formatting, column additions and deletions, as well as comparing the values of two different columns and deleting any rows that have duplicate entries. That last part is one of the most time consuming operations so far. The opening approach was to duplicate what was currently being done manually -- concatenate the two compared cells into one value

 =concatenate(A2&"-"&E2)

 result "20-3154"

The entire sheet is then sorted by the column holding that formula and then a loop compares each cell to the cell above it, and if the values match, deletes the duplicate row. This is unfortunately a time consuming process as each cell in the column must be assigned the formula, and then each cell evaluated. In a sheet that can have thousands of records, this process can take 20 to 30 minutes to crunch.

I re-evaluated the needs and decided I could skip the concatenation and just sort the sheet by both columns, and evaluate them in a nested loop of if/then/else blocks. This cuts out a step, but still is not quite as fast as I'd like; perhaps because a good number of the records are evaluated twice, once for the first column, and then by the second if the first proves true.

I am currently evaluating the autofill command to see if the first method might be faster this way, but I'm having a hard time extracting the proper index references from the ranges I have defined. Partly because Excel speaks to the user in one reference style, and to itself in another. (A1 vs R1C1)

[Stratos Burst] Camera and software

In order to continuously capture images during the ascent and the free-fall afterwards, the camera on board will need to use an intervalometer that is programmed to trigger shots automatically. Instead of adding additional equipment that will increase the payload weight, we have elected to use an inexpensive point-and-shoot camera that can be hacked with an open-source script add an intervalometer to the camera features.

The Hack
CHDK is an open source program that can be added to your Canon camera, and introduces a range of features. What we're interested in here is the ability to add custom scripts to the lineup. (CHDK Wiki)


The wiki also provides a list of Canon model numbers that have proven compatible with the update as written. We're using this to narrow the search for an affordable camera.


The Ultra Intervalometer script allows you set the interval to your first shot, the span in between each following shot, and the number of total shots, or just make it endless. This means that so long as the camera has power and memory, it will take shots as often as you tell it to. There will be some calculations done later regarding the expected flight time, memory, approximate size of each image, and interval so we can plan on getting as many shots as possible throughout the flight without running out of memory.

Cost: Free

The Camera

The camera will likely be the largest purchase we could make for this project. The first one that we considered for this was a Canon Ixus 70. We already have one that we have used for several years. The wife has been hinting at wanting a new digital camera anyway, so if something fatal happend to it during the flight (or more likely -- the landing) we wouldn't feel put out by the loss. Unfortunately it uses a NB-4L Lithium-ion rechargeable battery. In this situation that is a deal breaker. We really want to use standard Lithium batteries in all electronics where possible. It gets really cold up at the altitudes we expect to reach, and those temperatures can cause NiCad and Li-ion batteries to shut down. It's unfortunate, but Li-ion batteries are just too weak. We do plan to include a couple of pocket hand warmers in the payload to keep the internal temperature of the insulated container up, but as a redundancy Lithium batteries can tolerate lower operating temperatures.


Next we found a used Canon Powershot A470 on Craigslist for $90. This was local and was on the list of cameras compatible with the necessary firmware hack. Unfortunately it is not listed on the list of tested models that work with the intervalometer script. Now that is not to say that it won't work, but if it did not, I'd be out that cash for this project.


Instead, I have opted for a Powershot A480 which is on both the firmware hack and the script list of verified models. I found a used one on Amazon for approximately the same cost, and it sports 10 megapixel resolution instead of the A470's 7.1 megapixels. This should hopefully lead to sharper images throughout the flight. It is also powered by two AA batteries, which allows the use of off-the-shelf lithium batteries.

Cost: $55.00


Batteries
I picked up a 4-pack of AA lithium batteries. Two will go into the camera on flight day. I expect that the other two will be used as a backup power-source for the prepaid phone that will be used to help us retrieve the payload when it returns to terra firma.


Cost: $11.99 + tax


Edit: Ok, bugger this. The vendor I bought the camera from cannot find it now, so I'll have to look someplace else. Hello, ebay.

Edit: Ok, after a series of lost auctions on ebay, we've managed to secure a "like new" model A480. Now, onward!


Edit: 17 May 2011. For once the USPS managed not to lose something bigger than a letter, and the A480 showed up today. I'll be posting on my progress of hacking it and loading the intervalometer script soon.

AppleScript identifying InDesign hidden characters #2

Back in this post, AppleScript Identifying InDesign Hidden Characters, I outlined an issue with AppleScript picking up meta-characters from InDesign that were causing false results in string evaluations. Posting my problem to the Adobe forum resulted in a couple of less than helpful suggestions that revolved around calling in the robust JavaScript. Thanks for trying, guys, but JavaScript is not the sharpest chisel in my tool box. Also, I still feel this is a bug in the CS5 programming, but I'm not going to waste my time trying to push the issue with Adobe.

I did manage to generate a fix of my own though. I was trying to avoid re-writing the original script and how it was evaluating the content, but I was not left with many options, and I set about adding in a new handler.

Instead of comparing the contents of all of the text frames on a page that share a similar script label against a pre-set list of strings, this handler counts the number of text items in each string in the list. Because the application is recording data from the meta-character, it should have at least one and if any one string in that list contains more, it is considered not empty and returns a corresponding boolean value that is evaluated by the main body of the script. True, execute the contents of the block; false, do nothing. This worked pretty well until I started testing on other templates that are used. Some of the data merge remnants would return three or more text items in what was supposed to be an empty frame! I changed the text item delimiters that AppleScript uses to count those items, but I had to insert a couple of assumptions, the first being that one set of labeled frames would always receive a price containing a decimal, if anything, and the other would always receive a string of text two or more words in length, separated by a space. I dislike doing this because it opens the door for any number of exceptions, but the data sources supported the plan. By re-setting these parameters, the text item count for an empty frame would always return "1", regardless of the number of metacharacters, as they would have no decimals or spaces to separate them.

I also cleaned out the small army of redundant tell statements directed at the application, an assigned variable that was never used in the script, a number of blocks that no longer had a function because of the logic of the new handler, and inserted some detailed documentation regarding the revisions.

A successful update, and a working solution to a satisfying challenge. Now I'm off to script a process on a baleful application, Microsoft Excel.

[Stratos Burst] Because the stratosphere is hella tits!

A few weeks back I came across an article that was posted on wired about MIT students that launched an edge-of-space camera for about $150. Weather balloons launched by classes and individuals is nothing new and there are a number of DIY sites and tools available on the internet. I'm totally going to do this. Not for science or peace, but because I think it is fucking awesome!

Obviously there are considerations to be made; equipment, FAA regulations, legalities, launch and landing planning, etc. I'll be blogging here as I develop what we shall title Project Stratos Burst.

Stay tuned!

AppleScript identifying InDesign hidden characters

This last week I have been updating a script that acts on Adobe InDesign; the update is to move the script from CS4 to CS5. Besides cleaning up the code to remove the small army of redundant tell statements in the original script, the only edits that it needs to function properly are revisions to the syntax in statements that address script labels. This is a common bug for us this time around and is usually one of the first things I look for, and solves 90% of our broken scripts. This particular script has presented greater difficulty and I am a little stumped. After the standard edits have been made, the script runs to completion, but fails to perform any of the intended actions, and I've narrowed it down to the result of an if statement that never returns true. 

The script is intended to pull the content of all text frames on a page that are tagged with a given script label, and compares the result to a variable for a string match. In this case the control variable is

{"","","",""}

The content of the four text frames on the page is compared to this control in an if statement

if pageData is dataCheck then

 so if all four frames are empty, the if statement should return true, and the contained actions will be executed, which it never does. The culprit appears to be a hidden character that is the remnant of a data merge, but I'm at a loss on how to deal with it.

Record Marker (:)
and End Of Story (#)

Prior to the running of this script, the page is generated by executing a data merge within InDesign onto a template document. The script then checks these particular frames for content because sometimes they receive empty strings of data in the merge. Even so, the hidden characters that InDesign uses to mark the beginning and end of a record entry remain.

Most functions typically ignore these, but it seems that InDesign is picking it up in the get contents command, even though in the context of the application, it has no idea what it is or how to address it. It's taken me a couple days to figure this out.

Here is the native AppleScript Editor event log showing it's script command and the return (lines 1-3):
And here is the results of the same command (lines 1-2 above), and the returned list as seen in Script Debugger's event log on AEPrint view:


To translate that into a string view it would look like

{"?","?","?","?"}

AEPrint picks up a bit of data in that string, although it has no idea how to display something that exists only in the context of InDesign as a virtual glyph representing an insertion point. As far as I can tell the character is selectable only through a shift-arrow selection. It can be copy/pasted into into a find/change field but does not return as a result in a text or GREP search.

It is possible to manually remove the record markers from the frame, but this defeats the purpose of using a script as it involves a user touching every affected frame every time a data merge is run. I'd rather not re-write how the script evaluates the content of the frame as the current method is probably the most accurate, but I could attempt to count the characters in the frame and hope that all future merged content is longer than two characters. I need to figure out how to coax AppleScript to allow me to manipulate these hidden-but-existing characters, or otherwise ignore them entirely. Is there an elementary solution here that I'm passing over, making this harder than it should be?

It seems to me, since this script ran well with InDesign CS4, so something might have changed in CS5. Is it possible that hidden characters that were beneath the view of InDesigns other functions are now being included? Or is this an overall bug in the machine?