General Barron

AWESOME!!! I've been wanting this for a LONG time (I think I never got around to asking though)--that is, the MP saving/loading functions being separate from the other SoW code. Packaging it this way makes your great work much more generic and useable by the community. I see many, many great things ahead using your work. Thanks a million! Unfortunately, I still have yet to get heavily into MP editing. So I don't think I'll be playing with these for a little while... but I'm glad I noticed this thread! When OFPEC comes back up, be sure to make a news post about it there, and I'd love for us to host it. Just taking a quick look at the download, I've got a couple suggestions/complaints: 1) The functions are all in the root mission directory! Please put them in a separate directory so they don't clutter the mission folder. I think all large script projects should do this. I'm a bit of a neat freak in this regard, but there are practical reasons for this as well. For example, if you update the scripts, all I would have to do to update my mission is drag and drop the new folder into my mission. 2) No tags on your global variables! *Puts on "standards police" hat* Stick a tag in front of your functions (eg "SoW_SaveRaw", or maybe "MPS_SaveRaw" for "MP save"). This does 2 things: prevents other scripts from conflicting (unlikely but possible), and it also makes it easier to understand what each function in a script is doing. For example, if I look thru a script and see a "SoW_SaveRaw" function call, I'll know it is a SoW MP saving function, and I'll know what documentation to look in for more info. 3) Script initialization clutters up init.sqs. Just something I've decided on thru my own projects: it is usually better to have a 1 line initialization in init.sqs for large script systems, instead of many lines. So basically, all the lines you currently have in init.sqs would go into a "SoW_init.sqf" function/script which is inside of the MP saving functions folder. All the editor has to do is start this init script in HIS init.sqs via one line. The reason? It makes updating a breeze. What if you add functions in your next update? What if you add variables, or other stuff that needs initializing? What if you remove functions? If this is all initialized in a separate script, all the editor has to do is drop in the new script folder. Currently, the editor will have to make sure to change everything in his init.sqs properly. And I speak from experience when I say that can be easy to overlook. ---------- Anyway, don't take my suggestions as criticisms. I only take the time to think about and give suggestions on stuff I really like. SoW has always been pushing the boundries of OFP, and I'd love to see that continue. Keep up the great work!

I'm not sure, but this MIGHT work: Go into your ofp/res directory. Create a new folder called "MPMissions". Plop all your resistance-only missions into this folder, and delete them from your normal MP folder. It MIGHT work, since addons/campaigns/etc placed in the Res folder only show up when Res is running. I suspect it works in a manner similar to mod folders. -EDIT- Nevermind, you can't make MPmission folders in regular 'mod' folders, so I don't see why it would work here.

Wow. That's an odd "feature" I've never noticed before.

Okay, haven't read thru all your post yet, but I see the general idea is that if you drop a particle below ground, it will return a negative value for it's Z position? So you use this + the fact that the drop can be relative to a unit's position, in order to drop them at sea level beneath a unit. Clever. Anyway, the only problem with this method (although it might be faster CPU-wise), is that it can't be run from a function (right?). So if you can't use it in an @ command or another function, for example. That's not to say it's bad though. Never hurts to have different ways to do the same thing. The right tool for the right situation, right?

Game logics have no 'physical bodies' to them, and do not interfere with other units/objects in any way, as far as I've seen. There are lots of scripts that place game logics at or near vehicles (eg for cameras) and do not interfere with them in any way. I've used invisible targets (an addon) and placed them exactly on a vehicle with no ill effects.

