zbug

I've been wondering a lot about the resources system lately, and I'd like to know what you think about it. The main advantage of the current system is to force people to play as a team. Since there's no personal resources, everything someone pulls has a cost for everyone. While the point of it was to promote teamplay (and on closed servers it works as intended), on servers open to the public it only encourages admins to lock people out of the build system entirely so they can't spend the team's precious resources (and especially ammo). I'll be honest, I've been doing that on my own server too :P End result, people can't pull their own vehicles at all, and if admins don't keep a free pool of vehicles that pubs can use to move around, pubs are stuck to foot soldiering forever. (Now maybe my analysis is wrong and you like it the way it is, if that's so then just tell me.) The proposal would be to switch to personaly owned resources, while keeping the three different kinds. All 3 resources would be actual amounts and not upkeep capacities, like ammunition already works. Players would earn resources only through active gameplay like capturing sectors or destroying hostile forces or doing secondary missions or reviving people or ferrying people around, etc. The amounts earned would be determined by how many sectors of each type the team already controls, making purchases easier (and advanced vehicles more accessible) as the campaign progresses. There would be no tick-based rewards that only encourage idling around for a long time. Each resource gain for a player action would also send (part of) the gain into the "team pool", to be used by the commander to buy AI vehicles and structures and such. Or shiny stuff for himself if he's a selfish commander (same as the good old Warfare and so on). Structures would finally have a cost (manpower most likely). Players would be able to transfer resources to other players (or towards/from the team pool). Resources would be saved for each and every player during the whole campaign. I'd like ammoboxes to stay, so retrieving an ammobox would send a bonus to everyone and discourage stupid competitions between slingloading helicopters (although that would be fun). To avoid the stupid spam of cheap vehicles, I'd put a vehicle ownership system that allows players to be the owner of only one vehicle at a time. Spawning a new vehicle would make the last vehicle owner-less. Owner-less vehicles would depop in mere minutes, but they'd also switch ownership to the first vehicle-less players who gets in. An extension of that would be the usual lock/unlock commands for vehicle owners. An exception to that would be AI operated vehicles so the commander can still do their stuff. Permissions would be reworked accordingly, allowing admins & commanders to restrict the build AND use of vehicles per category. The current "building" permission would be used for structures, static weapons and supports. That's my thoughts at the moment, what are yours? It's not coming next week so we have a lot of time to discuss this, but I think it's important to come up with a fair vehicle use system before version 1.0

1- That's because Arma clients store a lot of info in their profile which the server does not, such as arsenal loadouts. I'm really not the only one using the profile as a way to save things, BIS started doing it first ;) 2- On our windows server we can see the profile file being modified every single minute of the game running (game is saved every 20 seconds now), which also works in case of a server crash or admin shutdown, we never lose progress further than the last 20 seconds. I don't know why it doesn't work the same on your end or if it's just a linux server issue, at least you might want to check whether your server has full read/write permissions on its own profile. The profile data should always be different as the playtime is being saved (i.e generating a hash of the file should always give a different result)

Do you have the latest update of Arma 3 ? (v1.54)

I will just remove them, I didn't think that would cause such an issue. Welp It's in gameplay_constants.sqf, currently set at 4000 It's not really "a lot", it's maybe 1 or 2 servers out of the 60 to 80 that usually run the mission according to http://arma3.swec.se/server/list I've asked here but most people answered they feel it's more CTI than coop. Of course it's both, but you can only put one tag on the mission, and I've chosen CTI in the first place because when I played MFCTI back when OFP was still a thing, I felt it was more about conquering sectors all over the map and building your own bases than the anticlimatic crushing of a small base built by the AI. And MFCTI had some good AI opposition contrary to most other CTI scenarios that came out since. Of course that might have been a different feeling in pvp but I didn't get broadband internet until after Arma 1 came out so I never tried that Yep it will be corrected in the next version

v0.919 is out Changelog: New option to set a minimum amount of FPS that the game should try to keep at all times, by reducing the view distance if needed. It will help with severe fps issues in large towns. If you leave this option at 0 (default) it won't do anything. Player score has been added to the savegame. To avoid saving values for every player that joins the server, only scores above 20 points will be tracked. New notification warning about the next place that will be attacked by incoming hostile forces. Classnames file has been refactored. If you had your own version, it's likely you'll have to do your changes all over again, however on the plus side OPFOR infantry will be much quicker to setup in this new version. And it will also affect secondary objectives as expected. New gameplay constant for HALO drop altitude, if you want to tweak that. Various tweaks and fixes.

The change is simple enough that you should try to do it by yourself ;) Yes it's still in, you think I should remove that fix now? https://github.com/GreuhZbug/greuh_liberation.Altis/blob/master/scripts/client/spawn/redeploy_manager.sqf line 41

Sorry, but no clue, I don't even know how the Nimitz works (the LHD is a collection of big objects being assembled together) You have to look for "box_transport_config" in classnames.sqf, for each entry in this array you have : - classname of the truck - offset when unloading the boxes (i.e how far behind the vehicle the first box should pop) - offset of each box when they're loaded Getting it right requires a lot of trial and error, didn't find a better way yet Without steps to reproduce it's hardly a bug report :D https://github.com/GreuhZbug/greuh_liberation.Altis/blob/master/scripts/shared/set_skill.sqf If you want different sets of skills for east and west you'll have to add one more condition

The performance in Kavala is bad regardless of the mission, but nevertheless I've relayed your question for more ideas about the issue, just in case So I'll try the suggestion by Quiksilver and see how it goes, noted here

