Well if that is the case then there is a problem for us who relie on prone lean. Not something I will scream about though and willing to wait patiently until fixed. Still an amazing piece of work.
Last edited:
disturbingly differing dynamic displacement damage system of differentiatable doom
- Thread starter yurch
- Start date
-
Two Factor Authentication is now available on BeyondUnreal Forums. To configure it, visit your Profile and look for the "Two Step Verification" option on the left side. We can send codes via email (may be slower) or you can set up any TOTP Authenticator app on your phone (Authy, Google Authenticator, etc) to deliver codes. It is highly recommended that you configure this to keep your account safe.
Any chance to separate bulletsounds from the damage system? Not a biggie maybe, but the damage system inside the bulletsounds mutie is just weird.
ok me and geogob are doing extensive tests from all angles and taking screenshots. Report coming ASAP.
geogob
Koohii o nomimasu ka?
extensive is the word. it's worse than i thought... 
Got about 100 screenshots and 5000 shot fired... only for the head...
Putting up a report asap
Got about 100 screenshots and 5000 shot fired... only for the head...
Putting up a report asap
Last edited:
That's most likely a combination of lag an LIIIa armour, which I'd guess most people wouldd take in Siberia.
geogob
Koohii o nomimasu ka?
Ok here are the preliminary results for the testing NT and I did yesterday. We took about 3 hours testing only the head and around. This report is in the form of a .doc file explaining about 111 screenshots. Some screenshots have been modifed to show specific elements.
The screenshots have been upload in 2 archives. One of them in tif format (zip compression), the other in gif. The problem with jpeg is that UN17's red dot for the socom is hardly visible. (BTW I found a bug with your red dot... i'll post it in the correct thead asap).
so here it is. enjoy.
GIF screenshot archive - 41 MB - Archive of screenshots in gif format.
TIF screenshot archive - 144 MB - Archive of screenshots in tif/zip format.
Report - 145 KB - MS word document explaining the screenshots and the identifed problems.
For obvious reasons, I did not document every thing we tried (e.g. when there was no bug). For exemple, if the horizontal limit for the head was correct, i did not put in the report. 5000 screenshots would have been needed... that would be 7+ GB in tif format...
The screenshots have been upload in 2 archives. One of them in tif format (zip compression), the other in gif. The problem with jpeg is that UN17's red dot for the socom is hardly visible. (BTW I found a bug with your red dot... i'll post it in the correct thead asap).
so here it is. enjoy.
GIF screenshot archive - 41 MB - Archive of screenshots in gif format.
TIF screenshot archive - 144 MB - Archive of screenshots in tif/zip format.
Report - 145 KB - MS word document explaining the screenshots and the identifed problems.
For obvious reasons, I did not document every thing we tried (e.g. when there was no bug). For exemple, if the horizontal limit for the head was correct, i did not put in the report. 5000 screenshots would have been needed... that would be 7+ GB in tif format...
geogob
Koohii o nomimasu ka?
Wow, looks very complete guys. Good work. Hoepfully this will be enough details for Yurch to move foreward.
Just one quick question, related to Logan's issue above. Is the netcode sufficient to support this type of mutator or is it possible that one of the reasons for the overbloated hit cylinder and the fact that it continues to propogate in the current UT2Kx games is that it is a buffer to help eliminate lag issues? Am I even making sense? Probably not. Feel free to slap me.
Just one quick question, related to Logan's issue above. Is the netcode sufficient to support this type of mutator or is it possible that one of the reasons for the overbloated hit cylinder and the fact that it continues to propogate in the current UT2Kx games is that it is a buffer to help eliminate lag issues? Am I even making sense? Probably not. Feel free to slap me.
Lol, good work but
One can hope yurch will continue to code this, but I'm not sure how much more he can do.
As for the animations, I know this is going to sound stupid but is there any (or perhaps any simple way) of applying the cylinders to the animations? I know very little about animation, but would there be some way of running the animation, having it output the position of model during those frames, and then applying the cylinders via some algorithm? Or would all of these changing cylinders be too processor intensive while INF was running.
Also would this be easier to do in UT2K4 with the bones? (Something along the lines of defining a cylinder to a bone etc.) Again let me know if this is insane, or if you've tried it already.
yurch said:
One can hope yurch will continue to code this, but I'm not sure how much more he can do.
As for the animations, I know this is going to sound stupid but is there any (or perhaps any simple way) of applying the cylinders to the animations? I know very little about animation, but would there be some way of running the animation, having it output the position of model during those frames, and then applying the cylinders via some algorithm? Or would all of these changing cylinders be too processor intensive while INF was running.
Also would this be easier to do in UT2K4 with the bones? (Something along the lines of defining a cylinder to a bone etc.) Again let me know if this is insane, or if you've tried it already.
Yea but these are standing still animations we are testing. We are not moving around or doing anything else. IIRC correctly those positions should be perfect all around. Plus there were major bugs found as you can see which shuld be addressed. And yurch, please report your opinion on these testings ASAP we are spending alot of time to help you, and if these tests arent helping we dont wanna spend another 6 hours of our lives for nothing.
Yes but as it stands (IIRC) there is only one model for standing, nothing changes for aiming, or each gun, so that could be part of the problem (perhaps we should superimpose the orignal model onto the screenshots and see if that accounts for some of it.) I agree some of these are major problems, but it helps to know whats causing them as well.
geogob
Koohii o nomimasu ka?
I don't know what's the point to quote yurch... if he's not interested he'll tell us himself
We did this to give him a helpfull hand by doing a full detailed report on our findings. It's also a response to Mute's post. And we just feel like doing it. We did that for so long yesterday we were really sick of it. I can see why yurch or anyone else doesn't like to do such tests.
So the more we do for him, the less he as to do himself, hence the more coding he can do
And I'd agree with NT. These testings are quite tedious... if that's not what you need or if you need some specific information I forgot to put in the report, yurch, if you could tell us asap that would be very nice of you.
as you may have noticed from my report and from my other post, i'm already putting my finger on a cause a a lot of bugs related to the original INF itself. the more I test, the more my second hypothesis seems correct.
Furthermore, I would like to add that we I obeserved major inconsistencies, total weirdness or stuff like that, I tested it with different weapons. For instence, all those screenshots with the psg1 have been tested with other weapons as well. Most of the test we initially conducted with UN17 socom + LAM which seems pretty weel zeroed.
It's not always easy to test like that because of some weird **** with INF weapons. Crazy zeros, bullets flying in weird directions...
We did this to give him a helpfull hand by doing a full detailed report on our findings. It's also a response to Mute's post. And we just feel like doing it. We did that for so long yesterday we were really sick of it. I can see why yurch or anyone else doesn't like to do such tests.
So the more we do for him, the less he as to do himself, hence the more coding he can do
And I'd agree with NT. These testings are quite tedious... if that's not what you need or if you need some specific information I forgot to put in the report, yurch, if you could tell us asap that would be very nice of you.
revens_hawk said:
as you may have noticed from my report and from my other post, i'm already putting my finger on a cause a a lot of bugs related to the original INF itself. the more I test, the more my second hypothesis seems correct.
Furthermore, I would like to add that we I obeserved major inconsistencies, total weirdness or stuff like that, I tested it with different weapons. For instence, all those screenshots with the psg1 have been tested with other weapons as well. Most of the test we initially conducted with UN17 socom + LAM which seems pretty weel zeroed.
It's not always easy to test like that because of some weird **** with INF weapons. Crazy zeros, bullets flying in weird directions...
Last edited:
Has anyone looked at this from the gameplay-side? I used to find it annoying how someone could strafe+sprint out of a door and immediately fire and kill me from a block away. With BS4, whether or not it was right, you would have trouble killing me if i were a house away!
geogob
Koohii o nomimasu ka?
yes. but if you cant put a bullet in the head with a psg1 from one block away, it aint better either. The point is not to have a larger hit detection surface, but to have a correct one. (e.g. not to have the head 5 feets behind and over the real position of the head).
Okay, Damn. It's readily apparent I'm not going to be able to keep up. I really just don't play the game anymore in it's current state, and as a result, reasons to work on BS4 don't come up often. I feel bad though, as it wasn't fair for me to start all these projects to never finish them, and it certainly isn't fair for me to sit on them now when others are the ones that have to live with the problems.
No, this isn't a goodbye post, I'm not gone yet. Real life, with me getting back to classes and actual social contacts, plus the occasional other game is taking precedence.
If you are willing to make the effort, the mutator in it's current state shouldn't be too hard to modify. I should be able to provide you with the knowhow needed to at least add and modify 'cylinders', and probably help you figure out how to test for something specific.
I'll start this in a second post in a minute.
Ut2k3/4 Headshots are checked via 'closeness' to the phyiscal head bone, so it may be possible for someone to do a system much like we are using here for ut2k4, using the bones with much more accuracy.
I don't think lag really comes into play all that much, hit detection is handled on the server, only the results of which are sent to the client - bandwidth really shouldn't change.
No, this isn't a goodbye post, I'm not gone yet. Real life, with me getting back to classes and actual social contacts, plus the occasional other game is taking precedence.
If you are willing to make the effort, the mutator in it's current state shouldn't be too hard to modify. I should be able to provide you with the knowhow needed to at least add and modify 'cylinders', and probably help you figure out how to test for something specific.
I'll start this in a second post in a minute.
Not so much lag as 'fairness'. Most players feel frustrated when missing when they think they should have hit. Combine this with the wildly varying playermodels (skinny saphire vs powerarmor gorge) and you can start to see why they kept the old system.shan said:
Ut2k3/4 Headshots are checked via 'closeness' to the phyiscal head bone, so it may be possible for someone to do a system much like we are using here for ut2k4, using the bones with much more accuracy.
I don't think lag really comes into play all that much, hit detection is handled on the server, only the results of which are sent to the client - bandwidth really shouldn't change.
Last edited:
geogob
Koohii o nomimasu ka?
BS4 works by taking hits to the player, passing them through a 'filter' which simulates several stretched spheres ('pill' shapes) and applies or ignores damage from the calculated results. We have tried to make this as flexible as possible for the purposes we have imagined for it.
That being said, there are two main categories of 'bugs' in BS4:
Things that are my fault.
Things that aren't quite entirely my fault.
The latter is almost always a failed hit detection caused by the bullet never actually being picked up in the first place. Usually places not covered by the original hitcyl.
Bugs in the former category can be from three things:
Cyl/pill placement error - it's located or rotated in the wrong place. For example, our placement rotations become the opposite direction when we converted some things by hand on occasion.
Animation inconsitancy - related to the first, but exaggerated by subtle changes, like the arm/head positions for different weapons, head lookup/down, and even breathing.
Underlying geometry check errors - Fairly unlikely, but still a possibility. This can take the form of not enough variables being taken into account, the best example being the still unfixed prone-pitch adjustments. Actual code errors in the geometry check are utter fucking nightmares to fix, and they aren't something I'd wish on anyone. The good news is they cause almost total randomness in the hit detection, so any errors should have been noticed in the early stages by now.
The 'insanity scope' is somewhat useful for testing cylinder position and animation consistancy, provided it's updated with everything else. It will work for the host of a listen server, although not for clients.
The geometry filter is first applied according to what 'state' the player is in (prone, leaning left, standing, ect) and then checks the cylinders in order, stopping when it reaches one, reporting the location and dealing damage to the target. The head should be first for all states, and the order of body parts should be fairly consistant across the board. In the mutator this has become basically a huge database of if statements and function calls.
If anyone is interested, I'll get into the fairly extensive description of how the psudopills are defined later.
That being said, there are two main categories of 'bugs' in BS4:
Things that are my fault.
Things that aren't quite entirely my fault.
The latter is almost always a failed hit detection caused by the bullet never actually being picked up in the first place. Usually places not covered by the original hitcyl.
Bugs in the former category can be from three things:
Cyl/pill placement error - it's located or rotated in the wrong place. For example, our placement rotations become the opposite direction when we converted some things by hand on occasion.
Animation inconsitancy - related to the first, but exaggerated by subtle changes, like the arm/head positions for different weapons, head lookup/down, and even breathing.
Underlying geometry check errors - Fairly unlikely, but still a possibility. This can take the form of not enough variables being taken into account, the best example being the still unfixed prone-pitch adjustments. Actual code errors in the geometry check are utter fucking nightmares to fix, and they aren't something I'd wish on anyone. The good news is they cause almost total randomness in the hit detection, so any errors should have been noticed in the early stages by now.
The 'insanity scope' is somewhat useful for testing cylinder position and animation consistancy, provided it's updated with everything else. It will work for the host of a listen server, although not for clients.
The geometry filter is first applied according to what 'state' the player is in (prone, leaning left, standing, ect) and then checks the cylinders in order, stopping when it reaches one, reporting the location and dealing damage to the target. The head should be first for all states, and the order of body parts should be fairly consistant across the board. In the mutator this has become basically a huge database of if statements and function calls.
If anyone is interested, I'll get into the fairly extensive description of how the psudopills are defined later.
Well, I could have said I'm just too damned lazy.geogob said:
Chances are I'll still be screaming at the ucc compiler quite a few more times.