MDCCLXXVI

hah sweet

AFAIK, that is not quite the same .. Many civ-variant vehicles have a random array of colors/skins. The new setVariable ["color",X]; will merely allow mission makers to select the one they want rather than be beholden to the random selection. honestly unless admins are okay with having 50mb mission files with lots of custom skins (which seems to work on Altis Life), I'd say don't bother with re-skinning stuff. here's something we made awhile back when playing around with setObjectTextureGlobal: https://community.bistudio.com/wiki/setObjectTextureGlobal

3. The Strider variants will work with that camo, the Ifrits will not. That is actually the base skin of the Strider, BIS overlayed the AAF skin afterwards.

thanks! I'll look into it on wednesday-thursday and see if I can't shake something loose. Is there a TS or email I can catch you on? Will be handy to speak to you when I get around to working on that later in the week.

This causes people to grumble when it's implemented. I have tried doing so in the past, including removing thermal optics, and it causes outrage. I think it is too late to implement these restrictions on the playerbase. If it was done around game launch it might have worked. Now, it may just cause people to go to different servers. If server was giving people stable 50-60fps then there would be performance budget for complicated monitoring loops. As it is, monitoring good/bad pilot behavior is quite a performance drain with an already tight budget. Maybe a solution is out there however. re ropes. its my intention to limit the ability to pilot only. I've made a few attempts but given limited time and low priority thing to do, I wont get around to recoding that for a few weeks probably. I have asked the author (zealot) to do it, but no response. edit: I have just had a second look at the fastrope script, and have coded in a fix so only the pilots can deploy/cut the ropes. just depends on preference. I prefer the current requirements and would resist making the job easier. AFAIK the FOBs are not implemented yet. They were implemented in previous dev builds but I did not remove a mention of them in the changelogs. they will be back, and be focal points of attack and defend play. IIRC paradropping was in before and while handy, it demeaned the role of pilots and made transportation feel cheap. It may return in a different implementation, but not in the near future.

Not sure if it's been adjusted on AW yet, but I received a PM from Xeno today: -- This one is a reasonable alternative. http://forums.bistudio.com/showthread.php?163206-Group-Manager ^ It's the 'hold T' one, and was sitting dormant in recent versions of I&A. not quite as easy to use but ... yea group_manager.sqf

There is a performance budget that has to be worked with ... It can certainly be re-implemented but it is not a matter of copy/paste. They were removed at the time bc an ArmA update broke the diver spawning. After that the code was adapted for urban-style CQB missions. They proved far more popular than SCUBA ones .. Personally im not the biggest fan of underwater combat in ArmA. Large numbers of AI underwater is implausible from realism standpoint, so it would only be a few defenders of a target. That would mean may have to put a mission fail variable in, should too many players attempt to attack it. an alternative is coastal/shallow water missions where SCUBA is a legitimate method of insertion. -- re missions in general .. Zeus is coming soon.

You didnt scroll down. reference to admin_uid.sqf is in the init field of every playable unit, of which IIRC there are 57.

the portion to search for and remove is underlined now

open mission.sqm in main directory search for init="(group this) setGroupId [""IA""]; this addEventHandler [""respawn"", {_this execVM ""admin_uid.sqf""}]; "; And delete the red portion. There will be some 50-60 entries of it, in the init field of each playable unit. this can also be done in the 2D Editor. Open the mission in the Editor and double-click on each playable unit, and delete the red portion above from the init field of each. make sure you dont delete the "; at the end of the line. -- next, open the init.sqf in main directory search for this line _null = [] execVM "admin_uid.sqf"; delete it. note it may already have been removed. -- open the description.ext folder in the main directory find this line (its near the top): #include "spectator\spectating.hpp" // Kegetys Spectator Script delete that line. note it may have already been removed -- delete the 'spectator' folder from your main mission directory (or wherever it is, if it is still there).

It's possible, but SCUBA missions were never that popular.

Current AW versions are actually running both squad managers in parallel. So you can both use your scroll wheel AND hold T to select. I would suggest removing the 'hold T' one, since it's just another piece of code running, which doesn't need to run. This can safely be done by simply deleting the file "DOM_squad\group_manager.sqf". It is authored by aeroson. Removing that will not adversely affect Xeno's group management.

In 2.71f, UH-80 Ghosthawk can drop a para-drop a supply box.

haha good point will do the best re grass settings nothing is broken .. there is a line in the init.sqf to 'disable no-grass'. if the community wants to be able to disable grass then its easy enough to re-enable the 'no-grass' setting.

first you say it is most stable version, then you say there are catastrophic instabilities after 1 hour of server uptime ... I am confused. If you could post the actual lines that would be handy. this line is just a report, not an error or loop. almost every mission has it. If they are the LODShape LoadHandler errors then no need. those are in every MP mission due to engine bugs related to those optics. ie There's also a really nasty one with the black MX with attached suppressor. Those are BI issues that cant be fixed except by removing the items from the mission.

re Thronos castle ... It would have to be a custom side mission. There used to be an AO up there, however the AI get stuck inside the walls of the castle and in the rocks north of it. I attempted it again recently with a new findSafePos function, however AI still spawn ATL (at terrain level) underneath the rocks, making them impossible to kill and stalling the mission cycle, requiring close admin support or a restart. Transport and Ambush side missions will soon not require oodles of coding, as the Zeus module will allow on-the-fly missions like this to be created without burdening the server with more mission code executions and loops.

The sling error is only thrown while a vehicle is being lifted. It's quite benign and has no noticeable effect on performance, part of why it's taken so long to get around to debugging it. The problem is that the initial attempt at that sling script included trying to simulate rope physics. Most other sling scripts use 'attachTo' to attach a vehicle to another vehicle, which is like slinging something with rebar, and the slung vehicle does not take damage and does not collide even with the ground. The attempt at rope physics failed (ArmA 3 engine just doesn't do it effectively) and when we get around to debugging that code, we'll just use attachTo instead. In the meantime, try slinging a vehicle and dragging it along the ground ... There you will see the difference between that sling script and others. It hasn't been removed from the pbo because it has been seen as adding to the gameplay/fun more than it detracts.

mind sending me a copy

This is a serious issue that has arisen since the recent ArmA update. BI has already attempted a fix: http://dev.arma3.com/spotrep-00020 Server operators have to update their server with that hotfix for it to take effect. I can confirm it DOES fix the MP crash issue. edit: issue seems to be successfully resolved on EU #1

2.71e = copilot seat disabled on the workhorse transports, Mohawk and Ghosthawk, until BI fixes the desync issue with the crew seats. Ghosthawk gunner seats can still desync, but Mohawk will experience no desync bugs.

Neither the revive or squad manager are new to AW I&A. Arguably more popular, but as Raz said the author of the Squad Manager has allegedly said he doesn't want others to use it. That has to be respected. I'll see if I can contact Xeno and ask him nicely

IIRC he was given the boot from the ACE dev team

Just a note, it all belongs to Bohemia Interactive Studios. Can't recall one instance of legal action being taken with any coders IP in ArmA. Yes it is rightly frowned upon to use someone else's code against the authors will, but it legally belongs to BIS.

Are you referring to an ArmA 3 guide, or an I&A guide?

had a play with it love it! keen to see how this develops, great fun. lots of tension and time pressure