For Eve Incursion Waitlist: 0.16.2
If you are taking over an existing fleet, it will set you as the new fleet manager and you are done. If you are starting a new Fleet, the following additional steps are needed
there
to the right of their name to remove them
(They should have done that when leaving through)
If the eveapi is working and used you need to do Nothing, when the other Person
takes the fleet, it will automatically replace you as Fleetmanager. If the eveapi was
not working, and the manual way of setting a Fleetmanager was used, you
need to remove yourself from it by pressing the to the right of your
name.
When you are leaving fleet and you where the Fleetcommander or Backseat
remove yourself from the FC- or Backseats-Row using the to the right of your
name.
Shows/Hides the fittings
below the portrait accepts all fits from this character
Sends a Notification (make the gong go off) and poke (with the
message that the FC wants something from them) on TeamSpeak if they
are on there and their Charactername matches exactly (case sensitive and
no additions)
Remove a entry from X-UP, this does not affect that characters entries
in the Waitlists!
NEXT to a FIT, allows to approve this single fit, without approving
an of the other fits. To deny specific fits, you accept all fits that you want
to accept using next to the fit and then use to remove the X-UP
Entry.
to open a Fittingwindow (Figure
2). behaves exactly the same as in a X-UP Entry1.
removes them from the 3 type lists (dps/sniper/logi) but NOT from
the x-up list.
Sends the Notification (Gong) and a TeamSpeak poke if their
Charactername matches exactly (case sensitive and no additions). The
message contains the Waitlistname they were gonged from. This is mostly
there in case CCP fucks up the api or you need a person for something
else then inviting!
sends an invite to the person using eveapi. The character is
invited to the specific squad. This triggers the Notification and TS-Poke,
in the TS-Poke it is written which waitlist they were invited from
(dps/sniper/logi).TS-Pokes can be disabled on the X-UP Form, they are enabled by default. Inviting some one sets off a timer that check for the invite beeing accepted and then removes a found character from the Waitlist.
.
to the
right of your name.
.
Make sure the Fleet-Type you want to change to, has a X-UPs open and press
next to your Fleet. You will get a Screen like this 
where you can
select the Fleet-Type you want to change to, if a Waitlist is not Open, it’s
type will not be listed here! Press and your fleet should now be listed
under the other Waitlistsettings. FCs needs to manually remove them selves
from the old Waitlistgroup-Settings and add himself to the ones of the new
Type.
These Settings are used for the TS-Poke.
Should only be changed if the TS-Server is changing (e.g. going to a backup TS)
Select a TS-Server from the Dropdown and press 
to make the TS-Bot change
server
Under Default Character fill in the character name you want to use, then press
.
Ship Classification is used to sort submitted fits into the different waitlists and assign tags to them. There are Collections and Checks. A Collection contains Checks and Each Group of Waitlists can only have one Collection assigned to it while each Collection can also only be allotted to one Waitlist Group.
A Collection, is a Collection of Check that will be applied to fittings. Each Collection has it’s own name and Waitlist-Group it assigned to. Further they have a default Waitlist and Tag, these get assigned to Fittings if none of the Checks match.
Each Check is part of a Collection. They have a Name that is only there to make them more easy to be identified by humans. Further they have target Waitlist and Tag that is assigned to Fittings which match the Checks rules.
Ordering of Rules Each Rule has an order Attribute which defines the order in which they are executed. Lower Order numbers get applied first. If more then one rule have the same priority then module rules are applied before hull rules. If more then one hull rules are of the same priority they are applied in arbitrary order. If more then one module rule are of the same priority the get applied in the same pass. For more info Module Rules
Hull Rules There is 3 different types of rules that match against the hull type. You can match by type-id, inventory-group-id or market-group-id.
Module Rules There is two different types of rules for matching against highslot modules. They can be matched against type-id or market-group-id.
Additionally for these rules you can set restrictions by type-id, inventory-group-id or market-group-id regarding the hull these modules are on. If there is no restriction set the rule applies for all hulls. If there is multiple restrictions set the hull must match ANY of them to be applied.
For module rules there is an modifier attribute that allows to have a specific rule be worth more then an other. When module rules are applied, all the module rules with the same priority get applied at random order, while a module gets filtered out after being matched by one rule. When a type-id is matched it gets the modifier of the rule assigned as value.
After all highslot modules are check the module that accumulated the highest value is selected. This way there could be rules for e.g. Blaster with a modifier of 1.00 and a rule for Large Remove Shield Booster with a modifier of 2.00. Now if a Vindicator has 4 Blaster and 3 Remote Shield Booster the result would be a score of 4.00 for the Blaster rule and a 6 for the Remote Shield Booster. And in the end it would get assigned the Tag and Waitlist of the Remote Shield Booster rule.
If the value is not at least 4.00 the result is treated as if the rules would not have matched.
There is a script setup_shipclassifications.py bundled with the waitlist that allowes for generating some rules you can start from. This script assumes the setup_waitlists.py was used to setup default waitlists.
