Wasn't Containment a map added later?

I am pretty sure but I could be mistaken. I don't feel like looking it up but I am almost 100% positive it was.

quotes from WIKI: "This is by far the largest map Bungie Studios has come out" "It is sometimes referred to as the map "That's so big, it won't fit into the Xbox." "The level may also remind you of the classic multiplayer level from Halo: Combat Evolved, "Sidewinder", being set in the snow and having a blue and red base. However, this map is very different from Sidewinder and is not a Sidewinder remake. It was originally intended to be a remake of the Halo PC map, Timberland. The map has many similarities to Battle Creek in the first area, as each end has a complex base with many levels, and is set in a valley with alternate base entrances and teleporters, though of course on a far larger scale." "Containment is a Halo 2 multiplayer map. It was added to Halo 2 in the Bonus Map Pack"

I hope that clears up all the questions about containment, and just for the fun of it, I think I an gonna play on this map later on the xbox, anyone care to join me?

I have it. There is an interview with one of the designers where they talk about it. It is not a remake, but its design was inspired by Timberland.

oshi- it's Karrde

didnt he quit cause no one spelled his name right?

You're jumping to conclusions. I liked the gate system, but i never saw the point when

A) The gate is opened from outside
B) One can get out when the gate is closed
C) One can get in when the gate is closed.

It would be better if you had to open the gate to get out, but ran the risk of enemies getting in. The entire map would need to be redesigned around the concept. And its hardly worth working on it in a multiplayer element when it doesn't sync. Maybe i need to try working with halo 2 or 3?

if shadow doesnt get help from salimander (forgive me if spelled wrong) for the machines. Ill do them or atleast try.

I seem to have better grammar than you on instant messaging services. :/
I'll get the damn shaders done sometime, when I'm not busy as hell.

I'm already pretty sure I know the answer to this, but there isn't a way to make things like massive gates sync in MP, is there?

Not really. The way the game is designed the information about AI, Device machines and animated scenery is not transmitted over the network between client and server. People have used biped kill scripts to try and sync device machines however they are subject to twice the inherent lag of everything else because of the way that on-off information is translated across the network. In addition you cannot determine variable or intermediary position or state of a device or AI using on/off scripts because they run at the rate of each local computer. With fast moving doors this can be acceptable since the variable positioning is fast enough to not interfere with game play but with a large slow moving door the intermediary positions would be different on each client which would interfere with game play.

machines sync online with a script that puts two bipeds for that machine one for on one for off so in this case on containment I would need 4 bipeds and two scripts and i have them

This is a misconception. They do not sync in that they do not transmit the position or status between client and server. All you can do is tell the device to start or stop but you can not insure the position or status across all clients and all clients run at a different rate. In fast device machines this is not a problem but on slow ones it is. That is why you can't make a reliable lift. You can't sync the actual position of the lift on all clients. The same would hold true for slow moving doors.

Is that also because of the absence of lag compensation? Wouldn't the start and end SUPPOSEDLY be the same because the animations should not change from client to client?

There are many factors involved in the script initiated device machine operation. First the devices run at different rates on different speed PC, the scripts also run at different rates and since it all relies on killing a biped which takes three network traversals to operate: spawn vehicle - kill biped - initiate device. There is built in network lag due to the time it takes the biped to be killed and the server to register it. On the client the device gets initiated but the server has to wait for local biped kill before its device actuates. This immediately puts the device position of the client and server out of sync because they are running at different rates and different start times.

Like I said, on fast moving devices it can be OK but on slow moving ones not so much.

If korn can get his networking upgrades working, os can sync most of that stuff except ai.
Edited by Dwood on Jan 31, 2010 at 02:08 PM

Then I hope he does, i'd like to see this kind of thing implemented.

Dennis. Heres the question I have. If it works pretty well for fast moving objects, but you have an object to move slowly, what if you were to break it up into different stages - each stage being a different Biped (Which is ironic, as gates are not bipedal).

Therefore, the speed between the different stages would be fast enough to have conciderably better syncing. Doing this in an array allows a large object to work reliably.

The only hole that could be blown in this is if it were to make obscene amounts of lag, not from the process itself but from running it multiple times in succession. For a gate the size of containments i would think you would need at LEAST ten different stages. Thats forty bipeds, i believe.

You just can't sync slow moving device machines because the status and position of the device is not transmitted across the network. With slow moving devices that effect game play the position is crucial and you can't transmit or receive it properly.

I meant using the bloody biped method that we were discussing several posts ago.

I don't believe you can. Using multiple stages with multiple bipeds increases the network lag and each stage will get further and further out of sync. The game was not designed to sync moving devices especially slow moving ones and any workaround will still be subject to the network traversal issues that plague existing ones.

Even fast moving doors / device machines using the biped script method cause visible and hit related issues especially when impacted by projectiles during their transition. Many times a projectile will look to the client that it hit or didn’t while a door is opening but the server only goes by its positioning and may record it differently. With fast devices people just shrug it off but on slow moving ones they will be more aware of the discrepancy.

Just make the bridges lower very, very quickly. Unless you can think of a good reason to make such a delay.

I remember this was my favorite ever map made for Halo 2 me and my friends used to love it because you could hold out at your base and have basically a drawbridge. I hope this can get made!

Didn't the gates in the original map always lower sort of quick? It's been a while so I can't remember.
Wow this is the most posts by Dennis in one page I have ever seen I think.

Its still slow by standards. Even though they opened remarkarbly fast, he's talking hallway-door fast, which you never had to wait for. They would still be moving sort of 'slow'.

You mean like maybe 6 frames of animation almost. That fast?

What about like the doors in sciophobia though. They open REALLY slow. Why is it that no one seems to have trouble there? Or is it just so slow that it doesn't make a difference in that case?
Edited by eliteslasher on Feb 1, 2010 at 07:05 PM

Are you talking about the normal doors everywhere or the ones leading out to the banshees? Because the banshee ones are pretty slow, but the rest are normal.

Either way, the reason why all of those kinds of devices work out is because they take care of themselves. Although their status is not synced, they are set to open automatically when a player comes nearby and close again automatically when there are no players around. Player positions do sync, so the server and all clients usually agree on the door's position.

Oh yeah right right. WTH am I thinking. :P

So why not make it instead of opening the door manually it opens when you go through the place that you usually click x to open it at and then have it stay open for a while just like regular doors only that you dont open it from next to it?

There's something called a comma, for your information ._.

So why not make it so that instead of opening the door manually, it opens when you go through the place that you usually click x to open it at, and then have it stay open for a while, just like regular doors, except you don't have to be next to it in order to open it.

I'm assuming this is what you meant.

Exactly what is the "place that you usually click x at"?

The thing in the middle of the pic, is where you open the door from.

Because device machines work for a certain area directly in front of them.
Edited by Gamma927 on Feb 1, 2010 at 08:11 PM

Oh ok Ive just never thought of that, so i wondered.

@_@ sounds like its going to be hard to implement the machine and making it sync.

I guess Yoyorast Island V2 gate method is secret as no one has mentioned it yet?

I was going to mention it the other day but You know what, I'm sure other people were already thinking it.