But to answer your question, the Variable you're looking for is Ability Code.
@Mordeltho Under the hood it's also just an integer variable, but GUI classifies them differently to try to prevent dumb user stuff. In some cases treating it directly as an integer can be preferable (for example you can't store an abilitycode in a hashtable in GUI because it literally will not let you, but you
can store an integer easily).
As Uncle alluded to there are two 'kinds' of ability variables. Abilitycode (integers internally) refer to the overall ability as a whole; you might say: "The blizzard spell that Archmages can learn". Most of the time you just need to use abilitycode variables to do whatever you need to do because telling the game "remove the 'Archmage Default Blizzard' type spell from Triggering Unit" does what you need it to do.
A few patches ago Blizzard (re)introduced
actual ability instance variables that refer to a specific instance of an ability on a specific unit. They did this because it's now possible to modify a specific instance of an ability rather than the ability as a whole. "This archmage's Blizzard costs 50% less than every other archmage's Blizzard" is something you could do with these ability instance variables without having to have an actually separate version of the ability for each unit whose Blizzard should act uniquely in some fashion.
When they find a new weapon, I want them to switch it out and lose the previous abilities gained. I'll have several potential abilties so unless I code it to remove every single passive given by weapons, I cant just code it to remove the ability.
Along with this functionality to set ability fields dynamically at runtime on a per-instance basis Blizzard introduced the ability to
read many Object Editor fields at run-time. This means it's now possible to load and read the list of abilities attached to a given item! You could proceed this way by storing the abilities directly on the manipulated weapon object, then loading the rawcodes of the relevant abilities by reading the object's data fields, and then adding/removing those abilities (by rawcode, which is effectively an abilitycode) as desired.
Another solution is to build your own database in a hashtable. You would use the manipulated weapon object as a parent key in your hashtable and store the relevant information in that hashtable at map init. When a unit manipulates one of these weapons you look in the hashtable under that weapon as a parent key, using the child keys for different things you might want to return. Think of them as x,y coordinates but instead of numbers they can be objects or strings or numbers or anything. Longsword,NumAbilities might return 3, telling you that there are 3 associated abilities with the Longsword. Then you read Longsword,Abil1 and Longsword,Abil2 and Longsword,Abil3 to learn what those abilities are.
IMO grabbing that info directly by reading the OE data fields would be easier, but both are acceptable solutions.