Laydor

No, the 255 limit is a core design choice. There's absolutely no way something like SKSE could alter it. The game itself was converted to 64-bit code but the formID values are still 32-bit values and changing that would require altering absolutely everything. Even for the game developers changing it would be at least as hard as the switch from 32-bit to 64-bit code they've just done. So I don't expect that to change even for the next games in the series. Not that hard to include more bits, in fact they could have just used a 64-bit primitive/type instead of 32-bit even on a 32-bit system (bit slower tho). If they made it 33-bit values, they could double it or increase it by one hex value to be 9 hexadecimals long, making it 36 bits long or they could have done 48 bits, so the first 16 bits would be related to the mods, the last 32 bits for the form id. It really isn't that hard to change. All you really are doing is changing a value type. Yes it is annoying as hell to do, specially if you have ten of thousands of lines of lines of code. But not impossible or require altering absolutely everything. And they would only have to change these values in the game engine and the creation kit. Then recompile both and then recompile the game. Sure it might take a week at most with most of the time just being compile time. I totally disagree. You are right when you talk about a simple 1-file program. But the Skyrim engine is a huge conglomerate of probably more than 20 years of development, based on the old gamebryo engine. You cannot judge from outside what what kind of programming techniques, casting, mapping to data and file structures are used over the time. Techniques that make it impossible to simply change the type. The engine is not a properly designed piece of software. Why do you think there are all these CTD coming from. I bet by making the engine use a different type for IDs we would simply get more of them. And finally: they gave us the game as they have implemented it. They have never designed and tested with a huge modding system in mind. Why should they change that now? More than 255 mods is the desire of an extreme small portion of their customers. A fraction of 1% I would think. Why should they spend effort and risk "stability" for that small community. It actually isn't very hard to change primitive typing even with tens of thousands of lines of code. It is time consuming. There wouldn't have to be much of a redesign if any at all. Normally you tend to not do primitive type casting just because it can tend to waste memory or you lose data from that primitive. For instance if you go from an int64(long) to a int32(int) you tend to lose information from the leading 32 bits. Tho there are the odd times you do. And then when you are going to be dealing with Form Ids, you most likely will always be dealing with the full value and thus won't be casting to any different primitive. Techniques wouldn't change, because all you are doing is changing the type on all ends (so within the function and the calling function, etc). The only issue that going from 32 bit Forms to 64 bit Forms or higher bit sized Forms would be memory and time (since you would have to change each calling function, function and all the references to the 32 bit Form to 64 bit Form and their memory allocations, specially if you are using pointers). For all we know, much of the system could have been coded not into the game engine itself, but into a module for the game engine or a module of the game itself. But then again they might have a few other reasons other than memory bloat that they stuck with the 255 mod limit.

So are you trying to keep the cost of the spell constant? Or are you wanting to have the increase but at a smaller rate?

It would be possible. But you would have to get voice actors that sound very similar to those characters and probably would have to replace all of their dialog sound files with the new voice actors or else it would sound very weird.

You can only load Dawnguard, Dragonborn or Hearthstone at a single time. You can load Skyrim.esm and patch.esm with any of them. If you want to load the 3 dlc master files all together or two of them at the same time, you will have to follow the instructions in this modding resource. http://www.nexusmods.com/skyrimspecialedition/mods/3380/?

I suggested this on the first page, but because I have not worked in the kit for three months and was not at my "Modding" computer, I did not verify Laydor's claim that you can only put the Conditions on the Magic Effects. You click the effect in the spell template and put the condition on the Effect Item Template. I am going to get you Laydor! :laugh: Where did I say that? I don't recall saying you can only put the condition on the magic effect and not in the spell.

The source scripts should be in "Skyrim Special Edition\Data\Source" not "Skyrim Special Edition\Data\Scripts\Source". But just so you know, all your created scripts go into the \Scripts folder when you compile them.

From my understanding of scripting, it will only corrupt someone's save if you modify an exist Form or script to call a new script or a modified existing script or modified part of a script. But if you only add scripts to your Forms and only modify those scripts, it shouldn't corrupt the save.

