Ssnake

If it can't be found in your spam folder immediately after the purchase, it's rather unlikely that it will appear there. Rather, it's usually being held up by the shop software (as explained above). But we regularly check for torsos clogging the chute, and then Leroy will pry them loose with his digital broomstick. Artist's rendition:

In cases like these, it's best to contact Shipping (@eSimGames); that being said, since we switched from our own web shop to that of a web shop company, there's a fraud prevention mechanism that, for example, triggers whenever someone's IP address is from a different country than the billing/shipping address; this could indicate something fishy, but usually it's quite harmless - when customers use a VPN gateway while ordering. As a consequence, a human must authorize the execution of the purchase, and we only have the time to do this maybe two to three times a day or so (we have no full-time employee to tend this web shop exclusively; Steel Beasts isn't that popular). I'm not saying that you shouldn't alert us early. When there was no such fraud prevention mechanism in our web shop, a delay in the delivery of the license did, indeed, signal some sort of a problem. As explained above, these days it happens more often but usually for inocuous reasons; so, keep calm, send us an email, then carry on. Eventually the email with the license ticket will arrive, or we will send you an email telling you that we just refunded your money for some reason.

We need to differentiate between Callsigns (that's what's exposed in the UI and in the dialog mentioned by Mike further above), and CombatantIDs (which is what Steel Beasts internally uses). Dupicate Callsigns are bad for users, but as long as the CombatantIDs are unique, no problem for Steel Beasts.

We cannot rule out (at this point) that they have a similar problem with unit IDs. If that user happened to be the only one to interact with a unit with invalid ID, it may be coincidence. Or we're dealing with more than one issue, that certainly is also a possibility.

Invalid combatant IDs are a bit of a lurking horror just beyond your peripheral vision. Things can go about normally for a good while until there's some form of an interaction with them that changes their status (like, shooting them, or a collision damage). Once that this happens, the wrench is thrown into the gearbox with the associated "funny effects".

Discord, maybe?

In what way do you not get the multiplayer thing running? Did you try the Search function on this forum? Chances are, you aren't the first for whom this question came up (and was solved here).

You have mail.

I don't know if T, used from the CDR's position, really helps to make the AI GNR switch to the new target; its original intention was for the gunner to temporarily "stun" the AI CDR's attempts to redesignate or to change to a different target right in the middle of an engagement. But if it helps, maybe something happened in the last years that I missed, so I guess it's worth trying out. It may however just as well be that the fact that you're overriding the gunner and take the time to press T gives him that one extra second to recognize the new target in his sight, and simply switches to it because the intent is now clear. A super-quick target handover might fail if the gunner doesn't "see" the new target, and "because there isn't anything here" goes back to the location where he knows enemy to be hiding.

FWIW, I've filed a Bugzilla entry (#11621) to allow the human Bradley commander to override the AI Gunner with launcher control.

Okay... it's a point.

It was designed to be one, but the customer never really followed up on it after delivery. Other than your emotional discomfort (and I'm not mocking you), I really see no disadvantage in the AI always having the launcher ready. It's no impediment when vacating a position, and it's better to have it ready "just in case" than being surprised by needing it, and then having to wait until it's in position. 10 more seconds of exposure, plus missile flight time.

Yeah, N means "lean forward" in 3D interiors, where "forward" is the direction in which you look.

We're designing the crew AI on the assumption that there could be armor threat anywhere, anytime, so they will make the launcher ready. Also, we want to keep the number of hotkeys and GUI complexity at a manageable level, so I'm inclined to say that we're not going to do it. The benefit of your ease of mind does not outweigh the disadvantage for thousands of other users.

The first error message, failure to rread a scenario file, indicates a different problem. The file path looks very long. Note that white Windows since version XP supports 256 characters for a file name, this includes the whole path. So, it may simply be that the scenario just exceeds that limit. Or, your current user account has no access rights to that folder (maybe the files still have ownership by a previous user account). Or, the file is corrupt (less likely, but it does happen). And then, like Gibsonm wrote, if you the scenario was made in a newer version than the one that you have installed, there would also be this error. The debugLog file might list the exact reason why it failed to open.

Older (prior to version 4.1, 2019) scenarios will require some map conversion work. We created a help thread for this (and there's also a section in the User's Manual about it, in the Map Editor chapter): Also, this:

How do you know that you're only facing infantry?

We considered that option, but felt that it might be too much of a deterrence to, effectively, force the user to become competent with every single vehicle, or face the consequences. I'm fully with you on this - from a the point of logic/internal consistency this would be the way to go. But, well, not everybody is a full-on tank nerd. Some may want to use Steel Beasts as some sort of a real-time war/strategy game. We don't want to penalize people if they have only limited interests in fire control system intricacies, so that's why we simplified it.

I agree that the described symptoms suggest that there was NO disconnect between Host and Client. Having a look at the debugLog.txt of that session (search for "ERROR") might yield a clue (you should make a backup soon after such a session, and if you have several of them we can start looking for identical event chains in them). Steel Beasts keeps the last 12 copies in the logs folder, but of course at some point the oldest ones get overwritten. If the whole issue always happens in conjunction with "network overload", well, there isn't anything that we can do except recommending that you run sessions with fewer clients. Once that network packages are lost, all kinds of "funny stuff" may happen.

Yeah, CodeMeter-protected applications are partially encrypted, which can trigger relative simplistic heuristics. A lot of malicious software is encrypted to protect against AV scans ... so the logical fallcy is "if it's encrypted, it must be a virus"...

If a network game experiences an interruption in the connection between Host and Client, Steel Beasts switches into single player mode to allow you to continue playing. Of course, from that moment on it's two different games. If you are on Teamspeak and the voice communication is not interrupted, and if the enemy is scripted and it's some sort of a cooperative session, I can see how the "seamless disconnect" (which we thought was a nice feature at a time (ca. 2000) when internet connections were still less common, low bandwith, and generally unreliable) would go unnoticed, and could then create the impression that it's a serious bug when the sessions are drifting apart and you suddenly feel like you were in the Twilight Zone.

With version 4.1, we changed the underlying network library. This eliminated the need - to have the entire range of ports 2300...2400 open; now, only the HOST needs to have only port 2300 exposed; - to have port 47624 open ... this too is no longer needed (at least that's my understanding of it)

Alt+J (or was it Shift+J?) inverts the Y axis (the other recenters a driftig stick signal).

a. We do not comment on future feature development b. As a general rule, a specific weapon system gets added when a number of conditions apply simultaneously, - allocated development time - access to the system/permission to create a model of it. These two conditions align easiest if there's a military customer who wants it in Steel Beasts. It's not the only way how this can be done. The number of examples is bigger than the number of vehicles made for Steel Beasts on military request. Still, (legal) access to the vehicle or at least its documentation is an indispensable prerequisite.

The Ulan IFV has an Elbit fire control system which may show some similarities to that of some Merkava variants. The MiniSamson remote weapon station is from Rafael, the E-RCWS is also basen on Elbit technology, there's the Spike missile. All can be directly controlled by a human player. Beyond that, I have answered all your questions twice, on Tanknet, and by email.