PDA

View Full Version : Suggestion: FM debug mode



XyZspineZyX
09-24-2003, 06:17 PM
/this post is in a process of adjustment


The basic idea is to make a speedbar for the enemy plane too (in replay mode and QMB, not online, activable from conf.ini).

Because there are a lot of complaints about the way aircrafts loose speed my suggestion is to make a debug mode, which when selected, will display more detailed information about your plane and the plane you're engaging.

Speed bar for the plane engaged (for example the plane kept in view with internal or external padlock, or last viewed in external or some other criterias, for example the criteria AI choses the aircraft to engage) with the basic information: speed, alt and direction, plus a very useful G-load meter.


Player/Host should be able to switch it off of course. Is not meant to give more information about the enemy in combat. It is not for cheating, it is for debugging.

If it can be used only at replay then it is good enough, though I'd like to use it in QMB, it will cut a lot of time involved in testing.

An ideea would be to disable it permanently for online use, but it should be available for online tracks replay.



Think about how useful tool the debug mode with arrows proved in debugging the DM. A similar tool is needed for FM.

What do you think?



<center> http://www.stormbirds.com/images/discussion-main.jpg </center>

Message Edited on 09/25/0304:32AM by Huckebein_FW

XyZspineZyX
09-24-2003, 06:17 PM
/this post is in a process of adjustment


The basic idea is to make a speedbar for the enemy plane too (in replay mode and QMB, not online, activable from conf.ini).

Because there are a lot of complaints about the way aircrafts loose speed my suggestion is to make a debug mode, which when selected, will display more detailed information about your plane and the plane you're engaging.

Speed bar for the plane engaged (for example the plane kept in view with internal or external padlock, or last viewed in external or some other criterias, for example the criteria AI choses the aircraft to engage) with the basic information: speed, alt and direction, plus a very useful G-load meter.


Player/Host should be able to switch it off of course. Is not meant to give more information about the enemy in combat. It is not for cheating, it is for debugging.

If it can be used only at replay then it is good enough, though I'd like to use it in QMB, it will cut a lot of time involved in testing.

An ideea would be to disable it permanently for online use, but it should be available for online tracks replay.



Think about how useful tool the debug mode with arrows proved in debugging the DM. A similar tool is needed for FM.

What do you think?



<center> http://www.stormbirds.com/images/discussion-main.jpg </center>

Message Edited on 09/25/0304:32AM by Huckebein_FW

XyZspineZyX
09-24-2003, 06:41 PM
This doesn't make sense. If you are flying in relation to an enemy aircraft you have no idea what it will do and how it will perform - that's the whole idea of the game. Only in formation flight can you gauge the attitude of another aircraft. If the game was somewhat predictable like that it would take the fun out of it ... and it's bad enough that people use labels and padlock anyway.

XyZspineZyX
09-24-2003, 06:57 PM
KG26_Thief wrote:
- This doesn't make sense. If you are flying in
- relation to an enemy aircraft you have no idea what
- it will do and how it will perform - that's the
- whole idea of the game. Only in formation flight can
- you gauge the attitude of another aircraft. If the
- game was somewhat predictable like that it would
- take the fun out of it ... and it's bad enough that
- people use labels and padlock anyway.


Player/Host should be able to switch it off of course. Is not meant to give more information about the enemy in combat. It is not for cheating, it is for debugging.

If it can be used only at replay then it is good enough, though I'd like to use it in QMB, it will cut a lot of time involved in testing.

An ideea would be to disable it permanently for online use, but it should be available for online tracks replay.


<center> http://www.stormbirds.com/images/discussion-main.jpg </center>

XyZspineZyX
09-24-2003, 07:52 PM
Yeah I know where you're coming from but it will detract from the elemnt of unpredictability in the game. When you look at WW2, pilots would be somewhat aware of what the oponents aircraft was able to do but the information would not be exact, so I can see your argument. I recommend you try using the aircraft viewer to get a better idea of comparisons. Get it at this link if you haven't done so already.

http://mudmovers.com/Sims/FB/fb_essential_files.htm

