Two autopilots
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Two autopilots
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.
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.
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
Re: Two autopilots
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
FreeGameDev forum - open source game development community
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
Re: Two autopilots
Do you fully understand the differences between the implementations?
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
FreeGameDev forum - open source game development community
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Two autopilots
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.
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.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Two autopilots
Yes, but I still need to make the last of the agreed changes.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.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Two autopilots
AutoLongHaul is used by the player and the AIs use Unit::AutoPilotTo().klauss wrote:I may be way off, but maybe AutoLongHaul is used by AI and GameCockpit's is used by players?
GameCockpit::Autopilot() uses Unit::AutoPilotTo() but also does other stuff like camera panning.
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().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.
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.
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.charlieg wrote:Do you fully understand the differences between the implementations?
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: Two autopilots
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.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.
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".
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Two autopilots
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.breese wrote:AutoLongHaul is used by the player and the AIs use Unit::AutoPilotTo().klauss wrote:I may be way off, but maybe AutoLongHaul is used by AI and GameCockpit's is used by players?
GameCockpit::Autopilot() uses Unit::AutoPilotTo() but also does other stuff like camera panning.
It's required by privateer-like mods.
Mods, atm, are data-only. They're not forks, they're alternative data sets to the same binary.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.
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.
-
- Elite
- Posts: 1567
- Joined: Tue Jan 26, 2010 2:03 am
Re: Two autopilots
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
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Two autopilots
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.
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.
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Two autopilots
We already have this problem today. We know that it compiles, but we do not know if it works.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.
-
- Elite Mercenary
- Posts: 1329
- Joined: Thu Mar 27, 2003 11:51 pm
- Location: Manchester, UK
- Contact:
Re: Two autopilots
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
FreeGameDev forum - open source game development community
-
- Bounty Hunter
- Posts: 152
- Joined: Thu Sep 02, 2010 8:00 pm
Re: Two autopilots
While I agree that we would be much better off with unit tests, it is easier said than done.charlieg wrote:Unit tests!
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.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Two autopilots
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.
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.
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: Two autopilots
It's generally good idea, but it's a mess.klauss wrote:Mods, atm, are data-only. They're not forks, they're alternative data sets to the same binary.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.
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.
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
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Two autopilots
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.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).
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.
-
- Elite
- Posts: 1363
- Joined: Sat Aug 04, 2007 3:42 pm
Re: Two autopilots
If the python code was documented a lot more aggressively, then that might no longer be the case.klauss wrote: it's still code - modders won't mess around with that code because few will understand it.
-
- Elite
- Posts: 7243
- Joined: Mon Apr 18, 2005 2:40 pm
- Location: LS87, Buenos Aires, República Argentina
Re: Two autopilots
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.Deus Siddis wrote:If the python code was documented a lot more aggressively, then that might no longer be the case.klauss wrote: it's still code - modders won't mess around with that code because few will understand it.
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.
-
- Elite Venturer
- Posts: 753
- Joined: Sat Apr 15, 2006 2:40 am
- Location: chthonic safety
Re: Two autopilots
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:I would agree on that, but the API for scripting may be lacking at times if you were to implement some features,
Maintainable and portable...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.
True, but if the same functionality have to be implemented either way, it's less "code or data?", and more of "code where?".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.
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