Jump to content

Weapons to all classes


zeye

Recommended Posts

First of all, I Am Not A Lawyer (IANAL), nor am I affiliated with Nexus. But I am an IT Professional (retired), have been on Forums here and elsewhere for decades, and have read A LOT of license agreements. (And yes, someone has to do it in the business world.) Each and every one I can recall has prohibitions against redistributing their product "in whole or in part", modified or not. (It's just part of the standard boilerplate.) Look at your Steam license, or for your OS, or for XCOM. Replacing an executable, modified or not, by giving it to anyone else is redistributing. That is what I initially took from Yzaxtol's statement (which he clarified is not what he meant), and what I cautioned against. If an installer is wholesale replacing a game EXE file with a "copy", it's illegal as to the intent of the license. Modifying for your own use could be argued is also prohibited by the license (a point of dispute; 'license' terms are not the same as 'copyright' terms), but that's for lawyers to argue over and in practice not worth the license owner's time to pursue. They just say you broke their 'warranty' or 'terms of service' or 'license' and leave you without any support. If you can't fix it on your own then you have to buy a new copy. (Win-win for them.)

 

A patch is simply code; not the program. ('Mods' are technically just 'patches'.) It's incapable of doing any 'work' without the program it modifies. If it doesn't come from the vendor, then it's "unauthorized". Which means they can say any mod breaks their license and lets them off the legal hook for any consequences IF THEY CHOSE. That most game companies don't waste time and money pursuing 'modders' is a business decision, not a legal one. When they decide you are threatening their bottom line, then the lawyers get to play.

 

The point here is that Nexus HAS to take a very conservative view of statements that can be interpreted as advocating illegal activity. You might want to take a look here, and read some of the 'banned' causes. Legally, what is the difference between advocating distributing a 'cracked' copy and a 'modified' copy? None. It's still an unauthorized 'copy'. Merely announcing you are using a 'cracked' copy can get you banned. The site has to do that because it would be opening itself up to a lawsuit it couldn't afford. Under DMRA they could get completely shut down while the lawyers argue and the cash flows OUT.

 

As for how any particular mod installer works: first of all I would suggest being very certain it is actually distributing a copy of the game EXE. Unless it says that is what it is doing, then you need to get into the internals of how it works. Then I would raise the question with the Nexus Admins. And then I would be willing to lay down money that it gets banned. The fact that one or more installers are doing something illegal but not obvious doesn't reduce the sites legal liability and risk. (Not to mention the authors.) Regardless of what the terms of service do or don't say.

 

Please: don't take my word for it. Ask the Admins as a 'hypothetical'. I only raised the point to try keep careless talk from getting anyone banned.

 

-Dubious-

Edited by dubiousintent
Link to comment
Share on other sites

Sooo....

 

Just checking that a program that will look at a file called XComGame.exe and make 1 HEX change is alright?

That is the essence of 'patching'. Because the owner of the game is willfully executing the program that applies the mod, makes it that they are patching their own game with an "unauthorized" patch. That is not 'redistributing' the game. Even with the program that applies the patch, without the game EXE, the patch/mod does nothing by itself. Perfectly legal. Does (like any mod) violate the 'warranty/terms of service', but game companies tacitly accept that.

 

Makes no difference how many bytes are changed. See my reply to Bertilsson.

 

Oh, and again: IANAL.

 

-Dubious-

Link to comment
Share on other sites

Instead of telling me where I can read more, you made a long declaration about copyright in general mixed with your personal views of what is what.

The point here is that Nexus HAS to take a very conservative view of statements that can be interpreted as advocating illegal activity. You might want to take a look here, and read some of the 'banned' causes. Legally, what is the difference between advocating distributing a 'cracked' copy and a 'modified' copy? None. It's still an unauthorized 'copy'. Merely announcing you are using a 'cracked' copy can get you banned.

Then you state a rethorical question inferring that I am advocating piracy, which you, both before and after, highlight that people are being or could be banned for.

 

That is not very constructive and I do not want a debate so I will not continue this discussion.

If you have any comments on this or if someone have a more relevant answer, please send me a private message.

Link to comment
Share on other sites

Getting back to the original issue that spawned the copyright discussion, the issue at hand is how to modify the executable for a mod installer so that the executable reads from the DGC.ini file instead of the internal Resource Cache.

 

Ultimately it is not absolutely necessary in order to mod the game to allow weapons to be assigned to any class (or to be assigned more generally to additional classes beyond those possible in the vanilla game).

 

However, the major "quasi-released-and-working" mod package that includes this is the new item modlet, which can run into problems with the DGC.ini getting too big. The current solution is to patch the exe to read from the file, but that requires the user to use a hex editor to edit their own exe.

 

Not exactly an ideal solution.

 

---------------------------------------

 

Back on the 'weapons to all classes' them, I did find that weapons can have more than one class weapon property assigned to them. However, side-effect behavior is unknown.

 

What happens if a weapon is given both eWP_Sniper and eWP_Assault. Does it get a close range-aim penalty or a big close-range aim bonus? Does it get a long range aim penalty from the Assault class?

 

I think in the long run it would be better to make up "new" weapon properties outside of the range of the current enum, and use these new weapon properties as the indicators for which class(es) the weapon can be assigned to. The existing eWP_Heavy, eWP_Assault, etc would be reserved for the in-game effects (close-range, etc).

 

One issue that arises is that only six Weapon Properties can be defined in the DGC.ini, which could quickly get filled up if a weapon were to be assigned to exactly three of the four classes.

Link to comment
Share on other sites

I'm still running with both "AnyClass" and "Heavy" properties without issue and everything is working as intended (Assault Rifles are now less spammable with suppression having taken on the ammo capacity characteristics of Vanilla heavy weapons and they are equippable by the every class including the Heavy). Simply using AnyClass on Assault Rifles (and Laser/Plasma equivs), for a reason I don't understand, made them available to all classes except the Heavy, but by adding the 'Heavy' property to the weapon I managed to hit-two-birds-with-one-stone by toning down my buffed Assault Rifles and making them forever optional for any class. Which is fantastic when kicked in the teeth by Vanilla's irritating random Class Assignment mechanic. So I no longer rage when due to that mechanic (and lots of guys in the infirmary) my active squad members consist of Sniper, Sniper, Sniper, Sniper, Heavy, Heavy, Noob. =)

 

The coolest part is that a lot of Vanilla perks are in fact weapon locked so that my Assault Rifle wielding Snipers can't use Headshot or Disabling Shot which is exactly what I was concerned about (I didn't want them to outperform say, Supports, when using Assault Rifles). So, now although everyone can use Assaults, each class has a good reason to stick to their intended weapon specialty when the circumstances (or diversity of specialists) are favorable. I'd kinda like "Flush" and "Bullet Swarm" to be locked to specific weapons (Heavy Weapons only . . though now my Assault Rifles are technically "Heavy Weapons" too so that would defeat the intention. . . gah) but that's really just picking a scab that doesn't need to be picked.

 

