kenoxite

I created several spreadsheets with listings of all the units, but this was done for a previous version (v0.7 or 0.8). A lot of things changed since v1.0, the most notable being that now all infantry units use custom variants of the vanilla WW4 weapons. Names are mostly the same, though, so where before it was, say, WW4_W556_30Bmag now it woulb be WW4EXT_W556_30Bmag, etc (so, from WW4_ to WW4EXT_). There's hundreds of new infantry and vehicle units in v1.0 onwards than it's listed in those spreadsheets, but it should give you an overall idea of what's available. I tried to keep naming conventions as coherent as possible, so once you get the idea of what a name of a role is then all you have to worry is about what the prefix of a given branch or faction is (WW4EXT_MUSARGrenadier, WW4EXT_DFMOTGrenadier, etc, prefixes being WW4EXT_MUSAR and WW4EXT_DFMOT in this case). The spreadsheets should be updated, but it's such a huge and boring task that I can't assure you it'll be done, or that it'll be done in a reasonable time frame. But even if you have to dive in the pbos you shouldn't have to have a hard time finding things. ww4ext_inf_cfg.pbo and ww4ext_veh_cfg.pbo are extremelly modular, with all the different unit classes clearly divided by either camo type/branch or side.

I really like Texel island, that's the island where I was testing my tropical units and the one I was going to promote if I were to release my tropical stuff. It's quite close to a central-american setting, and it's really, really well done. Working download link: ftp://ftp.ofpr.info/ofpd/unofaddons2/Texel_Addon.rar Jungle Everon v1.2 is also very nice, although this is clearly south-east Asia flavored.

Well, that's both tricky and it's quite likely not allowed (unless you get permission form the author/s). IIRC GL3 was very interwinded with SLX, and TBH I can't recall right now which feature belongs to which part (to SLX itself or to GL3). But, who knows, maybe someone will take on this and go through all the hassle.

kInfoshare updated to 1.1 Download: https://www.mediafire.com/download/rmngdot59902tti/kInfoshare_v11.zip Changelog: * CHANGE: in2Darray function is now embedded in the main script * CHANGE: revised parameter parsing and assignment of defaults * CHANGE: Expanded comments and descriptions The script itself, for those who can't access mediafire:

Group Link started in OFP (by toadlife), so there's a native GL version for this game. Latest version that I'm aware of was II (2, updated by keykat). You can get it here, and it works in both OFP and CWA: http://www.ofpec.com/editors-depot/index.php?action=details&id=273&game=OFP It's not as powerful and complex as the Arma2 and beyond versions, but that's because the ability to manage AI units via scripting commands is very limited in OFP/CWA when compared to the newer games. For instance, Group Link II allows suppressive fire, but only when the player is the one shooting. It also only works reliably by default with vanilla units and weapons. EDIT: Just checked the GL2 readme again and it seems it also requires Kegetys' Editor Addon v1.11. --- I just realized you meant GL3 for OFP, the one that is bundled in SLX.

I see. It's also correctly displayed on Chrome. But it's faulty in my Firefox 40.0.3. Although I have yet to test this without addons enabled (in safe mode). EDIT: Just tested it. It doesn't work on Firefox even in safe mode. It doesn't work on IE 9.0.8112.16421 either. --- It works on Microsoft Edge, though.

I stand corrected then. Still, I was able to "fix" it by modifying the shape of the upper part of the gloves. It doesn't look natural, but at least the hands are linked to the arms now.

Hmm... I'm afraid that doesn't seem to do anything. EDIT: Ok, I managed to make it work by just typing the link without the media tags. Such as: http://imgur.com/a/NXoiC So I'll use that format from now on. The albums don't seem to be updated, though. I'll keep waiting until tomorrow. But now I'm not sure who's doing the caching: your server or imgur's. -- Something else: placing an album inside spoiler tags breaks it (it doesn't display properly). Test:

