Install Steam
login
|
language
简体中文 (Simplified Chinese)
繁體中文 (Traditional Chinese)
日本語 (Japanese)
한국어 (Korean)
ไทย (Thai)
Български (Bulgarian)
Čeština (Czech)
Dansk (Danish)
Deutsch (German)
Español - España (Spanish - Spain)
Español - Latinoamérica (Spanish - Latin America)
Ελληνικά (Greek)
Français (French)
Italiano (Italian)
Bahasa Indonesia (Indonesian)
Magyar (Hungarian)
Nederlands (Dutch)
Norsk (Norwegian)
Polski (Polish)
Português (Portuguese - Portugal)
Português - Brasil (Portuguese - Brazil)
Română (Romanian)
Русский (Russian)
Suomi (Finnish)
Svenska (Swedish)
Türkçe (Turkish)
Tiếng Việt (Vietnamese)
Українська (Ukrainian)
Report a translation problem
About "AIs can respawn" module:
I created this module for respawning non-playable AIs (playable ones are set by editor). The former intention was to allow enemy/friendly waves, infantry not in vehicles (because this case is supposed to be treated by the "Respawn vehicles" module.
So, respawning multiple AIs can be resource demanding. I focused on type /side /loadout, which is not so bad.
The name is the same as in editor (the full name), and not to be confused with the variable name of the unit (nor carried over). The pitch of the voice is neither carried over. The insignia is not carried over.
Scripted traits are not treated (as any other scripted behavior). But I'm rather sure that native traits (like medic or engineer) are carried over by types of dead/respawning AIs.
Everything is possible but I had to make some choices. That's a balance between general purpose and demanding specific features.
Furthermore, it seems to me Bohemia forums are dead. Arma 3 is no more maintained by devs, Reforger is not my taste. In other words, I spend less time on Arma.
MGI AI module
Triggers will only carry over one time after the initial spawning any trigger connected to the group or units are lost I believe because individual variable names do not carry over like in JEBUS.
Traits assigned like medic engineer ect will only carry over on the first use after they initial respwans they lose the ability that was a sign to them.
Voice changes will carry over for all respawns.
Faces changed will carry over for all respawns.
Any information but into a unit init will be lost after the first respawn for example forcing a specific ammunition to be used in a weapon ect.
Sincerely Avibird
I don't know if you're done modifying this but if you ever do can you look into those functions. As of now I need to use both to get the mission design that I desire. Avibird. The other possible modification would be to different AI module to spawn different sides at different intervals. Right now whatever the module set for will affect all four sides. This is not a criticism love your scripts and mods just a wish list Avibird
JEBUS has a few really cool features that yours does not and vice versa.
JEBUS allows unit group spawn if a opposing unit is at a certain distance from the initial spawn site the group will not spawn. The other feature is
Unit individual variable names carry over as well as unit init box codes carryover. For example I'm able to use codes like dostop and disabled pathway. These codes only work on the initial setup of MGI after respawn the codes do not carry over.
addMissionEventHandler ["EntityCreated", {
params ["_entity"];
<your code here>
}];
Your code must comply with MP requirements like locality for each command you are using (one of the reasons it seems to me hazardous to pass an init code).
NOTE: "entityCreated" MEH must be filtered for AI units (+ side or else) because you don't want animals or weaponHolder... something like: if (_entity isKindOf "CAManBase") then {..};
especially "must-read articles".
this setVariable ["specGrpForResp", "death"];
"death" or "leader" or "start" .... see documentation.
For spawned group (script) replace this by the variable name of your group just after you create it.
If group is supposed to change its locality in MP , i.e. change for its owner (Player's PC), make this variable public. If you don't understand that, don't script for MP!
Yeah I can tell this is definitely a libertad problem lmao. Your mod is working as intended, but libertad probably does some weird stuff to enable horses to be ridden, which your mod simply doesn't think to account for. It's a bizarre but funny edge case.
I do not have the "Other mods" tab ticked for the civilian population module; this is only an issue that occurs with the traffic module. So, I don't have civilian horses or anything wandering around as civilians. It's only with cars that this can happen. As you suggested, making a filter to avoid these kinds of issues would be appreciated. Who knows what crazy stuff other modders will come up with! So it'll be helpful to have a way to blacklist anyone we don't want showing up in a car seat.
I'm looking forward to your Expeditionary Forces update!
Anyway, you can populate civilians by Arma Tanoan or else, and not tick uselessly "other mods", because there are just animals as civilian units from libertad mod (no civilian man at all!).
For traffic, crabs, boars... can drive any vehicles. You can check that in editor, dragging an animal above a vehicle, as driver or else. I could change that by a specific filter... Perhaps in the next version of my mod (preparing Expeditionary forces compatibility).
The cars module however pulls from all possible civilians. So I saw a horse in default animation floating along clipping through the roof of a car. That was goofy as fuck.
It may be prudent to blacklist certain classnames from appearing as passengers in the civilian vehicles module. Or, make it so if you sync Civilian Life and Car Traffic, it only pulls from civilians that Civilian Life allows.
Other than that, I'm so far having more luck with this mod now that I'm on another map.
As any other modules (and logics or objects) placed in editor (3den), server and clients must have
them, so the addon. If a client doesn’t have the mod, the mission will not run for him. On the other
hand,
this mod is light!.
See the documentation here.
https://www.dropbox.com/scl/fi/6jfyof0g8y3k9zkg5j7gt/MGI-ADVANCED-MODULES-by-Pierre-MGI.pdf?rlkey=qex566h6tfjd8jhevj7t0j4pk&e=1&dl=0
Aside from these flaws, the civilian module overall has still been very useful, and seems to perform better than other mods that do the same thing.
About civilian life, if you don't want a despawn, just tick the spawn at start case. There is no other way. Spawning/despawning saves resources, spawning at start saves scenario and you can use the BI dynamic simulation. Spawn system is made for spawning randomly, each time you enter the area (and that works but, of course, it's not the same unit at the same place). A point you highligthed is the possible path outside the area, leaving some units not despawned. I'll do a fix for that. Previously, try to use squared triggers for areas.
One thing I am hoping you could help me out with. Is there a command to exclude civilians from the spawning/despawning? Since I keep having civilian units despawned in areas after players leave said area. I have civilians placed in 3den that are part of the mission and I don't want those civilians to vanish. But when players leave the area, because it's shared with an area covered by the civilian module, they disappear, and you never get them back. They're just gone forever.
There should be a check if the civilians the module is erasing were spawned by the module in the first place.
A less common unconfirmed issue is it looks like civilians who are able to leave the area are also not despawned when players leave, causing them to pile up after especially long missions. When their area is no longer valid they try to path to 0,0,0
I will not create a module for a so specific task, like you flags with interaction, condition and textures. But I can help on BI forum if you open a topic about that. I guess there are already some relevant scripts or hints like:
https://forums.bohemia.net/forums/topic/234864-capture-flag-bis_fnc_holdactionadd/
https://steamcommunity.com/sharedfiles/filedetails/comments/1937443167
If you need to repeat this event, you must set the trigger to repeatable AND set the repeat occurrence in module (-1 for infinite), with a decent timer. This way, the module is waiting for timer AND trigger (trigAttack1) condition met in order to spawn a new wave.