Inf-info.xls

Snakeye · May 18, 2009

GalZohar said:
I don't know, man, if it works fine with 80, 300 is likely to not be that big of a difference. Do we even know how the original INF "check bulk" function works to compare their complexities/run times? I wouldn't rule out a 300 array without trying it, assuming the 80 works fine. And obviously common items can be placed first.

I wouldn't say I know exactly how it works, but I've got a vague idea, which already scares me enough - plus I never claimed the 80 one works, I just said he compiled one for 80..

GalZohar said:
Adjusting the bulk on every item combination is not that big of a deal. Like I said there are less than 300 of them, and if excel makes the INI all I need to do is make the "INI maker" tab read the "desired bulk" values from the "mass" tab. M4A1 with acog for example would add up the bulk of the M4 with the bulk of the acog, so later adjustments are quick and easy. I just need to know if there are items I shouldn't include or items I need to include before other items, as well as an XLS that actually accepts 300 items, as I don't understand exactly how the XLS's INI generator works.

Well, whatever floats your bow - just remember it's not only ALL of them but ALL of them in the RIGHT ORDER. Plus you'll need to spend a time checking for common mutator configurations to see if they work when placed in various orders. It's not just a "slap together an Excel file and compile it" - if you intend to do that seriously you'll spend more time testing it than you spend for all the rest, plus I'd suggest for an online test to investigate issues that only happend online.

GalZohar said:
Anyway, realistic bulk is not going to happen without completely overhauling the bulk values, since a lot of items are too heavy yet reducing their bulk by 1 would make them too light, as well as items that are too light but increasing their bulk by 1 would make them too heavy. Besides, most items need their bulk values changed at least by a little regardless of the "rounding issues".

I'm not talking about realistic bulk, but about achieving the best possible result with the least possible effort - and as easy as it may seem now, I can tell you you'll run into more serious issues doing this the hard way than you might think now - not that I want to disgcourage you..

Anyway, 300 limit .u-file attached (think so at least

) - I hope Stm doesn't disapprove..

GalZohar · May 18, 2009

Well I at least don't expect it to work with any other bulk-modifying mods, since, well, the whole purpose of this is to fix bulk issues by itself. Issues with non-bulk-related mods will have to be investigated when they're discovered.

What order is needed? Modifications before "plain"? Anything else needed?

Would still make my life easier if the excel file supported 300 as well, though I can work around that with a bit of extra effort.

Kueltag · May 18, 2009

Snakeye said:
plus I never claimed the 80 one works, I just said he compiled one for 80..

It does. I entered 78 items (with the xls it was just a few minutes!), and checked all modified items plus many of the unmodified ones. Everything was okay. The sad thing is you really have to care about the sequence.

Here's my list (that has been checked). It compensates for RL masses (+ or -) and brings down too heavy weapons (like M136).

