kenoxite

OK. Thanks for testing this. I think I'll just use the preprocessing tool again and keep the godzilla sized infantry config as is, like in the previous versions. I don't want this issue to stall the release for too long and Krzy, who has always been the one testing this compatibility issue, isn't around so far. And TBH this new approach of splitting the config into several ones causes me more troubles than what is worth.

@JdB: Thanks. It'll be ready soon. -- Meanwhile, I need someone to test this new configs for infantry with a copy of OFP v1.96: https://www.mediafire.com/download/d77ni38767it5uv/ww4ext_new_inf_cfgs_test1.zip You only need to place all those in the "WW4_EXT\addons" folder and either rename, move or delete the existing "ww4ext_inf_cfg.pbo" file. Once you've tested it, just restore the old ww4ext_inf_cfg.pbo and delete the new ones. It will probably give you some errors, that's to be expected, but what we're testing here is that by chopping the main infantry config into smaller ones should be enough for old OFP not to crash. So, if it crashes: bad. If it doesn't crash but spew some errors: good. Then obviously reply here with your results. Thanks and here's a sneak peek of the next patch: (is the 90 something kb limit for images still up?) Also, as you can see, there will finally be a couple new models and units. I couldn't help it.

Glad to see you back :) Just chimming in to let you know that if you are interested in anything from WW4 Extended you just need to let me know (vehicles, textures, etc). Regardless if you use anything "as is" or you want to tweak it it's always faster and easier than starting something from scratch.

I'm afraid that's not planned, sorry. -- BTW, the next patch will be released in the following days. It will include the fixes already posted here, plus some others reported or not that weren't patched already. For the most part those are harmless bugs, though. The patch will also include some new features and objects, but no vehicle or infantry units (there won't be no more of those, at least not for the main project). There's also quite a lot of revising and balancing (things such as recoils, dispersion, body armor vs bullet damage, etc). The changelog is quite lengthy TBH.

@Fruitpunchsamurai: thanks for reporting! @spirit_jat : A patch has been worked on in the last weeks, although lately there's not much free time. I think I could release what I have about this weekend or so, but there's some things that I'd like to further test or revise.

Because even with all its faults, it's still better than your mom.

In DAS\Client\Start.sqs you need to change this line: _action = player addAction ["AIR SUPPORT","DAS\ShowDialog.sqs"] to this: _action = player addAction ["AIR SUPPORT","DAS\Dialog\Dialog.sqs"] I've created an WGL version of the default mission in Everon. You can grab it here and see by yourself all that was changed.

No, it was the mission I linked, the one you tested already. Anyway, maybe it was a weird coincidence caused by who knows what. I'd check the scripts myself but I'm rather busy lately.

There seems to be some issues when autocompleting both login fields via a 3rd app or browser extension. As in, it doesn't enable the LOG IN button unless you "activate" the username and password fields manually (say, by placing a space at the start of each field and then deleting it, to poke and wake up the input field). This is happening to me with the KeeFox extension (a Firefox extension for KeePass) which I'm using since LastPass was acquired by LogMeIn.

It's the mission template that ProfTournesol included with the mod. And read "template" as just a normal mission in its barebones that you are supposed to Merge (via the mission editor) in a new one to speed up mission making with this mod. Weird. And, yes, I was aware that the issue only happened once you pbo them. That's why I was puzzled about this issue. Regarding pressing space bar, the ammo didn't even show on the gear menu (nor mine nor any of my team mates).

