thecodemonger

This was determined to be an issue with the ArmA engine restart system being essentially broken when using mods. I've settled on using the shutdown command and the time array with a simple pgrep bash script (below) to make sure the server stays running. It's fair to mention that I've white-listed my launch script using 'sudoers nopassword' so this can continue to run hands-free - as per the purpose of this exercise. Doing it this way allows me to change shutdown frequency exclusively in the mod scripts, and not have to update a cron tab. Thanks for chiming in Chris @infiSTAR - it's always greatly appreciated! -TCM

I considered it, but past experience tells me I'd much rather just have it working in-process for the sake of minimizing downtime during restarts and overall ease of maintenance. TSWR:

Ok, so after some time away, I've come back to arma 3 for some exile and zombie action. So I went ahead and started with a fresh rebuild of my old server, got exile working, the RZ&D, adv. towing, DMS, and finally infiSTAR. Initially, it was working fine, but then as one of the final adjustments I set up the infiSTAR restart system using the fixed time array. The server runs fine, everything works great - until the restart, which ends at the following point in the process per the logs: stderr from the point of restart initialization: stdout: Note the partial line output where the server crashes. I imagine this is a threaded operation, and not completely relevant. Potential stderr anomalies or useful info from initial launch: System Information: I can provide additional snippets if requested. As a general rule and for fairly obvious reasons, I'll only post infiSTAR snippets if asked for by Christian. As a professional developer, I'm all too familiar with the, "It's not my code, it's your implementation" defense, and I'm plenty willing to concede that point if it's actually the cause. That said, everything seemed perfectly fine until I implemented the restart system. That is - no 'unusual' warning/error messages in the complete error log (see above). ArmA scripting isn't my day job though, so here's hoping you folks can spot something I overlooked. Thanks in advance for any assistance. -TCM UPDATE#1: ANY combination of restart/shutdown whether timer or time-based produces this same 'String id' error followed by server crash. UPDATE#2: I decided to try eliminating other mods as the cause of the issue by setting up a vanilla exile server with infiSTAR only. Interestingly - it too produces the exact same string id error. I'll try Exile only and send it a shutdown command without using infiSTAR to see how it behaves.

I'm not new to coding (it's my day job, actually), it's more a matter of still getting used to the A3 script structures - suffice to say there are no missing semicolons. Those type errors tend to keep the server from running at all. We did fix an issue in the cfgBuildings class however, where the class was erroneously closed '};' halfway through the list. I cleaned that up and removed any duplicates. When I started seeing issues with loot on the map it did make me wonder if the devs had to jury-rig something elsewhere in order to get the rest of the building loot to work, and that my 'fix' could be a part of the issue... I did want to post about that in the 'ask the devs' section, actually, but having not had to ask about much here in the forums up to this point has my post count a bit on the low side for that just yet. As far as the logs, I do see a number of 'strange convex component' notifications and 'podesta_1 config class missing' type errors on server load, but it's my understanding that these are in fact 'normal'. We are having a separate issue I'm looking into currently that is generating a lot of 'object id not found in slot' and 'link cannot be resolved' spam in the log, but I'm reasonably convinced this is unrelated to loot spawning and is instead related to the vast sea of supply drops in the southwest corner of the map that aren't de-spawning; see attachment, lol.

That's right, another no loot thread - except it isn't 'no-loot' so much as 'wtf is going on here?' I'm working on assembling an Exile Esseker server with a friend, and we followed this post as a general guideline. We did modify a few steps along the way while we were setting everything up; using A2OP rather than AIA, assembled a list of buildings and loot spawns on our own instead of using Hollow's, disabled loot spawn restrictions around trader cities in Exile.Esseker's config.cpp for testing, etc. At first we thought it was a full-on no-loot issue, then we decided to use infiSTAR's loot esp and broaden the search. After a while we found a few buildings that spawn loot, but it seems limited to specific buildings / locations. Yes, same building class name when compared to other locations, not a _dam version. Confirmed using infiSTAR hud. Can anyone shed some light on what may be going on here or where to look in order to fix this? Can provide code snipets as requested. It's also noteworthy to mention this is on a Linux server, everything is latest version, and Exile Esseker is completely vanilla right now apart from infi. Here are the only buildings we've been able to find loot in so far, and the location they spawn it. Outside the listed towns the buildings don't seem to spawn anything. I'm guessing it could be something to do with defined map/town/trader areas, but we disabled spawn restrictions, so I dunno - I'm still learning some of this stuff, heh. Thanks in advance to anyone who can provide useful direction or feedback. -TCM

Hello Chris, I'm the dev for the server in question here. To answer your question, she is referring to a3_infiSTAR_Exile.pbo needing to be renamed as a3_infistar_exile.pbo for linux. We have since went ahead and updated everything on the server so it is now 1.60/0.9.61. Additional mods in place: The infiSTAR scripts now initialize properly and I removed the allowance for 158. The problem we're now facing is the following BE Script kick: Adding the following filter to scripts.txt does not help, as if it's being completely ignored: Additional potentially useful information: Hopefully this is enough information to help you find the cause of this issue. If you would like to and/or are willing work with us more directly in resolving this issue, PM Dianna or myself and we can set up an irc/ts/skype/etc meeting. During the course of composing this post however, Di mentioned to me you released an update, so I guess we'll try that and report back with our findings. Thanks again for all the great support you do - it's genuinely appreciated! =) -TCM