Is it. So how does the game reset the chance to explode ? It doesn’t. The chance to explode is a 2 step thing, first the weapon needs to fail to fire, aka malfunction, then at the second malfunction, it just explodes instead.
K, here a thing. You either need to show up your skill or stuff it. So if you have the solution, show it. After all it was so easy…
Maybe I don’t support @Nattfarinn style of arguing… But what do you @TheImp suggest?
That in Unity it is impossible to do? You want to say that an array and new function and accompanying animation can’t be created in the engine?
I don’t know, but maybe you talk about modding such stuff? Because I suppose you don’t suggest that developers can’t insert above things in the game?
Nevertheless… even if you talk about modding it, then some things are still possible when using javascript. You can create variables, you can create new skills and you can probably adapt existing animations to launch when skills are triggered.
Of course it would require dedicated man to try to implement such change, which in my opinion is not worth the time to have such adjustment in the game. But don’t say it is impossible.
I am talking indeed about modding such a thing in. And I don’t see a way to do such. I of course can be mistaken, and I am willing to admit it if there’s a mod to do such a thing… but as far as I can do things, with .dll’s, there’s no such a way.
You can limit the individual items to different malfunction maxes, and have different malfunction increments… but you cannot reverse it with ease. Unless you make such a function into the engine, which technically can be done, but I don’t have such a knowledge…
So the suggestion is to either live with the as is, or use the Kaos Weapons mod from here:
So that has absolutelly nothing to with the game being CryEngine, Unity or Unreal Engine based. It is all about not having mod support (which is hopefully going to change, yay!).
“Let me fix that for you”
Thing is, this is theoretical… and has no consideration of the game modding capabilities.
Which by the way are non-existent.Which makes it impossible .
Now it makes sense.
Still in matter of strict possibility, even thou there’s no mod support everything is actually possible with DLL injection, bytecode monkey patching and pipeline interception. Inconvenient as hell, unstable due to updates, but doable. Been there, done that, wouldn’t recommend it to anyone. 
Yep. First and last things are probably how Modnix and other mods work for Phoenix Point. You write code in other language which translate into code used in the game. And you overwrite and add things above existing things. I don’t have knowledge how exactly do it, but it is how people write Phoenix Rising mod. 
Thing is, even the game makers themselves made a mistake in their code, that can be found out in the games own items, they believed that you could just lump the malfunction chance to be a negative value(-10) and it would stay negative up to the intended point, which would be the 6th shot/burst that would make the malfunction chance to increase above the non zero mark… but you know what, it doesn’t work and it starts from zero and goes up from the first shot/burst.
So this is an engine level thing… specifically a Unity Engine thing.
No. Again you are wrong, it’s stable as rock. You just need to reinstall the mod insertion tool(modnix or before that the Phoenix Point Mod Loader, which originally was a Battletech mod loader*) after each update as the update will remove the modified content (.dll etc loading insertion commands).
*If you don’t believe me, read this and weep: GitHub - RealityMachina/PhoenixPointModInjector: Experimental tool
You don’t have much experience and knowledge about bytecode monkey patching yourself, do you?
I haven’t been wrong once here. It is you who continue to make assumptions knowing shit.
You continue to say things without actually knowing what it means. The bytecode monkey patching hooks wouldn’t be stable at all (and are not) as the bytecode address in 99.99% cases will differ between the updates. Currently the patching relies on non-obfuscated (which isn’t always the case by the way) game symbols and doesn’t have to rely on static physical addresses. If you disagree so far, could you elaborate?
Alright, so tell me, what do you want me to show you ? Something simple … so I don’t need to make an instrictions for it.
Or how about this…
.json commands, using the Phoenix Point Mod Loader, and PPDefModifier 1.7 , we want to set wardog helmet’s armor stat to 35 for an example.
We write the following code in a new .t(e)xt file, and put it into the correct folder(named in the instructions):
[
{
“guid”: “27529afe-893d-f024-180d-f69593df788c”,
“field”: “Armor”,
“value”: 35,
“comment”: “Blarg”
}
]
… it will work in the very first version of the game as well as in the very last. Now, the same thing can be done in other ways as well, but I will need more instructions of telling what’s you need, and this is already too long.
Do they ? So why would you be using those then ?
Again, the usability comes from either of those facts, and they can be used in their own ways. But you have to commit to one and use it as you intend … actually consider what you want to do and pick the one you need to get things done correctly or you’ll be cheesing multitude of facts … like patching a Mutog, and you get Arthtons with multiple times their intended hit points. … just because you patched the Mutog’s legs by looking at it’s string and the Arthron’s legs have the same exact phrase in it as the mutogs has.
Show me the proof of:
Why do you assume that the reason is the game engine choice?
Sometimes it is the last resort. But makes things absolutelly possible (we did that in Kenshi: Genesis project).
You keep assuming that the reason for things not being possible to do is the Unity Engine itself, but keep ignoring that the game does not provide mod support (yet) and current mod loader and DLL injection only makes easiest scenarios possible. It has nothing to do with the game being Unity, Unreal, OGRE or CryEngine based. You would have the very same issues with DLL injection in any of those engines, and Unity is even easier to handle because it keeps most of symbols and signatures intact unless intentionally build obfuscated. The monkey paching though is still available and sometimes viable.
I just went to nexus mods, chek Jamo’s dlls. download the Kaos weapons. Set the Malfunction chance to 15% and set the malfunction increase to 0%. (they’re significantly stronger than average gear so i think 85% success rate is fair)
You still want to bring multiple guns for heros that weild your chaos weapons because you dont want the gun blowing up (2 malfunctions in 1 mission), and also, sometimes the kaos weapon is not necessary to finish off a mob because its wounded so its not worth taking the 15% malfunction chance.
Does the fact that the chance is/was set to negative 10 in the 1.14 version of the game and it still starts from zero for every one of the weapons, testify as a proof ? And as a matter of fact, when you place the weapons on top of each others in the players general inventory, they rezero to the same 0 chance to malfunction. And this was been reported by the beta testers of Kaos Engine … for how ever long it was tested by the community counsel. As you can read from etermes first post. I was not part of them… but I heard this from elsewhere too.
Not at all. It just means there is kind of max(0, value) somewhere in the game’s MonoBehaviour.
No idea how does it relate to Unity game engine. Do you call “Unity Engine” everything that can’t be modded via DLL? It would explain a lot.
Well, the normally set max is 40… but you can set that if you want, it’s just a different variable. And you failed to undestand that when the game has it set to negative ten, it doesn’t matter, in actual game terms, it is zero and progresses from there on to positive numbers. So there is a minimum that is outside the normally set value already.
Here’s a view of portion of how the item is set up:
All those Malfunction variables can be easily set with a .dll … thing is, the values under zero on the BaseMalfunctionPercent do not matter … the game - like we already know - sets it to ZERO, MINIMUM. And rezeroes it when it’s placed ontop of other similar items, as then, it’s one of many, so it looses all it’s internal figures it had.
I call this to be due to Unity Engine, as it’s what the code is off. Or the game engine is using Unity Engine and as such, the game engine can only use the feartures programmed into the engine, and not things that are not.
Just stop, OK? You keep ignoring the fact, that there is a whole game made by Snapshot Games developers in between the Unity Engine and what is available to flawed home-made modding tools. Nothing of what you’ve described is a feature of Unity Engine and if you had any experience with it, or any other game engine, you would know it.
You just described the bug in Phoenix Point inventory system, not the “feature” of the Unity Engine. Unless you’re of course able to tell me which Unity feature clamps the value.
So the answer to my previous question would be: yes, you keep calling stuff you can’t affect by modding tools “Unity Engine”.
Ask Snapshot Games developers why they did it like that. Like I’ve said, there is max(0, value) or other value clamp somewhere in inventory system written by SG.
A 40% failure rate? Wow! It can go that high? My Khaos weapons have never gotten to that point. They always blow up in my soldiers’ faces at the 12% failure rate.
That’s because you are using them a second time after it already didn’t succeed in an attack, in the same mission.
As in, you can use them as many times in a mission until it fails it’s first and then it can blow up. Before that point(per mission), it never can(blow up).
I’ve been playing around with this DLC and found that the difficulty level is a huge factor in how long Khaos guns last. On Legend difficulty, you get about two or three missions with one weapon and a maximum of two fumbles with it before it self-destructs. And you are then guaranteed to see it detonate in your soldiers face when it gets to the 8% to 12% Malfunction Rate on Legend. On lower difficulties, the guns are much more usable and don’t blow up as often. I was able to use one gun extensively for a couple missions when playing on Hero before I even saw its first malfunction.
Conclusion: you’re not supposed to enable the Khaos Engine DLC or use Khaos weapons in a Legend Campaign. It’s totally pointless.