Free Allegiance Forums

training missions use 'static_core' which seems to be unmodified.

The ship is Advanced Fighter(488). In static_core, all 3 values for yaw,pitch & roll for this ship are set to 1.0472

Which is what I get when debugging the mission (line 8126 and line 8132):
I get both 1.0472 for pitch & yaw. If I change 'c_axisYaw' in the second line with 'c_axisPitch' I also get 1.0472 (obviously...)

As you said in a previous post here, this makes no sense.

To test ICE and the core loading code, I modified and changed yaw & pitch values for advfig488 to different values: these new value are correctly showing in the 2 lines above.

So for sure now, it's not a core or ICE issue.

The problem is elsewhere. But I still don't understand it clearly so I can't really investigate more.

may be try explaining the problem from scratch without referring to any code and values ?

QUOTE Once the game is started, don't move, just zoom in at the base in front of you and move the joystick. Do this with both running clients and you can clearly see that the fig using the X values from the core is far more sensitive (slewing 67.5 degrees per second) than is the other client where you have 1.0472 in both axis max turn rate values.[/quote]
so it's about JS sensitivity & dead zone when zoomed and only when zoomed ? yaw sensitivity only ?
something that changed between R4 et R5 ?

I'll put together a test on video with a better description, I'll try to do this later today.

It's difficult to explain and it's not so obvious unless you are using the js in a specific way. Yes, this all came about at the release of R5. The problem was even in the Alpha version prior to releasing R5. It's as though speed and torque took on a new feel and fine adjustments became impossible with that stair climbing affect.

You cannot make fine adjustments especially when you're moving just a few pixels at a time. R4 has perfect reaction in both axis'.... R5, 6 and 7 are out of whack.

The reason I say to zoom in on something is because that is where you can visually see a speed change when moving from a dead stop. The pointer accelerates faster and unequally in both axis compared to R4 which works perfectly and consistently thru all speed ranges.

https://www.youtube.com/watch?v=YmLUoF8e8Vc Video of the test wasp and i made when investigating the issue

Senor NoirSol wrote:QUOTE (Senor NoirSol @ Mar 15 2016, 03:18 AM) https://www.youtube.com/watch?v=YmLUoF8e8Vc Video of the test wasp and i made when investigating the issue

The issue I'm referring to in this thread is the unpredictable reactions of the x and y axis which is most noticeable when making fine adjustment such as when you are nearest the deadzone where the controller is moving the pointer at the pixel level. The X axis feels as though it's doubling up. If you switch the values (use Yaw value for Pitch), you can then feel it in both axis.

I'm still working on getting a video together. I'm busy as hell so it'll likely be in the next couple days.

This is near impossible to show on a video since it requires you to "feel" the difference. I'll keep trying though.

It "feels" and, when testing, is visually clear that there is more speed being applied and it is most prevalent in the x axis. It "feels" as if the ship has less weight. The pointer movements are quicker and it is as if the quadratic rate (which I use) comes onto the accel ramp much sooner. So, any quick movement from a stopped position on the stick results in an over reaction in whatever axis is highest on the quadratic ramp.

Say I'm turning left at 50% joystick deflection which is being applied to the quadratic curve. And lets say I have say 25% joystick deflection on the y axis...if I move the stick very slightly yet VERY quickly on the x axis (as when moving at the pixel level to fine tune your aim)...I get an exaggerated movement in the x axis which far exceeds the value called for. It's like that slew is completely gone and I get instant acceleration to the point the joystick deflected to.

In R4, flying a JS is very fluid. It's as though you are in water. Every release since then has been like flying in very thin water that has currents in it. I've been experimenting with various computers, windows timers, joysticks...with the same results. If you have a joystick, launch R4 and fly around using sidethrusting and what not and you'll notice this right off. I and many others have reported and confirmed this...I'm just doing whatever I can to zero in on it. It is most noticeable and indisputably visual when trying to turret with a joystick. Joysticks were unbeatable in turrets <=R4.... R5 and beyond, you can't track squat in a turret with a joystick.

It appears that this issue affects controller input / pointer speed (observed by the faster acceleration on the quadratic curves) or some axis value or axis influencing calculation. Now if ya want, I'll bring a joystick over and R4 and R5 and you can see it right off.

