Two autopilots

Development directions, tasks, and features being actively implemented or pursued by the development team.

Two autopilots

Postby breese » Sun Jan 30, 2011 5:31 am

There are two different implementations of the autopilot code.

Orders::AutoLongHaul (bound to "ASAP" in vegastrike.config) is the one currently used.

GameCockpit::Autopilot (bound to "AutoKey" in vegastrike.config) is not used by VS.

I would like to remove the latter if it is dead code. Can I remove it and redirect the "AutoKey" command to the same implementation as the "ASAP" command?

PS: Strictly speaking there are three implementations, as there is also one in Cockpit::Autopilot. This will also be removed if we remove GameCockpit::Autopilot.
breese
Bounty Hunter
Bounty Hunter
 
Posts: 152
Topics: 14
Joined: Thu Sep 02, 2010 1:00 pm

Share On:

Share on Facebook Facebook Share on Twitter Twitter Share on Digg Digg

Re: Two autopilots

Postby charlieg » Sun Jan 30, 2011 7:02 am

Hi breeze, you do know you have commit privileges now, yeah? And that one of your patches got the OK on codestriker by klauss.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
User avatar
charlieg
Elite Mercenary
Elite Mercenary
 
Posts: 1328
Topics: 56
Joined: Thu Mar 27, 2003 4:51 pm
Location: Manchester, UK

Re: Two autopilots

Postby charlieg » Sun Jan 30, 2011 7:03 am

Do you fully understand the differences between the implementations?
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
User avatar
charlieg
Elite Mercenary
Elite Mercenary
 
Posts: 1328
Topics: 56
Joined: Thu Mar 27, 2003 4:51 pm
Location: Manchester, UK

Re: Two autopilots

Postby klauss » Sun Jan 30, 2011 8:01 pm

I may be way off, but maybe AutoLongHaul is used by AI and GameCockpit's is used by players?

In any case, if there are two "bindings" and one isn't used in VS, it smells like mods to me. There may be a mod that requires the version VS doesn't use.

You should ask the other mods for a clue ;) - that or check them out and take a peek at their .config files.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Re: Two autopilots

Postby breese » Mon Jan 31, 2011 12:11 pm

charlieg wrote:Hi breeze, you do know you have commit privileges now, yeah? And that one of your patches got the OK on codestriker by klauss.

Yes, but I still need to make the last of the agreed changes.
breese
Bounty Hunter
Bounty Hunter
 
Posts: 152
Topics: 14
Joined: Thu Sep 02, 2010 1:00 pm

Re: Two autopilots

Postby breese » Mon Jan 31, 2011 12:50 pm

klauss wrote:I may be way off, but maybe AutoLongHaul is used by AI and GameCockpit's is used by players?

AutoLongHaul is used by the player and the AIs use Unit::AutoPilotTo().

GameCockpit::Autopilot() uses Unit::AutoPilotTo() but also does other stuff like camera panning.

klauss wrote:In any case, if there are two "bindings" and one isn't used in VS, it smells like mods to me. There may be a mod that requires the version VS doesn't use.

That is also my impression. As we do not know if it is still in use, I suggested mapping "AutoKey" onto "ASAP" if we remove GameCockpit::Autopilot().

Admittedly, GameCockpit::Autopilot() has more config settings than AutoLongHaul, so the auto piloting behavior of the mods could be changed. However, if some mods need the old GameCockpit behavior, then we should donate the code to them. It does not make sense that we should maintain code that we not use and cannot test.

If we have to continue to support GameCockpit::Autopilot, then I suggest that we move it out of the cockpit code and into an AI script (like AutoLongHaul), but I would rather not waste time doing this if the code is unused.

charlieg wrote:Do you fully understand the differences between the implementations?

No, but I fully understand which parts of VS invokes the two implementations, and GameCockpit::Autopilot is only invoked by the "AutoKey", which we do not use.
breese
Bounty Hunter
Bounty Hunter
 
Posts: 152
Topics: 14
Joined: Thu Sep 02, 2010 1:00 pm

Re: Two autopilots

Postby Deus Siddis » Mon Jan 31, 2011 2:31 pm

klauss wrote:In any case, if there are two "bindings" and one isn't used in VS, it smells like mods to me. There may be a mod that requires the version VS doesn't use.


Maybe the privateer mods. I remember in privateer remake, there's a key that skips over in system travel time almost instantly. You can use it whenever you are not in combat and have a destination targeted.

So it is for the same purpose as auto spec in VS, but it's a totally different solution and thus would probably require a separate bind.

