Jump to content

opusfmspol

Member
  • Content Count

    716
  • Joined

  • Last visited

  • Medals

Everything posted by opusfmspol

  1. I have this commonly appearing in my .rpt log now. Haven't experienced an issue though. Version 1.63.131129 Item STR_DN_LADA_CP listed twice Item STR_DN_LADA_RED_CP listed twice Item STR_DN_LADA_WHITE_CP listed twice Item STR_DN_LADALM_CP listed twice Item STR_DN_MTVR_REFUEL_CP listed twice Item STR_DN_USBASICWEAPONSBOX_CP listed twice Item STR_DN_USLAUNCHERSBOX_CP listed twice Item STR_DN_USORDNANCEBOX_CP listed twice Conflicting addon CorePatch_CCP_67542 in 'corepatch_a2\corepatch_ccp_67542\', previous definition in 'corepatch\corepatch_ccp_67542\'
  2. Part of the bahavior can be expected. Init.sqf gets run on every machine, and the commands "createGroup" and "Join" are global commands. So not only the server, but everyone joining ended up running the commands. And the variables aren't made public, so each machine has a different reference to a different group. Your reference ALPHA is not the same group as the joined client's reference ALPHA. The units joined the last groups created by the last client to join. Try using a condition in the init.sqf to limit the commands to a specific machine (the server in this example): if (isServer) then { ALPHA = createGroup west; BRAVO = createGroup west; [A1 ,A2, A3, A4, A5, A6] join ALPHA; [B1 ,B2, B3, B4, B5, B6] join BRAVO; }; My own testing so far, I feel pretty sure the "unitReady" command is being used with synchronized "GET IN" and "LOAD" waypoints. In SP, as the heli approached I used "selectLeader" to have a subordinate take command of the group. I became subordinate to the AI. When the heli came to a hover the leader gave command for all to mount and the mount icon appeared on the heli. My suspicion is that the "unitReady" commands is used to check who finished boarding. Still testing some thoughts about this.
  3. An intriguing thought. One would tend to say no; the pilots and their group still being AI, would belong to the server: https://community.bistudio.com/wiki/6thSense.eu:EG#Locality But the locality bug in the transport.fsm (in Functions) which caused the Transport and Supply Drop supports (in SOM) to fail for joined clients was resolved by having the clients create the vehicle and run the FSM (which runs a few "unitReady" commands on the aircraft). The issue was that the aircraft were created by the server. The "unitReady" command was always returning true to a joined client since the aircraft was created by the server. The issue resolved once the client also created the aircraft. Yet the aircraft and its group, being AI not under player control, one would say they belong to the server? Yet it worked.... So could AI aircraft created by a client but not part of the player's group actually belong to the client? It makes me wonder if the event handler for an editor 'GET IN' or 'LOAD' waypoint uses the "unitReady" command. It would explain the behavior. Perhaps "unitReady" command has to be run on an object created by the local machine, or the waypoints (a group function) need to be created on the local machine? The wiki doesn't indicate the command's locality use. Short answer: I don't know. I'll do some testing with this thought over the weekend and post results back.
  4. It seems to be a multiplayer locality issue with the waypoints, but I can't figure it out. I created a mission of my own using yours as a template, and experienced the same thing you did. It worked in SP, and on hosted server it worked for host, but not for joined client. Then I used a dedicated server so both leaders were joined clients. Both helis approached and hovered until their teams reached their waypoint, then both helis moved on to the "Transport Unload" waypoints without ever landing. BUT, while the heli was hovering, if the leader disconnected before reaching the team's "Get In" waypoint, the heli then landed and the team boarded. The team at that point belonged to the server, it no longer belonged to the client machine. - I placed a Functions module to activate Multiplayer framework, and got the same result. - I used "setOwner" command on the helis to make them belong to the client machine of the boarding team, and still got the same result. At this point I too am at a loss to understand it.
  5. Don't know, I've never run music grouped to a unit. But might try ungrouping to see if has any effect. The setup does appear correct.
  6. Yes. "this && isServer" will fire only on the server machine, including a dedicated server, but not on the joined client machines. Otherwise the trigger is firing on all machines. "Player" wouldn't work because Player is objNull on a dedicated server. Are you sure the two helos aren't grouped? It looks like a group line leading down from it.
  7. Are the triggers or waypoints using "On Act." code with "UnitReady" command? or is the "Player" variable involved? The choppers being AI, they belong to the server. "UnitReady" command only gives an accurate return if run on the machine the unit belongs to. Run on a machine the unit does not belong to, it will always return "true", even when the unit is not ready. So if a joined client's waypoints rely on a "unitReady" command run on an AI (belonging to the server) it will always return true. And inevitably, using "Player" command works in SP but causes headaches in MP. --edit: Maybe try "this && isServer" in the triggers. Maybe it has to do with the triggers firing on all machines rather than just the server.
  8. I'm thinking the triggers might be the issue. What kind of triggers? Radio or presence detection? If detection, what kind? If radio, are both on the same channel? Do they have custom conditions other than "this"?
  9. Are the helos grouped, but the teams are separate groups (two groups)?
  10. Put the code in the init field of the parachute jump target. Place a marker about 50 meters south of your jump target and name it "marker1". You don't have to place the nightlight objects down. They'll be created at mission start when the jump object initializes. The objects are created AGL - at ground level. But they tend to clip into the ground, or be obscured by grass, which is why they're raised (+0.1 meter). veh1, veh2 and veh3 are variables you use to refer to those nightlights. Example, you could place a radio trigger to find the distances between them: Trigger: Activation: Radio Alpha - Repeatedly Text: Get distances On Act.: dis1 = veh1 distance veh2; dis2 = veh2 distance veh3; dis3 = veh3 distance veh1; hint format ["light 1 to light 2: %1 m \n light 2 to light 3: %2 m \n light 3 to light 1: %3 m",dis1,dis2,dis3];
  11. In editor, or created dynamically in mission? Having the classnames, you need the positions. In editor position can be obtained with a marker. centerPos = getMarkerPos "marker1"; Getting the position in mission depends on what you intend to use for a center pos. There's a math calculation I can't recall (would have to dig) that uses sin, cosine, direction and range from a central pos to get perfect pos from a circle. But a less precise, much simplified version, where pos serves as the (centered) base of a triangle, would be:
  12. opusfmspol

    Auto accept SecOp mission?

    The code in the post above is updated. It was hanging on a "while do", changed it to an "if then". // --- edit After more testing, finding it was clearing the option to accept those missions not auto-selected, the second code set was revised again; using BIS_SOM_unregisterTopicFunc removes only the selected topic instead of all.
  13. opusfmspol

    Auto accept SecOp mission?

    Putting this in the SOM init field might work. Or if putting it in an init.sqf, replace "this spawn" with "mySom spawn" (mySom being the player's SOM). Automatically accept all SecOps: Try this to automatically accept certain SecOps, but not others: The _secOps list are those that will be automatically accepted. Remove from the list any that should require a player decision. Automatically accept certain SecOps:
  14. Hmmm... apparently not. SILVIE creates empty cars. It looks like ALICE2 creates its own vehicles for civilians to drive around in, apart from SILVIE. It doesn't have a custom init for the vehicles. It has custom init from the logic, and custom init for towns but both get applied to the civilians being created. When a driver is created, the custom inits run on the driver before being placed in the vehicle. But if a vehicle has cargo seating, a passenger is created and placed in the vehicle before the passenger's custom inits run. That could help. Putting this in the Alice2 module "init" field might work: this setVariable ["ALICE_civilianinit",[{if (vehicle _this != _this) then {(vehicle _this) lock true;};}]]; When the passenger is created, they lock the car.
  15. SILVIE is the random vehicles module, which I only assume you are using. It has an optional variable to set the init for each vehicle it creates. The variable is code {} and the only parameter passed into it is the created vehicle, referred to in the code as _this. The code is run by the server. - Put this in the editor module's init field: this setVariable ["vehicleinit", {_this lock true}]; - Or in a server script that created the logic ("SILVIElogic" being reference to the module logic): SILVIElogic setVariable ["vehicleinit", {_this lock true}];
  16. Place a radio trigger to detect your side. sd = side player; hint str sd; when it happens, call the trigger and see if you have been made side civilian. In my mission I also use first aid module, and encounter that problem sometimes when killed. I haven't found the source that causes the side switch. >> Placez un Déclenchement Radio pour détecter votre côté. sd = side player; Hint str sd; Quand cela arrive, appeler l'objet et voir si vous êtes devenu camp Civil. Dans ma mission, j'utilise également le module «premiers soins», et parfois rencontrer ce problème quand tués. Je n'ai pas trouvé la source qui provoque le commutateur. >please pardon errors, using Google translator< /---------- Edit ------------/ Found the cause. The agony FSM of the First Aid Simulation module (AIS) uses setCaptive on those going into agony. When a unit in agony dies and respawns, they remain set captive. A script or event handler dealing with respawn corrects it: // [... when unit respawns....] if (Captive _unit) then {_unit setCaptive false};
  17. The default Reinforce SecOp will only run when a member of the original group dies. It only replaces members of the original group, it won't add members. Simplest alternative would be to maintain the group composition registered in SOM during the mission, adding to the array when larger is needed and calling the SecOp by script or trigger to gain them (it won't run automatically when the array changes, only when a group member is killed). Reinforcements given are based upon the units listed in the group composition. Those missing are given. The group composition is an array of class names of the units in the group at mission start. It gets registered in SOM locally on the server. // (SP) or (MP server only), won't work on a joined client. // Trigger1: Set a larger group composition. comp = +(mySOM getVariable "grpComposition"); comp = comp + ["USMC_Soldier_Medic","USMC_Soldier_GL","USMC_SoldierM_Marksman","USMC_Soldier_LAT"]; mySOM setVariable ["grpComposition",comp]; // Trigger2: Gain the reinforcements. ["reinforce",true,mySom] Call BIS_SOM_requestSecOpFunc; Maintaining the array to lower the units would be tricky. Units in the group can share the same class name, you'd have to know which one to select. Another alternative, for better control, would be one of these two methods with Reinforcement phase scripts copied into your mission folder, modified for your mission purposes. You could script them to do the secop exactly the way you want it, and run them separate from the default or as the default.
  18. One thing missing from Darren Brandt's instructions is that when you place the empty WF airport object (hangar) in editor, you need to give the object a Name. Not giving the hangar a name causes a script error in the .rpt log like so: Error in expression <3ebe0f00# 1055260: ss_hangar.p3dSide = Ci> Error position: <ebe0f00# 1055260: ss_hangar.p3dSide = Ci> Error Missing ; Basically, the update script formats the object's name for a variable, but uses the object ID if it has no name. The script doesn't handle the formatted object ID as a variable, which results in error. So to avoid error, give the hangar a name.
  19. On the server at game start, create an array for storing player data when they disconnect. JoinedPlayersData = []; As players disconnect, have onPlayerDisconnected run code to store their information as an array within the array. // After three players disconnected JoinedPlayersData = [[_uid,_name,_funds1,_property1],[_uid,_name,_funds2,_property2],[_uid,_name,_funds3,_property3]]; As players join, have onPlayerConnected run code to check whether the uid in one of the arrays is a match. If no match, it's a new player and they don't get assigned values from the array. If one matches, they have rejoined. Assign the values from the matching array to the player. Then remove the matching array from the list: // After player #2 has reconnected JoinedPlayersData = [[_uid,_name,_funds1,_property1],[_uid,_name,_funds3,_property3]]; When they disconnect (again), onPlayerDisconnected stores their information in the array (again). // After player #2 disconnected again JoinedPlayersData = [[_uid,_name,_funds1,_property1],[_uid,_name,_funds3,_property3],[_uid,_name,_funds2,_property2]];
  20. onPlayerDisconnected https://community.bistudio.com/wiki/onPlayerDisconnected onPlayerConnected https://community.bistudio.com/wiki/onPlayerConnected
  21. I would suggest not using nil, since nil is a command. If you try destroying a variable later using nil, it will likely assign the handle for rifle.sqf instead. https://community.bistudio.com/wiki/nil
  22. Not that I'm aware of, but maybe someone else would know.
  23. The drag and carry part of First Aid, no addAction appears to drag the wounded unit, and there is no carrying since you first have to drag him. This occurs in missions when the First Aid modules are synched to units. It impacts on missions and the Basic Training medical aid scenarios. Thanks Goliath! -- edit: Running CO in beta mode. Occurs in A2 and OA.
  24. opusfmspol

    Problem with creating short- cut's to mods...

    Try removing the space between "=" and "@" maybe?
  25. Maybe you mean the Commander View camera? Numpad period [ . ] is the default. But the camera stays with you (the Commander).
×