Basically, this code should check the item you are enchanting if it has
APPLY_FIRERESIST already on it, if it does, it sets resistance to true. // this all works
Next, it will check which essence you are using // This works too
Then it will see if resistance is true, if so it checks to see if location is apply_fireresist
once again, and if it is, it just ADDS to the current # of fire resist on that object.
I have the code commented on what works and doesnt.


for ( paf = obj->pIndexData->affected; paf != NULL; paf = paf->next )
{
if ( paf->location == APPLY_FIRERESIST )
{
send_to_char("Gets here.!\r\n",ch); // Gets here
resistance = TRUE;
}
}


if (!str_cmp(obj2->name, "poor essence fire"))
{
if (resistance)
{
send_to_char("Gets here too!\r\n",ch); // Gets here

for ( paf = obj->affected; paf != NULL; paf = paf->next)
{
if (paf->location == APPLY_FIRERESIST)
{
send_to_char("Doesn't get here.\r\n",ch); // Doesn't get to here.
paf->type = 0;
paf->modifier += 1;
paf->level = 1;
}
}
}
else
{
// After the else, it adds a new effect because resistance isnt found as TRUE.
// This part also works correctly.

What's the difference between obj->pIndexData->affected and paf = obj->affected?

The indexdata is the actual MAIN object. The one without is the one the player is holding.

For whatever reason, if I change the
for ( paf = obj->affected; paf != NULL; paf = paf->next)
{
if (paf->location == APPLY_FIRERESIST)
{
send_to_char("Doesn't get here.\r\n",ch); // Doesn't get to here.
paf->type = 0;
paf->modifier += 1;
paf->level = 1;
}
}
to a for loop using pIndexData, it works, however it actually changes the main object instead of just the one the player has. Thus affecting that object at it's core.
for ( paf = obj->pIndexData->affected; paf != NULL; paf = paf->next)

I don't get why obj->affected doesn't work, it works in other various aspects of the code ive used. It should just affect the obj
the person is enchanting however, it skips it entirely if I leave the for loop without pIndexData

I am assuming you're using a Diku variant probably along the merc side of the family tree. Unless you've made significant changes to how affects work, affects are somewhat more complicated than you're assuming.

IIRC, when an object (obj) was created from its prototype (obj->pIndexData), the affect list of the object was initially empty and the (obj->enchanted) flag is FALSE. So your object has no affects where (paf->location == APPLY_FIRERESIST) for your loop to modify. The first thing you have to do when enchanting (or disenchanting) an object is set (obj->enchanted = TRUE). This tells you (and the stock code) to ignore the affects from the list (obj->pIndexData->affected) which are now supplanted by the list (obj->affected). Then, unless you're disenchanting, you want to duplicate each of the affects from the (obj->pIndexData->affected) list to the (obj->affected) list. Finally, you modify the affect from (obj->affected) where (paf->location == APPLY_FIRERESIST) with your +1 bonus.

C-like pseudocode:

if( obj->enchanted == FALSE ) {
    obj->enchanted = TRUE;
    // Copy affects from the prototype to the real object
    // This is sloppy – the copied affects will be in reverse order if that kind of thing bothers you
    for( paf = obj->pIndexData->affected; paf != NULL; paf = paf->next ) {
        naf = clone_affect( paf );
        naf->next = obj->affected;
        obj->affected = naf;
    }
}

// Find and modify the fireresist affect.
for( paf = obj->affected; paf != NULL; paf = paf->next ) {
    if( paf->location == APPLY_FIRERESIST ) {
        paf->type = 0;
        paf->modifier += 1;
        paf->level = 1;
        break;
    }
}

if( paf == NULL ) {
    // No fireresist affect exists on this object.
    // So create a new APPLY_FIRERESIST type affect here and attach it to the object.
}

I no longer remember the names of all the affect functions – implementing and/or finding the real name of clone_affect() is left as an exercise.

Yeah, I looked through most of the files and I don't see a void clone_affect ( ); Basically are you saying it needs to duplicate the exact affects on an object?

(Not long after…)
20 minutes later….
He made it work correctly, thanks to that gentleman's post above.
Dooky way of ROM's affects live on!

Affects are overly complicated in ROM indeed, and if you ever code spell that change affect flag, you need to reapply flag when a spell fall down and remove an affect because they are coded as a true or false and not in a stack effect (basically you have NO easy way to know if a flag has been affected more than once)

Have two spells that affect the char with poison, one spell fade, the poison flag disappear, even when the other spell that give it too is still there.
that can happen with equipment that gives an affect (or cast a spell when being wore, change of race etc etc etc)…

It's been a while since I've done much with stock ROM, but I would think you could fix affect_remove_obj() to take care of those flags if it doesn't already.

IMO, the main problem with ROM affects is that the stock interface (affect_* functions) is clunky. There's nothing wrong with a complicated-but-efficient implementation as long as it's behind a nice interface.