Idea: Create a RPC API (or other IPC) to allow mods in JS, Rust, etc.

icetbr

Chieftain
Joined
Jul 15, 2006
Messages
17
Think of all the UI rewritten in JS. The AI rewritten in Rust, C++20 or Zig. All running in a separate process, making better use of multiple cores.

This might encourage people who work with those languages to create more mods. Developers learning a new language could practice writing useful code, instead of another Todo application. The use of modern C++ brings new features and allows the use of many libraries that use modern C++ as well.

This could lead to a multi project oriented development. Teams dedicated to different components. Bonus points if we could create common components for Unciv as well.

If anyone figures it out how to use the FireTuner protocol, that would work as well.

RPC call overhead should be close to zero for most cases as far as I know. Latency of UI as well.

PS: This relates to the Roadmap/Vision Brainstorming. I tough I would make a new thread because crazy ideas deserve crazy visibility.
 
Yes. I tried some ideas before but couldn't get it to work. I'm not a C++ coder, maybe someone here can do much better then me.

Eventually I'll give this another go.
 
As far as I'm aware, this isn't possible without rewriting the entire game engine, because of the way it loads mods. Could also run into issues with compiling and linking the DLL.
 
Basically it would just need to duplicate every CvLua***.cpp and adapt them to handle the chosen data format. I open a TCP port and send messages.

Compiling/linking would just be an issue if I tried to use modern libs, right? That's why I couldn't get a quick solution. I had to get some older tutorials/libs just for this.

FireTurner works by evaluating lua code "on the fly" I think. A solution like this wouldn't need to duplicate any files, and it would allow interacting with Civ's native graphical controls.
 
Well, if you can prove that this works (even on a small scale), I'll add it to the roadmap as a possibility. Probably not high priority, though.
 
Of course, thank you. I'll be here hearing for ideas until I get to finish a POC.
 
Lua calls are really slow though. I'm not sure about the performance of getting entire game states.
 
Lua calls are really slow though. I'm not sure about the performance of getting entire game states.
If we could pack and stream the game states in binaries and send them out in 1 call, is it going to be better? I have done similar things on other projects before.
 
I'm not sure. I'd have to learn about threads in C++, or else I'd already tried that.

This is where it hangs:

This line `RCF::RcfInitDeinit rcfInit;` eventually arrives at

/RCF-2.2.0.0/src/RCF/AmiThreadPool.cpp:346
Code:
AmiThreadPool::AmiThreadPool() : mThreadPool(1)
    {
        mThreadPool.setThreadName("RCF AMI");
        mThreadPool.enableMuxerType(Mt_Asio); <<<<<< THIS LINE
    }

I couldn't understand what that does, and why it would hang. It didn't "feel" like it needed a new thread, and I was eager to try another lib, so I gave up this version.

Would it be simple to "thread" that constructor? Actually the whole block then

Code:
RCF::RcfInitDeinit rcfInit;
RCF::RcfServer server(RCF::TcpEndpoint(50001));

HelloWorldImpl helloWorld;
server.bind<I_HelloWorld>(helloWorld);
server.start();

Since I couldn't get boost Asio to work, because it needs at least VS2010, I'll get back to try RCF then.
 
1st step done, I can make RPC calls.


I can call
C++:
CUSTOMLOG("XXX %d", GC.getNumTechInfos());

Now I need to make something more interesting, using game state.

I was going to try an adapter for BasicLuaMethod, so then I could reuse all Lua calls without adding much code. But we don't have the source code for that I guess.

Progress is slow because I'm poking this between gameplays, which takes many days.

EDIT

Nvm, BasicLuaMethod is a template, I would only need to make a converter for lua_State. I'm not sure this is the way, but it could make things very easy.
 
Last edited:
Back
Top Bottom