Tremor game dll change history Beta J 12/08/99 Re-arranged a few things. Beta copies of release maps are now in pak0.pak. Example maps are in pak4.pak. func_trainbutton. Yep, a button that's attached to a func_train and moves with it. Specify the func_train with the "movewith" key. NOTE: Currently this button does NOT move relative to the train - it doesn't punch, in other words. Initial stab at this was just all screwed up. This MAY be amended in future releases (I doubt it), but just to play it safe you should still specify angle, speed, and lip values (which will currently be ignored). Thanks to new guy "the gimp" for the suggestion. trigger_mass fires its targets if touched by any entity with mass greater than or equal to the mass value of the trigger. Lots of possible uses here - see trigmass.bsp for one. trigger_inside fires its targets only if the bounding box of the entity specified by the pathtarget value is completely inside the trigger field. This might be useful for requiring the player to move a key thingamajig (as in a func_pushable) to a specific spot. trigger_scales is teamed with target_character(s) to display the weight of the entity or entities touching the trigger, including stacked entities. The weight value displayed is proportional to the fraction of the bounding box area that is contained by the trigger field. While not especially useful, this is a nice effect in a warehouse-type environment. See hyde2.bsp. Changed health display on the HUD. Monsto apparently has something against numbers :-) Sorry, had to do that. Beta I 11/30/99 The +action key is no more... all actions previously accomplished with +action are now accomplished with +attack. Lock changes - lots of 'em. See lock3.bsp. The addition of this stuff makes it feasible to use multiple target_locks only under very limited circumstances. 1) Added "HUD" spawnflag (=2) for target_lock. If set, the known combination digits are displayed on the HUD. Unknown digits are displayed as "?". Digits are revealed either with a target_lock_code (all of 'em) or target_lock_clue. 2) Combination may have from 1 to 8 digits. 3) If the player attempts to use the target_lock w/o the correct combination set, the target_lock's "pathtarget" is triggered if this value is used. If NOT used, talk1.wav is played and the target_lock message is displayed, if present. 4) Target_lock_clue reveals 1 or more digits of the combination. Which digits are revealed is controlled with the message key. A "?" indicates that the corresponding digit is NOT revealed. For example, "X??X" in the message field will reveal the 1st and 4th digits of a 4 digit combination. Target_lock_clue can be used in several ways - if the "team" key is used along with a collection of target_characters with the same team name, then the target_character digits continuously spin until they are locked in, at which time they will show the correct digit. It is *not* mandatory to use the team key and target_characters, though... triggering a target_lock_clue will also set the corresponding digits in the HUD display (if the HUD spawnflag is set). You *can* place target_characters for the target_lock_clue in different areas of the map... just make sure to use the correct "count" and "team" keys. NOTE: If the HUD spawnflag OR a target_lock_clue is used, there should only be one target_lock per unit if a crosslevel lock is used. If a crosslevel lock is NOT used, you should only have one target_lock per map if either the HUD spawnflag or a target_lock_clue is used. Floating func_pushables. Changed flotation criteria for gameplay considerations. In this version, a 64x64x64 crate with mass > 500 will sink. This was done because 500 is the maximum mass that a player can push on land. Without this change, it might have been possible for the player to transport a 600 crate out of water and onto land, where he'd then not be able to do anything with it. If you use crates LARGER than 64x64x64 with mass > 500 that float, AND if those crates can possibly be moved out of the water, you'll need to include another method of transport - crane or (currently) nonexistant forklift. Target_text - similar to target_hint (which is now obsolete... don't use it). If the "file" spawnflag (=1) is set, the message key references an external file, which should be in the [gamedir]/text folder. If this spawnflag is NOT set, the message is the text to display. The drawback to using the message key is that the message length is limited to something like 128 characters. For external files, the game first looks in [gamedir]/pak0.pak for text/[message], then in [gamedir]/text/[message]. For external files the message can be ANY length. Player scrolls the text with the invnext and invprev keys. You'll probably notice that scrolling the text is a bit sluggish... this is intentional. The display is part of the HUD, and as such is subject to the same bandwidth restrictions as everything else, even though we're talking single player only. The initial version I cranked out was very susceptible to SZ_GetSpace:Overflow errors before I crippled it. For the same reason, we can't use a bigger background screen to fit more characters (I tried :-( ). See hyde1.bsp (on Easy) or text.bsp for examples. Third-person view. One of you suggested automatically switching to a third- person perspective when pushing func_pushables. Actually two of you suggested this, but I killed the other one. So anyhow, here it is. There are two persistant cvars that control third-person view: tpp (default=0). If set, third- person view is on ALL the time, but changing this setting will not take effect until the game is restarted. tpp_auto (default=1). If set, view switches to third person when the player is pushing a func_pushable, and switches back (if tpp=0) when the player is no longer pushing anything. You can also toggle third- person view at any time with the "thirdperson" console command. You can change the distance from the "camera" to the fake player by pressing +use (bind a key if you don't have one) and moving forward or back. This setting is not persistant. There are at least two problems with third-person perspective: 1) It works reasonably well in open areas, but in tight spots really REALLY sucks. In tight spots the camera is prone to move into solid brushes... it usually corrects itself sooner or later, but the problem is definitely noticeable. You'll also notice that the crane cage drives the view nuts - hopping back and forth trying to find a good spot. There's really not a good way around either problem other than designing maps around it... for example the crane and forklift cages should be much larger. 2) The player model MUST have a weapon. In the game dll source, even if the gun index is set to none, the game exe decides it knows better and picks weapon.md2 in the players/[model] folder... which is usually the shotgun. We *can* use our own viewable weapon that's small and invisible, but then we'd also be forced to copy this weapon model to EVERY player model folder on the user's system. And anyhow... the player model's arms are positioned for holding a weapon, and looks pretty goofy without one. In case you haven't figured it out, I'm not a huge fan of third-person perspective :-) Fixed problem with visible model used for the crane spotlight. Now uses an invisible sprite. On a related note... added an alternative flashlight for you to check out. It's voting time :-). Use "alt_flashlight" to check it out. One weird thing you may notice if you're in a map that uses different texture scales (crane.bsp, for example)... the spot uses the same scale as the textures it touches - very weird. So - if you're building a map in which you might want to turn out the lights or a map with large dark areas, try to use scale=1 for all large brush faces. Added target_lightswitch - turns lights off. You can (temporarily) test the effect with the "lightswitch" console command. The minimum light level ("a" by default) can be changed with the lightsmin cvar. Lights off does not work well at all in outdoor areas - sky brushes will retain the same look, though they won't give off light. Also, transparent textures will retain their initial lighting. Nothing we can do about this one. Added Rogue IR goggles. (These may not make the cut... if we want to keep them we'll need to make our own model because we can't count on users having the Rogue MP, and the model isn't ours to distribute. If nobody is interested in using them that's a pointless effort. Let me know what you think). IR goggles give the player's view a red tint, and all entities a bright red glow. To test, go to the console and type "give ir goggles;use ir goggles". ========================================================================= Beta H Nov 24, 99 Finalized (until you bitch about it :-)) target_fog and trigger_fog. See fog.bsp and docs. Target_phaseshift causes the targeted entity to cycle between visible- >RF_TRANSLUCENT->EF_SPHERETRANS->invisible. Shift frequency is controlled with wait and random values. See pshift.bsp. After checking out fog on a TNT2 and being mostly unimpressed, added "allow_fog" cvar. This value is 1 by default. If set to 0, target_fogs are discarded at startup. "allow_fog" will be saved to config.cfg. It will have no effect on fog console commands, and will not take effect until the game is restarted. Changed model_spawn with PLAYER_MODEL spawnflag to use the player's model and skin. There's no way (that I can see) to assign a skin to a model that isn't a real player. Usermodel is now ignored for model_spawn with the PLAYER_MODEL spawnflag. Added "tremor_infirmary" info_player_intermission. If present in a map, the player will be moved there at death and respawn at the last target_goal position, last "load game" position, or at the map start, whichever occurred last. See hyde1.bsp for an example. Beta G Nov 18, 99 First stab at our status bar. Yes, the icons need work. You volunteering? :-) func_bobbingwater - Divine Comedian's suggestion. This is identical to a func_water with the addition of "bob" and "duration" key/value pairs. Bob specifies the amplitude of the bobbing motion; duration is the time (in seconds) between cycles. If you use this entity as a func_water movable brush, the entity will NOT bob in its "open" state if "wait" is >=0. If you want the func_bobbingwater to bob at both ends of its motion, use wait=-1 and re-trigger it to "close". Many changes to the gremlin's escape AI. First stab at the player death/respawn sequence. Changed (hopefully for the last time) keys and values for model_spawn and model_train. Changed crane to use the blaster glow as a spotlight effect rather than the cone model. I never got much feedback on this... if you want to see the cone model start crane.bsp with "+set spotlight_type 0". Changed up func_pushables slightly - player cannot push a func_pushable with mass > 500 if the func_pushable is on solid ground. Player can push a floating func_pushable of ANY weight. Beta F Nov 10, 99 Note: Most of this stuff could use a bit of input from you guys. Check out the writeup in Tremor Implementation.Doc and let me know what you think. func_vehicle - moving, drivable vehicle. This is the ancestor of func_forklift. See forklift.bsp monster_gremlin - item thief, steals a random item from player and runs away with it. See gremlin.bsp. target_hint - similar to target_help, but a one-time deal that is meant to display clues for solving the puzzle. See hyde1.bsp (target_hint in this case is only enabled in Easy games). new powerups - jetpack, jumpboots, jumpjet (no damage rocket jump), speedboots. I don't have a sample map for these... to test them out, bind keys to "use jetpack", "use jumpboots", etc.; go to the console and type "give all" or "give jetpack", "give jumpboots". All of these items must be activated with the "use" command - picking them up (or obtaining them with the give cheat) only puts them in the player's inventory. player death - first cut at auto-saving/loading maps. Game is saved at map startup and whenever a target_goal is triggered. Upon player death, last saved game is automatically reloaded. func_explosive - can now be damaged by impact. Bug fixes/changes: Improved func_pushable physics a bit. Impact in water is slightly more realistic than previous version. Changed up renderfx and effects values for model_spawn and model_train so that different effects can be combined. ================================================================================ ========= Beta E Nov 3, 99 New stuff: target_locator can be used to place entities in randomly selected locations (specified by path_corners). This feature has the potential to give your map a bit of replay value. See locator.bsp model_train - combines features of model_spawn (which has been changed quite a bit - see Tremor Implementation.doc) and func_train. This is the result of a suggestion from new guy Bakersman... thank him for it. model_train allows ALL KINDS of stuff that you previously couldn't do. Want transparent moving windows in your doors? You got it... all you need is a window model. Want moving spotlights? You got that, too. And since the model can be animated, there's all sorts of whizbang things you should be able to do with this. Couple of quick notes on this: 1) You'll see in mtrain.bsp that there's a gap between the window panes and the door. I'm not sure right now whether that's because I botched the window model or if it has something to do with the path_corners being slightly off relative to the model. Either way, this will be fixed and shouldn't stop you from using this stuff. 2) Another thing you'll notice right away is that the lighting of md2 models, unlike brush models, DOES change during play, dependent on location. So when the example door slides into the wall, you'll see the windows get dark before they are hidden completely. That's because the origin of the window models is at the center of the model. To use this sort of thing you'll need to be careful about how it is used so you don't end up with this sort of funkiness. 3) Moving lights - unfortunately, model_trains that use the NO_MODEL spawnflag also don't show any of the rendering effects when moving... so there's literally nothing to see. I changed the code to use the null weapon model if NO_MODEL is specified, and gave the model the EF_SPHERETRANS and RF_TRANSLUCENT properties. This helps, but you'll notice the (very small) model in the example map if you stare long enough. Fixes/Changes: tremor_turret_breach. You can now disengage from a turret by pressing +back, in addition to +moveup. I always thought jumping was kinda stupid here, but have left it in for anyone accustomed to MapPack turrets. Thanks to Mad Dog for pointing out that crates generally don't say "uunnggghh", regardless of how far they fall. Corrected a problem with func_pushable sound. In previous version if crate was moved by a func_train or other entity, the sound would play whether the crate was scraping along the ground or riding on a platform. In THIS version, func_pushable only plays a sound if 1) it is being pushed/pulled by the player, 2) it is on the ground. #1 may cause unforeseen problems... if you have a better suggestion let me know. Added impact physics to func_pushable. If you drop a func_pushable on top of another func_pushable that is in the water, the two func_pushables interact - the lower func_pushable is pushed down; the upper func_pushable slows down or possibly bounces, depending on the relative masses of the two. Same thing applies if a func_pushable with a horizontal velocity strikes another water- borne func_pushable. The motion in the normal direction is more-or-less real world stuff and fairly realistic. I added another component to the velocity in an attempt to prevent stacked func_pushables in water (or rather to unstack them)... both the upper and lower func_pushables will slide horizontally until clear of each other. While not entirely realistic, it doesn't look half-bad (in my opinion... if you're not happy with the current setup speak up and I'll mess with it some more). See hyde1.bsp for an example. A Mad Dog suggestion - func_pushables can be damaged by dropping other func_pushables on them. (falling damage to the other half of this wreck has always been in there). Anyhow... damage is done if... V = impact velocity, delta = V**2 * 0.0001. If delta > 30, then damage = mass (hitter) / mass (hittee) * (delta-30)/2. This is pretty much the same criteria for player falling damage... don't ask me about the numbers, I have no idea. For normal gravity you'll get damage if a crate falls more than 190 or so units onto another crate. As always, func_pushables with health=0 are invulnerable to falling damage, impact damage, or pretty much anything else except damage from a blocked train, plat, etc. Invulnerable func_pushables (health=0) are now pushed by trigger_push. (Health <> 0 has always been effected by trigger_push). I suppose this was id's way of keeping dead guys from being moved by trigger_push. Anyhow... it works correctly now. To help judge distance with the crane, we've added a fake light rather than a simulated shadow which was discussed earlier. The problem with a shadow is that, depending on the lighting, it would either look very fake because of being in the wrong location, or be in the correct location but not be much help. Added spotlight to crane_hook that "shines" down from the hook. This helps quite a bit when trying to judge distance. To include the spotlight set the new "spotlight" spawnflag for crane_hook. **** NOTE ***** There are currently 2 different spotlight models available. The default is a cone shaped model. The alternative is the hyperblaster glow, projected down from the crane_hook to the first solid object it hits. You can see this spotlight by starting the game with "q2.exe +set game tremor +set spotlight_type 1 +map crane". I'm interested in your opinions on which you prefer, other suggestions, whatever. ======================================================================= Beta D.5 :-) Func_pushables get pushed by currents. Beta D 10/29/99 Added MapPack's controllable turret in lieu of Scampie's asked-for cannon. To use, replace turret_breach with tremor_turret_breach, and set sounds=1 for railgun, 2 for rockets, 3 for BFG. Use normal +attack key to fire; jump to exit. See turret.bsp Added (and fixed) MapPack model_spawn. This is pretty cool. You can place ANY model in your map. Static or animated, and add all kinds of whizbang effects to it. See the Implementation doc... it can be fairly complicated. Bug fixes: ========== If player leaves the ground while pushing or pulling a func_pushable, he now loses contact. In previous versions you could use a func_pushable as a funky parachute when falling, or climb a func_pushable that was jammed up against a wall. If a func_pushable becomes jammed up such that it cannot be pushed or pulled in the desired direction, the player loses contact with it. In previous versions this situation resulted in the func_pushable hopping to the new location once the path was clear. Fixed weird problem associated with the lack of an origin brush, which caused things to run into walls well before the wall was reached when you pushed or pulled a func_pushable towards X=0 or Y=0. You might have noticed this in the last release of box.bsp. Man I hate origin brushes :-) New sample maps =============== turret.bsp Demonstrates tremor_turret_breach model.bsp Demos model_spawn pool.bsp Added a few func_trains to move things around a bit Beta C 10/27/99 Func_pushables float! This is pretty nifty. Waterline is based on density of the func_pushable (density is calculated assuming func_pushable is a parallelepiped). Func_pushables with density > .0035 sink. Why .0035? Assuming player is roughly the same density as water, mass=200, volume=56x32x32 -> player density = .00349. Yeah I know this is silly but it needs to be based on SOMETHING. Anyhow... density of .00175 or lighter floats with waterline at center of object. If they floated higher than that they'd look strange. For a 64x64x64 crate this corresponds to mass=459. The same size crate with mass=918 sinks. The corresponding masses for a 32x32x32 crate are 1/8 these values: 57 and 115. Crates with densities between .00175 and .0035 float with the waterline somewhere between the midpoint and the top of the crate. Crates bob in water. Lighter crates bob faster and higher. You *can* push floating func_pushables, whether you are standing on the ground or not. You *cannot* push them up, though. See pool.bsp for an example. I'm still fooling with the physics a bit, but it's pretty close. I haven't done anything like add masses for stacked floating func_pushables, nor have I taken player mass into account when player stands on a floating func_pushable. Don't plan to, either. Also related to this... player standing on a func_pushable doesn't get eaten by it when the func_pushable is moved by something else, e.g. water or a func_plat. This eliminates the weirdness in box.bsp when you jump on top of a moving func_pushable (In previous version, if you jumped on top of a crate on the func_plat, when the func_plat moved up the crate would go through the player, the player/crate combo then blocked the func_plat, and the func_plat hurt the player). NOTE: There's an annoying jitter when standing on a moving func_pushable that I *think* is related to the different update frequencies used for the player and other entities. I'm workin' on it. New stuff! Combination lock uses 3 entity types: target_lock, target_lock_digit, and target_lock_code. This is pretty nifty. See lock.bsp for an example, and Implementation doc for usage. Changed func_door so that it will not close on a player. Since Tremor is a non- violent game, damage from a closing door seems pointless. This works fine AS LONG AS either 1) the sides of the door are not embedded in the brushes surrounding the door, or 2) the player is standing mostly in the center of the door's path. The scheme breaks down if the player is standing to one side of a large vertically opening door that's embedded in the walls, or if standing in the path of a horizontally opening door that is over twice as tall as the player and is embedded at the top and bottom. Later versions will *probably* include these exceptions. Func_toss - added target field. The specified target will be triggered when (if) the func_toss detonates. tremor_target_changelevel - Identical to target_changelevel, but if spawnflags=1, strips player of all items and resets health to 100. item_methanol changed to item_plasma Bug fix: Func_pushable speakers (for sounds <> 0) now check to see if the func_pushable is on the ground before playing. Map editions: Added health and sounds values to crates in crane.bsp. One of the crates (marked FRAGILE) has a health value of 1, the others are invulnerable (health=0). Beta B 10/24/99 crane_control is now disabled when an item is picked up, and remains disabled until the item has attached itself to crane_hook. In previous versions it was possible to select the pickup button, then pick another action before the cargo had finished floating up to the hook... this resulted in screwiness (is that a word?) Added crane_reset entity. This is a point entity that, when triggered, calls the crane to the crane_beam extent closest to itself. The crane_reset would normally be targeted by a func_button. Crane_reset checks to make sure that the targeted crane_control has been powered up before moving the crane. See crane.bsp for an example. Fixed (sort of) problem of picking up multiple crates. In previous versions, if a crate was picked up that had another crate resting on top, the top crate travelled along as you'd expect. However, synch problems occurred when raising the crate then stopping, causing the piggybacked crate to intersect the hooked crate. I messed around with this some and got THAT problem solved, but then taken another step - a crate on a crate on a crate - was all messed up. So I limited pickup to only having one layer of crates on top. If there were 2 or more layers, the game said "too heavy" and refused to pick up anything. This worked, until you tried to move the crane in the direction of the piggybacked crate. Argggghhh. So... what I *could* do is tie the piggybacked crate motion to the hooked crate, rather than allow Q2 physics to handle it, but there's an inconsistency here... what happens if you pick up a single crate, position it so that an edge is under a crate hanging off a ledge, then raise it? To be consistent the 2nd crate should be picked up at that point. But *this* would require changing the pushable crate touch function that's used for the player to push the things around. This is getting awfully damn convoluted... so bottom line, I wimped out. If a crate has another crate on top, it can't be picked up. The end. For the same sorts of reasons, you can no longer push or pull stacked func_pushables. There are just too many inconsistencies that crop up if this is allowed. If you already have some grand scheme in mind that involves pushing stacked crates, let me know and *maybe* we can work around this somehow. Sounds with brush models - this change applies to the crane components and func_train. If you've ever tried using the "noise" value for a func_train, you've either used an origin brush with the func_train, placed the func_train at 0,0,0 in the map, or wondered why the sound didn't play. The new game dll checks to see if 1) the noise field is used, and 2) if the origin of the entity is at 0,0,0 (which indicates that the entity MOST LIKELY does not use an origin brush). If both true, the game creates a speaker entity that follows the center of the brush model around, playing the sound specified by "noise" when the entity is moving. This eliminates the need for an origin brush with a func_train and the accompanying lighting problems, and also allows the use of a sound for a toggled func_train (sounds played with "normal" func_trains can only be turned on and off at path_corners). New entities: tremor_trigger_multiple and tremor_trigger_key Why new entities instead of modifying existing entities, you ask? Well that's what I originally did, but Mad Dog came to your rescue and suggested this alternative, since 1) there's no way to simply modify existing entities in an add-on .fgd file and 2) you don't want to screw up your trigger_multiples and trigger_keys for non-Tremor maps. Anyhow, what these do: tremor_trigger_multiple is identical to trigger_multiple, except that it is toggled on/off each time it is targeted. This eliminates the ability (though I honestly didn't know this ability was there) to fire the triggers targets by targeting the trigger. tremor_trigger_key is identical to trigger_key, except that 1) it's persistant - it doesn't go away once the player has the required item, and 2) another Mad Dog suggestion - it has a key_message field. This message (if present) is displayed instead of the normal "You need the blankety-blank". The tremor_trigger_key is used with the admittedly exceptionally ugly vending machine in vending.bsp. These aren't finished :-). One machine is no-cost, the other requires an item. You'll figure it out. ID feature similar to RYO misnamed player id - displays common name of whatever player is looking at. You can toggle this on/off with "id" console command. Added item_battery, item_cells, item_gas, item_alcohol, item_methanol, and item_nuke. These currently all use the ammo_cells model, and will likely continue to do so until Monsto gets past the notion that I'm a modeller. The bounding box will be the same as normal Q2 pickups - 32x32x32.