Do "null" cröns work?

- updated

Update: see my last post for another question.

I'm trying to get a little feature of ARPIA2 fixed, but can't seem to find a "perfect" way that works.

There are seven types of Akarui & Hayai fighter bays in total (4 Hayai, 3 Akarui), and the idea is that you can buy a maximum of four.

To stop people from buying more, I used simple counter cröns (and so it counts up to four bays), and so basically, a player has to land on the planet again to buy a second bay (IIRC).
It's not satisfactory, but it's the best I could find (back then).

To re-enable players to buy bays, I used another counter crön system, but the other way round (if the player sells one and has four originally, Nova will now register him/her as having three bays now).

The problem comes from players selling multiple bays at once, because in that case, the counter is only started once, and Nova therefore thinks the player has only sold one bay.

All this could be worked around if "null" cröns (which I define as being cröns with no duration, "preholdoff" or "postholdoff" whatsoever) work(ed).
But I seem to recall testing it out a couple of years back, and I believe it didn't work. Does anyone know whether it does?
(yes, I'm lazy)

Basically, if they don't work, I'm trying to find another workaround.
I've been thinking about invisible oütfs, but that wouldn't help as a counter unless I'm missing something.
And I've been also thinking about mďsns, but then the problem is I'm not sure whether the mission would 1) appear immediately in the outfitter (invisibly, of course I know that that much works) 2) reappear multiple times despite the fact it's been offered once in the same place (and has auto-aborted).

Any ideas, or more concrete info on how to emulate the behaviour I'm looking for?

This post has been edited by Pace : 24 July 2007 - 03:37 AM

Sounds like a more simple case of the Multiple Ammo Types trick. The first version (not 'revB') should suffice but you could probably make it even simpler because you don't have worry about 'using up' bays while in-flight. And yes, it does use invisible outfits - I think you're missing the ability to have iterative crons

And no, null crons don't work properly.

Well, the "simplest" solution is to use slots. In particular, stop using "turret slots" and start calling them "fighter bay slots". Make turrets and fixed guns both use "gun slots" if you want. Whatever. The whole "slots" thing is arbitrary to begin with. I call this "simplest" because no new resources are needed, just changes to existing ones. But, of course, since ARPIA 2 is a large plug-in and not a TC you don't want to mess with EV:N on that scale.

I don't know anything about iterative cröns. Guy, could you please explain in detail? They might turn out to be very useful for something, even though I prefer not to use cröns if at all possible. Are you saying that a crön can fire multiple times in a single day as long as its requirements are met? And if so, what specifics must the crön have to ensure that it will fire iteratively until its requirements no longer are met?

And, back on topic, won't this work to ensure a maximum of 4 fighter bays at a time:

Your ship, when you purchase it, comes with four outfits, call them "Fighter Bay Docks" or somesuch. Give it outfit ID xxx. They can't be sold, they don't transfer when you change ships, and they may as well be invisible for all the player has to know about them.

Each fighter bay outfit has Availability Oxxx (so it can only be bought if you have a dock. This can also be done with Require bits, by having outfit xxx contribute a bit, so you can work with it if visibility of the fighter bay in the outfitter has to change based on availability but not require bits.) Each fighter bay has OnPurchase Dxxx and OnSell Gxxx.

Now, the only remaining difficulty is when the player has, say, 2 Docks and wants to buy 19 Hayai Bays all at once. What we need is to limit the number of bays that can be purchased as a batch to the number of Docks owned, and that's easy enough. Just use ModType 27, Increase Max with ModVal 1. The Dock can only do that for 4 types of bays, so depending on how many total bays exist you'll need additional outfits, call them "DummyDocks" or whathaveyou. Give them IDs yyy, zzz, and so forth. Now your ship has to come with the same number of each of those as it has Docks, and every time a Dock is granted or removed, one of each DummyDock is too.

AND THAT IS ALL.

Of course, to implement this into an ARPIA 2 update, you have to deal with players who already have pilots that already have fighter bays. Either issue a blanket statement that says "Pilots from older versions no longer work" or try to do something clever with cröns as a one-time updater miniplug.

Anyway, to repeat, here's the method:

One "dock" outfit with Increase Max 1 to each of 4 fighter bays and maybe gives a Contribute a bit.
Additional "dummy dock" outfits with Increase Max 1 to each of 4 other fighter bays until all fighter bays are accounted for.
Every ship comes with each of those outfits in the correct number. (Docks = Max Bays - Stock Bays, and the same for each Dummy.)
Every fighter bay is purchasable only if the player has at least one dock.
Every fighter bay removes a dock and one of each dummy when bought.
Every fighter bay grants a dock and one of each dummy when sold.
No fighter bays are granted (by missions etc.) except when a dock is owned, and when granted a dock and one of each dummy is removed.
No fighter bays are granted by përs ships using GrantClass.

