- User Since
- Aug 12 2017, 8:45 PM (184 w, 5 d)
Tue, Feb 23
Sun, Feb 21
== "D:\Games\ArmA3\A3Master\arma3server_x64.exe" "-profiles=D:\Games\ArmA3\A3Master" -client -connect=18.104.22.168 -port=2302 -password=**** "-mod=
This looks like a headless client rather than the master server.
Also: ACE looks pretty weird with this "obfuscation" - don'T understand why this is even a thing in the modding community ...
Well, as pointed out: This is only a feedback tracker meant for reporting serious bugs, logic errors, and put feature requests. What you encounter is for support - so it would fit way better on the community forums, the steam forums, or maybe even reddit. Posting your issue here is just the wrong spot for it.
This tracker is for some like "I found an issue in campaign east wind, mission 3 on altis, where this and that should happen - but instead X happens" - but not what you reported. You encounter some launch issue caused by some weird setting or launch option - maybe caused by some file loaded along with normal game launch. So you need support - that's nothin for this tracker, hence many post such issues here don'T get any reply at all.
So, what could cause such? I don'T know - as Arma3 still quire LOTs of work although it's released back in 2013.
As for your "fix the game" - well, that'S what steam tries to implement with its "verify game files" feature - but this only works as long as the root cause can be fixed by such action as restoring the default data. But as arma3 was developed with custom content in mind it does search for quite a lot of additional files in lots of locations that are not covered by steams feature to check the integrity. Maybe it'S some weird registry entry somehow checked and executed by the startup code - but as only very few is documented public without knowing the exact stack that lead to this point it's extremely hard to nearly impossible to figure it out - let alone only communicating through this site - and quite bad english from both of us.
have you subscribed to anything in the workshop?
Well, you may can try this:
- clean local appdata: c:\users\<yourusername>\appdata\local - and delete both the Arma3 and Arma3-Launcher folder
- clean documents: c:\users\<yourusername>\documents - and delete all Arma3 folders
Although this is a feedback tracker to report bugs and make requests and not a support forum (that's what the regular community forums, steam foums and maybe even reddit are for): As from another topic: What happens if you double-click the arma3(_x64).exe in the arma folder directly instead of using the launcher?
That sounds very weird - as such an issue caused by the model of the house? Strange ...
Well, ok, it may be an issue with some transparency with the door frame make the unit inside invisible. But the bugged menus? I'm not sure how that could be specific to a building object model - unless some issue with the bounding box (which comes up a lot even on normal server-/game startup - so I guess there're in fact quite some bugged models).
This looks more like an issue caused by the mission itself depend on some other stuff rather than some issue of arma3 itself. Try to contact the mission author or google the base class name.
Sat, Feb 20
that's some really weird bug you got there - would like to know what causes it and how it can be fixed
I noticed quite a lot of issues while playin both the official campaign and custom missions (mostly altis life) - but what you got there - wow, quite a lot has to go wrong in a specific order at the same time to cause that ...
Wed, Feb 17
You quite obviously didn't got the point at all - but, where should I start?
That weird date format in the bottom right corner? A DxDiag representing its OS as english but then lists quite a lot of german? CloneDVD - something used - IDK - about a decade ago? Doesn't really look legit to me ...
This list of "potential pitfalls and causes" is quite long about "hmm - I only get this issue with arma but nothin' else". Sure, maybe true, and maybe steam thinks all the files match their checksums and hence responds with "all fine" - but just give a thought: "I have some weird issue" and "all is fine" just doesn't add up. And even with all the stuff provided to tinker around to MAYBE figure what MAY could cause your issue - most we can do is just guessing. And yes, maybe you have some neat new hardware under your desk - but that doesn't mean it can't be faulty. I myself use a bad RAM stick for couple of years now - and it sure does bite me in the ass if I access that very spot which unfortunately gets me back some faulty data - but sometimes it's just a matter of "well, that 0 should had been a 1" and "omg - my system is going haywire". So, why you start that fight? I tried to help - and all I get back is some FLAK cause I throw in a few jokes between the lines cause you're using some not so legit stuff that is known for causing exact that kind of issues you experience? WAKE UP KIDDO! If you ask for help and expose yourself to use some not-so-legit stuff - accept you get mocked for it.
Well, just from looking at the few interesting lines I have quite a few ideas what might could be wrong not just with your game but with quite a lot of other stuff, but as I have to trust your reply that "everything is fine": to me the logs don't add up with that statement. If you experience this with arma only the one plausbile cause left is: there's something wrong with your data - either the game files itself - or the stuff you try to load into. Otherwise, if someone would rule out that cause, it's most likely some weird hardware bug, or maybe some of the junk you have on your rig (be surprised by what a simple dxdiag can reveal to someone reading it carefully).
All working perfectly fine but only one application having such weird issues? Nah - doesn't add up well ...
Without any look at the logs this sounds like a hardware issue to me, maybe some bad ram or anything else attached to the board. Give good old memtest a try and have it run at least once the full set of tests. If memtest doesn't show any errors even on multiple runs could be many things from dying/already broken cpu/gpu/hdd/ssd to just corrupted data fixeable by game file validation via steam.
Tue, Feb 16
can you provide logs without mods loaded?
Sun, Feb 14
Many thanks for that reply with some inside information on what actually happens when #shutdown command is called.
I really much appreciate you even take time to look into it although it doesn't seem to be something caused issues in the past. So I fully understand it to be some very low priority, and maybe it only gets fixed "along the way while fixing other issues".
Although I didn't repeat it for all the tested systems from a short test on my main server it seems the issue is the same for the regular x86 binary.
I also tested this issue on several other environments:
- gentoo (at least I tried - but compiling the kernel from scratch just took too much effort and time)
- slackware (from which opensuse descends)
All environments showed the very same issue. As I reported this to the ones I asked for testing my short code they agreed upon that if an issue is exactly the same on so many so different styles of linux mainline distros it's most likely the application causing the issue, although without having a look into source noone is able to confirm or deny on that.
I'm sorry I didn't tested on windows or even try some stunt with the DotNET framework - but as my extension is only meant as a small connector to a java backend using some plain sockets for brdiging the gap between SQF and my backend, and it's meant to run on a linux server, and as just setting up the required dev environment to build a small DLL - I just didn't put in the effort. Also, as you mentioned: it does work on windows.
Thu, Feb 11
Thank you once again for having at least a look at it.
As promised, I tried to use clang - but, unfortunately, result is the same.
Thank you for your reply.
As one can see, my code does contain a destructor. I also had it tested by some C/C++ devs that it gets called correctly when dlclose() is called. So they suspect that the server shutdown just doesn't call dlclose() on loaded extensions.
I was also able to find another source which mentioned, that dlclose(), according to POSIX standards, is only required to invalidate the given handle. So it's up to runtime if a call to dlclose() actually calls an maybe existing destructor. This source also mentions some difference between using gcc vs clang - but I haven't tried using clang yet, as I just read about it after your reply.
So, the question to the devs is: Is dlclose() called on loaded extensions during shutdown and if it's maybe my way of creating my extension or even my runtime I execute it on to cause my issue, or if the shutdown just doesn't call dlclose() at all.
Anyway, I'll give it a try to use clang and see if this makes any difference. I'll report back after testing.