Reneer

Are those script functions or something to do with the quest? Those are script functions.

ESP mods work just fine.

You could use the quest to do it. You would want to use the StartTimer and OnTimer functions to create a looping system, then check in the OnTimer function to see if the player has too much ammo.

Yes and no. Yes in that the code looks good, no in that it would only run once and the player could simply pick up the ammo again from the ground.

Sure thing. This is a quick and dirty script that should do what you want (haven't tested if it compiles): Scriptname GrimReaperSprintQuestScript extends Quest Event OnInit() Self.RegisterForRemoteEvent(Game.GetPlayer() As ScriptObject, "OnKill") ; Self is an "automatic" variable that tells Papyrus that you are ; directly referring to the Quest / Quest script itself. ; Basically what this does is it tells the quest to watch for ; events coming from the player specifically the OnKill event ; and the event gets sent to the ::remote function below ; The "As ScriptObject" is a "Cast" that basically ; tells Papyrus that it should treat the player ; reference as a ScriptObject ; Mostly this is done so that native functions ; which are compiled directly into Fallout4.exe ; will actually work properly. EndEvent Function ::remote_Actor_OnKill(Actor akSender, Actor akVictim) ; note the akSender variable. This is added by the remote ; function call above, so any function you set up with ; a RegisterForRemoteEvent will have the ; type (in this case Actor) sent as the ; first variable if (akSender == Game.GetPlayer() && akVictim != Game.GetPlayer()) ; stuff goes here endif EndFunction Now, as for why you are getting slow function calls in your above script, my guess would be that A) Papyrus is slower than previous Bethedsa scripting systems because it is threaded / asynchronous (kinda-sorta), and B) Lots of stuff going on related to the player reference.

A few ways of speeding it up might be to try running the script in a Quest and using: Self.RegisterForRemoteEvent(Game.GetPlayer() As ScriptObject, "OnKill")And in another function: Function ::remote_Actor_OnKill(Actor akSender, Actor akVictim) ; do stuff here EndFunctionThat -might- be faster. On another note, I'd ask, personally, that you use "code=auto:0" when writing out code, otherwise it makes it really hard to read every other line of text.

So what is your proof that this is "already done"? And mods are not a huge reason people buy Bethesda games. You need only look at Skyrim sales on the PS3 and Xbox 360 versus PC sales to see that fact. Bethesda is trying to integrate mods on to consoles, but that was a major selling point of Fallout 4, not any previous Bethesda games.

No, they won't. As I've said, it would take a complete overhaul of the existing game engine, something they will not do for an already-released title. In order to make such a drastic change to the game engine, they would need months of QA testing. Not to mention the fact that increasing the mod limit wouldn't generate any new game sales.

Did you multiply 256*256 to get a 65,535 mod "limit"? The "arbitrary limit" is 254 because the engine uses two hexadecimal numbers to represent load order. Those values can be 0-9, and A-F, for a total of 16 per unit, so 16 * 16 = 256 different combinations. 00 is reserved for Fallout4.esm and FF is reserved for dynamically added items, so there are only 254 "free" slots for mods to use. It is not "just a few lines of code" that would need to be changed. Simply trying to tell the game engine to use 4 hexadecimal units to address load order would give us that magical 65,535 mod number, but it would require searching through the entire codebase to find each point where the game used to expect only 2 hexadecimal numbers and change the code so that it now expects 4 hexadecimal numbers. And you would then still need to change Fallout4.esm to have it be addressed in 4 hexadecimal number load order. Finally you would need lots of testing to make sure that you didn't break anything in that process. You'd also need to rewrite the GECK / CK to support those 4 hexadecimal addresses too. And all the DLC, to boot. Even if you "cheated" and told the engine "OK, if the FormID is only 8 units long, the first two units are load order, and if the FormID is 10 units long, the first four units are load order", you would still need to search through the code to make those changes, and it would have the result of making each of those code areas twice as complicated as before, because you've introduced a conditional that wasn't there before. The mod limit of 254 will not be changed by the release of the GECK / CK. It is not "arbitrarily limited" because Bethesda is worried about people crashing their games, it is the consequence of a design decision that was made back in the Morrowind days.

I am 100% aware we are talking about Fallout 4 and not Skyrim. It would still be a massive undertaking to overhaul the underlying code to support an increase in load order addressing beyond the current constraints. They would basically need to rewrite the entire game engine, then rewrite all of Fallout 4 to support that new engine.

Because it would be a huge problem. It wouldn't just be a simple "increase the number of mods allowed'. You would need to go through the entire codebase and change each area from 32bit memory addressing to 64bit memory addressing.

the limit was 255 because of 32bit address not allowing more than 4gb.64bit allows for thousands of gb so there isnt any limit on the amount of mods you can install but the more you have probably the slower your game will run. only because you only have so much video Ram. well Bethesda can easily change this after an update [PEOPLE NEED TO VOICE THEIR OPINION]. fallout 4 is 64 bit and 64bit can address over 18 quintillion values. Its likely only 254 because of consoles. This would not be a simple fix. They would have to recode a large part of the game engine to make it work, introducing all sorts of new bugs in the process.

Yup, each line in your plugins.txt counts. DLCList is Bethesda specific, and loadorder is just NMM sorting.

the limit was 255 because of 32bit address not allowing more than 4gb.64bit allows for thousands of gb so there isnt any limit on the amount of mods you can install but the more you have probably the slower your game will run. only because you only have so much video Ram. This is incorrect. The mod limit on Fallout 4 is 254 mods. This is because the FormID length has not changed - the first 2 hex digits are the load order and the remaining six digits are the reference within that mod. Since the load order is still 2 hex digits, the most any mod can use is up to FE, or 254, because FF is reserved for dynamically added items, and 00 is for Fallout4.esm. And yes, DLC do count towards this limit.

That is exactly like saying that a person who works a 2 hour day deserves the same pay as a person who works the same job for a 10 hour day. They do. You get the same pay for your time investment as you would get for your time investment over a shorter or longer period of time. The law requires it.I think he means that the person working the 2 hours makes the same amount of money, doing the exact same job, as the person working 10 hours a day, while both working at the same company. Both make $100 each day, but one guy only works 2 hours while the other guy has to work 10.

Not to my knowledge, no.

Just so you all know, I ran into a major bug / glitch that I can't seem to figure out and it doesn't look like there is an easy solution. As you may have noticed in my script, OnItemEquipped / OnItemUnequipped both provide Base Object Forms and Objectreferences. The Objectreferences, however, are pretty much always null / empty. The mod successfully detects forms, but in the case of weapons, two very different guns can have the same base FormID. And since there is no way to get the actual Objectreference of the gun, but only the base form, I can't determine which gun to give the companion back. So it might be that the best method for this is still modifying the interface files. :/

Of course. But a texture is a texture. A new mesh is a new mesh. Everything on the Second Life Marketplace was created by users, just as everything on the Nexus was created by users.

Welcome to modding Bethesda games, where something that should be trivially easy is in fact neither easy nor trivial.

Short answer: No. Longer answer: The Nexus hosts 137,023 files. Around 118,143 of those are Bethesda game mods, leaving 18,880 for other games. However, that 118,143 Bethesda game mods is utterly dwarfed by the number of mods / UGC on the Second Life Marketplace, which has 3,889,838 user-created items. Even if we say that the number of Bethesda game mods is off by a factor of 10, the SL Marketplace still has it beat. And that's not even counting other games like IMVU.

I'm not sure. This is just a question because I don't know the answer myself, but does that actually mean there's no way of accessing the information in the variables? Or does it just mean that we can't use the correct object oriented design principles in how we access them? Can they be directly referenced from within another function? I've been trying to figure this out myself but haven't gotten anywhere so far. (Edit: I mean without using F4SE) As far as I know, there is no current way to get the INI values without using console commands. There supposedly is a GetINISetting console command, but no way to really use it to store values in Papyrus.

No. Again, nothing like that is exposed to vanilla Papyrus. I dont see why you need papyrus for this. dont we have Nifskope. Well, adding, say, six meshes together in Blender, cleaning up vertices / faces, stretching the texture, etc, can all be done, of course. But then what would you do if the player only put 4 objects together instead of six? You could create one, two, three, etc, item blocks and replace what the player puts down dynamically, that would work. It would be a major pain, but theoretically possible.

An appeal to tradition, a no true Scotsman, and hints of an argument from authority. Almost a trifecta. And a good dose of NIMBY to boot. It's nice when people tell me all my hard work and effort is worth nothing. /s Because you don't get to decide if something "should" be free or not. The person making that thing gets to decide whether it is free or not. And you get to decide if you want to spend your money on it.

No. Again, nothing like that is exposed to vanilla Papyrus.

Short answer: Yes. Longer answer: There are several functions in Utility.pex that would be useful: Function SetINIBool(string ini, bool value) global native Function SetINIString(string ini, string value) global native Function SetINIFloat(string ini, float value) global native Function SetINIInt(string ini, int value) global native However, you will note that there are no functions available to GET INI variables. Which makes absolutely no sense, but that's Bethesda for you.