Can anyone think of any situation in which this would not work flawlessly?

This post has been edited by Qaanol : 24 May 2007 - 01:05 PM

Brilliant idea (though I haven't tried Guy's method yet, so I can't say which one would be better)

Just one thing: I don't truly understand the point of the Dummy Docks Could you elaborate on that?

And a good thing is that the max number could then vary depending on the shďp: you could say that fighters are allowed no bays, medium ships 1-2, and larger ones up to 4 Just make sure the "OnRetire" field includes the "Dxxx", otherwise the "Exxx" expression would mean that a player could end up with 8 docks.

I was wrong. No wonder you didn't understand it, it wouldn't have worked. =p

Here's what it should be:

The Dock outfit comes stock on all ships in the appropriate number (Docks = Max Bays - Stock Bays)
Each fighter bay has a maximum of 1.
Each fighter bay does IncreaseMax to itself.
Each fighter bay removes a Dock on purchase.
Each fighter bay grants itself on purchase.
Each fighter bay grants a Dock when sold.
Each fighter bay removes itself when sold.
Each fighter bay can be bought only if you possess a Dock.

If only it were that simple, everything would be dandy. Unfortunately "IncreaseMax" works exactly as described in the bible. So that means you need a whole slew of Dummy outfits that each do IncreaseMax to four fighter bays, until every fighter bay is covered. Then you need the player to always have exactly one of each Dummy. They could be granted OnStart for every chär, and you could have a crön that grants them to "update" a pilot file from a previous version. The Dummy outfits can't be sold or bought and in general they just sit there.

Now the situation, as the player sees it, is this:

You can buy a fighter bay, but only one at a time. After you buy the first one the outfitter refreshes and then you can buy a second bay. Once you have four bays in total, though, (ie, when you run out of Docks) you can't buy anymore bays until you sell some. They can be sold in groups (by option-clicking) but they can only be bought one at a time.

If you want a certain bay to have a max of 1 (ie. you can have 4 bays, but no more than one of them can be "Teh Ubber Bayness of Doomz0rz") then that bay would not IncreaseMax itself.

If you want a certain bay to have a max of 2 or 3 then you need to introduce an additional outfit for that bay, call it, "Ubber Bayness of Doomz0rz Dock" and it would work just like a normal Dock except only that particular bay would G/Dxxx it. That bay would still G/Dxxx normal Docks too. But if you're going to have a "max total bays" type deal you probably don't care how many of them are which type, so this is just a waste of outfit resources.

So basically that's how it's done: Every bay IncreaseMax's itself, but you need to have one IncreaseMax for each bay already present, in the form of Dummy outfits. The Dummies are never granted or removed (except on character start, or when updating an old pilot) they just sit there and stay with the player no matter what ship he or she changes to. Docks keep track of bay slots.

This post has been edited by Qaanol : 25 May 2007 - 02:33 PM

@qaanol, on May 25 2007, 05:37 AM, said in Do "null" cröns work?:

I don't know anything about iterative cröns. Guy, could you please explain in detail? They might turn out to be very useful for something, even though I prefer not to use cröns if at all possible. Are you saying that a crön can fire multiple times in a single day as long as its requirements are met? And if so, what specifics must the crön have to ensure that it will fire iteratively until its requirements no longer are met?

Ugh, I really didn't want to think about anything here (hence I just pointed Pace to an existing solution, albeit one for a more complicated problem) but it's Saturday now and I have a clear head (good to see you round, btw ;)). Anyways, this is all in the bible - just read the section on crons:

Flags		 0x0001	Continuous, iterative cron entry - keep evaluating
						 the cron's OnStart field until the EnableOn expression
						 is no longer true or the constraints of the Require
						 fields are no longer met. This can create infinite
						 loops, so be careful!
			  0x0002	Continuous, iterative cron exit - keep evaluating
						 the cron's OnExit field until the EnableOn expression
						 is no longer true or the constraints of the Require
						 fields are no longer met. This can create infinite
						 loops, so be careful!

However, now I've thought about all of this I realise the whole point of the crons was to recalculate stuff to account for ammo lost/gained in-flight, so they would completely pointless here. Once we take all that stuff away though we're left with nothing but the same solution Qaanol first posted. Well, almost. Sorry to tell you Qaanol, but batch purchasing is nothing special and you don't have to anything special to account for it. All that extra stuff with increasing max and having dummy docks is completely unnecessary. All you need is the "Fighter Bay Dock" outfit which the actual bays check for and remove on purchase.

