@Avid:
You seem to underestimate my understanding of the methods at work here.
I know what interpolation is, I've dealt with it many times and have utilized it in many ways for different effects. I have even made my own interpolation code which strips down a model's animation data and depending on the interpolation given (I used different parameters than DBP uses) it would use in-between animation frames. The reason I don't use it is because it wasn't optimized and ran very slowly, but in hind sight it may have been because I used some seriously processor intensive techniques to smooth out and predict how the new animation frames should be made... like you said, the in-between frames on some would produce a wider curve instead of simply doing:
newX# = (frame(2).X - frame(1).X) / interpolation + frame(1).X
newY# = (frame(2).Y - frame(1).Y) / interpolation + frame(1).Y
newZ# = (frame(2).Z - frame(1).Z) / interpolation + frame(1).Z
That code would produce a straight line between the animation frames whereas it is more intuitive to give an intelligently placed frame to "mold" the new frames into what may have been an intended curve.
DBP code is slower than C++ code, there is no arguing it, and since the built-in functions of DBP are essentially compiled C++ functions utilizing DirectX, it just isn't in my best interest to try and best the DBP functions given to me by making my own functions through DBP code. (Though I have done this before when I found some faults with the built in DBP commands to find an object's on-screen location) I could very well make a plug-in, but seeing as how I'm short a decent C++ compiler with which I am familiar, that's not in my best interest either.
With that in mind, I have since been using and will continue to use the built-in DBP interpolation function.
As for building in a gunspec option for crouching accuracy... why would you want each gun to have it's OWN accuracy modifier? Isn't it logical to assume that crouching provides the same amount of stability for your gun (if any) no matter what that gun may be?
In any case, here's what you can do instead:
- Find out what weapon the player is holding through the use of "haveweap"
- If the player has the weapon you're looking for then give them an accuracy multiplier that reflects that weapon
Example:
:state=2:setvar=Temp 0
:state=2,haveweap=scifi/tavor:plraccmult=150,setvar=Temp 1
:state=2,haveweap=scifi/autoslug:plraccmult=125,setvar=Temp 1
:state=2,varequal=Temp 0:plraccmult=100
TADA!!! If the player is holding a tavor, it'll give him 1.5x accuracy, whereas if he's holding an autoslug, it'll give him 1.25x accuracy. A bonus to this script (assuming the variable was declared earlier) is if the player is holding a weapon that WASN'T checked for, then it'll reset his accuracy multiplier to 100% (Default)
I do agree with you, though, that I am lucky. I am lucky to be able to do the things I can, but I consider YOU to be the lucky one here since I am doing this for you and everyone else wanting to use this Mod.
As for the difference in visualizing code versus a fully animated 3D model that you can't touch... consider the fact that you can't touch math... you can't SEE math even when it's done and implemented. Can you visualize the difference in trajectories between two objects? Can you visualize how one would find that difference and store it in a meaningful way that the program can utilize it for multiple purposes? How about visualizing the connection between a polygon touching another polygon and a polygon NOT touching another polygon? Can you visualize how one would go about finding if they are touching or not? What about intersecting at any and all angles/positions? I'm going to guess that you can't. You see... okay, you don't... no body "sees" this, it just happens. Programmers need more visualizing than a 3D modeller. We need to visualize ANYTHING that the modeller could possibly concieve and devise a way to deal with it. We visualize the unreal, the UNSEEN, and we analyze it, calculate it, and manipulate it. We deal in the imaginary concept of numbers and because of that we are able to visualize much more than a simple object that moves. We may not be proficient in creating these objects, but we can definitally visualize them.
When you get the chance, try visualizing two spacecraft flying around each other. Their movements are not based on something you or anyone created. Their movements are based on the player's whim and can be anywhere and go in any direction. Now try visualizing the distance between them, the angles at which they are from one another... now put some math to that. What mathematical functions will you use to optimally determine everything about these two ships and their relationship with each other? This brings in more visualizing.
And if you haven't been keeping up, I made a lightsabre!!! I visualized it in my mind, modelled it, UV mapped it (to some extent, lol), and animated it!
Also, I don't know what you mean by "fixing the source code"... what exactly is broken about it?
I'm pretty sure we CAN do whatever it is your modelling tool does, but the problem here is efficiency. While you are modelling, some tasks may seem instantaneous to you, but try having the processor do it 60 times in a second WHILE doing everything else needed to make the game run. If you sit and think about what you're asking of the engine, you'll realize that by making the animations yourself and relieving that duty from the engine, it will not only WORK but it'll run faster because of it.
Now, after all of that... I commend you for knowing enough about modelling to do what you do, and I especially am jealous that you have a way to turn real life movements into an animation on the computer. I've always wanted to try that myself.
@meteorite:
Some commands suggested in the challenge thread will eventually be implemented. I'm glad to hear you found the problem you were running into with the command. Hope everything works out for you.
About the settargetreticle command... what you can do is move your character aside right before using the command, then move him back in place. It will happen before the screen is refreshed so the player won't be seeing the character blinking to side or anything like that.
Since you already know where the character should be, what you could do is just put him at these coordinates while the raycast is being calculated: -1000,-1000,-1000
Then move him back to where he was after the "settargetreticle" command.
@Airslide:
Let's not get into that here, okay? We all know how much code and math is behind making any game, so let's not start a battle on what profession is easier.
I think it'd just be easier to say, "It's unrealistic to ask the engine to perform 10x more calculations per second when you could have modelled it that way to begin with."
The one and only,
Those who live in the past, are destined to insanity. Those who live only for the future, will be slaves to their ambitions.
Those who live in the moment... only they, are truly happy.
