New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature] New waypoint AI #995

Merged
merged 2 commits into from May 30, 2016

Conversation

Projects
None yet
5 participants
@AnotherFoxGuy
Member

AnotherFoxGuy commented May 29, 2016

Replaced my waypoint AI with a better working one.
Also removed the AI from the beam class.
I will add some more features in the future.

Here are some videos of the AI in action.
https://www.youtube.com/watch?v=UMio5lhJq-0
https://www.youtube.com/watch?v=ob_f1IUZPxI

@AnotherFoxGuy

This comment has been minimized.

Show comment
Hide comment
@AnotherFoxGuy

AnotherFoxGuy May 30, 2016

Member

@only-a-ptr What do you think about this?

Member

AnotherFoxGuy commented May 30, 2016

@only-a-ptr What do you think about this?

@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr May 30, 2016

Member

Great work, way better concept than the previous Beam::navigateTo().

However, discussion is needed. Up to this point I didn't really think about AI, we have no strategy. So allow me to hijack this PR and clarify a few things:

  • Shall we extend our AngelScript interface or jump straight to Lua? I'd like RoR to be Lua-only in the future. Hopefully there's a consent about this, it was discussed and IIRC agreed, but some time passed already, feel free to discuss. This would mean we'd implment new functionality in Lua and only maintain AngelScript where it's actively used. AFAIK currently AngelScript isn't used much, which I see as a good opportunity for the language switch.
  • How should the AI interface with the vehicle? I like the method AnotherFoxGuy used - simple steering direction + acceleration throttle input. This will become important once we begin implementing Lua-based powertrain.
  • How should AI scripts interface with the core components? The method presented by AnotherFoxGuy is way too inflexible IMO. To be specific: the entire VehicleAI class needs to be written in script, not in C++. I actually like the concept of waypoint-placement API, but the processing itself needs to also happpen in script, not C++. AI is a complex and broad area and we need to be absolutely open and accessible to anyone (possibly new people) who might want to tinker and experiment with AI.
Member

only-a-ptr commented May 30, 2016

Great work, way better concept than the previous Beam::navigateTo().

However, discussion is needed. Up to this point I didn't really think about AI, we have no strategy. So allow me to hijack this PR and clarify a few things:

  • Shall we extend our AngelScript interface or jump straight to Lua? I'd like RoR to be Lua-only in the future. Hopefully there's a consent about this, it was discussed and IIRC agreed, but some time passed already, feel free to discuss. This would mean we'd implment new functionality in Lua and only maintain AngelScript where it's actively used. AFAIK currently AngelScript isn't used much, which I see as a good opportunity for the language switch.
  • How should the AI interface with the vehicle? I like the method AnotherFoxGuy used - simple steering direction + acceleration throttle input. This will become important once we begin implementing Lua-based powertrain.
  • How should AI scripts interface with the core components? The method presented by AnotherFoxGuy is way too inflexible IMO. To be specific: the entire VehicleAI class needs to be written in script, not in C++. I actually like the concept of waypoint-placement API, but the processing itself needs to also happpen in script, not C++. AI is a complex and broad area and we need to be absolutely open and accessible to anyone (possibly new people) who might want to tinker and experiment with AI.
@ulteq

This comment has been minimized.

Show comment
Hide comment
@ulteq

ulteq May 30, 2016

Contributor

I'd like RoR to be Lua-only in the future.

Me too, but I don't see this happening anytime soon.

AFAIK currently AngelScript isn't used much

That seems to me to be an illusion.

Replaced my waypoint AI with a better working one.
Also removed the AI from the beam class.

I understand this pull request as a drop-in replacement for the current system, nothing more and nothing less.

I would just merge it - while it has no merge conflicts - and move the discussion into the Issues section.

Contributor

ulteq commented May 30, 2016

I'd like RoR to be Lua-only in the future.

Me too, but I don't see this happening anytime soon.

AFAIK currently AngelScript isn't used much

That seems to me to be an illusion.

Replaced my waypoint AI with a better working one.
Also removed the AI from the beam class.

