Jump to content

JB47394

Member
  • Content Count

    105
  • Joined

  • Last visited

  • Medals

Everything posted by JB47394

  1. When I'm going to incapacitate a player in a vehicle, I player playActionNow "unconscious" and I also do a moveOut on them. Then I look for an empty seat in the vehicle to move them back into, excluding the driver's seat. The net result is that if a driver/pilot is incapacitated in a full vehicle, he gets kicked out.
  2. I think this is a pretty simple one. I have the following configuration commands for chat in my initPlayerLocal.sqf: 0 enableChannel false; // No global channel 1 enableChannel [true, false]; // No side voice 2 enableChannel false; // No command channel 4 enableChannel false; // No vehicle channel Note that side voice chat is off, but side text chat is on. When the mission starts, the player has side channel selected. If the player doesn't change channels, keys up voice and releases again, he'll be stuck with a hot mic in side. ARMA apparently doesn't reject the attempt to get into voice, but rejects the attempt to get out again (after all, voice is turned off). The only way out of that predicament that we found was to change chat channels. Note that additional PTT key presses and releases didn't have an effect. The solution I used at mission startup was to just set a channel that has both text and voice chat enabled. In our case, group.
  3. In production languages, there is invariably a switch to let symbols be defined from outside the source file(s). This is done to allow configuration of a source file when it is built. Frequently, it is done for multiplatform support, or simply as a testing or instrumenting aid. I can't seem to find such a feature for ARMA. What I want to do is start ARMA with a series of -define options on the command line. Most importantly, I want to define a TEST symbol so my scripts can turn on various test code during development. When run on a dedicated server, that symbol would not be defined, so none of the test code would be turned on. I'm not looking for workarounds. I know several. I would like to know if there is a technique in ARMA that allows a #define to be injected into every preprocess run of a script file during a run.
  4. For the record, the above doesn't work. Nor do myriad other variations that I've tried. In case anyone else bumps into this, a symptom of the problem is that when a helicopter stops, it can be moved onto the ground using Zeus. When it touches down, it immediately lifts off and continues with its waypoints. As I have given up trying to find the right incantation, I just worked around the problem. I spawn up the paratroopers off the map then send in the aircraft. When it reaches the waypoint where it's supposed to start dropping paratroops, I move the paratroopers one at a time to the cargo exit door of the aircraft (memoryPointsGetIn), setVelocity on each, and proceed through the parachute drop. A little more work to handle situations where the aircraft is destroyed and I've got the 99% case covered. I haven't done anything about a damaged aircraft landing safely. It hasn't come up yet, but if it does, it's just a little more patchwork.
  5. I know that this comes up a fair bit and I was originally posting to ask for help for a solution. This is about the third time I've started this post - and it works out that I finally landed on a solution. Here's the situation, followed by the problem and, happily, the solution. I spawn a flying helicopter (Kajman, Orca, Mohawk, etc) using createVehicle "fly" setFlyInHeight 50-200 I spawn the crew in a group and move them into the helicopter using (as appropriate) assignDriver/assignGunner/assignTurret moveInDriver/moveInGunner/moveInTurret I spawn the troopers in a group and associate them with the helicopter using addVehicle I move them into the helicopter using assignCargoIndex moveInCargo Waypoints are created on the crew group. They are move, careless waypoints. One is set at the start of the drop, one well beyond the start, and one back where the helicopter spawned to get it home again. The waypoint at the start of the drop has waypoint statements on it to start the process of dropping the troops. Waypoints are set on the trooper group. They are conventional infantry move-style waypoints. Sometimes the trooper group is split into one-man groups so that they can each go their own way. The paradrop itself consists of going through the units in the trooper group and using unassignVehicle moveOut allowGetIn false orderGetIn false sleep The result is that the helicopters fly, hit their drop waypoint, the troopers jump - and the helicopter stops. Almost every time. But not always. When the helicopter stops, it slams on the brakes as soon as the first trooper exits the aircraft. Then it will lower to around 50 meters AGL. If the ground below it is flat and open, it will land, then take off and resume following waypoints. Normally they just hover over the terrain indefinitely. If I manually push the helicopter onto the ground, it will also take off and resume following waypoints. The solution? Don't set any waypoints on the troopers until they are out of the helicopter. Note the original order: 1. Create helicopter 2. Create crew 3. Move in crew 4. Create troopers 5. Move in troopers 6. Create crew waypoints 7. Create trooper waypoints 8. Jump ARMA doesn't like the fact that the troopers have waypoints when they exit the aircraft. Reversing steps 7 and 8 solved my problem. My helicopters now fly through their drop at speed and continue through all the waypoints on their list. I hope this helps someone else battling this stuff.
  6. JB47394

    Side tabs disapearing

    Steps to reproduce (if we're talking about the same problem): 1. Click Units (single man) 2. Click OPFOR (red) 2. Enter "qilin" as a filter 3. Click BLUFOR (blue) 4. Click Units (single man) The blue box allowing selection of BLUFOR units is gone. It will come back if you re-enter Zeus. This reproduces the problem for me in vanilla ARMA.
  7. If badly done, yes, it would lead to security issues. There's no reason that it cannot be done.
  8. I call createDiaryRecord to put entries into a log in the diary during a game session, using the alternate syntax that allows the creation of a 'subtab'. So long as the player doesn't respawn, the records that I add are listed in the usual manner, newest to oldest, top to bottom, under that 'subtab'. My problem is that each time a player respawns, ARMA decides to create a new 'subtab'. My calls look like this: player createDiaryRecord ["Log", ["Special Operations", _logEntry]]; If I respawn three times, I'll end up with four tabs listed, all named "Special Operations" under the "Log" tab. Am I using this the wrong way, or is a new subtab for each instance of 'player' the expected result? Is there some workaround that avoids the creation of all the subtabs? I want a continuous log in a single 'subtab'.
  9. Thanks, but that will only ensure that one record is ever added to the Log subject. I have many records, added over a long period of time, and I want them all under one entry called Special Operations; it's the special operations log. I'll be moving the log into its own top-level subject as I don't see another way of doing it.
  10. Yes, I was trying to use "Briefing" for some strange reason. Thanks. I'll keep that in mind when designing this stuff.
  11. Thanks for trying to duplicate this - and my apologies for sending you off chasing a red herring. It turns out that it's an interaction of multiple diary records using the alternate syntax under the same main tab. That is, if these calls are made: player createDiaryRecord ["Log", ["Special Operations", _message]]; player createDiaryRecord ["Log", ["Notification", _notification]]; player createDiaryRecord ["Log", ["Special Operations", _message]]; player createDiaryRecord ["Log", ["Notification", _notification]]; then you'll see four subtabs on the Log tab of the map. As long as they alternate, they'll pile up new subtabs. And we're piling up subtabs. I can't imagine why Bohemia would implement it this way, but I rarely find their design choices intuitive. I don't suppose you know a way of working around something like this? Other than dumping the Special Operations log into its own main tab. I tried putting it into the Briefing tab, but that was just ignored (despite the fact that the Briefing tab is empty).
  12. JB47394

    Disable the Light on a "Device?"

    Good idea, thanks. I'll keep that in mind when I'm fooling with it again.
  13. JB47394

    Disable the Light on a "Device?"

    I'm also interested in doing this. I can see the device's SimpleObject.animate values in the config browser, but going through the usual 'animate' experiments yielded nothing. Is there a way to affect any of the animations listed in an object's SimpleObject.animate property? Running the device through a startup sequence would be a nice storyline addition.
  14. I just looked at the code you're creating and I see that you're relying exclusively on naming conventions, leading to a need to create constructs such as the following (on an interface call): ([_object, [_pos]] call compile ("_this call cl_" + ((_object select 0) select 0) + "_TeleportToPos")); }; That's taken from the interface example in your documentation (which is very clear and concise, by the way, thank you). You offer a warning about the use of interfaces in high-performance situations as a result, and I can see why interfaces warrant a warning. If you rely on numbers instead of strings, you can just create some global arrays and do three array lookups to call the right method. You'd be creating vtables for your interfaces. The same could be done with classes and you're all set to implement subclasses (single inheritance only, please). Class numbers would be assigned at runtime on a first-come-first-served basis. The lookups would be: 1. Get the class index out of the instance 2. Get the class vtable out of the interface table (accessed via a global name) 3. Get the method out of the class vtable In the above example, that would result in the code ([_object, [_pos]] call (Units_ISoldier_VTables select (_object select 0) select 0) That should perform nicely. I like the use of strings because it makes debugging much more intuitive, but having numbers and lookup tables makes things run faster. Having both at debug time would certainly provide the best of both worlds. Lastly, I think it's awesome that you chose to implement interfaces.
  15. As I mentioned above, I did. I switched away from it because of some kind of problem - which I don't recall now. So I guess I'll have to re-encounter that problem or find out that it was a red herring that caused me to switch. It would be nice if Bohemia would just let us specify an initial transformation matrix for the spawned vehicle... Clearly the fractal wave stuff doesn't try to keep its calculations in the middle of the single precision range. Not that there's any need for it to do so.
  16. It's a trivial exercise. Place all instances into an array, assigning a unique index to each instance. Place that index at the beginning of each instance. Now you can create a Pointer which is an index. The index can be converted into an instance and vice-versa. The index can be passed over a wire or used as a reference from a child to a parent so that ARMA's recursive arrays are avoided. Because developers work with multiple types, the Pointer should also include the index of the class so you can go to the right table of instances. That takes us back to [type-index, instance-index] pairs as the Pointer implementation. The inability to have circular references would cripple pretty much any design I'd ever think up. I'm quite surprised that anyone would suggest such a thing. Doubly-linked-lists, circularly-linked-lists, and parent-child are three trivial examples that spring to mind. At a broader system design level, I don't worry about whether two objects have indirect references to each other because I don't care. If I've designed my components correctly, I won't have problems. I want that rope and I work diligently not to hang myself with it - just as I do with every other rope in my kit. I have not tried with TypeSqf, but the source of the problem lies with ARMA. If two arrays reference each other (or if there is an indirect connection between them), ARMA generates an error regardless of how the SQF code came into being. I wouldn't have started down this road if I hadn't run into the problem in my own stuff. I implemented my own pointer mechanism to work around it, and that's what I'm encouraging you to tackle. We're talking about the same basic thing, where Type A references Type B which has a back reference to Type A. But I'm not concerned with resolving names at compile time like you are because I don't have a compile time, just a run time. Like the rest of my script, object references aren't typed, and that's why I'd really like to go with TypeSqf. But if you don't implement a basic Pointer mechanism, then I'll have to do it myself. I guess that if I had a Type A for my instances, I'd create a Type A_Pointer to represent a pointer to that class so I keep type safe with my pointer references. Type A would have an index on it, and Type A_Pointer would hold the index of any instance that it represented. Then I'd create a Dereference method on A_Pointer to get back the original instance. It'd work, but I'd be happier if I didn't have to keep creating a pointer class for each instance class. No, nothing compile time. My actual project is a multiplayer mission system that is entirely script-based. It was getting incredibly-unwieldy as raw scripts, so I fell back on macros for some object-oriented support. They're not pretty, but they get the job done. Here's an example of what I have to type right now: OO_BEGIN_SUBCLASS(Class,Parent); OO_OVERRIDE_METHOD(Class,Parent,Method,method); OO_DEFINE_METHOD(Class,Method,method); OO_DEFINE_PROPERTY(Class,Property,"type",default); OO_END_SUBCLASS(Class); Here's getting and setting a property: private _property = OO_GET(_instance,Class,Property); OO_SET(_instance,Class,Property,_property); Here's calling a method: [_parameter] call OO_METHOD(_instance,Class,Method); Ugly, but effective. It all ends up being arrays, of course, but there's runtime overhead that I'd love to discard. On the upside, because I control the macros, I can instrument them to put stuff into the report file and to check anything I'm interested in. Right now, my debugging relies heavily on seeing an indented list of OO_METHOD and OO_SET calls in the rpt file. It would be nice if you provided debugging hooks for everything (if you don't already). Or at least some standard options to kick out trace information per class or some such thing. My apologies for not looking deeper into TypeSqf. I've got my hands full with my own project.
  17. [-10000 - random 10000, -10000 - random 10000, 1000 + random 1000] I don't worry about collisions.
  18. I'm very much looking forward to using this on my current project. I'm relying on macros to do what you've done with a dedicated preprocessor and it would be wonderful to be able to move beyond notation-heavy macros. I noticed two things in my first quick test that I got errors on: if (not isServer) then The parser seems not to realize that 'not' is the equivalent of '!'. ----- Also, I use a macro which is obtained by including from a .h file. It is a way to trace function calls, so it looks like this when used: MACRO(method) = { }; TypeSqf doesn't like it at all, flagging a syntax error on MACRO(method) and stating that MACRO cannot be used as a target for assignment. ----- More significantly, I'm wondering about instance references. Pointers. ARMA arrays are passed by reference locally, so there are no problems treating them like objects. But if an instance is sitting on the server and a reference needs to go to a client (equivalent of netId et al), there's the question of how to do that. Have you tackled this or do you plan on tackling it? Or is this something that developers will have to do on their own? Like ARMA, I do the obvious, which is to create a lookup table of instances. Each instance includes its table index, so I can do instance-to-id and id-to-instance conversions. (I also have the instance's type index in each instance) So my instances look like [type-index, instance-index, property, property, property...] The reason for having a netId equivalent is that I may roundtrip to the client to perform some user interface action, and then go back to the server again. During that round trip, I want to hang onto a reference to the key object involved. I send the [type-index, instance-index] part of the key object back and forth. The next step after that is to include the owner of the instance in that reference so scripts can call methods and manipulate property values of non-local instances. I haven't done that yet, but it's certainly waiting in the wings. ----- Lastly, what do you do about circular references between instances? If parent and child instances reference each other, then you end up with a "recursive array" in ARMA parlance. I have a reference property type that uses those instance references from above to be able to break that recursion. If you've found a better way, I'd love to hear about it (such as knowing that we can tell ARMA to stop objecting to "recursive arrays" if they aren't going to be sent over the network. My apologies if you've answered these things elsewhere. I scanned this post and didn't see anything about more advanced topics.
  19. Super colossal awesome. Thanks. That's exactly what it was. I'd never spawn at the origin because of the fear of spawn collisions. I used to spawn at large negative coordinates (random) that were well above sea level, relying on probabilities to avoid spawn collisions. I don't recall my reason, but I switched to spawning at the target location at -10km Z. So I guess the new scheme had the problem that when the spawn script was interrupted between spawning and repositioning, ARMA would see where the vehicle was and consider its engine flooded. I went back to the large random negative coordinates and the vehicles reliably get moving. Unfortunately, there was a reason that I ditched that approach - but I don't recall what they were. Are there problems with large negative spawn coordinates for ground vehicles, or spawning high in the air? My old approach would spawn vehicles up to 10km up the air. I've reduced that to be no higher than 2km, but I'm still curious about whether ARMA will react to vehicle engine oxygen starvation. Thanks again.
  20. Here's a feature request that others might appreciate - and if I've missed the ability to configure this, please let me know. When typing into the debug console's immediate evaluation lines, scripting errors are sent to the report file. So as I'm typing, and the script is in some malformed, intermediate state, the report file is being bombarded with script errors, one per frame, polluting whatever other information I was routing there via diag_log commands and such. If I left a command in one of those immediate evaluation lines at the end of the prior session that doesn't make sense at the start of a new session, the log file is again bombarded. It would be very nice if the immediate evaluation lines didn't do this. I could work around the problem by composing my commands elsewhere and then pasting them into the lines, but that's a workaround, and a hassle. Ideally, the script in the line itself would not log errors while anything that it called, would. Oh, and if you could indicate errors in the immediate lines via an icon instead of flashing, that would be great. You're going to trigger epileptic seizures with that strobing effect. If you do the icon, have it show the frequency of errors over the last 1 second (or some such interval). If the line has been evaluated 60 times in the last interval and it generated an error every time, show a red icon. If 50% of the time, a yellow icon. And so on.
  21. Thanks, Ceeeb. Yes, I've noticed that lots of reports seem to go untended for years. It doesn't inspire much enthusiasm for adding new ones. As for the rest of the suggestions, thanks, but I can work around the problem as well as the next man. The point is not to work around it, but to get it fixed - because it's a flawed implementation.
  22. That's not a reasonable workaround. Just as you rely on the watch lines generating errors, I rely on being able to do visual pattern matching on log files. It's not a case of simply locating one line, but of seeing a pattern in many lines. If the lines that I'm trying to examine are interspersed with piles of immediate evaluation errors, I cannot see the pattern. I'd also like to turn off the Bohemia report garbage as well. This is akin to being able to control exception reporting in Visual Studio. Alter my request to be that the line doesn't evaluate so long as the user has focus on that line. So if I click on the line, it stops evaluating. While I edit, it doesn't evaluate. If I click off the line (or hit Enter, which causes focus to leave the line), it starts evaluating again. The important thing here is to stop evaluating code for validity when it that hasn't been completely written.
  23. I've read through countless posts on scripting explosions, and I can produce some nice ones as a result. But ultimately I don't have an understanding of which ammo types can be used with createVehicle. I tried just running a script to create one of each type under CfgAmmo, but that only succeeded in crashing ARMA. What property or properties on an ammo entry indicates that it will produce an explosion when created? Or is there some other indicator, such as properties in CfgVehicles entries or some such thing? Note that I'm not looking for anyone's list of tried ammo types. I'd like to know how ARMA handles this stuff.
  24. Thank you, sir. That's what I was after. Edit: Here's a configClasses query that will give me what I'm after. Note the additional check against the value of explosionEffects. "getNumber (_x >> 'explosive') == 1 && getText (_x >> 'explosionEffects') != 'ExplosionEffects'" configClasses (configFile >> "CfgAmmo") The createVehicle then works off the configName of each returned entry. The only exceptions seem to be FuelExplosion and FuelExplosionBig, which reference specific effects, but which don't seem to be working.
  25. It doesn't get much simpler { (configName _x) createVehicle (getPos player); } forEach ("true" configClasses (configFile >> "CfgAmmo")); I throw that into the debug console while in multiplayer and it'll produce a crash to desktop every time. I'm running other scripts, but no addons. I haven't tried outside of my scripts nor in single player. Replace the createVehicle with systemChat or diag_log and it cranks through the entries with no problem. Call createVehicle on the usual "SmallSecondary" or "Bo_GBU12_LGB" and ARMA creates the expected explosions. Also, there are 350 CfgAmmo entries, so I ran a loop that created 350 SmallSecondary explosions at my location to see if that would crash it. There's an appreciable pause while it creates them, but there was no crash. I also did a version that had a first loop that spit out all the configNames to the report file, followed by a second loop that spit out the names as it created the vehicles. The full list of names appears in the report file twice, so the loop seems to be completing (it's not choking on the createVehicle of a specific name), but ARMA is dying from trying to handle the resulting pile of objects. I assume nobody here knows the answer as to how Bohemia decides to turn a CfgAmmo name into an explosion.
×