New Ai Ideas

Forum closed. All further discussion to be discussed at https://github.com/OpenKore/

Moderator: Moderators

Message
Author
Technology
Super Moderators
Super Moderators
Posts: 801
Joined: 06 May 2008, 12:47
Noob?: No

Re: New Ai Ideas

#21 Post by Technology »

This is not exactly about AI, but since you were mentioning Xkore.
Here is an interresting topic:
http://bibian.ath.cx/openkore/viewtopic ... sc&start=0

Especially for xkore 2 and proxy its getting really hard to support different serverTypes since they interfere with eachother.
While fixing something for one serverType you must really be carefull not to break another one.
What about moving serverType specific stuff to for example:
Network::Send::ServerTypeX
Or maybe even creating new modules for this?
(so that while using Network::DirectConnection you won't have to load any of the xkore 1, 2, 3 modules)
Anyhow, we should think of better ways to implement the xkore's.
One ST0 to rule them all? One PE viewer to find them!
One ST_kRO to bring them all and in the darkness bind them...

Mount Doom awaits us, fellowship of OpenKore!

User avatar
kLabMouse
Administrator
Administrator
Posts: 1301
Joined: 24 Apr 2008, 12:02

Re: New Ai Ideas

#22 Post by kLabMouse »

Technology wrote:This is not exactly about AI, but since you were mentioning Xkore.
Here is an interresting topic:
http://bibian.ath.cx/openkore/viewtopic ... sc&start=0

Especially for xkore 2 and proxy its getting really hard to support different serverTypes since they interfere with eachother.
While fixing something for one serverType you must really be carefull not to break another one.
What about moving serverType specific stuff to for example:
Network::Send::ServerTypeX
Or maybe even creating new modules for this?
(so that while using Network::DirectConnection you won't have to load any of the xkore 1, 2, 3 modules)
Anyhow, we should think of better ways to implement the xkore's.
OK. I'll Explain.
What I want, is loose any Direct Calls to AI form Other Modules, and Loose All Calls to Network from Other Modules, except for Action Modules, witch purpose is to make any kind of Actions and Calculations that Other Modules need to do.

User avatar
kLabMouse
Administrator
Administrator
Posts: 1301
Joined: 24 Apr 2008, 12:02

Re: New Ai Ideas

#23 Post by kLabMouse »

Threading Model:
Kore -- (The main Thread that will wait for other Threads to finish)
|-Interface (non blocking Thread; used to make OpenKore Interactive Interface. Location: Interface)
|-KoreStage (blocking Thread, end when done; used to prepare all the settings. Location: KoreStage)
| |-StageLoadPlugins (non Thread; used to load Plugins. Location: KoreStage::StageLoadPlugins)
| |-StageLoadDataFiles (non Thread; used to load all Data Files including Configs. Location: KoreStage::StageLoadDataFiles)
| |-StageInitPortalsDatabase (non Thread; used to load and prepare Portals Database. Location: KoreStage::StageInitPortalsDatabase).
|-AI (non blocking Multi Thread; used for Logic and callings to AI::ModuleMgr. Location: AI)
| |- AI Modules Mgr (non Thread; used for Loading AI Modules and asking them. Location: AI::ModuleMgr)
| | |-AI Modules (non Thread; used to make some decisions, used by Tasks as Helpres. Location: AI::Module::* )
| |- Environment Que Dispatcher (non blocking Sub Thread; used to make changes on Global Environment Variables based on Que. Location: AI::EnvironmentQueDispatch )
|-Network (non blocking Thread; used to add Networking Support, PUSH variables to Environment Que. Location: Network )

Motivus
Developers
Developers
Posts: 157
Joined: 04 Apr 2008, 13:33
Noob?: Yes

Re: New Ai Ideas

#24 Post by Motivus »

The solution to the xkore problem is to create a single "network handler" that kore calls no matter what. It needs standard functions like Load, send, recv, socket crap, and access to a callback function to handle client->server packets from external sources. When direct connection mode is in effect the send/recv/etc functions directly map to the real ones, and because there is no client module loaded the function to handle external client->server packets is never called. When a specific network mode is enabled the send/recv/etc functions map to that plugin, and that plugin calls the client->server function when its client attempts to send a packet. That way Kore is always acting the same way, but the handler is able to mediate what is going on.

Configuration wise it adds a single option that we don't even have to make available to the public, we could just allow the external client "plugin" to define this option when it is loaded.

Option 0: External clients handle all connection/sync packets and kore only activates ai in the appropriate situation
Option 1: Kore generates all connection/sync packets and blocks the client's attempts

Edit: It fits right in with klab's Network. This idea needs some work, I am really sick and probably messed it up pretty badly. The basic idea is that Kore should have no idea if it is using a direction connection or an xkore mode, and that the normal packet generation code should have no idea either. This new function exists to moderate if kore or the client's packets are used, and as a result should fix a lot of compatability issues as well as encourage many different external interfaces because they only need to be updated in a single file.
Technology wrote:Especially for xkore 2 and proxy its getting really hard to support different serverTypes since they interfere with eachother.
The reason there are so many issues is because XKore is just tacked on. It was implemented in a way that only cleanly supports one mode, but as we all know there are multiple XKore modes now. On top of that it's a pretty big mess how Kore and XKore interact, and it's something that needs to be changed if we are rewriting things.
Oh no.

sli
Perl Monk
Perl Monk
Posts: 810
Joined: 04 Apr 2008, 17:26
Noob?: No

Re: New Ai Ideas

#25 Post by sli »

Motivus wrote:The solution to the xkore problem is to create a single "network handler" that kore calls no matter what.
How the fuck long ago did I say this and it's only now coming back up? :|
cs : ee : realist

kali
OpenKore Monk
OpenKore Monk
Posts: 457
Joined: 04 Apr 2008, 10:10

Re: New Ai Ideas

#26 Post by kali »

Most probably nobody understood exactly what you were saying back then, and Motivus just now clearly explained the idea.

That, or nobody really took you seriously :)
Got your topic trashed by a mod?

Trashing topics is one click, and moving a topic to its proper forum is a lot harder. You expend the least effort in deciding where to post, mods expend the least effort by trashing.

Have a nice day.

Motivus
Developers
Developers
Posts: 157
Joined: 04 Apr 2008, 13:33
Noob?: Yes

Re: New Ai Ideas

#27 Post by Motivus »

kali wrote:Most probably nobody understood exactly what you were saying back then, and Motivus just now clearly explained the idea.

That, or nobody really took you seriously :)
I've mentioned it in the past as well, although it was never seriously proposed. There's also some things not clear about the implementation I talked about, and anyone can hammer out the details if they like.
Oh no.

