General Coding Discussion


New member
Intro section added on 22nd Dec 2007:

This is the general coding topic. Below is a list of features we need to code for Alpha 1 and their progress.

List of features:

- Energy system, including HUD readouts and battery packs Done by Heoga suggested by Heoga
- Servomech remote controls Done by Heoga suggested by Jupix
- Shields Done by Heoga suggested by Heoga
- Player character damage model (how does it differ from Source? - mainly to do with implementation of shields) Done by Heoga suggested by Heoga
- I/O system for level-wide security alarms (this could include a prop type for the red rotating alarm lights, so that when alarm state is enabled all the lights + alarm soundscape go off automatically without need for I/O connections in Hammer) Completed by Heoga suggested by Heoga
- Security cameras Claimed by Heoga suggested by Heoga
- Spider bombs Unclaimed suggested by Jupix
- Spider mines (obviously this is basically just a combine hopper mine that doesn't hop) Unclaimed suggested by Jupix
[ this list is incomplete, please post missing features if you come up with any ]
- LMC Guards Should be a modification of the Metrocops with a new models and slightly modified AI Unclaimed suggested by Heoga
- Computer Terminals Unclaimed suggested by Heoga


Original first post:

Okay, a heads up on what's happening here and what I've managed to do so far.

Changed HUD colours from orange to red.
Implemented the coding for the three types of batteries and the energy cells.
Figured how to make weapons drain suit armor instead of using ammunition and implemented this with the shotgun as a test rig.  Code can now easily be applied to energy weapons when we get them ready.

Things to do over the next few weeks:

Add the various shield generators and modify how the character takes damage to match the original
Implement some (realatively) basic entities such as the cameras and alarm systems

Anything else you think I should be concentrating on?
Re: Coding

Remote operating of the mechs comes to mind first. We've got to look into how that feature should be implemented.

By the way, you can leave the HUD to me. It's mostly simple VGUI stuff so I believe I'm going to be able to do it. :)
Re: Coding

Yea, I haven't messed with the hud itself, just changed the colour.

As for the mechs it won't be that much of a problem to attach a camera to them and copy the crane control method for movement and firing.  The image from the camera could then be flashed up on a panel at the top of the screen.  I was thinking the same method would be used for controlling spider bombs as well.
Re: Coding

ohh guys you have some nice progress there. I need to get back to modeling. I'm getting better here so should find more time to model stuff.
Re: Coding

Okay guys, I've built the base servomech class.

How it works is this:

When building the map, a point camera named "Mech_Cam" is placed somewhere in the map.  When a Mech is activated from a switch, it freezes the players movement controls and disables their weapon.  It then attaches "Mech_Cam" to the eyes of the Mech.

The Mech can then be controlled:
Player ControlMech Control
Strafe LeftTurn Left
Strafe RightTurn Right
Move ForwardPitch Aim Up
Move BackwardPitch Aim Down
JumpRelease Control
Primary AttackPrimary Attack
Secondary AttackWalk Forwards

Whilst the player is controlling the mech, they're mouse control is still enabled and so they can continue to look around them for possible threats, releasing control when an enemy arrives.

This is all programmed in such a way that before control is activated, a Mech will work under it's existing AI functions and then return to it's AI on release,  i.e. if you took control of a Mech that was attacking you then released it again, the mech would resume it's attack.

The next hurdle is how to display the Mech View.  At the minute I have a large monitor on to which the camera projects it's image.

A HUD Element that becomes visible on command and displays the camera screen.
Displaying the data on Monitor screens ingame.
Taking control of, and replacing, the player's view entirely.

My preference is for the first option, this will however require a few extra code changes as default HL2 can only display one camera view at a time.  I plan to create a series of textures which cameras can target so that we can display multiple monitor views in a level.  One of these will be dedicated to the "Mech_Cam" view.  The rest can be used on security monitors.
Re: Coding

Jesus, dude. Someone should give you some money for that... Can't wait to see the code in action.

If I may pull some authority here, let's go with the third mech view option. That's how I envisioned it from the start. (View mode changes when player uses the security console and is changed back by pressing Esc).

My vision had quite a different set of controls for the mechs (identical to player controls) but yours don't sound too shabby, either.

Edit: As for how to implement the camera, have you already thought of utilizing the same method Valve used for, for example, the Combine mounted binoculars? (Near New Little Odessa, if I remember correctly.) It seems to me like the logical place to start, it would probably be the easiest method.
Re: Coding