Another thing that's really very sweet is that the mesh overlay for the XCOM soldiers is dependant on the weapon equipped. This is a really cool cosmetic touch that if wasn't a side effect of this change would be desirable. I'm sure you all know this, I'm just a little chuffed. :D

 

 

 

I think in the long run it would be better to make up "new" weapon properties outside of the range of the current enum, and use these new weapon properties as the indicators for which class(es) the weapon can be assigned to. The existing eWP_Heavy, eWP_Assault, etc would be reserved for the in-game effects (close-range, etc).

 

That would be great and could have some interesting applications.

Link to comment
Share on other sites

In vanilla the Bullet Swarm perk is indeed locked to require both a Heavy class and a eWP_Heavy weapon.

 

I had to make a mod to specifically unlock Bullet Swarm for other classes, so it is definitely possible to lock it back to only being usable by eWP_Heavy weapons again.

 

Similarly for Double Tap (although it was only checking for the sniper class, not the weapon).

 

Flush isn't locked, although that's probably a good thing since it wasn't a very good fit for the Assault class.

 

--------------------------------

 

Yes, the armor overlay is based on the main-hand weapon. A soldier with an Assault Rifle and a Rocket Launcher gets the standard Assault Rifle overlay.

 

The in-game code refers to this as the "Armor Kit"

 