I run R4 and R5 side by side...I'm sitting still zoomed in at the base in the training mission... alt-tabbing back and forth while moving the JS and I can clearly see that R5 moves faster and without the weight / torque feel of R4.

Could you check the torque values to see if they're getting through?

Are all the "R4 tests" you're mentioning here done with the version BT posted here : http://www.freeallegiance.org/forums/index...st&p=697675 ?

Sort of..., the tests and communication have been on forum threads, through messaging and at home tests and of course, BT's monumental efforts on GitHub.

From your recent GitHub construction , I have been able to build and test from commits right after R4 was deployed. Unfortunately, I haven't been able to build any of the early 2008 .exe as I'm unable to get VS2005 to work correctly,..maybe win7 x64 giving me trouble. Any chance you could build me a exe from commits 189, 192 & 193? I can't get them to build.

If all the ship speed and torque and what not is getting passed to the client properly, then I figure it's either the window shape or something to do with frame step / dt?

like I said, I'm no coder....but if I can test each build starting from R4 release date moving forward, I'll spot it right off in the training mission. The speed, poling rate, x and or y axis or engine window shape is definitely out of whack.

I've got the registry and artwork stuff together so that I can just drop an .exe into the folder now and test.

Thanks again for your attention on this. I'm certain 99% of the community is unaware of this problem because they use mice. The joystick makes this problem obvious (for obvious reasons).


EDIT:, hold off on that build request, it appears I need vs2005 sp1 installed...doing so now...

EDIT-1: Can't for the life of me get VS2005 to build allegiance.exe

Sorry but you're not very clear...

To be very clear because it's very important for further understanding the issue:

Does the "R7 with R4 engine" version of Allegiance (that you can launch by selecting "Use Directx 7 (R4 Engine)" in the preferences menu) exhibits the issue or not ?

There were two versions that BT made available using the the Dx7 option in the launcher.

The first experiment was with a bastardized version of R7 that used the R4 engine. You can find that HERE. The second experiment was a duplicate R7 client with ONLY the slew code changed in Wintrek.cpp and that version is currently available by selecting the Dx7 option in the launcher...it's really just R7, BT just didn't bother to rename the option in the launcher.

To answer your question...the problem does exist in the "R7 using R4 engine" version that BT created. That version is no longer available on AU and if anyone has it, it will be replaced with the "slew modified R7 version" on their next update. To be clear, "R7 with R4 engine" is no longer available or being tested since it has been confirmed that it DOES exhibit the same problem.

Wasp wrote:QUOTE (Wasp @ Mar 24 2016, 02:40 PM) There were two versions that BT made available using the the Dx7 option in the launcher.

The first experiment was with a bastardized version of R7 that used the R4 engine. You can find that HERE. The second experiment was a duplicate R7 client with ONLY the slew code changed in Wintrek.cpp and that version is currently available by selecting the Dx7 option in the launcher...it's really just R7, BT just didn't bother to rename the option in the launcher.

To answer your question...the problem does exist in the "R7 using R4 engine" version that BT created. That version is no longer available on AU and if anyone has it, it will be replaced with the "slew modified R7 version" on their next update. To be clear, "R7 with R4 engine" is no longer available or being tested since it has been confirmed that it DOES exhibit the same problem.

ok so as of today, we don't have yet the source of latest version (in term of commit number) that doesn't have the problem. This is what you're trying to find.

I can't help much on this front because I only have VS 2012 and VS 2015 so I can't build older commits between R4 & R5. I'll try anyway if I can find some time.

Meanwhile, I dug some old notes and compiled a short document highlighting important parts of Alleg code: the main loop(s) and where the js values are read from the hardware and where they're used.
it's here: https://docs.google.com/document/d/1jYc ... sp=sharing

short explanation: At each loop , the engine gets the input values (js, mouse, kb, etc ) from the hardware with UpdateInput(). The game udpates its logic with UpdateFrame. The values are passed from one to another using a 'stream' (JoystickInputStreamImpl for instance).

I can explain it more if it's not clear. By examining code changes (commits) between R4 & R5 around these parts of the code , we might find something relevant to the issue. But it's better first to find the latest commit without the issue.