This is a really good idea, but unfortunately it won't work due to the limitation I mentioned earlier. The "PerkToApply" field is only applicable to the player. There is no way to add a perk to a non-player actor at runtime. Period. And on that subject @Masterofnet: Aliases don't have a perk field. Darn. So close but so far

Where did you come from Man?? That is incredible! I am going to be keeping my eye on you. Very interesting. Lol, I'm just a simple programmer who just recently decided to try modding for Skyrim. Heck really first time creating mods for any game really.

Ok I think I figured it out. Not completely sure if it will work or not. First we have to start with a Spell. We'll give this the ID MonitorAbility and a descriptive Name. Change the Effect Archetype to Ability, set Casting Type to Constant Effect and Delivery to Self.Then we create an effect for each stage of the boss. Give each effect an ID relating to which stage it is and a descriptive Name. Change the Effect Archetype to Value Modifier, set Casting Type to Constant Effect and Delivery to Self. Under Flags, check No Death Dispel, No Hit Event, and Hide in UI.Add each Stage effect to the MonitorAbility, with no duration required. Add the condition you want for that stage to be active.Next create a Perk for each Stage. For each Stage add the spells you want the NPC to be able to use as an Ability.After that for each Stage Effect, set Perk to Apply to the perk that is for each stage.Lastly add the spell to the NPC's spell list. This in theory should work. It might not. What this is doing is adding a spell that is constantly working, and only the magical effects for a stage are active. Meaning that the perk for each stage should only be active for each stage. Now this will only work for Spells and not shouts as you have mentioned that you can't add shouts to the perk (Tho you can add the Spell for the Word of a Shout). But honestly it would probably be easier to do this as a script. As you would attach the script to the boss and just do register for update and do the condition checks and depending on what stage, you can add/equip a spell/shout to the NPC and remove/unequip a spell/shout when the condition is over.

Did you create this NPC? If you do not use script to remove, unequip and equip the spells and shouts the results are not going to be very good. There will be lags between the times the spell is no longer available and the NPC equips the new spell. It is a custom boss, yes. Scripting was never something I was good at. I was hoping there was an alternative via entry points and conditions. Setting events with GetHealthPercentage works flawlessly. It's a shame there's no entry point to remove or unequip a spell. As I mentioned above, there is. Tho it isn't a entry point, but as ability in the Perk Entries. Heck, even the Creation Kit website clearly states Source: https://www.creationkit.com/index.php?title=Perk Tho as some people above have mentioned, this will only allow the NPC to use the spell when the perk is added, it does not make the NPC equip it. I also assume that you have found a way to add and remove a perk to the NPC without scripting since you are using perks as a way to prevent the NPC from using said spell.

No, the 255 limit is a core design choice. There's absolutely no way something like SKSE could alter it. The game itself was converted to 64-bit code but the formID values are still 32-bit values and changing that would require altering absolutely everything. Even for the game developers changing it would be at least as hard as the switch from 32-bit to 64-bit code they've just done. So I don't expect that to change even for the next games in the series. Not that hard to include more bits, in fact they could have just used a 64-bit primitive/type instead of 32-bit even on a 32-bit system (bit slower tho). If they made it 33-bit values, they could double it or increase it by one hex value to be 9 hexadecimals long, making it 36 bits long or they could have done 48 bits, so the first 16 bits would be related to the mods, the last 32 bits for the form id. It really isn't that hard to change. All you really are doing is changing a value type. Yes it is annoying as hell to do, specially if you have ten of thousands of lines of lines of code. But not impossible or require altering absolutely everything. And they would only have to change these values in the game engine and the creation kit. Then recompile both and then recompile the game. Sure it might take a week at most with most of the time just being compile time.

That only works on the magic effect, which still allows the NPC to cast the spell, but has no effect.

What you could do is grant the ability to the NPC when they have that perk. And the NPC only has that perk at a certain remaining heath.

255 mod limit. And theoretically it can access 16 Exabytes of RAM if using 64 bit SSE and have a 64 bit CPU with a 64 bit OS. But honestly you are probably limited on the amount of RAM in your system.