Hoppah

Although Emergency 4 was released in 2006 and is about 8 years old, certain alterations to the game using mods may cause performance issues or CTD's, even on brand new and fast systems. Despite its age, Emergency 4 isn't a game that is optimized for high end graphics. Certain newer games such as GTA IV, have functionalities which try to increase the performance (like draw distance). Emergency 4 lacks a lot of functionality to 'automatically' improve performance realtime when you are playing. It was never intented to have functionalities like that, because of the simplicity of the original game. While it's advised to always update video drivers and to have an external graphics card to play this game, it is very likely that a modification itself can still cause a wide range of different issues, no matter how good your computer system is. Especially computers with AMD hardware seem to have more issues trying to run modifications. The random crashes look like memory leaks, which may be a flaw in the game's engine, but there's nothing we can do about that. In my opinion, a lot can be done to prevent crashes and issues by changing the modifications itself. Based on my own experience, and with MikeyPI's help, this guide will give you some useful insight how to deal with performance in modifications. I've divided the tips into 7 subjects and sorted them on priority. 1. Textures Textures are rendered dynamically in this game, so when you zoom in it gets more sharper for a better focus. That process, especially with bigger textures takes more of your computer system. Some texture formats (common formats in Emergency 4 are dds, png, bmp, tga and jpg) also require more resources than others. While bmp files have a great quality, they are larger in size and problably require more resources to load. Take into consideration that a 2,048 by 2,048 (4.16 million pixels) pixel sized texture is 16 times (!) larger than a 512 by 512 (0.26 million pixels) pixel sized texture. Thats a big difference. I strongly advice mod-creaters to seriously consider using lower resolution textures whenever thats possible. For example, a 1,024 by 1,024 (1.05 million pixels) pixel sized texture for a person model is redudant. A texture that's 4 times smaller (ie 512 by 512 pixels) will almost always suffice for a person texture. A texture with that size still contains plenty of details and you will NOT notice the difference in the game, because the game is played from a birds-eye view. 2. Lights A lot of people like to add a lot of lights to vehicles because of realism. There is, however, a risk of lag since lights are updated realtime on every vehicle (when a vehicle moves, the lights move instantly too). Especially radiation (light glow) may cause an FPS drop, because they're always transparent and therefore, the game needs to render more. Especially at night, radiation can cause severe lags. There's been a couple of reports on the forum about this. The same thing generally applies to polygon lights. 3. Particles Each effect, like smoke and fire, consists of particles. Although particles are in fact 2D effects, a wide range of settings and effects are used to make it look 3D. Depending on the quality, rate and other settings, particles can cause severe lag. The forest fire mission in the Los Angeles Mod by Hoppah is a great example of how bad particles may cause performance issues, so be careful when using (new) particles. 4. Models Models aren't that bad on performance, since they have nothing to do with physics/collisions ingame and they are all precached before you start playing. That said, take into consideration that Emergency 4 is not really optimized to deal with highly detailed models. 20,000 polygons for a vehicle is alot for Emergency 4. It's proven that big models or big textures take longer to load (see below). In case you have weaker hardware, try to load up a high polygon model in the editor and you will notice a slight lag. When you're a modeller, take into consideration that a lot of details on a vehicle (like doorhandles) can be added to the texture too and you will barely notice a difference in the game. A single highly detailed model will not take a hit on any computer system, but do not forget that that model is part of a whole modification. It adds up very very fast if a 20,000 polygon object is placed 20 times ingame. Also, the more single textures a model is assigned to, the longer it takes to load each independent texture. 5. Scripts Timers (for missionscripts) and scripts that are repeated in a loop (like the siren and water supply scripts) may cause a drop in FPS depending on the total frequency they are run. 6. Mod Loading times In my opinion, it is a wrong thought that the total loading times are only caused by the size of the entire modification. A mod precashes and loads all playable units (both vehicles and personnel) which are assigned to a unique 'UNIT ID' via the 'Units' folder upon loading a modification. Therefore, all prototypes and the assigned models of those playable units are precached. The logfile keeps track of this process. Using less detailed objects will decrease loading times. Note: the game also checks the scripts for icons and certain scripting errors when loading a mod. 7. Map Loading times It may a very long time to load a map sometimes. The reason behind this, is that the game loads all objects that are placed on the map. The logfile keeps track of this process. Using less detailed objects will decrease loading times. Note: when loading a mission, the game also precaches the missionscript or builds a more efficient version (pscript format) in case the missionscript got changed. Conclusions It aint hard to draw your conclusions based on what's written above. Emergency 4 is a game that is not optimized for highly detailed stuff. High end computers will probably run all modifications fine, but it's likely the game will CTD after a while. Possibly due to memory leaks and/or the absence of an external graphics card. AMD hardware seems to have more issues than other hardware brands. It's therefore advised to take the tips above into consideration if you want to build a modification that will work fine for most players, especially those regarding textures and lights. A smooth modification will greatly improve the image/reputation of the modification and the team behind it. You cannot simply expect that people should just get better, brand new hardware, while the original game runs fine on eight year old systems. Emergency 4 is not first person shooter, going for as much realism as possible by building highly detailed models/textures is not necessary. With this guide and tips, I hope I have given you some insight regarding performance for this game. In most cases simply common sense and logical reasoning applies to deal with possible performance issues. Recommandations none yet Hoppah

