Jump to content
Bohemia Interactive Forums

AgentFox2

Member
 View Profile  See their activity

  • Content Count

    170

  • Joined

  • Last visited

  • Medals

Posts posted by AgentFox2

  1. Posted

    How about adding a supersonic suppressed round/mag as a new class? (ie keep the SD as the subsonic and using something like SUP for supersonic ones). That would keep backward compability and enable more choices in the future.

    That could work, but only problem then is that many of the larger weapons packs now use the "subsonic" ammunition, when they should be using supersonic. The number of weapons that can use subsonic ammo are a bit fewer than those that use supersonic with a suppressor. So I think in the end the workload for authors who have to change to supersonic versus those who have to change to subsonic is significant. If you keep it as it is, then most suppressed weapons addons utilizing JAM will have to update themselves. If you make the SD mags supersonic, and add a subsonic class, then far less will have to update.

    But that's just my opinion. smile_o.gif

  2. Posted

    That sounds great to me!

    I hadn't thought of the impact changing the firing signatures would make to existing missions. Good catch!

    I think creating the extra subsonic ammo for all the suppressed mags would be a great compromise.

    Additionally, I just had a thought about the initspeed value. I had forgotten that the 744 value might just be specific to the M4, so I rechecked the Marine config.

    M4 Non-SD Initspeed:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=874;

    M4 SD Initspeed:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=774;

    AK74 Non-SD Initspeed:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=899;

    AK74 SD Initspeed:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=764;

    AKS74U Non-SD AND SD BOTH Initspeed:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=735;

    Obviously not as many of calibers or munition types present in JAM, but there is something of a pattern, at least in the full rifles.

    M4 NSD-SD

    874-774 = 130

    AK74 NSD-SD

    899-764 = 135

    I dunno how useful that information is, or even if that difference was deliberate, but maybe supersonic SD ammo should be reduced by some approximate amount relative to the non-SD muzzle velocity? Perhaps some testing should be done with that to see if that is an acceptable concept.

    Take care. smile_o.gif

  3. Posted

    Optics zero is controlled by

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">distanceZoomMin=400;

    distanceZoomMax=400;

    in the config of the weapon. The above value is what most of the BIS weapons are set to (M16, AK, etc), and JAM's demonstration weapons inherit directly from these classes without changing the value. So this value is largely outside of JAM's scope (because it is in the weapon code, not magazine).

    The problem is that with a low initspeed value (which is unrealistic for many of the weapons supported by JAM), OFP thinks that it HAS to get to whatever the scope distance is set to. So it's just that the initspeed needs adjusting.

    In JAM, the muzzle velocity (initspeed) for the 30 round 5.56 mag is

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=874;

    But the muzzle velocity for JAM's 30 round 5.56 SD mag is

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=350;

    Meanwhile, the muzzle velocity for Earl's non-suppressed M4 mag is the same as JAM's

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=874;

    while in Earl's M4 SD mag, this value is

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">initSpeed=744;

    You can use subsonic ammunition in the real M4, but the bolt has to be manually cycled for each shot. This is obviously not too acceptable for the role of an assault carbine, so most of the time the suppressed M4/M16s use supersonic bullets. The supersonic "crack" of the bullet is still there, but the shooter's firing position is not revealed.

    I think all you would need to do to fix it is change the init speed in most of JAM's suppressed magazines to the value in earl's suppressed mag (744). The other stuff like the range at which the shot can be heard and volume of the shot should probably be tweaked so that the change from subsonic to supersonic is apparent.

    The cool thing is that with the changes cornhelium has already made to JAM (sounds coming from bullets in flight) it actually comes pretty close to simulating the supersonic crack of the bullet's flight. smile_o.gif

  4. Posted

    only thing i think that needs changing is the rifle ammo sd versions since no one can shoot with it, it's too realistic

    increase its init speed to 800 or something

    It's actually unrealistic, since most of the suppressed weapons which have magazines defined in JAM don't use subsonic ammunition, but supersonic. M16s, M4s, MP5s would not use subsonic munitions, and if they did, they would not be zeroed for 400 meters, as JAM's ammo is. The only assault rifle I can think of operationally using subsonic ammo would be the 7.62x39 for the AKM with PBS-1 suppressor, but even then those who operated that sort of weapon would not zero it for 400 meters.

    Like I mentioned previously, I think taking a look at the way the Digital Grenade team coded the suppressed M4s in the Marine Assault Pack would be a good reference on how to config the suppressed magazines in JAM.

    Hope everyone is doing well. smile_o.gif

  5. Posted

    Great work, Laser! Can't wait to try them out! biggrin_o.gif

    Have you considered adding some models with the EOTech Holosight to your US weapons pack? I think it might really fit the theme and round out the pack of M4s, and possibly M14s. biggrin_o.gif

    And if not, I will still enjoy using them!

    Again, great work!

  7. Posted

    So in regards to some of the functions you stated, please keep us informed on your tests against live AI. I'm curious to see how it will be implemented so that the AI will actually be suppressed by the fire, such as hitting the dirt and keeping down. It shouldn't prohibit the AI from firing completely, but maybe to set a random number of the AI in the area on "Hold Fire" while the rest are set to "Stay Down" and return fire. This would simulate a few grunts too afraid to fire, while others are not. It would also prohibit this script from being used like a cheat, in that the AI will still pose a threat if you are not careful.

    Well, I am working on such a feature! smile_o.gif Hopefully with the changes I make it will make suppressive/covering fire an effective tool for the player (or enabled AI squads).

    Quote[/b] ]Also, how likely are "friendly-fire" incidents? For example, FT 1 on the left opens fire while FT 2 on the right moves out. AI don't exactly move in a straight line to their ordered positions, and it's possible that at times the AI from FT 2 might cross the line of fire of FT 1. Will the soldiers from FT 2 try and steer clear of the lead, or will FT 1 chew them up for their "careless" movements? I have a feeling that they will in fact get mowed down, so is there a way to ensure soldiers will not cross paths of the soldiers laying fire? I know the chances of this are not as likely, due to a squad in line formation is usually spread out enough to have fairly wide sectors of fire. But just in case, since the AI likes to move like a bunch of retarded gimps at times.

    Well, OFP's AI can take care of a lot of those type of things up close. In the editor, try setting up a battle between two squads, and then run back and forth right in front of your squad's firing line. You'll notice that as you pass each one, they stop firing and wait for you to pass. At further distances however the AI is less thoughtful, because by the time you are actually "inside" their direct firing line -- and they stop firing -- the previous rounds are already on the way. Obviously they cannot recall these rounds. biggrin_o.gif

    As an illustration to my answer, an example: I was testing out the script by trying to assault a base with a heavy MG team. I had one fireteam of the 2nd fireteam leader, a heavy machine gunner, and an assistant machine gunner laying waste to one entrance to the base by telling them to target the entrance on that side of the perimeter wall. The second MG team and myself flanked a bit off to their left, and I set my machine gunners target as one of the wall sections, but kept him on hold fire. I took down that section with an AT-4 and let him go. As I ran into the opening with the assistant machine gunner, I told my machine gunner to hold it and fall in. As I was clearing the base, I rounded a house corner and then *KERPHAT!* I bit it. As the camera zoomed to my killer...it was none other than the other machine gun team, who I had forgot was firing into the base!

    Just a small example to show that yes, it is quite effective (even against friendlies biggrin_o.gif)

  8. Posted

    From what I understand, you can order the AI to fire on specific objects, including buildings, trees, rocks, etc. As long as it has an ID # in the editor, then it can be targeted within a script. But for windows, I would think that you need to pre-place a target object at the window's location first. So yes, the map-click method would not work for firing at windows, unless the windows were marked with invisible targets and in the script it called to detect the nearest "window" target from the map-click and fire on that. I think it would be possible, but only with a lot of advanced mission setup and target marker placement, as well as a custom script for that specific mission.

    Yes, that is correct. To put targets in windows you would have to pre-place them in the mission editor. The only way to do it dynamically would be to catalog every window or door position of every building in OFP. Then you would have to find the nearest building, find out which building it is, then figure out which pre-configured window you want to use. Obviously that would be a lot of tedius work for not much benefit.

    Quote[/b] ]One thing I am curious about, which brings up a question for the scripters reading this topic. How difficult would it be to implement a script that allows you to choose the soldiers from your squad that will provide covering fire, and who will not? An example is the fast-rope scripts used in the BAS helicopters. When you call for a fast-rope insertion, you must first select the soldiers from your squad that you want to rope out, and then you click on the map where you want them to rope at. How hard would it be to add this type of function to the covering fire script, so that you can choose which soldiers will provide the covering fire? This way, you can order half of your team to stay and shoot, while the other half leap-frog ahead to their next position. It would also allow you to choose only specific team members to fire based on their assigned weapons, or to provide an amount of fire based on need. For example, if there are only a few enemy soldiers you need to suppress, no need in having all 11 men opening up on them, why not just order say your MG or AR soldiers and one or two riflemen to fire, while the others are ordered to flank, advance, retreat, etc.

    I have already done this. biggrin_o.gif In the current test version of my script, you select the soldiers you want to lay down fire, and click on the map. The invisible target is spawned and the guys begin to spray the whole place! When I was testing it out, I had one fireteam stop and lay down fire while myself and the other fireteam flanked around. Then I'd make the second fireteam stop and target the same area, and advance the first fireteam past our position. Worked great and was great fun! Even without enemies to shoot at! biggrin_o.gif

    I am also working on other functions. I should have a beta version for everyone to try out soon.

  9. Posted

    another non-update smile_o.gif My old computer is in the shop getting fixed (hopefully) and I've been getting used to my new computer. One major problem I have is that my ofp now has the alt-tab bug, so I have to find a solution to that.

    I've had that alt-tab problem before. Try messing with your resolution in OFP. Make sure it is not the same as your desktop. This fixed a similar problem with my system.

  10. Posted

    Awesome pack! I love it! biggrin_o.gif

    Would it be possible to make the model for these soldiers work similarly to the Generic OPFOR pack? Using hidden selections and setobjecttexture to randomly clothe them? That's the only thing I can think of that would make this pack any better!

    Again, awesome work, Munk, WheresMyRabbit, and of course JJR!

  14. Posted

    Hope all is going well with everyone.

    I have some additional thoughts apart from what I already mentioned about grenade vests...These are just suggestions, but I think they would really enhance JAM as a whole. biggrin_o.gif

    With the current JAM code, 200 rounds of 7.62 links take up the same amount of inventory space as the same amount of 5.56. This is obviously not representative of reality, as in real life, 7.62 rounds weigh much more than 5.56, meaning you can carry less of them. Currently you can load up an M240 or FN MAG machine gunner with 1,000 7.62x51mm rounds!! wow_o.gif I think that in the future, the space ammunition takes should be taken into account for realism. Perhaps it would be better to have a system like so:

    50 round 7.62 belt - 1 space

    100 round 7.62 belt - 2 spaces

    200 round 7.62 belt - 4 spaces

    with 200 round 5.56 belts still taking 2 spaces

    The second issue I'd like to suggest fixing is the problem with the suppressed magazines. They seem to have too low of a velocity for many weapons, especially 5.56mm, as most of the common 5.56 weapons cannot use subsonic rounds without manually cycling the bolt (which means they are not used). This causes quite an arced and unpredictable trajectory anywhere below 400 meters with JAM. Maybe it would be best if the suppressed rounds in JAM were similar in config values (trajectory, sound config) to Earl's M4 mags, as those are one of the most well done examples of suppressed weapons in OFP, in my humble opinion.

  15. Posted

    Frostbite: Thanks. smile_o.gif

    How did I do it? The answer is simple. I used a time machine. biggrin_o.gif

    Seriously, though, what I did was I set up a Game Logic as the base position for the camera (so it wouldn't change). I took the the scene with Suchey's Marine first. Once I took the first picture, I went into the editor and switched the unit to the WW2 USMC unit, then took second nearly identical picture.

    In PSP, I just used a mask, removing the water from the Modern picture so that the reflection from the WW2 one (which was a layer below) could be seen.

    I'm glad someone liked it. smile_o.gif

  17. Posted

    Awesome initiative, I can't wait! biggrin_o.gif

    As far as suggestions for new ammo types, etc., all I want is a couple more types of grenade vests. I really like the 24 round vests we have now, but one drawback is that it takes up 5 whole ammo slots, only leaving room for 5 magazines for the ballistic component of the weapon. Would it be possible to have a larger variety, with different number of rounds, and corresponding slot space?

    For example, perhaps something like this for the M203:

    24 round vest - 5 spaces

    12 round vest - 3 spaces

    and of course the single round taking up 1 space

    What do ya'll think?

  18. Posted

    Quote[/b] ]If i want to execute some script from within an activation field of some trigger (condition = Player In thisList), and i want the script to be executed ONLY by the client machine whose Player is In the trigger list, would the following work if i put it into the executed script?

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? not Player In myTriggerList : Exit

    VARIABLE = PLAYER_IDX

    It should, although you may want to add a parenthesis or two to that condition (simply for protocol's sake) Like so:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? not (Player In myTriggerList) : Exit

    Quote[/b] ](PLAYER_IDX is initialized in script running only on player machine // which is ensured with the help of similar line of code like above // executed from within init field of each Playable unit on map - and each of these units passes a unique number to this script => eg. to PLAYER_IDX)

    The problem is, when Player1 enters the area defined by the trigger, it sets VARIABLE to 1

    ..but when Player2 enters this area, the VARIABLE belonging to Player1 is set to 2, and so on.

    I'm not sure what you're trying to do. Could you explain it for me? If you're trying to make a list of player units, and give them variable IDs, I think an array would serve you better for your global variable. After declaring the global variable VARIABLE as an array, by writing "VARIABLE = []" without quotes somewhere early (like init.sqs), your above code might look like this:

    <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">? not Player In myTriggerList : Exit

    VARIABLE = VARIABLE + [PLAYER_IDX]

    I think you might want to check out the Chain of Command's Network Services script suite, which can be found here.

    Also, you can find documents and other neat scripts at this link.

    Quote[/b] ](i'm starting to see triggers not only in my dreams, but also on the street and in my house - and those are especially weird because they are allways upside down, placed on the ceiling. I'm afraid to move right now, because one of them is hanging right above my head, pleeeease help me)

    You are suffering from a mild case of scriptotitis. If you begin to speak in script code to your family members and friends, please seek a doctor. biggrin_o.gif

  19. Posted

    I am definitely not a source of knowledge on all that is scripting, but I think I may have some hints to the solutions for some of your questions.

    Quote[/b] ]1. When i make trigger and put // VARIABLE=true // into it's activation field, what happens?

    a.) will the VARIABLE become known to the server?

    b.) and what about all the client machines? will they know?

    c.) and will there be difference between dedicated/nondedicated server?

    (i am not asking about how to use PublicVariable function, i am asking about how OFP triggers works in MP)

    Not quite sure about this one. Someone more knowledgeable than I might know. But I think it would be the same as writing VARIABLE = true in a script that executed on all clients (including the server).

    Quote[/b] ]2. When i use // P = Player //:

    a.) to what will be the P reffering to on dedicated server?

    b.) to what will be the P reffering to on nondedicated server?

    As far as I know, on a non-dedicated server, player will refer to the host's player unit. On a dedicated server, I don't think player will refer to anything on the host computer (may be wrong on this). On all the clients, player will refer to the local client's player unit. The player variable will be different for each client (corresponding to their own local player units).

    Quote[/b] ]3. When i execute some script from activation field in trigger, will the script be executed on all of the clients, or only on server machine (dedicated or not)?

    (i know i can use the trick with 'Server' logic to ensure the script is running on server/client - that's not the answer to my question)

    Triggers are global or executed on each client, I believe. Game logics are only local to the server. So if you put a line of code into the init field of a game logic, that code will only execute on the server, as far as I know. (although I think it may have a global effect; for instance, CreateVehicle. I may be wrong on that one.)

    Quote[/b] ]You may think i am stupid - feel free to do so - but please, answer my questions :-)

    I would say those are some pretty tough questions. biggrin_o.gif I'm sorry if I misunderstood any of them and gave a misleading answer.

  20. Posted

    Oh...one other question...Why does it have a tail hook?

    I definitely could be wrong...but, I dont think they land on carriers that I am aware of.

    Some USAF aircraft (especially fighters) have tailhooks in case of emergencies. They aren't used on naval aircraft carriers, rather they are used on a regular old runway, except that there are arresting wires laid across the runway.

    Great work, Footmunch! smile_o.gif

  22. Posted

    Awesome to hear about this! Thanks to Avon, Cornhelium, BAS, and everyone else involved!

    I have one question:

    Would it be possible for the final JAM3 to not use the current sound folder system, but rather the .pbo? I understand the purpose of it (flexibility), but I fear the use for those who would cheat with it. (ie. replace a silenced round's sound with a very loud one, etc.)

    I think to offer the sound flexibility, you could just do as you did with this thread (offer multiple sound .pbos, etc)

    Thanks for everything! biggrin_o.gif

  24. Posted

    If you're just looking for inaccurate AI without any addons needed, Zayfod made a really nice script called "random firing" back in the day. I can't find the post on the OFPEC forums (might have been too far back). The script basically would randomly change the AI's direction while firing, creating a "spray" effect.

    If you can't find it, maybe I can put it up for download.

  25. Posted

    Okay. You might want to just test it and try removing the fuel a few meters before the crash, just to see if that helps. I remember having a similar problem with my own tailrotor failure script, and removing the fuel completely just before touchdown reduced or removed the problem, if I recall correctly.

    Again, really looking forward to your work! smile_o.gif

×