Recent Posts

Pages: 1 [2] 3 4 ... 10
11
Outpost 2 Divided Destiny / Re: Outpost 2 for macOS Updated
« Last post by Datan0de on February 15, 2018, 03:13:33 PM »
Could someone please post instructions on installation? Getting permission errors that don't quite make sense to me.

Currently on Sierra, I'm able to open the executable, which is a Wineskin app, then click Choose Setup Executable, but I just can't select the .app file. If I Expand the Package and go inside and choose drive_c/Outpost2/outpost.exe, I get "ERROR! cannot write to Info.plist, there are permission problems, or you are on a read-only volume. This cannot run from within a read-only dmg file." I'm not running it from inside the dmg file. I checked the Info.plist file and it has all permissions I need.

For what it's worth, I'm having the same issue. I was sooooo looking forward to revisiting New Terra!

./Datan0de
12
Computers & Programming General / Re: Embedded File Resources on Linux
« Last post by Hooman on February 14, 2018, 08:10:49 PM »
Hmm, good question.

There is a relevant looking article on StackOverflow about Embedding Binary Blobs Using GCC/MinGW.

The solution looks compiler specific, though this likely will be. The Microsoft resource compiler is of course a compiler specific tool. I'm not aware of any standard C++ language features that let you directly include an external file and make it accessible in memory through a symbol name. I know the NASM assembler has such a feature built in. Futher, NASM is cross platform, so it's likely such features could be implemented on multiple platforms. It just seems like the tooling is fragmented here, so you'd need to do it a different way for each platform, or rely on external tools, such as NASM, or possibly have a converter the builds a C++ byte array out of the file, effectively converting the binary data to C++ source code.
13
Computers & Programming General / Embedded File Resources on Linux
« Last post by Vagabond on February 09, 2018, 08:56:33 PM »
I am curious, are file resources (such as embedding icons and string resouces in an exe or dll) an accepted practice on Linux as it is on Windows? I'm not a Linux user.

If so, is anyone aware of a nice cross platform way to access a resource from C or C++?

Thanks,
Brett
14
Projects / Re: OP2Archive (Command line extraction and creation for .vol and .clm files)
« Last post by Hooman on February 07, 2018, 04:22:54 AM »
Quote
I think right now I am approximating an Invariant Culture (English language w/o an attached culture/nationality) search. However, it doesn't handle letters with accents properly. I could have OP2Archive refuse filenames containing characters past ASCII decimal 126. (https://en.wikipedia.org/wiki/ASCII). This would reduce the chances of anyone finding a way to break the sort with random untested characters. Probably good enough. I could document that it is an approximation in the readme as well.

From my brief debugging session, it didn't look like Outpost 2 tried to do anything special with accented characters. The code path that was actually used only took special consideration for the 26 uppercase characters.

Quote
Hardcoded was a bad word choice. I meant I would put the location in a settings file/resource and allow the user to specify its location on initial install.

And where would the settings file be located?  :P

I think the resource idea would work well. Might be able to use a MemmoryStream to load from a resource. Though ideally we should look at making the create function static. That could get a bit messy from what I remember of my code.
15
Outpost 2 Update / Re: Updates for Outpost 2 1.3.7
« Last post by Hooman on February 07, 2018, 04: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.
16
Outpost 1 & Outpost General / Re: Outpost 1.5 Download & Run
« Last post by leeor_net on February 06, 2018, 07:38:21 PM »
Meh, it just emulates a machine and the DOS internals -- FreeDOS is a good alternative, I'm not sure there's any IP infringement going on with DOSBox and if there was I'm pretty sure Microsoft would have shoved a Cease & Desist up someone's ass by now Hogwarts Style:


I tried to get Windows 3.1 to work on VirtualBox... and it works. Sort of. Performance is actually really really bad -- a bit of research shows why, VB isn't intended for anything less than Windows 95 to run in. -_-

I'll try to work with the current emulation package and see how I can streamline it and get it working better on shitty budget friendly CPU's. :)
17
Outpost 2 Update / Debugging problems with NetHelper on closing Outpost 2
« Last post by Vagabond on February 06, 2018, 12:33:58 AM »
Everyone, and probably Arklon most specifically,

I'm looking for some help with NetHelper. It is giving me a lot of problems when I close out of Outpost 2. Sort of three things are going on:

  • Using the new version of op2ext that I have compiled, it takes an exceptionally long time to run through NetHelper's DestroyMod function.
  • NetHelper cannot be compiled using Visual Studio 2015 or newer. (This one is solved, but should probably be fixed in the code base at some point)
  • When testing a newly compiled NetHelper DLL using Outpost 2 1.3.6 as tagged in the Outpost2SVN, an unhandled error is thrown when shutting down Outpost 2. Whoever updated op2ext for the 2.3.6 release of Outpost 2, only place the updated version of op2ext.dll in the trunk and didn't clean up the tagged release on SVN. This section doesn't apply anymore.



