You might wanna get on Gobby, I don't have time right now but there's enough on there to keep you busy reading anyway 
It's an old PHP based InSim project of mine, fully functional, take whatever you need
It's an old PHP based InSim project of mine, fully functional, take whatever you need
41ms within 100miles is bad and the rest is just utterly useless. What's the bandwidth? You will need quite a bit of upload, especially for high MCI/NLP frequencies.
They do have indicators, therefor they do have indicator relays.
It is a small improvement, but it should eventually be implemented. In the meantime you can just use CSR (like you should anyway, IMO).
It's clearly written on the label at the back, unfortunately the photo is less clear so you'll have to do the actual reading yourself :rolleyes:
I believe it's a radeon X1650 Pro though.
I believe it's a radeon X1650 Pro though.
Nails on a race track? Debris from collisions perhaps; probably what the devs are aiming for anyway.
Not randomly, it only seems to be random because we cannot (yet) comprehend the cause.
That's what I implied with what I said, I was merely pointing out that objects can be hit multiple times, even when they're already moving from a previous collision
You can generate a layout file, save into the server's layout dir and load it via /axload.
As for detecting which object was hit, since we're already tracking positions, we can simply combine AXO and a radius around the flag pole. If two cars were to come close to the flag, the player who triggers the AXO first (it is possible that both players trigger it because it will even trigger when you're hit by an object that's been accelerated by a previous collision) has obtained the flag.
As for detecting which object was hit, since we're already tracking positions, we can simply combine AXO and a radius around the flag pole. If two cars were to come close to the flag, the player who triggers the AXO first (it is possible that both players trigger it because it will even trigger when you're hit by an object that's been accelerated by a previous collision) has obtained the flag.
Even a billion horses wouldn't move it an inch if it had one leg in the air with an open differential
Project Torque / LevelR CTF is a little bit different; there's only one flag and the point is not to bring it to your own base (like traditional CTF) but to hold on to it for as long as possible.
Did you even try to comprehend the error message? Sure doesn't seem like it
rstmin is too large/long, try 300 and if that doesn't work, try less.
rstmin is too large/long, try 300 and if that doesn't work, try less.
Sorry, that should have been NPL.
The second bit (aka bit 1) of the PType in an NPL indicates whether the player is an AI or not.
Most of the mentioned messages (with the exception of the interface stuff) are meant for Scawen only, there is no point in translating them.
The two in the OP will disappear once the AI is completed, "Too many physics objects" and the MAX_ALPHA message (don't know the exact wording off the top of my head) will either be fixed by raising the limits or simply be hidden.
The two in the OP will disappear once the AI is completed, "Too many physics objects" and the MAX_ALPHA message (don't know the exact wording off the top of my head) will either be fixed by raising the limits or simply be hidden.
I see no problem with this. The UCID is session-unique, it will be assigned to a connection when said connection is established and it will remain static until the connection is disconnected. Except for the PName, all information contained in the NCN is also static, so all you have to do with regards to your connections list is listen for CPR and modify the PName upon receiving one.
Now this might be confusing, because CPR stands for Conn Player Rename, yet the CPR packet does not contain a PLID, only a UCID. This is because there can be only one human player and that's the only player of a connection capable of renaming. AIs have to be removed from the race, then renamed, then sent back out again.
So how can I find out who the human is if multiple players for a connection exist? Easy:
NPL.PType & 2What I do is keep a list of PLIDs with every connection, in python via dict which allows me to use the PLID as index and a reference to the player as value, the human player is kept in addition to allow quick access to the player.
This allows me to iterate over the list if I need to do something with all players of a connection, or directly access the human player for whatever I have to do that. An example being aforementioned CPR, which as we established only contains a UCID and no PLID. So what you do when you receive a CPR is you dereference your human player from your connection list and change the name there as well. A bit "wonky", but manageable
When information has to be kept over multiple sessions, the username is indeed the only globally unique identifier to rely on, but that doesn't mean you have to use it within a working session. Upon connecting, the user's data is obtained from the database and assigned to the UCID, much faster than comparing the string every time.
Last edited by morpha, .
Reason : Typo
My suggestion is to request an IS_RIP whenever the STA changes to ISS_GAME. This will either result in an IS_RIP with the (pseudo boolean) MPR member set to 1 (= multiplayer replay), or an Error value of RIP_NOT_REPLAY (= multiplayer game).
Both pics are fake, I only made mine because I felt a fake like that had to be done properly, i.e. with the exact wording, unlike rocklan's attempt.
For the vectors, IMO a template is the most elegant solution in C++:
#include <iostream>
template <class T>
struct Vector3
{
T x;
T y;
T z;
};
int main()
{
Vector3<int> myintvec = {10,20,40};
std::cout << myintvec.x << myintvec.y << myintvec.z << std::endl;
std::cin.get();
}
It is still online, if that's what you were asking for.
There's no fence that could confuse the AF and a lot more light, Xaid0n's Fuji could have performed just as well under the conditions your pigeon shot was made in.
It's there, round her legs
€: Kind of obvious
€: Kind of obvious
Do you want to use it ingame or as basis for an actual skin? For the former, taking the black background away is actually a good thing as it will result in a much smaller file. If you really just need a white skin, a 1x1px (a single pixel) file is actually sufficient. LFSW will upscale this, but there is no need for you to upload a 1024x1024px plain white image.
FGED GREDG RDFGDR GSFDG