UNN

I happened to be looking through the definition for class All in Bin.cfg. And noticed SecondaryExplosion was defined as: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">secondaryExplosion = -1; Perhaps it's not supposed to be a true\false value? Edit: Yep, spotted it in the wiki to: secondaryExplosion

There were a couple like that for OFP to. Thanks, it all helps. Can't speak for DrBobcat, I'm not exactly sure what he wants. But most of the time, range and velocity are the only things you do know. You’re looking to find the correct elevation and time of flight. I think DrBobcat was talking about moving the object along the parabola using scripts, not the Arma engine. At least, that should be assumed, when talking about parabolas and Arma.

@weegee_101 Lol..I nearly did the same thing It is a good site. I only wish they provided the source code for the online calculations. Would make it much easier to understand, at least for me. @DrBobCat The trouble with using parabolas is, your going to have either very high or low elevations: The yellow plot uses an Arma round, the red is a standard parabola. Ok, so you won't always have to worry about a 600 meter high mountain between you and the target, most of the time. But the angle of attack, at the point of impact, compared to Arma, is considerable. Which increases the chances that your going to hit something else, before you reach your target? You can go the opposite route, and fire at +45 degrees. But then the time of flight is dramatically increased. You could cheat. Half through the time to live of your shell. You could teleport it into position, so it reached the point of impact in good time, with the correct angle of attack. I have a spreadsheet that plots a parabola over time, if you want that? I found that to be easy enough to transfer into Arma scripts. Although its nothing special. But as for calculating time of flight, range and elevation e.t.c before plotting, I can't really help. I decided that parabolas were not suitable for what I wanted. So I never looked into it further. From what little I understood on hyperphysics, I think you have to use a combination of those equations, to obtain all the info you require. For example. If you know the range, then you can calculate the time it takes. With both the range and the time, you can calculate the required elevation. But don't quote me of that, maths has never come easy to me

Well we are really just using the same concept as you did with ACES. Cargo proxies are still the most flexible way of changing the appearance of vehicles. We are trying a slightly different approach. Plus, Arma's scripting and config changes help circumvent some of the problems you faced in OFP. But it's still a lot of work, to produce less than perfect results. But hopefully, most of the time, no one will notice

Ejecting dead crew can be a right pain in the arse. The only ray of hope is, we can at least, circumvent it with the config. I know the default Land vehicles are ok, haven’t tried Aircraft and Ships yet? But that’s just the tip of the Iceberg. Trying to do anything with crew proxies, that wasn't originally intended, just results in a load of baggage But I guess it's better the ability to moan about it, rather than never being able to do it at all

Well I dunno about that. Personally I think Arma scripting is a world unto itself It was a case of, if I'm going to reply. I may as well try and make it as accessible to as many people as possible.

It's the name you give it in the mission editor: Lines like this: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_unit = call compile format["%1",_name] Compile the string (name of the object) into a function. Calling that function then returns the object, that was originally assigned the name, in the mission editor. It works with integers and some other variables to: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">MYNUMBER=2; _Number=Call Compile "MYNUMBER";

I heard something along those lines myself. But textures was just an example, weapon proxies are another. Along with  open and closed top vehicle variations e.t.c Proxies go some way to sharing common object meshes, but they still seem to have a lot of problems.

Would it be handy if you could inherit from other p3d's? For example, you could inherit from an existing p3d just to override the texture paths.

You use the lbSetPicture command.

Removing any wreckages e.t.c sounds like something done with scripts? How do you know the scripts aren’t the cause of the drop if FPS. I suspect there is no such thing. Considering the complexity of the game without it, JIP is a brave undertaking compared to any other game? I'm sure BI are still working on improving it. There was an obscure bug that caused desynch with JIP, if you had your squad in a vehicle when you disconnected and reconnected. It's been fixed since 1.14 and I can't remember seeing it in the change log.

