Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Everything posted by zbug

  1. Nah no one got rude, it's just that this discussion has been coming around every few weeks and the dead horse has been dead for a while now :p Well I had a look at the code for this if ( typeof _unit in all_hostile_classnames ) then { stats_opfor_vehicles_killed = stats_opfor_vehicles_killed + 1; if ( isplayer _killer ) then { stats_opfor_vehicles_killed_by_players = stats_opfor_vehicles_killed_by_players + 1; if ( GRLIB_ammo_bounties ) then { private [ "_bounty" ]; _bounty = 10; if ( _unit isKindOf "Air" ) then { _bounty = 40; }; if ( _unit isKindOf "Tank" ) then { _bounty = 20; }; resources_ammo = resources_ammo + _bounty; [ [ typeOf _unit, _bounty, _killer ] , "remote_call_ammo_bounty" ] call BIS_fnc_MP; }; }; } If RHS is done in such way that its vehicle types don't inherit from the standard types of the game (for example with isKindOf "Tank" returning false for a BTR), then yep it doesn't work. Could be another reason but I don't have other ideas
  2. Sorry but the discussion about sector activation mechanics has already happened several times both here and in private, I'm not having another row of it, you're free to dig it up in this thread to see why it's done this way, and why all the simple solutions end up in massive performance issues. If you want to try on your own you can edit the value of GRLIB_sector_size in gameplay_constants.sqf (for a larger spawn area) and remove the contents of wait_to_spawn_sector.sqf (not the file itself, just leave it empty) for instant spawning everytime one blufor unit enters a sector. If the actual creation of individual units takes too long (you'd see them appear one by one in front of you) that's only due to your host fps (or headless client if you have those - that would help, btw) If you have issues with invisible weapons and vehicles, make sure both the server and clients are loading all the needed mods If enemies are popping in front of you make sure your server fps are acceptable, bottom left corner of the map, anything below 10 isn't acceptable. Last time I've seen that the server was running at 3 fps, and further checking showed several wasteland and exile instances running on the same host...
  3. Well the CSAT aggressivity parameter already exists, it's just a matter of having it influence the player count at which random attacks will start happening, so I'll do that in the next version Anyways yes that's the line you'll want to edit :)
  4. Thanks, I'll look into it. That's strange because it works correctly with regular vehicles. Does it help if you turn player markers off then on in extended options ? There is no issue whatsoever if you use a different classnames setup with the same savegame. The worst that can happen is if you remove the classname of a vehicle that has been saved in a FOB, you will lose that vehicle with no refund, and that's about it ;)
  5. We've been using the standalone version of this (which requires CBA), and I'd rather use the addon than put the script in the mission and force it upon every player. I could always put that behind a mission parameter, but the options screen is already getting very crowded. So yeah, I'd rather keep using and recommending the addon version for this I can't tell you exactly when but I expect the 1.0 to be done rather soon, see here The frequency and power of random CSAT attacks on your positions are determined by player count on the server (if you haven't disabled that option) and CSAT aggressivity settings. The global difficulty influences the speed at which the alert level will rise, so it affects CSAT battlegroup strength indirectly. Chances of getting a counter attack after a sector capture are influenced by CSAT aggressivity, global difficulty and current alert level. You also get counter spawns against your air and armored forces if the aggressivity is higher than "normal" and you use either air or armor a lot (determined by their share of kills), but maybe that isn't enough just yet. I've found out it's the hardest part to balance as it depends on the way every group plays the mission. I've had people complaining about too much CSAT pressure while other were complaining about getting too little. The CSAT aggressivity parameter helped but maybe not enough yet. I'm all for giving you all the control you need over that so maybe I'll rewrite that part before 1.0, as part of a larger balance/difficulty tweak. Also (I've just read the code again) for random attacks (not counters) you need at least 20 humans players and 20 fps on your server. Maybe that 20 players limit could be lowered by the CSAT aggressivity parameter, so you could get constantly hammered by CSAT battlegroups with only 5 human players to defend if that's really what you want ? :p Patrols are a different issue as they are spawned close enough from the players to avoid costing performance for nothing. If you move to a new zone of operations then patrols may take a while to spawn around you (up to 30 minutes). Their amount also depends on the current alert level, so if you do a lot of secondary objectives, you'll get less hostile patrols. Anyways that's a lot of rules so maybe I'll try to streamline all that into something simpler. It would seem related to the savegame, maybe your Arma has issues accessing your user files, or if you have a huge amount of units and FOB objects in your mission ? For your first question turning GREUH_allow_customsquads to "false" should help, but it might also bork the extended options UI that wasn't revised to allow that, you should try and see what happens. For your second question, that's weird, do you have another addon that maybe puts markers on blufor players? Cause what you did should definitly turn off the script that's doing it. Yep, you need to edit classnames_extension to add buildable stuff. Putting every single classname from every single mod in the build menu would definitely cause issues, and you'd have a hard time just to find what you need :) - I've tried this and apparently there's more to it than just putting a fire mission waypoint with Zeus, no idea just yet, - That used to work just fine but we didn't try recently, maybe v1.56 broke it? - You'd need to synchronise waypoints to do that with Zeus, I've enabled it in liberation v0.922, - Same, done in v0.922 It seems Arma only accepts integers as default values for mission parameters, I've already run into that issue There's tools to unpack and repack pbos without breaking them, you should be editing files inside the pbo, not the pbo itself. The other option is to grab the mission source files here, open the scenario in the 2D editor and save as -> export to multiplayer from there (which creates that pbo file you need)
  6. v0.922 is out This version has got way more changes and way less testing than most previous versions, if you encounter any major issue you should report it, and if needed revert back to v0.921 (the current savegame format is compatible with both). Changes: If you have player markers enabled, wounded players now appear on the map with a specific icon. Player markers have been reworked to refresh more often while costing less fps, although the difference in fps isn't really noticeable. Zeus can now delete objects and synchronise waypoints. It might correct the issue with transport chopper unloading. New mission option to enable/disable the autodanger behaviour on allied AI (disabled by default). New mission option to enable/disable the BLUFOR units that pop up to defend captured sectors (enabled by default). New mission option to limit the number of FOBs you can have at the same time (26 by default). Reworked the arsenal UI, "take loadout", "save loadout" and "copy loadout" options won't close the window. You can still doubleclick a loadout to quick load it. The server admin will be able to use the commander slot, regardless of whitelist settings. Classnames_extension has been improved to allow the extension or replacement of about any classname in the mission, allowing you to use any mod you want without ever touching the original classnames file. As a consequence classnames_extension.sqf has moved to the mission root while classnames.sqf is now a bit further. If you still need to modify classnames.sqf then you should tell me, so I can add what's missing in classnames_extension.sqf. There's a new arsenal.sqf that will restrict what is available in the arsenal. By default it's empty, meaning that everything is allowed, except the usual blacklisted items.
  7. I'll add the ingame option to have the UI at the right or bottom of the screen, or remove it altogether The whitelist could help indeed, but it also lacks the option to restrict the commander slot to the server admin, which I'll add It's just a loop that checks for the presence of blufor units around each sector. Since I don't know how costly that is, it's good to know that the loop will slow down if server performance isn't good enough It does cause an issue on some servers where players will get to the center of a town before the server even notices it has to spawn something, but I've only ever noticed that on servers that were running below 5 fps, which may or may not be due to the several other instances of exile and wasteland running on the same host If your mission has 100% human players you could offload that to the clients, making them tell the server when they're entering a sector. In liberation that wouldn't work because of the blufor ai units, or rather because the commander is able to attack sectors with only ai forces and no human around
  8. The script you want is scripts\shared\set_skill.sqf What you describe is more about "aimingspeed" than "aimingaccuracy" but you can modify whatever you want until it fits you This totally looks like you're overloaded rather than wounded. The respawn loadout feature might have that old bug which gives you one less rocket than you should have, making you just light enough to move. Either use lighter loadouts, or disable the stamina system altogether in the mission options While you're obviously right to an extent, this is a huge bias. Comments asking for something are made by people who have something to ask, and the majority of players are just content to play the mission and never say anything about it :) I use the server list to really see what's happening, and while there are definitely a good number of ACE3/RHS/Alive servers, it's still a small minority. The good news is, you can easily modify the mission to add any mods you want, and that's what the admins of those servers have been doing (and I've been talking with quite a few of them about it since the first release) Making those mods mandatory by default would make the mission unplayable out of the box for the vast majority of players. I could totally do dual versions (vanilla and modded), but then I'd have to spend the time to manage those dual versions, keep up with the updates and changes and so on, and I'm already short on time ! Just so you know, if you allow people to move objects with Zeus, they'll be able to move any troops and vehicles over any distance, so you have to be okay with that :) If that's not an issue then, scripts\server\game\zeus_synchro.sqf, remove lines 43 to 47 or set parameters to zero instead of -1e8 Also I think if you create an object in a FOB and then move it with unlimited Zeus, that movement won't be saved, the object will go back to its original position after server restart Definitely an Arma v1.56 issue that will be solved at some point. I agree that's a bummer though. That's some of the oldest scripts in liberation, one I'd totally rewrite if I had time and courage to do so. There's no real reason for having the 4 defender squads that way, it just... works, kinda. As for the rest you're proposing, see my post above ;) So many things I'd like to see, too, but not enough time and motivation. The main issue I think is that when the pitch of your mission is "a dynamic persistent coop cti campaign for Arma 3", you can work all your life and never get it finished. There'll always be something more you can do to make it better, more complete. Of course I'm being extreme here because I could totally do a lot more features in the next six months if I wanted to, but you see what I mean here, it's more about putting the limit somewhere to say "okay guys, the mission's done, that's all I'm willing to do", than wondering about which or which feature ought to be in since there's no limit to how many features you and your players can come up with.
  9. Hey everyone, just to repeat what was said a few pages back, and say a bit more on what's been going on: The current plan is to release a 1.0 "rather quickly", and the only thing that's absolutely mandatory for me to call it a 1.0 is more secondary objectives. 4 or 5 would be good enough, and the 3rd is already almost done. There's no point suggesting major overhauls of the mission, because I won't be doing them. A few features look easy enough to squeeze in, thus why hostile artillery and paradrops are on the short list, but that's about it. Don't get me wrong, I always value everyone's feedback and ideas, however you have to see it from my point of view: with so few man hours to spend, I have to pick carefully. If you're the only one reporting your issue, chances are it's on your side. If you're the only one suggesting a feature, chances are it won't benefit that many players in the end. (I go by the vote count on trello vs the effort needed to do a feature, by the way). Stop telling me most people play with RHS so I'm required to do an RHS port, I can see from the server list that a lot of people do, but not the majority, and certainly not "everyone". And on top of that, you can do it yourself. The reason for the drop in time invested and the end of weekly releases is very simple: my group and I aren't playing Arma anymore. The last time I played online with a few real persons was mid january. And after many years spent on this series (since OFP for some, including me), I can understand why people are burning out. However that means I can't playtest new versions properly. v0.922 has been ready for quite a while now, but I can't take the risk to release a buggy version and have to deal with critical issues popping up left and right. It happened in the past, and let me tell you how happy I am that the current v0.921 has no such major issue and people aren't coming in droves to report corrupted savegames and so on. From what I can see on public servers, on other groups' forums, in their youtube videos and so on, in its current state liberation is already providing a solid 250 to 300 hours of persistent campaign fun to various player groups around the world. That's already a lot more than I hoped for. Sure it could always be better, sure I could likely do everything you suggest (most of it are very good ideas), but that would cost many more man-hours than I'm willing to put into this. It's just not fun anymore. Of course I'd see it differently if I could still play, but that's the way things are. So you're getting a 1.0 in the coming weeks, depending on when I can test (but I'll play on a local dedicated if that's what it takes). However if you want more than that, you'll have to do it yourself. Not kidding, arma scripting is easy, and you can do whatever you want with my code. I'd be happy to see someone start the fork that aims to be liberation but a lot better, really. Also with the next version you get a lot more of easy scripting options to replace and extend the original classnames with whatever mods you like. You can still only play BLUFOR units I'm afraid, but that's exactly the kind of major overhaul I don't want to get into right now.
  10. The blacklist only works for backpack items because otherwise it would cause horrible performances issues. When the blacklist was allowed for everything the arsenal would take 10 to 15 seconds to open depending on how many mods you had, freezing the game at the same time. However in the upcoming version you'll be able to determine exactly what you want to see in the arsenal, so that should solve your issue
  11. When you're not getting the deploy screen, that means the mission failed to initialize in some way. If you show script errors or have a look into your rpt files, you'll have a lot more info about what's going wrong. I'd bet on a punctuation mistake in classnames.sqf ;) I'd love to help more, unfortunately I really don't have time. Put it another way, any help I'd give to modders would delay the progress on the main version The weather scripts are manage_weather.sqf both on the server and client, if you remove those from the init scripts you'll be able to do whatever you want, starting from the vanilla weather system
  12. Do you mean to limit the amount of FOBs you can have deployed at the same time? That's very kind of you and I sincerely appreciate the gesture. However I can't accept it for several good reasons. I'm not the only person who worked on liberation, especially if you include all the scripts that other people have authorized me to use for free (see the thanks list in the first post of the thread). Even without that, I'd have to split with the person who did most of the graphics elements (McKeewa), and all our group of people who playtested the mission, without whom it wouldn't even have existed. While no one would argue that I've put the most effort in this, I'd still have to split fairly. 20€ wouldn't cause any drama, however if many people start donating (I can only hope :D), it would quickly become an issue. So if you really want to send money as a token of your gratitude, I appreciate that a lot, and I kindly suggest you send the same amount to the charity of my choice, which is Medecins Sans Frontières
  13. Are you running any client mods that your friends wouldn't have? There was a very similar issue with that a while ago As for the original issue, I'd check if GRLIB_ignore_colisions_when_building is still there at the end of classnames.sqf and if it has a correct value
  14. Either way those issues suddenly started happening as v1.56 came out, with no release of liberation in the last month, so I'd rather wait for BIS to sort out the new issues rather than spend long hours debugging this problem
  15. Both of you are running with only one headless client ? Could you try with 3 headless if that's at all possible ? There's nothing obviously going wrong in the logs you provided, the issue may be related to the large amount of local units running on a single HC instance, large uptime (15+ hours), maybe exceeding the maximum number of groups (I should add that info in the log traces actually), maybe all those elements at once. I'm impressed with the fps you're getting with 350 units on a single HC by the way. Anyways nothing too specific for now, so rebooting your server once in a while is your best bet. Sorry I don't have time for a proper follow up at the moment, I didn't even get the chance to try the new editor. Short terms plans involve putting in the little stuff on the backlog, adding at least 2 more kinds of secondary objectives, and giving the commander a way to shutdown the auto-danger behaviour on friendly AIs, since it's now possible (yay)
  16. Noted here Good idea, noted for later I didn't look into CUP yet, your best option to get the LHD working is to look into atlas_manager.sqf, hoping the carrier elements are similar enough No ETA as it's unlikely to make it into the 1.0 shortlist (which is only either things that the mission really needs at the moment like more secondary objectives, or very small changes that can be done in a few minutes) Lots of great ideas but unfortunately nothing the mission really needs to be considered fully playable. Either I'll do that if/when I come back to the mission later on (and I'll make no promise on that, not saying there's no chance at all either), or someone else will take charge and do it (you don't need my permission for that) Edit: also if resistance is your type of gameplay you can have a look into antistasi altis You can add your unlockable stuff into "elite_vehicles_extension" in classnames_extension.sqf. The unlocks are generated at the start of the campaign and then saved so you'd have to start a new campaign to see your changes have an effect The way I've been doing it, you open the mission editor, move the player unit away from any fob or sector, put a truck of the wanted type and a few vehicle ammo crates there, and test until it works fine. Each time you click "save" in the editor the mission will load the latest version of your changes, so you don't have to reload the mission, only click "save" then "preview" every time. I agree it's ungrateful work but it also gives a weird sense of satisfaction where your crates finally fit just fine :P
  17. I'll add a mission parameter for that in the next version However be aware that these guys are useful in dealing with lots of hostiles without you even knowing. You're likely to notice it when they're gone :p If you're talking about the RTS mode, contrary to Zeus the view would have a minimum height so it's not used to spot hostiles in buildings or cover. Think of what you've got in Wargame series. But this isn't happening anytime soon anyways, as I didn't get to play liberation in the last month, I'm not all that motivated to make new features if I don't get to play with them at some point You're missing the new entires in the squads_names array, in the bottom part of classnames.sqf. Since it's only your version don't bother with localization, just put the name string in there You're not 100% required to have all the units in infantry_units, but the manpower upkeep calculation won't work for every unit from your new squad that isn't in infantry_units too
  18. I didn't have any broken test on my end, are you using a different set of mods/classnames than vanilla ? This minimum range is determined by sector capture zone radius + fob build radius, you'd need to lower either of these to build closer to sectors I'm only lowering the scope of 1.0, side missions are still on the todolist plus a few things like the actions wheel and hostile artillery In gameplay_constants you can raise the value of GRLIB_sector_size which will make the AI appear sooner. It will also destroy your server and client fps. More likely this is because the ace wind indicator uses the same way to show up which only allows one overlay at a time. I'm limited because liberation is not an independent mod so this isn't going to change on my end You could look into other benefits than just lowering the alert level, the upcoming side missions will have a whole range of possible benefits to make them really unique No clue about the font, I don't make these images ;) Headless clients are always enabled, that variable you've found only shows a diagnostic on screen, which is now useless as you can get the same info on the bottom left corner of the map. All you have to do is to get your headless clients connected to the server and it will work as expected You'll notice quicker AI reactions with headless clients only if your server fps were low enough to begin with. That will also allow the server to spend more of it's cpu time to run mission scripts instead of caring about the AI. Headless clients have no effect whatsoever on client fps which are only dependant on view distance, AI count, object count and object details
  19. v0.921 is out Changelog - FOB headquarters are now invincible, unless the FOB is taken over by hostile forces, - Passive income will now replace the ammo boxes found in hostile military bases with an ammunition bonus upon base capture, - Intel should now spawn correctly in hostile military bases (on the ground, but at least it's there), - Fixed the bug that prevented players from loading ammo crates onto appropriate transport vehicles. As a sidenote, just know that because of the lack of motivation from my own group to play Arma in general (and Liberation in particular), I may have to push a stable 1.0 out of the door sooner than expected, and maybe come back to it later on.
  20. No worries it's corrected already Currently the formula for the ammo tick is 4800 seconds reduced by 18% for each base you control with a minimum of 300 seconds. That rule doesn't change with passive income, only instead of a crate spawn (for 100 ammo) you get a flat bonus (35 + random 35 which i just changed to 50 + random 35) Ammo boxes only appeared in hostile bases with passive income on. I've changed it so that you get a flat bonus (75 + random 50) upon base capture instead. This could have so many causes I wouldn't know where to start looking. I've noticed the most broken spawns on servers running at 3 fps (having 4 concurrent arma instances on the same host and no headless client seems to do that). But if you have a server running above 10 fps and if you don't exploit spawn mechanics by rushing the center of the zone because you know the spawning is going to take a while, everything usually works fine. Protip: you can't capture anything if enemies are not spawned yet so there's really no benefit in exploiting spawn mechanics.
  21. They're not supposed to escape if they have any blufor unit within 100 meters and my tests were working fine, so if you say they escape while being escorted I'll have to debug more
  22. v0.920 is out Changelog: - Added a new secondary objective: convoy hijack. - Added the spanish translation made by regiregi22. - Tweaked the behaviour of prisoners, you may want to watch them more closely now. Also fixed the bug when getting into a vehicle would make prisoners stuck. - FOB buildings have been told to stop moving on their own between server restarts. - Tweaked the AI routines of CSAT battlegroups so they should behave better with very low server fps.
  23. The save is located in the server profile file which is named <serverUser>.vars.Arma3Profile, it's a good practice to backup this file before doing any change on the server so you can overwrite the new (empty) save with the old one if anything goes wrong. Maybe you can still find the old file on your server somewhere
  24. It's a new secondary objective, it's randomized in many ways and comes along with some funny AI routines ;) Tests are looking good anyways
  25. http://i.imgur.com/odp2Zv6.jpg http://i.imgur.com/ITfG8Wo.jpg