Heeding my own advice, I am creating this thread to allow us to discuss/plan a custom diplo screen mod component that would replace the unmoddable Firaxis diplo screen hidden away in the EXE, before we take over the Modding Questions thread.
Here's the discussion that led to this point:
Besides solving the technical problems (which sounds more feasible than I thought now that I've read Nightinggale's and Platyping's posts), we should also come up with a plan what to use our newfound power for once we have it. While it is much easier to mod the diplo screen once it has been uncoupled from the EXE, providing the most important information already would help the community get the most out of it right from the start.
I need to do some catching up on how all of this is wired together before I could say anything substantial, but wanted to open the discussion already regardless.
Here's the discussion that led to this point:
Spoiler :
Does anyone know where the Diplomacy screen is defined?
@ DH: in the exe![]()
This is something, which annoys me quite a lot. It severely limits what you can do to diplomacy. Perhaps the most annoying part is that it isn't bug free (at least in colonization) and being in the exe, bugfixing is not really something we can do. The bug is that under certain conditions, the AI will offer peace, but the request to open the diplomacy window to offer peace vanishes in the exe. Sending the request will make it fetch all sorts of needed data to make the window (leader head and stuff), but then nothing and it just carries on. Setting the two teams to peace and then request the window will make it open, indicating that the bug is a toggled bool check. Why is that check even in the exe?
I was so upset with it at some point that I considered rewriting the diplomacy window from scratch. However I haven't even started doing that and I'm no longer sure that I will. It seems like a big task
The concept is to set up UI in python. There are some parts in the DLL. They are (mainly?) popup windows with buttons and pedia string generation. My guess is that opening a new window would be ugly in python compared to the relatively clean C++ code. The pedia requires lots of data access, which may or may not be available to python. Also C++ is significantly faster than python, meaning CPU heavy UI elements could make the game lag in python, particularly on minimum system requirements computers.
As for why some screens are in the exe? Who knows? Maybe they have such brilliant code that they wanted to keep it a secret. Or maybe they just didn't consider modder access to screens like that. I think the main issue here is that the exe<->dll interface was not planned as a clean interface from the start. I have encountered a number of features where I think "those doesn't belong in the exe", yet they are still there. For instance GameFont ID setup for yields. It's in the DLL in BTS (good), but in the exe in colonization (quite bad as colonization is the one, which needs this to be modded). The exe sets up all the ids at startup, then check if they are what it set them to be and crashes if they are wrong. After that, the modder can set them to whatever he wants as the exe will no longer need the yield GameFont IDs. It just seems to be a silly limitation, which serves no real purpose.
If possible, that would be great. I definitely also share some of your frustrations with it.
That post makes me think. We share a problem and none of us has the solution. However maybe some of us has part of the solution and together we have the complete solution.
There are the following steps:
My abilities for these tasks:
- catch the diplo event before it enters the exe.
- open a python window
- draw the python window based on diplo event data
- python code to get which option the player clicked on and send it to the dll
- dll reading the answer and do the requested action (transmit on network if needed)
My biggest problem is python UI. If I can find somebody to do that, this could very well be done. I have experience in fixing network desyncs and know what it takes to make features work in networked multiplayer. I have made new classes in C++ and then added python interface to them, meaning variable communication between the diplo event and the python window would likely be a new class with a bunch of get/set functions. I have experimented with making C++ code where the code is in new files, meaning adding them to other mods is little more than copying in the cpp/h files.
- already done it (for a different purpose)
- should be doable, though I need research to figure out how
- my biggest issue. No idea how to do this. The leaderhead might be the biggest issue.
- might be able to figure this one out
- fully confident that I can handle this one
In short, I have a decent idea on what to do to make a replacement window. I just can't make the actual UI itself. Also my current top priority is M:C. There are some people who are stuck modding until I reach a certain milestone and I don't want to keep them idle for longer than I have to. Any other tasks will have to wait.
Are there any python UI skilled people, who could be interested in a joined effort (presumably next year)? I can easily manage a git server to host the source. It should be a modcomp for BTS, but I assume it shouldn't be too difficult to make something, which works for any civ4, including colonization.
2) This is easy. Opening a new screen when a button or command is given can be done via pure python. I done it frequently in my WB, which you can explore for examples. Not at my computer now.
3) Easy as well, perfect sample in pedia.
4) Doable too, although for this case, you should need modnetmessaging to send to all
I'm very interested in this and would like to help where I can. I think my skill set is closer to Nightinggale's (DLL stuff and backend logic), but I'm sure there's something to contribute. I'm less experienced with drawing (good looking) UIs but I'm sure I have something to add there as well.
Maybe there should be some extra brainstorming before we start (I think we're all blocked by other plans for the time being anyway, so let's talk at least). For instance, if we know what information to display in the screen (I'd love optional AI trade values for debug purposes) we can better plan what to expose from the DLL.
Besides solving the technical problems (which sounds more feasible than I thought now that I've read Nightinggale's and Platyping's posts), we should also come up with a plan what to use our newfound power for once we have it. While it is much easier to mod the diplo screen once it has been uncoupled from the EXE, providing the most important information already would help the community get the most out of it right from the start.
I need to do some catching up on how all of this is wired together before I could say anything substantial, but wanted to open the discussion already regardless.