Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

Community Reputation

162 Excellent


About mrcurry

  • Rank
    Staff Sergeant

Recent Profile Visitors

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

  1. Keep it up, I see great potential here, not only for AI. I'm curious in how you get the floor points (blue) and how do you distinguish wall from floor, is lineIntersectsSurfaces involved by any chance?
  2. +1 As a side note for later readers: Replace select with find and the previously mentioned toLower (or toUpper) to cover use cases where the string structure is not guaranteed i.e. when Cars = ["a_car_1", "car_2", "3_car"] is a thing. Iterating on @Larrow's example: _find = toLower "Cars"; _array = ["a_Car_1", "Car_2", "3_car"]; _result = _array findIf { toLower _x find _find > - 1 } > -1;
  3. What GOM meant was that registering the event frame 1 means the first execution might be delayed until frame 2, hence the delayed execution. Generally OnEachFrame helps by running the code in unscheduled but other than that I see no real improvement. Take for example my Voronoi generation. A scheduled run would take 5-8s but an unscheduled pre-init run is <1s. If you can get away with a pre-init exec it should be preferred IMO.
  4. Okey I had a sneaking suspicion but now I'm pretty certain this is the case. The normal behaviour is to on a disconnect event transfer the player object to the server, kill it and leave it lying on the ground as a casualty, unless the player slot is set to be a playable AI. I'm going to go out on a limb and say that the bodies of your players stay behind when disconnected, am I right? If yes go to 1. If no go to 2. 1. If I'm right that's why it will never exit because the player object (which _player actually refers to) is never deleted hence it's never turns null and will keep evaluating the rest of the condition which can never be true since the player object is dead. Now, if this is the case you've got a choice to make. Either you: A. get rid of the player objects when they are disconnected. Deleting the bodies should resolve the issue of them not becoming null and let your loop continue. It also has the nice benefit of cleaning up the battlefield if that's what you desire. It might be worth deleting the bodies on killed event as well for consistency's sake, just make sure to check how that interacts with the rest of your mission. B. adapt your condition code to handle this edge-case. That way the bodies will stay on the ground but the loop will still exit. Unfortunately I don't have a tested way to check if a certain player is still connected. From what I gleaned from your script it is running on the server meaning that you should be able to just check if the body is local to the server. I recommend you test that approach thoroughly though. If that doesn't pan out you can maybe look into some of these commands and see how they behave in your situation: owner, getPlayerUID 2. If I'm wrong then I can only advise you to print out all variables and all the separate conditionals used in your waitUntil and look through the log to see which part is screwing you over. Best of luck and please let us now how it turns out.
  5. Well that conditions looks alright so maybe something else is also messing with you. Couple of things to try: 1. Make sure the variables _flag and _logique actually are defined going into the waitUntil. EDIT: by make sure I mean do a manual check using a printout. 2. Add a log printout of _logique getVariable "state" in the waitUntil and make sure it's set to what it's supposed to be.
  6. Since you haven't provided the full condition its hard to say. My guess would be that your condition fails because of your OR's left-hand argument. Everything else looks fine. If your left argument requires the player to not be null then swap the left and right arguments of the OR and then wrap the new right in {} brackets. That way it will only be checked if the left side returns false i.e. when _player isn't null. Like this: //Your current code: a or isNull _player //New code: isNull _player or {a} If that fails provide full code.
  7. mrcurry


    Interesting, is this just the case 'cause OP is probably working with global vars and is it just true for compiled code? I've always been under the impression that the game would release any memory no longer referenced by any variable, is that not correct? Sorry for the tangent but I'm really curious.
  8. 1. Redo this quoted part, it doesn't make sense. First you read the variables using params then you overwrite them using select but in a different configuration. Stick with 1 method (params is best IMHO) and make sure it retrieves the correct parameters. 2. Protect your variables! Don't just declare them. Use private. 3. Check your arguments so you are actually passing what is expected. Also in the future when posting errors paste the actual error from the .rpt file as well as your description of it. It helps.
  9. That's not inherently bad though. The entire game is built around the concept of the config for data storage. The impact of a "bloated" mission description should be negligible. Unless you got some solid evidence that it is slowing things down I'd argue that your optimization efforts are better spent elsewhere. Remember that the most elegant solution is not necessarily the best.
  10. Well closest thing you got is #ifdef but that is more for manual switching tbh. What is it that you're trying to do that requires such an approach. Instead of filtering on mod in the description.ext why not just load all configs and choose the appropriate ones during runtime?
  11. I threw something together that should do it. Note: In the above version I'm using colour-coded procedural textures to represent the numbers. Simply update _numTex with the paths to the appropriate images. Make sure the paths are relative to the mission root and that the images are sorted in ascending order e.g. if your images are stored in root\img then it should look like this: private _numTex = [ "img\0.jpg", "img\1.jpg", "img\2.jpg", "img\3.jpg", "img\4.jpg", "img\5.jpg", "img\6.jpg", "img\7.jpg", "img\8.jpg", "img\9.jpg" ]; By the way, if you don't mind please share your pictures. This has more applications than just range scores and it would be nice to have both the code and a set of nice working pictures in the same place. (If you don't wanna that's ok too ^^)
  12. No, at least not with just code. Best you can do is make a bunch of jpgs with different numbers (0-9) on them and load the appropriate one. If you want to larger numbers (>9) just use multiple billboards/screens to represent each digit. Writing a parser for that kind of setup shouldn't be to difficult, if you need one let me know and I'll throw something together.
  13. AFAIK the short of it is: 1. Start server with -filePatching parameter 2. preprocessFile, loadFile or execVM the file on the server. If you need the data on the client you either have your server broadcast the data or have your client query the server for it. This has been asked before though, to get the long answer you will need to do some searching. Also this is non-sensical. isServer will always return true inside initServer.sqf and the exitWith will never fire.
  14. I think what @pierremgi means to say with his short rant is: set the groups behaviour to safe and you should be dandy. group _chief setBehaviour "SAFE"; The topic has been discussed before, give the forum a search (or 10) if you need more details.