There was a thread recently regarding improving the LFS wiki, and I personally have thought a lot in the past about how the programming section could be improved. My basic idea is that the LFS wiki should contain the full API documentation for the InSim protocol, as written by the programmers who use it every day. Many of us have an encyclopedia knowledge of InSim which has been learned through years of toiling away on esoteric pieces of code, and it frustrates me that all this knowledge and experience is not documented anywhere within the community.

My improvements to the wiki would include:

• Separate page on each InSim packet, explaining what each packet does, how it should be used, and with tips and tricks on how to use it effectively
  
• Introductory page with examples of creating an InSim connection in many languages (C, C#, Java, Python, VB etc..)
  
• Pages on how to pack and unpack packet data into binary formatted string in many languages (see above)
  
• Page on each of the popular InSim libraries, with examples and download information.
  
• Any other cool ideas people have.
  

A good example of a similar wiki would be wowwiki, which contains user-edited pages regarding every function and event in the huge World of Warcraft API. That being said, I think we could do a better job than they do, as InSim is smaller than WoW and our community is only a fraction as retarded.

Obviously this is not a task which can completed by any one man, so some aid from the whole programming community would be necessary. I myself can contribute pages on C#, Python and pyinsim, and also begin to contribute to the complete packet documentation. I felt however it would be a good idea to gauge the feelings of the community in general, before I started mercilessly culling stuff. Whether you like my idea of a complete InSim reference or not, I think you must agree that the current programming wiki is confused, limited and outdated, and that much could be done to improve it.

Thanks

Sounds like a great idea

Quote from jasonmatthews :

Sounds like a great idea

It dont sounds like a great idea it IS a great idea

I agree it's a great idea. When I first started out trying to use the protocol I didn't find there was a lot of information available, so it was very difficult to make any real progress. With better documentation it should make things a lot easier to make better programs more quickly. I'd be willing to help out with Java and the JInSim library.

Count with me. Now I have very fresh all that I'm learning, and I have a good PoV about what is the first wall that the people see when start to make insim programs.

I've playing WoW for 4 years, and I've make some addons... of course, the documentation al wowwiki it's exceptional, and there is too many addons that make you life better. And, of course, the libs than make a lot of things for you.

This is what LFS need, to customize each server, to allow peaple to be different from others, think in mirc, as well as wow...

For this all of this, count with me to help in this ^^

At the moment I'm thinking something like the following for the categories of the section. This is just rough and off the top of my head.

One thing is that Hosting shouldn't be lumped in with programming, they are different topics and no more related to each other than any other topic.

As usual DarkTimes, great thought and I commend your efforts so far May I offer one line from Field of Dreams - "build it and they will come".

Quote from DarkTimes :

One thing is that Hosting shouldn't be lumped in with programming, they are different topics and no more related to each other than any other topic.

I believe that the general thinking was to split up the non-racing and racing content as much as possible. However I can't see a reason not to split it all up further. After all - it's a wiki and restructing is simple

If I start seeing stuff change I'll happily join in and transfer any remaining notes that I have into the manual as and when I can.

The structure is fairly logical, although I'd be hestitant to split up the packets per page as there simply isn't a lot of stuff to be written about each. Perhaps a logical grouping might be more relevant. It would certainly be easier to grok the API quickly and then link problematic areas to their own, more in depth, page.

Quote from the_angry_angel :

May I offer one line from Field of Dreams - "build it and they will come".

Yes, that's the plan. I will start building it, it's just finding the time to do it. I want to do the majority of the ground work in a single sitting and then people can flesh it out and add to it later. It will be sometime this week.

I've made a start. Obviously it's still rough around the edges and needs hugely fleshed out and improved. I've done a basic introduction page and also a page on InSim, as well as setting out some stubs for the other pages. I will work more on it later.

On the subject of the insim packets reference, do you have any objection to a single sentence, plain english, description for each? I know from my point of view it would've been seriously helpful in the past.

For instance, I was thinking about something like this:

OK I have changed it to a table with three columns, for packet, description and type. Type indicates if the packet is an instruction (can be sent to LFS), information (only received), or both (both). The format could be cleaned up a bit (making tables in the Wiki is hard) and any detail in the descriptions comes from my own memory, so might be wrong.

Quote from the_angry_angel :

As usual DarkTimes, great thought and I commend your efforts so far May I offer one line from Field of Dreams - "build it and they will come".

Absolutely, I will help out if given an outline. I've be giving examples of packet parsing with PHP (if any one wishes to help, or even improve my own code examples, by all means please do!)

Quote from the_angry_angel :

The structure is fairly logical, although I'd be hestitant to split up the packets per page as there simply isn't a lot of stuff to be written about each. Perhaps a logical grouping might be more relevant. It would certainly be easier to grok the API quickly and then link problematic areas to their own, more in depth, page.

I'm going to disagree with you there TAA, I think there are volumes that can be written on each packet simply because of the many ways in that we can interpret this information. Some one doing a example for packet parsing in C# is going to do it very differently from that of Python, then that of PHP. While each page will be exclusive to each packet that is not necessarily a bad thing, especially when your only having an issue parsing a hand full of packets. And I don't fell it would also be correct to group packets explicitly, but rather implicitly at the footer of the page due to the nature of the InSim packet flow.

My one question is, what is the programming guide line for posting these examples for each packet?
Does it simply have to return the parsed packet, or does it use a more pseudo code style?
(That reminds me, I've not read any Coding Horror posts in like a year!)

I would suggest that you sould add examples of parsing packets with PHP on the InSim examples page. I have done some rough Python and C# examples, but they could be greatly improved. Still it's a start. My general feeling is not to post an example for each packet, unless there are some specific hoops you need to jump through to get it working in a specific language. Each packet is basically the same, so a few general examples of parsing packets should be enough to get most people going. In my experience learning how to deal with things like the TCP receive buffer is actually a more complicated subject to get your head around than unpacking packets, which is generally pretty easy in most high-level languages. That being said the more information you can add the better, so feel free to do what you like.

Not had much time to work on the manual over the last few days, but I'll try to do some more soon. Oh and if you like Jeff Attwood you should listen to the Stackoverflow Podcast. I think Joel Spolsky is hysterical.

Imma let you finish, but first I'm gonna bump this thread. I made a start on rewriting the Wiki a couple of years ago, but we still need people to add and edit pages. I've updated some stuff for LFS 0.6B, but a lot remains incomplete. The Wiki rewrite was predicated on the idea that 'if you build it they will come', however very few people have come yet.

The great thing about the Wiki is that it canonises our knowledge in a single place, and makes it much easier for new programmers to get up and running quickly. Back when I first located InSim.txt I had no idea what any of it meant and I had to work out how to write InSim apps myself by trial and error. It would be great if there was a comprehensive resource available that would prevent people from having to go through the same pain that I did.

So if you are an InSim programmer with a passing knowledge of how all this stuff works, it would be cool if you could edit or even add a page.

Pain is needed because we have to avoid billions of question from noobs that are trying to do cruise server with one code line (it's possible - but it's not the point of topic).

Quote from DarkTimes :

So if you are an InSim programmer with a passing knowledge of how all this stuff works, it would be cool if you could edit or even add a page.

The problem with that is, in PHP, there is no wrong way to make an InSim application. I feel that PRISMs code is pretty good, but I don't know if I would use it to teach people. I don't think new people find objects very easy to use, while it might be the most concise way, I don't feel it's conducive to learning how to program from the outset. I would first have to teach them the OO model.

I'll have to look at your code, for pyInSim, and the examples you put up to see how I should translate it across so that it allows for people to understand it. Also, I made a HTML version of the InSim.h file, that Scawen gave out in the document directory. The file links to definitions of it's self so you know where one variable came from. If we can do something like this with the Wiki I think it would stop a ton of the questions also.

Belive me, PHP OOP is easy to use (code like prism). Full OOP is hard to learn, but PRISM is coded good, functions are English-like-lang so it's no problem to make InSim without any knowledge.

It's not about OOP, or any one technology, it's just about sharing the knowledge. It's also not about teaching people to program. All I'm suggesting is that people read the programming section on the wiki and edit anything they feel is appropriate.

Quote from misiek08 :

functions are English-like-lang so it's no problem to make InSim without any knowledge.

That was by design. We avoid abbreviations so it's very clear as to what we are doing with that function. Any abbreviations that we do use ... for Example UCID, PLID, or things like that, is from the InSim.h file, so that it's consistent.

Quote from DarkTimes :

It's not about OOP, or any one technology, it's just about sharing the knowledge. It's also not about teaching people to program. All I'm suggesting is that people read the programming section on the wiki and edit anything they feel is appropriate.

I just want to make sure my examples for PHP are functional. So that people can use them.