ImperialAlex

Today's update is just short of 1GB, but the dev log doesn't indicate massive additions. Is it just stuff being moved around or what is going on?

Line drawing is an awesome feature that I'm really looking foward to. Should it also happen to come with a set of script commands along the lines of what the ALiVE team requested...well, that'd be just incredible :) EDIT: Might be out of scope for your task, but since you're already working on the map: Would it be possible to get an optional toggle for icons so that they have the same scaling behaviour as the lines? (I.e. they behave as if drawn on paper, unlike the current icons). Currently if I zoom in and draw something detailed with both lines and icons then the lines and the icons will behave differently when I zoom out :)

Thanks, that's a very considerate answer! Your point about monthly support vs commissions is also a very good one :)

Maybe it's because the rest of the community has realized that 1.) the server can run a different modline than the client, so you could totally use the complete mod on the server and 2.) you could easily create a 'dummy' mod that simply has all your required mods as a dependency. ;) @War_Lord: I'm not sure if you're allowed to disclose this but what kind of budget and time-frame are we looking at for commissions? (Oh, and if you're commissioning stuff that's going to be freely available then that's pretty cool of you!)

ENGINE Added: A new VoNCodec implementation based on Opus (can be enabled by setting vonCodec = 1; in the server.cfg)

Got a quick feasibility question for oukej: Considering AI path-finding, would it be possible to define "No-Go" zones for the path-finding? Either as a "unit setNoGoZone _some_rectangular_marker;" or, if it's not possible on a per-unit level, then globally as a "setNoGoZone _some_rectangular_marker;" :) Is this within the realm of feasibility or is the path-finding algorithm a dragon that should better be left sleeping? If it is feasible, even if it's just a single area that applies globally to all units, it would make a few mission design concepts a lot easier :) :) :)

It's in perfectly good taste - that's one of the main appeals of Open Source licensed stuff: It's fate isn't tied to the author being interested enough to maintain it. However it does mean somebody else would have to step up and work on it.

Except for sync, all the other suggestions are, imho, 100% awesome. Regarding sync: As much as I like extending SQF, we must also consider that most people that use SQF are horribly bad at programming. Professional programmers with years of education, training and experience still have a hard time managing concurrent programming. If non-hacky atomicity where introduced to the game then I can already see how many un- or misinformed creators would end up wrapping their entire program in one large atomic block. It might also be very hard to implement, given that the scheduler doesn't seem to be very sophisticated right now and sync could introduce arbitrarily long execution times. There's also the fact that I can't really see the lack of atomicity creating serious problems if you write scripts in a failure-tolerant way. The example you gave is valid but it has a very low chance of occurring and doesn't really cause significant problems. Yes, somebody now has access to two guns. Boohoo. That's only really an issue for life/zombie/etc-style gamemods which are bending a platform to a purpose way beyond its original specifications so I'd find it hard to justify major changes to the sqf engine just to solve a very very niche problem. Maybe there are other examples where non-atomicity doesn't just lead to minor gear inconsistencies but to actual major issues. If you can find one, then I'm sure that'd be a better way to convince people that adding atomic blocks is a good idea :) Even more so, all the examples given here (removing weapons/etc) would be very simply solved by using unscheduled code (right?)

People are discussing two different things here. One is the fact that the terrain LODs do not degrade very gracefully. This means that you can sometimes see enemies "floating in the air" when they're actually behind a ridgeline that is far away. This is also an issue in other games, however it's of course only noticeable in games where you have very long engagement ranges. The other thing is what OP is actually talking about: Infantry units (and not just AI, btw) are sunk into the ground a bit when they are prone and far away. This is intended to simulate them being "hidden in grass" (rendering grass out to 1000s of meters is sadly not yet feasible, even in other, better optimized engines). While it might have been a decent solution when it was first implemented (in OFP?), it is far less acceptable today where the visual fidelity of the rest of the game makes this look like a bug to pretty much anybody who hasn't yet heard of this "feature". The feedback tracker is currently down due to a recent security breach, but one of the highest voted items on there was a very clever and thoughtful suggestion how to replace this "sinking" by a more immersive technique. ( https://forums.bistudio.com/topic/140105-rendering-grass-at-long-distances-my-thoughts-about-it/). As far as I know it was looked at by BI but they sadly decided that it wasn't feasible/important enough (or, more likely, a combination of both) and wouldn't be implemented (at least not in this iteration of the game).

You guys do realize that @Ares is open-source, right? ( https://github.com/astruyk/Ares/ ) Anybody can fork the project and continue developing and improving it!

Indeed, it would be great to see these updated to the 1.54 personal protective equipment system :) It would also be super great if you could make it so that your equipment items show your mod's icon next to them in the arsenal. There's a description on how that works here: https://forums.bistudio.com/topic/185275-how-to-have-custom-icons-for-items-in-the-arsenal/?p=2921960 Since all of these changes are config only (which is about the only part of modding I'm actually capable of doing ;)) I'd be happy to give a hand. EDIT: Another thing I just noticed is that the gun sounds don't seem to have the new "sound tails" (e.g. cool indoor effects). Given access to fitting sounds (either from vanilla or from HLC AK's) this should be a mostly config-only thing, too :)