You can, and it will reload the script with the changes. Although I guess the OS could be informing Arma when the file changes? I also ran this test script: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">_Count=0; _MyTime=Time; _Func=Compile PreProcessFile "Script2.sqs"; WaitUntil    {    //_Result=[] Call Compile PreProcessFile "Script2.sqs";    _Result=[] Call _Func;    _Count=_Count+1;    (_Count==1000)    }; Hint Format ["Result %1 %2",Time-_MyTime]; PreProcessing the file outside of the loop always resulted in less time taken, compared with processing it in the loop. The larger you make Script2.sqs or the longer the loop, the more apparent it becomes. Obviously with small scripts executed once or twice in a game, it makes no difference. Even the above test only resulted in tiny performance changes. I'm happy to believe that BI included the new functions because they serve a purpose, rather than just doing it for the sake of it? One definite advantage when it comes to referencing scripts with variables is the ability to reduce network traffic. Communicating a variable name across a network can require less data than communicating a script name and it's entire path. As for the advantages of memory and saved game management, I'm not really qualified to say. But I prefer the idea of having the commonly used scripts and functions, loaded into unique, static memory locations, for the duration of a mission. Rather that loading and unloading multiple copies of the same script. When the duplicate scripts will occupy multiple locations in memory. For me the appeal is not so much about performance or efficiency, it's more about stability. For example pre-loading all the scripts and functions will result in a larger saved game, but the size will remain relatively constant. As opposed to loading all your scripts when you need the. Sometimes the save game will be small, sometimes it might 10x larger, depending on what’s been loaded at the time. So far I've used a mixture of both, depending on the frequency, size and purpose of the required scripts. But if the saved game issues have been resolved now, when it comes to global vars? I would be happy to convert every script that’s called more than once, over to precomiled global script pointers.

