CtrlAltDestroy has contributed to 91 posts out of 464953 total posts
(.02%) in 4,917 days (.02 posts per day).
20 Most recent posts:
Most of you already have these. Figured you might as well get them straight from the horse's mouth.
Quote: keep in mind that halo does not interpret motion of frame bone, only rotation. In other words, if you use the move tool on frame bone 24, it will not move in game, however the rotation tool will work. Make your movements with frame gun every time.
stop using JMA and use JMM.
If anyone else wants Halo 3 assets, theres a (relatively) functioning extractor here: http://rework3d.com/forums/viewtopic.php?f=112&t=82537&start=20
Also, if you want any other assets, i can help you out too.
Quote: --- Original message by: Dennis
Quote: --- Original message by: CtrlAltDestroy
the AI security camera on The Pit was set to target the first player that entered its field of view. Therefore, the camera's aiming was based on player position (something that does sync) rather than inherently random AI behaviors. It has synced perfectly every playtest so far.
Implement something similar with your automated turrets and it should synchronize over netplay.
Although your solution allows for suitable net-game play it in fact does not synchronize across the network. No data about its status, position or activity is transmitted across the network. All it does is operate similarly on each client PC but is totally reliant upon each client PC operating at the same speed in the same way.
Yes, I am aware of this. While each client is effectively generating its own set of properties for the AI turret object, the elimination of the randomness associated with AI behavior can (arguably) be considered an effective solution to this (barring latency, and other related issues).
On the matter of "synchronizing" object state (intact, destroyed), some clever scripting would have to be involved.
Edited by CtrlAltDestroy on Jan 16, 2010 at 03:15 AM
The reason AI does not synchronize over netplay stems from the sole fact that AI behavior is based on randomly generated values. Remove the 'randomness', then you have syncing AI. For example, the AI security camera on The Pit was set to target the first player that entered its field of view. Therefore, the camera's aiming was based on player position (something that does sync) rather than inherently random AI behaviors. It has synced perfectly every playtest so far.
Implement something similar with your automated turrets and it should synchronize over netplay.
Actually, our hud was custom made.
OK, just for the record, i'll set things straight with animation types:
First, lets run down on a little thing called frame info. You may have noticed these dx, dy, d-whatever things in the animation tag. 'd', for those of you who are familiar with calculus, means the derivative of--or the rate of change in--something, which is precisely what frame info is. It tells the game, frame by frame, how much an objects transformation is changing. dx, for instance, is the change in movement in the x direction. Similarly: dy for the y axis, and dz for the z axis. There is another called dyaw, which is the change in yaw rotation (or z rotation). Frame info provides additional data to an animation that may be useful for the engine to apply to various situations. For example dx frame info in a running animation may tell how fast a biped is moving (which is what the game uses to determine how fast an AI runs).
JMM is a base animation with no frame info data. This is ideal for FP animations as it does not cause tool to store redundant data (ie: JMA stores dx,dy frame info data, which is used for bipeds).
JMA, as mentioned previously, is a base animation with dx,dy frame info. It is ideal for running/walking animations in bipeds, as it tracks x (forward/backward) and y (left/right) movement data.
JMT is a base animation with dx,dy,dyaw frame info. This is used in turning animations for bipeds, where frame data is needed to track yaw (z axis) rotation. Much like how dx,dy frame info allows the game to determine how fast an AI moves, dyaw allows the game to determine how much the biped turns, along with the dx,dy frame info that JMA provides (hence dx,dy,dyaw).
JMZ is a base animation with dx,dy,dz,dyaw frame info, it provides everything a JMT animation does, but with the addition of dz frame info, which obviously is movement on the z axis.
JMO is an overlay animation. Aptly named, these animations 'overlay' themselves onto base animations or otherwise. Rather than animating the object with absolute transformations, they use relative transformations to modify an animation already playing. An example of an overlay animation is the first person moving animation. Rather than wasting time animating 'moving' variants of the reload, ready, fire, idle, etc. animations, a simple moving overlay animation is used to simulate the "sway" of the gun, regardless of what animation is playing.
JMR is a replacement animation. These animations are more like base animations than anything, but with a few differences. In a base animation, even if some nodes are left unanimated (still throughout the entire animation), in the final product ingame, they will appear as "still" throughout the entire animation. Replacement animations, on the other hand, ignore unanimated nodes. This is useful in many cases, for example: If a reload animation for a biped (tp, not fp) was made to be a base animation, many variants of it would have to be made: reloading while still, reloading while moving forward/backward/left/right, reloading while crouching, the list goes on... With a replacement animation, one can just animate the upper body movement (spine, arms and what have you) and leave the lower body still. This allows the game to play the base animation of running, crouching etc for the lower body and play the reload animation on the upper body. Much more efficient.
JMW is a world relative animation. This is useful for cinematic animations (read: NOT recorded animations, thats a whole other subject). World relative animations are played relative to... well... the world (ie: the origin [0,0,0] point of the level). This allows the animator to animate, say, a pelican directly on the level geometry and have it work flawlessly ingame.
Hopefully this clears up any confusion with animation types (if you took the time to read all that lol)
Edited by CtrlAltDestroy on May 18, 2009 at 02:01 AM
Definitely not zteam... 'cause, you know, they're a bunch of ripping *******s. ;)
Edited by CtrlAltDestroy on Apr 12, 2008 at 10:48 PM
Better shaders, again.
A variable does not store an actual object, it stores a reference to an object (with the exception of primitive data types such as integers, etc). So, if you assign say, "(unit (list_get (players) 0))" to a variable, when you call that variable, the engine will evaluate what you assigned to it (more or less; it actually holds an address to the object)--in this case "(unit (list_get (players) 0))", which will return an undefined object as you called* it after the player died. It simply will not work. A variable will not hold an actual object. That would be far too costly at runtime and would be redundant anyways.
Edited by CtrlAltDestroy on Mar 16, 2008 at 02:51 PM
When a player dies, the corpse loses its status as a "player" object, and therefore, the player effectively does not exist until he respawns. How are you going to assign a non-existant object to a variable in the first place?
If you can't set the permutation of a dead player, what makes you think you can set the permutation of an instance of a dead player? Your script is redundant because in the end, you're still referencing the same object you began with.
Better shaders please.
(script static void navobject_dead
; stuff that happens when object dies
(script startup nav1
(sleep_until (volume_test_objects v1 (players))) ; test any player in trigger
(activate_team_nav_point_object default_red player example 0.6) ; replace example with your objects name ; activates nav point
(sleep_until (<= (unit_get_health example) 0.0)) ; replace example with your objects name ; tests the units health
(deactivate_team_nav_point_object player example) ; replace example with your objects name ; deactivates nav point
Quote: --- Original message by: Kiwi
Quote: --- Original message by: Brian
well fov i already knew lol like i have a halo pc 3rd fov camera
lol i just saw dane cook comercial, i wanna see dane cook now...
Something different from what you think, if Kiwi remembers Halo 1 is about 120 degrees while Halo 2 is about 90 degrees. Dunno about Halo 3.
They're both 70 degrees.
Maybe because halo ce != halo 3, if you are implying ingame wise.
Edited by CtrlAltDestroy on Jan 25, 2008 at 05:05 PM
"...and other well known people on my team."
Edited by CtrlAltDestroy on Jan 14, 2008 at 01:01 AM
Because clients cannot interact (for example: change permutation to damaged) with server created vehicles EXCEPT for entering and driving them, etc.
So, you're saying that every team should share their assets with the entire community--indiscriminately, in hope to expect benefit in the end?
That makes you a communist.
Edited by CtrlAltDestroy on Dec 16, 2007 at 07:02 PM
Quote: --- Original message by: zsdg06
so as leader.... is this what you tell your members, "START RIPPING!" or do you actually do anything..... no offense lol
Despite what the public might think about us, we do not (exclusively) rip. There is a LOT more that goes on in our 3-man team that probably no one else knows or will know of. The reason why, I think, that is the image we receive is that the 2 (3 if you count duplicates) maps that we have released so far only showcase the surface level content, which, the majority of which was taken from Halo 2. Case in point, even though we might take some (ok, most ;p) of our assets from Halo 2, do not view it as an easy 'three-step' process. Sure, probably everyone in this community can rip, though the sheer level of the amount of people that manage to mess it up in some way should speak to the point that even ripping (making it look nice, particularly) requires a shred of effort. By no means am I saying that ripping is harder than and generates better content than creating it yourself, just that it should not be seen as a process that requires no effort to generate a finished product.
Also, to answer your question, yes, I do much more than order people around. ;p
Quote: --- Original message by: SiMuLaCrUm Quote: --- Original message by: CtrlAltDestroy
Quote: --- Original message by: SiMuLaCrUm
No, all they did was rip. Wow how very creative. And all they've released are 2 betas.
Because CMT is so
much more creative. ;)
Well they made more content on their own, rather than rip. OK so they modded BSPs but the new stuff they put in was good.
How you create your content does not [directly] correlate to creativity. Sure, CMT made their assets on their own, but most their concepts are taken from other mediums of Halo (other games, books, etc). I'm sick of people tossing around the word 'creativity' like they know what it means.
Edited by CtrlAltDestroy on Dec 16, 2007 at 06:34 PM