Let's do this. (Open Sauce//Separate app[?])

[legionaire45]

The vehicle idea is the only non retarded idea in this thread, Even then, i'm sure it's going to have its problems. The only good way it can be attempted is if people stop being secretive and communicate (9mm and Skyline and IGM mainly)

Wrong.

The only good way it can be attempted is if someone or a group of someones can get people from outside of this arrogant community. People who don't have any priorities like work or school.

Everyone who has enough C/C++ experience who is involved in this community is either busy on other projects or they are dealing with their own things (like school or work).

It's not like there are only 3 programmers on the planet who have enough C/C++ experience to play around with this stuff and actually have a clue as to what is going on.

[Kornman00]

One issue is due to determinism. Another part to that issue is how Halo was engineered for LAN use, not for use across the internet. The way Halo on the Xbox worked was with a networked lock-step approach, which works fine because it was designed for use over a small, reliable local network.

Playing across the internet is not the same, at all. You suffer from constant latency and packet loss issues, even if you're playing with just your neighbor. There is no luxury of a single switch handle the communication between four boxes who are probably within about 50 ft of each other.

When Halo PC was developed, they engineered another component into the networking system for keeping objects and other state specific data in sync. Xbox didn't use data packets for things such as object creation, deletion etc because it was assumed to be in lock-step with the rest of the machines. This new PC system also allowed them to let players drop in and out of games.

Even if you could target and fix any and all non-deterministic game elements (hello custom scripts), you still have to handle keeping clients in sync and up to date even when there are latency issues or packet loss. If a client falls out of lock-step synchronization (ie, due to a missed packet), then they are no longer valid. If their state can't be properly updated (by a delta message, etc) then they and any one else in the party can't continue to run the game (thus, you can't just drop in and out of a campaign game).

It's not about sending more packets with more data (really, that is just adding to the problem, especially since your computer is suspect to be sending out other network traffic, ie if you have a chat program open). Halo 3 doesn't work that way, it's not sending out information in packets which say 'ok, brute A decided to move to firing point 32'. Halo 3 falls back on the lock-step approach like that of Halo 1, which is why things which in MP cases wouldn't normally cause the game to end due to state conflicts, will cause the game to end in campaign due to failed states.


This is no easy problem to solve, even with the source.

[Limited]

The vehicle idea is the only non retarded idea in this thread, Even then, i'm sure it's going to have its problems. The only good way it can be attempted is if people stop being secretive and communicate (9mm and Skyline and IGM mainly)

The reason we keep things secret is because if they don't fully work, we can drop them and nothing happens, we don't want to give people false hope.

There's probably 5 coders that look into OS stuff that is actually competent with it. We don't ask korn because we don't want to pester him. We all talk though minus firesythe who is never on lol.

[FireScythe]

I did have an idea for multiplayer bots, whereby the server adds fake players and controls them with AI (probably custom built), so that clients are none the wiser, but without even researching this it's obvious the sheer amount of work to get even something basic makes its not feasible/worth the effort.

We all talk though minus firesythe who is never on lol.

:O Am too, I AIM frequently.

[Inferno]

I did have an idea for multiplayer bots, whereby the server adds fake players and controls them with AI (probably custom built), so that clients are none the wiser, but without even researching this it's obvious the sheer amount of work to get even something basic makes its not feasible/worth the effort.

:O Am too, I AIM frequently.

I'd script working MP bots with pathing and shit if someone where to code them to show up as players.

[Dwood]

Oooh scythe thats a good one... I know this
is a massive stretch but how could we add more than 16 players? (not human but ai)

Btw korn there was another idea to use the maps hash as the seed for all ai's 'random' actions. Then the biggest problems would occur when a player joins the game. If we used c lets assume minimal packet loss. (eg lan)

When i get back on my main computer I will research how the original AvP games got ai to sync and report back.

[malolo420]

I found a way to take away the second biped, set the ai to spawn outside of the map and teleport them with a command list to where you want it to spawn. Then script it so once there spawned to delete all the objects on the map then recreate them and make sure the will spawn only once more then when the script deletes all the objects on the map it will delete the second biped and when it respawns the second biped wont be there. I can't remember if you can do an ai_erase_all because I think if that worked for it I wouldn't have made my old map delete everything. Then I just changed the biped tags so the AI's running speed is 0. They don't move but atleast clients can kill them and theres no invincible biped. Its a pain in the ass, but Its easiest way that I found.

[Epsilon927]

The vehicle idea is the only non retarded idea in this thread, Even then, i'm sure it's going to have its problems. The only good way it can be attempted is if people stop being secretive and communicate (9mm and Skyline and IGM mainly)

I spent some time experimenting with vehicles, and bipeds, because both technically should sync. I did an experiment where I attached a biped to an AI encounter, and every few seconds or so, I would attach it to a vehicle that was defined in the globals, save the information about the biped, (EG health and shields), detach and then delete the biped. I would then create a new biped, set it's health and shields to the previous biped's, attach it to the vehicle, detach the vehicle, and teleport the vehicle elsewhere. The problem with this, is that instead of the vehicle keeping the AI in sync, the vehicle itself dropped out of sync, similar to how players dropped out of sync in Kirby's player - AI fusion experiment. With this method, the AI didn't really sync the position, but at least there were no duplicates of the AI.

[Kornman00]

Multiplayer games use the same random seed, so generating a new seed won't help anything. It's the issue of deterministic code. You'd have to make the AI code be completely deterministic (good luck with that when you don't have the source). Possibly even a few other campaign related engine components.

Attaching a vehicle to an AI unit will do NOTHING to that AI in terms of syncing, that AI's unit doesn't depend on that other unit which is attached to it. Yes, vehicles and bipeds have network delta messages to keep the clients in sync. However those messages are JUST for those actual unit objects and nothing else.

If you can't grasp the issues involved (read: the problem), then you really shouldn't be trying to figure out a solution.

[=sw=warlord]

I know im rather uninformed on how the game is engineered and all but there is something i was wondering for some time.
Is there a control in the games code stopping different varients of the same map being used in servers and if not would it be possible to have serside maps holding the ai and client side having just lifeless bipeds and then script the server side ai to attatch to the lifeless bipeds?
I mean instead of having the ai spawn as normal attach the server side actor varient's to the client side bipeds.
Im just throwing this idea out there as it's something i've always been curious about but never had a chance to test out for myself.