Page 1 of 1
Air pad Limit..
Posted: 10 Apr 2007, 19:13
by Fanger
Currently from what I have learned, talking both to Trepan, doing a test myself, and hearing of input from Thor working on nota. I have confirmed that Airpads are limited to a max of 2 per unit. This is all well and good for some small building but if someone wants a giant supercarrier of doom.. well we need more than 2.. My request is simply for someone anyone to up the limit to 8, 32, 128 or what have you, anything above 2.. This would be really helpful..
Posted: 10 Apr 2007, 19:15
by Pxtl
So you mean the lower two pads on the 4-pad airpad in AA are actually totally decorative? Crappy. Is bad issue, given how many mods are trying to capitalize on the "fuel" system to make carriers.
Posted: 10 Apr 2007, 19:36
by Neddie
I believe at this point, 16 will serve all of our needs, but if you could remove the limit entirely, that would be preferable.
Posted: 10 Apr 2007, 19:51
by trepan
The "QueryLandingPad" COB call in RegisterAirBase is part
of the problem, the way COB handles call arguments is a little
messy.
I've got a patch to allow up to 16 pads per base if someone
wants to test it. We could also split up the QueryLandingPad()
into GetAirPadCount() and GetAirPadPiece() that would be
used as alternates for Spring.
Posted: 10 Apr 2007, 20:53
by trepan
I've committed a patch that should allow up to 16 pads per air base (SVN r3600).
It certainly seems to work with the ARM Air Repair Pad (ARMASP) unit, all four
pads are now used.
Posted: 10 Apr 2007, 21:10
by 1v0ry_k1ng
sorry if this is offtopic but do aircraft only use pads if they have no standing attack or patrol order?
Posted: 10 Apr 2007, 21:16
by trepan
Made another small change, if you really want more then 16 pads,
then you can define the "QueryLandingPadCount(maxPads)" call. The
input value for arg0 is the default maximum number of pads (currently
16), and the value that you set it to will be used as the maximum.
Posted: 10 Apr 2007, 21:16
by Zpock
Wow, this is a great fix. I thought it would get lost among the million other possible things that can be done. I was getting used to the tought of designing around it hehe.
Posted: 10 Apr 2007, 23:50
by zwzsg
trepan wrote:We could also split up the QueryLandingPad()
into GetAirPadCount() and GetAirPadPiece().
I don't see the needs for such additionnal function, since in OTA, you could have loads of air pad I've personnaly scripted 4 air pad carriers, and TheRegisteredOne made ... hundreds pads carrier, simply with the regular QueryLandingPad function. OTA worked like that:
QueryLandingPad(var1,var2,...,varN)
{
var1=pad_piece_num_A;
var2=pad_piece_num_A;
....
varN=pad_piece_num_A;
}
When a plane wanted to load, it would call the QueryLandingPad(...) of the carrier, and it would test each of the returned piece, one by one in the order, and would land on the first that had no unit already attached to.
The QueryLandingPad function could be written to not return always the same pieces, or the same piece but not in the same order,.... For instance a bad script would always present the same four pad in the same order, which mean that when four plane wanted to get repaired at once, they'd all four first try the first pad, only one managing to dock, then the three remainding would all try the second pad, etc..., while with a better written script, pads would always be presented in a shuffled order by the function, so four consecutive call would return the same pads but not in the same order.
Posted: 11 Apr 2007, 00:01
by trepan
zwzsg:
1. It's already done, I've added QueryLandingPadCount().
(check a couple of posts above yours)
2. The QueryLandingPad() call is only called once after a unit is created
in the Spring implementation (and for unit team changes). You can do all
the crazy randomizing you want, but it wont do jack. I made a simple
modification to allow a flexible number of landing pads without rewriting
the AirBase registration code. If you want to write a dynamic version, go
ahead

Posted: 11 Apr 2007, 00:05
by zwzsg

I would have thought keeping OTA compatibility AND less script function names to remember AND simpler and more versatile would have been better. Oh well, after all I aren't doing any mod with complex carriers, why should I be allowed to care?
Posted: 11 Apr 2007, 00:10
by trepan
A bug free exec with resync would also be better: step up!

Posted: 11 Apr 2007, 00:11
by Fanger
Thanks trepan.. sounds great..
Posted: 12 Apr 2007, 04:46
by Shadowsage
Great, now we just need to have move order onto landing pad=land.
Posted: 12 Apr 2007, 05:26
by Zpock
And ability to build planes on the carrier (moving factories), without using the script hack that I guess give the player a lot of hassle, to mount the factories on the carriers and stuff? Sorry if I'm ignorant.
Posted: 12 Apr 2007, 05:42
by Thor
Shadowsage wrote:Great, now we just need to have move order onto landing pad=land.
Agreed.