Thanks for this feature. It seems this option will also help lower the load of the pages, as we can now simply embed full galleries instead of individual images. I embeded a couple already here. It seems to work without problems. EDIT: Actually, there seems to be some kind of issue. While in the linked post both albums show up without problems, the second one in the first post doesn't. Are albums under the limit of 30 images per post? That's the only explanation I have right now. EDIT: Hmm. It seems imgur itself doesn't send the latest status of an album immediately. There seems to be some lag between any change you make and being able to see the updated album inside a post. If so, then the second album might not show up because I embedded it first, edited the album itself (removed some images) and then posted it in this forums. If so, then it's a matter of waiting a few hours to see if the album shows up. If by tomorrow or so the album still doesn't, well, then there might be something else.

Would it be possible to be able to embed imgur albums? There seems to be a free IP.Board extension already.

A bit of info dump related to the development of WW4 Extended: Stats How many infantry classes does EXT add? 1074 And the Cold War module? 238 And Arctic? 176 WW4 Extended adds 1488 infantry unit classes. How many vehicle classes does EXT add? 291 And the Cold War module? 90 And Arctic? 46 WW4 Extended adds 427 vehicle unit classes. How enemy identification and detection for AI works in Ext https://imgur.com/a/xxGka (check the image descriptions at the bottom for more info) Basically, Ext units inherit four base classes: Random person - This sets the basic stats and it's identified as neutral (Man, in yellow). Generic soldier - This sets the basic stats for soldiers and it's identified as neutral (Rifleman, in yellow). Faction soldier - Sets the basic stats for a normal Ext soldier and has side defined (Rifleman, red if enemy) Role soldier - Sets the specific stats for the role of the soldier (<Whatever role the unit has>,red if enemy) This gives awareness to Ext units of other enemy or neutral nearby units without giving them total knowledge of their side or role. That information is only gathered by AI units when those units get closer, similar to how a human would do it. Once a unit has been revealed (by the naked "eye" or through magnified optics, such as binoculars or rifle scopes) all proceeds as you would expect with WW4 units. Another difference between WW4 Ext and vanilla WW4 is sneaking. In vanilla WW4 sneaking around enemies is not possible (due to increased hearing abilities). In Ext, the units hearing is similar to BIS default, but the noise generated varies by their unit class. Noise generated is higher for regular soldiers and lower for civilians and insurgents (they have little to no gear) and SF and recon units (they are trained for this). In general, it's closer to vanilla OFP/CWA behaviour than to WW4. You can see all this stealth system working in this test/showcase mission: https://www.mediafire.com/download/t4au5lsi2l1gnkl/_ext_stealth_test.eden.zip You have an SF and regular Ext unit to the left, and a SF and a regular vanilla WW4 unit to the right. Test this mission using several speeds and stances (walking, jogging, running, kneeling, crawling, etc). The dots over their heads indicate if they have spotted you: not detected (green), suspected (yellow), detected (red). Unfinished and on hold (indifinitely) https://imgur.com/a/OJJDL The glitch in WW4 skeletons where the hand glitches out of place when holding handguns was particularly evident in these units. I finally had to artificially elongate the gloves, which solved the "broken wrist" (particularly noticeable in first person) but made the hands look really weird. All that was part of a module for Ext I was working on but never got to finish, centered around Tropical conflicts (center and south America, SE Asia). So it's now in the same bag as NBC and flashlight units. Changing sensitivity and armor values of infantry units As you have seen, Ext changes the way units detect and engage quite significantly. It also changes the way infantry armor is calculated and assigned. Regarding armor, two changes are particularly relevant: The armor of arms has generally been upped so it's similiar (if not identical) to that of the torso. This was done in order to prevent what I call "death by arms", where units die from a shot to the arm in most cases due to the way the animations are set (where arms are covering most of the torso 90% of the time). Now a shot to the arms deals the same damage as if it were the torso. The armor of legs has been upped. This was done to prevent the usual and annoying (from the player's game experience and gameplay POVs) situation where you have to crawl the majority of a mission due to an unlucky early leg injury. Note that you can still lose mobility, but it's more difficult now. Also note that this change of armor values is closely tied to the built-in and forced hit EH in all Ext units, where shot units will generally lie down when shot at. So, visually and from a gameplay perspective the effects are similar, without all the annoyance. Also, armor values in general are now tied to the one that the unit is actually wearing. Units with PASGT vests are worse protected than those with IBA, those without helmets have the most basic armor value in their heads, etc. All these values are tied to the new Ext versions of the vanilla WW4 weapons, so IBA vests can take up to 3 7.62 shots, PASGT about 1, etc. While damage values of the weapons are mostly the same as in WW4, the Ext versions have other changes that can break this balance if you use other weapons. This same rule applies to anti armor weapons (AT launchers, etc) and Ext vehicles. All these values (armor, sensitivity, and also camouflage, etc.) are set by using defines, in the definitions.hpp file found in ww4ext_inf_cfg (in the v1.96 compatible infantry config all this is already preparsed, so you must search for it in the main config.cpp). definitions.hpp has defines for WW4 Extended, vanilla WW4 and vanilla BIS values. This way you can easily set the value of any given unit type just by changing the define to be used (to revert them back to vanilla WW4 values or maybe change the Ext ones). That file is also heavily commented, so you shouldn't have too many problems knowing what's what. -- EDIT: Added more info about detection; added link to stealth tests mission; info about changing values of infantry units; embedded the albums now that we can; corrected some things

