Nick Seafort

Hi fellas, I've been scratching my head over these for a while now and not getting any closer to figuring out what's going on. I've tried the Discord a few times, but I think these questions may be a bit lengthy for that and haven't gotten any responses! Situation: finalising adding pylons and associated scripting for our modpack's helicopters, and these differ from vanilla helos in that: a) they may have both a pilot and gunner controlling pylon weapons simultaneously (rather than all pylons controlled by one or other), and b) who controls each particular pylon varies between different presets of the same vehicle. First issue: a "SAFE" weapon that we include as the first weapon for all vehicles vanishes ONLY IF the pylon loadout is altered in the mission editor. So, we have fairly standard SAFE weapon added as the initial weapon for both pilot and gunner. The weapon is defined with a magazine name that doesn't exist, and when we specify the magazines[] for the vehicle we just include nothing - so the players see a read "SAFE" weapon with no rounds that they have to swap off to actually fire anything. Having added pylons to the helicopters, these still work just fine upon loading into a mission. HOWEVER, if I alter the pylon loadout in the editor at all (via the vehicle's attributes pane, and simply swapping one ammo-type for another ammo-type for the same weapon for the pilot, for instance), then both the pilot and the gunner don't have the SAFE weapon show up any more - their initial weapon is the next in the list/first pylon, and cycling through all weapons reveal it's missing. Has anyone else experienced this, or have an idea what might be causing it? I've checked other mods out and they don't seem to encounter the issue, but I can't spot anything in their configs that reveals an obvious difference. The only workaround I can think of is to rip all weapons off on spawn and then re-add them as well as the static weapons/magazines as part of the init... but this is obviously not a great solution and also runs into the second issue. Second issue: I cannot find a reliable method via scripting to determine which seat controls which pylon station. As an example, if the vehicle's default loadout has the pilot controlling two wingtip stations and the gunner controlling two inboard stations, then if this is changed in the editor so that actually they've swapped so the pilot controls the inboard stations and the gunner the wingtip stations then I can't see any way to find this information out. As I'm trying to finalise the in-mission rearming GUI for pylons, this means that currently I have to try and guess who controls which pylon initially (to pre-set the ownership options on loading the GUI) and then store that in a custom variable after this to facilitate behaviour for the rest of the mission. It also means that I can't accurately workaround the first issue by removing and re-adding weapons/magazines due to not know the actual order to reattach them in to retain all the same animation/behaviour. It also means that the guessing function is a bloody awful nest of loops and array comparisons, with lots of checks to ensure the totals match after each step etc. Is anyone able to offer insight into either of these points? If more convenient, I'm available to chat via Discord or TS - just let me know ☺️

I didn't get a notification for this for some reason, but thanks for the suggestion Quake! I had a look into it, and unfortunately that mod doesn't really cover what I need (although I do like the way they've done some things!) ☺️ Anyone else got any suggestions?

I'm not honestly sure, not having used them myself - but given their naming structure and lacking any further documentation, I'd assumed that they were missionNamespace variables rather than functions. I'm busy tonight and tomorrow, but I'd suggest you check that out. With regards to giving you some kind of hook to execute code on the crate against, there isn't currently functionality for that built in to the system - but it's an interesting idea, if I can figure out a sane way to do it. It certainly won't appear soon as I'm rather busy currently though, sorry!

Hi Snake, I'm not quite sure what you are asking/want to achieve? If you want to alter the weight that is carryable for an ACE container you set ACE_maxWeightDrag and ACE_maxWeightCarry, rather than altering the crate itself.

@CPT J. Shaw If you literally want our mortar and ammo without the rest of the mod so that it can be used ingame, then that's not something we do - the pack is designed to work together, and at a purely practical level it would be a significant effort to unpeel the various mods to provide something like the mortar as a stand-alone. If you instead want the access to the raw assets so that you can modify them for your own/your group's use, then that's not something we do either - and nor do most mod makers. However, you can "inherit" from our mod and then tweak the behaviour and characteristics of our mortar, or create a child version of it. However, if you're not familiar with what inheritance is, then you'll probably struggle to make any useful changes. This may be better discussed via Teamspeak or similar where I can directly talk through it with you. If you want to do this, send me a PM here and we'll arrange something.

@CPT J. Shaw I think I'd misunderstood what you were asking then - are you asking to be provided with the content from our modpack for the 60mm mortar and its ammo? If so, I can fairly confidently tell you that we wouldn't provide that, and instead would suggest you inherit from our mortar if you want to make any unit-specific usage or modification.

@CPT J. Shaw Well we can't answer if we don't know what it is :P

@NethrosDefectus It depends what you mean by custom: any crate that you can place in the editor or via Zeus (ie, a crate that's a defined class), you can add that to the loadout and spawn list by adding its classname in the options menu (as a comma-separated list if you're including multiple crates). If you mean crates that are filled with custom loadouts specified by scripting at runtime, then no that's not supported.

Hi @bofhgr, While you can control who has access to the menu at all by altering the condition of the action appearing in the menu, there's no support current or planned for limiting functionality within players who have access to the menu - that's both outside of the scope of intended use, and also a substantial amount of work. So you could take the current condition that the action is based on, and then wrap that condition in a condition of your own that is based upon the various currencies you need to consider. The route to follow for that might be to have the player pay for permanent access to the menu on a per-vehicle basis? I should also mention that, while I'm not currently certain of the state of my work within the general licence of the mod, I wouldn't be comfortable with its use being in any way monetised on your server - if these are purely in-game currencies with no ability to acquire them through means like donating or purchasing packs etc, then I would provisionally be fine with it being used unmodified (beyond the access condition to the menu) with proper attribution to the mod team. Drop me a private message if you have direct questions regarding this or decide to go ahead with the project, and I can work out the specifics. Nick

Confirmed bug, I failed to notice the logical gap in implementation - the new infantry access was written with the assumption that it's from the Logistics Point, and I failed to specifically add the action to the prop synced to the Module o\ I'll sort that out, good spot!

Excuse the potato video, but here we go. As noted, the one point I meant to include but forgot, with the ACE Hellfires that use laser guidance, you can now do LOAL (lock-on after launch). As long as the laser sparkle indicator is red, then the missile will track to it after launch, even if it isn't locked on. And your edit link is from a comment on the previous pack version. If you're having difficulty getting our mods working but vanilla works, then try again with just our mods, CBA, and optionally ACE enabled. EDIT: also, your ACE link is for the wrong feature, this is the feature you want: https://ace3mod.com/wiki/feature/hellfire.html

Are you using ACE or not? This changes how the weaponry functions, as we're making use of the ACE Hellfire module when available. Also, which Hellfire variants were you using?

I just tested it and it works fine? I placed the barrel crates from the Prop > Supplies group, placed the Vehicle Logistics Module, and then right click > Sync To the module to the barrels.

How do you mean doesn't have ammunition? Do you mean that there aren't any belts in the inventory? Or that there aren't any loaded? Have you checked that you've disabled the safety on the vehicle (F by default, your switch weapon keybind)?

Yep, seems like that slipped through somehow! I've added it back into our tracking list, thanks :)

I've created a limited number of "compatibility patches" for 3rd party content (such as RHS) to add access to the Logistics and Servicing Menus, based selfishly upon the vehicles and mods that we use within 3CB ;) However, you can add access to any vehicle by including the appropriate following snippet in the vehicle's init: //Air Servicing this addAction ["Servicing Menu", {if (player getVariable ["uk3cb_baf_vehicle_servicing_pylonsUI", false]) then {createDialog "UK3CB_Servicing_Pylons_GUI_Dialog"} else {createDialog "UK3CB_Servicing_GUI_Dialog"}}, nil, 4, false, true, "", "[vehicle player] call UK3CB_BAF_Vehicles_Weapons_fnc_can_service_air_vehicle", 10]; //Ground Servicing this addAction ["Servicing Menu", {if (player getVariable ["uk3cb_baf_vehicle_servicing_pylonsUI", false]) then {createDialog "UK3CB_Servicing_Pylons_GUI_Dialog"} else {createDialog "UK3CB_Servicing_GUI_Dialog"}}, nil, 4, false, true, "", "[vehicle player] call UK3CB_BAF_Vehicles_Weapons_fnc_can_service_ground_vehicle", 10]; //Logistics this addAction ["Logistics Menu", {createDialog "UK3CB_Logistics_GUI_Dialog"}, nil, 3.99, false, true, "", "[vehicle player] call UK3CB_BAF_Vehicles_Weapons_fnc_can_load_vehicle", 10]; This is also on my list of things to be included/improved in our documentation :)

Hmm... I can't see that we've properly published that anywhere - I'll make a note to get that sorted out! In the Logistics Point or Logistics Module's options in the Editor, there is now a field where you can type in the classnames of any crates you want to offer as a comma-separated list. So if you wanted to offer none of the default loadouts but just a Vanilla Ammo and Grenades crate, you'd type Box_NATO_Ammo_F, Box_NATO_Grenades_F into the text field, and then untick all the BAF options below. Let me know if you want further clarification :)

To extend on that: Andy was doing some really good work on the Pylons for our helicopters, but we decided to pause that to get this release out. The Servicing Menu upgrade means that now you can rearm all vehicles again - the old servicing method was incompatible with the new Pylons system, and ended up stealing armament. So for now, you can use the Servicing Menu with any Vanilla pylon-enabled vehicle (such as the A-164 or AH-9), and for third-party pylon-enabled vehicles (as long as they either have a compatibility patch, or the UserAction added to them via scripting).

Our vehicles like the Jackal and Landrovers make use of a custom ammunition system - simply, you manage ammunition and reloads similarly to how you do as an infantryman. If there are the appropriate ammunition in the vehicle's cargo, then when you empty a weapon you hit R (by default) to reload the weapon using ammunition stored in the inventory. This lets you manage ammunition between vehicles in a convoy or patrol properly, rather than each vehicle having a magic pool that is unavailable to anything else.

(Excluding the first flyable Wildcat, ZZ400. Because I know someone will trot out a picture otherwise :P )

It sounds likely that you've got some custom crate(s) that are defined, and then they're loaded dynamically after being spawned. If that's correct, then unfortunately they wouldn't be compatible with the system that I've implemented. If you have your member get in contact with me, we can either discuss it further via PM or Teamspeak. I'll be happy to help them work out if there's a solution for your lot, or possible future enhancements that could work for you.

Hi Dostojetski, Handily enough, I've already added functionality to our dev branch that allows the mission creator to specify additional crates. The system works by letting the creator (via the Attribute window in Eden) add a list of crate classnames that will be added to the list of offered loadouts - both as loose inventory added directly to a vehicle, and as crates if ACE is enabled and the crated loadouts option is enabled. So while you couldn't add crates which are dynamically specified and filled during a mission (which is what I presume your member has done?), if those crates were specified in a mini-mod that you wrote then those crates could be used through the Logistics system :) While the system could potentially be extended to allow the addition of dynamically-defined crates and loadouts, I have no intention to do that currently. It would require an action-heavy process to be added to the functionality, and I had looked at it early during the dev process and discarded it as inelegant, needlessly heavy, and suffering from a few other awkwardnesses (such as crate naming in the ACE cargo window). Sorry! The current version allows you to reduce the "operation time" (the time to load 1000 units of cargo, clear 2000 units of cargo, or add a single item to ACE cargo) to 1 second. This restriction had been in place to avoid expected UI disruption, but some quick testing has let me discard that - your desired truly instantaneous loading is now possible :) There's a technical restriction in the way the system is built currently that prevents altering the timing of a particular logistics point during a mission, but you could place your instant Logistics Point prior to the mission, and then when the initial loading phase was complete either have Zeus or a script to remove the instant Logistics Point and replace it with one that has a non-zero duration. The concept of user-savable vehicle loadouts is an intriguing one, but probably not a direction I want to go. I'll add it to the list of things to have a look at, but unless it turns out to be a pretty easy and neat solution / I get mobbed by people demanding it, it's unlikely to happen. Let me know if you have further questions/suggestions!

