Fighter Loadouts - A tough problem

So I've been tinkering with Nova for a bit after a loooog hiatus of not playing EV/O/N.
I'm haveing fun making new things, though there were some spots of fustration. Most of this time I could find the answers by expiramenting or just by searchng through this board.

I'm busy creating a slightly different interpertation of how EV works...
In this project, the combat feels more like naval combat, more time to react and work tactics and less reflex. Everything is smaller and slower - so as if you were viewing the space scape from farther above.
Ships are always constantly draing fuel. Most outfits consume a bit of power, and most weapons consume power also. If you run out of power, you're probably dead. This complicates the logistics of traveling and engaging in battle far from your bases.

This creates new and interesting challenges for outfitting your ship. Sure, you can mount those 8 heavy blasters, but they suck power pretty quick, maybe you should get a larger power source instead... Should that fighter forgo the advanced IFF/Mass sensors to save on fuel drain? Is that radar jammer worth the cost in power consumption?

Of course, this means that there must be tools to address the issues of a constantly draing power supply. Like auxiliary/reserve power systems that don't provide fuel until you need it, different generators and such.

I had some creation challenges, and wrestling with NCBs, but I've managed a few nice things so far.

• I've managed to create turrets that can be toggled between point defence/regular mode mid-battle. Also works to turn off/on PD weapons.

• A "pulse" weapon that expands out from the firing ship 360 deg. to damage missiles and ships alike (even ships unaffected by PD weapons)

• 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.)

• Different launchers can be combined in different ways with different different missile types. Each launcher can fire multiple types of missile, and each missile can be used with multiple types of launcher for different launch characteristics.
This works out pretty nice in battle too.

I'm having some issues trying to make it so you can't land on a planet (atmospheric flight) unless you are in a small fighter or ship, or your capital ship has shuttle or fighter to use. But I think I can work that out.

So anyway, my biggest hurdles were time travel and the ability to switch your fighters to different loadouts for different tasks.

Time travel is solved and you can visit the universe in 5 different eras so far. Like, go ahead in time, grab some technology and bring it back to the past to use. Solved, that is, except for the fact that to make the numerical date match would take my computer about 3 hours to loop around 65534 years using date post. Can't have that! (It takes about 15 seconds for the comp to think about how to advance the date by 32767 days.) So I'll just have to explain away the invalid date somehow. Right now I'm displying the current era as a mission in the active mission box.

My biggest challeng so far, and reason for this log winded post, is trying to have the ability to give your fighter different loadouts.

Such that you buy a particular fighter, and maybe have two options: an anti-fighter loadout, or an anti-ship loadout.
Ideally, I'd like to be able to select the loadout and then launch them into battle. Then, and some point, recall them to re-arm and select a different loadout, and send them back into battle.

However, it looks like I'm going to have to settle on landing at a planet to do the retasking. Just as long as it doesn't require going all the way home and selling and repurchasing a different fighter bay and fighters.

The same weapon using multiple ammo trick doesn't work with fighters too well, because fighters can come back after launch. This can lead to ways to get more fighters than you are supposed to be able to hold.

I could revamp the fighter bay system and limit your fighter numbers of how much mass you have available, which would be nice. Except Nova doesn't check for mass constraints when capturing or recalling fighters. This too can lead to having more than you should be able to hold.

Another part of the problem is that while Nova keeps track of how many fighters you have, it doesn't mach the outfitter screen if you have some launched when you land. I tried making an outfit that is only available if you have a particular fighter, that converts it to a different fighter (loadout) when bought. But you can't Dxxx a fighter that is currently launched even though a launched fighter will still trigger Oxxx. That's a problem.

I don't think I can use a seperate item or NCB to track fighter numbers because how do you get that to recognise when a fighter is killed?
Unless someone can think of another way, I think I need to be able to
• automatically recall all fighters (or force the player to recall all fighters)
OR
• track total number of fighters (launched and unlaunched)
OR
• track when a fighter dies
OR
• Trigger stuff on fighter launch/land

I don't think any of these are possible?