Good to see you managed to solve it. TBH I didn't pay much attention to your spawning scripts, I guess I should have :) From now on: make sure everything related to AI units (spawning, issuing orders, etc) is managed by the server only. In general, only run scripts on clients if there's no way around it or it's a task that must be done by clients (like onmapsingleclick). And, when in doubt, check the wiki often, particularly for the information about locallity of each command if you're doing multiplayer.

Ok, I've done some tests myself with a custom version of what you're doing here (in move3.sqs) and all seems to work fine. So, let me recap what you're trying to do: Player chooses the option to select a unit via a dialog move.sqs: The dialog option launches move.sqs with a parameter, that you assign to msel, and you ask him to click on the map to select the units move1.sqs: Then you place the trigger of msel type on the clicked position, and a placeholder (helpm1) to "store" the selecte position, then ask to click for the destination move2.sqs: ??? (you forgot to copy/paste this one, I guess you place the helpm placeholder here) checkm.sqs: Meanwhile you have this script running all the time, which checks if the move global var is true, and if so launches move3.sqs and sets it to false move3.sqs: Runs only on servers. Moves again the type of trigger selected (via msel) to the position of your first placeholder (helpm1), and then orders all units inside it to move to the position of helpm (which I guess is set in move2.sqs). And, while all the global vars are correctly set and passed (msel, helpm1, helpm) the units don't move. You don't need to move the trigger in move1.sqs, as all you need is the helpm1 object. And not knowing how move2.sqs is written I can't tell you if the problem is there (but, if your problem is that units aren't moving, and helpm, which is used to set the destination, is set in move2.sqs... well, that sounds suspicious). Other than that, and unless something very obvious has slipped me by, this really seems a task you must solve yourself. Chop all this system into individual pieces and test them separately, then keep adding until something breaks. And print all the vars all the time, so you know what's going on. That will save you some headaches in cases like this.

Ah, yes, that must be it. Anyway, remember that anybody is free to edit the materials found in this addon to suit their needs or personal taste. Unpboed versions of the two of them are found where the addon is installed.

Hmm... that looks a bit far fetched. Have you tried this already? (not sure if it's still relevant)

It'd be better if you debug all the variables in move3.sqs. That will give you more hints about what's being correctly passed and what not, and then work from there to trace the bug back. Anyway, move3.sqs has other problems. You should run it only on the server. AI units (those not in the group of a player) are handled by the server, and only the server should be dealing with them. Also, doMove (and any other "move" order) is local/global, meaning that the unit must be local and the command is automatically run on all clients. Although I would support Zulu1 suggestion regarding the creation of groups instead of single units, unless you want them to be single for some reason. Remember that in OFP the unit count limit for each side is 63.

You should be able to toggle text radio messages in: Options > Difficulty > Radio subtitles enabled.

What do you mean, exactly? I'm asking because in the initial version some textures from one of the tanks (the BIS T-72 IIRC) weren't added to the lists, so parts of it didn't have materials applied. That was fixed in the latest patch (the one included in the installer). But there might be other BIS vehicles with some other textures missing. Could you give me a list of the tanks you found faulty, or do you mean all of them? Also, if you were using tanks from addons (SIGMA's, etc) they won't have materials applied. You'll have to create your own addon with those textures included in the material lists (there's a template already included in the installer for you to use) and their models must also have to be binarized or it won't work (like with Berghoff's vegetation packs, which are included but they won't display materials until someone with a lot of time binarizes them all). While this project includes hundreds (thousands?) of textures from other addons, I only added those of terrain. vegetation and objects. The only units (infantry and vehicles) added are BIS defaults and WW4 Extended ones (maybe some from SEB's Nam too, can't remember). This is because this project was initially to be part of Ext, but I finally released it standalone (hence the unoriginal "OFP materials" name, as it was just a placeholder name to differentiate it from the WW4 Extended materials).

As krzy says, you are better of using defines to do what you want to do. Inlcuding files so many time seems a bit overkill when you can include once a file with a list of defines. I used this approach for a lot of configs in v1. It gives you extensive modularity and makes it easier to follow and edit them (at least it does for me). The only downside is OFP compatibility, as mentioned. While CWA can preprocess almost anything like a champ, good old OFP can't even start if you go overboard with all this (and I definitely went - once preprocessed ww4ext_inf_cfg.pbo is probably the longest config in the history of OFP/CWA). Just note that if you give each infantry class (of the same "branch") different ruck ammo depending on role then the you're better off just manually writting the loadout of each one in their class area, or you'll need one define per role, which kind of ruins the point of a define. That's what I did for the infantry classes in v1, as you might have noticed already.

To clarify, as OP was referring to init EH regarding Ext units: In Ext v1.0 onwards all infantry classes are derived from a handful "master" ones (which can be found in ww4ext_inf_cfg\base). Those parent classes only have a basic init EH (the one that I first posted in this thread). That means that if you create a child class from any of those, it will inherit the mentioned init EH. That also means that it will spawn without rucksack even if you place the corresponding logic. To assign rucksack and ruck ammo to a new class you still have to define a new init EH there, where you make a full call (all parameters passed) to the eh_infantry.sqs script. So, yes and no, in the context of Extended. If the new classes bennysouthst is creating are children of the "base" classes then they will inherit the basic EH. There's no need to apply any new one (but, remember, no rucks). If he wants the new classes to carry rucksacks OR he's creating new ones from scratch (maybe the parents being the vanilla WW4 infantry classes) then he has to define a new init EH, as pointed in my previous posts.

Expanding on what Maczer said: Double quotes: that's just a way to make sure the engine won't stop reading after it finds the second quote once it parses it. The content of EH in a config must be inside quotes (init=""), so if you write some code inside those quotes that also needs further quotes you must use double quotes ("") instead, so the engine knows the new quote is inside the other quote and shouldn't close it. Alternatively, you can also use curled braces ({}) or single quotes (') instead of double quotes ("") in most cases. But for configs I found that brackets wouldn't always work. More info on strings here. _this select 0: All event handlers return their values as an array. Even if the init EH has only one element (the unit) you must still reference it as an element of an array. When we call the eh_infantry.sqs script we need to pass the unit we want to initialize all the EXT stuff on. As we're doing this in the call to the init EH (_this, the full init array) we must get the value of the unit from the init array (select 0, the first -and only- element of the init array). More info on arrays here. And on select here (spoiler: select is used to pick the value of an element of an array, as noted already).

Not to mention that gamefront simply doesn't work for almost half the World. See the list of banned countries here. IMO that place should be avoided for mirroring. Too bad there's still a lot of old content that can only be found there.

You need to define the init eventhandler of any new unit unit you create: class EventHandlers { init = "[_this select 0] exec ""\WW4EXT_scripts\eh_infantry.sqs""; "; }; This will work as long as you still require vanilla Ext or include the "ww4ext_scripts.pbo" file in your version. -- EDIT: Something I forgot to mention myself but that was covered already by krzy: The second and third parameters are used to specify the rucksack and rucksack ammo that the unit will use. So the full format for a call to the eh_infantry.sqs script would be: [_this select 0, [<class of the rucksack>],[<ruckack ammo classes>]] exec "\WW4EXT_scripts\eh_infantry.sqs"; The classes of the rucksacks themselves and the rucksack ammo can be found inside the MAP_Rucksack.pbo (in cfgWeapons.EXT.hpp and cfgRuckMags.EXT.hpp, respectively). I made several spreadsheets covering the classes for almost everything found in Ext, but they were done for the things included in the 0.8 version (or so) only. I guess they should be updated and expanded. Eventually.

Good, good. I'm finally discharged! :) Feel free to lock this thread to avoid further confusion over where to report things.

Bugs and glitches: Links to latest posts are malformed for not logged in users. They lack the ?view=getnewpost parameter. Only the link to the date (such as: Yesterday, 14:50) has that parameter. Threads with polls light up as unread every time a vote is made. You can vote on your own threads. I mean, the stars at the top of a thread. Missing features: Features that were present in the previous version of the forums that haven't been implemented in the new version yet. Missing ability to set the amount of posts to be displayed per page. Missing badge display in posts for supporters. Currently badges are only displayed in the Profile page. Missing the Community groups. Missing bottom panel showing server time, etc. Smiley selection is way too limited. At least compared to the previous version. Missing ability to set format of time and date. To 24h, american date formatting, etc. Missing ability to state a reason when displaying the "Edited by" text. Missing ability to export PMs as xls. While the "Archive this conversation" feature might help with saving PMs it still seems quite limited compared to the ability to export as xls. Missing button to easily insert videos in posts. Meanwhile, you can embed videos using this format: [media]https://www.youtube.com/watch?v=<ID of your video>[/media] or just: https://www.youtube.com/watch?v=<ID of your video> Missing more forum layouts. There's currently an user made Dark Theme that could be of use to you devs. It's not possible to embed Daylimotion videos. Partially solved or unkown status issues: --- Suggestions and Inconsistent/Suboptimal behaviour: You are directed to the main forums page whenever you log in. You should be redirected to the page you were viewing before logging in, as it happened in the previous forums. Quote or multiquote isn't available in the "Reply with more options" or "Full editor" screen. I mean in the list of posts shown there. IIRC this was also the case in the old version, but it'd be nice to have. The Friends list doesn't seem to serve a purpose right now. One would imagine that they would work, among other things, as a "Contact list", so you can easily select any of them when creating a new PM. Yet, there's no link nor any other way to access your Friends when composing a PM. No inheritance in forums selected via "Filter by forum" in New Content. While not an issue per se, this isn't the behaviour I was personally expecting. I thought that by selecting the parent forum ("or subforums hub", such as the ARMA: COLD WAR ASSAULT / OPERATION FLASHPOINT one) all the children elements inherited that selection. Actually, you have to manually click every single subforum for this to work as (I) expected. If this behaviour stays, you could as well remove the parent ones, as selecting them does absolutely nothing and just confuses things. uBlock must be disabled to proceed correctly through the login process. The conflict lies here: Static filter /setcookie? . As in: https://account.bistudio.com/setCookie?client_id=... It's part of the EasyPrivacy filtering. APB seems to also conflict with the login process. Font styles and link format bleed to the blank space after a word or line break. As in: underscore strikethrough link etc. It'd be preferred to contain all that to pages and have styles close after line breaks. The current forum layout uses way too much vertical space. Multiquote limit is inconsistent. While it allows you to multiquote a whole page (20 posts) you won't be able to post that unless you trim it to 10 or less quotes. Search function doesn't allow common scripting/modding or military terms if they are under 4 characters. Such as sqf, sqs, COP, FOB, etc. There's a hard limit of 10 maximum images per post. This limit seems a bit too strict. Latest unread post in a locked thread. Ignore signature popup is clipped. Member since display on post bio. Only shows up on the profile card when you hover over username. Mark threads/indication if BI staff have replied. Custom Syntax highlighting of code. Tapatalk integrated functionality. It is installed however there are issues in the testing we have been performing. Unfortunately, there will likely need to be possibly some changes to Tapatalk client software, because of the unified BI account system. Solved issues: Non-issues that were reported as issues: Won't fix / Add / Re-Implement: