Jump to content

mrcurry

Member
  • Content Count

    438
  • Joined

  • Last visited

  • Medals

Community Reputation

282 Excellent

About mrcurry

  • Rank
    Gunnery Sergeant

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. mrcurry

    can't delete sideEmpty

    allUnits returns all units, it does not return all objects. All units is a subset of all objects and most definitely doesn't contain objects of sideEmpty. Since your using synched objects now and trying to replace them instead push the managed objects inside a 3den layer and use getMissionLayerEntities
  2. Well that's a different beast entirely! 🙂 The original code was designed to handle involuntary disconnects of clients a.k.a. crashes, powercuts etc by saving the units loadout, position and direction on the server. I downloaded the test mission and ran through the issues I found. Here's some of them in no particular order. When respawn isn't enabled and testing with a single slot this script won't work, the server will have to be restarted every time which means the PlayerConnected event won't load the data since its not a JIP-connection. This is by design. When respawn is enabled it won't fire on the first loading of a mission. Successive connections will load properly though. This is also by design. Sometimes when the player connects the position won't be applied properly. Easily fixed by implementing a quick sleep in TAG_fnc_loadClientData. Something tells me that we're getting disparate results because we're asking it to do what it never was intended to do. For what you want to do; Instead of hunting down and squashing every little bug one at a time I would ditch this code and start from scratch. That work doesn't belong in this thread though, I'll send you a PM to sort something out.
  3. mrcurry

    UXO counting trouble

    Try this for your triggers condition: count ( thisTrigger nearObjects ["BombCluster_03_UXO1_F", (( triggerArea thisTrigger)#0) max ((triggerArea thisTrigger)#1)] ) < 1
  4. I don't know, conceptually, adding potentially several thousand new mission objects seems like it could have an effect. Even if the "original s" are hidden they still exist. Sure I imagine the rendering pipeline won't be bothered much if the replacement objects are of similar complexity but more objects spawned during runtime would mean more data to deal with, which in turn could hit things like network and simulation. I could be wrong though. If you got any neat tricks to share please do.
  5. Short answer: Yes, use hideObjectGlobal combined with createVehicle or createSimpleObject but be aware there might be a not insignificant performance-hit to this dependent on how many objects we are talking. Long answer: learn terrain modding and create a mod. Probably better performance-wise.
  6. @pierremgi In the test showed in the video (dedi-server with only client disconnecting/reconnecting) your code should still work with even with the nil-ing enabled. It does work on my test-bench. Yes, using the profileNamespace version is a bit pointless if your going to be resetting every time the mission restarts but right now it doesn't even run in the basic use case. @Noel Collins Since we know the code works by itself we need to go back to basics. Upload your test mission so we can take a closer look. Correct link added to previous post.
  7. So I just test ran @pierremgi's code and had a hiccup. When I copied from his forum post to the init.sqf a "ghost character" showed up which would prevent the script from working. This is why running test-benches with startup parameter -showScriptErrors is important. See image: https://www.dropbox.com/s/c2zewaykupzgwba/mysterycharacter.png?dl=0 Pierre could be messing with us... ...but more likely its an artifact from the forum formatting of the code. So check if you are also getting this in your init-file. To be safe retype "profileNamespace getVariable". After I busted the ghost the code ran fine on my test-bench. If it still doesn't work here's a couple of things you could do: 1. Check your CfgRemoteExec so that "spawn" is allowed. 2. Check the .rpt if some other error is being printed when you disconnect / connect. 3. If running with mods, give it a try without them to see if they are interfering somehow.
  8. Hmm I'll see what I can do, I'm working on a dynamic AirCav-focused mission, having villages seem "alive" as players patrol through them would certainly up the ante. I haven't had time to take a proper look at the code yet but is there an alternate execution which relies on given set of arrays for the shoppers, sellers and destinations etc instead of doing the varname search?
  9. Looking great! Really useful stuff! But I must ask about the elephant in the mission. How's the MP-compatibility? 😋
  10. TAG_disconnectedLoadouts also needs to be changed, the script in its current form relies on that global variables are defined in missionNamespace unless otherwise specified. But just changing out which namespace is used is gonna cause undefined behaviour when the same server runs multiple missions running the script. I've been planning to rewrite this using hashmaps anyway so I'll see about writing up a version for profileNamespace too
  11. You are only scanning the lower left quarter of the map. Use _size = worldSize; Resolution is going to be a problem, a way around that would be look for locations of type Mount, AFAIK they are generated at local high points by the BIS tools during the map creation process so are present on all maps, even flat ones. So something like this:
  12. Not at the computer at this moment to double-check but in my experience emptyPositions only cares about currently occupied seats. Whether a unit is assigned should have no bearing on the result. Hard to say more without seeing the relevant code. Some things worth thinking about: Have you checked the return of emptyPositions at the time of execution? Are you sure the emptyPositions are counted when you expect them to? Correlation does not prove causation and assumption is the mother of all fuck-ups.
  13. 1. Most likely it refers to the current active camera of the local client to where the eventhandler is added. Not sure how it acts on a dedicated server which I presume has no camera. Note the effect is only for remote objects. 2. Since you are looking to track shots fired then you don't need to worry too much about the camera. Instead add the eventhandler to the player and count shots on that player's client. Depending on how and when you want to present the result you can either send it to the server or keep it on the client. I wouldn't go sending a per shot update to the server though, just to save on network performance.
  14. Off the top of my head I would say it's an invisible object acting as the base object, All visible models are attached to the invisible object using attachTo and setObjectScale. The spinning is then achieved by a EachFrame or Draw eventhandler updating the invisible objects direction using setDir
  15. Its hard to say which method is the least intrusive, I think JBs suggestion is least likely to mess with purely editor-made scenarios but that's just a hunch, got no data to back that claim. All methods have their pros but at same time I bet most of us could easily think of a legit scenario design to break each method. I really question if a truly robust system is worth it. Imagine you would have to implement multiple solutions and use some auto-analysis or mission vars to control which method is used based on the situation for the group on question. Maybe this early it's better to go whichever is easiest and focus on keeping the whole "pause waypoint"-functionality as modular as possible so you can easily rework if need be
×