![]() ![]() Simply - to state it as a public function in this case - without some dire need (wide codespread need) for it - will only upset the performance more (as in every such case) but - will do the same. So you can declare and test it that more private way only - in the case if RemoteTrigger () scr was only meant to call the WeaponBehavior scr functions and for nothing else. So: anything from that above - as not public void, (in order to upset the system less as possible, and that way (performance-wise) will be much better, since Fire () function in RFPS is very rich, code wise and couples with a lot of other such code rich functions as well. (whatever makes it more a / or a / private class) Also: why public void for the RemoteTrigger () ? is that script too accessed by some other script or acting only on his own ? If RemoteTrigger () scr is acting only on his own - and has no any of it's functions called from other scripts it may be better to declare it as either: Further: as the idea 2 - your chosen weapon for this task may be also -in the Inspector (in it's weaponBehaviour script) ticked to single mode in this situation, and that - as-all-natural - makes it - to shoot in the single mode. so it's not at least a your-new-script script issue but just that firing mode information as it seems (and is it active) might be still missing in your new script, when you are accessing the WeaponBehavior script with it. This is important because the WeaponBehavior script auto firing function is switchable on and off, as the condition, and it has 3 switchable modes: single, burst, auto, so it may need additional information from you: in which firing mode is it, to activate / deactivate auto firing mode that we suppose you want to use in this case, rather than the mode that causes the single shot (and that correctly, thus far, as well as we can see) - since you are getting single shot properly. Also: is there a bool in the WeaponBehavior that should choose / and / confirm active firing state, at any moment, such as "firing = true" that you may have forgot to add to new auto-fire script as well ? We are of the feeling that playerInputControl.firePress = true just as that alone - is not enough to keep the auto firing active. NOW: Has your WeaponBehavior script still has that 'extra' function' for firing left inside, that you added earlier, that now perhaps is interfering with this your new AutoShoot script ? That would be a good idea to check first. Ĭlick to expand.This asset can not be deprecated, since it's community here is active and that can not be deprecated and - as the new RFPS members come in - we have no intention to deprecate it, in the next 100 years. Don't know at any given moment what's exactly in your scene ? You have just subscribed your self for a 101+ extra red exceptions and game object "anomalies" that 'don't make any sense'. Missing that orientation out of your focus, for anything else happening is always the main fatal mistake. The scenes, therefore - remain the final and most important: product. is simply - only the way to get there - to tell the story (per each scene): properly. Think per-scene, most importantly and what's in the scene at any given moment - the scenes that we all, the Unity dev's make: are what players are going to get to play - at the end. Unity games and simulations are produced per-scene. Also, there is some recent "fashion" of thinking "per script" and "per asset" quality of development. good idea, and using Don'tDestroyOnLoad depends of what's already in the scene, are there more than 1 script in the scene that is calling Don'tDestroyOnLoad () ? Always check that first, and what their exact mutual interactions might be. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |