I am currently building UNSC weapons and I have completed the standard set. I have made the standard rocket launcher, but its not the greatest SAR (surface to air rocket). I was thinking of making this old one that bungie was going to out into halo 3:

http://halo.wikia.com/wiki/G4H-DuSH

I understand that homing missiles are possible, but what about this?
https://www.youtube.com/watch?v=A57zBWOTd7c

The Javelin from MW2. You see how the missile flies straight up, pauses, and then flies towards it's targets? I was thinking that maybe it could be an animated garbage or effect file, that spawns a homing missile projectile after it's finished it altitude animation. I don't understand how garbage files have physics (or maybe their animated?) so idk if that will work exactly.

Any ideas? Or do you think that this weapon is dumb and useless? lmao.

I think a weapon with that level of homing capability would be overpowered, or at least close to it.

As far as making it work, I suppose you could make it have great magnetism (making it OP and incredibly dangerous to any enemy)

I think Zteam's implementation of the Target Locator may be good for something like the Javelin.

Edited by Dumb AI on Mar 14, 2014 at 01:02 AM

Maybe a weapon that fires a projectile which has negative gravity effects, causing it to go straight up, then it creates an effect, which drops a second projectile straight towards the ground? It'd have limited range, but could be interesting.

Also, FYI the Javelin is primarily a Ground to Ground AT missile system, at least the one from MW2 is. The British also have a "Javelin" but it's a Surface to Air missle system that sits on a tripod.
Edited by olly12345 on Mar 14, 2014 at 05:53 AM

Will there be a script where the missiles can only home in on locked-on vehicles like in Halo 2/Reach/4?

from what I understand, you have to tell halo that this is a vehicle, and to only home in on it. So it has to be continuously be checking for a vehicle from which to home in on, is this a vehicle? yes/no? home or no home lmao. And I was thinking of having this only in single player, like to take down phantoms and other large aircraft.

I'm not sure if this is possible traditionally. I know you can fire straight down on a target where you click at though. Perhaps the firing upwards could be an animated scenery or something.

The realworld Javelin can take up to thirty seconds to establish a lock, and I believe it only has one shot. I'm not sure that it can be reloaded in the field. If he does something like that, then I don't think it'd be too overpowered.

The problem here is that it would be largely ignored due to it's single shot and 30 sec. lock-on time.

If it was recreated accurately (with those limitations), it would be rarely used by anyone.
Edited by Dumb AI on Mar 14, 2014 at 11:43 AM

The thirty second lock-on could be toned down a bit. I think it'd still see some use due to its fire-and-forget ability, and the power to knock out most any ground vehicle up to and including a Scorpion tank.

*related*
Anyone know if there is a simple way to have a homing projectile maintain it's focus on it's target? For example if a homing projectile in Halo overshoots it's locked target, it doesn't loop back around like in later games, but continues forward.

that's not the only thing wants to be done really badly
(inb4 beating vampire girl to it)

I don't see why you wouldnt

I talked about this somewhere before but having a way to make flares or decoys to use against homing missiles might be good too :P

Working on something atm, will post later with some progress.

Here's the thing though, either it will be buggy or not work at all in multiplayer, as the method I have in mind for the rocket uses AI targeting. Plus, the weapon's firing mechanic will require OS: (weapon_data_get_real <> heat).

Lost in HDD crash ;)

On the other hand I have no idea about how to make the missile home in after an activation time. The way cad's FRG works would work if the spawned projectile was still considered as fired by the player it would be easy to do
Edited by bourrin33 on Mar 15, 2014 at 01:31 PM

Alright, here's the rocket.



AI targeting... this was decided because we want the rocket to be able to:
1) Have any target be effectivly and accurately defined during gameplay, and not change
2) Track said target reliably, even loop around to try again
3) Of course, still explode on impact with target or any other surface


I went and made the rocket a vehicle to start:




Honestly, the largest portion of time spent here was experimenting with the physics. I've never really delved into the area, and the main issues I was facing was the obvious bounding problem that caused the rocket to spaz out, probably due to conflicting forces on the physics points, misplaced mass or a trolling tool. I settled on making a flat "bed" of points all equally spaced, with a few lining the center-top for balance, in addition to having the points produce as little friction as I could make the engine work. This allows, or more precisely, forces, the rocket's model to stay a certain distance from the ground without causing any issues with getting caught on the ground, or a wall or whatever.