The way I see it, it has to be in at least two stages. The same way starting a regular MP works: The first stage being every thing that goes on while players are in the briefing screen. Including organizing groups and vehicle roles e.t.c Executing all the script commands encountered up until a script is paused with Sleep e.t.c The second stage starts once the players move into mission from the briefing screen. Finishing off any scripts that were paused during the first stage e.t.c JIP looks very similar: The first stage probably as above, with the addition of processing all the SetvehicleInit commands executed on the server since mission start. Scripts launched with SetVehicleInit are also subject the Sleep command. It looks like the processing during this stage, is represented on screen as a progress bar. The second stage, again, including all the SetVehicleInit commands still to be finished. As all of this can take an undetermined amount of time. At some point, as whisper says, the client has to be re-synched, as no doubt something has changed since startup. How is this measured? Are there any concrete guidelines for optimising JIP. I would certainly be interested in seeing them, as long as it was info gained through experimentation rather than personnel preference. I guess some things are just common sense, this must be bad: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">For "_i" From 0 to 1000 Do     {     _Object SetVehicleInit "[""This is a very long string designed to waste space""] ExecVM ""AReallyLongNameUsedToDescribeAScript.sqf""";     }; ProcessInitCommands; Compared with: Init.sqf: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">S1="This is a long string designed to waste space"; S2=Compile PreProcessFile "AReallyLongNameUsedToDescribeAScript.sqf"; <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">For "_i" From 0 to 1000 Do     {     _Object SetVehicleInit "[S1] Spawn S2";     }; ProcessInitCommands; Ok, might not save massive amounts of time, but the difference in size must have some effect when executed a 1000 times?

I'm sure you know more about animating (ships or whatever), than I do. But for what it's worth, I think class thing would not be a bad start? Apart from the fact that it appears to be underused in general, BI do use it for the barrel class. Also, it's easy to convert class static to class thing in the config. But perhaps I’m just lazy So either thing or ship, at least class ship should cope better in water?

That’s what I was thinking. Class static e.t.c appears to take a lower priority than the other classes. It becomes even more apparent in MP. Can you get away with making your animated sections, as seperate objects using a different class?

What is the exact cause of the problem? I mean. Have you looked at the increments of the animation source over time? i.e Is the animation source incrementing in smaller steps than the animated parts of your model. Or does the anim source appear to increment at the same rate as the animated parts?

It's been a while since I messed around with animations, but I observed the same problems you did. The distance a linear translation moves is directly related to the animation source. Hence the distance of 1m. I tried all these values you listed without seeing any apparent change. The only examples I've seen are in the model.cfg's released by BI. They only cover dampers, so there is never any need to go beyond the 1m limit. Like I said it's been a while and I can't remember if I tried using my own animation source this way. If you can define your own min and max values for user defined animation sources i.e 0 to 1000 instead of 0 to 1, then it should work ok? An alternative, all be it, far from ideal. Would be to have nested, linear translations using bone inheritance. The theory is, three connected bones, each with it's own 1m translation. Would then extend to three meters max, based on a single 0 to 1 animationphase. If that makes sense? Anyway let us know how you get on.

No, but there is no reason why you can't write a mission that looks for specific custom addons. If there present then use them in the mission, if not then use a stock, BI alternative.

Perhaps more emphasis should be placed on the fact that, there is an active group of people who share the same interest in developing the more esoteric aspects of game? As icemotoboy says, logistics are an important aspect, even if they do lack the glamour. I can't see why there should be any conflict or contradiction, in striving to further shared goals?

It's a pain in the arse, but not a total one. It might only effect enclosed spaces. I think some addons won't have a problem? At worst, it will either mean modelling the bulk of the vehicles visual LOD's, as proxies. Or, use external Cameras, for any Player sat in a cargo position. I think BAS did something along those lines with their infantry addons? When they first developed the concept of cargo proxies in OFP.

Well the only real issue, is still the problem we highlighted, some time ago in this thread. Whether to allow vehicles to be loaded, by driving them into the back. The way the ARMA engine prioritises the drawing of the Cargo LOD, verses the rest of the world, causes some wierd looking graphics. The simplest solution, is to not allow anything to walk or drive into the back of the C130.

createvehiclelocal by definition, will only work for a single player. Plus, a certain amount of delay is to be expected, if you’re trying to communicate across a MP network. One thing to consider though, is to avoid using class Static. This has an inherent delay in MP.

The new modelToWorld command would help in this case. If used in conjunction with the position parameter of createVehicle, you can avoid placing objects inside any existing map objects e.t.c

I've worked with CSJ on Med Evac for OFP. Treating stretchers e.t.c as vehicles, wounded infantry can occupy is pretty straightforward. If the stuff we are working on fits into their plans, as Rock says, we will try our best to implement it. Ultimately this will lay the groundwork for more specific RKSL projects, but a wider acceptance is very much the goal of our team. @Fk Andersson Cheers. the public beta, should (fingers crossed) follow shortly after. We will let you know before that happens.

Yeah, it's pretty easy to get it to work with anything that shares the same cargo proxy layout, of any vehicle that's already defined. So reskins will just be a case of adding a single command to the init field (or config) or init.sqf. <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">[This,"BIS_TRUCK5T"] Call RKSL_RegTransport As themaster303 said, there isn't much room for visible cargo. I should also point out that, without the new VBS2 commands, each cargo object has to take up at least one passenger position. So unfortunately, for the likes of the Hilux and Datsun, once you have something loaded in the back, you can't have anyone sat in the from passenger seat. But now BI have released their p3d's, you can always create your own version of the hmw, with extra cargo positions and an animated boot e.t.c You can also setup the vehicles to carry non-visible cargo, so you’re not limited by the number of cargo proxies, although that will probably be implemented after the first release of the public beta. I want to make sure the hard stuff works in peoples MP missions, before adding the bells and whistles. For players, it's just a case of dropping the vehicles and cargo into the editor. Getting the AI to use it will require a bit more work from the mission editor. But I will try and include as many commands to help out as I can. I'm not a mission maker, so I'm always open to suggestions on how to make it easier. I hope to include an example mission that sets up an AI supply chain. Airlifting cargo from an off map location, then distributing it around the island using a variety of vehicles. There is a lot that can be added, like automated warehouses and supply depots e.t.c but one step at a time. Cheers