Ask chuck_starchaser if PU uses it. If not then that only leaves Vega Trek, but I think they used a modified version of VS' spec for their "warp drive".
Deus Siddis
Elite
Elite
 
Posts: 1362
Topics: 13
Joined: Sat Aug 04, 2007 8:42 am

Re: Two autopilots

Postby klauss » Mon Jan 31, 2011 3:54 pm

breese wrote:
klauss wrote:I may be way off, but maybe AutoLongHaul is used by AI and GameCockpit's is used by players?

AutoLongHaul is used by the player and the AIs use Unit::AutoPilotTo().

GameCockpit::Autopilot() uses Unit::AutoPilotTo() but also does other stuff like camera panning.


That's it then, GameCockpit::Autopilot is the privateer-like autopilot, that "teleports" you to some clicks away from your destination and plays a camera panning animation of your ship after doing so.

It's required by privateer-like mods.

breese wrote:However, if some mods need the old GameCockpit behavior, then we should donate the code to them. It does not make sense that we should maintain code that we not use and cannot test.


Mods, atm, are data-only. They're not forks, they're alternative data sets to the same binary.

So the engine has to support all the features required by mods, toggleable by config and/or data elements, like units.csv, systems xml and stuff like that.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Re: Two autopilots

Postby pheonixstorm » Tue Feb 01, 2011 5:35 pm

klauss, do you think code like this should be moved out of the normal VS code and into its own code files such as.. mod_privateer.cpp/h or even into its own folder? That way we don't have to compile in a lot of unused code into the main vs binary. We could probably add check boxes into cmake to tell which mod code to include (if any) and do something along those lines for the windows project files.
Because of YOU Arbiter, MY kids? can't get enough gas. OR NIPPLE! How does that mkae you feeeel? ~ Halo
User avatar
pheonixstorm
Elite
Elite
 
Posts: 1567
Topics: 113
Joined: Mon Jan 25, 2010 7:03 pm

Re: Two autopilots

Postby klauss » Tue Feb 01, 2011 7:28 pm

Ya, that would be cool.

But if we do that we'll also need some kind of continuous integration tool or plan, to make sure we don't let the "extra" code misattended.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Re: Two autopilots

Postby breese » Sat Feb 05, 2011 3:48 am

klauss wrote:But if we do that we'll also need some kind of continuous integration tool or plan, to make sure we don't let the "extra" code misattended.

We already have this problem today. We know that it compiles, but we do not know if it works.
breese
Bounty Hunter
Bounty Hunter
 
Posts: 152
Topics: 14
Joined: Thu Sep 02, 2010 1:00 pm

Re: Two autopilots

Postby charlieg » Sat Feb 05, 2011 6:16 am

Unit tests! The most funnest thing in the world ever!
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
User avatar
charlieg
Elite Mercenary
Elite Mercenary
 
Posts: 1328
Topics: 56
Joined: Thu Mar 27, 2003 4:51 pm
Location: Manchester, UK

Re: Two autopilots

Postby breese » Sat Feb 05, 2011 9:25 am

charlieg wrote:Unit tests!

While I agree that we would be much better off with unit tests, it is easier said than done.

I have tried to write some simple unit tests (using the excellent framework in Boost.Test) for some of our classes, but they have to be refactored extensively to reduce implicit dependencies on other parts of the code. For instance, the StarDate class is an obvious candidate for unit testing, except that it requires a list of factions, which in turn requires an XML file, animations, contraband, and sooner or later you end up depending on everything else.

Even if the code was better structured and had less dependencies, it is not easy to write unit tests for something as complex as an autopilot.

I would really like to have lots of unit tests, but we need to de-spaghettified the code base to a sufficient degree first.
breese
Bounty Hunter
Bounty Hunter
 
Posts: 152
Topics: 14
Joined: Thu Sep 02, 2010 1:00 pm

Re: Two autopilots

Postby klauss » Sat Feb 05, 2011 2:16 pm

It's not only spaghetti code what's the problem.

I wrote tests for the new audio system, but they're not unit tests, and they're not automated.

Sure, they do perform assertion checks and excercise a lot of code, but they also rely on the user actually hearing the audio output and deciding if it's what it should be or not.

There are things that are very difficult to test.

But I'd be in favor of some framework put in place, so when we do write code that can be tested, we can easily write tests for it.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Re: Two autopilots

Postby TBeholder » Sat Mar 26, 2011 7:08 pm