XyZspineZyX
09-24-2003, 07:57 PM
KG26_Thief wrote:
- Yeah I know where you're coming from but it will
- detract from the elemnt of unpredictability in the
- game. When you look at WW2, pilots would be somewhat
- aware of what the oponents aircraft was able to do
- but the information would not be exact, so I can see
- your argument. I recommend you try using the
- aircraft viewer to get a better idea of comparisons.
- Get it at this link if you haven't done so already.


How would it unpredictability decrease if this mode will be available only at replay?


<center> http://www.stormbirds.com/images/discussion-main.jpg </center>

XyZspineZyX
09-24-2003, 08:09 PM
Hehe, I get it. I think it's a great idea Huck. It will definitely save a lot of time testing, and hopefully will provide clear evidence either for or against many of the FM claims made here.

<center>http://flygirl.dhs.org:8080/jg51/Alpine-Thunder.jpg


3./Jagdgeschwader 51
www.jg51.com</center> (http://www.jg51.com</center>)

XyZspineZyX
09-24-2003, 09:21 PM
Because it didn't happen like that historically speaking. I think using the aircraft viewer would be more accurate and more relevant to what people knew about enemy aircraft at the time (WW2.)

Remember, of course, why better versions of aircraft were released throughout the war, stolen technical specifications and the such? All this information was kinda vague which is one reason why improved aircraft types were developed - you need to try and out do your enemy. Besides similar aircraft at a certain time, say 1943 or something, were not too vastly diferent from each other, probably because of available technology, but a 1940 Mk2 Spit and a 1944 FW190D9 would obviously be totally different. That's why there's the saying, "know your enemy's capabilities" You had to learn it from experience, it just wasn't given to you on a plate and besides what an aircraft was supposed to do and what it actually did fall a bit short of the mark.

XyZspineZyX
09-24-2003, 09:45 PM
While this could possibly be useful, here's two problems with that idea:

1. doing this over a network will only be as accurate as the maximum transfer rate of data between clients. There will always be an unremovable element of lag warping which may skew comparisons.

2. doing this offline against the CPU means making comparisons between a human player and an AI controlled craft using a simplified flight model. Not great for accurate comparisons either.

I think that implementing a 1/10th of a second figure to the trk file playback would be a far less time consuming activity for the developer. Alex Voicu made this suggestion as part of his La7/Bf109K energy bleed comparison charts and I think it's a good idea. Having only full seconds makes it quite hard to assess any of the information Huckles mentioned [Gs, instantaneous turn, etc].




http://home.iprimus.com.au/djgwen/fb/worker_parasite.jpg

Need help with NewView? Read this thread. (http://forums.ubi.com/messages/message_view-topic.asp?name=us_il2sturmovik_gd&id=yzbcj)

XyZspineZyX
09-24-2003, 11:01 PM
clint-ruin wrote:

....

1. lag is easy to spot so you can ignore the values obtained during lag; though it might be interesting to find out lag's influence on performance

2. offline is interesting too, because the developer said in number of times that AI has the same FM with human players.

3. I don't believe that track files contain information specifically for the speed bar, it is calculated in real time. So it can be calculated for enemy plane too.

Parameters like pitch, roll, yaw and sideslipe angles are necessary if the FB FM uses formulas not tables, therefore they can be displayed. If the developer consideres that this is too difficult then at least the basic speed bar for enemy plane will be ok.


<center> http://www.stormbirds.com/images/discussion-main.jpg </center>

XyZspineZyX
09-24-2003, 11:51 PM
If such a speedbar could be read only in replay and only for the plane the replay view is attached to then a person could pause replay and check any state of flight wanted or watch along any one plane. REPLAY ONLY would ensure no chance of in game abuse. REPLAY ONLY would cut lag out of the equation.

In that case it would be a powerful tool for learning how to judge and understand some of the circumstances behind what has happened in a mission. It won't stop whining totally, maybe even give whiner more to whine with/about but the majority of users would have something very good. I am sure that such information is readily available to the sim itself. It just needs to switch the information from player plane only to whatever plane the view is locked onto with no extra controls needed. So maybe it is not a big thing to ask for?


Neal

XyZspineZyX
09-25-2003, 12:06 AM
The thing is though, that other than client side prediction, there is no information available to your client as to the current speed, roll rate, etc, of the enemy craft in a multiplayer game, that I know of. CSP does not depend on knowing any of those things, either. There's also no consistency checking on what aircraft are able to do, as evidenced by the response to receiving suspect data "cheating detected" - it's just written off as lag. The prediction makes assessing what effects are due to lag/network processing delay, and which effects are due to FM inconsistencies very hard if not impossible to do.

If you need to do comparisons I think they're best done under the same game settings from a player client only.

As to whether the AI use a simplified flight model, I'm pretty certain they obey the limits shown in Il2Compare, but it's more a matter of how they perform within them, if you know what I mean. I don't believe that FB AI craft use the full physics of the FB engine to determine what they can do. I'd be quite interested to see how FB handles say, 40-60+ aircraft per mission, like it does in the ones I make, with the same exact simulations running on all of them as for the player, as well as everything else involved [graphics/sound/game world], and not suffer any real noticable speed difference as compared to running around with only a couple of aircraft.

http://home.iprimus.com.au/djgwen/fb/worker_parasite.jpg

Need help with NewView? Read this thread. (http://forums.ubi.com/messages/message_view-topic.asp?name=us_il2sturmovik_gd&id=yzbcj)

XyZspineZyX
09-25-2003, 12:51 AM
The client is processing the enemy planes in the same way it's processing the players plane. I do recall reading way back in the IL2 days that only control inputs, occasional positional updates, and DM related info is transferred over the wire.

This makes sense too when one considers the limitation on flyable a/c in MP in this game as compared to others. If every client was only processing it's own players FM with the host coordinating it all, the limit of simultaneous players would be much higher.

That means that Hucks idea would be plenty feasable for online play.

XyZspineZyX
09-25-2003, 03:09 AM
BlitzPig_DDT wrote:
- The client is processing the enemy planes in the
- same way it's processing the players plane. I do
- recall reading way back in the IL2 days that only
- control inputs, occasional positional updates, and
- DM related info is transferred over the wire.
-
- This makes sense too when one considers the
- limitation on flyable a/c in MP in this game as
- compared to others. If every client was only
- processing it's own players FM with the host
- coordinating it all, the limit of simultaneous
- players would be much higher.
-
- That means that Hucks idea would be plenty feasable
- for online play.



Um.

That's possibly the most ******ed idea I've ever heard of.

I'm wondering how it is you propose that one would handle packet loss, lag, and synchronisation if each player is effectively remote controlling a plane on every single client individually.

Was it you who was mentioning you're a network engineer and have a low opinion of university graduates in IT?

I really do hope to god it's just my reading comprehension getting the sense of what you're saying wrong, or I really fear for whoever has to live on any kind of network you run.


http://home.iprimus.com.au/djgwen/fb/worker_parasite.jpg

Need help with NewView? Read this thread. (http://forums.ubi.com/messages/message_view-topic.asp?name=us_il2sturmovik_gd&id=yzbcj)

XyZspineZyX
09-25-2003, 03:16 AM
Well,online play aside,I'd support this idea....

47|FC
http://rangerring.com/wwii/p-47.jpg

XyZspineZyX
09-25-2003, 03:19 AM
necrobaron wrote:
- Well,online play aside,I'd support this idea....

I think the whole point of the idea is that it works online. Huck can later pour over a replay and work out the precise point where another plane pulls something "unfair", allowing him to fine tune the point at which he should hit his "VVS NOOB LOL LOL ROFL LOL" macro.


http://home.iprimus.com.au/djgwen/fb/worker_parasite.jpg

Need help with NewView? Read this thread. (http://forums.ubi.com/messages/message_view-topic.asp?name=us_il2sturmovik_gd&id=yzbcj)

XyZspineZyX
09-25-2003, 03:22 AM
Well, I meant I wasn't getting into the online play debate you guys were having. I should've been more clear...

47|FC
http://rangerring.com/wwii/p-47.jpg

XyZspineZyX
09-25-2003, 05:21 AM
Clint, it's just your inability to comprehend much of anything really. You proved it yet again.

I could hand hold you through it, but, I really don't have the time or interest. If you really understood much of anything about networking and programming, and were capable of making logical connections of any sort, you'd understand it quite well.

However, I suspect you just might understand what I wrote and realize just how far off your post is, but, your inner-troll prevents that from getting in the way of you trying to take yet another shot at me.

You've actually become obvious, played out, and boring man. Time to think up a new schtick.

XyZspineZyX
09-25-2003, 05:58 AM
clint-ruin wrote:
- The thing is though, that other than client side
- prediction, there is no information available to
- your client as to the current speed, roll rate, etc,
- of the enemy craft in a multiplayer game, that I
- know of. CSP does not depend on knowing any of
- those things, either.

I really think that CSP would require those values even if it had to calculate them internally from updates as to position, motion vectors and twist on 3 axes or whatever is sent. How do you keep a plane rolling, turning or moving in the next possibly half second or more between updates without those?

- There's also no consistency
- checking on what aircraft are able to do, as
- evidenced by the response to receiving suspect data
- "cheating detected" - it's just written off as lag.
- The prediction makes assessing what effects are due
- to lag/network processing delay, and which effects
- are due to FM inconsistencies very hard if not
- impossible to do.

With lag the data would always be suspect, yes considering the online phenomenon known as warping. There are probably min-warps that aren't noticed but would be if the data was running below. Oh well, another one bites the dust.

So I guess that such a tool might only be good for offline play and then it's the AI as you point out that's a problem. Well possibly on a LAN it would work well.


Neal

XyZspineZyX
09-25-2003, 06:24 AM
BlitzPig_DDT wrote:
- The client is processing the enemy planes in the
- same way it's processing the players plane. I do
- recall reading way back in the IL2 days that only
- control inputs, occasional positional updates, and
- DM related info is transferred over the wire.

That's pretty much how I understood it. Control changes don't happen as often as position, vector and attitude changes so it makes more sense to do it that way.

However with positional updates the planes do warp however far the predictions vary from the updates which is easily visible with bad lag.

This takes a bit of thought... positional updates still wouldn't affect speedbar data for the other plane, only the position. Would positional updates include attitude and speeds in all dimensions? (plane might be skidding, ploughing, etc) Wouldn't those cause jumps in the data as that plane is effectively restarted with every update?

It is less data to transmit but I wonder about how twitchy the display would look on playback.

I don't know though how FB netcode really works so it's all only speculation on my part. It makes sense to me is all that the offline code could be used for online with the other planes controls handled through the host with as you say the position/status updates added in. In place of the aircraft AI soaking up CPU cycles and resources there would be netcode soaking up CPU cycles and resources.

It doesn't mean that's how it's done though. The whole thing could be position and status (DM, attitude & vectors, movement vectors) on every plane over and over from the host while the client keeps sending the host updates back.


Neal

XyZspineZyX
09-25-2003, 06:39 AM
-
- clint-ruin wrote:
-- The thing is though, that other than client side
-- prediction, there is no information available to
-- your client as to the current speed, roll rate, etc,
-- of the enemy craft in a multiplayer game, that I
-- know of. CSP does not depend on knowing any of
-- those things, either.

- I really think that CSP would require those values
- even if it had to calculate them internally from
- updates as to position, motion vectors and twist on
- 3 axes or whatever is sent. How do you keep a plane
- rolling, turning or moving in the next possibly half
- second or more between updates without those?

I don't think it comes down to predicted speed at all, just a position trend would do it. Doing things the hard way by sending pitch/roll/yaw control input [note that this is different from instructions on how to draw the model or where the prediction thinks it will be in another 1/2 second] would be good for flooding the network but I don't think it would make things any more accurate for it.

Just as easy to make the other planes an arbitrary dumb object in the game and describe their movement via a positional trend, let the prediction sort out smoothing the jumps. No problems with consistency, the player aircraft are just where the server says they are and doing what the server/csp thinks they're doing. XYZ position and facing information doesn't have to bear any relation to what a plane is capable of, it just has to look good to the players. Static actions [distribution of debris from a crash, fires, path of a bullet, etc] are all handleable locally.

Nonetheless I could be "uninformed" and FB may indeed use a system whereby raw control inputs from every client are merely routed via the server to each other, with each players PC drawing every plane fully simulated as player aircraft in the game world of each client via each clients own local physics/game engine. Which was about the only sense I could get out of DDTs post. But as I said, I have no idea how you would handle synchronising that, nor what would happen when you try to run something like that over a crappy tcp/ip link.

But, whatever - could be wrong :>


http://home.iprimus.com.au/djgwen/fb/worker_parasite.jpg

Need help with NewView? Read this thread. (http://forums.ubi.com/messages/message_view-topic.asp?name=us_il2sturmovik_gd&id=yzbcj)

XyZspineZyX
09-25-2003, 07:57 AM
Maybe for friendly aircraft, but to me it's a cheat if you have it for the plane your engaging.

Not to mention, pointless.

XyZspineZyX
09-25-2003, 08:04 AM
waterinthefuel wrote:
- Maybe for friendly aircraft, but to me it's a cheat
- if you have it for the plane your engaging.

It can't be a cheat since it can be used only at replay.



- Not to mention, pointless.

Pointless to you because you don't understand it's use.



<center> http://www.stormbirds.com/images/discussion-main.jpg </center>

XyZspineZyX
09-25-2003, 08:43 AM
Sounds like an interesting idea Huck. I have to say, some of the posters here can't seem to decide if they should walk to work or take a sack lunch. I think you know what I mean lol.



IRON SKIES
As real as you want it to be.

XyZspineZyX
09-25-2003, 09:36 AM
I thought more of it and maybe the most important additional info in speedbar would be the G-load (Lift calculation from G-load can be made easily), because pitch and roll angle are displayed in no cockpit view and for the level of precission these calculations will have yaw and sideslip angle are not the main concern.

So a speedbar for the enemy plane with an additional accelerometer will be more than enough. An accelerometer was requested many times, it will be a popular addition. We can keep it permanently in speedbar, because the pilot feels the G-load all the time, not only when he's starting to blackout.


<center> http://www.stormbirds.com/images/discussion-main.jpg </center>

Message Edited on 09/25/0304:39AM by Huckebein_FW

XyZspineZyX
09-25-2003, 05:43 PM
I don't think it's a cheat at all because there's an option to turn it off, but I don't think it would be realistic, as I mentioned. In real life you wouldn't know when the oponents aircraft changes mixture level, prop pitch, throttle or whatever.

XyZspineZyX
09-25-2003, 06:36 PM
Hmmmm, I think it was suggested as a replay feature online, not a real-time one.

Server side control would make the "cheating" part moot, as well, if it were "real time." Just as one doesn't enter into servers that don't match their preferences for realism/difficulty, so could one do the same with servers with this option.

The difference, of course, is the way online tracks are recorded versus offline.

However, it would be very useful to take an online track of a dogfite online and see information from other aircraft as a training tool.

Indeed, it would be awesome to take the cockpit view of other aircraft in the same manner as your own in playback.

"How did that guy get his plane to do that? Man, I just spin and stall when I fly that plane!"

Now you can hop into that guy's planes and follow through with his controls and learn something. Heck, it might even make the sim more enjoyable.

XyZspineZyX
09-26-2003, 02:33 AM
Going point to point and knowing the time between the points (which may be near or totally impossible, or might be easy if compared to the player-plane or some other timing) the speed shouldn't be hard to come up with. Nor the altitude. I would only want what is on the speedbar now so rollrate is no issue to me.

It does make sense that sending only changes to the controls states would require less bandwidth but yepper if packets get dropped then the plane will jump and warp on the next full positional update every time. I wonder how often that happens? I do know that packets don't always arrive in the order they are sent either but that doesn't make the case for positional updates only any stronger either. My guess is that there isn't as much losses in a tolerable connect anyway and that bad lag disconnects via the anti-cheat should squash most of that.

It would be cool to know more about how netcodes work these days, but those are trade secrets.


Neal

XyZspineZyX
09-26-2003, 09:07 AM
Hi Huckebein

I am concerned too about the energy bleed characteristics of FB planes and i made a few measurements and comparisons recently. Here's a link where you can find details about the testing and evaluation procedures: http://www.alexvoicu.home.ro/enbl_comp.html
It's a long read; conclusions are at the bottom of the page (the big complex chart) and seem to confirm the feel you get when flying german planes. I think you'll find it interesting; let me know what you think.

Alex "Bloodhound" Voicu