[INFCustomBulk.INFCustomBulk]
bLog=False
ClassBulk[0]=INF_Core.INFc_FSVEN 4
ClassBulk[1]=INF_Core.INFc_FSVENClip 1
ClassBulk[2]=INFMOD_AKM.INF_AKMS_Drum 5
ClassBulk[3]=INFMOD_AKM.INF_VOG25pAmmo 1
ClassBulk[4]=INFMOD_AKM.INF_AKMSGP25 22
ClassBulk[5]=INF_Equip.INFe_AN_M8W 1
ClassBulk[6]=INF_Equip.INFe_Claymore 5
ClassBulk[7]=INF_Bonus.INF_nBC 1
ClassBulk[8]=UN_HandgunFix.UN_DE50 8
ClassBulk[9]=INF_Mutators.UT8Ball 30
ClassBulk[10]=INF_Mutators.UT8BallAmmo 5
ClassBulk[11]=InfWeaponEnhancement.IWE_FAMAS 18
ClassBulk[12]=INF_Core.INFc_AttachFAMAS_ACOG 2
ClassBulk[13]=INF_G36KImproved.CS_WeaponG36K 15
ClassBulk[14]=INFMOD_HK416.INF_HK416 15
ClassBulk[15]=INF_Core.INFc_HK69Shell 1
ClassBulk[16]=INFMOD_M4A1.INF_ParachuteFlareShell 1
ClassBulk[17]=INF_Core.INFc_HK69SmokeShell 1
ClassBulk[18]=INFMOD_HK416.INF_HK416M203 19
ClassBulk[19]=INFMOD_HK416.INF_HK416M203sup 21
ClassBulk[20]=INFMOD_HK416.INF_HK416M203RXsup 22
ClassBulk[21]=INFMOD_HK416.INF_HK416M203RX 20
ClassBulk[22]=INFMOD_HK416.INF_HK416sup 17
ClassBulk[23]=INFMOD_HK416.INF_HK416RXsup 18
ClassBulk[24]=INFMOD_HK416.INF_HK416RX 16
ClassBulk[25]=new40mm.newHK69 8
ClassBulk[26]=new40mm.M397Shell 1
ClassBulk[27]=new40mm.HEDPShell 1
ClassBulk[28]=new40mm.BSShell 1
ClassBulk[29]=INF_Bonus.INF_nAT4RL 20
ClassBulk[30]=INFMOD_M14DMR.INF_M14SupScop 25
ClassBulk[31]=INFMOD_M14DMR.INF_M14Scope 23
ClassBulk[32]=new40mm.M397Shell 1
ClassBulk[33]=new40mm.HEDPShell 1
ClassBulk[34]=new40mm.BSShell 1
ClassBulk[35]=INF_Core.INFc_AttachM16A2_ACOG 2
ClassBulk[36]=INFMOD_M16A4.INFc_IncendiaryShell 1
ClassBulk[37]=INFMOD_M16A4.INF_M16A4M203supSL 29
ClassBulk[38]=INFMOD_M16A4.INF_M16A4M203SL 27
ClassBulk[39]=INFMOD_M16A4.INF_M16A4supSL 24
ClassBulk[40]=INFMOD_M16A4.INF_M16A4LAMsupSL 25
ClassBulk[41]=INFMOD_M16A4.INF_M16A4SL 22
ClassBulk[42]=INFMOD_M16A4.INF_M16A4LAMSL 23
ClassBulk[43]=INF_Equip.INFe_M18R 1
ClassBulk[44]=INFMOD_M4A1.INF_M4A1ACOGsupFL 20
ClassBulk[45]=INFMOD_M4A1.INF_M4A1ACOGFL 18
ClassBulk[46]=INFMOD_M4A1.INF_M4A1M203ACOGsup 24
ClassBulk[47]=INFMOD_M4A1.INF_M4A1M203ACOG 22
ClassBulk[48]=INFMOD_M4A1.INF_M4A1ACOGsup 19
ClassBulk[49]=INFMOD_M4A1.INF_M4A1ACOG 17
ClassBulk[50]=INFMOD_M82A1.INF_M82A1mag 4
ClassBulk[51]=INFMOD_Nades.INF_M83Ammo 1
ClassBulk[52]=INFMOD_M93R.INF_M93R 5
ClassBulk[53]=INFMOD_M93R.INF_M93RMag 1
ClassBulk[54]=INFMOD_MAG7.INF_MAG7 17
ClassBulk[55]=INF_Bonus.INF_MiniUzi 11
ClassBulk[56]=INFMOD_MP5A2.INF_MP5A2 12
ClassBulk[57]=InfWeaponEnhancement.IWE_MP540 13
ClassBulk[58]=INF_Core.INFc_AttachMP5A3_Silencer 2
ClassBulk[59]=INFMOD_OICW.INF_XM29GLAmmo 4
ClassBulk[60]=Bob.bob_mk23 3
ClassBulk[61]=INF_Core.INFc_P90Clip 2
ClassBulk[62]=INF_M4A1_RO979.INF_M4A1_RO979_NGZ_N_HEIShell 1
ClassBulk[63]=INF_M4A1_RO979.INF_M4A1_RO979ACOGsupFL 20
ClassBulk[64]=INF_M4A1_RO979.INF_M4A1_RO979ACOGFL 18
ClassBulk[65]=INF_M4A1_RO979.INF_M4A1_RO979M203ACOGsup 24
ClassBulk[66]=INF_M4A1_RO979.INF_M4A1_RO979M203ACOG 22
ClassBulk[67]=INF_M4A1_RO979.INF_M4A1_RO979ACOGsup 19
ClassBulk[68]=INF_M4A1_RO979.INF_M4A1_RO979ACOG 17
ClassBulk[69]=INF_Core.INFc_SIG551 16
ClassBulk[70]=INF_Core.INFc_AttachSIG551_ACOG 2
ClassBulk[71]=INFMOD_UDAR.INF_UDAR 5
ClassBulk[72]=INFMOD_VSSV.INF_VSSV 13
ClassBulk[73]=dukeXM8b.dukeX_M8 13
ClassBulk[74]=INF_Equip.INFe_ArmorVestL3a 10
ClassBulk[75]=INF_Core.INFc_Pickup -1
ClassBulk[76]=INF_Core.INFc_Ammo -1
ClassBulk[77]=INF_Core.INFc_Weapon -1

