Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Everything posted by *zeewolf*

  1. *zeewolf*

    BM21 script?

    Err which addon are you referring to? If it's just a BM-21 vehicle addon with no scripting included then there will be no easy way to make it fire at an arbitrary location that isn't line of sight. The CoC artillery addon provides the enormous amount of script required to get AI units to behave like real artillery. If there isn't support in CoC for a BM-21 already then it's unlikely you'll be able to get a unit working as proper artillery. With artillery it isn't always essential to do it "properly" by getting the actual shells fired by the unit to land on a given target, often it's easiest for a mission maker to simply script the explosions at the given position while the artillery unit (if it even needs to exist) fires at some random position. There are plenty of "artillery" scripts around that simulate bombardments by spawning the shells at the target.
  2. Are you asking how to use the DSF addon or are you trying to make your own scud launching script? If you just want to use the addon, a quick way to repurpose the DSF demo mission would be to add a radio trigger to which runs a new launch request script and add a game logic named TargetLogic that the script can move to a custom target position. The launch request script called from the radio trigger would be: [side player,"HQ"] sidechat "Provide map coordinates" onMapSingleClick {[_pos] exec "launch_scud.sqs"} launch_scud.sqs would be: onMapSingleClick {} TargetLogic setpos (_this select 0) [1,10,TargetLogic,scud2] exec {\DSF_RUSOPFOR\scripts\DSF_ScudLaunch.sqs} Which according to the addon script should cause the unit scud2 to launch a missile at TargetLogic after 10 seconds. If you're trying to make your own version then be aware that all of the explosion effects are created by the DSF addon. Effects scripts in general are very complex beasts so making your own mushroom cloud effect from scratch would be very difficult.
  3. Hi everyone, I've managed to secure permission from Sled88 to release the final version of his excellent Battletech grass (Erba.pbo). This version fixes a bug present in the publicly available alpha/preview version where the grass model blocks bullets fired from certain angles (which made the preview version impractical for me to use in MP missions). Although Sled88 no longer had a copy of the final version (which was never publicly released) I managed to locate the model being distributed (without attribution :nono:) as part of Drago island. With Sled's permission I have repackaged the model with the two original textures used in the preview version as well as the texture used in Drago island release. The grass itself is excellent for covering large areas and can block AI vision pretty well. I've included a template mission with various tiling patterns for use by editors. Filefront download (Filefront's servers seem really unreliable so this link doesn't always work). EDIT: OFPr.info/ofp.gamepark.cz screens and mirror. Sendspace mirror NOTE click the "Regular Download" button then "Click here to start download from sendspace" DO NOT click any of the other "download" buttons Multiupload mirror
  4. *zeewolf*

    Invasion 44 standalone grass pack

    Update. Kenoxite has added a script to the .pbo that greatly improves AI pathfinding and automatically lowers grass near the player to balance gameplay against AI opponents (who can see about 50m through grass). Get it here. Demo mission and instructions included.
  5. With permission from the Invasion 44 team I have repackaged the grass used by their Normandy island as a standalone addon providing editor placeable vegetation. The pack contains thirteen varieties of vegetation; grass of various heights, ferns, crops and wild flowers. Also included is a template providing tile patterns of various sizes for the different vegetation types. Special thanks to Bielow for assisting me in locating the original authors and securing permission for this release. OFPr.info/ofp.gamepark.cz screens and mirror. Sendspace mirrror NOTE click the "Regular Download" button then "Click here to start download from sendspace" DO NOT click any of the other "download" buttons Multiupload mirror
  6. *zeewolf*

    Battletech Grass pack new version

    Update. Kenoxite has added a script to the .pbo that greatly improves AI pathfinding and automatically lowers grass near the player to balance gameplay against AI opponents (who can see about 50m through grass). Get it here. Demo mission and instructions included.
  7. *zeewolf*

    updating older version

    I'm confused, you say you want to update the mission yourself, but are unwilling to learn how to script. CTI missions in general are probably the most heavily scripted OFP missions ever made, how exactly do you expect to alter the behavior of a mission without altering the scripts? Even the best written/documented CTI missions do not go into the specifics of how every script works, that information can only be found by talking to the author or analysing the scripts. If you aren't going to learn how to read/write scripts then you are essentially asking for someone to do all the work for you. CTI missions can easily have more scripting in them than a full blown total conversion mod and you are asking for someone to reverse engineer it to your specifications. I suggest you contact the author for some advice on whether any of the things you have asked for can be changed easily, regardless if you are going to do any of the work yourself it will involve writing scripts.
  8. *zeewolf*

    Need help with some scritps

    Here are a couple of ways to do full "side" respawning: First method is to use a regular "BASE" respawn mode to respawn the player outside of the mission area (while playing a camera script so they don't see this), the killed eventhandler (or a client side monitor script) then starts finding a suitable AI unit for them to replace (searching an array of possible units etc). Once the candidate unit has been selected, record all the necessary information about it (position, heading, position in vehicle) delete the AI unit then move the player into the matching position with the equipment the AI unit had. A second way is to fudge the "GROUP" respawn mode where each player has a second disabled AI in their group, outside of the mission area that they can spawn into when they die (catching the player to stop them becoming a seagull while the script finds a candidate to spawn into). A killed eventhandler then joins the selected AI unit into the player's group, then kills the player again, causing the player to be spawned into the new unit. If there are still candidate units available then another "catch" AI is spawned outside the mission area in the player's group. The second method requires less scripting and gives a 100% accurate loadout. The first method is far more reliable since I've found the second method places a lot of strain on the game and can easily cause loss of synchronisation. Either way, "side" respawning can only be achieved with complex scripting. The second method quickly becomes impractical if the player is in a group with other players/in-mission AI, you'd have to start shuffling them in and out of groups using join, which will put a lot of stress on the game.
  9. The intro is stored as a mission in dta\Anims.pbo. When you use a mod folder with that file your mod is overriding the default anims.pbo with its own missions. The name of the actual intro mission being run when the game starts is set by the mod's main config.cpp/.bin (mod folder\bin\config.cpp) under CfgWorlds.DefaultWorld.Cutscenes. The default mission is Dta\anims.pbo\intro.intro, you can either add a new mission to your anims.pbo and change the mod's config.cpp to this new mission (or allow multiple possible intros as used on Everon or Malden), or you can just edit Mod folder\Dta\anims.pbo\intro.intro using the mission editor.
  10. Some general tips first: Always initialise your global variables to a value in init.sqs, this can be a null value if necessary but it's never good to leave them as nil. Don't blast out publicvariable commands one after another, put delays in between of at least 0.1 seconds, this makes them much more reliable. If the killer was in a vehicle then the "killer" object reference passed to the killed eventhandler is actually a reference to the vehicle, not a unit inside it. So you'd need "if ((vehicle _killer) == Player1) then {killer_integer = 1};" to dereference the playable unit. You only have one publicvariable set for all four players in the mission. Ask yourself, what happens when two players kill each other at the same time? Your player object references should be the name of the unit in the editor. Is this the case? The update applied to a player's scores are only done on the player's machine in your script this will mess up the multiplayer score board since addscore is not a global/public function. In my opinion you should use one publicvariable set for each playable unit (to avoid race conditions). This would be for example Player1Cash, Player2Cash Player3Cash, Player4Cash, Player1KilledBy, Player2KilledBy, Player3KilledBy, Player4KilledBy. Then set a single global variable to serialise the players in init.sqs: Each killed eventhandler would then be: The receiving client.sqs script then loops to monitor changes in the publicvariable sets, updating scores as necessary. I haven't tested the above, I just wrote it off the top of my head but the principle is sound because what you are trying to do is very similar to the killstreak system I implemented in my Modern Warfare Crisis framework. Have a look at how the scoring works in that (the mod's editor guide explains how these kind of scripts work). Also notice that this code is being run exclusively client side, nothing here is server side only. While this makes things slightly more complicated/obtuse it offers significant performance benefits when you are dealing with large amounts of data (in terms of both frequency or volume) being broadcast by public variables since you aren't tying up a single machine with service requests, the workload is being shared by the machines purely by the probability of a given player triggering the handled event.
  11. Sure, just put a comment in the relevant script section saying where you got it from. That way anyone reading the script to figure out how it works can find out more about it.
  12. Another issue is that this feature needs to be rolled out as a combined mission template/addon framework which as you know I am a fan of but they don't appear to be very fashionable around here. So I'm not expecting to see it used in any releases just for that reason.
  13. I guess so, you could define an individual animation set for each "man" class, then use scripts to detect changes in loadout which trigger a class change. My recent tribulations with trying to override states for a Juggernaut unit have left me loathing the sight of CfgMovesMC. Based on my experience you're definitely better off using StatesExt to override the standard state classes rather than trying to override the actions that call them, even if it looks messy. So the Juggernaut addon's config.cpp is basically: So, if I wanted I could make SoldierWMG use CfgMovesMCJugg then use a script to detect when the player (using a SoldierWB class for example) picks up a PK or M60 then switch them into SoldierWMG while preserving their loadout, the player would look the same but their animations would be changed to that of the new class. When they drop the MG, the script switches them back to a SoldierWB etc. In the demo mission there is 2 second delay when switching classes, this could probably be reduced, I kept them in there to spread out the extra bandwidth demand of the createunit and loadout manipulations, if you remove the "black in" cuttexts in the demo's dialog script you'll see the transfer to another unit takes just one frame, the camera in the game's standard "onPlayerKilledRespawnAsOtherUnit" script just gives you the impression it takes a long time. I guess the amount of "black in" you use is dependent upon whether you want the player to see what your script is actually doing, dropping dead every time you pick up a weapon might get annoying.
  14. I want to restrict a certain soldier class to a limited range of animations, such that a player using the class can't sprint, run or go prone. So CombatActions slowF and fastF should play StandJogF. All down actions should map to crouch. Do I need to make a complete customised copy of CfgMovesMC to do this? Or is there a more efficient way to limit a single unit's animations?
  15. *zeewolf*

    Restrict unit animations?

    It's only for multiplayer obviously. I haven't tested it out yet on a network, but I got a basic mission working and it has some limitations depending upon how heavily you script the transition. It relies on manipulating the "Respawn as other unit" mode, where you respawn as a member of your group. So if you want to spawn the player into an arbitrary class, you override the event script "onPlayerRespawnOtherUnit.sqs" with your own version to override the standard camera allowing you to do some "behind the scenes" work and manage the transition (or you could manage it using a killed eventhandler it doesn't matter). It essentially relies on having a unit in the player's group for them to spawn into when they die. So my plan for my game mode is quite basic at the moment, to have an immobile AI squad member somewhere on the map for the player to spawn into. Once the player has transferred, their new unit is setpossed into the mission area and a replacement AI unit spawned into the group using createunit. It's important to note that for this to work the unit to be transferred into must be spawned into the group before the player's death, if death can't be predicted then the unit must be spawned and "hidden". For other situations where the player requests to transfer to another unit using a dialog, the script itself is what kills the player so the AI unit they'll spawn into can be created "on demand" of any given type prior to killing the player. E.g. (I haven't tried it this way but it should work) 1. Player chooses to transfer from a soldierWB to a SoldierWSaboteur unit using a dialog or action menu. 2. Script blacks screen and disables radio (using enableradio). 3. If there are more units in the players group move the player into an empty temporary group using join. 4. Spawn the SoldierWSaboteur into the temporary group using create unit. 5. Kill the player, allow the engine to transfer the player to the new unit. 6. Transfer the player back into their original group (if they were the leader some messing around may be needed to get them back in charge). 7. Setpos the player to their original position and transfer gear if necessary. Dispose of the player's dead body if desired. 8. Black in the screen to reveal the player using a new class. Enable the radio again. I think this can all be done surprisingly quickly if it's performed on the local machine.
  16. *zeewolf*

    Restrict unit animations?

    Thanks that looks like it will do the job. I'm thinking of making a Juggernaut game mode, since I came up with an idea of how to do a script that can respawn players into different unit classes, a sort of team switch function for OFP. So a player could spawn as a regular soldier, but once they kill the juggernaut then they are spawned as the juggernaut. When they die as juggernaut they can be spawned back to being a regular soldier etc. The juggernaut needs to move slow and be unable to crawl while having enormous armor values. So I'm on the look out for models of EOD/bomb disposal suits. If I can't find one I'll have to stick with a SWAT style model.
  17. *zeewolf*

    OFP Addon request thread

    Anyone know of any units released for EOD Bomb disposal suits?
  18. *zeewolf*

    Some scripting problems

    For radios I suggest using Init eventhandlers on the vehicles that detect when a player is inside the given vehicle, if so they play the relevant sound to them. The current sound to play could be controlled by the server if all players need to hear the same sound at the same time. A simple server side script that broadcasts the current sound to be played and a signal to start playing it would suffice. The locality of scripts can be controlled using the local command, it's standard practice in 1.96 to use an editor placed game logic called "Server" to determine locality, since editor placed objects are always local to the server, "local Server" will always return false on clients but true on the server. v1.99 has the isServer function that serves the same purpose but is not backward compatible. Broadcast communication of hints and generic sounds is relatively simple in multiplayer. Just run an "effects" script on each player's machine that loops around waiting for a global variable to change. When it does it parses the variable and plays the appropriate local effect. Simultaneously other scripts can write to the global variable and broadcast it to other client machines using the publicvariable command. This is a peer to peer setup. E.g. clientfx.sqs as used in MWC an example caller script, in this case MWC's s_jdam.sqs which runs when a player calls in a precision airstrike 7 kill streak reward: The other way to do it is have the server detect when an effect needs to occur then broadcast it to all clients, check out the Coin coop engine (if you can find it) for a well written example of a rigid server-client system. Which you choose depends upon how you want to balance scripting load across the machines on the network. You'll need a bit of thought to prevent race conditions and ensure the "effects" script is able to read and execute the effects faster than machines are going to send them. I tend to think of triggering most remote sound, cut and drop effects as best effort so lump them all together. But in the case of mission critical synchronisation of data a dedicated set of scripts and public variables can be used to ensure the information is passed using publicvariable handshakes. For checking who killed someone you need to use killed eventhandlers, they receive an object reference to the killer passed by the engine. Unfortunately killed eventhandlers only run on the machine the unit was local to. So if say player 1 kills player 2, a killed eventhandler assigned to player 2 will only run on player 2's machine. Once the script has figured out who killed player 2 (i.e. who to reward) it needs to pass that data back to other machines on the network using public variables. In some cases in multiplayer the killer isn't identified by the engine (you'd see "player x was killed" in global chat rather than "player x was killed by player y") in this case the killed eventhandler will run but the killer will be null, this usually happens with splash damage weapons or being run over by a vehicle. In most cases if you don't receive a killer reference in the eventhandler there's no practical way of finding out who killed them, so you just have to treat it as suicide. When I made kill streaks in my MWC mod I had to pass a lot of data over the network to give the killed eventhandlers a chance of identifying the killer (since hitting someone with a predator missile would trigger a "player x was killed" message). For some basic AI scripts check out stuff like GDCE, or Coin coop engine. They have basic AI behaviours in comparison to CTI missions (which may be a little heavy if you're not familiar with how they work). For multiplayer purposes just spawn and manage all AI groups on the server, you just have to be careful about what happens in mixed AI/player groups if the player takes command of the squad.
  19. *zeewolf*

    Some scripting problems

    I think you should start by looking into how "health bar" type addons work. I believe several FFUR releases had one. That is essentially what you want if I understand you correctly. Also bear in mind you can use dialogs to display much more complex information to a player than a cutrsc. You mentioned DayZ so I assume you are trying to replicate the temperature, hunger, blood and thirst icons. Is that the case? Have you considered providing an individual RSC for each possible state of the available icons? If you allowed each icon to be either green, amber or red and used titlersc for two of the icons and cutrsc for the other two, you would need 18 images, which isn't completely ridiculous. Unconsciousness, broken bones and exposure effects could be covered by sound and camera effects. Also consider using hints, titletext and briefing objectives to display status to the player. Regarding AI, I suggest you start by designing flowcharts for an AI's decision making and actions. Then convert these flowcharts into state machines which are the fundamental components of general AI scripting. Once you've worked out what information an AI unit needs to make a decision and what they're actually going to do you can then think about the scripting to make it happen. If you are doing zombies then look into the many previous zombie mods that have been made for this game over the years which offer similar behavior to DayZ's denizens. If you're making a multiplayer mod you'll need to be aware of the locality of your scripts, scripting commands and variables at all levels of your mission framework in order for it to work properly. Is the mission going to be multiplayer?
  20. *zeewolf*

    OFP Addon request thread

    I'm looking for some large enterable buildings. The important thing is they have multiple rooms and any extra floors be connected by (working) stairs rather than ladders. Multiple floors would be nice but not necessary I'm just trying to get a large, realistic building that would be good for multiplayer maps. So office buildings, malls, apartment blocks, schools, hospitals anything with a lot of rooms to clear. Can anyone think of some addon packs? Or just their favorite non-BIS enterable building.
  21. *zeewolf*

    Modern War(fare) Crisis

    Thanks, you just motivated me enough to release another hotfix and content drop of the stuff I've been playing/working on. There's some minor bug fixes to the MWC mission templates and missions as well as a lot of new content. This time the new content has rather random addon requirements, some of them use a mixture, e.g. CAT Afghanistan objects on Buren island or BAS Tonal objects on CAT Afghanistan. A rough list would be: BAS Tonal (for .bas_i1 missions and the Afghan Green Zone mission) BOH Buren and Kanon islands (for .buren and .kanon missions) CAT Afghanistan (for .CAT_intro missions and Daraisolas mission) AGS Industrial pack v3 (for Rust, Petrol and Bloc) Chechnya island (for .chechen missions) NIM dynamic weather (for the falling leaves in Farm.kanon) Seb ilo objects (for the Afghan Green Zone mission) I've also included prop templates which you can merge into your own missions.
  22. *zeewolf*

    Modern War(fare) Crisis

    It's a shame these issues weren't raised in the addon discussion thread. Even if you have only one person to play against, bare in mind that some game modes actually work really well as two player matches. Kill confirmed being the best, although Hunter and Oddball can lead to some excellent standoffs. All game modes are PVP. Bringing any kind of AI into the mod opens up a huge can of worms. If they were included would they be "bots" which attempt to mimic humans as closely as possible or would they be better used in a more conventional sense in a single player or coop campaign? Both options have their pros and cons. It is possible to implement co-op or single player gameplay into the mod but would require the game modes to be re-written from scratch since they are so heavily optimised for multiplayer they simply don't allow AI to be added in. The AI in Battlefield 1985 AI demo is as close as I could get to bots for an advanced game type, yes they'll actually be able to do everything a human player can but they aren't a substitute. I created that mission to allow the teams to be balanced in matches I was playing in, but players found them to be inadequate for full competitive play. Hence why I haven't put similar support into any mission since. I find it hard to justify the work of adding them to MWC given the lack of demand for AI in my clan and more importantly no consensus on what is meant by "coop" support. Possible options for singleplayer or coop support are: Completely autonomous bots playing any MWC game mode in a lone wolf fashion (as in the BF1985 demo). Bots in MWC team game modes that rely on a human team leader for instructions. Bots in MWC team game modes that operate in a seperate squad to human players on their team. MWC team game modes that pit a human only team against an AI only team. An MW3 style survival mode with equipment purchasing. A COD style campaign playable in coop. A CCE style persistent dynamic coop campaign with equipment purchasing mechanic. Which would you like to see? If there's a strong consensus then I'll consider making it.
  23. *zeewolf*

    Modern War(fare) Crisis

    No the purpose of default classes is described in the editor's guide. Basically they are the scripts used to define the default class loadouts used in missions, if you're not actually making MWC missions then you don't need them. Also the mission folders in "templates" should be placed in Users\Username\MPMissions not your BIS template folder since they are not wizard templates. You open them like a regular mission in the mission editor to move stuff around and add props. As for the .adf file, well consider that an amusing easter egg for you to unlock if you choose to research it, the file extension should be enough to go on.
  24. *zeewolf*

    Modern War(fare) Crisis

    It appears a bug slipped in when building the release. Some of the missions aren't displaying the Outro sequence which is pretty important in MWC because it's where the player's profile is updated with their earnings from the mission. The effected missions can be patched with this hotfix. Also included is a content drop of new missions using the BIS islands. Only "Bloc" and "Rust" require a third party addon in the form of AGS Industrial Pack v3.0. I will release content drops for third party islands if there is sufficient feedback/demand.
  25. *zeewolf*

    Modern War(fare) Crisis

    If you mean; can you play MWC game modes cooperatively against AI? No you can't, no AI is allowed in the MWC game modes, many features actually rely on it not being present. It could be implemented but playing against AI always feels different to playing against a human and they can never be relied upon to properly balance out teams in team game modes. As provided MWC game modes are strictly PVP. It is backward compatible with standard SP and MP missions though since it replaces standard BIS classes. You can also use the create-a-class shop in Debug mode to view the weapon and magazine classes for a given attachment combination then add these weapons to your own missions as you see fit.