Multiplayer Testing Times?

Discuss the Wing Commander Series and find the latest information on the Wing Commander Universe privateer mod as well as the standalone mod Wasteland Incident project.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Thanks, guys; I'm gonna try after work.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Well, it's un-playable for me. Several times I restarted the game and there's this Confed hornet fighting someone else. I can't hit it even once, and once he's done with the other guy, I can't target him at all; always in my 6. I'm sitting on the arrow key but I can't turn fast enough, and with just a few of his shots I'm gone. This is the same problem I reported a gazillion times, and never gets fixed: It defies the laws of physics that a ship could fly around me faster than I can turn, and it makes the game un-playable and no fun. But before you guys give me the standard line that the game doesn't cheat, beware that the cat is out of the bag already: I remember the videos that John Cordell showed once, with ships moving sideways, up and down, like they have no mass at all, faster than the head of a printer... This is just the game cheating against the player, 100%.
I hate the music too; hope this is not the original WC music.
Sorry to have negative feedback to give; I'm sure there's great new features in it too, and new ships and whatnot; but a few things can ruin the experience.
Anyways, I haven't tried it multiplayer yet. I'll try substituting Privateer music before I do, tho. ;-) But I'm not a big fan of multiplayer gaming, so not the right play-tester for that.
Last edited by chuck_starchaser on Tue Sep 19, 2006 11:07 pm, edited 1 time in total.
spiritplumber
Developer
Developer
Posts: 1831
Joined: Mon Mar 07, 2005 10:33 pm
Contact:

Post by spiritplumber »

I put a couple bots in the game... and yes, that's the original music, straight from the PC version. The Amiga version has somewhat better music.

I really need to get off my ass and fix the AI.
My Moral Code:
- The only sin is to treat people as if they were things.
- Rules were made for people, not the other way around.
- Don't deceive. Real life is complicated enough.
- If all else fails, smash stuff.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I don't think it's your fault, spirit; and I don't think the problem is with the ai. It's just that the ai's seem to have access to ridiculously powerful, if invisible, vertical and lateral thrusters, which the player doesn't. It's also the fact that the rotational speed of the player's ship is artificially capped to a very low value. It's also the fact that that if your speed is set at max and you try to turn and the vertical and horizontal jets can't cope with that rate of turning, the engine prevents your nose from turning faster than the ship's vector of motion is turning, for no reason whatsoever. These are all physics problems, not AI.

In fact, your job should be to try and make the AI's smarter, to try and match the player's real ai. You shouldn't have to work with the goal of making the ai's dumber, to try and compensate for the unfair advantages that they enjoy from being above the physical laws. It's the physics that needs fixing, and the fact that ai's are given unfair advantage, in the form of access to the lateral thrusters. But both this cheat, and the physics problems, I suspect, are well buried and hidden in the VS code. I'm positve there's nothing you can do about it from the python side.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

You nailed the problem, but not, Chuck.
The physics is the cuprit, but it isn't wrong.
It's the "simulation quantum". Sometimes, units that should be prioritized aren't, and they're coarsely simulated. The result: decoupled turning. That is, you don't see what the physics layer thinks, but rather a coarse interpolation of it. It makes things look horribly unreal. It shouldn't happen, but the basic physics equations are somewhat alright (I'd have to check much more than I have to be 100% certain).

Anyway... I'm sure the video John posted is about the simulation quantum. That's a problem that will eventually be solved 100%, I hope.
To tell the truth, it's been a while since I've seen it happen, so I don't get it happening to you that often.
Anyway2, I'm sure we'll have a config variable to disable that eventually, as not all mods need it.

About the AI defying physics before that bug was introduced... I bet they don't. They only move as their stats say they should. I bet if you reduced the angular acceleration limits on their ships, and disabled all forms of shelton slide (the user has it disabled, but the AI not yet - spirit, could you check that?), it would look more natural.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

I think you're mistaken. I'm not saying there isn't an issue of simulation choppiness, but the maneuvers that were visible in John's video showed ships moving up, down, sideways, backwards... That's not a problem with precision. And it's no shelton slide. That's application of vertical and horizontal thrusters. I'm positive.