BTW., why not make 1 bulk = 0,01 kg. It would make things easier.

Kueltag · May 18, 2009

GalZohar said:
Would still make my life easier if the excel file supported 300 as well, though I can work around that with a bit of extra effort.

I'll increase that to, say, 1000. Maybe tomorrow. Then I'll upload it here.

GalZohar · May 18, 2009

If you scroll back a bit you'll see I already posted a modified "inf-info.xls" file that has "desired bulk" values on the "mass" tab using fine-tuned bulk with 0.02KG = 1 bulk. Just need to turn them into an INI in the correct order (and I'm still not sure what exactly is "correct order"). Combine that with player bulk adaptation mod with the below settings and you get something that should be pretty true-to-life.

[INF_PlayerBulkAdaption.INF_PlayerBulkAdaption]
CustomBulkPercentage=1.00
CustomStandardBulk=-1170
CustomBulkDivisor=99999
CustomBulkSpeedDivisor=1170

Not 100% sure about the "not losing stamina" thing but I don't know how to scale stamina in a way that will make sense, the only options are to set it to the same as BulkSpeedDivisor or to set it to a very high value. Anything else would just feel wierd, as like the current system it'll stay at 0 loss up to a certain bulk value and then start to drop quickly past it. That is, if you set CustomBulkDivisor to more than 1170 it'll make bulk have little effect on stamina, and if you set it to less you'll have even a 0 bulk loadout start with less than 100% stamina. Keep in mind stamina decays over 2X slower than speed with default settings, which is impossible to maintain if you want a more logical bulk system that starts slowing you down past 0 bulk.

Snakeye · May 19, 2009

GalZohar said:
What order is needed? Modifications before "plain"? Anything else needed?

To understand this you'll need to know how the classes are derived and identified in the CustomBulkMod.

The latter first: CustomBulk uses a check if a class is a child of a reference class. This check if true if it's the same class or a derived one [if you don't have any idea what I'm talking about a quick lesson of object oriented programming would be in order]. If CustomBulk passes a check it will assign the bulk value to the item - so putting INFc_weapon first would result in all weapons having the same bulk, since all weapons in INF are derived [children of] from that class.

Now the classes for most custom weapons use a "base class", which is derived from INFc_Weapon (excpetions apply*) and the various attachment combinations are derived either from the base class (for single attachments) or from a derived class (for double attachments) or a derived, derived class (for triple attachments).

The point you'll have to pay attention to is, that the classes which have NO further classes derived from them must be put first, since the child-of-check will identify just this class. To find out the correct order you'll need to either read the source code or - much more convenient - fire up UnrealEd and take a look at the actor browser, since it shows dependencies nicely. Note that you'll need to load the Inf related packages either by including them somewhere in the ini or manually in UnrealEd - loading manually is a tad boring since UnrealEd doesn't seem to remember the packages when started again (at least on my system).

Oh and when I said load order dependency troubles I meant it. MicroBulk doesn't work depending on where it is put in the mutator list even if NO OTHER explicit bulk influencing mutator is present - note that ALL custom weapons do use a modification for the CheckItemBulk function, since otherwise the function wouldn't recognize their classes.

Plan at least two or three weeks of testing, which should include a plausible method to check the bulk for every item in that list - otherwise you might end up with wrong bulk values as was present in the original M4. Also include commonly used mutators for the testing and write down the order in which you can confirm they work. I hope I don't leave the impression of being too much of a nagger, but I'm not sure you understand the scope of the modification you intend to do..

*The Hk416 is actually derived from the M4

GalZohar · May 19, 2009

What happens in general if 2 mutators override the same function? I mean, if a mutator overrides custombulk's function for checking item bulk there's nothing I can do about it (unless it can be solved by changing the mutator order or something).