This seems to be similar to how the snowspeeder in Rouge Squadron works when flying near the ground- hugging the ground without causing a crash.



Thinking about it now, the best physics shape may likely be a sphere of physics points around the rocket to allow perfect re-orientation should there be any close walls or objects it may side-swipe and not hit directly. Even a boat shape under the rocket may be more suitable, but whatever. How do you do it atlis?



Now, why is the rocket a vehicle? The rocket is made a vehicle so that we have more control over the way the "projectile" moves and turns as well as being able to change the direction it flies as it is flying. By using the 'alien fighter' vehicle type, the rocket is able to turn itself up, down, sideways... at any time during flight. Regarding locking onto targets, this requires the projectile to be actually fired from the weapon and make use of the weapon's aim assist and guided velocity. It's not that that's the problem, but there are conflicts with what I have planned for the weapon's firing mechanic.



I may end up using this system later to create something similar to a wire-guided projectile. The idea is to have the vehicle fly forward constantly while having the AI look directly its target- (ai_look_at_object pilot rocket_target). The AI look at command allows any named object to be the target, enemy or friend, biped vehicle or even scenery and other weapons. With the pilot of the rocket looking toward the player, the rocket vehicle will constantly try to orient itself so that it is facing the target.





Finally, by having the vehicle's maximum reverse speed set to a negative value, the vehicle is able to maintain a minimum speed that will keep it going even with no more input. Think of the Halo 3 Banshee and most jets in games.



I'll get some video eventually of the rocket tracking the player on foot as well as in a plane, as well as the weapon's firing mechanic later. Hopefully this leads to something good.
Edited by A Juicy Frank on Mar 15, 2014 at 10:00 PM

Video time:
http://youtu.be/pkHXfP753pU

Just a demo showing the rocket's tracking, being able to target the player on foot as well as in the banshee, and even the banshee itself. It is able to adjust mid-air, but will still detonate itself when impacting any surface. When testing the rocket, I had it teleported to a flag in the air facing away from the player to test its flight immediately after being moved and turn radius. This is somewhat related to how I'd have it fired by the player- when called into action by the script, the rocket will be teleported to the launcher's 3rd person model on the primary trigger marker while accelerating to the target.

If it needs to fly into the air first, ala Javelin, that could be done with either a recorded animation that the AI driver plays, or a custom animation on the vehicle itself. Recorded animations will take priority over the AI_look_at_object command for the duration of the recording, which I thought was weird while testing but it does offer some conveniences. And as the video shows, the rocket will be able to reorient itself toward its target after its flight upward.


Changes can be made to the turn radius of the rocket, speed of the rocket's travel, distance rocket can travel (creation .effect delay timer), explosive damage and radius, explosive force to bipeds, impact force to vehicles, detonation/other reaction to materials (overpenetration) as well bright blinking lights if that is what's wished.

Cool, now we know properly homing missiles are possible. That's great! I look forward to seeing what you do with this.

OMFG A Juicy Frank, that is AMAZING. I never would have though that making it into a vehicle would have worked so well, but I guess that it makes sense since the banshee can move like the missile while airbourne. But does it have to be launched via script? I know that's just how you did it to display it in the video, but is it necessary in the final product? I also think it's kickASS how you have a chance to destroy it before impact.

I know, I don't like creating too many dependencies on scripts either, but believe me that there's not too much going on in either the script nor the tagwork here.


Basically the script is designed to "set up" the rocket by placing it somewhere on the map with the pilot already inside, waiting for some form of input about when to put everything into action the instant it's called for (in the video it was a variable I manually changed, set test 1. For final it will be some check that the player's weapon was fired- most reliable method I've found is OS' weapon_data_get_real <> heat command, so expect a overheating charge weapon mechanic recommendation from me).
When the input is received, the pilot is told to fly its rigged vehicle into its target, which for final I expect to have determined during the whole time the weapon is charging (in the video I had the target set to my player most of the time, and manually set it to the banshee named "ss" for a time to demonstrate its ability to track any named object).



Bottom line is that for the rocket to know anything about when it's needed (player firing his rocket), where to deploy from (teleporting rocket to end of player's rocket barrel), and what to kill (what object the player was looking at), it needs to be told by a script. Yes, vehicle tags may be spawned by a weapon's projectile, but these vehicles aren't named at all, and can't be referenced without OS or told to do what is needed above.