I understand this pull request as a drop-in replacement for the current system, nothing more and nothing less.

I would just merge it - while it has no merge conflicts - and move the discussion into the Issues section.

@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr May 30, 2016

Member

Me too, but I don't see Lua scripting happening anytime soon.

Well, we have 2 options. Either we stick to current infrastructure as AnotherFoxGuy did, or we go "bang! wham!", make a draft of complete scripting API for Lua and then implement it piece-by-piece based on current needs. It could look something like this:

RoR AI subsystem (quick draft)

Architecture

RoR creates a Lua state machine (VM) per every actor (thats's any rigged object, be it a vehicle or a wooden box). This VM is used for drivetrain scripts, machinery simulation or - AI!

Upon vehicle spawn, scripts can be loaded by this VM. These can be attached to the vehicle or supplied by player. Each of these scripts gets it's own global environment (http://leafo.net/guides/setfenv-in-lua52-and-above.html) and can register functions/objects to be invoked on specific events.

Script API

All RoR API is under namespace RoR.

API relating to the script's hosting Actor is under RoR.ThisActor. If this object is unavailable, you're not in an actor.

  • RoR.ThisActor.on_physics_frame_started(handler) - register handler.
  • RoR.ThisActor.on_physics_frame_ended(handler) - register handler.

Example (pseudocode)

-- File: my_awesome_AI.lua

local ai_context = {
   foo = 1,
   bar = "abc"
}

function ai_frame_started()
   ai_context.foo = ai_context.foo + 1
end

function ai_frame_ended()
   ai_context.bar = ai_context_bar .. "d"
end

RoR.ThisActor.on_physics_frame_started(ai_frame_started)
RoR.ThisActor.on_physics_frame_ended(ai_frame_ended)
Member

only-a-ptr commented May 30, 2016

Me too, but I don't see Lua scripting happening anytime soon.

Well, we have 2 options. Either we stick to current infrastructure as AnotherFoxGuy did, or we go "bang! wham!", make a draft of complete scripting API for Lua and then implement it piece-by-piece based on current needs. It could look something like this:

RoR AI subsystem (quick draft)

Architecture

RoR creates a Lua state machine (VM) per every actor (thats's any rigged object, be it a vehicle or a wooden box). This VM is used for drivetrain scripts, machinery simulation or - AI!

Upon vehicle spawn, scripts can be loaded by this VM. These can be attached to the vehicle or supplied by player. Each of these scripts gets it's own global environment (http://leafo.net/guides/setfenv-in-lua52-and-above.html) and can register functions/objects to be invoked on specific events.

Script API

All RoR API is under namespace RoR.

API relating to the script's hosting Actor is under RoR.ThisActor. If this object is unavailable, you're not in an actor.

  • RoR.ThisActor.on_physics_frame_started(handler) - register handler.
  • RoR.ThisActor.on_physics_frame_ended(handler) - register handler.

Example (pseudocode)

-- File: my_awesome_AI.lua

local ai_context = {
   foo = 1,
   bar = "abc"
}

function ai_frame_started()
   ai_context.foo = ai_context.foo + 1
end

function ai_frame_ended()
   ai_context.bar = ai_context_bar .. "d"
end

RoR.ThisActor.on_physics_frame_started(ai_frame_started)
RoR.ThisActor.on_physics_frame_ended(ai_frame_ended)
@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr May 30, 2016

Member

I would just merge it - while it has no merge conflicts - and move the discussion into the Issues section.

The problem is, merging or not merging this particular PR decides the future of the evolution. Currently, our AI consists of AngelScript Beam::navigateTo() which isn't particularly useful. The API AnotherFoxGuy implemented is actually very good and useful, so if we merge it, we'll have no future choice but to continue supporting and extending it. Of course, we can always drop any feature, but IMO introducing new features and then obsoleting them is actually worse than not introducing them in the first place.

AnotherFoxGuy's AI is very nice, but it's just a closed prototype without further extensibility and sufficient flexibility. If we merge it, our players will start using it and demand it to stay supported, even if we come up with something better. I hate this scenario.

Member

only-a-ptr commented May 30, 2016

I would just merge it - while it has no merge conflicts - and move the discussion into the Issues section.

The problem is, merging or not merging this particular PR decides the future of the evolution. Currently, our AI consists of AngelScript Beam::navigateTo() which isn't particularly useful. The API AnotherFoxGuy implemented is actually very good and useful, so if we merge it, we'll have no future choice but to continue supporting and extending it. Of course, we can always drop any feature, but IMO introducing new features and then obsoleting them is actually worse than not introducing them in the first place.

AnotherFoxGuy's AI is very nice, but it's just a closed prototype without further extensibility and sufficient flexibility. If we merge it, our players will start using it and demand it to stay supported, even if we come up with something better. I hate this scenario.

@mikadou

This comment has been minimized.

Show comment
Hide comment
@mikadou

mikadou May 30, 2016

Contributor

@AnotherFoxGuy Nice work. 👍 for further reducing weight of the Beam class! Btw, this reminds me of TORCS, another open source game which is also used for AI competitions.

Shall we extend our AngelScript interface or jump straight to Lua? I'd like RoR to be Lua-only in the future.

Wouldn't it be more desirable to provide a general scripting interface in the first place? It would make sense for me to start by extracting an abstract interface from the current Angelscript scripting implementation. Adding an additional Lua scripting backend could be done afterwards. In principal, we can also get support for ChaiScript or Runtime C++.

Contributor

mikadou commented May 30, 2016

@AnotherFoxGuy Nice work. 👍 for further reducing weight of the Beam class! Btw, this reminds me of TORCS, another open source game which is also used for AI competitions.

Shall we extend our AngelScript interface or jump straight to Lua? I'd like RoR to be Lua-only in the future.

Wouldn't it be more desirable to provide a general scripting interface in the first place? It would make sense for me to start by extracting an abstract interface from the current Angelscript scripting implementation. Adding an additional Lua scripting backend could be done afterwards. In principal, we can also get support for ChaiScript or Runtime C++.

@mikadou

This comment has been minimized.

Show comment
Hide comment
@mikadou

mikadou May 30, 2016

Contributor

If we merge it, our players will start using it and demand it to stay supported, even if we come up with something better. I hate this scenario.

I do understand this. On the other hand, I also agree with @ulteq on just merging this. It's a first step in the right direction, even if the scripting interface will need to be reworked/broken in the near future. So far it's not an official feature in an official release.

Contributor

mikadou commented May 30, 2016

If we merge it, our players will start using it and demand it to stay supported, even if we come up with something better. I hate this scenario.

I do understand this. On the other hand, I also agree with @ulteq on just merging this. It's a first step in the right direction, even if the scripting interface will need to be reworked/broken in the near future. So far it's not an official feature in an official release.

@@ -315,4 +315,6 @@ struct rig_t
std::vector<std::pair<Ogre::String, bool> > dashBoardLayouts;
Ogre::String beamHash; //!< Unused
VehicleAI *vehicle_ai;

This comment has been minimized.

@mikadou

mikadou May 30, 2016

Contributor

Better: std::unique_ptr

@mikadou

mikadou May 30, 2016

Contributor

Better: std::unique_ptr

@ulteq

This comment has been minimized.

Show comment
Hide comment
@ulteq

ulteq May 30, 2016

Contributor

So far it's not an official feature in an official release.

Exactly. And I think we should also allow experimental features in official releases.

Contributor

ulteq commented May 30, 2016

So far it's not an official feature in an official release.

Exactly. And I think we should also allow experimental features in official releases.

@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr May 30, 2016

Member

Ehh, okay then, let's go with it 👍
Just add it to the AngelScript doxy, pls.

Member

only-a-ptr commented May 30, 2016

Ehh, okay then, let's go with it 👍
Just add it to the AngelScript doxy, pls.

@mikadou

This comment has been minimized.

Show comment
Hide comment
@mikadou

mikadou May 30, 2016

Contributor

@only-a-ptr Just an idea which might make you feel more easy on this. We could use a preprocessor define which is only set for official releases. I.e. experimental code can be tested in nightly builds etc, but isn't part of official releases. This would solve the problem of players starting to rely on non-stable features.

Contributor

mikadou commented May 30, 2016

@only-a-ptr Just an idea which might make you feel more easy on this. We could use a preprocessor define which is only set for official releases. I.e. experimental code can be tested in nightly builds etc, but isn't part of official releases. This would solve the problem of players starting to rely on non-stable features.

@only-a-ptr

This comment has been minimized.

Show comment
Hide comment
@only-a-ptr

only-a-ptr May 30, 2016

Member

We could use a preprocessor define which is only set for official releases. I.e. experimental code can be tested in nightly builds etc,

Eh, what? I thought we're working with Git... what are branches for?

Further, the idea of nightlies differing from future stables is outright scary. A common issue of opensource projects is devs endlessly experimenting and never releasing. What you're suggesting is exactly this kind of trap.

Finally, experimental code should really stay in it's author's repo. Upstream means up-stream. The author can just as well publish builds from his machine, possibly as just a replacement .EXE to use with nightlies (isn't it mostly just a few altered sources?) or let people clone and build his repo, or just collaborate around his repo. Isn't that what Git is all about? My fork of RoR hosts experiments 2-10x the size of this PR.

As I said, this AI patch is really nice, clean and actually useful, except it's a dead end. It's a hardcoded mechanism, similar to our BeamEngine - usable, but limited, bound to cause endless complaints from advanced modders. The waypoint API concept is nice, but it would have to be implemented completely in AS to be extensible.

But I'm OK with getting this merged. It's so much better than what was there before.

Member

only-a-ptr commented May 30, 2016

We could use a preprocessor define which is only set for official releases. I.e. experimental code can be tested in nightly builds etc,

Eh, what? I thought we're working with Git... what are branches for?

Further, the idea of nightlies differing from future stables is outright scary. A common issue of opensource projects is devs endlessly experimenting and never releasing. What you're suggesting is exactly this kind of trap.

Finally, experimental code should really stay in it's author's repo. Upstream means up-stream. The author can just as well publish builds from his machine, possibly as just a replacement .EXE to use with nightlies (isn't it mostly just a few altered sources?) or let people clone and build his repo, or just collaborate around his repo. Isn't that what Git is all about? My fork of RoR hosts experiments 2-10x the size of this PR.

As I said, this AI patch is really nice, clean and actually useful, except it's a dead end. It's a hardcoded mechanism, similar to our BeamEngine - usable, but limited, bound to cause endless complaints from advanced modders. The waypoint API concept is nice, but it would have to be implemented completely in AS to be extensible.

But I'm OK with getting this merged. It's so much better than what was there before.

@ulteq

This comment has been minimized.

Show comment
Hide comment
@ulteq

ulteq May 30, 2016

Contributor

A common issue of opensource projects is devs endlessly experimenting and never releasing.

When did we do the last stable release? 😊

But I'm OK with getting this merged. It's so much better than what was there before.

Ok, let's not waste more time and just merge it.

Contributor

ulteq commented May 30, 2016

A common issue of opensource projects is devs endlessly experimenting and never releasing.

When did we do the last stable release? 😊

But I'm OK with getting this merged. It's so much better than what was there before.

Ok, let's not waste more time and just merge it.

@ulteq ulteq merged commit fed296e into RigsOfRods:master May 30, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@AnotherFoxGuy AnotherFoxGuy deleted the AnotherFoxGuy:New-AI branch Jun 5, 2016

@Michael10055

This comment has been minimized.

Show comment
Hide comment
@Michael10055

Michael10055 Jun 24, 2016

Contributor

@AnotherFoxGuy Could you please upload a example map of the AI working like you did with your older AI?
Edit: Example uploaded in the pull request listed below.

Contributor

Michael10055 commented Jun 24, 2016

@AnotherFoxGuy Could you please upload a example map of the AI working like you did with your older AI?
Edit: Example uploaded in the pull request listed below.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment