The 10 commandments of PC games
The Tech Report has an intresting article about The 10 commandments of PC games. It's ten things that a PC game company should never do. So let's see how LFS fairs shall we?
- Thou shalt not shun thine player's mouse.
LFS get's more then full marks for this one. Using the mouse to control the car's steering, and doing it well at this was a stroke of genius!
- Thou shalt not accelerate mouse input.
And it does not.
- Thou shalt not make a mockery of third-party controllers.
I think LFS has the best 3rd party controller support I've ever seen.
- Thou shalt not mix thine bindings.
No mixed bindeds found, in fact I don't think LFS allow it at all.
- Remember thine user-interface conventions and keep them holy.
Even going so far as to recommend them to InSim devs with buttons.
- Keep thine configurations options exposed.
Top marks for LFS on this one.
- Thou shalt allow players to host dedicated servers.
And LFS does.
- Enough with the save points already!
Not a problem.
- Thou shalt not worship false gaming services.
Not a problem here
- Honor thine modders and mod communities.
This one, needs some discussion.
Kinda like a Time to Live? Interesting.
That does bring up a good point ... Timed buttons. Where a button must only display for some time, the delete it's self. This comes to a point where I must think how to setup the API to allow for buttons to have their own callbacks within plugins, so things like a count down clock could be done easily.
That does bring up a good point ... Timed buttons. Where a button must only display for some time, the delete it's self. This comes to a point where I must think how to setup the API to allow for buttons to have their own callbacks within plugins, so things like a count down clock could be done easily.
Teach a man to fish ... or in this case, read the manual, lol!
Let me know if you find one.
Yeah, but I did forget it, lol.
Yeah, I would need a list of popular ones, and ones that are used by the InSim developers out there. Of the coalition of PRISM Developers (Myself, Victor, GeForz, & T3) we all use Github. But I really can't think of any other InSim project that has multiple programmers working together like on the PRISM project.
You and me both! I did not like CVS and I could never get SVN to work very well. Too complicated. Mercurial and Hg (That filur had me using for a while), never really seem to work as well as Git does.
Should that not be;
<?php
char Z = (char)(MCI.Info[i].Z / 16384);
?>
<?php
byte Z = (byte)(MCI.Info[i].Z / 16384);
?>
No one has made a InSim client / app with Ruby. The programming languages listed are used within the LFS Programming Libs and Tools forum. If some one made a lib, app, client, tool with Ruby I would of added it to the list. You might also notice that the order is not really an order at all. I did that to ensure that no language was unfairly favored because of it's position within the list. The list it's self is in the order that I found them within that Libs & Tools forum.
Yeah, but how many source control management software are out there? I only know of Git, Mercurial, and CVS. Would you also include the web sites that run behind it like github, codeplex, and sourceforge? If you want to do it, or if you want me to do it that's fine, but we should know the scope of the question before we ask it.
I can see it now! Set a cone on each node, set a cone behind the client as he drives around ... Some silly fun can be had here!
It can be any ClickID as long as it's tracked on a per use basis. Named buttons offer a better solution as the name is the key, and the ClickID for each user could be stored as it's value. So when you want to send the same button all users, label it. Within the button handler, it will find the next available ClickID for each client and return it back to the system. This is then saved in an array that will have the buttons label as a first level key. After that, it will cantain an array that will have the Key as the UCID, and the ClickID as it's value. That would look like this ...
<?php
$this->buttonsToAll = array($ButtonLabel => array($UCID => $ClickID);
?>
I'll go with that within the context of the OAuth data, but I would still like to know their license level for other reasons within the game. Not that it's a huge issue when it comes to license levels, but it's nice to know. Whereas DEMO vs Licensed is a must know in some cases.
LFS, OAuth & PRISM.
So, I was talking to T3 the other day on his server about how to secure parts of PRISM. I've come to the conclusion that this can be done correctly only for the web site front end and in game, where a chain or trust already exists. Anything that happens within PRISM regarding passwords can't be considered safe if you don't trust the host that is running PRISM. PRISM is the man in the middle in this case, and that's the nature of the beast. So the only solution is to remove the man in the middle from handling any senstive information that it can't be trusted with. There are 3 aspects where this becomes important.
Regarding demo users vs that of S1 and S2.
There is another argument to be made about the level of trust extended to a DEMO user vs that of a S1 or S2 user. Where a user has unlocked his client to a S1 or S2 level is a authenticated user that can be tracked and handled. Demo users on the other hand don't have this level of trust extended to them as the client's status has no weight or value. The information could be used once and thrown away by each demo user as their accounts are banned from servers.
- In Game.
In game, the client is already authenticated by the LFS master servers. This is not the case with demo races, but a level of trust can be assumed. On S1 and S2 servers the level can be asserted to a slightly greater level as user name and password is required to connect to a S1 or S2 server with the game client. (Ie, the game has to be unlocked with the client's password.) This can not be absolute as there may be a situation where the LFS client can be compromised, and that would also compromise the integrity of PRISM. But really, if the game trusts them, we should trust them too.
- On PRISM's Web Front End.
There is where OAuth comes in. Whereas LFSWorld / LFS.net set it's self up as a OAuth provider. When some one tries to login to the web site front end, they are asked to login using their LFS credentials, but as the username and password is entered on LFS's servers and not PRISM's we can again trust that as long as LFS says that it's ok, then it should be ok for us as well.
- On PRISM's Telnet Client.
This one is the hard one. The telnet client is handled on PRISMs end. We can't use a LFS password for this case as the server operator might change the nature of how PRISM works and instead of sending your password to LFSWorld, it might do that, but also save it plain text in a file some where. This is not an acceptable security risk, so users within say the website front end, or the game would have to setup a password from there. So the chain of trust only extends to the PRISM server host, but it leaves the security of the LFS information intact as it would not use those credentials.
Regarding demo users vs that of S1 and S2.
There is another argument to be made about the level of trust extended to a DEMO user vs that of a S1 or S2 user. Where a user has unlocked his client to a S1 or S2 level is a authenticated user that can be tracked and handled. Demo users on the other hand don't have this level of trust extended to them as the client's status has no weight or value. The information could be used once and thrown away by each demo user as their accounts are banned from servers.
Last edited by Dygear, .
Much thanks to the community around me. This update was really put up together by GeForz, I just made it work within the current system. We have a long way to go, Version 0.4.0, vs Version 1.0.0 ...
It does also help that I'm out of Medic school, and that I've passed all of my exams.
But while some of this is still not over. I have 4 days, where I am to be cleared as a Paramedic at my job, because it's a title upgrade I have to go through some on site training on the Vent and IABP and things like that. So while I'm doing that I hope that you all give the 0.4.0 branch a really good run down on what works well, what does not and what needs to be changed, and what should say the same.
I realized that I did that packet system wrong from a fundamental point of view. Button packets are going to have to sent to the button class, and bypass the plugin system altogether for this to function efficiently. Although, it's not going to look pretty in the core the first time I implement it. I do expect that some other pass-throughs it will get better. That said, I would also refactor some of your code T3, you did a good job, but I have some other more concise ideas for this, although your theory is correct.
Last edited by Dygear, .
Sweet! I might just do that!
This is something that I am really hoping to nail before 0.5.0 of PRISM. But I could use some help!
Is it currently not recommended that anyone use this version that's not very brave. This is not a stable release, but there have been many improvements that GeForz has added in the way of the button interface. This is a experimental test version (as really they all are, but this one more so), and should be used at your own risk only.
Good luck, and good hunting!
Good luck, and good hunting!
PHPInSimMod - PRISM 0.4.0 Discussion
You can download PHPInSimMod - PRISM 0.4.0 from that link. Please use this thread to talk about this release.
Thank you.
PHPInSimMod (PRISM) 0.4.0
Thank you.
PHPInSimMod (PRISM) 0.4.0
- Added a Button handler, that should be used to ensure no button colisions occur.
- Includes Button class, to be used in place of IS_BTN directly.
- Includes Singlton Button Manager.
- Added an implementable callback called 'onButtonRequest' for plugins.
- Includes Button class, to be used in place of IS_BTN directly.
- Changed around the registerSayCommand's callback functions order of args, was done in a pervious version but never documented. Beware!
- Added packet Size default value to IS_CON.
- Added object list to the prism_layoutobject thanks to T3charmy.
- Can now also send IS_AXM packets. But be careful as the Info limit of 30 not enforced at the packet level, it must be done so within the plugin.
- Fixed sent size in IS_HLV & IS_OBH to the CarContOBJ parser.
- Fixed Undefined variable: command in canUserAccessCommand
- Fixed IS_ACR's UNPACK definition, now reads correctly.
- Fixed UNPACK definition of IS_AXM, packet now works as expected when reciving.
- Fixed crash when IS_OBH is sent due to CarContOBJ->Sp3 being set to protected, change to private.
- Fixed Undefined variable in prism_plugins (line 252).
- Fixed IS_PLC's PACK and UNPACK (Thanks Krammeh).
PHPInSimMod (PRISM) 0.4.0
PHPInSimMod (PRISM) 0.4.0
- Added a Button handler, that should be used to ensure no button colisions occur.
- Includes Button class, to be used in place of IS_BTN directly.
- Includes Singlton Button Manager.
- Added an implementable callback called 'onButtonRequest' for plugins.
- Includes Button class, to be used in place of IS_BTN directly.
- Changed around the registerSayCommand's callback functions order of args, was done in a pervious version but never documented. Beware!
- Added packet Size default value to IS_CON.
- Added object list to the prism_layoutobject thanks to T3charmy.
- Can now also send IS_AXM packets. But be careful as the Info limit of 30 not enforced at the packet level, it must be done so within the plugin.
- Fixed sent size in IS_HLV & IS_OBH to the CarContOBJ parser.
- Fixed Undefined variable: command in canUserAccessCommand
- Fixed IS_ACR's UNPACK definition, now reads correctly.
- Fixed UNPACK definition of IS_AXM, packet now works as expected when reciving.
- Fixed crash when IS_OBH is sent due to CarContOBJ->Sp3 being set to protected, change to private.
- Fixed Undefined variable in prism_plugins (line 252).
- Fixed IS_PLC's PACK and UNPACK (Thanks Krammeh).
Spec them, as it's the same as a jump start, and that's how LFS handles it on their grid so it's better to keep consistent.
Using UTF-8 strings natively would of killed Scawen?
No, I'm not home to submit the fix. I'm sitting in my ambulance corps right now.
It was the only packet that I did not check. 
Sorry all.
Sorry all.
.Lol, yeah it was filur. I wonder if I have the source code. I'll see if I can't change it around to use AXM & objects.
FGED GREDG RDFGDR GSFDG