It's really best if you leave PRISM's core alone, everything is programmed in a way for a reason, even the error handler. It's very hard for me to support code that I can't see, and even more so when your reporting bugs in code that is no longer mine because of the modifications that you've made.
As for the Indirect modification error, that's because of somewhere in your code you have modified UName some how. Check your plugins, and I'll need the whole error message next time so I can tell you where it's coming from, hopefully.
Yeah, that's a known bug. Not really sure how I am going to fix that yet. I ask for the connections in the case of PRISM starting while there is already a session in progress and I don't have their information yet. The request is needed so that I can populate their information within the state module. I'll probably check to see if there is a session in progress before I request an NCN packet.
Last edited by Dygear, .
No, although it has been asked for many times.
Oh here we go again. This is why Open Sourcing your code makes sure you get the kudos.
Did you modify PRISM's error handler?
When do you get this error?
When do you get this error?
Just to be sure, we should really make that recursive, but really good catch. I was pretty sure that I used microsecends, so even if you added two timers, it should of given you a unique value for each of them.
Anyway, the fix should look something like this, just added a recursive call to create timer, and the simple recursive call should offset it enough not to bounce into another timer.
<?php
// Registers a callback method.
protected function createTimer($callback, $interval = 1.0, $flags = Timer::CLOSE, $args = array())
{
# This will be the time when this timer is to trigger
$mtime = microtime(TRUE);
$timestamp = $mtime + $interval;
# Check to make sure that another timer with same timestamp doesn't exist
if (isset($this->timers["$timestamp"]))
{
$this->createTimer($callback, $interval, $flags, $args)
}
# Adds our timer to the array.
$this->timers["$timestamp"] = new Timer($this, $callback, $interval, $flags, $args);
}
?>
Like you have shown, there is a time where two or more timers want to execute at the same time, and for that we need a real solution. I think having the current timestamp keyed array is a good solution, but also it's value should be allowed to be an array as well. So if there is a collision with time stamps, then the other timer is simply added to it's array. Something like this is the real solution.
<?php
// Registers a callback method.
protected function createTimer($callback, $interval = 1.0, $flags = Timer::CLOSE, $args = array())
{
# This will be the time when this timer is to trigger
$timestamp = microtime(TRUE) + $interval;
# Adds our timer to the array.
$this->timers["$timestamp"][] = new Timer($this, $callback, $interval, $flags, $args);
}
?>
I pretty much only watch the Superbowls, or some of the local team games if it's on and I have nothing else to do. Other wise, I'm programming or working. I did enjoy the game last night, the team where I live won, so I'm pretty happy and I do get quite into it. Just like I got into watching real football when I lived in England ...
What about just shipping the PTH files with the application? Would that not just solve your second problem out right? Or is it that you want an always available fall back mechanism, should a third part connect to a server they don't own? Like how your using XI4N on the cargame server.
So, going with the calculation of 32 clients on the server and getting closing speed of all of them even just 1 time a second is not really feasible. So that's out of the question. (For those wondering, it's like 26313083700000000000000000000000000 calculations to get the information for every player vs every other player.) I think that, using each MCI cords, finding the number of client's within a 25 meter radius of each player and prioritizing by the group the has the most amount of players in each area. Then from there, you only have to find the closing distances of the players within these radius giving you the a much less to calculate. However, if you find that there is more then say 10 clients in a single 25 meter radius of a single client, then you should just look at that group. Closing distances are not really needed, and would become problematic to calculate. But making that a 'threshold' variable might be a good idea so that you can play with it while you develop it. Doing the same for the radius search would be good too.
So, going with the calculation of 32 clients on the server and getting closing speed of all of them even just 1 time a second is not really feasible. So that's out of the question. (For those wondering, it's like 26313083700000000000000000000000000 calculations to get the information for every player vs every other player.) I think that, using each MCI cords, finding the number of client's within a 25 meter radius of each player and prioritizing by the group the has the most amount of players in each area. Then from there, you only have to find the closing distances of the players within these radius giving you the a much less to calculate. However, if you find that there is more then say 10 clients in a single 25 meter radius of a single client, then you should just look at that group. Closing distances are not really needed, and would become problematic to calculate. But making that a 'threshold' variable might be a good idea so that you can play with it while you develop it. Doing the same for the radius search would be good too.
PRISM can do it with iTunes, but not winamp. If winamp had a COM api, it would of been possible.
It was not. If anything the changes posted where the main points of the update. I don't have anything new but what you can find on the GitHub repo. I've had zero time to do anything with prism since this update, but that's why this is open source. Anyone can take what I've done and continue the work. Thank you for the bug reports, if I get some time, I'll fix to the level you have here and I'll update as needed. I'm pretty sure that I'm not done with the base class for PTH and that's why I've not really done anything with the LVS plugin.
Took a look at the video, how did you get color into the CMD prompt, very jealous that you got this working in such a short amount of time. Keep on rocking on dude!
PRISM is meant to get around those problems by allowing plugins to work as applications. You could write the applications in PRISMs plugins and avoid the whole problem in the first place. But I guess a MetaSim plugin is not a bad idea if for some reason you need to do that as well. Not sure how that would work tho, would have to look at PRISMS networking code to see if it's possible in it's current incarnation. (Pretty sure it would be, it just might be a little awkward.)
And PRISM has always been non-blocking, thanks to Victor's network code (found in PRISM's core and in the modules he made).
I was using a similar idea from AMX Mod and Source Mod with regards to InSim packets. As each InSim packet is an event, making the methods of a class handle these events via defined methods I found to be interesting. Where you could use the method clientConnect for when the IS_NCN packet is sent or clientDisconnect when the IS_CNL packet is sent. Dynamic arguments are not really an option for me in PHP so I would have to give them the packet (and then what's the point of having a high level of abstraction in the first place.) or manually map the method's arguments myself and have to remember to change them when the version number changes, and new functions or the packet structure changes. Ideally, only editing the packet's module should be enough to update everything, but PHP does not allow me to do that. At least Python has that covered for you.
That's unbelievable! Having the option to swap out NodeJS with socket.io to have it run in a browser is just awesome. Must play around with this, possibilities are endless!
I wonder if we can use the HTML5's File-API and JavaScript Typed Arrays to read the data directly from the PTH file.
PTH VERSION 0 - Path files for Live for Speed S2
=============
The nodes are given by a fixed point position (X, Y, Z) and a
floating point direction (X, Y, Z)
The node can be considered as a line perpendicular to its direction.
Outer and driving area left and right limits are given.
TYPES :
=======
1) X,Y,Z int : 32-bit fixed point world coordinates (1 metre = 65536)
X and Y are ground coordinates, Z is up.
2) float : 32 bit floating point number
FILE DESCRIPTION :
==================
num unit offset description
--- ---- ------ -----------
HEADER BLOCK :
6 char 0 LFSPTH : do not read file if no match
1 byte 6 version : 0 - do not read file if > 0
1 byte 7 revision : 0 - do not read file if > 0
1 int 8 num nodes : number
1 int 12 finish line : number
......NODE BLOCKS
NODE BLOCK :
1 int 0 centre X : fp
1 int 4 centre Y : fp
1 int 8 centre Z : fp
1 float 12 dir X : float
1 float 16 dir Y : float
1 float 20 dir Z : float
1 float 24 limit left : outer limit
1 float 28 limit right : outer limit
1 float 32 drive left : road limit
1 float 36 drive right : road limit
Last edited by Dygear, .
Nodes are meant for EXACTLY this case. (Amongst other things.)
I don't really expect this post to go over that well, but I'll give it a shot. For the other members of the community, I respectfully request that you do not use this as a catalysis to start moaning at the devs. I would like a discussion, an open dialog with the dev, not a one sided yelling match. So here is my argument.
With no time frame for new releases, it makes sense to keep the community alive that new content should be released to retain interest and enthusiasm in the project. I thank you for the current work on Live For Speed, the simulator is great and I've not regretted purchasing the for even a minute. It's still by far and away the best sim I've ever raced on even with it's "incorrect" tire model. We all understand that the tire model is not perfect, and that's fine with me.
So why not release the VWS, having some fresh content in this game, even as simple as adding a car would do great things for this community. I understand that Rockingham is S3 content, and that with the new tire model we should get realistic times on that track. But until such a time as the new tire model is available for release, what is the harm in releasing this track. We then get the benefit of seeing how well the new tire model works over the old current model. I also think that releasing Rockingham would be a great a idea, allowing us to purchase an S3 license to use it would also be good for you as it would inject some cash into the project and perhaps give you some incentive to work on the project full time. Then when you have the new tire model you can release that, when you have new cars or tracks you can release them until LFS is done. I have 12 GBP sitting in my account right now. Go on, take it, I know you want too!
With no time frame for new releases, it makes sense to keep the community alive that new content should be released to retain interest and enthusiasm in the project. I thank you for the current work on Live For Speed, the simulator is great and I've not regretted purchasing the for even a minute. It's still by far and away the best sim I've ever raced on even with it's "incorrect" tire model. We all understand that the tire model is not perfect, and that's fine with me.
So why not release the VWS, having some fresh content in this game, even as simple as adding a car would do great things for this community. I understand that Rockingham is S3 content, and that with the new tire model we should get realistic times on that track. But until such a time as the new tire model is available for release, what is the harm in releasing this track. We then get the benefit of seeing how well the new tire model works over the old current model. I also think that releasing Rockingham would be a great a idea, allowing us to purchase an S3 license to use it would also be good for you as it would inject some cash into the project and perhaps give you some incentive to work on the project full time. Then when you have the new tire model you can release that, when you have new cars or tracks you can release them until LFS is done. I have 12 GBP sitting in my account right now. Go on, take it, I know you want too!
Valhalla's Roughnecks Challenges Mud, Sweat and Tears.
I don't think you understand, PRISM has it's own settings that you must change to allow it to get MCI packets. This is because it's up to the InSim application (Such as PRISM) to request these details from the InSim host (In this case, the LFS Server.) To do that you have to change the settings for the host to include the MCI flag. The default value right now is ISF_MSO_COLS (8) & ISF_CON (64), or 72. You have to add ISF_MCI (32) to get MCI packets. This is not explicit, you have to set the flags your self in the hosts.ini file.
The flags settings above will give you the most amount of detail possible right now (2024).
[localhost]
; Host 1 - Your local LFS Server.
; The IP Address we are going to attempt a connection on.
ip = "127.0.0.1"
; The Port we are going to attempt the connection on.
port = 29999
; Optional UDP Port to receive MCI / NLP packets on
; Use 0 to skip this port and receive MCI / NLP via regular TCP
[b]udpPort = 29999[/b]
; Number of MCI or NLP packets to get a second.
[b]pps = 4[/b]
; Set connection flags
; 4 : ISF_LOCAL - guest or single player
; [b]8 : ISF_MSO_COLS - keep colours in MSO text[/b]
; 16 : ISF_NLP - receive NLP packets
; [b]32 : ISF_MCI - receive MCI packets[/b]
; [b]64 : ISF_CON - receive CON packets[/b]
; [b]128 : ISF_OBH - receive OBH packets[/b]
; [b]256 : ISF_HLV - receive HLV packets[/b]
; [b]512 : ISF_AXM_LOAD - receive AXM when loading a layout[/b]
; [b]1024 : ISF_AXM_EDIT - receive AXM when changing objects[/b]
[b]flags = 2024[/b]
; Separate port to listen on for OutGauge packets.
; You must manually edit LFS's cfg.txt to have LFS send OutGauge packets to this port.
; Use 0 to skip this port.
outgaugePort = 0
; Default Password to Attempt
password = "password"
; Socket Connection Type
; 0 - Use Best
; 1 - Use TCP
; 2 - Use UDP
socketType = 2The flags settings above will give you the most amount of detail possible right now (2024).
Last edited by Dygear, .
You have to turn that on in your flag settings. Go to the hosts.ini file, and change the settings as it shows in the first few lines.
- Became a Paramedic.
- Doubled my salary.
- Started a large InSim project called PRISM
- Started a WebSockets project.
- Launched a Volunteer Ambulance Corp website.
- Became a Lieutenant at my Ambulance Corp (Again.)
- Read The Steve Jobs Book, Roberts Rules of Order, the Constitution and By-Laws.
- Became De facto CTO of a community website.
- Became an admin for the TeamSpeak server, also became the webmaster for the community I am a member of.
- Became second in command of the BF3 community Valhalla's Halls
- Got to the rank of Vice-Admiral (Twice) on Star Trek Online.
- Got to the rank of Colonel in Battlefield 3.
- This year ain't over yet!
What version are you running? Where there any errors?
I'll be the first to admit that I don't follow all of the programming standard that is set out in the thread you linked too. Some of the code was made before the standards where settled, so I'm not really sure I could be held accountable for it. As far as verbose variable names, it's really something that people are going to have to swallow. It just makes the code much easier to read then a bunch of one letter variables. Variable name size does not make your compiled program any bigger, so I recommend not worrying about that, and worrying more about if you can read the code a year from now. It's also very helpful to have different classes of thing with the program typed in different ways. One example of this is variables are always preceded with a dolor sign in PHP, $. Functions could then there for use all camelCase, and classes could be CapitalCase, const and defines are always UPPERCASE.
FGED GREDG RDFGDR GSFDG