The colouring has been removed because the tiny bit of UI improvement just wasn't worth the large performance hit (checking every item in every loadout). However, the underlying feature is still there, you'll just get a message when loading your loadout that says "item X not found". Currently investigating https://github.com/ImperialAlex/XLA_FixedArsenal/issues/32to check if this still works after the eden update. (EDIT: Yes, still works)

The scripting workflow is still terrible. Like most others I've found my own little workflow that works well but the fact that you need to manually navigate to your mission folder, create an *.sqf file, open that with an editor that ideally has some sqf highlighting... that's not a great process. The description.ext has been moved "in-game" with 3DEN, so why not try to move scripting in-game, too? (As long as it doesn't break our current workflows). I don't expect to be able to create PatrolOps like mission from within the editor, but it would be nice if I could at least interact with the mission event scripts (init.sqf, initServer.sqf, etc) from inside the editor :)

Oops, you're 100% right. Sorry for the wrong info and thanks for fixing it! :)

Posted solution to non-full arsenal issue on github :)

The launcher crashes when I try to sort by players (descending) in the server browser. (current 1.56 RC)

With 1.56 about to bring some pretty decent mod support to the 'vanilla' game, it would be nice to see TFAR on the steam workshop. I know there were concerns about whether or not you could add arbitrary loose files (especially the critical *.dll plugins) to a Steam workshop mods and yes, you now can. There's obviously no auto-install like there is with PwS or A3Sync but the files will be there, ready for users to manually move them to TS. It would be great to see an official TFAR release on Steam Workshop before 1.56 comes out, the publishing process is surprisingly painless! :)

Thanks for getting back to me so quickly and best of luck with your RL stuff! I'm really impressed by the level of craftsmanship in PO, really looking forward to working with it again :)

Thanks Blackheart, I did read that (It's standard CC-BY-NC-SA), however Roy's website mentions that PO3 is licensed under a variety of CC licenses and it's definitively not unheard of to have certain parts of a mod be licensed slightly differently (e.g. some of it might be CC-BY-NC-ND). I'm fairly certain I wouldn't end up getting sued to hell and back even if I did choose to read the first post as applying to everything, however I'm more concerned with respecting Roy's wishes and not annoying a great scripter unnecessarily :) So far I've simply worked around the apparent restriction by editing only files without those restrictions mentioned in them, however it does mean that there's some 'dead code' in there that I can't touch because it's e.g. referenced in one of the "don't modify" files.

Hey! I saw that the first page of the thread states that the mission and code are released under CC-BY-NC-SA, however in Patrol_Ops_3.sqf it says "Permitted for public release without modification". There are also some other files which include a "do not modify this file" line but do not mention if this is technical (don't modify, might break things) or licensing related. Some clarification would be greatly appreciated! (Oh, and is hosting the mission on a public server considered 'public release'?)

From today's dev branch update. Any specifics? :)

Bit of self-advertising: @XLA_FixedArsenal which adds a few fixes & features my community ended up needing to really make the arsenal work for us: Partial loading of loadouts: Even when some items are unavailable (e.g. mod not loaded/item not currently allowed) you can still access all loadouts (only available&allowed components will be loaded) Way better performance: The system can be significantly faster, especially for large whitelists and large modsets with plenty of weapons/items. Option to disable the 'feature' that makes current player gear replicable in the arsenal even if it's not on the current whitelist. Blacklisting: No more need to list all "allowed" items, you can now also provide a list of forbidden items (might sometimes be significantly shorter, e.g. removing all thermal scopes) Support for force-replacing equipment: Supply an old_classname and a new_classname and the system will replace each occurrence of old_classname in the players loadout with new_classname. (Happens on opening arsenal & on loading outfits). Originally developed as a workaround for TFAR's duplicate radio ID issues, this can also be used to e.g. automatically fix people using the wrong kind of UAV tablet (wrong faction). Usage is probably best explained by looking at the header of xla_fnc_arsenal, all options are listed there. The mod still behaves like the vanilla arsenal in most ways so switching over is not very complicated. Mostly just replacing "bis_fnc_arsenal" with "xla_fnc_arsenal" in your ammobox script and, if you want to use some of the optional features, adding a few (optional) params to the call.

Thanks for keeping people updated :) The issues we experienced turned out to be unrelated to the actual "addon" part and instead seemed to have something to do with mission initialization being a bit unreliable. If you're using a complex whitelisting script, I recommend adding a simple sleep 10; at the beginning. On github you can find the current "development" version that has all the tiny changes that were made to the vanilla arsenal between 1.42-vanilla-arsenal and 1.54-vanilla-arsenal. Since all those changes seemed fairly unimportant no update is currently planned. From my point of view the mod currently does the job required for our community with any issues we currently have being caused by/fixable by changing the whitelisting script rather than the addon. There are still a few items on the "feature wishlist" but unless it gets broken by a game update I'm considering this mod "completed" for now. If you feel like there's some critical feature missing then please feel free to fork the repo (or Push-request/ask for write permission) :)

I'm really looking forward to this. As SilentSpike said, just the change of camera controls is worth celebrating :)

Visibility is linked to editability, so you'd need to addCuratorEditableObject (with 'false') those units. However then the Zeus can't give them orders anymore.