It seems like life would be a lot easier if you simply replace the "ClassIsChildOf(A, Classes)" with "Classes.IsA(A)". That way I no longer care about the class structure, and it doesn't make my life any harder in any way since I'm modifying the bulk of everything anyway.

For bulk purposes, I'm not supposed to care whether or not HK416 inherits from M4A1 or not, and making that change will make it work that way, solving the INI ordering problems. I may have to place all possible combinations in the INI, but that's something I had to do regardless.

Kueltag · May 19, 2009

Upped to 1000.

Snakeye · May 19, 2009

GalZohar said:
What happens in general if 2 mutators override the same function? I mean, if a mutator overrides custombulk's function for checking item bulk there's nothing I can do about it (unless it can be solved by changing the mutator order or something).

In general all load order dependency problems can be solved with changing order - although I do think to remember using MultiMut does cause troubles on its own, since it doesn't seem to keep the order as in its ini, but I digress. From what I could find with my limited knowledge, there is no such thing as "happens in general" with UT/Inf - you'd have to look at every case for itself.

GalZohar said:
It seems like life would be a lot easier if you simply replace the "ClassIsChildOf(A, Classes)" with "Classes.IsA(A)". That way I no longer care about the class structure, and it doesn't make my life any harder in any way since I'm modifying the bulk of everything anyway.

