Me KS has contributed to 1000 posts out of 469359 total posts
(.21%) in 4,247 days (.24 posts per day).
20 Most recent posts:
Quote: --- Original message by: MoooseGuy
Is it possible to set the player unit as a vehicle? I never tried this...
Yes. It's in the globals where you specify the multiplayer biped. You can switch the 'unit' from 'biped' to 'vehicle' and then just specify whichever vehicle you want.
The game will play just like usual, except you will spawn as that vehicle.
Also, whichever vehicle you play as would have to be destroyable or else killing each other would be impossible.
Quote: --- Original message by: Maniac1000
Is recorded animations where you can have animations of like a huge fight, all viewable in sapien?
Ive never fully understood, but i have read countless times that it cant be done.
Recorded animations are really adaptable. They're not like normal animations that move the nodes around and so are limited to an exact model only. Instead, what they do is inject inputs into vehicles or bipeds exactly as if a player was controlling that biped/vehicle.
This is why you can run any recorded animation on just about any biped or vehicle: the animation is a recording of player inputs being played back. The recorder for recorded animations must have been a simple recording of your input as a player that the game saves in the scenario when you're done.
Imagine being able to just take control of a peli in Sapien at a certain starting point, hit 'Record', and just casually fly it around the way you want it to enter into the map, then saving that recording to be used in the scripts whenever you want the peli to do that. Wouldn't that be amazingly easy? That's basically how it must have been done.
Of all the things they removed from the HEK removing that was a huge missed opportunity for us.
Quote: --- Original message by: Mysterion
Ok, it seems to work now after I put () around the player0 and player1, however, it can't tell the difference between player0 and player1. For the script where an alert is supposed to sound when player0 enters player1's base perimeter, if you change sides, and are now player1, you still set off the alert.
If you are the only player in the game, you are always (player0) no matter what side you're on. If somebody were to join the server with you (assuming this is MP), they would be (player1).
Edit: actually, scratch that. If somebody were to join a server with you, you would become (player1) and they would be the new (player0). The number system is really weird with the (players) variable, just letting you know.
Edited by Me KS on Apr 25, 2010 at 06:44 PM
Quote: --- Original message by: Gamma927
When you attach an object to another, there is no collision for the attached object, hence why if you were to load a warthog into the cargo seat of a pelican, it'll clip through the ground if the pelican were positioned as such.
It's been a while since I last did a tl;dr post. Here goes.
Although it would clip through BSP, all other objects, including projectiles and players, can still collide with the attached objects.
I had completed scripts that were almost implemented in RPG_Beta6.2 for this exact feature, except one of the scripts needed for it just plain didn't seem to run for some unknown reason, so it was scrapped unfortunately. It sounds like it was an error in the script, I know, but I checked that script many times and I swear I couldn't find anything wrong with it.
Point is, I was able to get as far as implementing a system for checking the vehicles underneath the peli for any available ones and storing which one was available, which meant we implemented the biped attachment just fine.
Through testing the attached bipeds, yes, you have to do something about their collision, or else they could get shot at and collide with players trying to walk into peli.
I found that even getting rid of their collision model references wasn't enough. Although projectiles would pass through them and they would not be able to take damage, they would still collide with player bipeds when attached. But, checking 'passes through other bipeds' did the trick.
In addition, once attached, the only players that could get inside the peli were the ones on the same team as the bipeds. Apparently there's no difference between loading them in a seat and attaching them.
Had it not been for time, we would have made an invisible scenery to attach to the peli with 2 markers on it to attach the bipeds to the scenery rather than the peli, but that didn't happen either. My temporary fix was just to set the bipeds to the 'default' team so at least Red team could hop in.
Quote: --- Original message by: Niels
So in order to make it move better this script shoot refresh faster but still not to fast to lag anything? Is that even posible?
The laggy vehicle issue can't be helped. The reason is, like Gamma said, the script detaches the vehicles once re-attached so that the netcode recognizes them as separate objects and still sends their position to clients.
However, when a vehicle isn't occupied, the server only refreshes its position at certain intervals. Normally, this is all that's needed since forces that could throw around unoccupied vehicles are usually synced. For example, a grenade explosion should sync, so on client and server the vehicle should get tossed very similarly so the server shouldn't have to update its position as much or at all.
But in the case of the peli pulling along a vehicle, there isn't even any force. To the clients, the vehicle is just changing position for no reason, so the server has to constantly update the position of the vehicle. Due to the fact that it only updates the position at set intervals, what you see as a client is a vehicle lagging to keep up with the peli.
The only 'fix' to this is to somehow decrease that interval, but that's probably hard-coded.
Quote: --- Original message by: Old Gregg
Nope, someone found a way but theirs a glitch of random spawning bipeds around the encounter spots or soemthing like that.
That 'way' didn't do anything. It changed nothing.
Quote: --- Original message by: 117
For those of you wondering what the method behind this is, click this link: http://rework3d.com/forums/viewtopic.php?f=89&t=66956
(Tricks the engine into thinking the AI are vehicles. Their positions sync, however their aim vector will not. This is according to Adolif.)
The method changes nothing about the tag's data. All it is is a swap of the tag type in HHT from 'bipd' to 'vehi'. It's just an identifier. It changes nothing about the actual data that makes up the biped. It's still a biped. In order for the netcode to treat something like a vehicle, it must actually be a vehicle.
And even then, you won't get very far, since there's no way you're going to get a vehicle to look and function like a biped, particularly with AI.
Quote: --- Original message by: 117
I take no credit for the method behind it, only the attempt. And I have to say that I wasn't expecting him to post this. (My current suspicion is that the clientside bipeds get in the way of the syncing working right; there are still invisible AI running around that the client cannot see, but can kill, which I think is due to the fact that the game won't let the AI run through the clientside bipeds that the clients see. Some AI will sync, but eventually they break the sync attempting to run through the client bipeds.)
The 'invisible AI' are the actual server side AI which aren't syncing. The client side bipeds that sit there unarmed are the result of the tiny fraction of things that usually sync with bipeds: health and existence. Nothing more.
The ones that clients actually see working properly are nothing but completely independent local instances of AI that spawned when the player joined the game. They don't exist on server side so their actions basically don't count.
You can warp right through them and their shots have no effect on you. These guys are completely unsynced in every way, and if you think that some of them are syncing it's either a complete coincidence or bad judgment.
What I'm saying is that nothing is 'getting in the way of the syncing'. There is no syncing. The changes that were made had no effect. If you grab any other AI map, you'll see the same 3 things on client side: dummy bipeds representing server side AI bipeds, local client side independent AI, and server side 'invisible' AI actually hurting you.
Quote: --- Original message by: Gamma927
He wasn't specific enough >>
Oh I know, I wasn't criticizing you for not knowing, just pointing it out now that he made it clear.
Quote: --- Original message by: Glitcherguy
(script startup insertion
(ai_allegiance player human)
(sleep (sound_impulse_time "sound\dialog\x10\sgt05"))
He's not playing sound tags, he's using the AI conversations from the scenario.
You can check the status of a conversation:
returns the status of a conversation (0=none, 1=trying to begin, 2=waiting for guys to get in position, 3=playing, 4=waiting to advance, 5=could not begin, 6=finished successfully, 7=aborted midway)
So if you want to wait until 'jhonson' finishes successfully (6), you can use (sleep_until) like so:
(sleep_until (= (ai_conversation_status jhonson) 6) 1)
But I would recommend checking for 7 and 5 as well, because if either of those end up happening then the script will hang there permanently since it won't finish successfully, so this is what I would do:
(= (ai_conversation_status jhonson) 6)
(= (ai_conversation_status jhonson) 5)
(= (ai_conversation_status jhonson) 7)
Quote: --- Original message by: Dwood
An ie update killed all halos on 64 bit comps. thus, 1.09 was born.
Really? Because I have Windows 7 64-bit on my laptop and I can run version 1.08 of CE and it works fine there. Although Halo does give an error saying that my computer has absolutely no RAM on startup, but once I hit 'continue anyway' it works fine since there clearly is sufficient RAM.
Maybe the patch just addressed the error so it wouldn't annoy people?
Edited by Me KS on Apr 6, 2010 at 11:22 PM
Quote: --- Original message by: doompig444
They aren't, I'm pretty sure they're random.
Tested again with 017, he sightjacked me while I played normally, it seemed to be working, but with glitches and lag.
Your 'tests' aren't good enough. You're just playing the game and assuming that they sync. Well, I did the real testing needed.
As promised, 2 screenshots from the same viewpoint at the same time, one from the server and one from the client. I did nothing at all to the AI in the game on either end before taking these screenshots.
Quote: --- Original message by: doompig444
And how did you achieve your AI sync? It's all in the method.
I didn't, nor am I trying. Nothing but a change in the Halo engine can make AI sync. Also your 'method' is way too simple. I know what you changed. In theory, a very possibly idea, and again I thought it had potential since I never heard it before. But unfortunately it doesn't work.
Quote: --- Original message by: doompig444
I am pretty sure his were synching, because I could see him killing stuff and vice versa.
And I'm not pretty sure, I know they don't sync. I used to mess with AI a long time ago with 2 computers hooked up through a LAN to see how AI worked out in the netcode, so I know what to look for. I didn't see anything different when I tested it here. Same, unsyncing AI.
If you really aren't convinced, I will post 2 screenshots, one from each computer (server and client) from the exact same viewpoint at the same time.
I know you don't accept that they don't sync, and trust me I would hate me right now if I thought I was on the brink of an epic achievement and someone was shooting me down, so I can understand that. But I would be letting you lie if I didn't try to prove otherwise, and misinformation isn't good for anybody.
Well, I have a more sure answer.
They're not syncing.
It's best that people know the truth so that nobody gets the wrong idea. I'm really not trying to criticize your efforts or anything, just saying the truth. To be honest I was convinced the idea might work until we tested it. But anyways here it is:
The AI that you see running around are nothing but the completely independent client-side AI that spawn when you join the game, just like in any other AI map. They aren't synced to the server-side AI.
These AI are just like scenery: because they don't sync at all, you can spawn them all you want on client-side and they will function perfectly-only they don't exist at all on server-side. Same goes for server-side, except they do exist as the 'dummy' bipeds on client side, but nothing more.
And we're sure about this (or at least I am xD) Here's what we tried:
-Killed all AI on server side - AI on client side did not die as they should have if they were syncing
-Killed all AI on client side - AI on client side shouldn't have died if they were synced to server AI.
-Because of this, we were able to have different number of AI on server and client which shouldn't happen
-We saw AI in different positions
-I killed all my client side AI while server side AI still existed - I was getting shot by nothing as the client
-The server would warp me right through an AI standing still, indicating it wasn't there on server-side - further proof for different positions
-Client side AI would be shooting at me and not hurting me at all
And when I say 'AI' I mean the functioning AI running around and shooting, not the dummy bipeds. We also turned off respawn whenever we killed them to make sure there were none at all.
Quote: --- Original message by: ODX
I can't play for some reason, because my version changer can't make me go to 1.09. Anyone know a possible way to stay on 1.07 (so I can use Yello Battery), and play on 1.09?
You probably have the older one before 1.09 was out. They updated it now: http://goemitar.wordpress.com/version-changer/
Quote: --- Original message by: IcePhoenix
So you think they deserve the ability to march into any game and ruin it by just holding back the entire enemy team?
Yes, if the enemy team is bad enough to let one sniper 'ruin' their game. Every weapon has a weakness. The sniper's biggest weakness is other snipers. If the enemy team is bad enough not to be able to take one annoying little sniper down, then they deserve to get held back.
Quote: --- Original message by: IcePhoenix
Oh and I forgot.
Another reason why sniper and pistol/BR are annoying weapons: they are pretty much the only ones which can turn from being slightly annoying to just ridiculous in the hands of an aimbotter.
I mean, at least the guy who spawn-camps your team with sniper actually deserves itto SOME extent.... but a guy doing it with aimbot is just.... [insert entire vocabulary of swear words in here]
That doesn't count. You're arguing that those weapons are annoying purely because they can be abused by a hack which was never meant to affect the game. They are most definitely not always abused by the hack since only a minority of players aimbot, so you can't call that a bad characteristic of the weapon. It has nothing to do with the weapon, but rather with the player using the weapon while botting.
Quote: --- Original message by: IcePhoenix
and seriously, imo sniper is the cheapest weapon besides fuel rod. it kills in 2 bodyshots, 1 headshot, has infite range and perfect accuracy. you can hide and kill enemies when they can't return fire. i find it's for pussies. plus if someone good is using it, you can't even stop urself getting killed again and again. ruins a whole game.
I used to completely agree with that opinion. I hated snipers. But then I realized that although the sniper has the potential to be extremely powerful, it's balanced out by the fact that you need very good skill at aiming to use it.
After all, if you think about it, it's without a doubt the hardest human weapon in the classic set to use. Possibly the hardest period. Considering the lead due to latency, consistently being able to nail two body shots let alone a head shot on a moving target is tough for the average player with only 4 shots per clip.
So, like you said, 'if someone good is using it.' Exactly. Only somebody good can use the sniper to its full potential. Frankly, if someone sucks at sniping, the sniper weapon becomes nothing but a harmless waste of ammo. And so for those who are good enough to harness its potential, they deserve it.
Quote: --- Original message by: shadowce9
(script continuous air_check
(sleep_until (unit_get_current_flashlight_state (player0) true) 15)
(unit_set_desired_flashlight_state (player0) false)
It's saying it needs one argument because you added 'true' as if it was a second argument. What you meant to do was test whether the function (unit_get_blah_flashlight) is equal to 'true', right? Well you need the test function (= [expression] [value]) for that.
So the [expression] is the flashlight function written in parentheses (functions and scripts are always in parentheses), and the value you're testing for is 'true' (values and variables are written in without parentheses). So here's the corrected line:
(= (unit_get_current_flashlight_state (player0)) true)
Then use (unit (list_get (players) 0)).
Or you could just add this static script to the beginning of the scripts:
(script static "unit" p0
(unit (list_get (players) 0))
And then whenever you want to refer to the player just type in (p0). Saves effort.
Edit: ^ Lol beat me to it.
Edited by Me KS on Mar 29, 2010 at 09:40 PM
I wrote a couple tutorials on those two things a while ago, so here you go:
Chapter titles use "unicode_string_list" tags for storing the text.
For that, get this string list editor. It makes editing unicode_string_list tags much easier, since you can just open and save the tags directly without having to compile through Tool: http://hce.halomaps.org/index.cfm?fid=1049
Then, using the string list editor, make a new "unicode_string_list" tag with as many strings as you want. Each string will be one Chapter Title. Once you're done, save the tag anywhere, but preferably in the same folder as your scenario tag. Name it whatever you want.
Next, in Guerilla, open up the scenario tag. Go all the way to the very bottom and you'll see "Cutscene Titles". Just under there should be a tag reference that says "ingame help text". Browse on that one, and select the tag you just saved.
Then, just next to "Cutscene Titles", click the "Add" button to make as many chapter titles as you need. Just under should be "name". Make the names whatever you want, but make them easy to remember because that name is used in the script.
Now, the "text bounds" and "justification" should be self-explanatory, but they're not. I'm not sure what screen resolution the game assumes as a standard when using the "text bounds" values. If someone knows, that would help. But, t = top, b = bottom, l = left, and r = right bounds, and the 3 justifications are general positions: "left, right, center". You can mess with those some if you want a different position than usual, but if you want the usual, just enter these values that I got from a10's scenario:
That actually makes it come out to the left, oddly enough.
Once that's done, set the "string index" to the index of the string you want to use for that chapter title. If you're not sure, you can get the number by opening the string list tag and looking at the number to the left of each string right in Guerilla. It starts from "0" and goes up.
Then comes the text color. The "r, g, b" values are just 0-255 levels of red, green, and blue to make a color. You don't have to worry about that, just select the color by clicking the box to the right. Most likely you want white. Most of the time, the shadow is set to black, but it can be changed too. Don't miss the "a" before each color though, that's the alpha transparency. 0 = fully transparent, 255 = opaque. So most likely you want 255 for no transparency.
Then, the fade times should be self-explanatory. "up time" is how long it stays fully opaque on screen once it fades in, "fade in" is how long it takes to fade in, and "fade out", same thing, but fading out.
Then, the script is the easy part. Whenever you want the chapter title displayed, just use this command:
Usually you want the letterbox to appear and the hud to disappear in conjunction with that. Just as a reminder, it's:
hud_messages are different from unicode_string_lists that the string list editor saves. These you're going to have to do manually in notepad and compile them with Tool.
First off, in your notepad file, each line will be one hud message. Don't make them too long, as Halo does not clip the message to a new line in-game, and instead it runs off the screen. However, there is a way to make new lines if you really need that much text. It's shown later in the tutorial.
You have to name each message with a name that's easy to remember so you can refer to it in a script, and then directly after the message name, stick an "=" sign and then write the message right after. So, here's an example of a few lines:
vehicle_warning=>> WARNING: Enemies Alerted
crapload=>> Eliminate All Covenant Forces
crapload_1=>> Then Advance Into The Area
You don't have to include the ">>" at the beginning, but it was used for most hud messages and it looks best to have it.
Now, if you find yourself absolutely needing more space than the screen offers for one message, there is a 'new line' character and it looks like this:
Wherever this character is placed, the text after it will be part of a new line on the screen. I doubt it's necessary, but whenever Bungie used this newline character they always put one space before and 4 spaces after it. It's probably for aligning the new line with the first line, so I would do the same. Here's an example from b40's hud_messages (you might not see the 4 spaces, so just quote me to see them):
obj_chasm2=>> Reach the transition to the |n third chasm.
After you have all of the messages you need, save the file in the exact same directory as your scenario is located under the "tags" folder, but in your "data" folder, and you must save it as "hud messages.hmt" without quotes and change the "Encoding" to "Unicode", not the default "ANSI". You will know what I mean when you go to save with Notepad. Tool will not compile correctly unless you do all of these steps.
For example, if your scenario is located in "tags\levels\amazingmap\amazingmap.scenario", then you either have to find "data\levels\amazingmap" or create that directory and then save it there, resulting in the file's path being "data\levels\amazingmap\hud messages.hmt".
Then at this point you're ready to do the tool command hud-messages, which is:
tool hud-messages (path) (scenario name)
So, for the example above, I would type:
tool hud-messages levels\amazingmap amazingmap
because the path to either the scenario or the messages file is the same: "levels\amazingmap" and the scenario name is of course "amazingmap".
It then compiles your hud_messages tag into the tags folder where your scenario is and automatically gives a reference to it from your scenario so you don't have to do it yourself. Then, you're ready to refer to these messages in your script.
shows or hides the hud help text
"boolean" meaning you can enter "true" or "false", as in "yes" or "no", or you can enter "1" or "0", respectively. When this is turned on, the hud message selected will be constantly displayed, so you should turn it off again when you want it to disappear.
displays "message" as the help text
This command selects which hud message to be displayed when the command above is set to "true". You use the name of whatever was before the "=" sign for the message you want in the original ".hmt" file you compiled. For example, for this line in the hmt file:
ohcraphelpme=>> You're Screwed, Have Fun
If you want that message, you use this command like so:
sets "message" as the current objective
This command does the same thing as the one above, except it sets the message to be displayed when you hit "Esc" and go to the pause menu under "Objectives".
Quote: --- Original message by: DarkHalo003
What exactly is the camo-fix for? Standard GFX or for a modification?
When Halo runs on an NVIDIA card, it makes players transparent instead of giving them the camo distortion. Dxtweaker fixes that.
'map_name' is a default console command. You don't need devmode for it.