need help w/ complex condition AND + OR

[johnnylump]

:) I just ran the same test, ItemBalance=(eItem=eItem_SHIVSentry, iCash=999, iElerium=50, iAlloys=60, iTime=21, iEng=13)

 

Confirmed it works.

[Amineri]

I've never used Modpatcher to try and edit the DGC.ini so I can't say whether it provides the same capability to freeform edit the DGC.ini, but Resource Hacker definitely does.

 

I think this will make life a whole lot simpler ...

 

Now if I could only figure out a way to use this to circumvent the ItemIsWeapon() and ItemIsAccessory() checks for building Item Cards, I'd be happy.

[anUser]

Great finding guys. Now if someone of you ever find a conditional with an AND and an OR remember to visit this post again :p ... I'm just wondering now, maybe you that have looked at the code could tell me... if that ini info is processed by a function, would it allow some kind of code there?

[Amineri]

Oh ... I've written code with ANDs and ORs mixed together. The order is important, else you might end up with logical errors, although it shouldn't cause the game to crash.

 

Looking at the IsClassEquippable, it looks like some overzealous coder circumvented the later switch/case eWP_Heavy property check with the earlier code segment:

 

if(eClass == 2)
{
// End:0x1AF
if((((TACTICAL().WeaponHasProperty(eItem, 8) || eItem == 85) || eItem == 88) || eItem == 76) || eItem == 77)
{
return true;
}
// End:0x1B1
else
{
return false;
}
}

 

The function will always return from this with either true or false (for Heavy class), and will never get to the later switch/case statement checking weapon properties. Essentially this segment is forcing only eWP_Heavy weapons, and the Medikit(76), Combat Stims(77) and Frag Grenade (85), and Alien Grenade(88) to return true for Heavy class.

 

However, this code is somewhat redundant, as the earlier conditional:

 

if((((((eItem == 80) || eItem == 76) || eItem == 79) || eItem == 78) || eItem == 81) || eItem == 82)
{
return true;
}

 

already made the Medikit(76) class-equippable for ANY class. (In addition to a few other generic items).

 

I can only imagine that the first code segment was added as a sort of hack because of the following two conditions:

 

if(TACTICAL().WeaponHasProperty(eItem, 3))
{
return true;
}
// End:0x215
if(TACTICAL().WeaponHasProperty(eItem, 2))
{
return true;
}

 

The first returns true for any weapon with eWP_AnyClass, and the second returns true for any weapon with eWP_Pistol. I guess it was all about restricting Heavies from being able to equip pistols....

 

However, a more robust way to do this would be to change the conditional to:

 

if(TACTICAL().WeaponHasProperty(eItem,2) && eClass != 2) ...

 

This would specifically prevent Heavies from using pistols, but all of the other Weapon Property code would work (and that specific check for Heavies) could be removed.

[Amineri]

As far as the mixing of AND and OR statements --

 

Here is a snippet of code I wrote / modified from the original:

 

return (((iItem > 1) && iItem < 55) || (iItem > 84) && iItem < 100) || (iItem > 112) && iItem < 117;

 

Here is the breakdown of how I wrote the hex code for it:

 

 

 

04 -- return

84 -- or

84 -- or

82 -- and

97 -- >

00 EE 77 00 00 -- local iItem, using reference from ItemIsAccessory

26 -- int 1

16 -- execute >

18 0E 00 -- skip token, 0x0E = 14

96 -- <

00 EE 77 00 00 -- local iItem, using reference from ItemIsAccessory

2C 37 -- int 55

16 -- execute <

16 -- execute and

18 20 00 -- skip token, 0x0020 = 32

82 -- and

97 -- >

00 EE 77 00 00 -- local iItem, using reference from ItemIsAccessory

2C 54 -- int 84

16 -- execute >

18 0E 00 -- skip token, 0x0E = 14

96 -- <

00 EE 77 00 00 -- local iItem, using reference from ItemIsAccessory

2C 64 -- int 100

16 -- execute >

16 -- execute and

16 -- execute or

18 20 00 -- skip token, 0x0020 = 32

82 -- and

97 -- >

00 EE 77 00 00 -- local iItem, using reference from ItemIsAccessory

2C 70 -- int 112

16 -- execute >

18 0E 00 -- skip token, 0x0E = 14

96 -- <

00 EE 77 00 00 -- local iItem, using reference from ItemIsAccessory

2C 75 -- int 117

16 -- execute <

16 -- execute and

16 -- execute or

EDIT: I was dumb and pasted the wrong broken down hex segment *blush* -- this is now the correct breakdown

 

Edited April 9, 2013 by Amineri

[Amineri]

The IsClassEquippable function can certainly be cleaned up quite a bit. Part of the problem is that many items that should be equippable on any class are not marked with eWP_AnyClass. The only items that are so marked are (1) all of the grenades, even those not made -- smoke grenades, battle scanners, psi grenades (2) medikit (3) combat drugs.

 

NOT marked are (1) Reinforced Armor (2) Chitin Plating (3) Targetting Module (Scope) (4) Mind Shield

 

If all of the items were properly marked, then most of the "special item checks" could be removed. The only one that would have to be especially kept in would be the one to prevent pistols from being equipped to Heavies.

 

If you wanted to get rid of the Rocket Launcher for Heavies, and give them LMGs + pistols, you'd have to make a couple of other changes :

1) In XGFacility_Lockers.GetNumInventorySlots, it returns 2 for Heavy and 1 for all other classes (to accomodate the Rocket Launcher)

2) In XGFacility_Lockers.EqupPistol, the if(kSoldier.GetClass() == 2) {return false} would have to be removed.

 

.... and maybe a few others that aren't immediately obvious.

[anUser]

Ok thanks, now I see it... I wasn't using the skip token after the AND... why does it want to know how many positions in memory it's to skip if it has to evaluate BOTH conditions? I understand that in an OR condition where if first evals true it skips evaluating the second one, but here? Damn, it doesn't make any sense to me... well, at last I got it, and in the process of locating and fixing this I've debugged all my mods... hehe :p

 

ps: you're so right, that is a mess. I just wanted to make a quick edit to play around with new items and trying to make 'em grant abilities (grapple & shredder rocket being flashbang grenades) but couldn't go any further. It would need a deep re-planning, but I'd like to know first for sure what are the limits of what can be modded and what is definitively hard coded, 'cause there are quite a few things relating classes that are opaque (an example being the heavy secret rocket slot, which is a different number of slot, and most flagrantly heavy class having reduced ammo capacity, or increased ammo cost, when it should be right the opposite). In any case it would be always possible to just swap classes so yeah any re-rwitting would be good

Edited April 10, 2013 by anUser

[Amineri]

If the first statement in an AND operation is FALSE, then the second statement can be skipped because the entire AND operation is FALSE.

[anUser]

If the first statement in an AND operation is FALSE, then the second statement can be skipped because the entire AND operation is FALSE.

LOL that's true! my bad... hehe all these days I never gave it a second thought... from all the things I've tried this wasn't going to be one of the first 100 or 200 I'd try...