From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27425 invoked by alias); 22 Aug 2004 05:54:47 -0000 Mailing-List: contact xconq7-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: xconq7-owner@sources.redhat.com Received: (qmail 27417 invoked from network); 22 Aug 2004 05:54:46 -0000 Received: from unknown (HELO web13123.mail.yahoo.com) (216.136.174.141) by sourceware.org with SMTP; 22 Aug 2004 05:54:46 -0000 Message-ID: <20040822055446.98854.qmail@web13123.mail.yahoo.com> Received: from [67.170.222.55] by web13123.mail.yahoo.com via HTTP; Sat, 21 Aug 2004 22:54:46 PDT Date: Sun, 22 Aug 2004 06:38:00 -0000 From: Elijah Meeks Subject: Item Units To: xconq7@sources.redhat.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004/txt/msg00988.txt.bz2 (Figured it deserved it's own thread) Eric, you'd mentioned additional tables and we've talked about the cow patties. It seems like the framework's in place for items, just add a fifth entry to the ferry-on-entry/departure tables that's "Full" (Or something similar). I'd thought, when I first worked with items as occupants, that "over-all" would've worked, but it didn't. "Full" would mean that the transport paid all necessary ACP costs for the occupant to move into the hex and load onto the unit. Problems: The AI, of course, would likely not get that these units were useful, and would probably pick them up and drop them at random. An initial workaround would be to set the ferry-on-entry to "Full" and the ferry-on-departure to over-nothing, which means that once the AI orders a legitimate unit to pick up an item, it's stuck with it. Not the best solution, of course, but it would work. I'd like to introduce three item types in Opal: Weapon, Armor and Gear. They'd come in two flavors, fine and magical. So far, so good (Heck, only six new units, I'll never reach 1000 like this). But we've all seen how a unit looks with three occupants, especially when it occupies a cell with another unit or two. Without an occupant dialog box, it'd just be too cluttered. Building each magic sword by hand is also a pain. So I'd love to see initial-occupant and occupant-when-created tables that call for, in the case of the former, a unit placed with said occupant and, in the case of the latter, an extra build to produce, if the builder is able, the additional occupants. The tables would be percentage based, especially useful with the initial-occupant table, because then some of your swordsmen might start with fine weapons or magic armor, adding a little randomness to the game. If the percentage is higher than 100, it would indicate more than one occupant, so that, say, a huge city could be set at: (initial-occupant (hugecity magicsword 350) ) And would always start with three magic swords with a 50% chance of a fourth. Tablewise, occupant-adds-hit-chance/fire-hit-chance, occupant-adds-acp, occupant-adds-damage and occupant-adds-hp would be a great start. And neural nets, and 3D units, and a fully 3D globe, and XBox support, and and and... _______________________________ Do you Yahoo!? Win 1 of 4,000 free domain names from Yahoo! Enter now. http://promotions.yahoo.com/goldrush