Yes, I noticed the disableAI "target". I have mixed feelings about that,though, as it also makes units under your command non-responsive to engage commands (and we can't toggle disableAI in OFP, just use convoluted workarounds). But I guess it's OK for just AI squads. Anyway, I don't think it should be an issue in a mission if you make sure you use "hold fire" or "never fire" while the units are travelling to the battlefield. Once there, they should be in range, so no engage orders (or very few) should be issued by the AI. What I've found more annoying and, unfortunately, unsolvable, is the default combat behaviour, where units will move towards "cover" positions (bushes, trees, etc) by themselves, breaking formation. Other than disableAI "move" I don't see a clean way to fix this. Possible solutions like "doMove" loops are simply inefficient and make the poor OFP AI behave worse than usual (as they try to keep domoving in position instead of firing). I wasn't aware that they would actually lie on the ground. That's great, as it simplifies some things, such as the need to force a stand up. This would also solve one of the problems I was trying to solve when doing some tests myself with your mod, where units standing up behind a friendly line where all are crouching won't fire. My guess for this weird behavior (weird because logic dictates that you should be able to safely shoot over a crouched friendly in front of you) is that for the crouching you must set the units to "stand up" (setunitpos "up") and the crouching is actually a playmove (playmove "crouch"). The engine must just read the standing position (up) and then assume the line in front are all standing up, hence forbidding the line behind from shooting. BUT, if lying down is allowed then you could force the first line to lie down. This should allow both the first and second lines to fire. Regarding the problem with the ammo, I was just testing in the mission I used to create those screenshots. You can check it out here: https://www.mediafire.com/download/5o9xw5pzxailhlc/FPW_tests.FPWnoe.zip I tried to be a grunt in the prussian line, but none on my team was issued any ammo. Other than a different arrangement of troops and waypoints the mission is just a copy/paste of your battle template. I've tinkered with it a bit, mainly on the init.sqs. Then there's also a custom openfire.sqs which I use in that test to coordinate firing orders. You might want to consider uploading your mods to moddb.com. You'll definitely reach a wider audience there. Because, you're right, around here most of us are just modders, scripters, mission makers and such. Which is nice because it let's you release in a quite friendly and constructive environment, but has the drawback of most players being elsewhere. Players that would most likely love to play with some of the stuff found around here but aren't because they are not aware of it.

Great work :) May I suggest setting closer formation distance as default for infantry? I've tested it setting both x and z to 3 and it works without problems while also offering a more proper firing line. This should also allow you to skip some of the formation scripts in missions, recovering some performance. Check this album: https://imgur.com/a/vDm4p The part of the config that was modified: Also, to avoid units lying down when in combat you might want to add this line to your battle template: ~1 {{_x setUnitPos "UP"}forEach units _x} foreach arrayi; Apart from that, I wasn't able to enable ammo for my team (as a grunt, not squad leader) even when placing the ammo fix logic.

The ruck mags only use the handgun slots, so that's the limit (4 slots IIRC). I see that I placed 6 in my example from the previous post. I'll change that to avoid further confusion.

I actually spotted the problem with the marksman in that group last week, so I know what you mean. There's also some other tweaks that need to be done with the stryker mech groups anyway (such as using the MG versions instead of the GL ones). Thanks for the clarification about the AH1Z. Regarding the script (the sqs file) you must create it yourself. It should be placed in your mission folder (the same where your description.ext is). Just create a new text file, paste the code I posted before there, and rename the file so it ends in .sqs and not in .txt. This process is the same whenever you have to create a new script. BTW, if you don't mind, could you separate your posts into paragraphs? That would make them way easier to read. Thanks!

Why should you apologize for trying to help? Don't be silly :p

Thanks for the bug reports. I'll check them out. Regarding the ruck mags: Both the backpacks and the rucksacks are added to the units after they have spawned. That means that there's a small time gap between the spawning and the final gear the unit will use. Anything you place in the init line will be executed as soon as the unit is spawned, so you are actually removing a magazine that doesn't exist yet and adding a new one that is replaced when the EXT infantry script kicks in (gearing up the unit). So, how to work around this? You must place a pause (0.1 is probably enough) before changing or deleting the ruck mags. You need to create a new script to do this, as you can't place sleep calls in the inits of the editor. Something like: You could name that script "swapRuckMags.sqs", and would call it in the init line of each unit like this: [this,<class of the mag you want to remove>,<class of the JAM mag you want to add>,<amount of JAM mags to add>] exec "swapRuckMags.sqs"; Example: [this,"map_ww4ext_w556_pdm","whateverJAMclass",2] exec "swapRuckMags.sqs"; If it still doesn't swap the mags properly, then you need to increase the waiting time a bit and keep trying. I looked into this and it's an easy fix, but I spotted some weird behaviours in the script pbo and wanted to revise and fix what's needed before releasing a quickfix. As it seems it's not going to be done soon due to time constrains, this is what needs to be changed to avoid the "Heal yourself" action menu spam: In ww4ext_scripts\EH\killed.sqs change comment out the two last lines before the exit, so it ends up like this: Then recompile the pbo. EDIT: whoops, used the wrong quote!

