if tim can connect to irc, and i can recieve stuff from irc, we already have the means of what we're talking about here dont we? we just have to make each client send the apropriate data automatically, instead of typing it in.
assuming lua can make actors walk/jet somewhere currently.

pretty sure that the Lua bindings necessary for the hacks in question do not exist

You'd also have to figure out some way to make the IRC protocol support instantly transferring a few dozen messages per second. Good luck with that.

barely a few dozen unless firing.
and cant you change the flood limit? idk i dont use irc much.

Oh my gosh, all you haters need to shut up

With LUa this is fully possible. Easy? No, but completely possible.

Remember dark messiah of might and magic? Using LUa and the exact same idea the OP talked about, people manged to hack multiplayer into the demo

Stop with the idiotic ranting about how you're an obvious God of coding because you learned how to ♥♥♥♥ around with the absurdly basic code structure that was used before LUa was added.

CC is totally a source-engine game. Hey, source engine has multiplayer built in already. Hey, dark messiah of might and magic is a source engine game. Hey, that's such a coincidence!

Multiplayer for CC would require looping through EVERYTHING in the host game and sending that data over luasocket to the connector, then parsing that and making EVERYTHING in the same position and type.

It really doesn't sound all that hard, besides for getting luasocket to send the data. To me it sounds like it would lag horribly, though.

dont need everything. bounce always happens the same way, at least in the last two builds it has.
drop a grenade, from any hight that wont blow it up, onto concrete. wait for it to stop bouncing around. now, drop another grenade from the same place. it follows exactly the same path.
only things you'll need to send are random numbers for anything that uses them (guns, splosions etc) and what the player is doing. if you get desync, who cares, it wont be too big. and itll be your internet/computer's fault. if it gets too bad restart the game, it should take quite a while for it to get noticeable unless you're using raping weapons. which you wont be if youre using vanilla content.

Specifics like that would take work. And I'm not saying send the calculation. I am saying send the position that everything is at on the host. That's the only way I can see this working at all.

Geti:
You need to understand that Cortex Command is a game which uses a physics engine. The grenade example that you keep giving uses the physics engine. Of course, given a certain set of starting conditions, you will get the same result consistently as long as you keep repeating an experiment under those conditions. While it is easy for one computer to tell the physics engine "Ok, so there's a guy at some position in an X,Y grid, and he throws an HDExplosive at such and such velocity at such and such angle, which has the characteristics of mass of X, bounce of Y, etc. Tell me where that grenade goes." But people tend to forget that the Internet is severely much slower than a processor, which has nearly instantaneous access to data being processed, for most people.

Now, take this in terms of computer science, so I can quantify what I'm talking about here.
1.6 GHz, for example, is 1.6 * 10^9 cycles per second (Hertz), or 1,600,000,000 cycles a second.

That means that a computer can flip 1,600,000,000 bits (1/8 of a byte, which is the basic unit of storage in a computer) a second, from 1 to 0 or 0 to 1.

Conversely, modern Internet connections are usually measured in Kb/s or Kilobytes per second, averaging around 300 Kb/s on a good connection and maybe 800 Kb/s- 1000 Kb/s on a really good connection. This means the computer can change around 1000 Kb (1,000,000 bytes) of data from 0 to 1 or 1 to 0 per second on an excellent connection. This is about 1/1000 of the amount of data a 1.6 GHz processor can change per second.

My computer, which does have a 1.6 GHz processor in it, lags when playing Cortex Command on occasion. Thus, being able to flip 1,600,000,000 bits per second, is not sufficient enough to run Cortex Command at a good knock. If my computer has to dedicate even a small part of that to tell another computer what's going on in my game, I will lag horribly. And my machine is fairly modern, being made only 1 year ago. This is not even factoring in the fact that most computers are lucky to get a 200 Kb/s upload speed on urban connections, 1/20,000th of the speed of my processor. Things are going to get slow as molasses.

This is not even factoring in the amount of data that we would have to send over a connection. Consider this: the modern FPS has lags of 150 ms to be anywhere near acceptable. FPSs send significantly less data than Cortex Command is sure to do. But you might claim: "What about Day of Defeat: Source, or any other source game for that matter, such as Garry's Mod. They do physics just fine!" I'm not 100% sure how Cortex Command's physics engine works, but I know it's a heck of a lot more work than simulating 50 objects (the point at which my computer lags, though it may be because of my GPU) in Garry's Mod. Garry's Mod does well usually because it is simulating very few physics objects, in comparison to Cortex Command. You probably will have 200-400 physics objects (extremely overestimating, btw) on your average server after players get going, while in Cortex Command, you likely have millions.

FPSs send some information about you, the client. Take Counter-Strike. Really, the only thing that a client of a Counter-Strike server sends is whether or not you're performing a certain action, such as firing or moving or jumping. If a server detects that you want to move, it says, "Ok, I want you (the client software) to show that the player is at position X,Y,Z, and that he is aiming in vector A,B,C." The client does all this and the process repeats, creating the appearance of your character moving, shooting, and other things until you disconnect . In reality the client computer is basically a televison screen: it only displays the results, it is the host (or in the television metaphor, the DVD player) who does all the work.

