Ambrosia Garden Archive
    • NebuchadnezzaR, on Nov 2 2005, 01:04 PM, said:

      Am I right in understanding that the behavior is, with one weapon selected, it is a normal fighter, and with another it could be a missile? So you could have "Fighter X" weapon and "X: Kamikaze" that would behave as you would expect?View Post

      Correct. That would actually work out to be a nice variation on the "fighter-type swapping" trick: fighters, or kamikazes?

      Guy, on Nov 2 2005, 07:02 PM, said:

      So... you buy the fighters, and when you abort the mission it swaps all the As you have on board for Bs. And the way to swap them back is by launching them and recalling them? That's really weird. Also it only works once between takeoffs. Ie, I abort and switch to Bs, launch them, recall them as As, and then abort again but don't switch to Bs again until I land and takeoff again. Maybe something to do with the cron bug with setting duration pre and post all to 0.View Post

      Hmm... Looks like I need to tweak it a bit more. That swapping back by recalling was unintentional, and is probably because both bays actually use the same ship. :rolleyes: (There wasn't supposed to be any way to switch back.)
      The once-only per launch may be because of the 0-0-0 problem, or it may be because I forgot to reset bit 127 at some point. Still, looks like I did fairly well for half an hour's work.

      Desprez, on Nov 2 2005, 07:28 PM, said:

      Well the fighter bay would HAVE to come with the fighters otherwise you can keep swapping and buying them. Doing it that way solves the problem of being able to buy too many fighters. I'd have to do it so that each bay comes with 1 fighter max so that you can replenish your fighters by selling off the bay and repurchasing it.View Post

      Check the Cool Nova Hacks thread- particularly the multiple ammos for one weapon trick. It should be possible to invert it. Adding in the bay-swapping should also work, although you'll start going through free Require bits very quickly.

      Edwards

    • Edwards, on Nov 3 2005, 07:40 PM, said:

      Hmm... Looks like I need to tweak it a bit more. That swapping back by recalling was unintentional, and is probably because both bays actually use the same ship. :rolleyes: (There wasn't supposed to be any way to switch back.)
      The once-only per launch may be because of the 0-0-0 problem, or it may be because I forgot to reset bit 127 at some point. Still, looks like I did fairly well for half an hour's work.
      View Post

      Yeah, it is pretty cool it just confused me a bit at first. Maybe you can come up with some kind of excuse as to why it only works once.

      Edwards, on Nov 3 2005, 07:40 PM, said:

      Check the Cool Nova Hacks thread- particularly the multiple ammos for one weapon trick. It should be possible to invert it. Adding in the bay-swapping should also work, although you'll start going through free Require bits very quickly.

      Edwards
      View Post

      The only unfortunate thing about that is that it doesn't work for fighters. Argh! Fighters is what I thought it would be most useful for.

      Maybe if you change it to use require bits...

      This post has been edited by Guy : 03 November 2005 - 01:50 AM

    • Guy, on Nov 3 2005, 03:03 AM, said:

      Why not just make the fighters have like 1 armour or something?

      It doesn't work with the rest of the universe too well...

      Quote

      Okay, so let's have 5 missions.
      Missions A and B are the ones you want to start depending on the state of bxxx.
      Missions C and D will be used as a substitute for bxxx. Mission C will be activated when you start the game. In its OnAbort it will have sA sC. Mission D's OnAbort will have sB sD.
      Now whenever you change bxxx you should instead put fC sD to set it or fD sC to clear it. So mission D being active is equivalent to bxxx being set, and mission C being active is equivalent to bxxx being clear.
      Mission E is the one you abort manually. In its OnAbort put aC aD. So if mission C is active (ie, bxxx is set) then it will get aborted which will start mission A and also mission C again. Else if mission D is active then it will get aborted which will start mission B and also mission D again.
      View Post

      Damn that's nice!

      Now can I do something similar with require and contribute? The above will help in a lot of situations.
      But in the case of the fighters, the only way to tell if you have at least one of any various versions docked is through the contribute bits, unless i'm mistaken.

      How can I get that to work on an OnAbort?
      IF contribute1 is true {Sxxx else Syyy}
      ---
      I did manage to solve the fighter problem on the ground. And it is robust in that the player can't break or cheat it.
      Even better, I maganged to swap loadout in flight through a pers mission. However, the pers mission wasn't very robust in that you could gain extra fighters.

      I had it set up so that the mission to make an interceptor into a bomber only available if you had an interceptor in a bay (contribute bit)
      The pers would know if you had fighters available to convert but the problem was that if you launched or recalled after the initial contact, he couldn't keep up with the changes.

      Also the pers only offers one mission and I need two. One go from interceptor > bomber and the other to go back. And I'm having trouble getting two pers to always appear.
      ---
      Anyway here is the map of the outfits on the ground.

      Fighter Loadout Variants
      This will simulate a bay that holds up to 4 fighters - with each fighter being able to change between 2 different variants when at a port with an outtfitter, and still have the option of only buying new fighters where you want them to be available. Plus, it remains consistant to any cost and weight mechanics you may have set up.

      #1 Fighter Bay This is really for cosmetics and cost consistancy - the overhead required to run the place, cost and mass. The real bays (weaps) need to be cheaper and closer to the cost of the fighters themselves the way they are being used in this. This is really a featureless weapon with max ammmo of 4 and #2 is the ammo.

      #2 Fighter Loadout Area This is actually ammo for #1 but when you punchase these they also Gxxx an actuall fighter bay #3 and a Fighter #5. This makes it so that you can't sell the Fighter Bay without selling the Loadout Areas first, and also sets up max 4 areas per bay. Cannot sell these. Cost this appropriate for the cost of a fighter.

      Edit: Actually, now that I think about it, this also solves a different problem too. I always though it would be nice to be able to customize the size of the bay based on how many fighters you bought for it without making multiple sized versions of the same bay. The problem was that if you give fighters mass as a limitation, you can launch them to free up more mass. This way we can give the loadout area the mass, and you can't launch that.

      #3 Fighter Bay (Interceptor) Invisible outfit. This gets placed by #2, it is the outfit associated with the weap for launching the interceptor variant. Max ammo of 1. (You will have a launcher for each fighter.)

      #4 Fighter Bay (Bomber) Invisible outfit. Gets placed upon swaping, see below. It is the outfit associated with the weap for launching the bomber variant. Max ammo of 1.

      #5 Fighter (Interceptor Loadout) Cannot buy. Available everywhere. Ammo for #3. Gets placed initially by purchasing #2. Selling this will Gxxx #6, and also Dxxx #3 and Gxxx #4. The sell mechanic works funny here, but it is the only way to insure that the player has a fighter to swap. We swap out a copy of the launchers here as well, so that the player can't pick up disabled fighters unless he has lost one. Sets a contribute bit A.

      #6 Fighter (Bomber Loadout) Cannot buy. Available everywhere. Ammo for #4. Gets placed by selling #5. Sell this and it Gxxx #5 Dxxx #4 Gxxx #3. Similar to above. Note that the player doesn't see the launchers themselves swapping, because the Loadout Area #2 doesn't change it's tally. It shows the totall number of fighters you have and the Loadouts #5-6 show the breakdown of what kind of fighters you have. You can swap #5-6 indefinately at cost 0, as long as you have a fighter in a bay to convert. Though, I suppose you could add a re-tooling fee if you want. Sets a contribut bit B.

      You can't ever get too many fighters because you can only purchase them by buying #2 the Loadout Area, and you can only have 4 per Fighter Bay. You can't capture fighters unless you have lost one first because you have 1 launcher per fighter.

      Those are the components. The next three are tools to use since we co-opted the sell buttons.

      #7 Sell an Interceptor These sell something when you "purchase" them. This will sell one copy of a #2 #3 #5 but you can only do this if there happens to be a #5 available (require bit A check). It also runs a mission to give you some credits back for the fighter. It also removes itself.

      #8 Sell a Bomber Works like #7 but Dxxx #2 #4 #6. Require bit B check.

      #9 Remove Empty Loading Areas Is only available to use if you have no fighters at all. (regardless of docked or not) After a battle you may have lost some fighters. The only way to replenish them is to re-buy #2 Loadout Area. You can't do that if you are already maxed out. And you can't sell a #5 or #6 unless you have a corresponding fighter. (All that is necessary to keep the system robust.) So you first sell what you can and get credit back, and then use this to "reformat" the inside of your bay. It Dxxx every copy of everything except #1 (though when this is available it means you only have residual launchers and loading areas. No fighters hiding in orbit!)

      The only unusuall part is having to buy certian items to sell, and selling some items to convert. But I think with clear instructions in the outfit descriptions that won't be too bad.

      As pointed out earlier, it should be straight forward to have more variants, larger or smaller bays, etc. Just keep 1 launcher for every fighter. And you only need 1 contribute bit per variant. Though You need 9 outfits, a mission (to get money on selling), and a weapon for every variant + 1. But this works the same regardles of the number of fighters the bay is to hold.

      Now all I have to do is get the swaps working in flight!

      This post has been edited by Desprez : 03 November 2005 - 02:37 AM

    • Heh. Actually, forget all that.
      It works well enough, but I found a better way to do it. And it looks better to the player too.

      I'll provide a download as soon as I clean up the plug-in.

      First off, I always felt that it would be neat to simply have one big bay that could hold all of your fighters regardless of composition. (I also decided to use cargo space for most of the bay, but that's an arbitrary decision on my part. You could just use mass if you want. But heck, there doesn't seem to be any reason why the cargo holds wouldn't work as a hanger)

      Then, I combined that with the loadout options from before.
      The bay doesn't have a preset ammount of fighters it can hold, (the fighters themselves have space requirements) just think of it as overhead space required. Including maintenance areas and command centers. The thing is, that those kind of things your going to need pretty much regardless of whether you have 4 fighters or 16. Your going to need one maintenance area, but not 16 of them. Once the overhead is laid out, you can keep stuffing fighters in until you run out of space.

      In otherwords, you get more space savings in bulk. This kind of concept is reflected in the design.

      I'll describe how it appears to the player...

      You buy the main bay. It takes up a non-trivial ammount of cargo space for overhead, plus some mass space for command centers and such.
      Then you can buy outfits that represent different fighters, and the fighter types can all have different ammout of cost and mass (these fit in your cargo space also)
      Once you have a fighter of a particular type, you can change around it's loadout buy "selling" as in my previous post.
      Then if you want to sell it, you purchase a "sell" outfit, that gives you credits back.

      The outfit screen will show the main bay, plus for every fighter type, you have a "Buy fighter"(also acts as a runnig total of that fighter type) a "Sell fighter" and an outfit for each loadout option that also tracks the subtotals of the different loadouts.)
      For a fighter type with 3 variants, you would see 5 outfits + the main bay.

      For a bay that currently holds 3 different fighter types, two of which have 3 variants, and one that has 2, you would see 14+1 outfits to manipulate them.

      These are fighter types, not individual fighters. That second example wouldn't change whether you had 3 or 300 fighters.

      (This is with the outfits not "jumping around" with changing availability. If jumping isn't a concern for you, the currently unused variants could hide themselves. As it is, the are outfits that will swap places with each other, but they have the same name so you don't notice. There's actually a sell button for each fighter variant, but you only need to see one at a time.)

      This works very nice, and I haven't figured out how to break or abuse it yet.

      Behind the scenes resourse wise, the main bay takes 2 outfits, 1 weapon, and 1 require bit.
      then every fighter type uses: 2 outfits + 3 per variant, + 1 weapon per variant, + 1 require bit per variant, + 1 mission.

      (Though, if you have a fighter type that only have one state I think you can get away with 2 outfits + 1 weapon. But I have to check to see how that integrates with the rest of the bay.)

      So the previous example would take:
      30 outfits, 9 weapons, 9 require bits, 3 missions.

      The require bits are going to be the limiting factor I think.

      So there you go, a universal bay with the ability to mix and match fighters, and load different weapons on your existing fighters when you land.

      Proof of concept forthcoming!

      This post has been edited by Desprez : 03 November 2005 - 11:37 AM

    • That sounds pretty cool, can't wait to try it out. I hope you stick around here, Desprez, we can always use another smart mind 😉

    • Guy, on Nov 3 2005, 10:22 PM, said:

      That sounds pretty cool, can't wait to try it out. I hope you stick around here, Desprez, we can always use another smart mind 😉
      View Post

      Well according to my account here, I've been regestered since 2000. But I'll be damned if I can remember that.
      When I attempted to register a few days ago, I was suprised to have my screen name taken. So I made a different one. When I clicked the sent link to activate the new account, suddenly it logged me in under this older account.
      Very strange.

    • Couldn't you just use Edwards's method and have his "Abortme" mission Sxxx itself OnAbort, so you can switch to bombers through the mission and back to fighters through recalling them, indefinitely? Obviously this burns one of your 16 active mission slots, but them's the breaks.

    • NebuchadnezzaR, on Nov 2 2005, 10:38 PM, said:

      As for the mission staying with you, make sure the CanAbort flag is checked. This flag decides if the mission dissapears instantly or if it gets that bullet in front of it. Only if you land with a bullet on the destStell do you ever get the Failtext (to veer off topic).

      But yeah, checking canabort will make Fxxx cause the mission to dissapear instantly.
      View Post

      I'm doing that right now, and that's not the behavior I'm seeing.
      Even with the CanAbort flag checked, the mission just gets the bullet on fail, and sits there in the active missions box.
      I just tried it both with and without the flag, and it doesn't dissapear.
      I even tried landing on a planet and checking to see if it would go away. No dice.

      You're getting different behavior on your machine?

    • Qaanol, on Nov 4 2005, 12:12 AM, said:

      Couldn't you just use Edwards's method and have his "Abortme" mission Sxxx itself OnAbort, so you can switch to bombers through the mission and back to fighters through recalling them, indefinitely? Obviously this burns one of your 16 active mission slots, but them's the breaks.
      View Post

      Well, unless i'm missing something, that method didn't seem to work.

      It doesn't prevent abuse, for one.
      Looking at the resource, you get a fighter B for every Bay A you purchase.
      Ok, so you buy some fighter As, then use the mission to change them to B's and suddenly you have more fighter Bs than you had fighter As. ??
      (Perhaps it was supposed to add a Bay B instead? But this leads to the basic problem controling capacity from before.)

      The crux difficulty of this problem isn't switching them. The problem comes in preventing the player from gaining fighters he shouldn't be able to get.

      You can't control them by mass.
      This is because the player can launch them and free up mass, then go buy more fighters. Repeat indefinately.

      If you use the weapon's max ammo property, then you can no longer use the multiple-ammo-for one-weapon-trick.
      When you change the fighter to the new type you are basically Dxxx and Gxxx somehow. This won't check for ammo limits. The upshot is that the player maxes out a fighter then switches them to the other type. Now he can go and fill up on the first fighter again, then switch them again, overloading the max. Repeat indefinately.

      This is compounded by the fact that you can capture disabled fighters and hold them in the alternate launchers.

      Furthermore, there is an additional problem.
      You can tell if you have at least one fighter on board using require bits.
      You can tell if you have at least one fighter (regardless of location -bay, or space) using Oxxx.
      But there's no exclusinve tool to detect if fighters you own are in space.
      Therefore, you CAN'T tell if there are fighters in space IF you have even a single fighter on board.

      This means that it is very hard to check for limits when you have multiple weapons representing a single bay.

      An abortable mission doesn't work because the conditions of setting up the mission may be different when it executes.
      (Edwards cron (test) was a pretty good soultion to dealing with changing conditions, but the more I dwell on this problem, the more it seems like abortable missions will easily max out the simutaneous mission for only just a few fighter types.)

      In the soon-to-be-ready example I have 3 fighters with 7 variants among them. Using abortortable missions for this would take up 7 of 16 places!

      Swaping in flight for MANY fighters and variants is as good as dead, I think.

      But the problem to do it on the ground is solved.

      As you'll shortly see, I'm using something OTHER than the fighters to count them. It looks like controlling them by mass, except it is not the fighters themselves that have the mass. (so you can't abuse it by launching them)
      The tradeoff, is that it is somewhat convoluted when you need to replace a destroyed fighter.
      How do you check to tell whether it's actually destroyed, and not merely in orbit? See the logic above.

      So it has to be that you have to sell all fighters of a particular type, so Nova can detect that you have no more fighters (Oxxx) and then knows it's safe to remove the reserved space.
      -----
      Ok, as I was typing this I have a possible idea with abortable missions.
      Maybe I can set up an "abortable mission menu system!" What I mean is that only 1 mission is needed per carried fighter type. you abort it, and then it Sxxx a mission for each variant option for only that fighter.
      Aborting one of these will run an in-flight advancement to trigger a cron that can detect if there is still an appropriate fighter available in the bay. Then those missions collapse back in to the original.
      Better than running them all at once, but it will still need a bunch of mission space to run. Hmmm.

      Well, there's still the problem I mentioned last post about Fxxx aparently not deleting the mission under any circumastance.

      This post has been edited by Desprez : 04 November 2005 - 07:08 AM

    • Desprez, on Nov 2 2005, 05:37 AM, said:

      • Commands you can prefom mid battle, like:
      "more power to the shileds!" (drains fuel and recharges shields for a short time), or
      "switching to auxiliary power" (consumes an item to regenerate fuel for a time) or
      "rerouting power from navigation" (quickly regenerates fuel but reduces accel, speed, visuals, radar until you can land for repairs)

      (Most of the above is accomplished by pulling up the active mission box and "aborting" a mission to activate a particular effect.)

      I soooooo want to steal this idea for SFA. Especially since you can now only take one Ready Room (Mission Board) mission at a time.

      I won't, but man, do I want to. Great ideas, Desprez

    • UncleTwitchy, on Nov 4 2005, 12:19 PM, said:

      I soooooo want to steal this idea for SFA. Especially since you can now only take one Ready Room (Mission Board) mission at a time.

      I won't, but man, do I want to. Great ideas, Desprez
      View Post

      Take 'em if you want. Why not?
      If you feel guilty, I suppose you could always throw a thanks inthe somewhere.

      -----
      Back to the other issue.
      I just tried putting a function similar to Edwards tecnique into what I had so far.

      Suprisingly, it turns out that the require bits don't always properly update when in space.
      Specificaly, if a fighter is in the bay when the require bit is checked. It detects correctly, but it won't get re-checked again later, even if you launch the fighter. It gets stuck in the initial state until... when you land maybe?

      So I can't use require bits for in space swaping.

      This is very dissapointing.

    • Ok, I'm just about ready to post an example plug.

      But somewhere along the line I did something that every time a weapon fires, the game will momentairly run at 2x speed.

      I tested, and this only happens with this plug, when running with AbsoluteMinimum.

      What would do this? And how do I fix it?

      This post has been edited by Desprez : 04 November 2005 - 05:07 PM

    • Strangely enough, it's also come up in another project using Absolute Minimum. If you can work out what causes it, then remember- It's not a bug, it's a feature 😉

    • Ok, here is a proof-of-concept example.

      Use this plug with the regular game installed. Don't use AbsoluteMinimum.

      If you create a new pilot you should be given an empty carrier to work with. Land on the planet and you should see instructions there, and in the outfitters.

      I also included a couple bonus weapons for you to play with. And a few targets in space so you can see how things work.

      Fighter_Loadouts_v1.zip (472 KB)

      Edit: Here is a more developed version: See this post for context
      Fighter Loadouts v3.2 (581 KB)
      Edit: Now updated for EVN 1.0.9

      Comments welcome!

      This post has been edited by Desprez : 12 March 2006 - 07:04 PM

    • Desprez, on Nov 4 2005, 05:07 AM, said:

      Looking at the resource, you get a fighter B for every Bay A you purchase.View Post

      That's a remenant from an earlier version that I forgot to remove. Serves me right for not spending an extra half-hour de-worming the plug.

      Desprez, on Nov 4 2005, 07:48 AM, said:

      But somewhere along the line I did something that every time a weapon fires, the game will momentairly run at 2x speed.View Post

      I'm pretty sure that the problem is caused by the formatting of the sound resources- something about them causes the game to run at 2X for as long as the sound is playing. It could actually be useful if you looped the sound- forced double-speed battles...

      Oh, and don't use MacOS X's built-in archiving function. It has a fancy way of storing resource forks that can't be read on Windows, and is difficult to read on any Mac OS prior to 10.3. Try Guy's Plug-in Archiver instead (you'll need to do a bit of set-up, but it can pack plug-ins in the easily-read .bin.zip format).
      Also, that file size may give you a clue as to why most of us use AbsoluteMinimum for demo plugs- it may be a bit of a pain to convert, but it removes all of the mess and wasted space of nulling the universe.

      Anyway, the demo looks great! I ran into a bit of a bug with the manual-auto turret- it got transferred to my escape fighter when I blew up just after activating the swap mission, but otherwise it looks quite good.

      Edwards

    • Ooh, very nice. The auto weapons are pretty cool 🙂
      Though I can't seem to get a Clear Puma Bay outfit.
      Also, would it be possible to use a cron dependant on contribute bits to temporarily remove all docked fighters and then you could see if there's any still left in orbit via Oxxx?

    • Edwards, on Nov 5 2005, 06:16 AM, said:

      I'm pretty sure that the problem is caused by the formatting of the sound resources- something about them causes the game to run at 2X for as long as the sound is playing.

      I think you're right about that. Interesting.

      Quote

      Anyway, the demo looks great! I ran into a bit of a bug with the manual-auto turret- it got transferred to my escape fighter when I blew up just after activating the swap mission, but otherwise it looks quite good.

      Edwards
      View Post

      Transfered to the escape fighter? Wow, I hadn't considered that! Funny.
      Well, um... it's a pocked sized turret... um yeah.

      And, yeah, the plug was 9 megs, but a nulled universe did compress pretty well!
      I was working in AbsoluteMinimum, but the 2x speed was really getting on my nerves.

      @ Guy:
      Hmmm. That might work. An iterative cron that uses a different outfit to act as a temporary container? So you remove them, check for fighters in orbit, then put them back in? I'll think about that.

      About the Clear Puma Bay. I'll have to check to make sure I didn't mess up the code, but I have the Clear Bays stay hidden untill you can use them (if you have no fighters of a particular group but still have some launchers.)

      This is the messiest part of the implementation. Basicly, when you have lost a fighter, you will have an extra launcher. I can't think of a clean way for Nova to tell WHICH launcher is the extra, and therefore which fighter to replenish, or which launcher to delete.

      So, it's an ugly kludge, but you have to sell all the fighters (of a group) before Nova can be sure that there is an extra launcher somewhere, and allow you to delete it. And prevent a situation where you have more fighters than launchers.

      The cron thing might be a way to solve that. Check for fighters in orbit, if any are detected, stop. If not, then remove all fighters and launchers, then place them back one by one with a launcher. And that will equalize the fighter/launcher ratio.

      Edit: Yeah, I had messed up the code. I also noticed a few other mistakes. The Puma interceptor and bomber were reversed in the ship resource, plus the instructions were botched on the "Sell (fighter)" outfits. But I think the concept demo was still clear.
      -----

      Ok, I have some other ideas about changing the set-up I have in the plug. Maybe you guys can lend an opinion.
      Right now, you use the sell button on a particular fighter to change it's loadout to the next in the line. This makes it easy to see which fighter you are changing.

      But, if I change it to where you click buy on the variant that you want to change TO, I can add some neat things like additional prerequesites to use a particular variant. For instance, you can make a fighter into a kamikazie bomb, but choosing that variant also would require taking a nuke from your inventory. Or maybe a certian high-tech loadout would require having an upgrade to your main fighter bay.
      The only problem is that it might be confusing for the player to know where his fighter will be swaped FROM.

      Perhaps, adding a fighter will automaticaly add the default configuration. Then you can only change a default fighter to a different variant, so you always know where the reconfigured fighter will come from. If you want to change a reconfigured fighter, you would first have to change it back into the default. The sell fighter mechanic would also only sell a default config. (and that also means I can use 1 less outfit per variant.)

      Would that be too cumbersome? Or is that functionality just to cool to leave out? Comments?

      This post has been edited by Desprez : 05 November 2005 - 08:24 AM

    • Ok, just a quick update.

      I'm changing the fighter bay system up again. I went ahead and tried using the buy buttons instead of the sell buttons to swap fighter types.

      The good news, is that requireing the player move his fighters to the default configuration before selling them, frees up may require bits. Now I only need 1 require bit per fighter TYPE, not each variant anymore. I think that's reason enough on its own to change it. Plus I'm happy to report that the added requirements to use certian loadouts is VERY cool.

      Plus, I discovered another cool trick this this system allows.
      You can now design a fighter that can combine and seperate into peices. :blink: It's possible to have one loadout be a larger fighter, and another loadout that yields two smaller fighters when you swap it. Or you could have an option to combine seperate variants into a Voltron like contraption. (though that would require additional require bits) You could even give the combined fighter additional technology prerequisets if you wanted. You can do A LOT with this thing. Neato.

      The bad news, is that the complexity of the system had trippled buy using the "buy" button.
      My work around has also cause the layout to become hectic.

      I also tried expirementing with a system to save space, that collapses and expands the fighter bay outfits as they are available. But it seemed to add more noise and less function.

      Also, due to some work arounds of Nova limitations, it's has also become necessary to run a mission every time you enter the outfitter. And now having to click "ok" every time is kind of annoying also.

      And I haven't even touched the iterative cron thing that Guy was talking about yet.

      Workin' on it. But, now I gotta get ready for my REAL job.

    • Desprez, on Nov 5 2005, 07:29 PM, said:

      Also, due to some work arounds of Nova limitations, it's has also become necessary to run a mission every time you enter the outfitter. And now having to click "ok" every time is kind of annoying also.View Post

      Do you need to actually give the player a choice, or are you forcing them to click "OK"? If the latter, you should be able to make that mission invisible by giving it a blank offer desc.

      Edwards

    • Arg. I'm getting some very bizarre bugs here.

      First, the reason I'm running a mission when you enter the outfitter, is to add launchers for all the fighter variants. This is so you can swap a particulat fighter variant. (otherwise, Nova won't let you add ammo without the gun, even if adding the ammo will also add the gun at the same time via Gxxx)

      Then, when you take off I'm running a cron to remove the added launchers.

      Ther problem is, as far as I can tell, the cron and/or mission are not always running is situations where they look like they SHOULD be running.
      (The blank desc worked by the way, but the mission is running less often. Not sure if that's related.)

      Now one strange behavior, it that I'm loosing fighter bay placeholders when an ENEMY ship loses fighters. ??? Edit: Figured this out. It was domething different.

      The other is this: If I loose say, a Raven Interceptor, I still have the bay and can recapture one to replace it. This makes sence. But I've noticed that I can capture a Raven Bomber to put in its place and it BECOMES a Raven Interceptor.

      One of the trade-offs I knew would happen, was that you would only be able to capture fighters of variants you currently had (and had lost). But somehow, Nova is captureing an innapropriate variant (that I don't at the moment have a launcher for) seemingly knowing that it's a variant that I can swap if I was to land, and it's ok to let me capture it. VERY STRANGE.

      Now, to be sure, this is a very good effect. You logicaly SHOULD be able to capture a variant of a fighter you have room for. But I can't imagine how Nova is able to use one kind of ammo (fighter) to replenish a completely different weapon. And do so correctly. I mean, how does it know that the "completely different" fighters are conceptualy a part of the same group? Even stranger, I haven't been able to do it unless there's a free bay of a "related" fighter available, so I can't cheat to gain extra fighters.

      This bugs me because I don't know why it's happening, and therefore don't know if I can control it. But now, as I type this, I have a theory.

      I had the launchers on the planet, and they automatically got Dxxx when I took off. Somehow, some parts of Novas memory must not be getting that updated state quick enough. Interestingly, if I try to capture a fighter before I have room, it attempts capture, finds that it can't, and makes it become an escort, and won't fill a bay. If I did have the room, it doesn't find out that I didn't still have the launcher until after it placed it, so it somehow gets converted to ammo for a bay that I do have. Though I'm not sure how this could possibly be working correctly.

      Edit: I think this is becoming clearer too. And I think it's actually becoming a controlable bug (feature!). It seems to be a mismatch in the timing of the way Nova tracks what's on you ship. It thinks you have the launchers when you don't, but it still correctly figures how many fighters you can hold by the correct number of launchers. So, it's like the extra launchers are there but you can't use them until you lose a fighter first. It doesn't seem to fix itself if you open the player info box either. I'd better check to see if it fixes when you take off or land.
      Edit: I turned off the adding and subtracting of launchers. It STILL happens! Now I have no idea.

      This post has been edited by Desprez : 06 November 2005 - 03:14 PM