It is determined in the function XGBattleDesc.DetermineSoldierKit

 

When the tactical game starts up, one of the first functions called is XComTacticalGRI.InitBattle (GRI stands for Game Replication Info I think).

 

InitBattle calls XGBattleDesc.InitHumanLoadoutInfosFromDropshipCargoInfo (I love descriptive names).

 

This in turns calls BuildSoldierContent, which does just what it says... this is what loads the art assets.

 

It does the following, in order:

  1. The first conditional is adding the grapple item to the Skeleton / Ghost armors if the unit doesn't already have the grapple.
  2. The second conditional is adding the PsiAmp item if the character is psionic and doesn't already have the item.
  3. Then the base pawn is set based on armor / sex.
  4. Then the kit is determined based on pawn type (e.g. armor) and weapon
  5. Then the head is set based on appearance.
  6. Then the entire soldier inventory is copied over
Unfortunately the ultimate function MapArmorAndWeaponToArmorKit which returns the kit based on weapon and armor is a native function. Somewhere in there I'm guess there must be a bypass of some sort to allow the user-customized armor kits to override the default ones.
Graphically the head is just another item that is attached to the body, just like any other. I think this is why some of the dev console commands that spawn new soldiers create soldiers without heads.
Link to comment
Share on other sites

With the above hex change if you change the LMG-class weapons to have eWP_Support then they will only be equippable by the Support class. Unfortunately the level-up process will still equip the Heavy soldier with an LMG, although it won't be equippable generally.

 

*Shakes Fist*

 

Is this at all moddable? Heavies levelling up with LMG's when LMG's have been reclassified as "eWP=Support" is irritating. Is it a native code thing that's not upk accessible that's responsible for this?

Link to comment
Share on other sites

 

 

*Shakes Fist*

 

Is this at all moddable? Heavies levelling up with LMG's when LMG's have been reclassified as "eWP=Support" is irritating. Is it a native code thing that's not upk accessible that's responsible for this?

 

 

Actually you are in luck here.

 

The code to designate which classes get which weapons is completely written in Unreal Engine code and is in the XComStrategyGame.upk

 

The function that does the job is XGStrategySoldier.SetClass.

This function basically sets the class, the name, and changes the soldier's loadout when it is called. It's called from XGStrategySoldier.LevelUp when the soldier is promoted from Rookie to Squaddie.

 

-------

 

For the new subclass system I altered this so that SetClass is no longer called from LevelUp, but instead called from OnAcceptPromotion.

 

When the soldier reaches rank 1 and becomes a squaddie the soldier is still assigned a base class, (i.e. Heavy, Sniper, Support or Assault), and is given stats based on the base class, but is not given a name string or assigned new equipment.

 

Instead, in the perk tree, just after the first squaddie perk choice is selected, then SetClass is called but with the perk enum instead of the class enum. The class string and initial and possible weapon loadout options are set using the just-selected perk instead of the base class.

 

This is how the Sniper branch of Sniper gets the Sniper Rifle but the Scout branch of the Sniper keeps the Assault Rifle. Similarly the base Heavy class gets either the LMG or the Rocket Launcher.

 

So, it's definitely possible to mod the initial weapon loadouts in whatever way desired. If I'd wanted to, I could have kept every class just equipped with an Assault Rifle (since in Long War 1.9 every class can use the basic rifles), but that would have necessitated the player to go in and manually re-equip most promoted soldiers, which is just busy-work and no fun at all!

Link to comment
Share on other sites

  • 4 months later...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...