Ok, it seems that laruence submitted a patch that now makes the code work in the snapshot version of PHP. So I've got a nightly version of PHP 5.5.0-dev and there is no such issue with the fread function in that version. So I hope we will see this fix in RC2 of the 5.4.0 branch.
I just wanted to say that something is very broken in the repo when used with PHP 5.4.0 RC1. I'm not sure what this is yet, I have fixed two bugs and cleaned up some of the code, but it produces a very strange error when using STDIN.
PHP :: Bug #60309 :: fread(STDIN, 1024) returns instantly.
PHP :: Bug #60309 :: fread(STDIN, 1024) returns instantly.
Last edited by Dygear, .
Reason : Added Bug Report.
If he did, he would be my best friend FOREVER!
We are up to BF3 PC Server R8, the doc is for R3. I hope this still works.
Last edited by Dygear, .
OAuth
LFS.net has a OAuth Provider, allowing you to use your username and password on here to connect to other websites.
Thread on Topic Here:
http://www.lfsforum.net/showthread.php?t=74832
Thread on Topic Here:
http://www.lfsforum.net/showthread.php?t=74832
I've yet to hear anything back from DICE. But I've asked in their Twitter and on the Battlefield 3 forums. With any luck, I will get a response.
C# doesn't have pointers, what the hell? But yeah, you've pretty much made the point I wanted to make with code.
You absolutely should do this. InSim, and the LFS engine handles Clients and Players are two separate but connected objects where one is the parent of the other. Where Client would be the parent object, the Player is handled as it's child object. I've handled this as an array of Player objects within the Client object, but in your case you would want to use the struct within a struct approach. By that I mean the same way that MCI can contain multiple CompCar packets, your Client struct should be able to contain 4 Player Structs. Using a pointer jump table, this make it EXCEPTIONALLY easy, and outstandingly quick to lookup information about both a client and a player.
I do recommend still having a separate struct for the players that you can fill with pointers to client object's player. In so far as Players[PLID] would bring you directly to the player object within one of the client object player ids. Again, this makes for a very fast lookup. Just make sure you clean and clear the pointer on disconnect.
I do recommend still having a separate struct for the players that you can fill with pointers to client object's player. In so far as Players[PLID] would bring you directly to the player object within one of the client object player ids. Again, this makes for a very fast lookup. Just make sure you clean and clear the pointer on disconnect.
From a FiA - FOM stand point, I would want:
Position, Player Name, [Sector Time, Best Speed in Sector][x 1 - 4], Lap Time, Delta to Car Behind.
For a car nut / status nut point of view, I would like to be able to click on a sector time, and see the other times posted by that client over the course of an event. For example. In qualifying, I would like to see WHEN I did my fastest sector, and a history of other sector times that I did. This could take the form of the color of the text changing the display if I set a personal best (Green) or a session best (Purple).
I think that one of the most obvious things would be admin account information to be stored within a MySQL or SQLite database. On the MySQL side, I would use the InnoDB engine as it supports FOREIGN KEY referential-integrity constraints, witch helps to make polymorphic associations possible within the database using a trigger. This become really very important when talking about the actions that admins can perform, and making sure that while you can delete an action that an admin can do from the database, you can't corrupt the database by deleting an admin first, before deleting the actions they can do. So that's a pretty powerful system in and of it's self.
That said, if your looking for maximum capabilities between SQLite and MySQL you could simply use the csv storage engine as that's really what SQLite uses by default. That would make the databases directly compatable with each other, meaning that you could directly build one from the other should something happen to one, but not the other.
Again on the MySQL side, the FEDERATED storage engine could be used to connect to an outside resource, such as your SQLite database to store information remotely from one command. I don't know if they have a proper implementation for this as I can't find and documentation for that fact, but it's an interesting concept to look into.
I think, above all, I would still use InnoDB for the MySQL Side of things, and I think I would use MEMORY on the SQLite local side of things. But I have to ask, why have two database connections in the first place?
--- [ EDIT ] ---
Actually, I'm strongly behind InnoDB. This is particularly important from the stand point of you and I. It stops lesser programmers, or lesser database admins from breaking shit! And that's hugely valuable when your distributing your environment to other people. It's the "No, no, you shouldn't do that." that I would of told to dev if they came to me, but this time, it's being enforce on their machine with the use of FOREIGN KEY referential-integrity constraints.
That said, if your looking for maximum capabilities between SQLite and MySQL you could simply use the csv storage engine as that's really what SQLite uses by default. That would make the databases directly compatable with each other, meaning that you could directly build one from the other should something happen to one, but not the other.
Again on the MySQL side, the FEDERATED storage engine could be used to connect to an outside resource, such as your SQLite database to store information remotely from one command. I don't know if they have a proper implementation for this as I can't find and documentation for that fact, but it's an interesting concept to look into.
I think, above all, I would still use InnoDB for the MySQL Side of things, and I think I would use MEMORY on the SQLite local side of things. But I have to ask, why have two database connections in the first place?
--- [ EDIT ] ---
Actually, I'm strongly behind InnoDB. This is particularly important from the stand point of you and I. It stops lesser programmers, or lesser database admins from breaking shit! And that's hugely valuable when your distributing your environment to other people. It's the "No, no, you shouldn't do that." that I would of told to dev if they came to me, but this time, it's being enforce on their machine with the use of FOREIGN KEY referential-integrity constraints.
Last edited by Dygear, .
We would have to value each node with a time, and then add the time of each nodes between two cars. But this could be highly variable depending on if they are in different cars or not. Also, what would you account for, the lead cars time for each node or the tailing cars time? Do you avg both and add that up?
Anything to works on the TCP/IP or UDP/IP stack will work on with PRISM. We just have to set it up to make sure it understands the packets that are coming in. That's really all there is too it.
Battlefield 3 Support
If I can get a hold of the RCON documentation from DICE, I might add BF3 support to PRISM. From what I have seen, it's going to be much more basic then the current power we have with the LFS packets.
That's interesting, and not intended. At least, I'm pretty sure I did not make a concision decision for it to work that way. Cool that you found a work around for it tho.
Anytime mate, anytime.
The only thing that happens for me is that it tells me to install .NET Framework v4.0.30319.
I really want to do some C++ programming. 
Nice job guys!
Nice job guys!
Yeah, I still do. I have some plugins that need to run with more then just me AI on a server.
It's the only thing I could think of that would coordinate between everyone's timezones.I don't know man. I claim shenanigans, because I have those files as well, it was a part of the Open Beta. That and you need the web interface, that's closed, for any of it to work.
registerPacket callbacks, and registerSayCommands callbacks.
registerPacket callbacks, and registerSayCommands callbacks.
Due to adding support for the OutGuage packet, I'm taking a second pass on how these callbacks are both initiated, and sent to the callback.
$this->registerPacket(callback $callback, packetEnum $Packet, ...);
$this->registerSayCommand(callback $callback, String 'Command', String 'Description');
Where registerPacket would hand back the packet right away, and the hostID it came from looking like this:
And the registerSayCommand would hand back in the same way.
Or do you think that the Say command should have a level of abstraction attached to it?
Oh while I am at it.
Or should I just leave it alone?
Due to adding support for the OutGuage packet, I'm taking a second pass on how these callbacks are both initiated, and sent to the callback.
$this->registerPacket(callback $callback, packetEnum $Packet, ...);
$this->registerSayCommand(callback $callback, String 'Command', String 'Description');
Where registerPacket would hand back the packet right away, and the hostID it came from looking like this:
<?php
function callback(ISP_ISI $ISI, String $HostID)
?>
<?php
function callback(ISP_MSO $MSO, String $HostID)
?>
Oh while I am at it.
<?php
$this->registerPacket('OutGuage', Out::Guage);
public function OutGuage(OutGuage $OG, $HostID)
{
print_r($OG);
}
?>
Your not. I've not made that function yet.
This is for everyone. If you have requests, please make them in PRISM's GitHub Issue Tracker and tag them under Request.
FGED GREDG RDFGDR GSFDG