It's a syntax error. The contents of the define must be in a single line. If you want to separate a define in several lines (for readability, etc) you must add this symbol \ to the end of each line (even if it's an empty line) This is wrong: #define US_ARMY_AA weapons[]={"WW4EXT_M4Aim","WW4_Beretta","Throw","Put","AALauncher"}; magazines[]={"WW4EXT_W556_30mag","WW4EXT_W556_30mag","WW4EXT_W556_30mag","WW4EXT_W556_30mag","AA Launcher","WW4_berettamag","WW4_berettamag","WW4_berettamag","WW4_berettamag"}; This is right: #define US_ARMY_AA \ weapons[]={"WW4EXT_M4Aim","WW4_Beretta","Throw","Put","AALauncher"}; \ magazines[]={"WW4EXT_W556_30mag","WW4EXT_W556_30mag","WW4EXT_W556_30mag","WW4EXT_W556_30mag","AA Launcher","WW4_berettamag","WW4_berettamag","WW4_berettamag","WW4_berettamag"};

If after Maczer advise you aren't able to solve this problem feel free to share your defines. The problem seems to be located there.

Cool. But it'd be better if you remove the link to Kodiak v1.1. WW4 Extended already includes a custom version of that island which uses buildings with removed window panes. This was done to avoid the problem with WW4 units becoming invisible through them. Those window-less buildings are found in vanilla WW4, so this version of Kodiak isn't standalone (it requires WW4). When you install WW4 Extended you already have the correct version of Kodiak, as it's bundled with it. Linking the the old non-WW4 compatible just confuses things further.

I was only able to test this in local MP and just by myself, but it looks good so far. A couple things: Skye has some addon dependencies that weren't included in your zip file. I guess you used v2, found here. It'd be better if you make all those markers invisible (type "empty") at the start of the mission, and change them back to whatever the icon you need is when needed. While you've placed them out of the way, they are still visible by all the players and it's quite immersion breaking and somewhat annoying. Other than that, all the options I tested seemed to work fine in my limited tests. The Zeus menu interface could use some cleaning and repositioning so each area is more clearly divided (spawning, AI orders, teleporting, etc), but I know what a pain creating those dialogs is, so I can sympathize if you just leave it that way. There's also the inverted Z in the Zeus particles display, but that might be a stylistic choice.

I'll look into this. The invisible targets for infantry aren't actually deleted. They are spawned in bulk (a full team of 12) and then repositioned back and forth as requested: from their original spawn position to the positions requested by the "suppression" script and, once it's done, back to the original spawn. The ones for vehicles are spawned on request, though. Were you shooting infantry or vehicles? Thanks for the report.

Zeewolf did something related to this feature here. Unfortunately the download link is down, and I don't have it anymore. Maybe Zulu1 still has it around? -- BTW you surely want to change your username so it isn't your email. That's an invitation to spam and other malicious activities. Post a request in this thread or directly contact BohemiaBeck.

kInfoshare updated to v1.2 Download: https://www.mediafire.com/download/isz92piv9bawpe8/kInfoshare_v12.zip Changelog * NEW: Added distance limits at which enemy units won't be reported depending on the type of group of the receiving friendly group (infantry, air, land or water vehicles). Editable in the SETTINGS area. * CHANGE: Removed requeriment to set comm distance for renegade groups (as it was unused anyway) The script:

I just had a look at the GL3 version included in SLX v1.1 and it seems you can safely extract it and use it as standalone without too many errors. I haven't checked the SLX version included in FFUR+SLX v2.5, but I guess the files and process I'll describe below will be mostly the same. To use GL3 as standalone you must move the following files to an addons folder of your choice: @SLX\SLX_GL3_Settings.sqf @SLX\Addons\SLX_GL3.pbo Then you should follow the GL3 instructions found in the readme inside the pbo. Or if you don't want or don't know how to unpbo that file, then read this copy/paste of the readme: You'll have to change some values in SLX_GL3_Settings.sqf to remove some addon dependencies, as seen in the "Addon dependancies/extra features:" part of the readme. With that said, I found that OFP still complained about some missing entries in the SLX_GL3 config.cpp file. To enable GL3 for groups you should paste this on the leader of each group: [this] exec {\SLX_GL3\SLX_Init_GL3.sqs} But you should first define SLX_GL3_Path in the init.sqs or whatever was the first unit you placed in the editor. Just copy/paste this: SLX_GL3_Path = {\SLX_GL3\}; All this should supposedly make GL3 work as standalone. BUT... (and now comes some self promotion) If you just want a suppression system you can always use kSupression, by yours truly. Unlike GL3, kSupression just deals with suppressive fire and must be enabled in a per mission base (it's not addon based). And unlike GL3 it works both in single and multiplayer.

Not bad. Now get back to work