Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Outpost 2 Update / Re: Updates for Outpost 2 1.3.7
« Last post by Vagabond on February 04, 2018, 01: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
22
Outpost 2 Update / Re: Updates for Outpost 2 1.3.7
« Last post by Hooman on February 03, 2018, 10: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).
23
Projects / Re: OP2Archive (Command line extraction and creation for .vol and .clm files)
« Last post by Hooman on February 03, 2018, 09:33:44 PM »
Outpost 2 searches the VOL index entries using binary search, comparing strings using strcmp, which is case sensitive. It does a simple binary compare of the bytes, without regards to locale or other special sort considerations. As such, lowercase letters, which have a lower value ASCII code, must be sorted before uppercase letters.

If a different sort order is used, the binary search can get confused when encountering an out of place entry and search the wrong direction. That can result in files not being found, even though they are clearly listed in the index table. And to make matters confusing, the way the binary search jumps around the index table, it can make which files are not found seem random (though it is deterministic for each set of packed files).

I'm afraid you have no choice but to sort all uppercase filenames before all lowercase filenames.

Edit:
Upon closer examination of the code, it seems the function was misidentified as "strcmp". It's actually not so simple. There is a memory flag that controls whether a simple case insensitive compare is used, or a or more complicated comparison is done, which looks like it might remap character codes. Maybe it's actually strcoll, or perhaps _stricmp. It appears the default is a simple case insensitive compare. If the characters are different, it attempts to remap upper case characters so they would compare equal to their lower case equivalents.

I suppose this means there are multiple possible sort orders, depending on the memory flag affecting the compare. That would of course completely break VOL files if it ever changed. As such, I'd go with a function that does a simple case insensitive compare.


Quote
Another way to solve the problem would be to try to eliminate the template files by either somehow storing the templates in the executable or maybe as a resource or something. Or perhaps modifying the Archive code to allow easier creation of vol and clm files without an initial template.

Agreed. These would be better solutions, particularly not needing template files.

I would recommend against using a hardcoded path, even with an installer, as people sometimes choose to install to a different path. Plus it's nice to not need an installer. Hardcoded absolute paths are almost always a bad idea.

Of course this problem stems from building on badly structured code that I wrote.  :-[
24
I realized the sort algorithm I developed for the CREATE command improperly sorts based on letter casing. It places any uppercase letter above any lowercase letter. I must have tested with only lowercase filenames. I developed stole from the internet and then modified a new sort function that ignores case.

I'll release version 1.1.1 soon with the fixed sort command. I'll wait a bit to see if any other changes are noted.

[RANT]This is why I like working in the .net framework. It provides handy functions like string sorting/comparison that I don't have to home roll and figure all the details out about casing or where it sorts letters with accents, or Japanese characters or which localization the sort is performed in or anything else related to the task of sorting that are outside my specialty but pertinent to a good sort. Instead in C++ I either internet search a library to integrate with that performs the task which I'm completely unfamiliar with or search for a single function, then sift through 3 solutions where the authors are arguing about which is more efficient. Guess that is the price of not being attached to the Microsoft ecosystem.[/RANT]



Goof was helping me learn how to add paths to the PATH environmental variable on Windows to allow calling OP2Archive from any directory within the command prompt. This is useful as I was pasting copies of OP2Archive across my file structure to manipulate vol files. However, I still have to place the Vol and CLM template files in the directories I'm working in to use the CREATE/ADD/REMOVE command.

A solution would be to hard code the location of the template files and setup a legitimate installer to handle this. The installer could also handle adding the correct path to the PATH environment variable automatically. And then remove the setting on unistall. I would probably use InnoSetup to create the installer as I've used it with good success in the past. Creating an installer adds a layer of complexity though.

Another way to solve the problem would be to try to eliminate the template files by either somehow storing the templates in the executable or maybe as a resource or something. Or perhaps modifying the Archive code to allow easier creation of vol and clm files without an initial template.

I don't get the impression anyone is currently using OP2Archive besides myself. But if anyone has an opinion on the matter, I wouldn't mind hearing it.

-Brett
25
Outpost 2 Update / Re: Updates for Outpost 2 1.3.7
« Last post by Vagabond on February 03, 2018, 07: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
26
Outpost 1 & Outpost General / Re: Outpost 1.5 Download & Run
« Last post by Hooman on January 31, 2018, 09:23:52 PM »
I've have pretty good success running VirtualBox on that CPU. Modern versions of Windows seems to run reasonably well. I did however upgrade my RAM from 2GB to 8GB. That made a significant improvement, especially with newer more memory hungry versions of Windows, or if I had other stuff open. Nothing quite kills performance like swapping to disk, and yes, I have a regular hard drive in that machine.

I've never tried Windows 3.1 in VirtualBox.

What about licensing issues? I was thinking, with VirtualBox, people generally run legitimate licensed software in the emulator. It sounds like DOSBox has it's own software environment that may sidestep some of those licensing issues. Though I'm guessing that didn't include the Windows 3.1 part, just the DOS part.
27
Just released version 1.1.0 of OP2Archive.

This one changes behavior of created Archives by forcing files to be inserted into the archive alphabetically by filename. Outpost 2 was missing files placed inside the archive if they were not placed alphabetically. Outpost 2 could accept archives not in alphabetical order, but the current code base to write the vol files assumes they are alphabetical. It makes more sense to me anyways that they appear this way when searching through the archives. See link in first post for new download.

Version 1.0.1 (07 Nov 2017)

 * Bug Fix and Feature Change: Sort all filenames alphabetically during CREATE command.
 * Error Handling: Attempting to CREATE a repository that would contain 2 files with the same name results in an error message.
 * Error Handling: Attempting to EXTRACT a directory from an Archive results in an error message.
 * General code cleaning.
28
Outpost 2 Programming & Development / Re: Coding project: Battle of the Blight
« Last post by Vagabond on January 29, 2018, 10:49:27 PM »
I played a 2 player round with this scenario.

Everything seemed to work right. I like that the light towers flash disabled when they are overpowered by their opponents. No bugs noticed.

Exploring the new mechanic was initially fun, but the game languished after that. We each kept building light towers to counter the opponent. While we could disable some, since the blight will not enter the lighted area, neighboring light towers would protect the disabled ones allowing time to shore up that section. So it appeared to be a stalemate that we eventually just ended mutually.

I guess some interesting mechanics could happen end game when you have maxed out your buildings and how you handle stuffing large numbers of convecs with light towers before going over the limit. But we didn't play that far.

Thanks for making it.

-Brett
29
you also can do a cmd file with

Code: [Select]
@echo off
cd C:\Temp
SET PATH=%PATH%;c:\Directory\sub\gitdir
SET PATH=%PATH%;c:\Directory\sub\whateverdir
cmd.exe

When you launch it the cmd.exe at the end inherit the updated Path above (or any other environment variables needed)

Code: [Select]
@echo off
Just avoid the lines below to be displayed.
30
Thanks Goof,

I was adding new environment variables instead of editing path.

With your graphics, I figured it out!

-Brett
Pages: 1 2 [3] 4 5 ... 10