Leaderboard

Work on the modification stopped as of 2015.

We proudly present the revamped New York City Modification v2.0! Currently still in heavy development, we have been working on a new version of this mod. The mod will contain many new features, such as a progressive style of gameplay, unique missionscripted events, interface changes, new functionalities and -of course- a new map. In this first report we'll show you pictures of the new map we're working on. The new mod is fixed in a post-9/11 era to about 2008. We didn't want to focus on updating vehicles constantly, instead we're focussing on improving gameplay elements, trying to keep the game challenging and fun. We'll release more information regarding gameplay changes later. The new map is fictional and won't be a copy of a real part of New York City. Instead we choose to make a more compact map with many (downsized) landmarks and influences from New York City and the North-Eastern American environment. This way, the map will provide a lot of variation with many things to get into. Pictures say more than words, so have fun watching the editor screenshots below: New screenshots 04/13/2015: In regards to current mod status: the core gameplay elements are done, but the new map isn't even halfway done and still requires a lot of work. Don't expect a release anytime soon.

Well, I know for a fact you can have duplicate versions of a mod on the same computer in the same game; I've done it before when modifying or tweaking an existing mod package for testing purposes. In those instances I edited the xml to display a diff name in the game and gave the root folder a diff name... Chances are users experiencing problems confuse the two (the original mod which they tend to keep) and the clone of it, since both folders would have identical structures, folder names, and in some cases files it is rather easy to make such a mistake. The advice itchboy is providing is the most prudent if you're creating a mod, even if you intend to use content from another mod within it, the logic behind it being that you would transfer only what you require for the functions/assets you need while leaving behind all the things you don't. The time lost in doing this is more than made up later for a number of reasons which I'll explain further down. It will cost you a bit of time in re-creating the package yourself but it will ensure that what you have in that package is exactly what you need minus things that might conflict or cause confusion later. Not to mention the fact you'll also be able to test each component you add piece by piece instead of potentially having 20 different items which have problems and being unable to sort which ones are causing the problems (seen many mods die because of catastrophic CTD bugs because they added too much junk at once and didnt know what was causing the problem). The benefits of creating a new package and setting it up yourself: You control the file structure for the mod since you're setting it up - Means you can make a more "logical" structure for you to understand where your assets are instead of relying on other people's sometimes confusing structures. You can go through and sort out any potential bugs/conflicts when doing this because you can (and should) add each component piece by piece testing them in between of adding more functions/features to the new package. - This game is very sensitive; as such adding tons of stuff at once usually results in at least one fatal flaw existing and if you add too much at once it's nearly impossible to hunt down the cause (especially if there is more than one cause). Always go slow and add piece by piece, it might be slower but it'll save you tons of headaches later if you do encounter a crash since you *know* from previous tests that everything else before the latest thing worked fine and stable. You can eliminate excessive/un-required files from the modification, thus improving performance (load times in particular) and mod file size. - When people create "sub-mods" they often times leave behind tons of files from the original mods which they don't use, particularly when they just merge pieces from several mods they tend to have massive mod sizes which in turn hurts the performance of the game/mod. The more crap the game has to load the more resources are being chugged for things that it won't even use, coupled with the longer load time and mod filesize it just isnt a good practice. Far better to make your own pack to ensure there are not such files cluttering the thing up. You don't have to go through later on and "clean" the modification up, since you setup the structure and added only what you needed, in theory adding things in as described above will save you tons of time/effort since every file you have is required and every file is neatly stored in the same structure; Also you won't have to remove un-required files later which takes a ton of time to do later (which is why many sub-mods never do it and still in their latest releases continue to have the "core" files from the original mod). - Having everything neatly structured means less effort when it comes to modding the scripts, finding files, etc; You know where you put fire stuff for ex, so it's simply finding that one folder instead of possibly 4-5 of them and figuring out what is where. This fact also means you're less likely to encounter errors in said scripts because of invalid/incorrect paths since the directories used would be universal and logical for each grouping of assets. Problem solving with a "clean" logical structure is much much easier since you know everything you've added, and if you add them piece-by-piece you're ensured that you can say "well it worked yesterday before I added XYZ" so you know where you should look for the problem, and could remove the offending item(s) to verify that they were the problem. This alone would save tons of time for you in development of a mod. Even if you make a new structure with a new package it would still be a sub-mod if you're using a good chunk of another mod within your package, so it should still be considered/treated as the sub-mod it still is. The good thing is though, as you progress if you continue to make it more it's own mod, and give it custom content unique to it and it alone you'll already have the structure in place and all the "core" work sorted out so as you "phase" out the sub-mod content and become your own mod, you won't have to go through doing all that later. That in of it's self saves a massive bit of time. Just my advice and the reason I think this way, it's up to you if you wish to invest the time in doing it. From my experience the invested time in the short-term is more than made up for in the long-term from not having to do it later when the mod tends to get more complex and has far more assets to have to manage. Knocking the "tedious" stuff out early just tends to make more sense when it comes to development in general as opposed to after you've made a ton of content in various places and have a really complicated mod to try to "Clean" and sort. Goodluck to you.

Have you pointed the units.xmls to the approrpriate e4p files for edgewater? Is this ingame or in editor? If its bugged in the editor, its a sign of some issues in the copy/paste process when you made the sep folder. If its an ingame issue along with the map, its probably that problem. Now that you've got it solved, the only thing left to do is take steps so it never happens again. Potential theory is you may have accidentally copy pasted the protos into the wrong place. Or made some clerical error when copying things. When making any mod, it is advised to create a totally separate folder for your project so that it does not conflict with LA, or any other mod. Another thing to advise is editing the 'em4mod.info' file in notepad so that the mod appears as its own entry with your name on it. Be sure to back up your files and relevant items. You've had a close call that nearly wiped your mod, it would be best to copy paste the mod into a USB stick, external HDD or upload it onto Dropbox/Google Drive and set it as private there.