Maraneshi

It should be impossible to even *start* APB on that GPU since it doesn't have driver support for D3D11 nor hardware support for feature level 10_0.

Okay so I feel like I've seen this crash before. It's very bizarre since all it tries to do is create/rewrite the commands.txt file in the documents folder but somehow it can't open the file and crashes. From the dates of the files in the screenshot I can see it was able to open engine.cfg in the same folder just fine. I have absolutely no idea why this would happen. You could try deleting commands.txt and see whether that helps. In case that does not work, I've put in a check so it shouldn't crash anymore when this fails, but I can't guarantee that it won't crash somewhere else later from a similar error because I simply have no idea why this would fail and I'm not very keen on trying to find all the places where we access any files in the engine to try and safeguard them. I don't think I'm allowed to distribute the fix to you individually and you'll have to wait for a new APB patch to be released if deleting the file doesn't help.

So, this is a bit annoying because the game doesn't even get to its crash reporter to produce a memory dump for us to analyze, which leaves us with basically no information whatsoever. You're going to have to tell Windows to automatically generate crash dumps when this game crashes. The process is documented here: https://docs.microsoft.com/en-us/windows/win32/wer/collecting-user-mode-dumps I have made two reg files for you to automate this process (enabling/disabling the crash dumps). disable game exe crash dumps.regenable game exe crash dumps.reg After enabling the crash dumps and trying to run the game you should be able to see a .dmp file appear in the folder %LOCALAPPDATA%\CrashDumps (just paste this into your explorer address bar or manually navigate to C:\Users\<yourusername>\AppData\Local\CrashDumps). If you could upload that file (or a zipped version, it compresses really well), we can at least try to figure out what is going on.

AVG is known to have flagged literal "Hello World!" programs as viruses. If your executable is not signed by a big company and whitelisted it's pure luck whether you get blocked or not.

Betting on anti-virus here too. AVG and Avast (same company) are known to flag our game for whatever reason and shut it down immediately without any notification. Unfortunately we can't really do much about that on our end.

DxDiag shows Win7 SP1. Hardware is very old but barely above minimum target for 5.0 so it should run.

This was for the error in the launcher log. The entire thread has been a bit confusing. I said "if the launcher still does not work", then try that update. Since the launcher clearly works, there is no issue here. I'm still betting on anti-virus.

Have you tried adding the APB game exe as an exception to your anti-virus program (particularly AVG seems to dislike it for unknown reasons)? If that doesn't solve it, what hardware (CPU, GPU) and operating system are you running on?

The launcher already runs as admin (since we haven't been able to decouple the install process yet and it's almost impossible to launch a process with lower privileges from one with higher privileges). Compatibility mode is not necessary. I'm betting on anti-virus blocking it for whatever reason (particularly AVG seems to dislike our game).

Are you trying to connect to the APB server from a Renegade client? APB hasn't been playable from Renegade in a long time. It is a standalone mod on a version of the engine that is incompatible with the original. You need to install APB from our launcher to play APB.

Sorry, I somehow missed this thread. 1. The error log is from the W3D Launcher and it says it can't establish a secure connection. If the launcher still does not work, please update your Windows. https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392 2. The crash dump is from Interim Apex, not APB. Unfortunately the dump doesn't seem to contain any useful information. Does this happen consistently?

My best guess from the dumps is that the game fails to open the following path: "C:\Users\ZOOL\Documents\W3D Hub\games\apb-release\commands.txt" Make sure the path exists, your user account has write permissions and your antivirus doesn't block the game for some weird reason (seems to be AVAST?).

Yeah, we've confirmed that the allied ore truck causes the slowdown in a few cases. However, the root cause of why this even happens is yet unknown. Currently working on finding it by running a server with special checks in place 24/7 and constantly fixing related things but it takes many many hours to do so.

This laptop has an integrated GPU from 2008. I'm surprised it can run anything at all. It straight up doesn't support MSAA.

As I said, they're identical.

My MD5s are identical for all the binaries and data files

I think there was something funky going on with this update because somebody reported two different binaries.zip (same name) files being downloaded and extracted by the launcher.