Now, I have no rear-view mirror, and I cannot tell you that for sure that's what this hornet was doing behind me. But I can't imagine what else it would be. I was pushing down the down arrow key almost through the keyboard, continuously, and the damned hornet was stuck at the edge of my radar, that is, right behind me, continuously. How can that be?
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Did you try an external camera?
Don't forget the brand-new padlock either (in VS it's F7... you'll probably have to bind the key in WCU).

And believe me when I tell you that the issue on John's video is simulation choppiness. When the physics system simulates a long quantum. The weirdness comes from interpolating linearly position and rotation, that is, a C0 interpolation (in math terms), rather than using a C1 interpolation, which accounts for constant acceleration. Basically, a C0 interpolation results in infinite acceleration at simulated points. Usually, when simulated points are close enough, you don't perceive it as such, only as gradual acceleration. But when they're full seconds apart, you will notice the infinite acceleration.

I would love to code a C1 interpolation, it's not that hard. Problem is, it may change things for the AI, and there has been a lot of work in making the AI properly account for interpolation issues, so I don't want to mess all that work.
I dunno... perhaps I should tag and try, a C1 interpolation would do wonders.

(BTW: think of C1 as a quadratic interpolation against a linear one - more than C1 is hard, as we would need second-order derivatives, that is, dA/dt, which we don't have).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Ok, I'll give you the benefit of the doubt, at least. ;-)

What about Runge Kutta 4 or RK5?

Years ago, I had a paper about game physics. The authors of that paper devoted a whole chapter to try to convince the readers that nothing below RK4 was efficient. They were saying that the precision benefits far outweigh the extra code, and that to get similar results from lesser algorithms increasing computation frequency results in much more computations per unit of time.

Bah, we talked about this and you told me there's no elasticity; just acceleration/inertia, so, ok, C1 should do. What about this simulation atom issue? Can that be fixed. I once looked at the code for that, found mistakes, including unreachable code, posted them, and got no reply.

The concept of tuning AI to a deficient underlying simulation system, and then avoiding fixing the problems to avoid disturbing the ai, sounds horrible. That's like avoiding cleaning up code in order not to have the files marked as changed on svn...

If VS keeps locking itself out of any possibility of progress in such ways, it will be obsolete as an engine pretty soon.
Improved graphics and networking aren't going to make up for crappy physics and ai.
Look at what's coming up next year: A galaxy with billions of star systems, realistically sized planets and moons and asteroids. The planets have autogenerated terrains, dynamic weather and clouds, including tropical storms, cities, space stations, trading, missions, piracy, and it's massively multiplayer... and has a story, to boot...
http://fl-tw.com/Infinity/infinity_media.php

And a video here: Notice what it says in the opening screen: 60 to 120 fps... Choppiness is an artifact of the video...
http://downloads.planetmirror.com/pub/m ... _moddb.avi
spiritplumber
Developer
Developer
Posts: 1831
Joined: Mon Mar 07, 2005 10:33 pm
Contact:

Post by spiritplumber »

What happens is that the differential simulation atoms were introduced as an attempt to handle situations in which you have a shitload of ships on screen... and it does compound the problem with prediction in multiplayer. I wish there was a way to put it back where it was (PR 1.0 / 1.1), for example as a .config option, but I don't know if I can touch that part of the engine...
My Moral Code:
- The only sin is to treat people as if they were things.
- Rules were made for people, not the other way around.
- Don't deceive. Real life is complicated enough.
- If all else fails, smash stuff.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

Spirit... it's pretty easy and (IMO) inconsecuential to add that option. In fact, I think a few config variables for the "differential simulation atoms" would be a good idea, allowing you to tweak them for your mod rather than accepting the hardcoded ones (for instance, WCU/PR would only need reduced priority for asteroids, nothing more).
If I wasn't debugging other stuff right now, I'd do it. So... to-doed.
chuck_starchaser wrote:The concept of tuning AI to a deficient underlying simulation system, and then avoiding fixing the problems to avoid disturbing the ai, sounds horrible. That's like avoiding cleaning up code in order not to have the files marked as changed on svn...
Truly horrible. But it might break lots of stuff...
...hm...
...I guess you convinced me.
As soon as this f***ing bug I'm tracking gets squashed (*), I'll try to enhance the interpolation and simulation step (they both have to be done as a single step). And I think I misclassified the interpolation... I could do a C1, but a C2 would be better and possible (second order derivatives == acceleration, silly me) - only for C3 and up I'd need third order derivatives, which aren't there on the engine and adding is... well... not worth it.

