autopilot code

[cracken]

Can anybody please point me to the code that is executed when shift+a is used?

I would like to modify it so that it controls the time compression so that the entire trip is done in about 4-5 seconds.

This may involve a bit of a rewrite of the control system that is used, since using high time compression seems to result in overshoot.

I'm a bcms math major, main skills in numerical analysis, calculus and computational mechanics. I'd like to have a go at figuring out how the game engine works if anyone can point me in the direction of the documention, or if that fails the appropriate source files.

[loki1950]

the auto-pilot maps to "ASAP" as to where that is in the actual source i don't know time compression is very unstable you drop precision every frame.

Enjoy the Choice

[klauss]

You can start tracing it from FlyByKeyboard::EngageSpecAuto
(ASAP = Automatic Spec Auto Pilot, I guess).

That's vegastrike/src/cmd/ai/flykeyboard.cpp/h

AFAIK, it binds your unit to an AI routine, an utterly passive "fly to" AI, which is a building block for more complex AIs. That is, you can't touch it without first separating its usage as ASAP from its usage as an AI module.

[lee]

There is already a class ´MoveTo´ ... As far as I can see, enabling ASAP queues an order (´AutoLongHaul´) that makes the ship heading to the target and then somehow applies speed/acceleration, but no more. This is done in navigation.cpp.

Is it possible to queue a ´MoveTo´ order instead of ´AutoLongHaul´? I tried, but my understanding of C++ is insufficient.

keyboard.cpp, 248:

Code: Select all

  if (SSCK.ASAP) {
    SSCK.ASAP=false;
	if(FlyByKeyboard::inauto){
		this->eraseType(FACING|MOVEMENT);
		FlyByKeyboard::inauto=false;
	} else {

		Orders::MoveTo* temp = new Orders::MoveTo();
		temp->SetParent(parent);
		Order::EnqueueOrderFirst(temp);
		FlyByKeyboard::inauto=true;

//		Orders::AutoLongHaul* temp = new Orders::AutoLongHaul();
//		temp->SetParent(parent);
//		Order::EnqueueOrderFirst(temp);
//		FlyByKeyboard::inauto=true;
    }
  }

src/cmd/ai/flykeyboard.cpp: In member function 'void FlyByKeyboard::Execute(bool)':
src/cmd/ai/flykeyboard.cpp:255: error: no matching function for call to 'Orders::MoveTo::MoveTo()'
src/cmd/ai/navigation.h:53: note: candidates are: Orders::MoveTo::MoveTo(const QVector&, bool, unsigned char, bool)
src/cmd/ai/navigation.h:45: note: Orders::MoveTo::MoveTo(const Orders::MoveTo&)
make: *** [src/cmd/ai/vegastrike-flykeyboard.o] Error 1

[ace123]

The reason it doesn't work is that MoveTo takes more arguments.

candidates are: Orders::MoveTo::MoveTo(const QVector&, bool, unsigned char, bool)

This means that it wants a position vector (presumably where you are moving to).

Not sure what the bools and the char are for...you'll have to look at the header (src/cmd/ai/navigation.h line 53) for that.

The problem with this seems to be that you give it a position, not a target, so if your target moves, or especially if you change targets, the MoveTo AI script won't know about it.

However, for now, just put in parent->target.Position() for the position.

[klauss]

I have the strong feeling that AutoLongHaul uses MoveTo, though.
I'm not sure MoveTo is a step forward.

I think you want to see how AutoLongHaul is implemented. I bet it's a subclass of MoveTo or something like that. In that case, one of the bools is surely whether to use afterburner and the other whether to use spec. I'm not sure about the char... probably some other interesting thing for AIs. In any case, you want to see what AutoLongHaul sends in those fields, and set the SPEC one to true.

Though, I'd rather make it configurable through vegastrike.config. It's trivial, you'll see config-stuff almost everywhere, just copy.

[cracken]

Looking in navigation.h/cpp, It appears that the methods used are fairly primitive.

