Wow Phoenix-D, very nice argumentation indeed. I wasn't defending... I only explained how it is coded. So, I can only tell you what I have scripted and if you want to look at the codes... they are free and easy to access.
All we do is setting a projectile to a different location. Maybe check the map in UED and take a closer look at the location this shooting at the sky test was performed on.
The 'stepping' occurs in 16UU steps. So, the thicker a wall, the more SetLocation calls will occur. The SetLocation function itself shouldn't cause much trouble in terms of performance due to it being one of the base functions that each and every actor has to use at the time the actor is spawned into the world. Even if the Spawn and the SetLocation function aren't the same, they act the same way in terms of setting the actor to a specific location. So, its internal native function calls should perform exactly the same codes for actually setting the location, cause both return if an actor was able to be placed at the given location or not, using the same test criterias. So the collision and whatnot checks these two functions perform should be the same.
So, if SetLocation would have a huge impact performance wise, then spawning of a dozen projectiles in itself would cause performance issues. And this spawning happens with and without the mutator being active in our 'shoot into the sky' example.
If you check out the RO maps a bit, then you will notice that the 'skyboxes' are huge if not to say giant or whatever you want to prefer to use for "really really... really huge". Some maps use blocking volumes that surround the actual accessable map parts and some use nothing at all around these areas. And each projectile has a life span of 5 seconds. Well due to the penetration it can happen that a projectile will travel very very far now if it was able to get outside of the playing area and the map has then nothing more around to let it hit something. This 'area' goes up and down, so even with the ballistics these projectiles will have a lot of free area to cross before something like a fakebackdrop surface actually shows up or the 'zero space' starts to exist...
Same is true for non-penetrating projectiles that you ie fire over buildings that then are able to reach these areas too.
Whoever came up with subtracting a tripple giant box out of the Unreal universe to place only very tiny maps within (tiny if you compare the huge outside cube with the actual area the map is placed in) should maybe rethink what they actually did.
All we do is setting a projectile to a different location. Maybe check the map in UED and take a closer look at the location this shooting at the sky test was performed on.
The 'stepping' occurs in 16UU steps. So, the thicker a wall, the more SetLocation calls will occur. The SetLocation function itself shouldn't cause much trouble in terms of performance due to it being one of the base functions that each and every actor has to use at the time the actor is spawned into the world. Even if the Spawn and the SetLocation function aren't the same, they act the same way in terms of setting the actor to a specific location. So, its internal native function calls should perform exactly the same codes for actually setting the location, cause both return if an actor was able to be placed at the given location or not, using the same test criterias. So the collision and whatnot checks these two functions perform should be the same.
So, if SetLocation would have a huge impact performance wise, then spawning of a dozen projectiles in itself would cause performance issues. And this spawning happens with and without the mutator being active in our 'shoot into the sky' example.
If you check out the RO maps a bit, then you will notice that the 'skyboxes' are huge if not to say giant or whatever you want to prefer to use for "really really... really huge". Some maps use blocking volumes that surround the actual accessable map parts and some use nothing at all around these areas. And each projectile has a life span of 5 seconds. Well due to the penetration it can happen that a projectile will travel very very far now if it was able to get outside of the playing area and the map has then nothing more around to let it hit something. This 'area' goes up and down, so even with the ballistics these projectiles will have a lot of free area to cross before something like a fakebackdrop surface actually shows up or the 'zero space' starts to exist...
Same is true for non-penetrating projectiles that you ie fire over buildings that then are able to reach these areas too.
Whoever came up with subtracting a tripple giant box out of the Unreal universe to place only very tiny maps within (tiny if you compare the huge outside cube with the actual area the map is placed in) should maybe rethink what they actually did.
Last edited:
Upvote
0
