Author Topic: Support_RaycastingWeapons Headaches  (Read 253 times)

Currently editing a weapon pack that uses this support script. I want to add a few minor bugfixes/changes to it, but I've discovered they would get overwritten by several different versions of it that have been edited in a similar fashion and are floating around in other add-ons. I could set the version number higher like they did, but that doesn't fix the underlying problem that it could be overwritten by the next guy. I'm half-tempted to rename everything in the script and make a version specific to the weapon pack, but that kind of defeats the purpose of using support scripts in the first place. Any thoughts on what I should do?

ideally all raycast hooks are overridable which allows you to add weapon specific functionality. you can also use this to add bugfixes. override the functions in an external script using packaging. if you know the specific bug, you can add a conditional that executes your own completely rewritten but fixed version of the source method, or parents the original. this way you can actually supply a fixed bug-free version that gets used when the bug is detected.

modularity hinges on parenting. the more you parent, the easier it is for other people to add more modular content over it. so you shouldn't be afraid of people overwriting things because ideally they would just parent it except when they need special custom edge cases

i guess the main problem you're having is with the version control. if you structure your changes as an external entity, you won't actually need to use any version number/support updater or anything. you can just slap support_raycasting into the pack and make a new file called raycastingfix.cs where you hook into the methods and supply your own fixes

if im not fully understanding the problem let me know
« Last Edit: July 26, 2019, 02:45:40 AM by PhantOS »

Unless your version is only useful to you specifically (like what i did in the MAS railgun, terrible practice i know), it should be fine to just make a new higher version of it.
Not many people will want to make more versions of it anyway.
I think the latest fixed version was mine, which was version 4 (attached).
I included comments near the fixes, which were mainly the disconnect function fix (where there were no parameters included, but should be) and a bugfix around a non-full 100 amount of range being set, which crashed the game.

The last version i used however was version 5 in Weapon_MAS_Rail_Rifle, which had a couple additions specifically for that weapon. I should just have made my own raycasting in the weapon, not use an edited version of the support script.
But alas, if you just use a version higher then 5, i think you should be fine.
Alternatively, set it to a much higher version.

ideally all raycast hooks are overridable
I'm mainly concerned with 2 issues. If someone's package is activated after mine and it doesn't call the parent, as often happens for custom onFire functions, then my code will never be executed, so it won't matter even if I run checks for my weapon pack. In many cases running parent is undesirable, since the whole point is to replace the default gun firing with raycasts and not supplement it. So packaging won't really fix the overwriting problem. Also, Support_RaycastingWeapons is coded to not activate the package if a higher version is detected, so I can't ignore version numbers.
But alas, if you just use a version higher then 5, i think you should be fine.
Alternatively, set it to a much higher version.
As for setting version numbers higher, I've seen multiple add-ons that have done this (v5 for Weapon_MAS_Rail_Rifle, v6 for Weapon_WH40k_Imperium, also Visolator's v5 for all those add-ons that got patched by Support_Updater). I would like to avoid breaking the ones that add custom functionality, in spite of their bad coding practices.

The Rail Rifle V5 being reverted won't completely crash the game, functionality will just be limited.
I did not know about the WH40K Imperium versions, not sure what they do/did.

You're right that it won't crash, though I want to avoid intentionally limiting functionality of other add-ons. For example, the WH40K weapons added the option to draw lines to display the raycasts. At the moment, I see two fixes:
  • Rename a bunch of stuff and make the script specific to my pack
  • Create a v7 that merges changes from the railgun and WH40K as well as my pack, assuming that they don't conflict

The second option sounds like the best thing.

I'm mainly concerned with 2 issues. If someone's package is activated after mine and it doesn't call the parent, as often happens for custom onFire functions, then my code will never be executed, so it won't matter even if I run checks for my weapon pack. In many cases running parent is undesirable, since the whole point is to replace the default gun firing with raycasts and not supplement it. So packaging won't really fix the overwriting problem.
you're either trying two things:

1) you're trying to create a better version of support_raycasting to use with your weapon pack. For this you don't even need to touch support_raycasting. you can just create a branch of the original and change the conditionals that check for image members. for example, raycasting checks if the image's member 'raycastRange' is greater than zero before processing any raycast logic. you can also create your own version independent of support_raycast and check for something like image.raycastfix_enabled = true. and any images with that member set to true will then process your custom raycast logic. this way any guns like tier tactical that rely on raycast can do their own thing and you don't even have to interfere with them. this is ideally the best solution. if you look at mods like gravity cat's default guns, he provides a bunch of custom image members like gc_maxammo that work with his ammo code. any gun with gc_maxammo as a value will be affected by the code, and any gun without it will be completely ignored, thus avoiding any unintended changes to outside packs.

2) you're trying to overwrite raycasting for all weapon packs installed. this creates a dependency to your code and anyone who wants to successfully hook into your new fixes HAS to know about your custom raycast mod. if some other person who doesn't know anything about you wants to make their own raycasting solution, it'll conflict with yours. this is the nature of overhauls

in the end you need to pick one. you can't assume that any other additive hooks will parent or not, that's outside your scope. your scope is to take the original raycast input, tweak it, and pass that information along to the next package that hooks it. if the next package breaks out, that's tough. you can't stop that from happening, and you shouldn't try to either, that's the next mod maker's job. if you really want your own custom raycast solution, you just need to create a new one from scratch. if you do, no mod will ever conflict with your custom raycast unless they are actually trying to
« Last Edit: July 27, 2019, 05:06:21 PM by PhantOS »