(*) Pardon the language, but I've been at it for several days... it's getting on my nerves already.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

And we've actually digressed from the main problem. The main problem manifests itself as my sitting on an arrow key and yet not being able to turn fast enough to face an enemy.
This is because the engine, for no reason whatsoever, wants the player's ship to always face in the direction it is traveling. But every time we get into this discussion, shelton gets named and all our thoughts get derailed.
Shelton has nothing to do with it. Let's separate the issues:
The shelton key disables the automatic firing of the invisible lateral and vertical thrusters. This is completely un-related to the orientation of the ship. Whether or not the thrusters are trying to get my speed vector to be aligned with my ship's nose, I should be able to turn the ship around if I want to.
I could understand that hornet sticking like glue to my 6 if I was driving a Paradigm, but I'm in a small ship, and to not be able to turn my ship around fast enough to face another ship is simply absurd.
spiritplumber
Developer
Developer
Posts: 1831
Joined: Mon Mar 07, 2005 10:33 pm
Contact:

Post by spiritplumber »

Hmm... I had the opposite complaint also (ships being too maneuverable, and it being too easy to overshoot). Do you use joystick, mouse or keyboard?

What I do know is that, at least in WC1 and 2, internally the AI's maneuverability is cut down quite a bit. Maybe we should add a multiplier, and make it difficulty-setting-adjustable... that's like 3 lines of code, I want Daniel's permission to do it though.
My Moral Code:
- The only sin is to treat people as if they were things.
- Rules were made for people, not the other way around.
- Don't deceive. Real life is complicated enough.
- If all else fails, smash stuff.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

spiritplumber wrote:Hmm... I had the opposite complaint also (ships being too maneuverable, and it being too easy to overshoot). Do you use joystick, mouse or keyboard?
I tried to use the mouse but it's too slow, so I was using the keyboard instead. Read my post again; I said I was pushing the down arrow key almost breaking the keyboard.
What I do know is that, at least in WC1 and 2, internally the AI's maneuverability is cut down quite a bit. Maybe we should add a multiplier, and make it difficulty-setting-adjustable... that's like 3 lines of code, I want Daniel's permission to do it though.
Please don't make any more things difficulty setting adjustable. Real physics are NOT difficulty settings adjustable. They follow inexorable laws. What we should be doing is the exact opposite: Searching the entire source tree for any occurrrences of difficulty setting dependencies and deleting them. Once that's done, working on the physics until they are right. And then re-think what difficulty settings should do.
There's one thing difficulty settings should NOT do, and that's a million things, like they do now.
Difficulty settings should affect just the number or strenth of the enemies. Absolutely nothing more. All that game acceleration crap has to go away: What kind of universe is it, that speed and acceleration and gravity and gazillion other immutable or unrelated things would vary with "difficulty". Like this crap about automatic landings if you choose relaxed gameplay. Totally arbitrary, like just because I choose relaxed gameplay means I don't like to land my ship manually?
Anyways, I digress; the thing is that there is something terribly wrong with the physics if I have a small ship, supposed to be light and maneuverable, and yet I cannot turn it around to shoot at an enemy. There is something very, very wrong. Turning your ship's position around should be a lot easier than for another ship to fly around you to stay always behind you. Wouldn't you agree. It's as if I kick your ass, and you turn around as fast as you can, but I somehow manage to race around you so fast I'm still right behind you and I can kick your ass again. Would that make sense to you? Doesn't make sense to me either. And it's not a matter of saying "maybe we should increase this" or "decrease that parameter". It's a matter of there not being a functional physics system at all. If there was, you'd only have to enter the push power of the engines, and the ship's mass, and everything would be alright automatically, without tweaking this or that parameter.

Otherwise it's like with bad electrical engineers. You know, if I'm designing a DC motor drive, I calculate exactly how much gain I need for voltage feedback, so that 90 volts on the motor map to, say, 4.5 Volts at the A/D converter input. In the microcontroller program, I document the units and scaling of every variable. For the output, I calculate how much phase angle I need to produce 90 Volts on the motor's terminals, and when the design is finished, I can count on better than 5% accuracy over-all. But most engineers calculate nothing, document nothing, take wild guesses at everything, then they spend a month tweaking parameters, and when the thing starts to sort of work they look so proud; but if they need to make any changes, they have to spend a month tweaking again. Resistor here, capacitor there, increase this, decrease that, add a trim-pot...
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