The use of the arrow keys for aiming isn't the best admittedly, but it's functional until I suss out to steal and pass along the mouse controls.  It can always be rewritten later.

I'll take a look at the third option later on then, I have a feeling it might cause some difficulties with PVS systems so I'll leave the camera option in as a backup whilst I work on it. 

I think the code for the binoculars was a point_viewcontrol (same as the intro Gman sequence and the menu background levels) and your right - it's exactly what I'll need to steal to make the viewpoint for the player control.

I'll see if I can get the code wrapped up nicely and send you the .cpp and .h files later in the week.  It just plugs into the HL2 Singleplayer SDK Project and needs a few lines added to the FGD before it's good to go.

As for the money, if we can get this mod to work - that'll be reward enough.

Oh yea, level design issue:  the player doesn't actually have a model so is invisible to the mechs at the moment.  Might see if I can do something about that later on.
Re: Coding

Righto, working on the code a little more before I distribute it.  Will try get it done before xmas.

The arrow keys are too clumsy for aiming I've decided.  Because of that I'm working on a mouse system.  Although, i'm planning to make it differ from a standard FPS in that the mouse only controls aiming, not looking.  If it works, it should mimic what is seen on the Vetron view at the start of No Remorse.
Re: Coding

Nice, like turret rotation. In order to rotate the body, use arrows. Aim Mouse where the cooursor runs all over the screen, nice idea!
Re: Coding

It worries me that if we're going to use WASD for moving about, it will strike players as odd if A and D are not for strafing but turning.
Re: Coding

I think its a good diversion between crusader and mech feeling.
You don't play the mech all the time and without strafing it makes it a little challange to use the powerful vehicle.  So it hasn't only advantages and isn't too simple.
Re: Coding

Jupix link said:
It worries me that if we're going to use WASD for moving about, it will strike players as odd if A and D are not for strafing but turning.

I wouldn't worry about that too much.
Re: Coding

I also do not think that it should be a trouble. Controls like that are very popular in MechWarrior games and they are perfect actualy. Man, I wish there was another MechWarrior developed by the same guys who made MW2 and MW2:Mercenaries. Those were two best games ever!
Re: Coding

Playtest time!

The files in this zip are the code needed for:

Mech Control
Fusion, Fission and Chemical Batteries

Use the FGD code to add the Mech to hammer.
Add a point_camera entity named Mech_Cam to the map.
Copy the binaries (or compile using the codes)
In game, fire the ControlActivate input to start controlling the mech.

Currently there is one bug which requires work.  If the mech wanders out of the player's PVS then the view will change to an abstract view somewhere on the map.  In order to solve this I'm going to have to delve into the PVS scripts, but that's a job for after the holidays.

At least with this you can get a feel for the mech workings and give some feedback on the system.
Re: Coding

First off, thanks for the release... Looking at the code now I realise what an enormous task you've done here, so you truly deserve everyone's gratitude. Great job.

I just diff'd and merged your codechanges but something's not clicking. When I pull my ControlActivate trigger in game, I get

> Attempted to create unknown entity type npc_thermatron!
> Can't init npc_thermatron

in the console. Any idea why the game doesn't recognize the npc type? It's probably something obvious but I'm not seeing it. Where are all the npc types defined?
Re: Coding

Hey Jupix,

I'm away from my computer for the next two weeks, so support is limited for now.

I came across that error myself before and discovered it was due to a typo in the FGD file.  The name type of entity in the FGD must match the name in the LINK_ENTITY_TO_CLASS line of the npc_thermatron.cpp file.

LINK_ENTITY_TO_CLASS( npc_thermatron, CNPC_Thermatron );
@NPCClass base(BaseNPC) studio("models/breen.mdl") = npc_thermatron : "Thermatron"

If that's not the problem, then test with the compiled binaries and see if they work.
If they do, then the most likely problem is that the npc_thermatron files haven't been added to the project.

Assuming your using microsoft visual studio
Click on the hl2_dll folder in the server.dll
Go to project->add existing item
add the files which aren't already in the project (thermatron, servomech and battery files)

Repeat the process for the cl_dll/crusader folder on the client.dll for the mech_targeting_hud file.

It should work then.

Let me know how you get on.