Setting equipment mounting time in ICE

DonKarnage · Post by **DonKarnage** » Wed Aug 03, 2011 4:52 am

As far as I know there's not a way to define the time it takes to mount equipment, if we had a way to set the arming time individually (And defaulting to a global value if not defined), it could open up some possibilities.

Just to name a few things that could be done:
Having certain guns be optimized for switching out and reloading quickly.
Shields that equip instantly and begin charging immediately, rather than taking 3 seconds before they even begin to recharge a few hitpoints, yet still raise signature.
Boosters capable of running without significant delay between tanks

This could maybe also allow for such things to be used as faction perks, ie. 20% faster reload, quick arming nannites, 30% faster prox mine deploy rate, etc.

KGJV · Post by **KGJV** » Wed Aug 03, 2011 12:42 pm

this can be done :

- at the 'part' level : that is a new value attached to a part (weapon,shield,cloak,etc)
- at the 'ship' level : that is a new value attached to each hull type
- at the 'slot' level : that is a new value for each mounting slot of each hull type

or all 3 of them, mount time been the total product (default been 1.0 for ship and slot)

do you also want a GA for this ? allowing 'faster mount time' devels and faction values.

also mount time is one thing, activation time is another (that one is at the part level only I presume).
so that's another distinct new value and eventually another GA too.

I don't see any big code change here , it's pretty simple to do actually BUT it implies a core format change and that's another story...unless we can find unused values in current core format to store these new values (but GAs are full, no spare room left here).

Meanwhile there is a global value that affects all mount rates (10/0A MountRate, default = 0.2).
It's core wide but it's there and (should) work.

madpeople · Post by **madpeople** » Fri Aug 05, 2011 11:10 am

I'd vote for part level at least.

I once wanted to make hunter killers lock on and arm much like quickfires, but then take a long time to reload when you emptied a rack of them.

Imago · Post by **Imago** » Fri Aug 12, 2011 11:07 pm

The IGC already has 'LOAD TIME' for all Expendables (Chaff, Mines, Missiles and Probes)

as seen in http://freeallegiance.sourceforge.net/pub/...Cores/cc_06.zip

Edit: If you need help (hand holding) getting it changed let me know.

TurkeyXIII · Post by **TurkeyXIII** » Sat Aug 13, 2011 1:56 am

That's the arming time. We're looking at something that controls the mounting time; ie the value currently controlled by the global MountRate.

Imago · Post by **Imago** » Sat Aug 13, 2011 5:37 pm

Gotcha. So rename LOAD TIME then to be what it actually is doing (ARM TIME) and make a new MOUNT RATE value for each EXPENDABLE and that would be worth the effort IMHO

Edit: give me the ticket # in Trac and I will give you an appropriate patch file

BillyBishop · Post by **BillyBishop** » Mon Aug 15, 2011 4:00 pm

KGJV wrote:QUOTE (KGJV @ Aug 3 2011, 12:42 PM) do you also want a GA for this ? allowing 'faster mount time' devels and faction values.

Yes. Variety is the spice of life, and Garr would be happy with a GA.

lexaal · Post by **lexaal** » Mon Aug 15, 2011 8:12 pm

I think we need an more advanced method to define aleph resonators than the current.

KGJV · Post by **KGJV** » Mon Aug 15, 2011 9:27 pm

Actually, the more I read topics like this one, the more I think about adding scripting server side so that people can do their own experiment and try ideas without depending on C++ coders (and the whole 'build & publish' administrative pipeline).

Because with the current system, we're kinda stuck in a sort of a deadlock: we have 2 populations; one population (core devs) that cannot try new stuff or ideas to see if they're worth adding to the game without requiring the other population (devs) implementing code changes. But these later can't (or won't) afford to make these changes if they're not worth adding. See the problem.

And 'worth adding' isn't the only criteria (threshold) of the deadlock here, 'interest' and 'perception of the gameplay (personal taste)' are other criterion. Add to that schedule issues and 'fade of interest for an idea over time' plus plenty other human factors and then you'll understand why since we have Allegiance source (February 5th, 2004) NOT A SINGLE CORE CHANGE WAS MADE yeah that's more than 7 years... (the single-sided resonator doesn't count since it was a '5 minutes to do' hack involving no change of format or internal structures).

So 1st, I'll let some weeks pass to see if the FreeSpace project goes anywhere but meanwhile I'll start working on bringing "scripting inside cores".
I've started to reactivate the Pigs which are automated players (bots). Their initial purpose is to stress test the network and server codes but since they use scripting they might be a good foundation to bring scripting inside the game logic. (Those who can compile the code can checkout the latest R6 to get the updated Pigs code. I'll post a topic soon explaining how they work)

Sure it's a bigger change than to add a few properties here and there in the cores but, then again deadlock effect, I'm not convinced that adding these few properties is worth the effort. Is adding scripting worth the effort ? well not sure either but I'm sure it'll stop people from asking this or that because they'll do it themselves.