sli
Perl Monk
Perl Monk
Posts: 810
Joined: 04 Apr 2008, 17:26
Noob?: No

Re: New Ai Ideas

#28 Post by sli »

kali wrote:Most probably nobody understood exactly what you were saying back then, and Motivus just now clearly explained the idea.

That, or nobody really took you seriously :)
I think the very first time I said it my exact words were "why the fuck does XKore have network code?" No one could ever give me a straight answer as to why there was network handling in XKore leading me to believe that either everyone else wondered the same thing, no one else noticed it, or no one had a good excuse for such a shoddy programming technique.
cs : ee : realist

User avatar
kLabMouse
Administrator
Administrator
Posts: 1301
Joined: 24 Apr 2008, 12:02

Re: New Ai Ideas

#29 Post by kLabMouse »

Motivus wrote:The solution to the xkore problem is to create a single "network handler" that kore calls no matter what.
OK. I agree too.
But we need to work out some things.
Let's see: Current dev Version of "AI 2008" is Multi Threaded now. Every thread can do whatever he wants.
Limitation: Network do only Network Stuff, it don't access any of "Environment" variables or "AI" or anything else, just some global variables (don't forget, NO DEAD LOCKS).
Q: So you ask. How the Hell "Kore" itself should should know what's happening????
A: Kore uses Que messages to communicate with each "Big" module.
For Example: Actor moved, Network push a variable to "AI Environment Que" about actor and it's changes, "AI Environment Que" pop that message, and handle it properly.
Back to Networking!
Basic Networking, is to communicate Directly with Server.
xKore (1), it's a Basic Networking, with Enabled Client Packet Parsers.
xKore (2); xKore (proxy), Basic Networking, with Enabled Client Packet Parser, and Server like packet sender.
All of these, should use the same like system, as current Send Recive works.
You can use another additional Thread in xKore (2) and xKore (proxy), just don't forget to handle "$quit" properly, and call "yeald()" after every iteration.

User avatar
kLabMouse
Administrator
Administrator
Posts: 1301
Joined: 24 Apr 2008, 12:02

Re: New Ai Ideas

#30 Post by kLabMouse »

Added a Draft and TechSheme for new SQLLite based Tables.
http://forums.openkore.com/viewtopic.php?f=38&t=3172

Locked