Also, I'll have a link to the tags put somewhere eventually. They're not perfect by any means, as the rocket's physics tag needs obvious improvement- something beyond my understanding. I'm just not sure what else I can do for the rocket. Plus, I'd like to refrain from holding onto things until they are utter perfection for what I would assume would be the sole purpose of having my name slapped on it. It's happened before, and I'm back hoping to do better this time. I'll get xfire and all eventually.
Edited by A Juicy Frank on Mar 18, 2014 at 03:13 AM

That sounds great, and if you need any help just ask (can't say im amazing with code but model's and such yes). I could build the model for you if you want since I'd like to help however I can ;)

Is there any other way to 'ping' the target to get the tracking data? Like if you could aim at a target, 'declare' it as 'pinged' then tell the missile to look for 'pinged' targets? Then put it into a global, then get the global pinged targets name, and fire (Kirby came up with a script that recognized friend from foe to highlight your targeting reticle (red for enemies and green for friendlies which I believe could be helpful) . I'm thinking something like this:

start
wait for player trigger press
get player trigger press and hold
wait 10
get_name
put name below
target 'Phantom1'
wait for player button release
teleport missile to player trigger
attack 'phantom1'
wait 10 if not fired then reset 'target'

quote "aren't named at all"
does the missile itself have to be named? or just the target, because if it's only hunting vehicles then I believe that it would work fine.

I'm not a fan of continuous scripts, so activation from the players trigger makes more sense. I haven't used OS before but I figured that I would have to eventually, so I'd prefer standard Halo ce first, but it might be time to move onto bigger and better things.

Sorry about the wait, stuff came up throughout the week and didn't have many opportunities to continue with this. WALL WITH NO PICTURES INBOUND

Now when you say 'ping' a target, would that be the equivalent of placing a distinct green sticker on a single box to mark it as unique, then have us be able to identify the marked box easily from the others when we need to later? This is pretty much what is planned for the launcher mechanic, and I'll explain in detail down below how the launcher and scripts will get and process this information. If the intentions were to get this information without the use of or with as little use of scripts as possible... there may be a way to go about doing this, but in all honesty it will probably not be as reliable:

Since all the pilot is doing is flying a vehicle rigged to perform like a projectile forward into a specified object, this could potentially be done automatically by Halo's AI system instead of being forced by scripts. I believe somewhere in the AI's .actor or .actor_variant tags it is possible to have the pilot try to ram his vehicle into whatever enemy it is targeting based on certain conditions. I don't know what these conditions are, but if he can be made to only rely on ramming as his offensive option, then it could produce the similar results. The issues that are involved, however, are what if he sees another enemy? He may very possibly attack that that guy instead. That's faulty tracking. What if the target being designated is anything other than an enemy? The pilot just won't attempt to fly at it. That's a faulty rocket. What if the player using the launcher is seen by the pilot as an enemy and the pilot in turn targets the player? That's http://imgur.com/t4cJdwQ. I feel there are just to much unpredictability going on this way to pass up on a method that gives us the degree of certainty we need. Plus since both methods use scripts anyway, we might as well just make the most of it.



On to the launcher. As usual, explanation first, video sometime later (maybe). Again, the actual mechanics of the launcher can be made to better suit what the developer wants, for gameplay purposes, innovation, or whatever. The one below is just what I had in mind.

The launcher is designed to pretty much have infinite ammo, with the rounds generating heat when fired. This is done so the weapon can reliably be tracked when it starts 'locking on', as well as how long the trigger has been held. The weapon's projectile field is left blank so that nothing is created at all when the trigger is pulled, while still allowing heat to be generated in the weapon. Depending on what kind of visual input the developer wants, the firing effect field may also be left blank, or have a glowing light in addition to a shaking firing animation. This is to make it look like the weapon is charging, even though in reality the gun is only firing blanks ;_; in order to generate the heat that we can track by script. As soon as the weapon starts 'locking on'- (> (weapon_data_get_real <launcher_name> heat) 0)- weapon's heat is greater than 0, the game runs a seperate static script used to determine what the player is looking at.

Now, HOW the static script goes about determining what the player is looking at can be up for debate. Because there is no (what_object_is_the_player_looking_at) command that actually RETURNS the object nearest the player's center screen, the next best thing is the (objects_can_see_object) command. This has a tendency to count objects behind walls as being seen by the player, however, as well as not being enough to discern what object the player is focusing on should there be more than 1 object in the player's line of sight. As buggy as it is, you do what you gotta do. We will run a seperate (if (objects_can_see_object (p0) <potential target> 10) (set rocket_target <potential target>)) for EACH AND EVERY potential target the player may be expected to lock on to. So the script checks if the player is looking at banshee #3, as well as warthog #5 and phantom #2. Yes, because the commands are done in order, it will ultimately end up targeting the last object that returns a true condition. This is obviously an issue, but without delving in more, I'm just going to leave it at there's not much more that can be done. Oh, and for visual reference, we'll place a single nav point on the target. This way the player knows what the game considers his target, and may act accordingly; If it is not the target he intended, he may look away- breaking the lock or let go of the trigger- dispersing the weapon's heat and resetting the script's actions.

With the static script having been run, the global variable 'rocket_target' now references what the target is, and now doubles as a constant that can be compared every time the continuous script is run. What I mean is that as long as the trigger is held down:
0 < (weapon_data_get_real <> heat) = heat is increasing = launcher's trigger is still held = the script is still running and is able to compare the rocket_target variable to what the player is CURRENTLY looking at. The first time around, the static script had SET the variable to the object, because the target before was set to 'NONE'. Now that there is a target other than 'NONE', the static script now runs the (if (objects_can_see_object (p0) rocket_target 10) command to see if this player is still looking within 10... degree units of the determined target . If it returns true, that means the player is still effectively tracking the target while the launcher's trigger is held. This will continue on until the script that checks the weapon's heat notes that it is past a certain value- held long enough, and will go through with a successful rocket launch. This process includes forcing the weapon's heat to be changed to 1, inducing the overheated animation. The desired first-person firing animation should be used here. If an ammo system is wanted, the weapon may have an age system that is increased by the script after each successful launch- limiting the amount of shots that the launcher has. The weapon's rate of fire will be reduced to 0.1 for a time, in order to prevent the weapon from starting up again immediately, and the rocket vehicle is moved to the weapon's model in the player's hands, where the whole firing system takes over. After some time, the launcher's heat is set back to 0 and has its ROF set back to 30, ready to be used again.

Now if at any point the static script finds that the rocket_target is not within 10 degrees of the player's center screen or that the trigger is not held down any more, an action is taken that reduces the weapon's rate of fire upper and lower bounds to 0.1- preventing it from firing any more and gaining heat, as well as manually reducing the weapon's accumulated heat to 0. The rocket_target variable is changed to 'NONE' again, and the nav point is removed from the object. After these resets are made, the script sleeps for 15~60 ticks or so- 0.5~2 seconds, then the weapon's ROF is changed back to a usable state- allowing the launcher to find new targets.
Edited by A Juicy Frank on Mar 21, 2014 at 12:12 AM

Isn't there anything like in multiplayer, where 'player1' shot 'player2' commands that are usable? If we, kind of like you said about leaving the projectile and trigger entries empty, make a projectile that does little or no damage, but pings the target as a target (like when they take damage, the game knows that this enemy is taking damage and displays them getting hurt, just an idea idk if possible). There must be something that can be used to

(activate_nav_point_object <navpoint> <unit> <object> <real>) right?
and about the nav point. If there's a script that puts a nav point on the target, then can't there be a way to tell the missile to track the nav point?and maybe look at it while it's homing in?.

I was originally thinking that one shot (one shot per phantom) would be better suited for this hand held death star, but it might be worth trying it with 3 weaker shots. I'm looking at the plasma pistol .weapon file right now and I can't seem to understand how it's charged shot works (the battlerifle i can understand), but how can you give it ammo if the scripts tracking it's heat? The charged plasma shot uses 11 points of ammo and can fire 10 charged shots, with the last one using 0 energy? I don't get it.

I think that everything is brilliant, especially the use of the nav point and the whole way how the heat method has a double use, for the live tracking use and even to tell it what the player is looking at. It's completely grade A genius material!

I'm going to start modeling and animating the weapon now and I could send it to you if you'd want to put the whole thing together (which I could do instead if you desire). I'd like to upload this so the community could use it if that'd be okay with you (you could upload it yourself if you'd like). I might try to get someone to texture it though, since my texturing style won't fit into any other maps that aren't mine (lmfao...).

Would it be better to have the player know when its locked on with something on the HUD or the weapon itself? The real Javelin scope has 4 white corners that move towards the center point of the screen as they lock on, i believe that might actually be possible to do in the hud so I'll do some research. I'm drawing some concepts for it now and I'll upload them when their done.


https://www.facebook.com/photo.php?fbid=764308670247631&set=a.758105760867922.1073741825.746518345359997&type=3&theater

The left hand doesn't seem to have any spot on the weapon to sit, so I might add a handle for it. This weapon could be reload-able since the front end is rather close to the players face (WAY closer than the rocket launcher). The front will have a light that will turn red (like the real thing) when it locks too. And the front of the missile and top circular piece on the launcher will be like this:

This is going to be fun!

What do you guys think we should name this badboy? I'm thinking Halberd since it's similar to the javelin, they are both names of close combat weapons.
Edited by Hell_Jumper_056 on Mar 21, 2014 at 06:07 AM

Mhm a little question : how do you think it would be reloaded ? In the concept I started, I had those things that links top and bottom on the side inverted, and the inner squarish part was sliding in the back to allow the operator to put a new missile.

But I ended up wanting to make it as a mortar as you can't do something very good in multiplayer, and it was a better idea in terms of multiplayer gameplay.

That does sound like a good idea to have the inner box piece move back, but I was thinking that just sliding the missile in through the front like the real Javelin would work fine since the barrel edge is close to the player:


https://www.facebook.com/photo.php?fbid=764533993558432&set=a.758105760867922.1073741825.746518345359997&type=3&theater

the missile is only as long as the larger barrel inside the boxes and will stop at the black strip beside the 'H'. The whole G4H-DuSH part of the shorter barrel will be empty.

I might move the shoulder mount closer to the handle.
Edited by Hell_Jumper_056 on Mar 21, 2014 at 02:57 PM

In regards to the reload, you could either drop another missile in through the back, or you could make it so that the entire rear half of the launcher (the gray cylinder that says "G4H-DuSH" in the concept) is replaced when reloading.

That sounds kick ass to me. I'll still work on mine, but make it into a lower poly version. I am rather good at tagging and shaders too. I would like to try the HUD and fp arms if thats ok (I have kinect that I'd like to animate with too). Will you add the G4H-DuSH directly to the texture? I personally add things like the G4H-DuSH and a UNSC symbol as a decal shader on top of the model, so do what ever you think would work best. I already have some ideas for the fire and flare effects.

That does sound like a good idea Echo77, because if you look closely , the black strip beside the 'H' is attached to the black base below it and the barrel. While farther back, inbetween the 'h-' and the 'd' there is a black clamp looking piece that is not attached to the barrel, which is kind of weird...
Edited by Hell_Jumper_056 on Mar 21, 2014 at 03:17 PM

Something a bit like the BF3 SMAW reload?
http://youtu.be/1IZofquAxsY?t=27s

There was just something about it that made it more appealing to use than the RPG


Also, working on the scripts. -------------------------------------------------------->
----------------------------------------------------------------------------------------->


Will be going out for a birthday dinner sometime tonight. I'll bring you all something.

That reload looks perfect! and is the little screen improv really necessary Mootjuh? If the lock on part will be displayed on the hud, then I don't think that we'll need the left display (up to you, I haven't seen a method of a shader displaying what the player is looking at for halo 1 yet, so idk exactly what I'd put there (I will look into this too)) and I personally wasn't going to add it on mine, because it's a big weapon taking up a bit of the screen, so idk, maybe if it was small.

So would you guys still want me to animate it like the javelin, where it flies upwards, pauses and then files to its target? or not? I think that it might need to be animated to the vehicle itself, or be made as a separate piece. idk yet

and what hud and fp arms should be used? I was thinking of blending this weapon with the standard halo 1 hud and weapons.
Edited by Hell_Jumper_056 on Mar 21, 2014 at 04:36 PM

Thats what I was thinking too. Since all the marines in halo have some sort of helmet interface, I figured that the weapon would just link to that instead of an actual display.

It depends on whether you want it to be an anti-armor weapon or an anti-aircraft weapon, I suppose.

To have the rocket do the Javelin's upward flight, make a recorded animation of yourself flying a banshee straight up into the sky. This recording will be played on the rocket at the same time it is moved to the player, making it fly upward.

When the recording is cut after however long we decide it should be flying up, control will be given back to the pilot of the rocket and fly it into the target.





Our theme song: http://youtu.be/xMaHEnVPd48

@Frank: I don't think the missile should fly straight up. More of a steep incline, methinks.

That does make sense Echo. I'll probably record two animations to see which one fits better.

You could probably make it be a projectile with negative gravity, then have it detonate and drop another projectile with homing on it, that could be a good start.