Technically it's just a physical representation of actual processes going on in my head ([hosted on my home computer, bear with it until I get the new server])
I’ve been working on networking, and I got first networking prototype ready. Right now only psuedo-AI pedestrian synchronizing is working – but it’s working really nicely. I set update rate to about 0.2 seconds (5 packets per second), and it was still really smooth, even when I randomly moved their target (you couldn’t actually see any lag with that, and it corresponds to 200 msec or less ping).
I attached rendering to dedicated server, so you can see what’s going on there. Clients are not yet synchronized, so when they move, they jump around crazily:
The networking is now done via callbacks and messages. You can send a new networked message to specific player like this: Network_Message* Msg = Clients[0]->Connection->NewMessage(); Msg->Start(NETMESSAGE_NEWCLIENT); Msg->SendInt(Clients[0]->PlayerPed); Msg->End();
And on the client side he will receive this callback: void netCallback_NEWCLIENT(Network_Connection* Connection, Network_Message* Msg) { Clients.LocalClient = Msg->ReadInt(); }
It is roughly like that. Networking is going to be thread safe (it’s designed to allow for several threads, but not currently protected against threading collisions yet). If you want networking layer like that, you can freely take the files from OpenGTA2, and change them for your project (they are stored in only two files, network.h and network.cpp).
I’ve been working on the model, and I completed basic structural frame for the cargo bay. It’s one of four sections (not counting nose) in this vehicle.
The sections are forward bay/crew module, mid bay, cargo bay, and aft bay. They are distinct sections held together by links. Also I’m more definite with engine design now – it will use 7 engines of 3 types: 4 turbofan engines, which act as ramjets at high speed (similar to SR-71), 1 scramjet engine, and 2 rocket engines to bring vehicle to orbit.
This is the cargo bay image. It contains of 12 carry-thru frames, which hold vehicle wings (this is not entirely complete, because some sections are slightly different since they are attached to wing spars):
And this is where cargo bay section is located in the vehicle itself (roughly):
I improved pedestrian collisions. There are two major changes – first of all, you can’t come closer than 0.1 units to a building wall (so pedestrians now have size, they are not just points, but more like circles), and second – you never fall through map anymore, the only spots where you can do that are map edge (obviously), and diagonals, collision with which isn’t yet supported.
The collision is segment-versus-map, it traces three segments against map, and checks if they collide. Sort of like this:
I recorded you a video of me walking around, and bumping into walls:
Oh by the way, there’s much less glitches compared to original GTA2 pedestrian movement. I’m going to write a post on how original GTA2 implemented pedestrian movement, and what bugs it had eventually.
I’ve been working on low-level networking transport for OpenGBH, and now it’s complete. Currently it only allows to use TCP as packet transport, and low-level networking only serves purpose of sending raw buffer of data over network. All access to networking is provided via “Network” module, but low-level networking isn’t that.
In OpenGBH low-level networking is presented as structure Network_Connection. This structure contains two primary values: int socketHandle which is socket handle/number, it’s used by sockets library, and struct sockaddr_in peerAddress that holds currently used/binded address.
To create new connection you call bool Network_Connection::Open(char* host, int port), which creates socket and opens connection. If you don’t pass host (pass it as zero) it will just create server connection. In case you pass both parameters as zeroes, it will just initialize internal data structures (for high-level networking), and not connect or start server.
You can send raw data using Network_Connection::Send(void* buf, int size), and receive data from socket using Network_Connection::Recv(void* buf, int size). Internally low-level networking uses WinSock 2.0 under Windows, and I_dunno sockets under linux and other platforms.
That’s pretty much it. I’m now working on high-level networking, which allows sending messages instead of just raw data, and receiving messages via callbacks.
Modelling, as always, by Mick, and I did the texture. It was a quick job, less than hour really. This is the texture (it’s actually not complete, Mick actually forgot canards on the XB-70, so I’m gonna add that, and post again):
I’ve been working on WireOS project. The changes I made over last week include this:
Fixed some bugs in constant value parser. Now it actually parses minus sign in front of expressions. Like this: -(2*2). And I fixed another bug, where it would skip half of expression (actually it was a typo, I had clearly written syntax as level0: level1 + level0, but in code it was level0: level1 + level1. Whatever that means to you.)
Fixed some bugs in assembly syntax parser, now it correctly detects size prefix (32bit float 1234.0). Also it now is a lot better at detecting constant value size and sign (it detects best possible sign and size in bytes for given constant number)
Been working on VM, now it passes all required (for now) tests which concern constant value/opcode decoding, and internal computations. It passess all tests but one, which is compilers fault.
Now in more detail about the required VM tests. Currently it’s just a source file, which must be correctly compiled by given compiler implementation, and correctly executed (provide known output) by the virtual machine. It only uses MOV opcodes, so it doesn’t actually test if those are implemented correctly or no (that’s job for another test). Constant type in these tests means what compiler should pick for constant size, sign, and type. For binary loading sign isn’t important (when operand is written in hex).
It’s not actually related to my primary project of simulating this in X-Plane, but I decided to get some skills in engineering and CAD stuff, so I decided to build a very highly-detailed model of this spacecraft. It’s actually no longer X-30, now it’s completly my own design, based on the previous shape, looking pretty similar, but designed from scratch, and mostly differing in wings.
I started working on internal frame structure, and I got one of frames done (there’s going to be about 50 of them, holding internal structure of main fuselage part). It belongs to position X=3000cm, in a special coordinate system where X=0cm is nose, and X=6850cm is the very tip of the fuselage:
This frame divides two parts of fuselage: equipement bay/extra space I didn’t use yet, and cargo bay itself (in cargo bay structural frames are different, they don’t have “ceiling” so the doors can be placed and opened there). The cockpit is also a separate part, it’s connected to all other fuselage structure.
But then I got ill, and I’m still ill, it’s not that bad and I’m getting better. That’s why no updates lately.
I’ve been working on on-board computer system for X-30, and I did some major changes to it. First of all, there are now more displays corresponding to various systems, but actually there’s more data to be displayed than there are displays present at the moment. Here’s example picture of the cockpit (notice fairly high FPS, the whole simulation and displays do not eat that much FPS):
The other general improvements are the following:
Keypad command entry now works – you can enter commands and change OPS (current major operation mode)
Caution/warning system works – the errors and faults are displayed on FAULT DISP screen, also corresponding light is lit up on annunciator panel. The queue of last three error messages is displayed in lower part of screen. You can clear oldest message from queue by pressing ACK on the numpad
OPS mode 304 displays partially work – they display vertical reentry state during early parts of reentry (above 100,000ft and below 300,000ft)
There is new primary flight display screen (PFD), see below
Internal system data display now displays complete state of computer RAM – and all internal data structures, in full detail. It can be used for advanced debugging, or just for fun.
This is the PFD:
And following displays are currently available:
DISP00 MESSAGE LOG/FAULT DISP – message log, similar to \texttt{FAULT DISP} screen accessed from keypad
DISP01 TIME – time signals from MTU (master timing unit), current timezone, current time, MET
DISP02 INTERNAL SYSTEM DATA – displays all internal system states, variables and data structures
DISP03 ITEM LIST – displays list of all items and their current values
DISP05 ELECTRIC BUS VOLTAGES -electric voltages on all buses, electric load in kilowatts
DISP06 PAYLOAD ELECTRIC BUS – payload electric voltages and electric load, specific payload-dependant data
DISP08 HYDRAULIC SYSTEM – hydraulic system pressures, fluid quantities, hydraulic pump information
DISP09 FLIGHT CONTROL SYSTEM – flight surface command and current position, artiftical stability information
DISP10 REACTION CONTROL SYSTEM – flight surface command and current position, artiftical stability information
DISP11 HYDRAULIC SERVOVALVES – position and command for all hydraulic servovalves, command line states, servo temperatures
DISP12 NAVIGATION – current position, distance and course to target airport, estimated time to arrival, etc
DISP13 ORIENTATION/RGA – spacecraft rotation and angles, alpha and beta angles, angular accelerations
DISP14 LOCATION – spacecraft location in space (GPS-based, inertial-nav based, atmosphere-based)
DISP18 ATMOSPHERE DATA – pressures and computed data from air probes
DISP19 INERTIAL DATA – position and accelerations from inertial navigation system
DISP20 GPS DATA – information about GPS satellites, and current GPS position