chuck_starchaser wrote:Totally arbitrary, like just because I choose relaxed gameplay means I don't like to land my ship manually?
Would you prefer a separate setting for that?
(what a question... of course you would)
Anyone knows his way around Setup?
I bet adding the field would be a no-brainer.
chuck_starchaser wrote:Anyways, I digress; the thing is that there is something terribly wrong with the physics if I have a small ship, supposed to be light and maneuverable, and yet I cannot turn it around to shoot at an enemy.
Think about it, Chuck. That's not a problem with physics, it's a problem with balancing. With the dataset fed to the physics system. I'm not saying the physics is perfect, but I don't see how any of the problems of the physics system (grainy simulation, discrete rather than continuous collision detection, rather incorrect stepping between atoms, etc...) could result in your problem. I do see, however, how an imbalanced dataset would.
It's simple, chuck: the hornet you were fighting outmaneuvers your ship.
There is, though, another issue. I've noticed the keyboard tends to fail to achieve maximum turning speed if your running on low FPS - I really don't know why, I bet it has something to do with the smoothing out of keyboard input, if there is such a thing. In any case, there is a problem with keyboard input (try joystick if you can, joysticks works great), but I bet you weren't running on low FPS.
Anyway... if the hornet outmaneuvers you, there's two questions to ask:
a) should it? (canon-wise)
b) should it? (gameplay-wise)

Simple as hell.
First one is simply checked: go find the turning rates of the ships on one of the many places where you could.
The second one, is the difficulty setting issue. I know you don't like it, but if gameplay isn't as fun with canon-based settings, you can disregard canon for gameplay's sake, and make the hornet less maneuverable than it should - for AI (you want the player to feel the truth). In fact, you make every AI ship less maneuverable. That's indeed not a violation of physics, only a difficulty-based AI impairment: pilots don't turn as fast as they could on their ships, for some reason. If you want it somewhat more realistic (to make it bareable), add some variance, so that not all of them do equally bad. You can't say dumber pilots aren't a sensible way of tweaking difficulty.

The other thing that may be affecting you is the lack of "response times" on AI - AI pilots immediately respond to your maneuvers. That is, evasive maneuvers don't shake AI pilots as much as real pilots, as AI doesn't have any difficulty in coping with attitude changes. If you know AI limitations, you'll make your task much easier. I believe you're trying to exploit inexistent weaknesses of the adversary pilot, and so failure is frustrating as it contradicts your intuitive premise: that the adversary will get confused by some maneuvers. What destabilizes AI most is not random attitude changes - rather, you have to induce high angular aspect changes - that is, you have to change quickly from his 12 to his 9 or 6, or things like that. That messes up the AI's tracking algorithm for a tiny while, allowing you to get on his six and track him instead.

Know your oponent.

In any case, you know how it would get fixed? With more realistic AI flaws - specially-crafted, purposeful flaws, rather than the accidental involuntary coding flaws that the AI now has. I don't think coding such a great AI is possible with the limited language at our disposal right now - we would need higher expressiveness, like Python or C++. We have python, but it's slow. So we could use C++, but we don't have it. I'd most certainly propose having it. In VS terms, it would take the form of a permanent hardcoded script, "behave naturally", with perhaps subscripts only affecting the goals, not the base AI.
I'd love to do some AI work, but I don't understand that part of the engine very well, nor do I have enough time given all the other tasks I'm already commited to.
chuck_starchaser wrote:It's a matter of there not being a functional physics system at all. If there was, you'd only have to enter the push power of the engines, and the ship's mass, and everything would be alright automatically, without tweaking this or that parameter.
Why are you so fixed on that POV?
Suppose you have that perfect system.
So what?
Can't you feed that perfect system wrong data?

I say simply this: VS's system is not perfect, but it's a good enough approximation so that you shouldn't be having the problems you're having. If you are, then I blame the data. Use better data.

What ship were you flying?
What's its maximum angular acceleration?
What's the hornet's?
What's both ship's maximum linear acceleration in all directions?
Do those numbers make sense to you?
Should the hornet, given those numbers, be able to shadow your ship without hope?