Most likely. First the map has to come up and then we have to see if it's actually usable ;) I hope for a lot of additional air assets and amphibious vehicles There's already RHS versions out there, I'd rather release a quick RHS port than a new option that will cause a lot of issues if people and servers don't have RHS properly loaded. Some people already ran into issues when their server didn't have RHS loaded and the militia units ended up with invisible and silent guns, which makes me think it wasn't such a great idea to make it an optional component in the first place

Bug reports yes, pull requests that depends if they've been properly tested. For example recently someone honestly thought it was a good idea to add an overview picture, but they didn't test it on a dedicated server which would have shown immediately why it's not a good idea. But if you know what you're doing then sure, send your pull requests ;)

This is something I've been thinking about, but on the other hand, free transport vehicles also mean players will more readily pull them and use them, especially on public servers. I get what you say, but I'd tend to think that the good side balances the bad side of it That would be very welcome :) 1- Noted here, it will be done eventually 2- Very good point, I'll update the fob templates and allow people to define which units to use in classnames.sqf. Noted here - In the mission parameters you should enable "passive income" (disabled by default) - https://en.wikipedia.org/wiki/High-altitude_military_parachuting "In military operations, HALO is used for delivering equipment, supplies, or personnel, while HAHO is generally used only for personnel. In typical HALO/HAHO insertions the troops jump from altitudes between 15,000 feet (4,600 m) and 35,000 feet (11,000 m)" Anyways I'll add a gameplay constant for this ;) noted here - You would have to code a whole new system, the mission spawns unmodified units as provided by BIS or whatever mod you're using - The "shorter nights" mission parameter is working on our server, time will go much faster between 9pm and 3am if you activate it. Unless you already have a day length lower than 30 minutes (time multiplier can't go any faster than that) That would make IED encounters very random and frustrating, requiring everyone to run with scouts at very low speeds ;) You can do that easily in classnames_extension.sqf The parameter is named "Fatigue" (didn't change after v1.54), 0 means disabled, 1 means enabled You have to modify classnames.sqf in your version of the mission. As discussed earlier the only thing you can't change at the moment is FOB defenders, but that will be corrected in the upcoming version

HC is already supported, if your server has headless clients it will just work (up to 3 of them - I could easily add more but there's no real point at the moment) You can monitor server and HC activity (local units and fps) on the bottom left corner of the map, if you see HC info there that means it works

Yes the savegame will work without issues, it's only if you go backwards in versions that you might have issues

v0.918 is out Changelog: Implemented a dynamic sector activation range which goes down when there's many existing AI units, to avoid activating entire clusters of sectors and causing performance issues, Town defenders may now have flashlights, Added a few empty civilian vehicles around the map, Fixed an issue with saved AAF vehicles getting their crews on the resistance side, Fixed an issue with missing info when joining in progress during a secondary mission, Added a mission parameter which will activate the new disableRemoteSensors command on all clients. This is supposed to give better performance while removing some of the AI simulation, but to be honest I've seen no difference one way or another. If you want to run tests with it, you're welcome! I'll be adding new types of secondary objectives during the winter break ;)

If you've got a good gameplay video and want to have it put on top of this thread, feel free to ask

You could remove every occurence of removeAllWeapons in the sqf. Thanks to you I've noticed there's one too many, the only one that should stay is in onPlayerRespawn.sqf. But if you remove all of them that should correct your issue. You don't like the quick arsenal feature? :p (you can have premade loadouts and select the one you want on deployment) I don't want to put mod specifics in the main version because that's endless. You can always do a specific in your version, but you'd run the risk of having your c130 clip into something and explode instantly. Maybe that 45 meters size is too much but that's in the mod config. Sadly I didn't find how to make proper vehicle ghosts in vanilla like we had in Arma 2 warfare, if anyone has a way to achieve the same result I'll be glad to make the building script more tolerant with surrounding objects

Ha, if you've modified your version of the mission then I won't be able to help, as I'm already busy enough with my own bugs as it is :p You may want to add the -showScriptErrors parameter to your arma launcher and have a look at the rpt logs to see what's breaking

Have you disabled the revive system in the mission parameters ?

Are you using ACE or any mod that would alter the revive functions?

Yes, most of the scripts start only when the savegame has been successfully loaded. To fix the most common issue that used to happen you can log as admin, open the console, execute this: resources_ammo = 1000; trigger_server_save = true; Wait a few seconds then restart the server, it may or may not work

Several bugs that could cause a savegame corruption have been resolved since then, you should always update as much as possible (it won't wipe the save)

v0.917 is out Changelog: New secondary objectives UI. It can be accessed from the base or any FOB, by the server admin, the commander, or any player who has the "misc" permission. Secondary objectives now cost intel (the blue star resource). Intel can be earned by capturing prisoners or finding intel in hostile military bases. For now the only secondary mission is the usual FOB hunting, more will follow now that the mission framework allows it. Added bounties for vehicle kills, that can be disabled in mission options. Added the Endgame spectator mode with a bunch of spectator slots. Various bug fixes and tweaks to existing systems. Squad management is now available all the time for squad leaders, not only close to spawn options. Calmed down the weapon sway from A3 v1.54.

http://i.imgur.com/TTGcYLe.jpg

Right now you have the ingame modules + the script. But I've tested it again just now, and the script alone works in every case (it's been fixed at some point apparently), so from v0.917 it's all in zeus_synchro.sqf Nope, still need script + modules to make sure deleting and destroying is blocked x( So if you want to be able to delete you need to remove the cost modules + remove the setCuratorCoef lines in zeus_synchro.sqf

You could tweak the Zeus setup but it makes little sense when the commander mode is coming. It will allow to build remotely from the RTS interface, using the mission resources system ;) Also some of the costs set in the script don't work, you need the mission modules synchronised with the Zeus module to restrict moving stuff around, deleting and destroying and such. Edit: apparently it's been fixed at some point because now the script alone works perfectly, so I've removed the modules