Reinstall the mod, and make sure you do NOT click New Campaign. All missions are already unlocked, so you just need to go through the list to find the LA Mod missions.

Do the fire engine's have the command 'VcmdPumpSwitch'? Do the fire fighters have the command 'PcmdPumpSwitch'? Double check that. Someone else had the exact same problem because he forgot to assign commands.

I'm still here. Hereweard Fyning is right, but I may see if I can get that to work later. The part which adds the tanker functionality is already complicated. I'm sure it's possible, but I'll keep this one open for now. I do think it would be cool to add it though. Btw, the limited water may not be fully compatible with the tower ladder script because the prototype swaps.

Looks good! Did you succesfully manage to install the Tower at a window of an open structure? (to reach floors) That's basically the only issue left for the tower ladder ánd the tiller. How does the script deal with the limited water?

Check the Wye script itself. See if the wye object that gets spawned has the name "extend_wye". I'm guessing the name is off, so the fire fighter doesn't do anything when you click the object.

Looks good! Keep up the good work. H.

Thats an Attach Hose command issue. You cannot click the wye at all? Or does nothing happens when u do click the wye? Or does the firefighter run up to the wye object and then stops?

Glad to hear that.

Okey cool. I assume we're talking about the freeplay version, right? I'm pretty sure your problem has to do with pump guy, if he cannot be found by the script, the commands disappear. The principle is that you need a working pump to spray water, thus when no pump guy present/found > script disables cool/extinguish commands) Couple of questions, to see if I can locate the source of the problem: 1. Just to be sure, does the fire engine have a child with the name "pump_controller"? 2. Does your fire engine have the command "VcmdPumpSwitch"? 3. Do your firefighters have the command "PcmdPumpSwitch"? 4. When the pump guy is working on the pumps, is he in a looped animation where he slightly bends forward to give the impression he controls the pump (actual anim is called "useextinguis")? 5. If you use the 'Rapid Deployment' command to undeploy the fire engine again (when hoses are connected to it), does the pump guy enter the vehicle too?6. Does your fire engine have any other custom complex commands? If yes, which ones?

That's because the hoses become uncontrollable if there is no person to run the pumps of the Fire Engine. I know alot of people have plenty of specific wishes for this modification. Seeing how complex the logic already is, I cannot go into specifics regarding that at the moment.

Which is a default game animation and only used in one of the Deluxe missions. As far as I know, it's not possible to edit the animations. Dyson is right that the animations itself are not present in the persons model files (the .v3o files). The persons animations are a skeleton/bone type of animation (a different way of animation than the muscleanims for all other models) and each person model simply consists of different bodyparts. A seperate animation file should contain the codes how the body parts move for each animation. I'm pretty sure the VMO file which comes with each person model file has to do with the animations as well as the file 'adult_anim.vmo' in the default 'Data\Models\Persons' folder. Seeing the size of that file, I'm pretty sure the latter contains the actual animations. If you have software that can open and edit that file, you may be able to edit or add animations. Other than that, I have no idea.

Indeed, that would be my idea too. You can either spawn the hose connections, or spawn the entire ladder base (kinda like the reversed ladder script). The water supply logic may be problematic indeed, but I'd prioritize things first. Get the combination to work first, then look at the water supply compatibility. What kind of scripts you all got in the Stillwater Mod?

Merry X-mas

That looks very nice actually, although it does need some polishing here and there. The cars look very detailed and the map looks good, a lot of Dutch influences are visible. I especially like what you did with the 1-6 buttons and the lights look very good too. I may actually try this mod out once I have some time. Will this mod be updated? Hoppah

Theoratically, yes, it should work like that. Dummycommands are about the safest way to add specific traits or flags as you called them.