This post has been edited by Guy : 25 May 2007 - 05:55 PM

Wait wait wait.

Can't you just start each ship with four "Bay Tokens" and only have a fighter bay purchaseable if a token is present?
Every time you buy a bay, you lose a token.
Every time you sell a bay, you gain a token.

Or did I miss something?
Sorry if I did. It's late and I just happend to be passing through.

Yup, that is the core plan here but Qaanol was taking extra measures to ensure batch purchasing didn't cause any problems, not realising that it doesn't cause any problems anyway.

@guy, on May 26 2007, 05:09 AM, said in Do "null" cröns work?:

Yup, that is the core plan here but Qaanol was taking extra measures to ensure batch purchasing didn't cause any problems, not realising that it doesn't cause any problems anyway.

I'd like to understand what you're saying here.

My reasoning went like this:

Let's say your pilot has 4 Docks.

You buy 3 Hayai bays. Now you have 1 dock.

Then you go to buy Akurui bays. You batch-purchase 4 of them.

What happens?

What happens is you only get one of them. If batch puchasing worked by always giving you the number you enter then there'd be nothing stopping you from over-purchasing any other items and ending up with negative free space, negative credits or more than the max allowed of that item. When you batch buy items it treats each one as an individual purchase and if the purchase requirements are not met for any one of them then it won't continue.

Oh, that's neat. I always assumed the game just did some integer division to find out the most you could buy considering free space, money, max and maxammo. It certainly seems to "know" how many you can get most of the time, putting that number as the default in the text-entry field.

Thanks lads. Given that I am now back from my holidays, I've started to implement it. But I now have another question: when you update the "onSell" of an oütf resource, will it be updated for the similar outfits your already has? Or will the pilot have to sell it and buy a new one for the whole thing to work?

(as you can guess, I'm starting to work on the "update cröns")

Well I can't say for sure but I will say with 90% certainty that whatever the current OnSell expression of an outfit is, that expression will get executed when the player sells the outfit regardless of what the OnSell expression was when he bought it.

How was your holiday?

'twas very nice, thank you, though rather hot. Not used to temperatures above 35°C, and the South of France, North of Italy and all of Slovenia (to name a few places where we were) were drowned in blistering heat.

I think I've found a way to make the "update for old pilots" work. I'll just have to test it now.

Gah. I'd forgotten about the other problem: ships with outfits.
When you sell a ship, the "onSell" of the outfit isn't taken into account, or is it?

Did the "on buy/sell d/gxxx" actually work? I had a similar thing in my plug, in which one weapon was supposed to have two functions: a large radius ionization and a PD ion beam. To do that I made the PD beam invisible and gave the large radius outfit the bit on buy gxxx and on sell dxxx. But for all my tinkering with it, that ended up bugging out; when I clicked "buy" on the outfit, it deducted the stated price of 500,000 credits, but neither outfit appeared. Same happened on selling it, it gave me back 125,000 credits, but the outfit stayed on my ship. Is it just me or something?

Yeah that's a known bug but easily worked around by making it Gxxx itself.

I'm pretty sure outfits aren't specifically 'sold' when you buy a new ship. What are you wanting to put in the OnSell field?

@pace, on Jul 24 2007, 09:32 PM, said in Do "null" cröns work?:

'twas very nice, thank you, though rather hot. Not used to temperatures above 35°C, and the South of France, North of Italy and all of Slovenia (to name a few places where we were) were drowned in blistering heat.

Heh, you should've come over my way

This post has been edited by Guy : 24 July 2007 - 10:01 PM

@guy, on Jul 25 2007, 02:57 AM, said in Do "null" cröns work?:

Yeah that's a known bug but easily worked around by making it Gxxx itself.

Ohhhhhhhhhhh

I wish I hadn't uploaded my teaser 4 minutes ago, I could have made that much smoother. Oh well, I'll do it for the complete version. :rolleyes:

@guy, on Jul 25 2007, 04:57 AM, said in Do "null" cröns work?:

I'm pretty sure outfits aren't specifically 'sold' when you buy a new ship. What are you wanting to put in the OnSell field?

I was hoping to use the OnSell field to give back a bay token, but it didn't work for the previous system, so it shouldn't here either. The problem being, if I have 3 bays on my ship (so 1 token) and decide to buy another ship instead (say with 1 bay), I'll only have one bay and one token (which was already a problem under the previous 'counter' system).
How on earth can I change that?

I was thinking of re-implementing a counter, but as I said, the counter doesn't help. So I'm at a loss.

Eh? When you buy a new ship, it will come with x bays and 4-x tokens. Any bays or tokens you had previously should not transfer to the new ship. Or am I missing the problem here?