Don't fall on the falacy of assuming that because you were on a smaller ship you'd be faster and more maneuverable. Smaller ships may not generate enough power. In fact, there was this trend on Sci-Fi sometime that faster ships would be bigger, just because of this. Given enough technology, faster ships would be able to generate more power - perhaps, just perhaps, enough extra power to push their bigger mass with higher acceleration than possible on smaller ships.
chuck_starchaser wrote:Otherwise it's like with bad electrical engineers. You know, if I'm designing a DC motor drive, I calculate exactly how much gain I need for voltage feedback, so that 90 volts on the motor map to, say, 4.5 Volts at the A/D converter input. In the microcontroller program, I document the units and scaling of every variable. For the output, I calculate how much phase angle I need to produce 90 Volts on the motor's terminals, and when the design is finished, I can count on better than 5% accuracy over-all. But most engineers calculate nothing, document nothing, take wild guesses at everything, then they spend a month tweaking parameters, and when the thing starts to sort of work they look so proud; but if they need to make any changes, they have to spend a month tweaking again. Resistor here, capacitor there, increase this, decrease that, add a trim-pot...
I'd apply that comment to the AI, not the physics.
It's the AI who's responsible for having perfect reflexes all the time, even when humanly impossible.
It's the AI who's responsible for using ship features you're not capable of using (which isn't unrealistic, only unfair).
The same physical limits applied to your maneuverability get applied to the AI's, AFAIK. I could check again, but all AIs are derived from FlyByWire, whose task is to map "want to's" with "push this way". FlyByWire automatically caps out-of-bound accelerations, so no unit can be driven past those limits, not from player controls or AI decisions.

So... in a few words... you think your problem is A, but it in fact is B. A being wrong physics, B being wrong AI/playbalance. It doesn't mean A can't be true, it just means it's not the cause of your troubles.

Fixing A is a lofty goal, and would be a way to convince you that A is not the problem (if it gets fixed and your troubles persist).
But I'd urge you to try the B route - try to see if it's the dataset the source of your troubles.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Okay, now I'm getting the picture. Well, in that case the first thing to look at would be FlyByWire and make it filter the thrust commands, so that for any set of thruster and counter-thruster, it takes at least half a second to go from full throttle one way to full throttle the other way.
AI-wise it should be pretty simple to deny AI's the ability to see behind or below their ships; except as dots on the radar screen; and their ability to turn towards a dot on the radar screen should be hampered by fuzziness: Not knowing exactly how much to pull on the stick exactly; which could be modelled as a step-wise function.
Reaction time should be easy to model: Collect all input for the AI and put it through a 2 or 3 stage FIFO.
And then there's the being able to think of one thing at a time thing: While an AI is controlling speed, its maneuvering should lapse, and viceversa. Same thing when changing weapons.
But I mean, for the first thing I could try and look at FlyByWire again, though last time I didn't understand a thing in it. But for the AI things I wouldn't know where to go, even in the most general terms.
You're right about AI dumbness being a valid target for difficulty settings. In fact, maybe that should be THE thing difficulty settings control. What I'm opposed to is difficulty settings affecting physics. I'm sure you agree with me that game acceleration is messing with physics... If you play a movie fast, gravity will seem to increase... Oh yeah, I forgot there's no gravity... But more generally, and as a programmer, I see the intrusiveness of difficulty settings, creating dependencies all over the code, as a disastrous design negligence.
As for data-side stuff, I'll try and look at it tonight.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Klauss, been thinking about your idea. Problem is, if the physics update is going to depend on whether something is in the player's view frustrum, then an enemy that is behind you will still manage to move in absurd ways.
And the trick would be well exposed in multiplayer, where a 3rd party can see things you cannot; unless you check for things not being in the view frustrum of ANY player; but then the benefit will be highly dependent on circumstances.
And you could argue that in the case of multiplayer, the physics will be done by the server; but that's not how multiplayer works in practise: The server rather validates the clients' physics, when packets manage to get there and back, and they validate old data in retrospect. The client has to do the physics anyways, speculatively, if you want to call it that.
I think the only valid physics optimizations are for non-self propelled objects on fixed orbits, or ships that are too far away to matter; but view frustrum optimizations are as safe as scorpions, IMO.
spiritplumber
Developer
Developer
Posts: 1831
Joined: Mon Mar 07, 2005 10:33 pm
Contact:

Post by spiritplumber »