I have the same problem about not finding any players online. I'm not in a squad, and when I try to play online from time to time, few people are there. But when you consider how old this game is, there is actually a respectable amount of people online at any given time. I remember trying to play Rome: Total War online about 6 months ago, and not being able to find ANYONE. For one thing, I live at GMT -8, which is the opposite end of the world from where most OFP players live (Europe). So when I get on to play, others must be asleep/at work/etc. I'd head over to the MP forum and look for the "Zeus Server" thread. They seem to be a pretty good coop server, which has regular game times and the like. Some group with an organized game time is your best bet at playing MP. Hopefully ArmAs will bring fresh players back to the game. I'll help with your editing Q if the posted solutions won't work (i.e. players aren't all in the same group).

Just for the record, a chinook couldn't lift a tank. Normally they are dropped from C-130 or other large cargo aircraft. So for OFP, I'd suggest just having it fall down from the sky instead of a helo (or actual aircraft, since it might be too high to see anyway).

I think what Mr_Tea means to say is that even if you have one unit that isn't grouped to anybody, he counts as a group. Group units together. If you need so many separate units because you want them to stand in specific places, then putting this in a unit's init field will make them stay still until combat starts: dostop this Make sure their "special" field is set to "none" (not "start in formation).

Hey scribe308! I guess I'll post in this thread since you emailed me it's existance . Okay, I'll need to know a little more detail about what you are trying to do/why you are doing it (why write to file?). But until then, here is the general formula I use when trying to capture keystrokes with Fwatch. The main trick is you use the @ command to make the script wait until the Fwatch 'getkeys' function returns the values you are looking for: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> #Top @call {_k = call loadfile ":input getkeys"; ({_x in _k} count ["0","1","2","3","4","5","6","7","8","9"]) != 0} ...do stuff... ~0.5 goto "Top" This example will wait until any of the number keys are pressed (0-9), then it will do something, then it will wait again for those keys. There is a slight delay to allow time for the player's finger to come off the keyboard. Note that the "call" command will run whatever code is in the { }, and will return the last value that is found in that code. So in this example, the "count" command is the last command in the 'call' code. Count returns a true or false value, so that is returned to the "call" command, which returns it to the @ command. I've never used Fwatch's mouse functions, but they should work following a similar method. Again, give some more specifics and we can figure out exactly what you are going to need.

Very cool. Looks very customizable and easy to use. I'll check it out when my computer gets back from the shop.

Unless you are making one HELL of a mission (like Abandoned Armies), you don't really need to be such a nitpicking scrooge and worry about whether adding a few triggers will "slow your mission down". I have a crappy computer that only gets like 11 FPS on average maps, yet I can run tons of scripts, triggers, @ conditions, and all the other things that people spend SO much time worrying about "CPU overhead" from, and not even drop a single FPS. What DOES noticably lower my FPS is mainly (1) Graphic intensity (i.e. pretty user addons/islands) and (2) the amount of stuff running around/shooting/exploding around me. I'd guess that you would have to run dozens of triggers to generate the "CPU load" that you get from firing a single bullet. Again, unless you are pushing the limits of OFP script-wise, then don't even worry about this stuff. It's like trying to save for retirement by picking pennies up off the street. ----------------- On topic, I've run into exactly the same problem. Actually, I think I used 'setfog' instead of 'setviewdistance', because the player can't just change the fog level back to whatever he wants on his own. It was a jungle mission, and I wanted visibility to be limited in the jungle (more so than the actual 'jungle' objects limited view), but open when the player went into a more open part of the map. I ran into the same problem as you, but never actually solved it. It has something to do with how triggers repeat themselves. I often have trouble getting them to work how I think they should when set to "repeat". Radio triggers work fine this way, but other triggers are often tricky. I'd have to open up OFP to figure out exactly what I mean, but my comp's in the shop now...

That's pretty simple then. At the top of your 'drop weapon' script, just add the condition CD mentioned: ? (vehicle _guy) != _guy : exit ...continue with code to drop weapon... Obviously replace _guy with whatever variable you use to refer to the unit who will drop his weapon. I'm a little confused about this though... you can already pick weapons up off of dead guys, so why do you need to 'separate' the weapon from the guy ("drop" it)?

Also worth noting: In the early days of OFP modelling, there was no binarize tool to turn .p3d models from MLOD (what O2 saves them as) into ODOL. Older addons will use MLOD format models. ODOL models cannot be loaded or edited by O2. Until a year or two ago (?), converting your model was a way to "encrypt" them, so that no one else could *gasp* edit/use/learn from your work (unlike all other forms of editing, scripting, etc, which are freely viewable by others). Then some guys released a tool called "ODOL Converter" which converted ODOL models to MLOD format. Modellers of course cried that the end of the world was coming, that there would be rampant plagarism, etc etc if the tool was released. None of which happened since then, of course. The only result is that now it is easier to learn about modelling than ever before, because you can convert and then open up other people's work.

Also worth noting: In the early days of OFP modelling, there was no binarize tool to turn .p3d models from MLOD (what O2 saves them as) into ODOL. Older addons will use MLOD format models. ODOL models cannot be loaded or edited by O2. Until a year or two ago (?), converting your model was a way to "encrypt" them, so that no one else could *gasp* edit/use/learn from your work (unlike all other forms of editing, scripting, etc, which are freely viewable by others). Then some guys released a tool called "ODOL Converter" which converted ODOL models to MLOD format. Modellers of course cried that the end of the world was coming, that there would be rampant plagarism, etc etc if the tool was released. None of which happened since then, of course. The only result is that now it is easier to learn about modelling than ever before, because you can convert and then open up other people's work.

If it is just for the player, then the radius of the action shouldn't matter at all. Blanco made a great script (called "perma action" or something) that would always keep an action available to the player, even when he got in and out of vehicles. It was posted on ofpec, but if you IM him, he should have it. Anyway, your trigger might work just as well too. --------------- Another, simpler, option might be to just use radio triggers instead of actions. These are always available to the player regardless of what vehicle they are in, and only take one trigger to set up.

Or just create TWO shells at the same point in the air. That's how most flak/AAA scripts I've seen work. I don't know if this results in the explosion doing double damage (from double the shells) though.

Didn't they get the animations for OFP in this way as well?

This is already in OFP. I think the default key is "F". It makes you kinda walk instead of running.

Alright, another great tool from Voyager. I'm afraid to admit I have no idea what this would be used for though... ? ----------- EDIT Interesting tool to play around with. Addon-wise, you can see, for example, if OFP tries to access a file that isn't there (for example, there is a missing icon in the editorupgrade, which otherwise produces no errors). Mission-wise, you can see what scripts are being run. You can also watch OFP try and access a bunch of default files, like description.ext, config.cpp, config.bin, etc. It seems a bit buggy or incomplete though. Not all files are being shown, which I know are being accessed (init.sqs for example). It is showing two copies of a script that I KNOW is only running once. Anyway, perhaps I just don't know exactly what this tool is doing. Perhaps more documentation would be nice. I'm not whining, I'm just really interested in this thing .

You can use cutresources, but it will be a little complicated: you can't add any 'dynamic' text to them, like you are doing with the format command. So basically you will have to make 12 different resources, then determine which one to show depending on how many guys are left in the squad. To find the picture you are looking for, you will have to depbo one of the game's core .pbo files (data.pbo I think). Here is my tutorial on cutresources, temporarily hosted since OFPEC is down. After you read it, feel free to post any Q's you have on how exactly to make what you want: http://rapidshare.de/files/13815137/cutrsc1_1.zip.html

Interesting set of scripts. I'll have to look into them in depth.

I've never heard of "Prosphere Lite". Could you provide a link please?

Haven't looked at the new version yet, nor have I seen the jerking problem you are talking about. But one idea on what COULD cause a problem: When you 'setpos' an object over another object, wacky things can happen. For example, setting an object at 29m above an object that is 5m above the ground might set the object at 34m above the ground, while setting the object 30m above might result in it dropping down to 30m above ground level. So, perhaps when the camera is directly over a bush, rock, or other object, there might be a problem. Or maybe the ASL function gets screwed up. I dunno if it would be the problem, just throwing a possiblity out there. To test it, you could fly a chopper over the ocean--if it is still jerky, then you can ignore everything I said .

Press "L" I think. Or some other key. One of them will turn it off .

Whoops... now I'm not sure if this is the case or not. Yikes, shows my ignorance. Hmm... seems like a pretty basic MP question that someone with more experience ought to be able to answer easily...