Like I said, we have it working well enough to release it with HITP mod. It's not perfect, but is a viable feature. TWE-Ryan, if you kmow how to fix the first person animations, especially the POV, please let me know.
Would this work server side? This question was asked before but not properly addressed. From my understanding since the 3rd person views are already there it should be able to be viewed by everyone if placed on a server. Please fill me in this. Thanks.
couldnt you actually change the persons POV? IE if you are launching it as a server side mod that responds to say "walking" and "crouching" at the same time, couldnt you perhaps go even further and make it bound (server sided) to mikeslegs.st? and then in MikesLegs catch "walking" and "crouching" and hitting "+PRONE" to make it go to the prone animations, and then in the prone animation (server side) you tell it to place the players POV lower?
You can't tell the engine to place the pov lower (even if the SDK says the opposite, it doesn't work). There are only 3 heights that work: stand, duck and jumpstart. None of them fills the gap to be used as a prone height and you can't use a custom height. (Errr... yes, I also have it working for 1936, but if I can't fix the POV issue most probably it won't make it into the final version - I used jumpstart as the prone view, since it moves the player's weapon and you "see" when you're proning, but height stays the same as crouching and you can see things you shouldn't see if you were lower). Regards, YoChoy
where are the animations that describe where the POV is supposed to be set? What I think is the SDK is right, the problem is that somewhere in its state info it overrrides it immediately after the pov command is done? IE you do the POV command, but the game is constantly telling it to do the "crouch" command. so what I propose is to do another command entirely. make an entirely other state and take more control over the game, I could take a look at it to see if it can be done if you guys would e-mail it to me, or get on contact on msn harschc@ku.edu ^e-mail and msn
the state machine uses the command "modheight" to alter the height of the player (and the location of the eyes). you can do things like: modheight "stand" modheight "duck" and it states in the g_dump file that you can do: modheight 20 but passing a height doesn't work, it overrides it with stand. stupid mohaa grrrrrrrrrrrrrrrr in fact u can use the 'modheight' in scripting. $player[1] modheight "duck" The engine is just so annyoing with this, even if u rescale or the tik's for the players and view models it still overrides the eye postion, and so far from testing this is true even if u alter the skd/skc's for the viewmodels. and although the 'func_camera' commands would seem to give a way around this by altering the pov, that don't work either, as you can't have a camera per player [well not that i've so far anyway]
I even edited the dll trying to turn jumpstart into something usable when prone (i.e.: lower it), but to no avail. The dll will not process other heights/options, it only recognizes stand (53), duck(30) and jumpstart(34) (numbers may be not exact, but are very similar; that bug in the dumpfile was corrected in the Spearhead SDK, but SH doesn't admit the jumpstart option). These values are hardcoded. Buzz theory is right, however, if you try to modify the bbox: it's redrawn all the time, so modifications don't stay on the model. Definitely interested on this thread, YoChoy
I think the state overriding is done in the mikeslegs.st, which is why i think you would hae to provide a different "state" for it to recognize.... you woul dhave ot add it in the "crouch" states, and the "stand" states, because without doin that the game doesnt recongize the state you want it in (prone) so you provide it with a new state value in those area, so that it doesnt keep setting the modhieght difference. in mikeslegs the modheight difference is done using setposflags which means that there is no real way for you to avoid it.
The states are already defined and included, I don't use either CROUCH_ or STAND_ anymore. But since modheight doesn't work as expected, there's nothing you can do. In mikelegs you use modheight to set the POV and anything differing from the three mentioned options is converted to "stand" by the dll. It's not overriden or something, it just replaces it with "stand" before doing any actions. Scorp, I was about to find something late night :lol:. Have you noticed that when you die your fpv is tied to the 3rd person model?? Well, I digged into anims_shared.txt and voila, it contains the anims used both for 1st and 3rd person view. Unfortunately, when I played any of them on an alive player, the POV moves ok on the X, Y planes, but stays at the specified modheight for the Z plane. However it works as expected when your dead?? Well, anyway I managed to insert a new viewmodelanim when prone, so at least the player using FPV knows when he's proning even if the eyes height stays the same. But maybe you can dig it further... Regards, YoChoy
Yep i've been trying to alter those damn models for a while, but i also couldn't get the damn Z to move Damn thing must be hard coded into the engine. If only the stupid Modheight would accept a height value (As it states it does in the g_dumpallclasses), then everything would work fine. Spose we just keep digging, but i have the feeling were banging our heads against a wall with this. U sure you can't hexedit the default values for stand/duck ?
I hexed them, but that didn't work. What I did was editting the existing values for jumpstart to something like 16 (prone); then it acted as "stand" but without the usual message (unknown height blahblahblah...) on the console log. Looks like there are two different checks on the dll, the one I hexed and a later one. I will keep on trying and let you know if I'm lucky (and share the modifications, of course :winkers. I'm thinking of modifying the dll so that it won't revert the input back to "stand" when the parameter is not listed (i.e.: making it act as it's supposed to). I'm not too optimistic either, but who knows... anyway, if I can use a new viewmodelanim so that the player knows when he's prone, I'm quite happy with it :zzohyah: Regards, YoChoy
Hold them crossed then... I did some more testings yesterday. I found a part of the dll where it plays around with the height numbers (these are exactly, 52 -stand-, 34 -jumpstart- and 30 -duck-). Surprisingly, on that part there was also a "10", which I supposed should refer to the "prone" value. I edited the jumpstart value to 10, but again without results... There are still some tests pending, like editing that 34 on both parts of the dll. Thinking about it, that looks like it could work (I've said that sooooo many times :lol Anyway, I will keep you informed. Regards, YoChoy
Indeed that would be awesome but even then there's still quite a number of issues left. First of all the view position also has to be placed further in front of the player, since the head is way in front of the player origin when proned. A better solution however may be to alter the animations so that the origin is near the player's head, although I'm not sure if it's possible to make this look good. Then also the bounding box has to be altered which won't be easy. Or well, maybe a normal crouched bouding box would do. Tests will turn out :winkers: Finally (hopefully :zpalease: ) the collision needs some work, since (with my little prone 'mod') I was able to fully hide under the terrain in e.g. Destroyed Village at craters (but could still see everything and shoot anyone). Well not wanting to annoy anyone with this. Just a list of obvious problems that still have to be fixed, and if somebody passes by this post knowing a solution for either, let's hope he posts it down here :zzohyah:
The discrepancies with POV and bounding box work both ways, so they tend to even each other out. True, you can go prone and see and shoot at players without being seen in some cases; but you can THINK you can shoot at players when you really can't. You can also be hidden behind something from your perspective, but sticking through it where you are an easy kill to others. HITP testers have gotten used to it and it's never even mentioned any more. It's just part of the game. Which, is all you can ever ask of any mod.
what would kick ass is if you guys made your own state that checked for +CROUCH and +USE that would make it so you could bind going prone to +CROUCH and +USE then people could bind alias +prone "+movedown;+use" alias -prone "-movedown;-use"
We have set prone as the default "down" position for some weapons. The difficulty with making it optional is you are never sure, since your POV doesn't change. Ideally, I'd like prone to be triggered by pressing down when you are already crouched. But, I think we need some sort of display or indicater to show you are prone.
My first implementation was exactly like that, but what happens if you're setting a bomb (or capturing a flag) while crouching?? :look: Right now in my mod you go prone by clicking crouch while crouching, then you press space to go back to crouch and then again to stand. But I would like to have the POV fixed so much... or at list some first person animation so that the player knows he's prone... Time will tell :winkers: YoChoy