klauss wrote:
breese wrote:However, if some mods need the old GameCockpit behavior, then we should donate the code to them. It does not make sense that we should maintain code that we not use and cannot test.
Mods, atm, are data-only. They're not forks, they're alternative data sets to the same binary.
So the engine has to support all the features required by mods, toggleable by config and/or data elements, like units.csv, systems xml and stuff like that.
It's generally good idea, but it's a mess.
Wouldn't it be more neat if the behaviour of each feature was chosen from a list, by variables? So it would be uniform and most generic outside of one "case" per feature which chooses the specific function to be used.
E.g. for the autopilot, auto pan/unpan and teleport are not somehow inherently tied.

Alternatively, less than time-critical things could be moved into Python code calling proper funcions. Then there would be no need to care about compiling (for each target OS) and somehow interfacing libraries for mods, but we'd have most advantages of this approach.
Like using autopilot. Or different versions of jump drive (waving to EliteStrike).
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
User avatar
TBeholder
Elite Venturer
Elite Venturer
 
Posts: 732
Topics: 38
Joined: Fri Apr 14, 2006 7:40 pm
Location: chthonic safety

Re: Two autopilots

Postby klauss » Sun Mar 27, 2011 12:32 pm

Turbo Beholder wrote:Alternatively, less than time-critical things could be moved into Python code calling proper funcions. Then there would be no need to care about compiling (for each target OS) and somehow interfacing libraries for mods, but we'd have most advantages of this approach.
Like using autopilot. Or different versions of jump drive (waving to EliteStrike).


I would agree on that, but the API for scripting may be lacking at times if you were to implement some features, and though it would be more maintainable, it's still code - modders won't mess around with that code because few will understand it.

So not everything can follow that route.

But I do agree - more should be accomplished by scripting than core engine features, it's a more maintainable way of doing things.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Re: Two autopilots

Postby Deus Siddis » Mon Mar 28, 2011 9:46 am

klauss wrote:it's still code - modders won't mess around with that code because few will understand it.


If the python code was documented a lot more aggressively, then that might no longer be the case.
Deus Siddis
Elite
Elite
 
Posts: 1362
Topics: 13
Joined: Sat Aug 04, 2007 8:42 am

Re: Two autopilots

Postby klauss » Mon Mar 28, 2011 12:16 pm

Deus Siddis wrote:
klauss wrote:it's still code - modders won't mess around with that code because few will understand it.


If the python code was documented a lot more aggressively, then that might no longer be the case.


Don't be so sure. Most modders are artists or gamers with a passion for modding, but code (in whatever form, with whatever how much documentation) will inspire fear.

I've seen it happen.

The closest a modder will get to programming with relative comfort, is designing triggers and rules at a very high level.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
User avatar
klauss
Elite
Elite
 
Posts: 7243
Topics: 55
Joined: Mon Apr 18, 2005 7:40 am
Location: LS87, Buenos Aires, República Argentina

Re: Two autopilots

Postby TBeholder » Sun Apr 03, 2011 12:52 pm

klauss wrote:I would agree on that, but the API for scripting may be lacking at times if you were to implement some features,
While everything hangs around separately - most likely. But if i understand correctly, you consider unification/consolidation of code when possible. Anyway, on early stages it's bound to be less about infinite possibilities and more about moving out of the engine existing less-than-time-critical custom stuff.
klauss wrote: and though it would be more maintainable, it's still code - modders won't mess around with that code because few will understand it.
Maintainable and portable...
klauss wrote: Most modders are artists or gamers with a passion for modding, but code (in whatever form, with whatever how much documentation) will inspire fear.
I've seen it happen.
True, but if the same functionality have to be implemented either way, it's less "code or data?", and more of "code where?". :wink:
IMHO for a modder moving the existing code out shouldn't entail more than a single line like <var name="module_autopilot" value="WC/autopilot"/> in config, which is enough because everything else already is in data/modules/WC/autopilot_client.py and data/modules/WC/autopilot_server.py.
And when one needs something new for a mod... Right now, a modder would have plausible, but less than shiny prospects: to either ask the dev team (and you guys already have a lot of stuff on to-do lists) or find someone willing to do a branch (but then, someone both able and willing is likely to work with dev-team on main anyway). With scripts, it's more like "find someone who writes on Python".
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
User avatar
TBeholder
Elite Venturer
Elite Venturer
 
Posts: 732
Topics: 38
Joined: Fri Apr 14, 2006 7:40 pm
Location: chthonic safety



Return to Engine Development

Who is online

Users browsing this forum: No registered users and 2 guests