Exceptionally long time to run

Using the newer version of op2ext, NetHelper's DestroyMod function is taking about 3 minutes to execute.

Within NetHelper's DestroyMod function, the following line takes about 21 seconds to run in either DEBUG or RELEASE mode:

Code: [Select]
WaitForSingleObject(hFwdThread, INFINITE);

Then the following line takes about 2 minutes, 42 seconds to run in either DEBUG or RELEASE mode:

Code: [Select]
for (int i = startPort; i <= endPort; ++i) {
    forwarder.Unforward(true, i);
}

I also verified it took about 3 minutes for Outpost 2 to close out without any debugger attached. When closing out of Outpost 2, from within the task manager, Windows moves Outpost 2 from the applications section to the Background application section, where it remains for 3 minutes.

So, I don't know if there is a problem in op2ext that is somehow affecting NetHelper's destruction time, or if there is a problem in NetHelper making it take so long to unload. To troubleshoot, I tried to compile a new version of NetHelper in order to get a PDB file to step debug through. See below.



Net Helper cannot be compiled with VS 2015 or newer

I wanted symbols (PDB file) in order to figure out why NetHelper was taking so long to destroy. I first attempted to compile NetHelper with VS 2017. However, I received errors caused by Microsoft making breaking changes to their toolset in the header stdio.h. This change was introduced with VS2015 and it looks like NetHelper was compiled with the Visual Studio 2010 (v100) toolset. The problem is these changes are inside the library file for miniupmp. So it cannot be used when compiling NetHelper with a toolset later than the one that ships with VS2013.

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.

So, this really isn't a problem right now because Microsoft allows downloading toolsets back to VS2010. However, for the long term health of the project, should probably be corrected. Just wanted to bring it up.



NetHelper throws an unhandled exception when closed using Outpost 2 1.3.6

Now that I had a version of NetHelper with symbols, I placed a releaseMinSize version of NetHelper that I compiled with VS2013 into Outpost 2 1.3.6, as seen at the repository here: https://svn.outpostuniverse.org:8443/!/#outpost2/view/head/GameDownload/Outpost2/tags/Outpost2-1.3.0.6-OPU. I did not change out op2ext.dll.

I was trying to step debug through the DestroyMod function. However, the function MemPatch::Disable throws an unhandled exception before the breakpoint in DestroyMod runs. I'm suspecting that DestroyMod isn't being called for some reason, but I'm not sure how to verify this. Below are the details of the exception.

... Doesn't matter anymore ...

When testing using the new version of op2ext that I have modified, DestroyMod is being called before the MemPatch::Disable function in NetHelper. I also remember there was a point in time when an outdated op2ext was released with Outpost 2 1.3.6 that was later fixed. So, perhaps the tag for Outpost 2 1.3.6 in the repo still has the older version? How can we check this, and if it isn't the problem, is there a way to test if this fatal error is occurring on shut down on the currently released version of Outpost 2 without symbols (since we don't have them)?




Okay, so I don't want to release the new version of op2ext without making sure it plays nice with NetHelper. But I've sort of hit these 2 roadblocks. I was hoping for some help moving forward since I don't really want to jump in and modify NetHelper code as it is Arklon's project, and I'm no good at networking anyways.

Update: It takes my computer a long time to unload/destroy the NetHelper module using either the version of op2ext.dll shipped with version 1.3.6 (the second version of op2ext.dll shipped with 1.3.6), or using what I'm calling op2ext.dll 2.0.0, for release on version 1.3.7 of Outpost 2. Hopefully not too confusing...

So, is it intended behavior for NetHelper to take this long to exit?
18
Quote
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.

Thanks for putting time into researching this.

I think right now I am approximating an Invariant Culture (English language w/o an attached culture/nationality) search. However, it doesn't handle letters with accents properly. I could have OP2Archive refuse filenames containing characters past ASCII decimal 126. (https://en.wikipedia.org/wiki/ASCII). This would reduce the chances of anyone finding a way to break the sort with random untested characters. Probably good enough. I could document that it is an approximation in the readme as well.

Maybe a more correct solution would be exposing the Outpost 2 sort code and statically linking against it. Not sure this is really a possible solution though.

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

Hardcoded was a bad word choice. I meant I would put the location in a settings file/resource and allow the user to specify its location on initial install.

I want to learn more about resources, so I'm leaning towards storing the templates as resources attached to the executable and foregoing the installer.

Quote
Of course this problem stems from building on badly structured code that I wrote.

The code reconstructs an undocumented custom archive format that includes compression. And I was able to follow what was going on as a new C++ programmer. Maybe not perfect code, but I count this as a big win.
19
Outpost 2 Update / Re: Updates for Outpost 2 1.3.7
« Last post by Vagabond on February 04, 2018, 04: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
20
Outpost 2 Update / Re: Updates for Outpost 2 1.3.7
« Last post by Hooman on February 04, 2018, 03: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.
Pages: 1 [2] 3 4 ... 10