From the github page, reading "endless raycasting which is cpu heavy". So you mean that raycasting with your plugin is more efficient? You don't have to raycast every frame, you can raycast on demand, also, im almost 100% certain, that current player has raycasting implemented by itself, so you could grab raycast result value. Also, by raycasting, you are NOT restricted to make ray infinite. You can simply set the max lenght inside the Ray function body (or however that was, i dont remember). I absolutely do not understand, how raycasting is related to mods that are loaded in runtime. The raycast handles these objects as gameobject instances, so if they have proper collision and tags, they work just as any other object in the game. TL:DR i cannot see a single reason, why even a modder use this mod. But prove me wrong, i'm interested...
no, I made it clear in the "raycastcore explained" tab that it's not any better, except for that it's a wish to unify raycasts into just one core mod, so each mod doesn't have it's own raycasting.
although that hardly will make a difference since there's like a 1000 raycasts running all the time in game already.
see here, not everything is a beer bottle, not everything is gonna just need a text at the bottom saying "beer bottle", raycasts are also used for player functions, like the gas nozzle picking up function for example... go figure. oh and also is it better to get an FsmGameObject and nothing else, and checking if the game object isnt null, then if it has the right name, then the right tag, layer, etc. and then having to add messy bools for converting that from a thing that gets called on each frame then, to a method that gets called only when it becomes the right object, or is no longer the right object... you know... OnRaycastEnter(), and OnRaycastExit()...
and about the raycast lenght, idk why but I thought a longer raycast would be more cpu intensive, my bad for implementing code that increased it only if needed, but that's hardly anything bad. I can remove those 2 lines of code if you hate them so much and move on.
all these items have general layer like pickable item, bodypart etc, if you think that every gameobject has its own separate layer then you are sadly mistaken. PhysX limits count of collision types. Only was for you to differentiate is to use some kind of tag. Also, it is no problem to make youself some simple enum, but for modding purposes, this is generally useless. And for 1000 raycasts, also wrong. For each car you have 4 raycasts, for player just one +- some npc's. Multiply that by some constant, you might get maybe over 100. If you want to optimize, disable wheels of other cars. But that is not such a problem, because they don't shoot infinite raycasts. Using infinite raycasts and then calculating vector3.distance is purely retarded solution. Fsm objects are retarded too, hard to find docs, that is why i implemented my own "fuel type". It was'nt very smooth solution, but still more effective with time invested and it was immune to further game updates (naming changes, lets say). Also, there is nothing like RaycastEnter or RaycastExit, that applies only to collisions marked as triggers, that get evaluated in their own physics thread (another thing done by PhysX, i believe)
4 raycasts per car? tf do you even know what you're talking about? each function has a raycast, 3 for each gas nozzle picking up, then a raycast for each container or fuel tank with a cap, then a raycast for items, for car knobs and other interactables, there's countless.
"Using infinite raycasts and then calculating vector3.distance is purely retarded solution." oh so weren't you who implied that I should just make the raycast distance infinite? also just use RaycastHit.ditance.
"Also, there is nothing like RaycastEnter or RaycastExit" did you even look at the github page? because to me it sounds like that was a blatant lie.
I was reffering to default unityEngine voids, not yours (which honestly make no sense) Also, yes, there are only 4 raycasts from car, it also hints that each one is for wheel. Gas nozzles and other stuff like fuel caps are interacted from players camera position and forward vector, there are absolutely no raycasts going from car to check for player. You kinda seem to lose yourself in the logic... Only player makes one raycast and this one raycast goes through of series of conditions, like what is being grabbed etc. I'm kinda surprised you are even able to pull out something like this out, when you have little to no knoledge, of how the game works...
Also, one raycasts returns the actual object that got raycasted, no matter what object it is, so player uses only one raycast, not that nonsense you think happens :)
oh ok, I guess doing Ray ray = new Ray(Input.mousePosotion.ToWorldSoace()) in hundrets of objects count as 'just 1raycast' Sorry for asuming you had a working brain, next time Ill tell you that its just magic since thats obviously the only way you could comprahend it - by not.
oh and lemme tell you another thing, nobody forced you to use it, dont see the point in you making s#*! up. and if youre asking for help to understand it, youve done a bad job at that
thanks, but I don't think so, being required to call the IsInRange in all methods and thus needing to reference the mod is kinda annoying, and I haven't done proper documentation on how to configure layers and stuff with it because quite frankly I don't understand them myself really x)
but hope I figure out a fix for the 1st problem and update it (ofc trying to keep support with mods writen in the old version)
well, i hope you don't give up, it's not worth to give up as long as you made a function for a game, like the cd player base, that's a popular function that is easy to use, and you can make a better one with this one
Give Feedback
12 comments
although that hardly will make a difference since there's like a 1000 raycasts running all the time in game already.
see here, not everything is a beer bottle, not everything is gonna just need a text at the bottom saying "beer bottle", raycasts are also used for player functions, like the gas nozzle picking up function for example... go figure.
oh and also is it better to get an FsmGameObject and nothing else, and checking if the game object isnt null, then if it has the right name, then the right tag, layer, etc. and then having to add messy bools for converting that from a thing that gets called on each frame then, to a method that gets called only when it becomes the right object, or is no longer the right object...
you know... OnRaycastEnter(), and OnRaycastExit()...
and about the raycast lenght, idk why but I thought a longer raycast would be more cpu intensive, my bad for implementing code that increased it only if needed, but that's hardly anything bad. I can remove those 2 lines of code if you hate them so much and move on.
"Using infinite raycasts and then calculating vector3.distance is purely retarded solution."
oh so weren't you who implied that I should just make the raycast distance infinite?
also just use RaycastHit.ditance.
"Also, there is nothing like RaycastEnter or RaycastExit"
did you even look at the github page? because to me it sounds like that was a blatant lie.
Sorry for asuming you had a working brain, next time Ill tell you that its just magic since thats obviously the only way you could comprahend it - by not.
but hope I figure out a fix for the 1st problem and update it (ofc trying to keep support with mods writen in the old version)