The first post for this topic has been updated to show which items have been completed vs which are still outstanding.
I reordered the change log to be newest changes at top of file. I also added a 1st draft of Known Bugs to the top of the Changelog. See below for what I wrote. These were all I could think of off the top of my head. If anyone else can think of other bugs to add, please post them/add them yourself.
I'm open to changing the format of the bugs. Less information, different format for list, etc. Also Fractured Alliance isn't in Outpost 2 yet, but since I plan on adding it, I went ahead and listed the bug.
Outpost 2 Changelog & Known Bugs
--------------------------------
Known Bugs
----------
* Menus on title screen occasionally do not appear
- only a single horizontal red line appears at top of menu with rest of menu nonexistent.
- Menu is still clickable even though it isn't being drawn.
- Typically clicking until managing to open a different menu will restore proper behavior.
* Starting building construction without committing the ConVec or structure kit
- If interrupting the ConVec on the exact right frame, the building will start construction without tying up the ConVec. The structure kit will remain in the ConVec.
* Scenario: 4P, SRV, Forsaken World
- Some starting colonies begin with buildings intermingled with what should be impassible terrain. One colony cannot access its starting ore deposit.
* Scenario: Plymouth Cold War
- Attacking the AI base often creates a crashing bug soon after initial engagement.
* Scenario: 5P, SRV, Fractured Alliance
- Occasionally the scenario will crash on initial load.
Changelog
---------
1.3.7
. . . MORE TEXT . . .
[/tt]
Err, no. It's set in stone now.
Subversion doesn't allow rewriting history.
Interesting. There is an easy to find button in TotoiseSVN for editing previous commit messages. Since actually changing the commits is so difficult, I wouldn't have expected them to expose the functionality so nicely in TortoiseSVN.
EDIT
-----------
Using the standard BMP format affects the mapper. The minimap display inside the editor looks a bit weird. Colors are generally correct, but there is some 'darker noise' inside the tiles. Saving the minimap to file via the mapper produces the same results. You can use the mapper otherwise without problem. Bitmap minimaps produced by the mapper are attached to this post for comparison.
New BMP minimap produced by Mapper
(https://forum.outpost2.net/index.php?action=dlattach;topic=6043.0;attach=1054;image)
Old BMP minimap produced by Mapper
(https://forum.outpost2.net/index.php?action=dlattach;topic=6043.0;attach=1056;image)
Now that I think about it, Greenworld tilesets were doing this to me earlier when I was playing with them in the Mapper.
Thoughts?
EDIT 2
I found where in Outpost2.exe the version strings are being set. It was actually really easy using HxD. I just searched for the text 1.3 and found them both immediately.
Offset 0xE1A00 - Sets the OPU Ver within the in game menu preferences section. I modded it to 1.36 locally and it didn't crash and showed the new number. I guess now we need to decide if we want to rip it out or start updating it with version changes. I tend towards removing it, but I don't actually know how to remove it, just edit it...
Offset 0xE7F3C - The beginning of the text 1.3.0.4. I'm betting this is the value for checking multiplayer matches. I haven't tested it out yet. Perhaps I'll find some time to mod one copy of Outpost 2 and then try to run up a multiplayer match and see what happens.
Strangely, 0xE7F3C doesn't match the hex address we are using in SetSerialNumber in op2ext.
char *verStrAddr = (char*)0x004E973C;
Thanks,
Brett
I took a look at the OP2Editor backend code. It contains some functions used to calculate minimap colors. I believe that's where we'd need to look. Curiously they are commented for removal. I can't say I remember why. I'm not even certain who wrote that code.
In CTileSet.cpp on line 712 there is a function:
// **TODO** Remove
void CTileSet::CalcMiniMapColors(int startTile, int endTile)[/tt]
...
case 16: // Assume 5/5/5 for RGB components **TODO** test this code
The comment stands out, particularly given my earlier off by 1 bit assumption, and knowing that many 16-bit bitmaps are actually encoded 5/6/5, not 5/5/5 (Red, Green, Blue). Though this might not be the problem, since the bitmaps you're repacking are 8-bit, not 16-bit, so that block shouldn't be active.
We could add this to our next pair programming session.
Thanks for the tip Hooman.
I used the debugger to step through the detach process for op2ext and found the problem. When op2ext calls the DestroyMod function on NetHelper, it just hangs for a long time. Sometimes it is only maybe 3-5 seconds. Other times it just seems to hang a really long time. After the interval, op2ext finishes closing out and everything is fine.
If I do not add the NetHelper module to Outpost 2, then everything exits correctly.
Looking through NetHelper's code, DestroyMod contains the following line:
WaitForSingleObject(hFwdThread, INFINITE);
I don't know for sure, but I'm wondering if this is what is causing NetHelper to not close out on my computer for a variable long length of time. I'm not really sure what this line does or why it is passed INFINITE for the wait time. Below is the entire DestroyMod function for context, but checking it out in the repo is easy enough.
It is probably incorrect that NetHelper can force Outpost 2 to not close out for such a long time. However, when closing out of version 1.3.6 on my computer, Outpost 2 seems to close just fine. It will transfer from the active applications to a background application for maybe 1-2 seconds at most and then disappear, which seems reasonable behavior. So, I don't know what is different between 1.3.6 and the new version that is causing the hang. Perhaps there is still some underlying problem that I added to op2ext.
extern "C" __declspec(dllexport) bool DestroyMod() {
bool result = true;
if (!SetBindPatches(false)) {
result = false;
}
if (mode != noForward) {
if (!SetGetIPPatch(false)) {
result = false;
}
if (hFwdThread) {
shuttingDown = true;
WaitForSingleObject(hFwdThread, INFINITE);
}
PortForwarder forwarder(mode == pmpOrUpnp || mode == upnpOnly,
mode == pmpOrUpnp || mode == pmpOnly);
for (int i = startPort; i <= endPort; ++i) {
forwarder.Unforward(true, i);
}
}
return result;
}
I tried compiling NetHelper so I could step debug through it and verify that line is called and is the culprit, but I cannot get it to compile. I'm getting a lot of LINKER errors associated with miniupnpcd.lib.
Severity Code Description Project File Line Suppression State
Error LNK2001 unresolved external symbol __imp__fprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(upnpreplyparse.obj) 1
Error LNK2001 unresolved external symbol __imp__fprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(minissdpc.obj) 1
Error LNK2001 unresolved external symbol __imp__fprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(connecthostport.obj) 1
Error LNK2001 unresolved external symbol __imp__fprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(miniwget.obj) 1
Error LNK2001 unresolved external symbol __imp__fprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(portlistingparse.obj) 1
Error LNK2001 unresolved external symbol __imp__printf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(minisoap.obj) 1
Error LNK2001 unresolved external symbol __imp__printf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(miniwget.obj) 1
Error LNK2001 unresolved external symbol __imp__printf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(igd_desc_parse.obj) 1
Error LNK2001 unresolved external symbol __imp__printf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(miniupnpc.obj) 1
Error LNK2001 unresolved external symbol __imp__printf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(receivedata.obj) 1
Error LNK2001 unresolved external symbol __imp__printf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(upnpreplyparse.obj) 1
Error LNK2001 unresolved external symbol __imp__printf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(minissdpc.obj) 1
Error LNK2001 unresolved external symbol __imp__printf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(connecthostport.obj) 1
Error LNK2019 unresolved external symbol __imp__sscanf referenced in function _UPNP_GetStatusInfo NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(upnpcommands.obj) 1
Error LNK2001 unresolved external symbol __imp___snprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(connecthostport.obj) 1
Error LNK2001 unresolved external symbol __imp___snprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(minisoap.obj) 1
Error LNK2001 unresolved external symbol __imp___snprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(miniwget.obj) 1
Error LNK2001 unresolved external symbol __imp___snprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(miniupnpc.obj) 1
Error LNK2001 unresolved external symbol __imp___snprintf NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(minissdpc.obj) 1
Error LNK2001 unresolved external symbol __imp____iob_func NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(upnpreplyparse.obj) 1
Error LNK2001 unresolved external symbol __imp____iob_func NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(minissdpc.obj) 1
Error LNK2001 unresolved external symbol __imp____iob_func NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(connecthostport.obj) 1
Error LNK2001 unresolved external symbol __imp____iob_func NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(miniwget.obj) 1
Error LNK2001 unresolved external symbol __imp____iob_func NetHelper C:\Users\Brett\Documents\OutpostUniverseGitHub\NetHelper\src\miniupnpcd.lib(portlistingparse.obj) 1
I tried playing with adding the folder with the miniupnp header files to the C++ include list and the 2 miniupnp lib files to the linker list, but it didn't seem to matter. Although I find getting these files to register in Visual Studio can be very finicky.
If I had the PDB file for either NetHelper or op2ext that is bundled with Outpost 2 1.3.6, I could step debug and see a little more what is going on.
-Brett
Below is the current Version Info resource script for op2ext.dll as an example.
Plus, extensions are not always updated on the same cycle as the game, so it's questionable to use the game package version for them.
To be clear here, I was just planning to update the product version to 1.3.0.7 and leave the file version whatever version that particular dll/exe was on in its release cycle. So the file version would represent the individual extension's release while the product version would represent its inclusion in the overall Outpost 2 download. Again though, I was just following what I thought was already halfway happening.
If we are wanting to not update the resources each release, what do we think of removing the 2 lines referring to product version from the Resource Script? This way, there would be not question about updating them in the future. Only problem is this would probably affect OllyDbg again on Outpost2.exe. Maybe we just leave Outpost2.exe alone and change the others. I can update the PublishingReadMe to reflect this.
Do we maintain notes on any of the dlls in Outpost 2 for OllyDbg, or is it just Outpost2.exe that we are concerned about?
1 VERSIONINFO
FILEVERSION 2,0,0,0
PRODUCTVERSION 1,3,0,7
FILEOS 0x40004
FILETYPE 0x2
{
BLOCK "StringFileInfo"
{
BLOCK "040904b0"
{
VALUE "CompanyName", "The Outpost Universe"
VALUE "FileDescription", "Extends Outpost 2 with new functionality"
VALUE "FileVersion", "2.0.0.0"
VALUE "InternalName", "op2ext.dll"
VALUE "LegalCopyright", "Copyright (C) 2017"
VALUE "OriginalFilename", "op2ext.dll"
VALUE "ProductName", "Outpost 2"
VALUE "ProductVersion", "1.3.0.7"
}
}
BLOCK "VarFileInfo"
{
VALUE "Translation", 0x0409 0x04B0
}
}
Minor point: To ease debugging with OllyDbg, perhaps upon release we should create a revision with the icon stripped. The change in file size invalidates the OllyDbg comments. The icon can be immediately re-added in a subsequent revision. I currently have a copy of the repo pegged at revision r915, which was the last update to the game download before the icon update in revision r1100.
Yeah, keeping OllyDbg relevant is important. I'm guessing we would need to push the old icon back into the resource in addition to removing the new icon to make sure everything lines up properly. Then make sure it compiles exactly the same way it did on the original file. Also, if I strip the ProductVersion from Outpost2.exe, I'm guessing this would cause the same problem as changing the icon did.
Is there an alternate solution that would allow us to account for embedded resource changes when loading OllyDbg?
Hooman, if you are comfortable with it, I will just notify you when I'm ready to push the final version of the game. Then you could mess with Outpost2.exe to get OllyDbg relevant, tag the code, then restore Outpost2 in the main branch. Then we can proced with tagging the actual release version. I'm not familiar enough with OllyDbg to trust myself in the matter without some help.
Thanks,
Brett
I was able to reproduce the Console Module Error message on my computer. It can be caused by having a space somewhere in the absolute path to Outpost2.exe.
We use this line of code to retrieve the attached console arguments on Outpost2.exe that would be used in loading a module via console (like multitek2):
std::string commandLine = GetCommandLine();
If the folder has a space in it somewhere, such as Big Test Folder 299 below, op2ext will assume the part before the first space is an incoming argument and cause an exception because it isn't formatted correctly:
"\"C:\\Users\\Brett\\Desktop\\Big Test Folder 299\\Outpost2-1.3.0.7-OPU\\Outpost2.exe\" "
The folder location below will not cause an exception:
"\"C:\\Users\\Brett\\Desktop\\Outpost2-1.3.0.7-OPU\\Outpost2.exe\" "
Dave,
Could you verify on your computer if the path to Outpost2.exe has a space in it or not? If it has a space, fixing this bug will fix your problem. I want to make sure we are not finding separate bugs though. You should be able to see the path by copying the top bar from Windows Explorer when you have Outpost2.exe highlighted.
If there is a space somewhere in the path, try moving Outpost 2 to an absolute folder that does not contain a space and see if the warning goes away.
Could you verify the attached screenshot is the screen where you are seeing the internal IP address? Also sense I am really dumb when it comes to networking, could you verify that with NetHelper loaded back in Outpost 2 1.3.6, you would see an external IP address here. If the problem is from NetHelper, I can devise a check to see if NetHelper is being loaded in release versions of Outpost 2 as a starting place for debugging.
Sorry for the poor workmanship on op2ext.
-Brett