Hi all, I've been working further on getting a servicing UI for the new Pylons, and I've run into yet another "roadbump". In this case, the roadbump is that the UIposition[] array for the Shikra is arranged [y,x], and the array for the Littlebird is arranged [x,y]. Now obviously, the UI within Eden renders absolutely fine and dandy, so what the hell are BI doing to get it to work? Do they even use the UIposition[] config value, or do they specify it somewhere else entirely? Is there another config key that says "turn your head 90 degrees before mapping these coordinates"?! I'm genuinely at a loss as to how to do this without simply being forced to hardcode UI element positions for every friggen Pylon into my servicing UI - as you can imagine, that is a) bad, and b) instantly removes compatibility with 3rd party stuff.... Help :/ Edit: and to demonstrate my point, the wingtip pylons for the Shikra: UI Top = [0.6, 0.45] UI Bottom = [0.05, 0.45] Pylons for the Littlebird: UI Left = [0.06, 0.4] UI Right = [0.59, 0.4] Almost exactly the same matrices, one giving a vertical separation, the other giving horizontal separation...

I'm just going to have a little cry now. Sleep deprivation & staring at code all day had me comparing data I'd scraped from the Shikra to the image of the Wipeout... everything appears to be okay, and I feel like a right tit :x Plus side, now looks like I've got pretty much everything I need to complete the prototype servicing UI :D

Hi all, I've been working through the 1.70 functionality and building up the process for choosing and rearming a custom loadout during a mission. I've got the entire process figured out with one exception: how to programmatically figure out which racks can be fitted to which Pylons. I spotted the getCompatiblePylonMagazines function mentioned in passing on the Biki, but I can't seem to figure out how it's actually meant to function, or whether it's actually in the game. This is all the information in the Biki: getCompatiblePylonMagazines string/index return list of compatible magazines, number > 0 or class name for one given pylon, or 0 for array of all pylons Anyone have any information about this, or how to go about the issue without manually scraping all of cfgMagazines to find what has a hardpoint[] that matches the type I want? :/