Outpost Universe Forums

Projects & Development => Projects => Outpost 2 Update => Topic started by: Vagabond on October 29, 2017, 08:28:27 PM

Title: Updates for Outpost 2 1.3.7
Post by: Vagabond on October 29, 2017, 08:28:27 PM
I was wanting to work some minor improvements on Outpost 2 for inclusion in the next release. Not sure how far past the anniversary of Outpost 2 a release can be made and still call it an anniversary release. :) I'm also not really sure how far along other projects are for inclusion in 1.3.7.

I'd like to keep game balance changes outside the realm of this thread. While I'm not necessarily against some balancing changes, they tend to take over the discussion and bury the rest of the administrative work that I am interested in.

COMPLETED

OUTSTANDING


If these things seem agreeable, I'll start pushing them into the active GameDownload trunk of the REPO with decent COMMIT messages. We can use the commits to verify the change log before release.  https://svn.outpostuniverse.org:8443/!/#outpost2/view/head/GameDownload/Outpost2/trunk

-Brett

Old Version String contained in Outpost 2 1.3.6
(https://forum.outpost2.net/index.php?action=dlattach;topic=6043.0;attach=1025)
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on November 01, 2017, 10:02:11 PM
This sounds like a good plan. Very clear, and actionable. I support these changes.

My one concern is I suspect #6 could cause things to get a bit bogged down. If things do start to get bogged down, I would consider a partial list to be sufficient for a new release.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on November 03, 2017, 01:03:57 AM
Thanks Hooman,

Since no one has responded negatively, I will start slowly working these suggestions into the repository.

I'll post in the pair programming listing about finding a date for working on the vol loader code.

Quote
My one concern is I suspect #6 could cause things to get a bit bogged down. If things do start to get bogged down, I would consider a partial list to be sufficient for a new release.

Agreed. Once the rest of the list is knocked out and tested, unless there are specific dates set aside for testing scenarios, we really should go ahead with a partial list.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on November 26, 2017, 02:18:59 AM
Just wanted to post a quick update on progress here, below are the SVN commit messages.

Replace Outpost 2 specific wells (tile sets) with standard BMP files
    * All files located in maps.vol. Files are well0000.bmp through well0012.bmp. New format is standard 8 bit BMP. Standard 9 bit BMP files are fully compatible with Outpost 2.

Update tech tree dtek_e.txt so Pre Release Eden Demo can be beaten
    * Updated file is located in maps01.vol.

Remove Punwick Junction (four players, Last One Standing) DLL
    * Punwick Junction does not have an associated map file and cannot be played in its current form. The map was based on La Corrida without a peacekeeper AI in the center of the map.

Beyond that, some good progress has been made on op2ext.

 * Better error messaging for problems when loading mods or vol files.
 * Allows loading vol files with any name (*.vol) into the game.
 * Some security fixes involving char* manipulation and copying code.
 * The code is about halfway through being rewritten using C++11/14 practices and a general cleaning (at least best of my ability to clean in C++).
 * A bug in SetSerialNumber that was setting the values in the incorrect order was fixed.
 * Merged changes between the two different versions of op2ext floating around.

Besides a couple of implementation details with public.h and OP2 Memory Management, I should have the skills to finish the rewrite on op2ext (although anyone else's help is still much welcome).


My current head hurter is removing or at least updating the outdated 1.34 version string from the in game options screen (see picture from first post for what I'm talking about). If someone has knowledge on how this is being set, it would be appreciated. I haven't dug into hxd or Ollydbg or anything myself yet to try to find it...


I'd like to add the following items to the list for this release:

 * Have the change log show the most current release at the top and the oldest release at the bottom (so you see the newest stuff when you first start reading.)

 * Add a list of known bugs to the change log.

 * Add some sort of devReadMe to the repository detailing a list of what should be done or looked into each release cycle. Just looking to make it easier to prep a release without missing something.

I'll keep from adding these 3 changes to the first post for a couple of days in case anyone has issue with them or a different plan to discuss.


Concerning testing, before this goes live, we need to make sure that everything still works with the most current version of the OP2Mapper concerning the addition of non Outpost 2 specific BMP tile sets and changing the names of some of the vol files. I can't think of any other programs that would be affected, but if they exist, please post and we can test them. I don't want to push content that makes the mapper harder to use or other programs.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on November 26, 2017, 03:20:21 PM
Quote
New format is standard 8 bit BMP. Standard 9 bit BMP files are fully compatible with Outpost 2.
Umm, 9 bit BMP? What?

Actually, I had to verify they were indeed 8 bit BMP. For some reason I remembered them being 16 bit, but they're not.

Quote
* Have the change log show the most current release at the top and the oldest release at the bottom (so you see the newest stuff when you first start reading.)
Yes, good idea. That would be a bit more standard. My one suggestion is to please do the flipping in it's own commit, without any additions or edits.

Quote
Concerning testing, before this goes live, we need to make sure that everything still works with the most current version of the OP2Mapper concerning the addition of non Outpost 2 specific BMP tile sets and changing the names of some of the vol files.
That's actually a good thing to test. I hadn't thought of that. Though I would expect it to handle either format just fine.
Title: Re: Updates for Outpost 2 1.3.7
Post by: lordpalandus on November 26, 2017, 07:51:41 PM
I thought a byte was 8 bits... where did the extra bit come from, to make it a 9 bit BMP file? From what I understand of color, you can only have arrays of 8 bits each; 8 bit, 16 bit, 32 bit, 64 bit, etc. So how could one have a 9 bit color array?
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on November 26, 2017, 10:07:42 PM
sigh, just a typo on my part.

It should read:

Quote
All files located in maps.vol. Files are well0000.bmp through well0012.bmp. New format is standard 8 bit BMP. Standard 8 bit BMP files are fully compatible with Outpost 2.

I just tried, but do not have permission to go in and edit my commit message. Perhaps Hooman, Leviathan, or leeor_net could fix it?

Hooman,

No problem with reordering the change log in a separate commit from any other changes.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on November 27, 2017, 03:19:32 AM
Quote
I just tried, but do not have permission to go in and edit my commit message. Perhaps Hooman, Leviathan, or leeor_net could fix it?
Err, no. It's set in stone now.

Subversion doesn't allow rewriting history. The only way to change it now would be to have an admin dump the repository, filter the dump file to make the change, and then reload the dump back into the repo, replacing it's contents. That generally means taking the repo offline during the replacement process. It also means anyone who did an update that includes a modified commit now has a borked local repo and must redownload. Not generally worth it, especially for small changes. You'd normally only ever do this in the case of legal considerations, such as copyright violations, or privacy concerns, such as when a confidential file is accidentally committed to a public repo.

With Git you can do it. Git supports history rewriting. Though it's generally discouraged to rewrite history after you've published.

Btw, you shouldn't push after every commit in Git. Just push once at the end of a session, or if you've just completed an urgent change that really needs to get out right away. As long as you haven't pushed yet, it's really easy to make changes like this. In particular, git commit --amend lets you fix typos in commit messages.


Edit: Oh the irony of all the typos I made in this post. I just edited it like 5 times.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on December 09, 2017, 01:20:12 AM
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]


Quote
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.

Code: [Select]
char *verStrAddr = (char*)0x004E973C;

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on December 12, 2017, 09:05:50 PM
Quote
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.

Ahh, right, I remember now. The commit message can be changed, but changes to it are not versioned. As changing it will overwrite and discard the old value, you can't do it without some configuration. There are details on this on StackOverflow:
How to edit log message already committed in Subversion? (https://stackoverflow.com/questions/304383/how-to-edit-log-message-already-committed-in-subversion)

Unfortunately, I don't have admin access on the current SVN server to make such a change. You'd have to ask Lev if you want to make such a configuration change.

As a side note, SVN doesn't hash all the files and the commit message to create a secured history. Couple that with log messages not being downloaded into the working copy, and only visible by directly contacting the server, so yes it is possible to make such changes without ensuing havoc caused by conflicting data in other people's working copy. Still, editing history is always something you want to be careful about, as it can be abused to ill effect.


Interesting note about the dark colors for the mapper minimaps. I assume the full sized tiles still look right? If so, it might be a format error for the minimap bitmaps. Perhaps bit field sizes are off by 1 bit or something, which can have such an effect. Guess I'd have to look at the code. Maybe there's a bug in the mapper?


I believe version strings were updated with a hex editor in the past, so that's probably the right way to do it. I like your idea of removing the version string. If the information is available elsewhere, it may be better to remove duplicates. More maintainable that way, and then we don't have to go digging through the executable again for future releases.

To remove the strings, you can truncate them by placing a zero byte where the new end should be. Make sure it's a binary/hex 00, and not an ASCII "0". Overwriting strings like that is usually quite safe, including early truncation while preserving the space the string used to take up. In contrast, changing the length of strings, by deleting or adding bytes, would shift the remaining contents of the exe file and likely corrupt it.

There may be version numbers in both Outpost2.exe and OP2Shell.dll.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on December 16, 2017, 01:42:53 AM
Quote
To remove the strings, you can truncate them by placing a zero byte where the new end should be. Make sure it's a binary/hex 00, and not an ASCII "0". Overwriting strings like that is usually quite safe, including early truncation while preserving the space the string used to take up. In contrast, changing the length of strings, by deleting or adding bytes, would shift the remaining contents of the exe file and likely corrupt it.

There may be version numbers in both Outpost2.exe and OP2Shell.dll.

Took me a bit to figure out how to insert hexadecimal and not ANSI text 0 using HxD, but I finally figured it out. This erased the string from the Game Options Section. The starting address for OPU Ver: is 0xE46E4, which is not collocated with the associated version string at 0xE1A00.

I still cannot find where we set the version number that appears in the top of the ABOUT section. It was updated to 1.3.6, so it had to have been modified recently. If Leeor or Arklon know where it is at and have the time, the assist would be appreciated.


Quote
Interesting note about the dark colors for the mapper minimaps. I assume the full sized tiles still look right? If so, it might be a format error for the minimap bitmaps. Perhaps bit field sizes are off by 1 bit or something, which can have such an effect. Guess I'd have to look at the code. Maybe there's a bug in the mapper?

The full sized map inside the editor looks perfect. The bug only pertains to the minimap and when saving the minimap to BMP on disk. If this was an easy fix on the backend, I think it would be worth making. Even if we don't change out the original tilesets, it would make working with the Greenworld set more natural. I'm testing with version 2.2.1 of the mapper.

I'm leaning towards replacing the wells with the standard format files even though it affects the map editor. We can document in the change log where to get the original wells if the minimap discoloration bothers someone using the mapper. In the long term though, if anyone manages to rewrite the mapper, it would be nice to not worry about trying to support the older format.

If anyone disagrees with changing them out though, I can push the Outpost 2 specific ones back in.

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on December 16, 2017, 10:45:17 AM
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:
Code: [Select]
// **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.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on December 16, 2017, 03:14:23 PM
Quote
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.

...

We could add this to our next pair programming session.

I'm game to look at it. I'm guessing we would need to the pull the project into a modern version of Visual Studio first. Would we work in the GitHub version of the code here: https://github.com/OutpostUniverse/OP2Editor?

I'd like to treat this as a bugfix only and not make major changes to the code structure. Otherwise, op2ext and Outpost 3.1.7 will never get through to completion.  :-\

Would this simply be recompiling the backend into a DLL, placing it next to the mapper, then testing? I don't think the mapper frontend exists in our repository, but once we have the C++ backend compiling, we could step-through debug the backend code as needed. If we fix and release, we can start saving the PDB file so future debugging can be done without having to update and recompile the code.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on December 16, 2017, 11:58:14 PM
Ahh, well there we go. I didn't even realize it'd already been ported to GitHub. I guess it was an easy case though, since the project was developed largely outside of version control, and so has no real commit history.

Yes, a modern project file would be a good place to start.

Quote
Would this simply be recompiling the backend into a DLL, placing it next to the mapper, then testing?

Yes. It might even be simpler. I believe the build system can auto register COM DLLs, and if the front end is loading the DLL through the COM libraries, you shouldn't even need to copy it to the same folder as the mapper, it should just work. But failing that, copying it should do the trick. No need to recompile the front end.

Which reminds me, we should find and post the front end source somewhere.

I'm noticing a bit of dyslexia on the version number there. ;)
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on December 17, 2017, 12:53:32 AM
I tested the version string in Outpost2.exe located at 0xE7F3C. It indeed controls the multiplayer compatibility. I'd like to update this to 1.3.0.7 since we are including the new multitek tech tree in 1.3.7 that would break compatibility with previous multiplayer sessions.


Below is a rough draft of the first Publishing ReadMe. Suggestions on formatting and other steps that should be included are welcome.


Outpost 2 Publishing ReadMe
---------------------------

This ReadMe contains instructions for publishing a new version of Outpost 2. While preparing to release a new version of the game, ensure these instructions are updated with any new requirements for publishing so they are taken on subsequent releases.


1. Ensure the newest version of op2ext has been compiled and included (https://github.com/OutpostUniverse/op2ext).


2. Ensure the newest version of all bundled extension modules (like NetHelper) are included

   A. Ensure proper settings have been set for bundled extension modules in Outpost2.ini.


3. Add new scenarios that seem free of bugs and are complete enough to play through.

   A. If tech tree modifications are made and multiple scenarios rely on the tech tree, ensure the changes do not negatively affect existing scenarios by changing their tech trees.

   B. Place associated new maps in maps.vol archive. For vol archive editing, see the console application OP2Archive (https://github.com/OutpostUniverse/OP2Archive).


4. Update version strings in all DLLs and Outpost2.exe to reflect the new release version info.

   A. Resources may be edited with Resource Hacker (http://www.angusj.com/resourcehacker/) or popular IDEs.


5. Update version string located in the about section.

   A. ? ? ?


6. Update internal version string for multiplayer.

   A. Open Outpost2.exe using a memory edit tool like HxD (https://mh-nexus.de/en/hxd/).

   B. Find version string at starting at Offset 0xE7F3C (Or search for version text).

   C. String format should be A.B.0.C. Where ABC represents Semantic Versioning A.B.C (https://semver.org/).


8. Review Changelog. Ensure all changes are recorded and fixed bugs removed from known bugs list.


9. When all changes have been committed to the repository, tag the release.


In the very long term, I'm thinking that OP2Utility and OP2Editor could be merged into one project. They are both designed to support manipulation of data and files associated with Outpost 2 as a library for other frontend applications. We would have to decide what to do about the COM interoperability code. Also, I'd like to see C++17 filesystem leave experiemental on the major compilers before continuing to spread it through all the projects. The combination of my lack of knowledge of COM and unfamiliarity with C++ made OP2Editor pretty intimidating for me to review/use several months ago.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on January 02, 2018, 05:22:36 PM
I was reading through this post by TH300 on how to use NetFix: https://forum.outpost2.net/index.php/topic,5313.msg81424.html#msg81424

The current default .ini settings for Outpost 2 1.3.6 for NetFix is:


[NetFix]
Dll = "NetFix\NetFixV3.dll"
GameServerAddr = "outpost2.net:47800"
ProtocolIndex = 3


As per the NetFix post, should this be updated to read:
GameServerAddr = "server.outpostuniverse.org:47800"

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Arklon on January 03, 2018, 01:17:35 AM
Quote from: Vagabond on January 02, 2018, 05:22:36 PM
I was reading through this post by TH300 on how to use NetFix: https://forum.outpost2.net/index.php/topic,5313.msg81424.html#msg81424

The current default .ini settings for Outpost 2 1.3.6 for NetFix is:


[NetFix]
Dll = "NetFix\NetFixV3.dll"
GameServerAddr = "outpost2.net:47800"
ProtocolIndex = 3


As per the NetFix post, should this be updated to read:
GameServerAddr = "server.outpostuniverse.org:47800"

Thanks,
Brett
No, the first one is correct. TH300's post is outdated.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on January 25, 2018, 02:08:47 AM
I've uploaded the new op2ext.dll to the repository and restructured the vol files as discussed. So now we have:

 - art.vol
 - tech.vol
 - maps.vol

I also removed the tech files located in sheets.vol and placed them in tech.vol. Newer tech files had been sprinkled into maps0X.vol and I wanted to consolidate them all. Check SVN revision 1235 for the current state of affairs.

I started adding the new scenarios. Unfortunately, for some reason any scenario that uses survtech.txt fails to load. survtech is used on several popular multiplayer scenarios. I think sirbomber is the curator for it. The message I get is:

Quote
local load failed

and

Quote
Host could not load the scenario

They fail to load when survtech is loaded from a vol file. When survtech is placed loose in the root game directory, the scenarios work.

Has anyone encountered this sort of behavior before? I guess in the grand scheme we could leave it loose for the release and be okay, although I'd like to figure out what is wrong. I will try a couple other random troubleshooting steps another day as I'm out of time to work now.

To complicate things, there seems to be a small bug in op2archive when using the ADD command. Not sure if it is a bug though and need to troubleshoot some more. The CREATE command works fine though.


Quote
No, the first one is correct. TH300's post is outdated.

Thanks Arklon.

Also, thank you Leeor for making this a sticky thread.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: leeor_net on January 25, 2018, 07:30:53 AM
Quote from: Vagabond on December 17, 2017, 12:53:32 AM
In the very long term, I'm thinking that OP2Utility and OP2Editor could be merged into one project. They are both designed to support manipulation of data and files associated with Outpost 2 as a library for other frontend applications. We would have to decide what to do about the COM interoperability code. Also, I'd like to see C++17 filesystem leave experiemental on the major compilers before continuing to spread it through all the projects. The combination of my lack of knowledge of COM and unfamiliarity with C++ made OP2Editor pretty intimidating for me to review/use several months ago.

-Brett

My personal suggestion is to dump COM code altogether. It's not portable, it's ugly as hell and there are better ways to achieve interoperability than through COM.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on January 28, 2018, 12:15:49 PM
Quoting Myself:
Quote
They fail to load when survtech is loaded from a vol file. When survtech is placed loose in the root game directory, the scenarios work.

Has anyone encountered this sort of behavior before? I guess in the grand scheme we could leave it loose for the release and be okay, although I'd like to figure out what is wrong. I will try a couple other random troubleshooting steps another day as I'm out of time to work now.

To complicate things, there seems to be a small bug in op2archive when using the ADD command. Not sure if it is a bug though and need to troubleshoot some more. The CREATE command works fine though.

I rooted out some bugs in OP2Archive dealing with not placing files into volumes in alphabetical order. I'll be putting out a patch for OP2Archive to fix this behavior before continuing the work on Outpost 2 1.3.7. Thanks to Hooman for some help with the troubleshooting as usual.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on February 03, 2018, 08:33:06 PM
I placed 8 'new' scenarios and updated the tech tree of one scenario in Outpost 2. I listed the creator(s) in the change log. Hopefully this list includes everyone who should be credited, so please let me know if I missed anyone. (Or if people prefer anonymity, I can pull the names alltogether)

 * Updated survtech.txt, the tech tree used by Forsaken World (4P, SRV), by sirbomber.
 * Added scenario Bomber's Big Blast (4P, LoS), sirbomber.
 * Added scenario Hidden Treasure (4P, LoS), Flashy.
 * Added scenario Caught in the Crossfire (4P, SRV), Mcshay.
 * Added scenario Darkest Hour (4P, SRV), sirbomber.
 * Added scenario Danger Zone (5P, SRV), Flashy.
 * Added scenario Fractured Alliance (5P, SRV), by sirbomber.
 * Added scenario Judgement Day (6P, SRV), by sirbomber.
 * Added scenario Outcaster's Starship (Colony Game, Starship), by Lord of Pain, ECC, & Flashy.

There is another problem with OP2Archive. The sorting is working, however it sorts all capital letters before any lowercase letters. I've pushed a patch to GitHub and will distribute a newer binary soon that fixes this sort.


I've noticed that oftentimes the working copy of Outpost 2 does not fully close on exit on my machine. This manifests by vol files still being accessed by Outpost 2 on closure. The task manager will move Outpost 2 from the APP list to the x86 backround process list on closure. I've also noticed the Visual Studio debugger will not automatically terminate when Outpost 2 is closed and the debugger is attached.

Does anyone know where to start looking for solving this and/or a tool to use to see which processes remain open or something?

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on February 03, 2018, 11:23:04 PM
Quote
I've noticed that oftentimes the working copy of Outpost 2 does not fully close on exit on my machine. This manifests by vol files still being accessed by Outpost 2 on closure. The task manager will move Outpost 2 from the APP list to the x86 backround process list on closure. I've also noticed the Visual Studio debugger will not automatically terminate when Outpost 2 is closed and the debugger is attached.

Does anyone know where to start looking for solving this and/or a tool to use to see which processes remain open or something?

Hmm, maybe investigate if op2ext changes are the culprit.

If the debugger is still running, it might be helpful to pause the program and see what's on the call stack, or what threads are still active (which could mean multiple call stacks).
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on February 04, 2018, 02:59:36 AM
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:

Code: [Select]
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.

Code: [Select]
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
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on February 04, 2018, 04:05:48 AM
Arklon may be able to help here.

What you found seems to make sense. The NetHelper is clearing out the port forwarding rules in the router, which requires communication with a remote device. Hence, the waiting. If there are any dropped packets or other communication problems, that could potentially be a long wait. It also looks like the cleanup may be done over a range of ports, in a serial manner, which can make the wait quite significant. I can't tell for certain look at this code, but perhaps it can be made quicker by doing the whole range of ports in parallel.

It might make sense to do the forwarding and cleanup when entering and exiting the multiplayer menu section of the game. That could hide the cleanup time, so there's no long delays during shutdown.


We should probably add some compile notes, or perhaps have a standard way to include additional dependencies in the repository, or as submodules. This is an issue we've kind of neglected for a few projects.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on February 04, 2018, 05:23:39 PM
For compiling NetHelper, I read through the linker errors closer, and it appears the problem is related to Microsoft making breaking changes to their toolset regarding the header stdio.h. This change was introduced with VS2015 and it looks like NetHelper was compiled with the Visual Studio 2010 (v100) toolset.

See quote below from this Microsoft article: https://msdn.microsoft.com/en-us/library/bb531344.aspx#BK_CRT

Quote
The printf and scanf family of functions are now defined inline. The definitions of all of the printf and scanf functions have been moved inline into <stdio.h>, <conio.h>, and other CRT headers. This is a breaking change that leads to a linker error (LNK2019, unresolved external symbol) for any programs that declared these functions locally without including the appropriate CRT headers. If possible, you should update the code to include the CRT headers (that is, add #include <stdio.h>) and the inline functions, but if you do not want to modify your code to include these header files, an alternative solution is to add an additional library to your linker input, legacy_stdio_definitions.lib.

To add this library to your linker input in the IDE, open the context menu for the project node, choose Properties, then in the Project Properties dialog box, choose Linker, and edit the Linker Input to add legacy_stdio_definitions.lib to the semi-colon-separated list.

If your project links with static libraries that were compiled with a release of Visual C++ earlier than 2015, the linker might report an unresolved external symbol. These errors might reference internal stdio definitions for _iob, _iob_func, or related imports for certain stdio functions in the form of _imp_*. Microsoft recommends that you recompile all static libraries with the latest version of the Visual C++ compiler and libraries when you upgrade a project. If the library is a third-party library for which source is not available, you should either request an updated binary from the third party or encapsulate your usage of that library into a separate DLL that you compile with the older version of the Visual C++ compiler and libraries.

I'm looking at downloading the v100 toolset to test if this is actually the culprit.


Quote
What you found seems to make sense. The NetHelper is clearing out the port forwarding rules in the router, which requires communication with a remote device. Hence, the waiting. If there are any dropped packets or other communication problems, that could potentially be a long wait. It also looks like the cleanup may be done over a range of ports, in a serial manner, which can make the wait quite significant. I can't tell for certain look at this code, but perhaps it can be made quicker by doing the whole range of ports in parallel.

The time taken to cleanup NetHelper seems acceptable to me. The problem is if it hangs up and never completes destruction (or decides to take 5 minutes to complete). While maybe improvements could be made to the time taken I don't think it is needed. I want better proof it is actually that INDEFINITE wait call causing the hang before assuming though. Hopefully getting the code to compile on my machine with the older toolset will allow proving that.
See updated information at: http://forum.outpost2.net/index.php/topic,6067.0.html

Quote
It might make sense to do the forwarding and cleanup when entering and exiting the multiplayer menu section of the game. That could hide the cleanup time, so there's no long delays during shutdown.

What happens if I immediately click on multiplayer again after ending a match and cleanup is in process? Or what happens if I try to create a new match while NetHelper is still initializing? I think it is a lot cleaner to handle on opening the program and on program closing as is right now. Although I'd certainly defer tp what Arklon prefers here.

Quote
We should probably add some compile notes, or perhaps have a standard way to include additional dependencies in the repository, or as submodules. This is an issue we've kind of neglected for a few projects.

I think Arklon actually hooked the code to the dependencies nicely. I just jumped to conclusions when all the linker errors showed up. Although some standardization might be a good thing here.

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on February 07, 2018, 05:12:06 AM
Quote
What happens if I immediately click on multiplayer again after ending a match and cleanup is in process? Or what happens if I try to create a new match while NetHelper is still initializing? I think it is a lot cleaner to handle on opening the program and on program closing as is right now. Although I'd certainly defer tp what Arklon prefers here.
Well for  now it sounds like the player would have to wait about 3 minutes after exiting multiplayer before returning to the main menu  :P

Clearly not a very workable solution.

My expectation was the cleanup code would only take a fraction of a second to run.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on February 24, 2018, 03:11:10 PM
I uploaded 5 more scenarios today. Sort of the selfish include since they were my scenarios. I think there may be one more scenario to toss in by onehand. Besides that, the final task for me is editing the version info resource for all the existing dlls and the .exe to be part of the 1.3.7 package. Resource Hacker has been a great tool, but it only allows editing one file at a time. I'm going to look around for a bulk resource edit tool if such a thing exists. If anyone has a suggestion for such a tool, it would be appreciated.

Thanks,
Brett

Commit Message

Outpost 2: Add 5 more scenarios to the game
 
 - Added scenario Rising From the Ashes (Colony Game, Starship), by Brett208
 - Added scenario Campaign - Ply, Pursued, Ep 1 - Evac Under Fire (Colony Game), by Brett208
 - Added scenario Campaign - Ply, Pursued, Ep 2 - On the Run (Colony Game), by Brett208
 - Added scenario Campaign - Ply, Pursued, Ep 3 - Rescue Escort (Colony Game), by Brett208
 - Added scenario Rescue Escort (2P, Convoy), by Brett208 (Under Land Rush Section)
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on February 24, 2018, 08:28:16 PM
Why would the existing DLLs need to be updated? I think that would be a bad practice to update existing DLLs for every release. I'm assuming versions strings got added to the meta data at some point?

I know in the past some meta data was updated for them. I also remember undoing a bunch of it for a release years ago.

I don't mind so much helpful additions, such as a description of the level provided by a DLL. I really want to stay away from game version numbers in those messages though.


It seems Resource Hacker (http://www.angusj.com/resourcehacker/) can take command line arguments. Check -action for add and extract for version resources. You can probably hack something together from that.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on February 25, 2018, 01:55:54 PM
I noticed the product version of DLLs had been updated to version 1.3.0.6. Although reviewing some more dlls, it seems all dlls' resources were not updated so it was partially done. I'm good either way, just trying to be consistent with what has been going on in previous releases.

-Brett

Revision 1100:

- Updated version strings throughout the Outpost2 executable and DLL addons.
- Added NetHelper to OP2 package.
- Updated OP2 executable icon to include a much more modern game icon.

Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on February 26, 2018, 12:11:57 AM
For the sake a future maintainability, I would recommend stripping out such version numbers if they're not needed. Less to update for future versions. 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.


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.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on February 26, 2018, 04:05:53 PM
Below is the current Version Info resource script for op2ext.dll as an example.

Quote
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?

Code: [Select]
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  
}
}

Quote
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
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on February 28, 2018, 09:12:37 AM
Yeah, I'm thinking just remove those 2 lines.

If this is for op2ext, then it should have no impact on the layout of Outpost2.exe. I don't expect the version info will create problems with OllyDbg.

I'm not sure if we have much in the way of comments for the DLLs. Maybe a bit for the shell DLL. I've never noticed issues with comments there being overwritten, but then I might not have noticed. The vast majority of the comments are for Outpost2.exe.


For now make sure the icon replacement process is documented.

I'd say worry about getting a proper release done first. After a new release is rolled out and tagged, the development branch can receive a quick rollback + redo of the icon. I suppose we could tag the rollback too, though I don't know if that's strictly necessary.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on March 02, 2018, 01:37:01 PM
Hooman,

I attached a modified version of Outpost2.exe. It contains the original game icon (pulled from tagged release 1.3.5 of the game). Also, the product version is set as 0.0.0.0.

I am hoping that we can modify the version info digits without affecting ollyDbg as long as we are changing out one for one characters. IE moving the file version from 1.3.0.6 to 1.3.0.7. If this works, the limit of course would be we couldn't make a 1.3.0.11 version someday.

Also in the zip file is a .res containing the icon information that I used to un-update Outpost2.exe. So, if this works with Ollydbg, all one would have to do is replace the current icon using the supplied .res file and then OllyDbg comments will work again. We can place the .res file in the repository as well, although it is easy to generate using Resource Hacker.

I checked and the file size of the recompiled executable appears the same as version 1.3.0.5.

Please test against the ollyDbg comments and let me know how it goes. If it works, I can throw a note on how to reformat it in the PublishingReadMe.txt for future reference.

-Brett

----------------------
EDIT: Attachment removed since it tested correctly.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on March 14, 2018, 10:56:21 PM
Ok, I finally got around to testing this. It works. The OllyDbg user comments are preserved.

We can probably remove the download from your post. Based on the number of downloads, it may be causing confusion.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on March 15, 2018, 12:09:44 PM
Hooman,

Thanks for testing. Glad to hear it worked. I think this weekend I should have time to upload the resource file with some text on how to use it to restore OllyDbg comments to the SVN repository. I deleted the zip of the executable as you suggested.

I've been pretty busy on a different project plus work has been very busy as well. Once the other non Outpost project is done I'll be swinging back to this.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on April 01, 2018, 12:47:10 PM
Finally updated the SVN repository to include the resource file containing the original Outpost 2 icon and a readme on what to do with it and why it exists. See below for ReadMe.

Just to verify, what we want to have happen is:

The other option would be having anyone who wishes to use OllyDbg just modify Outpost2.exe manually using the resource file. If above is what we want, I'll update PublishingReadMe.txt to include these steps. I think we are basically ready for the release besides me looking things over a few more times.

-Brett



Restoring OllyDbg Coments on Outpost 2.txt's Contents

RESTORING OLLYDBG COMMENTS ON OUTPOST2.EXE
------------------------------------------

Starting with Outpost 2 version 1.3.6, the embedded game icon was updated for a more modern feel. This breaks compatibility with important OllyDbg notes on internal Outpost 2 code. The newer icon takes up more memory than the original and keeps the notes from properly loading in OllyDbg.

However, the OllyDbg notes may still be used if the size of Outpost 2's resources are returned to match the exact same size as version 1.3.5 and earlier. This is easy to accomplish using Resource Hacker (http://www.angusj.com/resourcehacker/). Other tools may work as well, but are not tested.

To restore the Outpost 2 executable for use with the OllyDbg notes:

1. Open Outpost2.exe with OllyDbg.
2. Right click on Icon and select 'Replace Icon ...'
3. Click 'Open file with new icon...'
4. Select 'Outpost 2 Original Icon.res' and click 'Open'.
5. Click 'Replace'.
6. Clik File -> Save

A new file call Outpost2_original.exe will be created. Feel free to delete this as the original file may be retrieved from the repository at any time.

Additionally, all resource strings including the version_info must remain the exact same size as they existed in version 1.3.5 or earlier. Individual characters may be changed, such as changing 1.3.0.6 to read 1.3.0.7 but only if the length of the string remains the same.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on April 08, 2018, 03:27:02 PM
Outpost 2 version 1.3.7 is ready!

It is currently located at: https://svn.outpostuniverse.org:8443/!/#outpost2/view/head/GameDownload/Outpost2/trunk

I have played through all the new scenarios and tested op2ext back when it was in development. Today, I ensured that op2ext is properly loading dlls and all new scenarios load properly on Windows 10 64Bit.

I don't know if anyone else wants to provide testing, which wouldn't be a bad idea. Otherwise, I don't have permissions to post on the website (and I'm not really interested in having it). Once someone posts, I'll tag the SVN repository with the new version.


Outpost 2 Version 1.3.7 Changelog:

Core Outpost 2 Updates

Scenario Updates


OP2 Mapper Compatibility

When using the OP2Mapper with Outpost 2 version 1.3.7, you will notice the following two issues:

1. A fatal error is reporting on opening the mapper because the file OP2_ART cannot be read. Additionally maps cannot be opened without crashing the program. This is caused by relocating the file OP2_ART to art.vol. OP2Mapper can find the file properly using the steps below.

2. When opening maps, the 1 pixel per tile minimap will be readable, but the colors will be off. Saving the minimap to disk will suffer the same color problem. This problem is caused by updating the WELL files to use a standardized bitmap encoding instead of the Outpost 2 specific encoding. This problem is currently not fixable, but the mapper still functions with the visual artifact. I feel like the tradeoff is worth it, because now you can open and edit the WELL files with any image editor and change the in game tiles. Also, future programmers can access the WELL files without worrying about the custom bitmap implementation.

Make OP2Mapper.exe work with Outpost 2 version 1.3.7:
Title: Re: Updates for Outpost 2 1.3.7
Post by: Arklon on April 08, 2018, 06:31:01 PM
I've been testing some minor changes to NetHelper to maybe avoid the 3 minute long shutdown times again. What I've done should help, but I've been meaning to dig into the miniupnpc code to see if I can make a version of unforward that doesn't wait for an ACK (libnatpmp didn't need a modification in order for me to do that).
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on April 09, 2018, 02:24:54 PM
Arklon,

Approximately how long do you need before it is ready? I think it makes more sense to delay releasing 1.3.7 until you are ready unless it is going to be a long time.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on April 10, 2018, 05:50:50 AM
Good job putting this together. That was a lot of work.


I suppose I should try to give things a quick run through on Linux, though I don't expect any problems with the game.

The map editor problems had slipped my mind. Actually, I didn't even know about the OP2_ART issue. Would be nice to get things fixed, though it doesn't seem to be a show stopper.

It would be nice to include Arklon's update, though you're right about not wanting to delay a release for too long.


I'm thinking maybe a few days for review or updates, including the weekend, maybe release the following weekend? How do people feel about a target date of April 21st?
Title: Re: Updates for Outpost 2 1.3.7
Post by: leeor_net on April 10, 2018, 08:10:13 PM
Sounds like a plan to me.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on April 11, 2018, 04:23:07 AM
Hooman,

This all sounds good to me. If you see anything that isn't Wine compatible, please let me know. If it is reasonable to fix, I'd like to keep everything working via Wine.

For the map editor, as long as you specify to look for art.vol in the options, everything will work fine. I should probably throw this in the wiki under map editing section so people have a place to reference it.

I knew OP2_ART created an issue with the mapper, but I don't think I mentioned it until a couple of days ago, so that is my bust.

Part of the reason I'm maintaining OP2Utility is so that it is a viable solution for dealing with vol files in a future mapper project, for Leeor to use in his or anyone else which is probably the long term solution here.

Thanks,
-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Arklon on April 18, 2018, 08:53:54 PM
Quote from: Vagabond on April 09, 2018, 02:24:54 PM
Arklon,

Approximately how long do you need before it is ready? I think it makes more sense to delay releasing 1.3.7 until you are ready unless it is going to be a long time.

-Brett

At this rate, about the combined lifespans of several universes' worth of time or so.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on April 25, 2018, 11:00:54 AM
Well we passed the target date.

Hooman, how did it all run on Linux via Wine?

Does an admin for the site want to get it posted?

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on April 25, 2018, 10:30:33 PM
Yes, I've gotten a bit behind with forum duties, though I have been very aware of the passing target date.

I suppose in the back of my mind, I'm dreading some kind of complicated release process, but really, it's just zipping up the GameDownload trunk folder from SVN, isn't it. All the rest of the checklist, you've already done.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on April 26, 2018, 12:19:15 PM
Just to confirm, the most recent SVN update to the GameDownload trunk folder was on 2018-02-25, while your announcement about the next release being ready was made 2018-04-08. That's a little over a month gap. Were there any updates during that time period that were supposed to be included? I kind of had the sense there were some op2ext updates being worked on at some point, though checking git history on that project shows no changes since January.

I guess I had the sense the announcement was made after finishing some final feature, though perhaps it was made more after testing and a bit of time had passed to verify things?
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on April 26, 2018, 03:05:57 PM
Hooman,

The dates you list make sense. I got distracted at the end of development on other projects. When I came back I was going to modify all the file resource version_infos to match the new release but you cautioned against that, so there were no changes. I did spend some time testing the new scenarios, but nothing came up in testing requiring committing. I was also working on testing the old icon for ollyDbg comment purposes, but that didn't require changes to the actual GameDownload trunk.

You are correct that it should just be zipping the trunk and adding it to the website. I wouldn't mind seeing some sort of changelog and ability to download older versions on our website someday.

After pushing to the website, we will need to follow up with tagging the SVN repo and pushing the OllyDbg friendly commit, etc.

Thanks,
-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on April 29, 2018, 07:51:30 AM
Ok, finally got this handled:
 - Quick Linux test, seems fine
 - Packaged new ZIP file
 - Virus scanned
 - Uploaded to site
 - Updated download link
 - Tagged SVN release
 - Restored old OP2 icon (for use with OllyDbg)

We still need an announcement in the News forum. Vagabond, you want to handle that? You're most familiar with the details of the update.

I guess that means we can create a new thread and start prepping for a 1.3.8 release. So far that entails restoring the new icon, and bumping the version number.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on April 30, 2018, 04:13:46 AM
Hooman,

Thanks for the Linux test. I'll add scan for viruses to the release instructions as that is a great call. Glad you didn't find any or that would have been awkward.

I'll post the announcement shortly. I'll pull the download and make sure everything works on my Windows machine as well before posting. Just in case!

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on May 01, 2018, 06:19:37 AM
Okay, I just finished restoring the release icon back on the repository. I also incremented the version number on Outpost2.exe resource version to 1.3.0.8. You can use this to distinguish a release build from a development build if the need ever arises. I also updated the release instructions to include scanning the folder for viruses before release. Thanks Hooman for fixing the typo in my ollyDbg instructions.

Restore the release icon to Outpost2.exe

 - Add the release icon as a resource file for future use (Outpost 2 New Icon.res).
 - Update Restoring OllyDbg Comments in Outpost 2.txt to include instructions for restoring the release icon.
 - Move version number of Outpost2.exe to 1.3.0.8 to allow distinguishing development builds from release builds.

Lastly, I updated the Wikipedia by moving all the custom scenarios out of custom and into their respective categories since they are now bundled with the game.

I haven't heard any complaints yet about the release, so that is a good sign...

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: dave_erald on May 28, 2018, 07:11:42 PM
Download 1.3.0.7 , delete 1.3.0.6 , put this one in and play, comes up with a Error box

Outpost 2 error

ConsoleModuleLoader.cpp, Line:95: A switch was expected but not found. Prefix switch name with '/' or '-'

Myself and two others are seeing this. I'm in windows 7, game still starts after acknowledging.

And INTERNET (TCP/IP) is showing my internal address, not my external. So something something something...
Title: Re: Updates for Outpost 2 1.3.7
Post by: leeor_net on May 28, 2018, 07:22:14 PM
(https://snag.gy/qKj14n.jpg)
Title: Re: Updates for Outpost 2 1.3.7
Post by: dave_erald on May 28, 2018, 07:24:22 PM
that's the one
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on May 29, 2018, 12:01:35 AM
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):

Code: [Select]
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
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on May 29, 2018, 03:11:04 AM
I'm noticing there wasn't much context with the error message, which can help people understand what went wrong, and possibly how to fix it. I think the error message can be improved to show what the game is seeing, along with the problem statement. Perhaps show the quoted components. A path parsing issue due to splitting on a space can become clear, and allow people to take action such as moving things to a folder without a space, or trying to put quotes around a string, or escapes in front of spaces.

In this case, it doesn't look like there is anything the user can do in terms of quoting or escaping. They'd only be able to move the folder.

It looks like the issue is the istream_iterator simply splits on spaces, and doesn't respect quoting or escaping. That's not too surprising for C++, which tends to have pretty basic facilities.

The Windows API method CommandLineToArgvW (https://msdn.microsoft.com/en-us/library/windows/desktop/bb776391(v=vs.85).aspx) may be more appropriate. Ideally you want the command line argument parsing to match the standard way. That can be done by using the arguments from main (which you don't really have access to), or by calling the same standard method.


I believe the game always displayed the internal IP address. There's no way for the game to know the external IP address without being told by another machine, either the router itself through UPnP or similar (NetHelper), or by the game server or another client (NetFix).
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on May 29, 2018, 03:27:03 AM
I noticed an additional issue yesterday that seems rather specific to my environment. I just confirmed it now.

On Linux, when running the game in OllyDbg under Wine, there are two error dialog boxes that popup on startup. They do not prevent the game from loading or running, you just have to click through them. This only happens when running the game with OllyDbg. Running the game normally under Wine doesn't show any dialog boxes.

Quote
Bad or unknown format of 32-bit executable file 'C:\windows\system32\msvcr100.dll'
Quote
Bad or unknown format of 32-bit executable file 'C:\windows\system32\msvcp100.dll'

I noticed this when looking into the crash report for Evacuation Under Fire - Ply Campaign Scenario that affected the Garage storage view. I tried loading up the saved game that reproduces the issue in a debugger so I could see where the game crashed, and encountered the error messages while loading the game.


Edit:
After some googling around, these files are provided by the Visual C++ 2010 Redistributable package
MSVCR100.dll = C Runtime for Visual Studio 2010
MSVCP100.dll = C++ Runtime for Visual Studio 2010

Dependence on these DLLs is affected by project compile options:
 
The popups occur just after loading the NetHelper module. It might be worth checking the compile options for that project.
Title: Re: Updates for Outpost 2 1.3.7
Post by: leeor_net on May 29, 2018, 05:49:10 PM
It's as soon as I start the game. In my case there is a space in the directory path: "C:\Users\Leeor\Desktop\Outpost 2"
Title: Re: Updates for Outpost 2 1.3.7
Post by: dave_erald on May 29, 2018, 06:43:32 PM
Brett -

    Yeah that corrected it, moved the folder from where it was to straight onto the desktop and it is fine that way.

And yes the png you loaded is correct. OP2 always showed the internal IP, but in Arklon's nethelper changelog it shows him correcting op2 to show the external IP. Not sure at what version of what or where it stopped doing this, but it's back to showing the internal, both in 1.3.0.7 and .6

(Changelog shows you need Upnp, my router has it and was enabled, maybe it's just my side, but more than just myself are seeing this so...)

I've been out of the forum for awhile, so maybe I missed where this was addressed. Or I'm doing something wrong somewhere...
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on May 30, 2018, 02:00:58 AM
Dave,

No worries about being out of the forums. I'm usually out of the chat room :) Thanks for the quick reply and test on the bug.

Glad to here we located the bug dealing with the command line switch. Curious that your IP address problem is fixed now. Would you mind attempting another check for me? Could you place Outpost2.exe back into a directory with a space in it. Then load it, get the error message caused by the space in the path, and see if your IP address shows incorrectly again. I want to test if somehow when this error occurs if it is keeping the .ini loaded mods from properly initializing.

If the previous test doesn't cause the internal IP address to show up, could you try opening and closing Outpost 2 a couple of times in a row and then seeing if the IP address still shows proper? It takes a long time for NetHelper to release all its assets. I wonder if attempting to open Outpost 2 before all resources are released could cause problems within NetHelper/Outpost 2 loading NetHelper.

Hooman,

Nice investigative work. I just checked the project settings as listed on GitHub. It is set to compile with Visual Studio 2010. It is also set as /MD (Multi Threaded DLL), which I believe means it relies on the Visual C++ 2010 runtime. That is assuming the settings on GitHub were used at compile time. This probably means in its current form, Visual C++ 2010 runtime should be installed for NetHelper to work properly.

Are you able to load Outpost 2 and NetHelper with OllyDbg attached on Outpost 2 1.3.6? Of course it would require switching the icon. If this is a NetHelper issue, it should manifest in both versions I would think?

I would be in favor of seeing NetHelper recompiled in /MT mode using VS2013 toolset. If we decide to recompile, one of NetHelper's dependencies requires a Visual Studio toolset pre VS2015. See http://forum.outpost2.net/index.php/topic,6067.msg86151.html for details. Not sure how Arklon feels about all this though.

Also, I realized that I failed to upload the version of op2ext we are using onto GitHub with the associated PDB files.  >:( I need to remember to upload this version after we recompile op2ext.

Looks like the following improvements have been identified so far:

 * Improve error message when an ill-formed switch is discovered.
 * Add support for spaces in paths within the Console Mod Loader.



-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: dave_erald on May 30, 2018, 03:57:22 AM
The IP address shows internal regardless of where the folder is, both in .6 and .7
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on May 30, 2018, 02:25:39 PM
I've confirmed the error dialog boxes are present for the 1.3.6 release when loading the game in OllyDbg under Wine. Again, the dialog boxes popup after loading the NetHelper library, and before the game shell loads.

I believe compiling NetHelper with /MT will fix the issue. The toolset shouldn't matter too much, particularly with /MT. It can be upgraded if desired, though use what's convenient if there's an issue upgrading it.

Is there a way people can easily know if NetHelper loaded and is running? I'm wondering if a missing Visual Studio 2010 Redistributable package might cause the NetHelper to silently fail to load. There's a chance this could be affecting people on Windows and we just don't know it.

In particular, if someone is finding the NetHelper doesn't seem to be working for them (possibly evidenced by the displayed IP?), try googling for and installing the Visual Studio 2010 Redistributable Package (https://www.google.com/search?q=visual+studio+2010+redistributable). I'd be interested to know if that changes anything.


Sounds like you already have a plan for the other issue.
Title: Re: Updates for Outpost 2 1.3.7
Post by: dave_erald on May 30, 2018, 11:16:00 PM
I got Visual Studio '15 loaded already. And trying to run this it just says I have a newer version and to piss off.

No dice
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on June 01, 2018, 01:56:55 AM
Dave, We would have to compile it using Visual Studio 2013 or earlier due to one of the dependencies requiring the older tool chain. Unless you change out the dependency, Visual Studio 2015 will not work. This weekend I'll look at coding fixes for the issues with op2ext and posting a hotfix. After that, I could take a crack at compiling NetHelper with VS2013 as I have it installed. I looked at it briefly and received a single compiler error but haven't researched it to see the feasibility of working around it in VS2013.

Once we solve these issues, we will need to decide how to release them. Do we want to bundle this all in Outpost 2 1.3.8 or do we want to call it Outpost 2 1.3.7a, or some other solution?

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on June 02, 2018, 08:23:40 AM
It's a small update, so I can see wanting to keep the same version number. Though it seems a bit improper to track changes with endless suffixes. Or at least if you do that, you're not following Semantic Versioning. Technically, our bigger updates should change the middle version number, and small bug fixes like this should be changing the last digit. We've just only ever changed the last digit. If you want to switch to a more proper release versioning scheme, I'm willing to support that, in which case the fix would be released as 1.3.8.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on June 04, 2018, 02:34:50 AM
Hey everyone,

I wrote and tested code re-allowing op2ext ConsoleModuleLoader to support paths with spaces in them. See https://github.com/OutpostUniverse/op2ext/pull/2 for the source code modifications and technical details. I'll leave this up for a bit to allow others to comment on the solution before posting the compiled dll here for testing.

I spent some more time trying to compile NetHelper with static dependencies. See the warning and error code below. I believe the problem is one or both dependencies of NetHelper are compiled as /MD (Multi Threaded DLL). In order to compile the NetHelper dll as /MT, I think you would probably need to get static compilations of both dependencies? Below is a link to an article discussing how to override the warning that may also fix the Error? Although I'm not sure this would be smart.

Warning   LNK4098   defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library   NetHelper   

https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4098?f1url=https%3A%2F%2Fmsdn.microsoft.com%2Fquery%2Fdev15.query%3FappId%3DDev15IDEF1%26l%3DEN-US%26k%3Dk(LNK4098)%26rd%3Dtrue

Error LNK2005 _memmove already defined in LIBCMT.lib(memmove.obj) NetHelper C:\ . . . \NetHelper\src\MSVCRT.lib(MSVCR120.dll)

Anyways, I don't plan on changing out dependency versions. This is Arklon's wheelhouse.

Hooman, in regards to Outpost 2 versioning, I think it would be smart to switch to semantic versioning. If we end up messing with NetHelper, updating the internal version number of Outpost 2 seems like a must to me. This would prevent people from going through the woes of trying to create multiplayer scenarios with differing versions of NetHelper and op2ext.

The other part of that discussion is how we want to handle patch related releases as opposed to larger releases. This release will probably change about 3 files in the release which I suppose should be scanned for viruses and checked for reasonable compatibility with Wine.

Do we want to tag a new patch version in SVN and then commit a version of Outpost 2 with the older icon for OllyDbg use? Or we could just commit the changes to tag 1.3.7 and not support OllyDbg for the patch change. Besides the extra work, the downside of tagging each patch is we start to bloat the repository size (I think, maybe not???).

Dave, if you are still reading this long winded post, thank you for posting the bug in this thread as opposed to the news thread announcing the release. It makes for a much better official release thread to not be posting long bug related testing.

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on June 04, 2018, 12:02:16 PM
We don't need to do the icon thing every little release.

Ideally we should find a way to get a nicer icon without having to edit the exe file. Maybe we could use a shortcut with an updated icon? That might reduce future work when creating releases.

An extra tag won't bloat the SVN repository, since it's just marked as a copy with a new name. There is no duplication of files on the server. However, the working copy will get bloated with extra files. It won't need to download all of them, since knowing they are a copy means they can be copied locally, but they still take up extra disk space, assuming you've done a full repository checkout. In short, don't worry about making new tags when making new tags is warranted.
Title: Re: Updates for Outpost 2 1.3.7
Post by: leeor_net on June 04, 2018, 06:23:12 PM
I can accept including the new icon as a separate file and providing a shortcut with the new icon. Unless we can somehow pack it into the end of the exe file but I don't know if Windows would know to look there?
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on June 05, 2018, 02:36:57 AM
Attached is the new op2ext hotfix and debug file. It allows placing Outpost 2 in a directory with a space in it without giving the error and disabling the console mod loader. I was hoping someone could test it out on Wine to make sure I didn't break Wine compatibility. I've already tested it on Windows 10 but if someone wants to test it on a different computer it wouldn't hurt.


I think we are moving backwards if the icon isn't included standard embedded within the executable. I would prefer it not be a shortcut only.

Perhaps a better solution is to leave the old icon in the repository and just inject the icon into the executable as part of the release cycle. This would allow OllyDbg to be used at any commit in the repo and the flexibility of the icon being imbedded in the release executable.

Perhaps we could write a batch script that automatically updates the icon when run to simplify the process. It might be possible to auto-inject a new version number inside Outpost 2 as well. But considering how infrequent the releases are it is probably more efficient to just manually update.

Hooman, thanks for clarifying on how tags works in SVN. That makes since that it is just a marker to a revision in history.

-Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on June 05, 2018, 11:19:07 AM
Yes, "someone" ;)

I just confirmed the update works under Wine. I also confirmed it fixes the problem with launching the game with a space in the path under Wine.

There's still the outstanding issue of the error dialog boxes under OllyDbg, which is likely related to NetHelper compile options.


I'm curious why you feel so strongly about the icon being embedded in the exe. Is that how you normally launch the game?

Maybe there's a way to add the resource to a new section after the other sections.

I do rather like the idea of the release embedding tool, with possible version string update support. Though you're right, it'd be effort to make such a tool, and we don't release all that often. Might be best to just handle things manually for now.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on June 09, 2018, 01:01:30 AM
Hooman, thanks for testing. I can just ask you to test in the future. I keep expecting someone else with Linux to suddenly scoop you on testing something.  :P

I got around to checking out the external IP issue. When creating a TCP/IP game, I am seeing my internal IP address. This is despite having Microsoft Visual C++ 2010 x86 Redistributable - 10.0.40219 installed on my Windows 10 computer.

Although it would probably still be smart to install Visual C++ 2010 x86 Redistributable when using NetHelper as I don't know if it affects any other part of NetHelper.


I'll plan to push the new version of op2ext to the svn repository. Does anyone plan to work on NetHelper, Evacuation Under Fire's Garage Issue, or any other not yet mentioned item in the near future? If not, I will add a bug report to the change log for NetHelper and EvacuationUnderFire.


Hooman, yes normally launch the game by clicking on the executable. I would open the game is by searching for outpost in the lower left corner of my computer, but I typically have several versions milling around my computer and it would probably pick the wrong one. Maybe the shortcut would also show up there and maybe I am in the minority? It just seems to make sense to me to embed icons instead of linking to a separate file.

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on June 10, 2018, 12:40:07 PM
I just figured most people would use a desktop shortcut, and the shortcut could get its own icon.

I don't use a desktop shortcut, but then I also have an unusual setup, with multiple copies of Outpost 2 to work on. Usually I open the game using the previously opened file list of OllyDbg, so I see it based on path rather than icon.


I checked the NetHelper source, and it does indeed have code to modify the IP address display and show the external IP address. I wasn't previously aware it did this.

As a side note, previous versions of the OP2 SDK used a custom C-RunTime to produce smaller DLLs. I think older versions of the compiler were worse at stripping out unused code when linking libraries, so even a do nothing DLL could end up being quite large. To compensate, the SDK used to be shipped with a minimal CRT library that allowed output DLLs to be about the same size as those shipped with the game. When we upgraded to a newer version of Visual Studio, the older CRT wasn't compatible, though the stripping of unused code was better, so we got rid of the custom CRT.

Sounds like the issue with the NetHelper dependency is similar. I'm a little rusty on the topic, but I remember there being some decent documentation about custom CRT libraries.


If Evacuation Under Fire's code was up on GitHub we could potentially open an issue for the project concerning the garage bug. That might be a decent way to track it.

I should take another look at that, now that I've documented more of the crash point.
Title: Re: Updates for Outpost 2 1.3.7
Post by: Vagabond on June 10, 2018, 08:02:14 PM
Hooman,

I'm fine with migrating Evacuation Under Fire to GitHub. It would be the first actual mission file to make it out of SVN.

I do not have the skills to maintain the SVN commits when transferring to Git. If you want to do the work on this I don't mind. I could handle re-hooking the submodules to the scenario after uploaded. It also contains odasl.lib and I don't remember what the decision on whether we wanted that file on GitHub or not?

If people are wanting to go the icon shortcut route, maybe someone could post a modified exe that works with OllyDbg with a paired separate icon and we could play with it to see how it feels. I'm guessing Outpost2.exe would contain the embedded icon, so I'd assume this wouldn't get in the way of the shortcut's separate icon?

Thanks,
Brett
Title: Re: Updates for Outpost 2 1.3.7
Post by: Hooman on June 11, 2018, 02:07:22 PM
Perhaps I could dig up my old notes on the repo migration. I don't remember odasl.lib being a problem file, and it's probably not if it's an auto generated linker file.

The bug might actually be in Outpost 2 itself though.