An obvious problem (if i'm right) is that they all use simulation_atom, where they should be using simulation_atom * something::getTimeCompression() yes?

I also noticed that the thrusters on a ship are all reasonably balanced, meaning:
-A ship could accelerate fasture using it's rear and top thrusters
-Apart from where a ship's guns are pointing, it makes little difference which direction the ship is heading in, and thus the massive rear thrusters are just for show

Were the ships made like this to make it simpler to write the AI, and the nav computers?

I also browsed through the unit class, looking for the physics engine, has a complete overhaul of this been suggested? ie. removing most of the attributes/methods of the unit class, and putting them in sub classes of unit?

Two things I would like to do are: rewrite current navigation methods so that they would work well for a ship that has vastly more powerful rear thrusters than the others, and also be stable at large simulation steps. Also implement fly through path methods so that a ship will find a smooth (although I would imagine not optimal) path through a series of points, and possibly find a way to interpolate a set of states, ie.
path.addStep(state(position, heading, velocity, angular_velocity))
nextpath = path.interval[-1] #python list syntax
nextpath.startTime
nextpath.endTime
nextpath.state(time)
If that means anything to anyone

reworking the moveto routines would make flight look much cooler, as ships would be drifting around the system in curving paths, and adding in the sortof keyframe stacks would allow for a much more crafty AI routines to be developed, much more simply.

Still quite new to the source at this stage, is there an architecht around who has drawn up a "what the structure of the vegastrike engine would be like if programmers who want to improve the quality of the code rather than add in something new, spent a decent amount of time restructuring it" diagram/plan?

[loki1950]

Still quite new to the source at this stage, is there an architecht around who has drawn up a "what the structure of the vegastrike engine would be like if programmers who want to improve the quality of the code rather than add in something new, spent a decent amount of time restructuring it" diagram/plan?

that would be hellcatv thou i imagine that the Minister of Information is in the loop

Enjoy the Choice

[jackS]

An obvious problem (if i'm right) is that they all use simulation_atom, where they should be using simulation_atom * something::getTimeCompression() yes?

No, actually. Time compression is designed ONLY as a developer debugging shortcut for addressing any clock dependent behavior. It should not be more deeply integrated into any part of the code base.

I also noticed that the thrusters on a ship are all reasonably balanced, meaning:
-A ship could accelerate fasture using it's rear and top thrusters
-Apart from where a ship's guns are pointing, it makes little difference which direction the ship is heading in, and thus the massive rear thrusters are just for show

Were the ships made like this to make it simpler to write the AI, and the nav computers?

That's an artifact of certain aspects of the ongoing dataset rebalance. Moreover, other datasets (and eventually the VS one) will likely not have this property, so it's highly preferable that the engine not make many presumptions about that property.

[cracken]

With the balanced top/bottom/left/right thrusters, these give the player/AI the ability to aim at something and strafe around, dodging shots. To me this seems like a very bad thing, as it would take a lot of fun away from dogfights. What is the general opinion on this?

What I would like is to have ships handling like jetboats, that is, have one thruster on the back that can output x amount of force strait ahead, or x/3 either left/right/up/down, so as to push the back around, and make the ship rotate, or top-> left, bottom-> right to roll the ship. Other thrusters, apart from maybe ones on the front to help the ships rotate, and maybe brakes, I would, for most ships, omit altogether, for the sake of keeping it real in terms of the combat style, or at least lower them to around x/10

What I'm looking at doing for the nagivation, is calclulating a cubic bezier flight path, given beginning and end positions and velocities.

I don't really know exactly how to go about finishing a path with the ship pointing in a particular direction or with a particular angular velocity with elegance at this stage, however a near enough method could be made.

Do people *really* enjoy travelling around in real time? It just seems like a chore to me.

[loki1950]

Do people *really* enjoy travelling around in real time? It just seems like a chore to me.

Only us really crazy types

Enjoy the Choice

[klauss]

Do people *really* enjoy travelling around in real time? It just seems like a chore to me.

It's not really that bad if you make proper use of SPEC and NAV-mode.
I though think patrol missions could use a fix - they make you approach planets soo close that getting away from them takes ages. I hate patrol missions for that. Besides... what's the point? Do you actually need to get that close for a simple overall scan? You're not scanning a specific building, you know...

[jackS]

In a single-player experience, having time be continuous isn't necessary, and solutions like the Privateer-style autopilot are quite sensible. However, if one wishes to allow multiple players to interact, having all players experience a similar time progression becomes desireable.

[cracken]

How does the spec drive do it's stuff?

Is it merely a multiplier on your velocity that gets it's value by testing gravitational fields? What i mean here is does it take the normally calculated velocity value and multiply it by the multiplier, or does it affect how the dynamics calculations are done?

If, for instance, a ship turns around 180 degrees, is the time required for the ship to change direction of motion the same as it would be if the ship were not in spec mode?

[klauss]

Is it merely a multiplier on your velocity that gets it's value by testing gravitational fields?

Yes.

What i mean here is does it take the normally calculated velocity value and multiply it by the multiplier?

Yes.

... or does it affect how the dynamics calculations are done?

Doesn't.

If, for instance, a ship turns around 180 degrees, is the time required for the ship to change direction of motion the same as it would be if the ship were not in spec mode?

Yes.


I hope it's not overly succint

[providence2010]

You could implement some sort of trade lane system where you can use spec to a limited capacity outside of trade lanes, and then use autopilot when a trade lane (highlighted on your hud) is in line of site. Then make the AI use trade lanes to get around and all the sudden pirating and conflict become easier to encourage and or commit, and you can make smuggling more interesting by setting up check points for the authorities along the trade routes. Then make a speed limit in those zones so you don't run into anyone.

This shouldn't be too hard to implement should it? I think it would make the game more interesting too.