Welcome to AhoyWorld

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customize your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

Ryko

AW Core Staff
  • Content count

    1,045
  • Joined

  • Last visited

  • Days Won

    89

About Ryko

  • Rank
    Head Honcho

Profile Information

  • Gender
    Male

Recent Profile Visitors

2,132 profile views
  1. https://github.com/acemod/ACE3/issues/5302 Ace 3.10.1 issue, resolved in next release
  2. Please restrict this thread to reported bugs or suggestions. Following up: Fixed Fixed This is a longstanding misconception from ACE. The g-force suits do not do anything about blacking out. You need to be in a pilot class in order to have built-in g-force protection. That said, I'm not sure if ACE is properly tracking it for our needs, so I have added a secondary check to add the code that restricts g-force to pilot players. It seems to be intermittent, sometimes it works, sometimes it doesn't, I've gone over the code and everything -should- work - I have a feeling this a locality issue, in that when a player disconnects his dropped gear isn't sync'd to the server. For all the reasons mentioned, plus the fact that the mortar is ridiculously powerful and easy to use, suggests to me that it's no appropriate for Gauntlet. Other fixes in 53_113: 1) UAV vehicles available in plane spawn 2) UAV vehicles now respawn with crew, allowing them to be operable 3) fixes to Malden 4) mission fixes for counter attack, capture fighter, clear camp & destroy ammo dump 5) updates to default loadouts 6) added secondary check for g-force protection on pilot roles (a pilot uniform does NOT protect you from g-force effects) 7) updated CHDSK guerilla opfor faction
  3. @Lost Bullet - thanks for your concern on this matter, it had been brought to our behaviour and the parties involved have been warned. To answer the question, not okay. - R
  4. It's back! TS is also back.
  5. I wrote that script: that was not the intention and I'm surprised people died as everyone is set allowDamage false before the chopper is hit, and allowDamage true only after the end of the waking animation. Arma being arma. Ben might have been using his respawn script which respawns you with the gear you had when you died. Since the second part of my script has you "waking up" with your gun and some of your ammo / supplies scattered around you, any dead players probably spawned without that kit.
  6. It's something that I've thought about. However my gut feeling tells me that it wouldn't be as popular because it would quickly become a very similar experience for every engagement zone. At least with Gauntlet, there are a variety of different objectives that switch it up. I'm open to ideas, though.
  7. I think if we run this again I'm just not going to push the mission through until ASL slot (or whatever command element) is filled on both sides. I'm also going to remove the jets and possibly the armed helicopters - they're just to effective, and various aspects of the modded jets we use are broken. We can revisit air support when RHS has updated to make itself compatible with 1.70. The missions spawn dynamically but are limited to an area in between the two bases. Since it's random some AOs are going to be unfair for one team compared to another: if I made it so that the AOs always spawned equidistant to both bases, the missions would always tend to spawn in three places. As for rushing the objective, I see absolutely nothing wrong with that - it should encourage the teams to get themselves supplied, and moving out quickly. There are definitely AI troops deployed around the objective, so whether or not it's a factor depends on how much you want to make it a factor. In regular Gauntlet, players seem to delight in executing every AI enemy before moving in to complete the objective: if you want to complete the objective without engaging a single AI, that's your choice. Actually I did increase the AI skill in that op but I could set it to maximum. The bases can't realistically be moved closer because then the area where the missions spawn will be made much too small. Lastly, I think this mission type will only work if there is strict interpretation of the rules - Command shouldn't allow Alpha to take a tank, it should be filled by a Hammer or Torch team. That said we could allow for some latitude in slot restrictions, in that Hammer could be slotted without a full Alpha, given that we'd need a server of 40 players to get to a point where Hammer is feasible.
  8. Hey folks, Today's TvT will be something slightly different - BLUFOR and OPFOR playing against each other on a subset of the standard Gauntlet missions. AI is still there - the CHDSK rebels - and they fire on both BLUFOR and OPFOR. We playtested it this afternoon and it was epic. The more folks the better!
  9. ^
  10. It's not a simple matter. The map uses both custom placed markers as well as a master file to determine where AOs get placed.
  11. I'm not sure how doing it in Zeus is different from doing it with the Logi system, except only admins may perform the actions.
  12. To be fair, sometimes it's hard to assess whether MAT will be in position in time to realistically be able to help you. When that BMP is rolling up on you, it's hard not to prep AT and send off a shot when it gets close. I've taken to having MAT roll directly with Alpha for just this reason, rather than putting them in an overwatch position.
  13. Some backstory on this, as I realize I just kind of dropped this functionality into Gauntlet without really explaining it. To be honest I don't see the Logi structures functionality as working well with Gauntlet, rather it would be better for a game night scenario. But since it's hard to test how it works and fix / improve upon stuff without it being in the common mission, I elected to put it into Gauntlet and see how it works. I agree, Fallujah is probably too small a map to really need a FOB, but I liked what I was seeing there. Unfortunately I was just getting communications all over the place and wanted to keep the mission moving forward: I really needed to be Platoon Commander in order to have a better top-down view. But also unfortunately, I had to leave right as things were getting interesting. I did have a couple of realizations, though. The first is that the dynamic of having to leave the red circle marking the AO in order to advance the next mission is antithetical to the FOB setup I was going for, and frankly, there's no need for it in the modern Gauntlet code (its original purpose was to get players to leave the general area of operations so that dead enemy bodies could be cleaned up "quietly" - ie., the players do not see the bodies disappear). I think I'll just move it towards a timer that spawns a new mission some random time after the previous mission has been completed. The next is that I'm going to develop another mission parameter to filter out missions that require the players to RTB. For example, missions which require you to bring something back to base or take something from base to somewhere else on the map. This should produce an ability to string together missions that will keep players out in the field. Disappointingly, thin objects will not stop AI from walking through them: only H-Barriers will do that. I don't think even the fences will stop AI (although the razorwire barriers might). It's not intuitive, I know, but what it does is it rotates the structure to face the direction that you're facing. So if you're facing north, it sets the object's direction to 0 degrees. If you're facing south, it sets it to 180 degrees. I initially tried "rotate left" and "rotate right" but after three turns the structure would disappear! The problem is that the structures aren't consistent in terms of how they spawn: some face the way you'd want them to, others face opposite to that. So if I rotate the H-Barrier walls 180 degrees, the other structures are now facing the wrong way, and I don't actually want to build in too much exception coding to specify which objects should spawn which way. If you spawn the structure, face south, and then set rotation, it should do what you want. I'll look into a better way of handling this, but that's the way to do it for now. I thought it was interesting that ambient targetted the FOB as it did: that definitely kept players on their toes. I do like the idea of this but there are all sorts of issues spawning a composition of buildings. What happens if you try to spawn it on a steep gradient, or if there are trees and buildings around... part of the reason the FOB truck never worked reliably was that it needed a 20m clear, flat radius to deploy on, so that structures wouldn't clip / get destroyed / destroy other things. Plus what happens if you spawn a composition and someone is standing right where an H-Barrier deploys? At least in the minecraft method there is much greater fidelity in deploying the structures where they make sense. The individual structures only exist on the client's computer while they're being deployed so they don't kill/wound players while you are placing them.
  14. The script looks in a 100m radius for all available containers and then sums a pool of resource points, so if you had two large containers and a box you'd have 500 points available in total. When you deploy a structure that cost is deducted from the first available container until all its points are depleted and then the remainder are taken away from the next available container. If you don't have enough points to build something, you get an error hint.