Jump to content

NephilimNexus

Members
  • Posts

    113
  • Joined

  • Last visited

Nexus Mods Profile

About NephilimNexus

NephilimNexus's Achievements

Enthusiast

Enthusiast (6/14)

  • Conversation Starter
  • First Post
  • Collaborator Rare
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. Someone has already skillfully made a mod for fixing the absurd roulette wheel of the Proving Grounds, allowing you to mass produce any of it's results simply by expending supplies and e-cores. This makes sense, it's logical, and it's the way XCOM has always operated in the past. It is a good thing, and you can look at it over here: http://www.nexusmods.com/xcom2/mods/223/? My request is to take this idea and expand it to include weapon mods. It strikes me as absurd that we can build a combat exoskeleton with flamethrowers for hands but the technology of this mysterious thing called a "rifle scope" is somehow beyond us, forcing us to rely entirely on "loot drops" to get them. IMHO, this kind of cheap MMO bullcrap has no place in XCOM. It would make far more sense if all weapon mods were removed from the loot drops entirely (leaving nothing but elerium cores) and were instead logically added to the tech tree as something that you could unlock via research and then simply mass produce to your heart's content - or supply limit, which ever comes first. Example: Modular Weapons (3 days) -> Basic Weapon Modules (5 days) -> Specific items researched separately, 2 days each, or skip right to -> Improved Weapon Modules (7 days) -> Specific items again, and requires previous version so you can't just skip to the end, now take 3 days each -> Advanced Weapon Modules (14 days) -> Same drill again, now 5 days each -> Superior Weapon Modules (28 days - petty have some scientists by now) -> Top tier specifics, 7 days each. Then once you unlock any particular item you just go over to Engineering and buy the dang thing with Supplies (starts cheap, gets expensive as tech improves). There: A simple, logical way to handle weapon attachments that actually has some foundation in sanity.
  2. XComGameData_WeaponData.ini Go to line 65: FIREBOMB_ICLIPSIZE=1 FIREGRENADE_RANGE=10 FRAGGRENADE_ICLIPSIZE=1 FRAGGRENADE_RANGE=10 ALIENGRENADE_ICLIPSIZE=1 ALIENGRENADE_RANGE=10 GASGRENADE_ICLIPSIZE=1 GASGRENADE_RANGE=10 ACIDGRENADE_ICLIPSIZE=1 ACIDGRENADE_RANGE=10 GRENADELAUNCHER_RANGEBONUS=4 ADVGRENADELAUNCHER_RANGEBONUS=5 EMPGRENADE_RANGE=12 I think you can figure it out from there, yes? :)
  3. My only problem with the Workshop is that I can't figure out where the heck it is downloading/storing the mods, therefore I cannot access them with the SDK to find out what makes them tick.
  4. True, but that was easy enough to change. It was just a matter of changing the text the abilities to read PrimaryWeapon instead of SecondaryWeapon, just like the pistol itself. It's not that the abilities aren't working - as far as I can tell they are. The problem is that it still forces my soldier to carry an assault rifle, and uses it instead of their pistol. I did noticed in the Workshop something called the "Officer Mod" where someone has apparently found a way to make it work, but from what I could glean the way they did it was to add an entirely new weapon to the game that just happens to have the same stats as the pistol and then forced the new class to use it. Which frankly seems like a real hassle, especially since it would mean editing the research and engineering trees to insert all the upgrades into it as well.
  5. Are you using the ModBuddy or are you writing into the game's config files directly?
  6. So I finally managed to figure out how to add new character classes into the game without it crashing, which is a relief, and now I'm hoping to be able to do something a bit different: Making a class where the Pistol is their Primary weapon. Now I can change the data in the ModBuddy just fine and it doesn't show any errors on Build. The catch is that once in game it does nothing - the character is still stuck holding an assault rifle and none of their Pistol abilities actually result in a pistol animation being used for anything. It doesn't crash, it doesn't bug out, it just refuses to accept that they are carrying a pistol at all. Is this something so deeply hardcoded into the game that I may as well give up or do you think there is a workaround possible?
  7. I'm running into the exact same problem, and even after following the instructions posted here I could not resolve the issue. http://imgur.com/a/5NRRW
  8. So basically you want this XCOM1 mod converted to XCOM2: http://www.nexusmods.com/xcom/mods/631/? Wish I could help, but at least we know it can be done.
  9. Now I could be wrong but if all you're doing is tweaking the ini files for gameplay balance (harder/easier) then you shouldn't even need the Unreal Editor. Notepadd++ would suffice.
  10. Weapon Mod: Suppressor. If an enemy is killed in one shot and no other enemy is in visual range to spot it then Concealment is not broken.
  11. Once you actually take a NPC as a companion you can dismiss them later. However, when you do, your only options are to send them to one of your settlements. There is no option to return them to their point of origin. I'd like that to be a option. For example: "Go Home" - Nick returns to detective agency, Piper goes back to her house, Curie goes and hangs out at the doctor's office in Vault81, Dance could go back to either the blimp or the airport, etc. Because to be honest, companions make crappy settlers. They never shut up and half of them refuse to work. They just take up space and yammer the same two lines over & over forever.
  12. Thing is if you look at the BOS airship it only has attachments for 4 aircraft. Yet you can blow up 50+ of them and they just keep coming. I don't mind that they exist or that they even respawn, but egads they shouldn't be coming in by the squadron. I'd like to see a code insertion that reads "If a vertibird dies in this cell then no new vertibirds appear within twenty cells of this location for at least a week." I don't see losing a vertibird being the end of the BOS, but I don't see them as Space Invaders, either. They should need time to recover, send for replacements, etc. Because one thing that is really obvious in FO4 is that someone in the script writing department mixed up the the BOS and the Enclave.
  13. I think you're on to something there, and it could simplify some previously mentioned mechanics. Here is my take on this proposal: In an effort to make Guard Posts actually worth something without having to rebuild their models into something completely different, add a few new hidden variables into them. Namely, those Settlers assigned to Guard Posts would be classified as actual Minutemen. In addition to their small defense bonus (already in the game) each Minuteman employed at a settlement would reduce the probability of having external missions popping up - those annoying "we're scared of ghouls living a mile away even though we've got fifty rocket launcher turrets here" nonsense that seems to happen constantly. Just as settlement defense would reduce the chance of hostiles attacking the settlement, employing Minutemen via Guard Posts would reduce the chances of the settlement needing to sent you, personally, out to deal with all their trivial random missions. For example: You have four guard posts with four settlers assigned, so that gives you 4 Minuteman points. The game calls up the code for seeing if you get a random peon mission for that week; let's say it's 50%. The mod injects itself at the end of that formula and say "Hang on - says here they've got 4 minuteman points, so we're going to knock 10% per point from that (-40% total) which brings us down to only 10%. If a probability is reduced to zero or less then you never have to deal with those missions again... at least at that settlement. As you can see, this probably wouldn't be that hard to implement. It requires no new models, textures, or even orders. The only thing the modder would have to do is create a hidden variable that tracks assigned Guard Posts, adding a point for each one that is manned, then locate the game code for creating random missions and create a new function within that code that reduces the probability/frequency based on that new variable.
  14. Shouldn't be too hard, right? Simple texture recolor for all Gen3 synths to have the milky white android blood (as seen in the "Alien" franchise) instead of red, human-like blood. If you could add it to the Gen2s as well that would be interesting. I don't think Gen1s qualify - still too mechanical. Would certainly make the lore of post-mortem synth identification more believable. Too much self-contradicting lore in the game as is - this could be a simple, believable clarifier.
×
×
  • Create New...