Are you talking about Rapid Deployment or something else? It's possible, yes. But I wouldn't recommand doing that. For rapid deploy its important that you can use the hoses as fast as possible and therefore, one of the fire fighters immediatly starts activating the pumps. In the mean time, 3 others can use their hoses instantly and the 5th fire fighter install the supply line. If we change this, it will take about 10 seconds before any of the hoses can be used, because the pump controller gotta install the supply line first. Not very practical in my opinion.

I assume this is for freeplay? Yes, !WATER, Start DummyCheckWaterSupplyis there, but no vehicle gets a dummy object with an assigned water level. Possible causes: 1) The script does not get repeated, because the "water_supply_main" object can be interacted with during gameplay. What object did you place on the map to act as the "water_supply_main" object? You may have the same problem as Hereweard Fyning had with his LA Mod Submod. An object that can be interacted with in any way cannot be used for "water_supply_main", so do not use an object that has traits (Hereweard Fyning used a buoy before wich has a trait so cranes can lift it from the water), can catch on fire and definately not an object that is commandable. I used a satellite dish object from the HouseChildren folder for the demo mod. 2) Your vehicles are not recognized by the script. They must be either TLF, GTF, LPF or DLK type. What vehicletype are yours? If they are RW, it will not work. In that case, give me your script and I'll make the script compatible with RW vehicletypes as well. 3) You've edited WaterSupplyFreeplay.script, made a boo-boo, and the commandscripts are broken and cannot be executed anymore.

That's indeed a way to fix that. Since I think I only edited one D-line to wreck Zmod, you can also try the following: Zmod should mention which vertex is invalid. Write that down. Then open the v3o file with Notepad or Wordpad and find that vertex. That line should have a missing digit, so it looks like: D, -586, 228, 9024, 80, 201, 133, 565, 315, 0, 0, 0While in order to make Zmod import it, it must have an addition digit at the end (12 digits after D), so it looks like this. D, -586, 228, 9024, 80, 201, 133, 565, 315, 0, 0, 0, 0Noticed the difference?

Just like you could've contacted me personally to send me this message as well. I was going 'wtf' too, when I found out that there was no readme. You have any idea how much time I spend on the limited water logic? The freeplay version of it was actually requested by some of the members of this team. And that's just one very recent example that helped this modification become so good and popular. In regards to your question about my method: I don't agree because of effectiveness. This is usually the way me and other moderators operate when it comes to the subject 'copyright' and there is nothing wrong by that. Or are you so afraid of bad publicity and a tarnished image of this modification? Doing it trough PM may have been an option indeed, but I chose to do it this way to make sure it would be set straight as soon as possible. In my experience, personal messages are (generally speaking) ignored and not taken seriously a lot. I also could've taken down the whole download, deleted this topic and handed out some warnings to the involved members (which were all suggested by people who I talked to before I wrote the big post). However, I chose a less strict way, because I knew the 'theft' was NOT intentional ánd indeed an oversight. While it is easy to set this straight, copyright infringement is a serious offense on this forum and needs to be taken seriously. By writing a public post in a serious tone, I was sure the message would be received. I'm not sure how long you are around on this forum, but we (me and other moderators) used to enforce the terms of this forum in a much harder way in the past, so this was actually mild. Anyway, I considered a couple of options to deal with the problem and chose the most effective but least consequencing method to make sure the problem would be picked up and resolved as soon as possible. The mod is still there, no people were sued, banned or warned and the mod can still be continued. I personally have no bad feelings towards the mod's team and hope that the Manhattan Mod will be improved in the future. The new patch looks promising indeed and the readme is actually very extensive and clear.

Shouldn't be that hard to fix, although without the files it's hard to tell. If you can find a way to send me the entire submod I may take a quick look at it and see if I can find the cause of the problems.

Reset the orientation of the local axes in Z-mod before exporting. That should solve the steamrolled door.

windegroup must point to an integer, which is simply a digit such as 27 or whatever GroupID is not being used by the same caller (in other scripts) yet. Right now windegroup is not defined at all, so that results in an error. Add the following line on top of the script: int windegroup = 27;That should solve the error you wrote in your last post. Other than that, I have no idea what the script is supposed to do since there is no explanation. And because you didn't put the script in the code tags it's nearly unreadable as well. I'm guessing the script won't do anything.

BMA is German for Brandmeldeanlage or simply 'fire alarm system'. The script is run in the background by a dummy object. To initiate this, you will need to edit the freeplay startup script (fp_freeplay.script / fp_challenge.script). That script locates the dummy object and initiates the fire alarm system script. What the script itself does, I'm not sure, but I'm guessing it adds a new event/objective with false and true fire alarms. The bunch of text at the beginning of the script are settings you can change.