You do not need a login to join a server. The launcher login is mostly for staff members to get access to test builds.

It might be the game running out of memory, but I'm not entirely sure. Does this crash occur regularly? Can it be reproduced? Otherwise I'm not sure we can do anything since the code shouldn't be able to crash in this particular way as far as I can tell. Unfortunately it's difficult to tell which information in the crash dump is real and which is bogus.

The first crash *may* have been fixed in dev, but we're not 100% sure since we don't know how to reproduce it and it's a pretty complex case of things going wrong when the map is unloaded. The second crash has been known for a while with no known cause. We know it very rarely triggers when you destroy certain vehicles (boats, planes), but we don't know the root cause because the crash happens way later than what actually causes the game to break.

We currently only have the plugin working for Max 2017. Maybe @jonwil could look into how to best compile and distribute the plugin for all Max versions that work with the code we currently have (though testing whether it works is another problem... we can't easily procure and permanently install 10 different versions of Max for testing).

Small note: We now also have basic support for XInput gamepads (e.g. Xbox controllers), mostly intended for people recording videos and possibly for airplanes. Left/right stick axes are hard coded to move and look (because the binding system doesn't really support axes like that), everything else can be bound to actions in the controls menu. Note that "jump/crouch" are turned into analog "up/down" for flying units, so using the triggers here is very beneficial for smooth video recording even if it's unusual for actual gameplay. Airplanes are still a little bit awkward, ideally we'd need separate keybinds per unit type (including axes), but that would require a major rewrite of the input system and menus.

There are literally dozens of different anti-aliasing methods, though most of the newer and cheaper ones operate in screen space after the image is already rendered, which is not the case for SSAA and MSAA. SSAA is the first and easiest to understand since it essentially renders the game at a higher resolution (multiple "samples" per output pixel) and scales it back down to the output resolution similar to how you would scale an image in Photoshop. This eliminates aliasing across the entire image, but is obviously very expensive. MSAA optimizes this method by first testing how many different triangles are intersecting those sample points within each pixel and then only computing the shading for at most one sample per individual triangle. This effectively limits MSAA to the edges of geometry, which is the place where most aliasing happens (especially in old games; unfortunately, during the last 15 years or so shader aliasing became a major problem as well). Foliage, chain-link fences, grates, etc. are usually made using alpha-test textures, which means the geometry edge is not where the visible part of the object ends since it's just a transparent texture on a much larger surface. Thus MSAA by itself will not help with the aliasing here, but there are ways to manually make use of the texture alpha to explicitly tell the MSAA implementation "hey I want this pixel multi-sampled" (this is called "Alpha-To-Coverage"). Both SSAA and MSAA can use different patterns for the extra samples per pixel. A regular grid is the easiest to implement in hardware, but if the geometry edges align with the pattern (i.e. nearly horizontal or vertical lines), there will still be visible aliasing. Thus many different variants were introduced like rotated grids or semi-random distributions. MSAA can additionally vary the amount of samples used for testing how many triangles intersect this pixel (coverage samples) and for computing the actual shading (color samples) as the former are very cheap in terms of performance compared to the latter and can improve the results by weighting the color samples more accurately (examples of this are called CSAA [Nvidia] and EQAA [AMD]). I'm not sure, but that sounds to me like you're reading about the generic theory of image resampling (how to scale an image from one resolution to another), which happens to be the last part of the SSAA/MSAA process. Surprisingly, downscaling is an incredibly difficult problem even though you have all the information available. It's almost impossible to tell which information is or is not "important" to preserve during this process so that the end result neither looks excessively blurry nor has additional artifacts that weren't in the original (e.g. aliasing, ringing). Regular SSAA and MSAA as implemented in the hardware will by default just use a simple average of the samples within each pixel ("box filter"), but some other variants have been introduced over the years as well.

Silverlight - Wins way too many games by organizing his team, even though he sux. 😛 Pushwall - Best Pilot, always knows what to do. SilverShark/Totd - Would be the best player if he didn't care about his K/D so much.

Afaik it's also currently not possible to have multiple of the same production facility, so good luck getting 15 players onto a single airfield.