There might be a way to use a cloaked përs that follows you around. You target it and it looks like you are communicationg with a different section of your ship. Contacting it would be like "Fighter command here. Would you like to change loadouts?" This is the only way I can think of testing and offering different missions during battle. The "abort" activation mentioned earlier won't work because it cant "test" a condition after it's already a mission. There seems to be no other way to test a variable with precision timing unless you warp, land, or take off.
And I'm still not sure this is possible due to the Number in bay/Oxxx inconsistancy, but I have yet to test in space.

Any help?

Oh, and is there a way to automatically activate the weapon saftey? I notice that you can select a weapon that uses ammo. Land and sell the launcher. Then when you go back into space the weapon is still selected if you have ammo. (but you can't reselect it if you change weaps)
Edit: Err, not sell the launcher. I meant to say Dxxx the launcher and it will still stay selected. Selling will de-select it correctly.

This post has been edited by Desprez : 02 November 2005 - 12:58 AM

Wow, you have some really cool stuff there. Just hope you don't run out of MaxSimultaneousMissions. Well I don't have any definite or even very good answers but here's a couple of thoughts.

Have just one fighter carried by the player and it will carry the rest of the fighters itself. When you order it to attack it will launch the others and they'll all go off together. You could even use KeyCarried to make the one fighter look like many until it launches them. This may make things slightly simpler by having only two statuses: all in or all out. Only problem is if you lose the other ones they'll be replenished when the main one is recalled.

It may be possible to implement a test when you abort a mission. In the OnAbort field tell it to Axxx or Fxxx a second mission and then put the actual operators you want to use in the second mission. The second mission will be aborted only IF it is already active.

Desprez, on Nov 1 2005, 10:37 PM, said:

(About the fighters:) Ideally, I'd like to be able to select the loadout and then launch them into battle. Then, and some point, recall them to re-arm and select a different loadout, and send them back into battle.View Post

I have never tried this, but you might want to look into a combination of standard weapons using fighters as ammo, in-flight time advancement, and a cron (see if you can clear out the fighter outfits). I'll see if I can come up with something more useful by tomorrow.

Desprez, on Nov 1 2005, 10:37 PM, said:

• A "pulse" weapon that expands out from the firing ship 360 deg. to damage missiles and ships alike (even ships unaffected by PD weapons)

Just how did you manage to get it to affect missiles? As far as I can tell, it takes a direct hit by a PD weapon to destroy a missile.

Desprez, on Nov 1 2005, 10:37 PM, said:

...to make the numerical date match would take my computer about 3 hours to loop around 65534 years using date post. Can't have that! (It takes about 15 seconds for the comp to think about how to advance the date by 32767 days.)

Nice to see someone else confirming my numbers.

And welcome to the EVDC!
We're always glad to welcome new developers, and it looks like you're quite good at making work-arounds.

@Guy: But how do you run the tests on the secondary missions?

Edwards

Sounds like he means a simple true/false test, not an ncb test expression - specifically, either the mission is active or it isn't. If it isn't, nothing happens; otherwise, it does whatever it's told to. Theoretically, mutually exclusive missions with different fail/abort expressions, in combination with a set string that fails/aborts them all (abort would be best to avoid the "mission failed" dialog, and it doesn't have awful ramifications if the CanAbort flag is false by accident - you can Axxx a mission that doesn't have CanAbort set, right?), you could create an if/elseif/elseif/.../else test with no limits save the 16 active mission limit (meaning up to 15 different possibilities, though less in this case since he already has some for other purposes).

@ Edwards:
The pulse weapon consists of an PD turret (or a a non-PD unguided projectile for manual operation) that submunitions after 1 frame into 36 parts with theta -10 so it makes a nice even radial spread. Now this submunition is also designated as PD so it will connect with missiles. I've found that it doesn't matter how a PD weap is launched (automatic or subbed) if it is of guidance PD, it will hit missiles. Interestingly, subbed PD doesn't hit fighters in some conditions. And PD weapons won't hit ships that are immune to PD.
So in order for the PD to take out any ship, I added a proximity trigger that will sub into a non-pd weapon that CAN hit ships. The missiles won't trigger the prox, but ships will. (any ship triggers prox flagged, and detonate

The prox and blast distance is the same as the distance a shot travels in 1 frame. So as soon as the pulse gets close to a ship, it subs next frame, where it hits the ship. The parts that don't trigger prox, don't sub. (subs fail when shot expires flagged)

That's the basic idea, though it works better with a reload of 1 and burst count of 2 with a longer burst reload. This gives 2 rings of fire so that 1 missile doesn't knock out a whole section of the ring for the rest of its travel.
---
Now about the inflight advancement. I was under the impression that the crons only check to trigger when you warp in, land, or take off. If I date post while in the midts of flying in a system, crons will trigger? If so, that may be good news indeed. And now I can maybe realize some other cool outfits.

Still though, with clearing the fighters, Oxxx can't be used to check fighter availability since it returns true if you control one, even if it is not docked (available). (and reads 0 in the ottfitter area) Worse yet, it reads as available, and yet Dxxx can't touch it! (So I can't check for availibility and then Dxxx and Gxxx it into a different fighter.)
---
As far as running out of MaxSimultaneousMissions, yeah I'm getting close.
The on/off or manual/auto PD weaps each take up a mission. The "commands" each take up one.
---

@ orcaloverbri9:
I was refering to NCB tests. For instance:
Say I have a mission running. When I abort it, I want something to happen. It would be really nice if I could slip in an IF statement somehow. But the only test in the mission rsrc is in the availability section. And it doesn't trigger on Sxxx Axxx Fxxx or anything else.

If it turns out I can use in flight crons to evaluate test expressions, that might lead to a whole bunch of other stuff. (The crons continually modify what is available in the active missions. Such as, when you have no more missiles, Sxxx a mission that you can abort to transfer some stockpiles from your cargo hold. Or something.)

How's this for swapping fighter types? It currently relies on a cron and in-flight date advancement, but it could easily be adapted for use on a planet.

Basically, it turns out that Require bits are affected by whether a fighter whose outfit has them is launched or in its bay. With this bit of information, its becomes fairly straight-forward to switch fighter types using the same methods you use for other weapons.

My example is designed to be used with AbsoluteMinimum (if you're using a Mac, you'll need to convert it). To try it out, start a new pilot, land on the planet, buy a few "Fighter A"s and pick up the "abort me" mission from the BBS. Take off, launch a couple of the fighters, and abort the mission. Switch weapons, or look at the pilot info box, and you'll see that all of your "Fighter A"s have turned into "Fighter B"s.

And, in testing this, I ran into a couple of bugs:

1. In some odd instances, when the outfitters adjusts itself after you make a purchase that changes the availability of other outfits, the "Buy" button does not get de-selected, even though all of the outfits do. When you click it, you are given one of either the lowest-ID'd outfit on the list, or outf 128 (I only did a few tests, and this only occured when outf 128 was available).
2. Apparently Matt Burch never actually fixed anything so that a fighter bay can't be sold if you have fighters out- all of the "fixing" comes from the bays' "MaxAmmo" field preventing one from being sold if doing so would give you an illegal amount of ammo.

--------------------
Also, I am happy to announce that, although they were completely irrelevant to the solution, fighters that double as ammunition for normal weapons work quite well. I originally though of them as a method of changing a torpedo bomber's sprite when it launched its weapon, via KeyCarriedShip. Just something interesting that someone might be able to use.

--------------------
If you haven't already done so, you should read through all the threads mentioned in the "Cool Nova Hacks" thread, and all the ones linked from there. It's missing a few recent threads, but it has a great deal of useful stuff (such as in-flight cron usage).

--------------------
And finally, about only allowing some ships to enter an atmosphere, take a look at the govt resource's Require bits. They should work quite well.

Edwards

Attached File(s)

• SwapBays.bin.zip (907bytes)
  Number of downloads: 44

This post has been edited by Edwards : 02 November 2005 - 11:51 AM

Desprez, on Nov 2 2005, 10:05 AM, said:

@ orcaloverbri9:
I was refering to NCB tests. For instance:
Say I have a mission running. When I abort it, I want something to happen. It would be really nice if I could slip in an IF statement somehow. But the only test in the mission rsrc is in the availability section. And it doesn't trigger on Sxxx Axxx Fxxx or anything else.

Right, but you can set the value of the expression evaluated by the if by activating and deactivating the mission, and the OnFail/OnAbort would be the expression to evaluate if true. Using C if notation, you can replace:

if (bit set){
ncb set string
}

with:

if (mission is active){
OnFail/OnAbort string
}

Workarounds don't have to make sense, they just have to work.

Desprez, on Nov 2 2005, 01:37 AM, said:

"rerouting power from navigation" (quickly regenerates fuel but reduces accel, speed, visuals, radar until you can land for repairs)

Lies Speed and such only update in flight when the player opens the ship info dialogue. Mighty unfortunate, it had so much potential, too.

Quote

Time travel is solved and you can visit the universe in 5 different eras so far. Like, go ahead in time, grab some technology and bring it back to the past to use. Solved, that is, except for the fact that to make the numerical date match would take my computer about 3 hours to loop around 65534 years using date post. Can't have that! (It takes about 15 seconds for the comp to think about how to advance the date by 32767 days.) So I'll just have to explain away the invalid date somehow. Right now I'm displying the current era as a mission in the active mission box.

Hmm... Every date piece is stored as a str rescource... there might be some way to ###### with them... though, that would probably only mess up every instance of "1" for example. You could screw with the Ditls of the map and player info dialogue, and make it Qxxx something every time the player enters a system, but thats pretty low. Oh... right... and it ruins the date for all other purposes. I dont remember, maybe there is a way to make it so it just shows the day and month. Then it would be like you always jumped forwards and back integer multiples of years. You could add a few month datepostinc to it, then it would be completely random.

Quote

Oh, and is there a way to automatically activate the weapon saftey? stay selected. Selling will de-select it correctly.
View Post

This is sort of nasty, but can you afford to replace their ship with a copy of what they already have? (the mode that keeps the outfits the same).

edwards said:

Basically, it turns out that Require bits are affected by whether a fighter whose outfit has them is launched or in its bay. With this bit of information, its becomes fairly straight-forward to switch fighter types using the same methods you use for other weapons.

Wow! Thats awesome! This can be combined with the cloaked pers communicator thing

Quote

Also, I am happy to announce that, although they were completely irrelevant to the solution, fighters that double as ammunition for normal weapons work quite well. I originally though of them as a method of changing a torpedo bomber's sprite when it launched its weapon, via KeyCarriedShip. Just something interesting that someone might be able to use.

Whoa... thats weird. Wow. Thats actually insanely useful. I have a perfect place for that. 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? Thats mighty cool.

Quote

@ orcaloverbri9:
I was refering to NCB tests. For instance:
Say I have a mission running. When I abort it, I want something to happen. It would be really nice if I could slip in an IF statement somehow. But the only test in the mission rsrc is in the availability section. And it doesn't trigger on Sxxx Axxx Fxxx or anything else.

If it turns out I can use in flight crons to evaluate test expressions, that might lead to a whole bunch of other stuff. (The crons continually modify what is available in the active missions. Such as, when you have no more missiles, Sxxx a mission that you can abort to transfer some stockpiles from your cargo hold. Or something.)

You can also have a mission, 128 for example, that in its onfail it contains S128 S129, where 129 is whatever special you want to do. Theres also one more evaluation in space that doesn't require a day counter.

Dudes AppearOns. I have figured out some masterful ways of hacking the hell out of those. I feel bad about revealing my secrets though.

The cargo stockpile is also a neat idea. If you can afford an extra mission (not concurrent, just the rescource), you can even make it take a couple of seconds (ie Sxxx a mission with a specialship that follows the player around, jumps in aftrer a short delay, the ship mission is observe, and in the onship done, you abort the mission and add the rescources. The problem is, naturally, this ghost ship that pops in (though in this case, since it doesn need to die, it could just be a normal, unassuming ship that just 'coincidentally' appears everytime you reload. It doesnt seem like the playter woudl notice that)). Oh, right, but the only way to mess with the cargo on the players ship is to give him a delivery mission with no destination, then have the other mission cause it to fail. This would only work once, as Fxxx and Axxx fail and abort every copy of xxx. Note the only way to have multiple, concurrent copies of xxx is to use the S operator. A clever programmer would find a way to have all of his infinite repeating delivery missions take up maybe three or four slots. The only downside is the preacceptance briefing wont know the dest or pay of the mission (but story can play that off perfeclty fine).

Here is the thread that explains my continuous time progression while flying. I can get anwhere from... like 5 seconds a day (whatever a ship with deathdelay of 20 takes to jump in and die) up to... 18.2 minutes. But seriously, look at all of the posts in the cool nova hacks thread. Lots of neat stuff.

orcaloverbri9, on Nov 2 2005, 07:32 PM, said:

Right, but you can set the value of the expression evaluated by the if by activating and deactivating the mission, and the OnFail/OnAbort would be the expression to evaluate if true.

But how do you remove a mission without triggering Axxx?

Once the mission is active, Axxx will trigger regardless of how the abort happens. Whether the player clicks abort in the active missions box, or Axxx get thrown for some other reason.

I'm using the onAbort field so that the player can activate the effect at will. The mission has already been activated.

I have a outfit that when you buy it, it starts a mission. It will sit there until you use it by clicking Abort, then an effect happens.
The limitation is that I can't change what that effect is on the fly, or have different options.
If I have it start two missions and the player chooses which one they want to Abort, how do I remove the unused choice in flight? I can't Axxx it, because that will trigger it!
I can't have the Axxx refer to abother missions (test) field because that isn't checked upon Sxxx

The only work around is to have Axxx trigger another mission that uses OnShipDone to evaluate as true condition, and uses Axxx (before OnShipDone triggers) as the false condition.

This gives a delay of 2-3 seconds and requires the player make multiple clicks, and might not always be desirable or very striaght forward, and also relies on the PLAYER choosing the outcome by selecting wich mission to abort. But this won't support an IF condition that the player DOESN'T have control of.

Well, now that I know that crons can trigger in mid-flight I could use the availability (test) in the cron. I'll have to expirement with that.

@ Edwards:
I'll check that out and get back to you. Thanks.

NebuchadnezzaR, on Nov 2 2005, 08:04 PM, said:

Lies Speed and such only update in flight when the player opens the ship info dialogue. Mighty unfortunate, it had so much potential, too.

I can absolutely verify that accell, turning, murk, interference all take affect without opening the player dialogue.

I'll have to double check speed.

I have an mission that when you abort it, it instantly gives you two outfits containing:
High fuel regen, crippleing speed, turning, accell, murk, and interference while waiting for an OnShipDone to die.
After it dies, the outfits are removed and replaced with and outfit with less serious penalties.

This simulates re-routing power from other systems to recharge energy. Then, after a few seconds the power levels normalize, but some residual damage is still leftover from such a violent, out of spec, power transfer.

Desprez, on Nov 2 2005, 04:55 PM, said:

But how do you remove a mission without triggering Axxx?

Doesnt Fxxx work?

Desprez, on Nov 2 2005, 05:11 PM, said:

I can absolutely verify that accell, turning, murk, interference all take affect without opening the player dialogue.

I'll have to double check speed.
View Post

There was a big bruhaha about this not working... be careful that it isnt platform/version specific.

Quote

I have a outfit that when you buy it, it starts a mission. It will sit there until you use it by clicking Abort, then an effect happens.
The limitation is that I can't change what that effect is on the fly, or have different options.
If I have it start two missions and the player chooses which one they want to Abort, how do I remove the unused choice in flight? I can't Axxx it, because that will trigger it!
I can't have the Axxx refer to abother missions (test) field because that isn't checked upon Sxxx

Remember dude appear on values. Somewhere, you put a R(^bxxx).

I dont know which of the following works: (im sure of the second, not so much on the first)

If nova DOES do things perfectly, then in the onAbort of the mission the player can see, you put Sxxx ^bxxx Syyy. There would be only one dude, a ship xxx with visibility bxxx and 0 armor with a death delay of 20, and a ship yyy with visibility !bxxx, invulnerable. Both ships super fast, no fuel, no turning. They might be on radar for a single frame, but even that isnt guranteed. Both of these missions would reference the same dude, with the availability flopped in between. If this works right, then every single time, one mission starts with a ship that dies immediately, and the other ship live a long, prosperous life. In the onShipDone of each mission (destroy ship missions), Axxx Ayyy and then whatever you want to happen. The effect will be random.

If nova DOESNT do everything perfectly, then you use the same setup, but you just need to use 4 ship classes and 2 dudes. Same thing exactly, except the second pair of dudes visibility is flopped.

Just make sure there is always a valid choice for dude creation. Nova has been known to pick dudes out of its ass if all of the visbits are false.

(there are also bulky ways to handle this that involve... 1/15*25xxx(whatever that number is) chance of failure, but then you only need to have one of the dudes dissapear. The second dude will still be there while the first dude is there, it just has a terribly lower chance of showing up. And if it fails, it just accidentally choses the other option.)

Hmm... actually... I think you could just have it start two 'observe ship' missions, and it would be pretty random (possibly) which one gets done firrst (and thereby aborts the other). The problem with this is its random only, the above method allows you to set bxxx beforehand. Also note this can be done with more than two ships, it just becomes fairly expensive (Especially ship rescource wise).

This post has been edited by NebuchadnezzaR : 02 November 2005 - 04:37 PM

NebuchadnezzaR, on Nov 2 2005, 09:31 PM, said:

Doesnt Fxxx work?

Last I checked, it just fails it, it doesn't remove it, and therefore it can be still aborted.

As far as platform specific issues are concerned....
This sounds like a nightmare.

You mean to tell me that accel,turning,etc modification works on some machines and not others?

Because if it didn't work AT ALL before, there's some hope as maybe something seemingly unrelated is causing it to work in this instance.

Ugg. Where can I find what is and isn't platform specific?

You are the kind of person that would find and report that info.

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.

This post has been edited by NebuchadnezzaR : 02 November 2005 - 05:38 PM

Desprez, on Nov 3 2005, 09:55 AM, said:

But this won't support an IF condition that the player DOESN'T have control of.
View Post

What exactly is the IF condition you want?

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

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

And it doesn't trigger Axxx?
Really?
Golly, I'm going to have to exploit that!

@ Edwards:
I tried something similar with the multiple bays and fighters.
Except that there didn't seem to be any way to prevent the player from being able to have too many fighters.

The max ammo doesn't work because we're dealing with two different launchers. So if a bay was to be able to hold only 2 fighters, you can still get 2 in each version and end up with 4. Plus you can continuously swap fighters to the alternate type and keep buying more of the first.

Basing the max fighters on mass instead, doesn't work because you can buy them, launch them, buy them, launch them, was past your mass limits. Also, you can capture disabled fighters past your mass limits too.

I can make it so you can only have 1 bay set with 1 fighter set. But I'd need seperate resource set for every iteration of the set the player can have. The only way to prevent the player from picking up extra fighters to fill the capacity of currently unused launchers, it to swap out the launchers themselves instead of the fighters. But this only works if max ammo is 1 (otherwise both launchers could be active)

If I want them to be able to have 4 fighters max, I'd need 8 bays + 8 fighter variants. That's 16 outfits + 8 weaps to simulate 4 different changable fighters!
That seems wastefull.

I know for absolute fact that on Mac Nova 1.0.7 (don't ask) launching a missile that also doubles as a speed mod (or inertial dampener) does not cause the attributes of your ship to change until you hit 'p'. I have no idea if OnAbort Gxxx-ing an outfit has the same limitation, and it certainly sounds from what you're saying like it doesn't.

Edwards has a very elegant solution to the switching fighter types in flight problem. If you're interested in a method that requires landing (and thus can't be done in flight) but that doesn't use a mission, try this:

Outfit 1: Fighter bay. OnPurchase grant outfit 2. OnSell remove outfit 2.
Outfit 2: Bomber bay. Never appears in outfitters. Can't be sold.
Outfit 3: Fighter. Ammo for Fighter Bay. Can be sold anywhere. OnSell grant outfit 4.
Outfit 4: Bomber. Ammo for Bomber Bay. Never appears in outfitters. OnSell grant Outfit 3.

Just make creative names and descriptions for the outfits. Maybe make the fighter bay come with fighters, and have the fighters cost nothing (since you're not buying them, just refitting). The only problem with this is the persistence of the fighters/bombers: they can't be removed by selling them. I'm sure you'll be able to hack a way around that though. If you want more types of fighters to choose from, just make their OnSell Gxxx-ing circular. 1 -> 2 -> 3 -> ... -> N-1 -> N -> 1 -> ...

Edwards, on Nov 3 2005, 05:30 AM, said:

How's this for swapping fighter types? It currently relies on a cron and in-flight date advancement, but it could easily be adapted for use on a planet.

Basically, it turns out that Require bits are affected by whether a fighter whose outfit has them is launched or in its bay. With this bit of information, its becomes fairly straight-forward to switch fighter types using the same methods you use for other weapons.

My example is designed to be used with AbsoluteMinimum (if you're using a Mac, you'll need to convert it). To try it out, start a new pilot, land on the planet, buy a few "Fighter A"s and pick up the "abort me" mission from the BBS. Take off, launch a couple of the fighters, and abort the mission. Switch weapons, or look at the pilot info box, and you'll see that all of your "Fighter A"s have turned into "Fighter B"s.
View Post

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.

Qaanol, on Nov 3 2005, 01:17 AM, said:

I know for absolute fact that on Mac Nova 1.0.7 (don't ask) launching a missile that also doubles as a speed mod (or inertial dampener) does not cause the attributes of your ship to change until you hit 'p'. I have no idea if OnAbort Gxxx-ing an outfit has the same limitation, and it certainly sounds from what you're saying like it doesn't.

Edwards has a very elegant solution to the switching fighter types in flight problem. If you're interested in a method that requires landing (and thus can't be done in flight) but that doesn't use a mission, try this:

Outfit 1: Fighter bay. OnPurchase grant outfit 2. OnSell remove outfit 2.
Outfit 2: Bomber bay. Never appears in outfitters. Can't be sold.
Outfit 3: Fighter. Ammo for Fighter Bay. Can be sold anywhere. OnSell grant outfit 4.
Outfit 4: Bomber. Ammo for Bomber Bay. Never appears in outfitters. OnSell grant Outfit 3.

Just make creative names and descriptions for the outfits. Maybe make the fighter bay come with fighters, and have the fighters cost nothing (since you're not buying them, just refitting). The only problem with this is the persistence of the fighters/bombers: they can't be removed by selling them. I'm sure you'll be able to hack a way around that though. If you want more types of fighters to choose from, just make their OnSell Gxxx-ing circular. 1 -> 2 -> 3 -> ... -> N-1 -> N -> 1 -> ...

Well I'd rather have it work in flight. The landing part is what I'll probably have to resign to.

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.

But there's still the problem in that they player can pick up disabled fighters that will fit into the launcher that is unused, and again, end up with too many fighters.

Maybe if I combine ideas where switching fighters ALSO swaps out the opposite bays.

Actually, I might be able to combine this with the cloaked pers method too.

Hmmm.

Guy, on Nov 2 2005, 11:22 PM, said:

What exactly is the IF condition you want?
View Post

Ideally, I'd like to be able to evaluate a test expression in the onAbort field.
OnAbort: IF Bxxx (Sxxx else Syyy)

But it doesn't look like there is a clean hack around that limitation.
The only things that look like I might be able to pull off similar functionality are the in flight time advancement, a pers mission, or maybe the dude availability thing.

Desprez, on Nov 3 2005, 03:28 PM, said:

But there's still the problem in that they player can pick up disabled fighters that will fit into the launcher that is unused, and again, end up with too many fighters.
View Post

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

Desprez, on Nov 3 2005, 03:37 PM, said:

Ideally, I'd like to be able to evaluate a test expression in the onAbort field.
OnAbort: IF Bxxx (Sxxx else Syyy)

But it doesn't look like there is a clean hack around that limitation.
The only things that look like I might be able to pull off similar functionality are the in flight time advancement, a pers mission, or maybe the dude availability thing.
View Post

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.

This post has been edited by Guy : 02 November 2005 - 10:05 PM