I have gathered that Cortex Command is significantly more complex than, say, Worms. Worms weapons are simple: If I hit something, create/destroy a spot of dirt or terrain which has the dimensions X. That's why the "physics" of Worms can be so easily replicated. Cortex Command's dirt is constantly checking to see: "Have I been hit? Have I been hit?" If it finds out it has been hit, it tells the physics engine: "Ok, I've been hit by a projectile traveling at speed X from direction Y. It has a mass of Z, bounciness of A, etc. How do I react?" I'm fairly certain that ALL Cortex Command objects do this. Imagine trying to send all the information back to a client. The physics engine will look at every step, saying "Ok, Dirt Particle 1, you move 5 pixels down, Dirt Particle 2, 5 pixels down, 2 left, Dirt Particle 3, 4 pixels down, 3 left..." and so on, for EVERY SINGLE OBJECT in the game. It would take massive amounts of bandwidth, and a processor of immense power to even get close to creating a bearable game for 2, let alone 4, players. And even if we were to offload some of the processing onto the client, the entropy of Cortex Command is so large that you would need to send a great amount of data anyway to get the game looking the same

This is why Cortex Command will most likely not be a multiplayer-over-Internet game in present times. In the (near?) future, when we do have the capability to send such amounts of data over the Internet and the processors to support it, it may be feasible.

A lot of this opinion is speculation on my part, by the way, so if I have made some error in my description of how modern games send data over the Internet, what data games send over the Internet, or in the basic computer theory section, please let me know.


wtl;dr: Cortex Command has a freaking complex system of calculations and is not a feasible true Internet multiplayer game in present times. End of story.


This is not to say that we can't make some sort of multiplayer interaction, such as making a Lua script which enables people to control the "AI Brain", allowing them to send wave after wave of attackers in some sort of "Tower Defense" type game. That's very doable. The only things you would have to send back and forth in that situation would possibly include: HP of soliders, HP of enemy brain, and the activity of the player's soliders (with the ability to change it of course). That is "multiplayer-over-Internet" in a sense and would be fun if we could get an occasional TestDump of our progress.

Holy crap. I'm convinced. Just reinforces viewtopic.php?f=4&t=10846

I figured it was only a matter of time until someone posted the long, drawn-out explanation of why internet play won't work at this time.

Thanks Tim.

Wat? Tim? L2read? That was CherryT.

Man, I take topics from linear discussions to line segments.

rebuttal:

this is precisely what i am talking about with the grenade example. you dont have to send the details for every object moving in the game, just what is causing what to happen. in your CounterStrike example, you talk about having each person in the server only having to transmit their whereabouts, aiming, and cirtain actions/states (ammo levels, reloading, jumping, shooting etc.) and this makes it plausible to send over the internet. the host just draws a ray when someone shoots, and kills/hurts whoever is on the other end.
essentially, this is do-able in CC aswell. you only need to have player whereabouts, weather theyre shooting, jetting, whatever, and ammo/jet levels + their inventory. when someone shoots, if you can control the random number that makes the particle shoot at its angle and velocity, then you can use the clients physics for terrain/damage calculations.
at most the variables you would need to be constantly sending would be

and whenever a bullet was shot by any weapon, including those shot by AI controlled actors

NB the same code could be given to any gibs aswell as TDExplosive particles, to prevent desync there.

all of this could be applied to an NPC (for actors) or the fired bullet/gib/particle in the clients/hosts game, and with low latency nothing would go wrong. if something died in anyones game that could be sent, to prevent a serious desync error. inventories could be updated as they changed, which would prevent lag aswell by not always sending the player's inventory, and each 10 seconds a player position check could occur, checking the position of all actors in each players team and syncronising them, also to prevent desync [could be done by averaging positions or just taking the owner's variable]
that would minimise errors due to lag and mean you wouldnt have to send the data from every ♥♥♥♥ MO in the game, and each packet could be pretty small, and easily sendable in ~realtime. think about it, if you went all out on the player and bullet variables and made it so it contained all the atom code aswell, each packet would still be less than 1kB.
you dont even need to send mass or whatever, thats in base.rte
esentially what we're talking about here is not sending half a sim to someone else. we're talking about making an NPC in their game mimic what we do in ours.
if you were going to send all the data for the MOs you may aswell be sending the sim. the physics arent that random, so you dont need to send all the data.
thanks for reading.

tl;dr: touche, but its still possible. and besides, any source game would be a stupid example for me to bring up, as its made for multiplayer anyway.

Yeah no you'd have to send any active particles as most of them run off random numbers.

Which is still no problem and that INTERNETS R TOO SLOW explanation is bull♥♥♥♥ as always. There are other games that have done the same particle physics as CC multiplayer. CC just has a few more.

Which is why I said it would be horribly laggy over Lua. Data needs to do it.



Also-

Wow Venn. You're such a tool.