Flatline: Difference between revisions

From OniGalore
Jump to navigation Jump to search
(New page: =Oni Multiplayer\The Flatline Project\NetOni\whatever= ==Player to Player Communication== ===Scores=== Console write, functionality already in Daodan. ===Chat=== Saw a screenshot onc...)
 
m (localized image)
 
(32 intermediate revisions by 4 users not shown)
Line 1: Line 1:
=Oni Multiplayer\The Flatline Project\NetOni\whatever=
{{fmbox
  | text = This project is no longer under development.
  }}


==Player to Player Communication==
{|style="float:right" border=1 cellspacing=0
|[[Image:Flatline logo.png]]
{|cellspacing=3
!colspan="2"|The Development Team
|-
|'''Head Developer:''' ||align="right" |[[User:Gumby|Gumby]]
|-
|'''Resident Coder:''' ||align="right" |  [[User:RossyMiles|RossyMiles]]
|-
|'''Advisors:'''||align="right" |[[User:Geyser|geyser]]
|-
| ||align="right" |[[User:Neo|Neo]]
|-
|align="center" | [[/Dev Diary|Dev Diary]] ||align="left" | [[/Offsets|Offsets]]
|}
|}
The Flatline Project was the second fan-made attempt at Multiplayer for Oni. It combined the knowledge gleaned from projects such as [http://oniplayer.oni2.net/ OniPlayer] and Neo's engine hacking with new techniques of controlling AI characters to create the first working Multiplayer since the early days of Oni's development.


===Scores===
'''Status:'''
Development is halted.


Console write, functionality already in Daodan.
===Chat===
Saw a screenshot once of a hidden chat box, need to figure out if it does anything, chat could either be done through a dmsg or console write (though that would make scores go away…maybe a toggle button or something)
==Internal Communication==
===Player to Server===
*Key bitset
*Mouse X\Y
===Server to Player===
*Bitsets+XY for all other players
*XYZ location
*Rotation
==Dev Mode+Cheats==
Only the server itself would have dev mode enabled. Admins would be able to send commands to the server through chat. All players have cheats disabled. (Enforceable through Daodan etc.)
==Packets==
==Packets==
For now, all packets are UDP, though some of the less time essential packets (messages, commands, etc...) will probably be moved to TCP.
===Structure===
typedef struct {
  char id;
  int  packet_index;
  char data[1080];
} flatline_packet;
*id is an identifier the specific type of packet being sent (message, character sync, initial connection, etc...)
*packet_index is used to protect against duplicate packets. Each packet gets a unique indentifier, if a duplicate is found, the packet is ignored.
*data contains the actual data for the packet, and is typically cast to another struct. The largest struct needed so far is 1080 bytes. In theory, we can go up to 1400 bytes.


'''XXPPPPYYZZZZ…'''
===Connecting===
#Client sends a packet asking to connect to a server
#Server sends a packet back, saying if the client can connect or not, including a string to display if the connection was rejected
#Client either recieves said packet or times out after 15 seconds if no packet is recieved back (sending a new connection request packet every so often before that).
#Server sends basic game info to client, including a packet containing a mock BINACHAR for each player currently connected to the server.


'''XX''' = Sender. If XX=FF then server communication. All others use the server designated player number.
#Client sends packets containing keystrokes and other commands
#Server sends back xyz\animation\whatever data


'''PPPP''' = Destination players. Hex =>Binary etc If player limit was kept at 6, only one byte would be needed. Any more than that requires one more byte. Player => Server communication uses 0000 Server=> All players uses FFFF 
==Maps==


'''YY''' =.Datatype
Probably done through level plugins that use levels 64-127. This has the advantage of being hidden on the level list. These maps would have specialized CHAR\PART\whatever tailored to MP gameplay. Of course a console map change command would need to be implemented.
*01 = Dev console command
(win\lose level, and change current level number, through hex overwriting)
*02 = Keyboard bitset+XY
*03 = XYZ position
*04 = etc.
 
'''ZZZZ…''' = Data used with YY.
 
'''Example:'''
 
FF FFFF 01 646D7367282248656C6C6f20576f726C642229
 
Server is sending to all players to execute the Dev console command “dmsg("Hello World")”
 
==Cycling==
 
===Class Changing===
 
As dev mode is disabled (along with all cheats), we can use the Daodan to detect F8 being pressed, and not worry about the game also using that input.
 
At connection, the server would send a list of available characters. Pressing F8 in game (if allowed by server) sends out a dev mode command to all players to “chr_set_class player nextmodel”. Player being the player name or number, and nextmodel being pulled from the list.
 
===Gun Cycling===


If available (and implemented) gun cycling would work much like the above.


==Maps==
==Lag Compensation==
Quick and dirty lag compensation might come from "fast-forwarding" a frame for every 17 ms of lag or so. ( 17ms = 1 frame...damn that's short :( ) Compensating for rotation\movement differences will be a bit harder, and require a bit more calculation.


Probably done through level plugins that use levels 64-127. This has the advantage of being hidden on the level list. These maps would have specialized CHAR\PART\whatever tailored to MP gameplay. Of course a console map change command would need to be implemented.
[[Category:Modding projects]]
(win\lose level, and change current level number, through hex overwriting)

Latest revision as of 22:26, 7 May 2022

Flatline logo.png
The Development Team
Head Developer: Gumby
Resident Coder: RossyMiles
Advisors: geyser
Neo
Dev Diary Offsets

The Flatline Project was the second fan-made attempt at Multiplayer for Oni. It combined the knowledge gleaned from projects such as OniPlayer and Neo's engine hacking with new techniques of controlling AI characters to create the first working Multiplayer since the early days of Oni's development.

Status: Development is halted.

Packets

For now, all packets are UDP, though some of the less time essential packets (messages, commands, etc...) will probably be moved to TCP.

Structure

typedef struct {
  char id;
  int  packet_index;
  char data[1080];	
} flatline_packet;
  • id is an identifier the specific type of packet being sent (message, character sync, initial connection, etc...)
  • packet_index is used to protect against duplicate packets. Each packet gets a unique indentifier, if a duplicate is found, the packet is ignored.
  • data contains the actual data for the packet, and is typically cast to another struct. The largest struct needed so far is 1080 bytes. In theory, we can go up to 1400 bytes.

Connecting

  1. Client sends a packet asking to connect to a server
  2. Server sends a packet back, saying if the client can connect or not, including a string to display if the connection was rejected
  3. Client either recieves said packet or times out after 15 seconds if no packet is recieved back (sending a new connection request packet every so often before that).
  4. Server sends basic game info to client, including a packet containing a mock BINACHAR for each player currently connected to the server.
  1. Client sends packets containing keystrokes and other commands
  2. Server sends back xyz\animation\whatever data

Maps

Probably done through level plugins that use levels 64-127. This has the advantage of being hidden on the level list. These maps would have specialized CHAR\PART\whatever tailored to MP gameplay. Of course a console map change command would need to be implemented. (win\lose level, and change current level number, through hex overwriting)


Lag Compensation

Quick and dirty lag compensation might come from "fast-forwarding" a frame for every 17 ms of lag or so. ( 17ms = 1 frame...damn that's short :( ) Compensating for rotation\movement differences will be a bit harder, and require a bit more calculation.