Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
I'm not sure exactly how your ship building scenario goes, but you could make the buyable/flyable ships have zero armor. Then Gxxx an outfit that gives (at least) a single armor point On Purchase. (So they don't just blow up if the player accidentally takes off). That way, when then player captures a ship as their own (assuming they don't have the option to assign it to their fleet), their old ship will simply "self-destruct". Which could be explained to the player in the capturing dialogue. Of course you'd also have to Gxxx some armor On Capture as well, or they'd just blow up. Just a thought...
------------------ Edited to add: Ok, a quick test reveals (as I'm sure you've already found out) that the AI doesn't take advantage of armor mod types. This would at least eliminate the need to Gxxx anything, just make ships with zero armor and have armor type outfits come stock on the ship.
(This message has been edited by slouch (edited 07-07-2004).)
Slough, perhaps you should read what I actually want. Blowing up ships is not part of it. I'll make it different. As soon as I buy the certain ship, another ship, the modified version becomes available, which costs only the price the upgrade outfit would cost. It's going to cause trouble with trade in money, but I can at least almost compensate it, considering the player won't have too many precious outfits that raise it much. And if s/he has, well, lucky him/her. As a downgrade, I make a ship worth 0 cr, so the player gets the money for the outfits he'll loose. It's not as elegant as I wished it, but it'll at least work and it's not too complicated. And I remain under full control. The only problem is that the player'll loose outfits but I can compensate this, too, considering s/he usually buys sensor equipment, afterburner and perhaps solar cells.
------------------ It is interesting that well-protected secrets and complicated puzzles are often solved faster than easy ones. Why? Because the better a secret is protected and the more complicated a puzzle is, the more thinkers it attracts. - me (url="http://"http://starlightdev.freewebpage.org")STARLIGHT DEVELOPMENT(/url)
(This message has been edited by Arion (edited 07-07-2004).)
Apologies... I was reponding to Masamune's post, I should have made that clear.
------------------
Edit: Ok, I'll get back on track here, Arion.
Use the Cxxx operator in the On Buy field of the outfit you want to trigger the change. This operator allows the player to keep all of their outfits. To make sure that the outfit only appears in the outfitter when the player has the appropriate ship, you need to give the first version of the ship a unique contribute bit. The outfit would have to have the same bit flagged in it's require field. If you want to make the item sellable, you'd need to Cxxx the player back into first version of the ship On Sell.
Make a second non-buyable ship resource for your modified ship. Give it the same stats as the original, except don't give it any default weapons or outfits. If the cost of the two versions of the ship are the same, you don't have to worry about trade in value at all.
Slouch: That would, indeed, prevent the player from assigning the ship to his fleet. However, the much, much easier way of doing it is to simply go into the DLOG/DITL resources for the "What do you want to do with this ship?" dialog, and remove the option button to "Assign to fleet". Believe me- this works, and I wouldn't have to explain anything! Matt- don't you dare change this.
As it stands, I will have to explain why your old ship goes dead in the water, so to speak, but I still want the player to be able to sell his old ship.
HOWEVER, your example has given me an idea to circumvent the dead in the water problem! I could give all the ships a default speed (instead of the current 0), and Gxxx an outfit that takes it away- so when the AI gets ahold of the ship, it ignores the penalty, and your ship can still move around! Way to go, slouch! Hell, if I wanted to blow an outfit for every ship (and variant), I could cut the number of ships I need from 3 per ship type (2 for variants) down to 2... Hmm... Might even avoid the problem of assigning to the fleet altogether... I'll have to investigate and think. Lots of thinking.
------------------ ~Charlie Sephil Saga Homepage: (url="http://"http://www.cwssoftware.com")www.cwssoftware.com(/url)
Slough: this is exactly the idea I had at the beginning. There's only one problem, though: it won't let me change the upgraded ship back to the original version. The bits are not evaluated when Cxxx is used. And if you ask me now why to downgrade the ship, well, when I can upgrade it, I can also downgrade it. Otherwise it would not be flexible. And the player would use the downgrade if s/he needs money. Hm... but I could do something different That's an idea! Why didn't I come to that earlier? Not the ship activates the downgrade outfit, but the upgrade outfit does! I'll put the bit into the OnPurchase field of the outfit, not the ship. And at the same time, the bit makes the upgrade outfit disappear. That's the solution! Ship 1 (shďp): On Purchase (set): bxxx Upgrade (oütf): On Purchase (set): Cxxx & byyy & !bxxx Availability (test): bxxx & !byyy Downgrade (oütf): On Purchase (set): Cyyy & bxxx & !byyy Availability (test): byyy & !bxxx That should work, don't you think?
I guess my question is: what prevents the player from purchasing the upgrade outfit if they are not in the correct ship?
This is where the above discussion got a bit sidetracked. If I'm interpreting this correctly:
Ship 1 (shďp): On Purchase (set): bxxx
... means that you want to set an NCB when the player purchases the ship, and this is what will indicate that the player is in the correct ship to get the appropriate upgrade. Some problems associated with this method:
Quote
Originally posted by Arturo: 1. A captured shďp that players take as their own does not execute the shďp resource OnPurchase(set). 2. The shďp OnRetire(set) is only executed when a shďp is traded-in, but not when it is destroyed or when the player takes over a different captured shďp type. 3. The shďp OnCapture(set) is executed regardless of whether the players take the captured ship as their own or use it as an escort.
Basically, NCB's will not accurately keep track of the player's ship. Instead of setting a bit On Purchase, set a unique Contribute bit flag in the ship resource. Set the corresponding bit in the Require field of the upgrade outfit. So, all that would be needed is: Ship 1 (shďp): (ship 1 =yyy) On Purchase (set): Contribute:0x0000000000000001
Upgrade (oütf): Availability (test): Require:0x0000000000000001 On Purchase (set): Cxxx On Sell (set): Cyyy
(This message has been edited by slouch (edited 07-09-2004).)
There's another precaution to keep in mind as well. Unless you're developing a TC, one must take care not to "step" on any of the default scenario Contribute-Require bits, just as you need to be careful of default scenario NCBs and RIDs. The Nova scenario uses the following C-R bit positions:
Contribute-Require0 0x000001FF (used by license oütfs and ränks) Contribute-Require1 0xC0000071 (used to indicate possession of a physical ship and several ship classes)
Using any of those C-R bits in a plug for the default scenario will definitely mess things up. That still leaves 48 C-R bits that are unused by the default scenario. The next thing that may appear to be a problem is that with only 48 bits you may think you can only handle 48 different shďps. Not true. By creating groups of C-R bits one can easily handle every ship in the default scenario and then some. I used only 36 of those C-R bits to accomodate up to 1536 different shďps in my ShipyardUpgrades plug. I used 8 bits to define functional types (carrier, destroyer, fighter, freighter, etc.), then another 12 bits to specify the ship's class (AuroranCarrier, FederationCarrier, PirateCarrier, etc.) and finally 16 bits (dictated by the Abomination that has the most variants) to account for the variants in each shďp class. That way no two shďps can possibly have the exact same bit patterns, which would be the case if one tried to used the C-R bits to represent a number.
My mistake, I forgot the OnSell (set) bits of the ships. I won't use contributes because I hate this checkbox-cluster. And I won't make the Upgrade Outfit give the old ship back on sell because I want a different dësc for the downgrade and I don't want it to be shown in the player info. I'll check the remove after purchase flag. The capture stuff: There are effectively five ships that can be upgraded/downgraded. Courier <-> Armed Courier Almost unarmed and most everything is better than it, even when it is the armed version. So why buy an upgrade, even for cheating. Comet (Freighter) <-> Tempest (P. Cruiser) Getting a Tempest will most likely bring your own government against you (you can buy them, but there's a trick behind it). If the player wants to cheat, s/he'll find out soon that it is no good. BTW, you can't capture a Tempest, as it has almost twice as much crew members than the largest Terran ship you can buy in the beginning (Destroyer). Destroyer <-> Cruiser Boarding one of these ships is difficult, taking them over even more. And it will bring up your own gövt against you. Fighter <-> P. Fighter See above and for P. Fighter, see Tempest. Absis <-> P. Absis Again, see above and Tempest. So, should the player make the decision to cheat that way, s/he'll soon find out it was a big mistake. Anyway, boarding most of these ships will bring the only government against you where you can actually buy these upgrades. And their planets don't take bribes.
The trouble is, Nova will under many circumstances 'lose track' of what ship the player is flying. Because of the way many of the set fields are executed, it is entirely possible (if not probable) that a player will have an NCB set that allows them to purchase the upgrade outfit when they aren't supposed to. It's not really a matter of cheating, it's just buying what is available to them.
For example: Player buys the Courier. An NCB is set which makes the upgrade outfit available for that ship type.
Player captures a shuttle (or the equivalent in your plug-in). Player hates the shuttle. The upgrade outfit NCB is NOT cleared.
Player buys a big slow cargo ship. Converts as much space as they can to mass. Player fully outfits said big slow cargo ship.
Player buys the 'Armed Courier' upgrade outfit that they aren't supposed to have access to. Player is Cxxx-ed into the Armed Courier, but they keep all of the outfits they had on the overloaded cargo ship. They now have a ship which is way more powerful than it was meant to be.
From all of the great artwork of yours that I've seen in the Image Gallery, I'm guessing that you are working on a TC. I would suggest that learning to deal with the Contribute/Require fields is probably in your best interest. Just a suggestion...
(This message has been edited by slouch (edited 07-10-2004).)
Double-posting for emphasis
You know what, Arion? Ignore my last post. That situation will not occur so long as the ship's On Retire field unsets the proper bit. I just did some testing myself, (previously, I had been taking someone else's word at face value), and found that On Retire is evaluated when a ship is destroyed and when capturing another ship and using it as your own. I feel like an ass, I should have tested this in the first place. Sorry for confusing you.
However, the issue with the On Purchase set string not being evaluated when the player captures the ship still stands. If what you said above is ok for your scenario, then go for it.
Originally posted by slouch: **Double-posting for emphasis
However, the issue with the On Purchase set string not being evaluated when the player captures the ship still stands. If what you said above is ok for your scenario, then go for it. **
Slouch (and everybody else) I'm really sorry about that. I apologize for not retesting that myself before posting. I've just gone through and tested OnRetire(set) for all EV:Nova (Mac) game-engine versions from 1.0.1 through 1.0.8 and the OnRetire(set) works for all versions on ship self-destruction. I'm still testing destruction by other ships, which is taking a little bit longer. Then I will run through captures on all game-emgine versions, which will take longer still. I don't know yet how I came to the erroneous OnRetire(set) conclusion, but I just wanted to post my apology ASAP. I will also go edit my other post on this subject in an attempt to keep confusion to a minimum. Sorry folks.
Wow! You're a real integrated compatibility lab!
------------------ The (url="http://"https://secure.ambrosiasw.com/cgi-bin/store/hazel.cgi?action=serve&item;=breakdown.html&BREAKDOWN;_SKUID=1480")Ambrosia Mac CD(/url) with other registrations - 5$. Paying for (url="http://"http://www.ambrosiasw.com/games/evn/")EV Nova(/url) as it's such a great game - 30$. The (url="http://"http://www.ambrosiasw.com/games/evn/tshirts.html")1337 EV Nova T-shirt(/url)(url="http://"http://www.ambrosiasw.com/webboard/Forum25/HTML/000003.html#ZachaPedro05-18-200409:42AM") (/url) - 22$. The (url="http://"http://w00tware.ev-nova.net/")NovaTools(/url) by wOOtWare to tinker with your Nova - FREE! The feeling you're a Nova geek - priceless. There are things money can't buy or that are free, for everything else, there's indeed Mastercard.
Thanks guys. I'll do it that way now, let's see if it works.