It would make your life easier [actually it won't ]. Remember I didn't write that mutator in the first place - although I would be willing to investigate alternate possibilities to solve the problem if Stinkmarder allows it*. Plus your suggested way [using IsA] is just a fancy way of checking if an object is that class or a derived one - but you just need the name of the class instead of the class. UnrealScript is fun, isn't it?

Just to actually try and be helpful, IIRC there is a way to check if the class name is the same as a given string, which might possibly work for your case.

GalZohar said:

For bulk purposes, I'm not supposed to care whether or not HK416 inherits from M4A1 or not, and making that change will make it work that way, solving the INI ordering problems. I may have to place all possible combinations in the INI, but that's something I had to do regardless.

Click to expand...

Well, from a bulk perspective no, but from the perspective that you want to create nothing less than a complete bulk overhaul then YES you should care - and a lot if you ask me. Messing around with things you don't at least vaguely understand can cause severe problems [I know, I ran into enough while doing a few little mutators]. If you actually intend to get that bulk overhaul on a server you should be willing to do a lot more than just slap together an XLS and auto-generate an INI. I know it's actually work - and a lot of it - but unless you spend a significant time understanding the basic environment you're working in and then some more time testing your modifications to that environment the final product might as well cause more trouble than you intended to.

I guess I'm a bit of a nagger again, but then working a while [seems like an eternity to me] testing automotive/embedded software transform one into a misantropic pessimist.

*I know I'm a tad strange on this point [probably not only on this point ], but I don't like to mess around with other peoples work without their permission.

GalZohar · May 19, 2009

A short test concluded that custombulk works great for some items and doesn't work at all for others. It seems some items simply keep their original bulk values. Setting all bulk values to 9999 can easily let you come up with a list of which items "refuse to listen" to custombulk. It doesn't seem to have something to do with whether or not the items are inf-original or not. I'll post/edit if I find a trend regarding which items "react" and which don't.

Anyway, PlayerBulkAdaptation does work fine with it (all tests were conducted with it active, items that did take the custombulk value had proper scaling based on playerbulkadaptation values).

Snakeye · May 19, 2009

GalZohar said:
A short test concluded that custombulk works great for some items and doesn't work at all for others.

That's.. odd..

If you find out a trend [or even if not], just post a few that work and a few that don't - while I won't be around as regularly as usual from tomorrow to sunday I might still get some free time and try to investigate that, since technically custombulk should work for any equipment item.

GalZohar · May 19, 2009

For now it seems that anything that was modded by any way by anything does not work with custombulk.

Works:
5-7
claymore
sig
sig(scope)
m9, m9 mag
armor vests
rc50
AN-M8-white

Doesn't work:
AKMSU
M67 (modded by duke)
M93R
M16A2 (modded by new40mm)
MP5/40A3 (modded by inf weapon enchancement)
M16A2 - scope (I think the game automatically ignores attachments with no weapon)
SIG - scope (same as m16A1 scope)
Minimi (modded by inf weapon enhancement)
M4A1 mag
M1911
M93R
HK416
M16A4 - ref (again, I think attachments without weapons are removed automatically)

Anyway that's the only thing I found in common for all the items I checked. Maybe it's just the class names in the XLS that need to be fixed, I don't know...

On a side note, I just noticed that enabling microbulk (and disabling the other bulk mutators) also causes some wierd issues, with a heavier loadout having much less stamina loss than a lighter one. So custombulk isn't the only bulk mutator with a problem here, microbulk has issues too.

Snakeye · May 20, 2009

Just a quick question: where in the mutator list did you have custombulk/microbulk? If it's not on the top (i.e. first mutator called) put it there and try again - if you have a really long list and don't care to remove and add again all the mutators, you can also edit the ini-file (infiltration or infiltrationuser, not sure right now).

Which mutators are you using? Also for a first try it might make more sense to use only custombulk and then add mutators one by one - this also makes it easier to spot conflicting mutators.

As for your suspicion that the game ignores attachments without weapons, while I'm not 100% sure I too think that's the case - after all it doesn't make too much sense to pack an ACOG for a SIG if you don't have the SIG..

BTW [warning: useless information ahead] there is not really such a thing as a M4 mag - the STANAG mag in-game is the same class for every weapon using it, otherwise you couldn't interchange them.

GalZohar · May 20, 2009

Yeah that seems right, though in the loadout menu they show up as different items.

Putting it first on the mutator list seems to make things work more or less, but there are still issues. Even though when set to 9999 bulk every item in the loadout gets that bulk value, certain loadouts combined are simply too light.

I attached the INI files as well as the XLS file I used to generate those bulk values. An easy way to test whehter or not a loudout works is to make it have ~1170 bulk which should make you have 1/2 of base stamina and speed. Some loadouts simply refuse to do that even though when set to 9999 bulk each of their items put in its own loadout slows you down just fine.

Example loadouts that don't work:
M249 + 4 cans + M9 + 2 mags + 2 frags + helm + armor
M249 + 3~5 cans + M4A1 + reflex + 7 mags + 2 frags + helm + armor
M249 + 3 cans + M9 + 2 mags + helm + armor

As you can see all loadouts that I could make not work had M249 in it, even though M249 and its ammo's seems to work fine when it's on its own. All the above are around or over 1170 bulk however they slow you down by a lot less than 50%. Other loadouts with similar bulk do slow you down to 50% - even a loadout of 1170 bulk of M249 ammo cans (7-8 cans) slows you down to ~50%.

Crowze · May 20, 2009

Snakeye said:
In general all load order dependency problems can be solved with changing order - although I do think to remember using MultiMut does cause troubles on its own, since it doesn't seem to keep the order as in its ini, but I digress. From what I could find with my limited knowledge, there is no such thing as "happens in general" with UT/Inf - you'd have to look at every case for itself.

The trouble occurs with the way mutator function calls are passed between mutators i.e. whether the call to the parent muatate function, for example, comes before or after (or god forbid in the middle) the mutators own processing. If called at the end the function will be called in the order it is registered, but if it's called before then it forces itself to be processed last. The former is usually the best approach, unfortunately not all mutator authors (including myself) knew that at the time.

It would make your life easier [actually it won't ]. Remember I didn't write that mutator in the first place - although I would be willing to investigate alternate possibilities to solve the problem if Stinkmarder allows it*.

Just to actually try and be helpful, IIRC there is a way to check if the class name is the same as a given string, which might possibly work for your case.

Indeed those two forms are equivalent, but the former is preferred as the latter will give an 'accessed none' when applied to a non-object. The alternative is to use a cast, something like (Classes)A == None (although I've no idea whether that syntax will work in UScript).

*I know I'm a tad strange on this point [probably not only on this point ], but I don't like to mess around with other peoples work without their permission.

Click to expand...

There's no reason why you shouldn't mess with other people's code at your heart's content, but you ought to get permission before releasing a modified version. Might save you some time that way .

Search

Search

Inf-info.xls

Snakeye

Mk82HD

Attachments

GalZohar

New Member

Kueltag

New Member

Kueltag

New Member

GalZohar

New Member

Snakeye

Mk82HD

GalZohar

New Member

Kueltag

New Member

Attachments

Snakeye

Mk82HD

GalZohar

New Member

Snakeye

Mk82HD

GalZohar

New Member

Snakeye

Mk82HD

GalZohar

New Member

Attachments

Crowze

Bird Brain