See if the bots in the multiplayer thingy act any better? :)
My Moral Code:
- The only sin is to treat people as if they were things.
- Rules were made for people, not the other way around.
- Don't deceive. Real life is complicated enough.
- If all else fails, smash stuff.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Much better! Almost there. Whatever you did, do 50% of it yet again.
Except the mouse speed: That's a little bit on the too fast side now.

(How hard would it be to have mouse acceleration? Thing is, it seems the mouse is either too slow or too inaccurate; never just right.)

This is how it went:
The bot is doing the same maneuver again, of flying around me, but now I'm able to keep up with the turning speed. *JUST* keeping up, tho; I still can't turn fast enough to actually target him. I can only hit him when he's flying away in a straight line; but then again, that's how I remember the original game being. Except, in the original game they didn't keep flying around me, on and on, for like 3 or 4 turns; they changed directions more often. In fact, they didn't fly around you period. They made passes, which is different.
What's most frustrating about the flying around a long time maneuver is that I can't use the mouse to turn continuously, so I have to use the keyboard, but the keyboard is still a bit slow.

You're definitely going in the right direction; just a tad more; and maybe shorten the time between the choice of maneuvers, if that's one of the tweakable parameters. Or if you can get rid of the fly around completely that'd be the best, IMO.

(And they shouldn't even be able to fly around you, in the first place; the centrifugal force would be ***enormous***. How about making the vertical and lateral maximum acceleration of ships much less than the forward one?)

EDIT:
Oh, yeah, almost forgot; bug report: When I started the game, there was no response to keyboard. None whatsoever. The keyboard was dead; I couldn't set a speed; couldn't afterburn, nothing. I was about to 3-finger it, and then it occurred to me to press the right mouse button to afterburn. It worked, but more interestingly, after that, the keyboard worked.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Post by klauss »

chuck_starchaser wrote:EDIT:
Oh, yeah, almost forgot; bug report: When I started the game, there was no response to keyboard. None whatsoever. The keyboard was dead; I couldn't set a speed; couldn't afterburn, nothing. I was about to 3-finger it, and then it occurred to me to press the right mouse button to afterburn. It worked, but more interestingly, after that, the keyboard worked.
If you play in windowed mode, I've encountered that: VS looses focus while you have the modifier keys pressed (ctrl-alt, not sure about shift). When you release it, the message doesn't get there (because it lost focus), and VS thinks you still have the modifier pressed when you go back to it. The quick solution: when the kb doesn't respond but it should, press and release both ctrl and alt keys in sequence (shift too, just in case).
I'm not sure how to fix that on the VS side, though.

About the frustum thing... you're missing a very important point: acceleration extrapolation. Both the frustum and the unit are "inflated" to a "probable volume" estimated according to maximum accelerations. Thus, the unit on your back would not be on your back for a 10s prediction, as in 10s it would be able to accelerate itself into a position where, if you decelerated in the proper way, would end up on your viewing frustum. Furthermore, I might take into account a "radar" frustum for the player, an inverse conical volume (hollow in the cone's interior, solid on the exterior) that is considered visible through its radar readout (a hack - I know - but it's just for safety, I bet the "probable volume" thing is enough).
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
spiritplumber
Developer
Developer
Posts: 1831
Joined: Mon Mar 07, 2005 10:33 pm
Contact:

Post by spiritplumber »

I have time to play now if anyone cares? :)
My Moral Code:
- The only sin is to treat people as if they were things.
- Rules were made for people, not the other way around.
- Don't deceive. Real life is complicated enough.
- If all else fails, smash stuff.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Post by chuck_starchaser »

Evenings or weekends any time. You have my email, right? (danw^2;)).
spiritplumber
Developer
Developer
Posts: 1831
Joined: Mon Mar 07, 2005 10:33 pm
Contact:

Post by spiritplumber »

Yeppers.

I'm going to try and make a script that shows "who's online" in a webpage...
My Moral Code:
- The only sin is to treat people as if they were things.
- Rules were made for people, not the other way around.
- Don't deceive. Real life is complicated enough.
- If all else fails, smash stuff.
hellcatv
Developer
Developer
Posts: 3980
Joined: Fri Jan 03, 2003 4:53 am
Location: Stanford, CA
Contact:

Post by hellcatv »

ooh
it could just list the directory for .logged files
Vega Strike Lead Developer
http://vegastrike.sourceforge.net/
Post Reply