Oops, just found this. (Should have googled first, then posted) nevermind:

Quote from Chris Demorro @ The Recorder Online :

Building a Toyota Prius causes more environmental damage than a Hummer that is on the road for three times longer than a Prius. As already noted, the Prius is partly driven by a battery which contains nickel. The nickel is mined and smelted at a plant in Sudbury, Ontario.

This plant has caused so much environmental damage to the surrounding environment that NASA has used the ‘dead zone’ around the plant to test moon rovers. The area around the plant is devoid of any life for miles.

The plant is the source of all the nickel found in a Prius’ battery and Toyota purchases 1,000 tons annually. Dubbed the Superstack, the plague-factory has spread sulfur dioxide across northern Ontario, becoming every environmentalist’s nightmare.

“The acid rain around Sudbury was so bad it destroyed all the plants and the soil slid down off the hillside,” said Canadian Greenpeace energy-coordinator David Martin during an interview with Mail, a British-based newspaper.

All of this would be bad enough in and of itself; however, the journey to make a hybrid doesn’t end there. The nickel produced by this disastrous plant is shipped via massive container ship to the largest nickel refinery in Europe. From there, the nickel hops over to China to produce ‘nickel foam.’ From there, it goes to Japan. Finally, the completed batteries are shipped to the United States, finalizing the around-the-world trip required to produce a single Prius battery. Are these not sounding less and less like environmentally sound cars and more like a farce?

Wait, I haven’t even got to the best part yet.

When you pool together all the combined energy it takes to drive and build a Toyota Prius, the flagship car of energy fanatics, it takes almost 50 percent more energy than a Hummer - the Prius’s arch nemesis.

Through a study by CNW Marketing called “Dust to Dust,” the total combined energy is taken from all the electrical, fuel, transportation, materials (metal, plastic, etc) and hundreds of other factors over the expected lifetime of a vehicle. The Prius costs an average of $3.25 per mile driven over a lifetime of 100,000 miles - the expected lifespan of the Hybrid.

The Hummer, on the other hand, costs a more fiscal $1.95 per mile to put on the road over an expected lifetime of 300,000 miles. That means the Hummer will last three times longer than a Prius and use less combined energy doing it.

So, if you are really an environmentalist - ditch the Prius. Instead, buy one of the most economical cars available - a Toyota Scion xB. The Scion only costs a paltry $0.48 per mile to put on the road. If you are still obsessed over gas mileage - buy a Chevy Aveo and fix that lead foot.

One last fun fact for you: it takes five years to offset the premium price of a Prius. Meaning, you have to wait 60 months to save any money over a non-hybrid car because of lower gas expenses.

Source here.

Who knows?!

Tim

Unless the engineering process and destruction process for the Prius is majorly different to that of a "normal" car, then the fact the the Prius gives out a fraction of the emmisions of the "normal" car, then it must gain something. Even though in the bigger picture this is not as much as if you just take the emissions of the car running into account.

Plus, how do we know that something else the Prius is doing (emmitting, causing, anything really) is not damaging something else that we have not measured or even know about yet. If we all moved NOW to a Prius, we may find that all those hybrid cars cause something else to break somewhere in the environment. (I don't know what, but you know what I mean).

Tim

Quote from Stigpt :

Sorry for being an ass, but.. I don't see the point of the Prius.

It is not all about the MPG, it is about the emmisions; the harmful gasses to the environment and atmosphere. It does have a "normal" mpg, but:

Quote from Toyota :

Prius is certified as an Advanced Technology Partial Zero Emission Vehicle (AT-PZEV), [6] a standard created by the California Air Resources Board and adopted by other states. [6] AT-PZEV certification means Prius has near-zero tailpipe emissions, zero evaporative emissions and a special extended warranty on emission control components. [6], [7] It is one step cleaner than the previous generation's Super Ultra Low Emission Vehicle (SULEV) certification.

The source is here (Note: The links above only work from the actual site).

Tim

Also remember, that LFS can send more than 1 LFS packet in an actual packet. For example, you may receive 40 bytes, but byte(0) = 20. This means the rest of the packet is another (or more) seperate LFS packet (or packets), so byte(20) could = 4 and those 4 bytes are and IS_TINY for something else.

There is also the really horrid version where you don't get enough data in the actual packet. I have had this 3 times in all the time I have been playing with InSim v4 and I have yet to write the code to deal with it.

Basically, you would get 13 bytes actual, and byte(0) = 20. This means you have to wait for the next receive event to fire and add the first 7 bytes onto the end of the last set of bytes, and then deal with the next lot.

I haven't worked out yet where I want to save the first lot and I haven't yet worked out how to test it. As I say, it has happened to me 3 times now so I know it is possible, but I program by trial and error and with it only happening every so often, debugging and getting it working would take ages. So I haven't bothered yet. But I will..... soon...

Tim

No, the very first byte is the length of the LFS packet and the second is the LFS packet type.

So if you receive (physically) 20 bytes, and byte(0) = 20, then you know you have the full packet. Then you check byte(1) to see what type of LFS packet it is. In this case it should be 2 as that equals ISP_VER.

Edit: also remember LFS is sending you (and expecting from you) bytes, so an integer is broken down into 4 bytes which you have to convert to a type that VB knows how to deal with. Characters are easy because they are just 1 byte anyway and that corresponds to their ASCII value. ie 97 = a. This is why working with a string is not the best way, but it does work in places.

Tim

Last edited by t1ger, Thu 4 Oct 2007, 12:41.

Is that in your _DataArrival sub?

If it is, then I don't think you are best working with the bytes in a string like that. This is my DataArrival routine:


The checkdatain routine checks to make sure the right number of bytes has been received and if not splits it up into "LFS packets" or saves it and waits for more to be recieved. That last bit of code I posted is part of a "processpacket" routine which is called by checkdatain when it gets a full and complete LFS packet. The "processpacket" routine is just basically a big CASE statement which checks the second byte to see which LFS packet it is.

Tim

Quote from Krammeh :

akgrid2 a public type?

Its just a list control that I use instead of a ListBox, however recently I have been favouring the ListView anyway. Just imagine it is a list.

Quote from Krammeh :

hmm. I can encode a packet now, and it sends just loverly.

Its just receiving a packet, I've got NO idea how to decode it.

the data I get is: ôý
and: ôý

OK, start at the beginning then, this is how I decode the response to the InSim ISP_VER:

Firstly, I assume you have the packet recieved and fully checked to ensure you have a full "LFS packet". So you will have an array of bytes with a length of 20 bytes. So byte 0 = 20, byte 1 = 2.

To get LFS version and product use this


Tim

I also don't like using the libraries because that means there is a part of the code which I did not write and therefore don't fully understand. To this end, I stripped one library (edit: remembered, it was this one) down and I now manually decode and encode my packets. I know it is not the best programming practice, but I understand the code and, imho, it is easy to understand.

Here is how I encode a simple packet (this is a IS_REO packet that I send to LFS. akgrid is a 3rd party list control):


The main issue with decoding the packets is in converting the bytes to VB6 types. I don't have them all yet, because I don't use some, but is there anything inparticular you are after. I could post the code I use.

Otherwise, do like I did and get a library and work out how it works so you can do it yourself without the library.

Tim

Last edited by t1ger, Wed 3 Oct 2007, 15:23.

Anyone else going this year? It's on next weekend (8th - 9th September 2007) - which strikes me as odd as it clashes with the F1 in Italy?! :-/

We are going on the Sunday anyway as it should be a good day out for us.

http://www.worldseriesbyrenault.com/donington/uk/

Tim

Scooter - The question is what is the question.

http://www.youtube.com/watch?v=dUklTESKmis

Sorry, I love it! dum dum de dum, de dum, de dum, dah dah dah dum de dum......

Quote from AtomAnt :

Already found him.......sorry ,Tim Kay is the next name to watch.
You could try to bribe him, but he's on staff with OLFSL. The largest LFS league....and one of the oldest.

Thanks ANT!

I would like to help, but I have my work cut out with the Original LFS League and the app I am writing for it.

Sorry,
Tim

Quote from Bogey Jammer :

an out of topic question: UDP vs TCP, what are the differences? I've heard that UDP is potentially faster

This seems to be the best (and most to the point) description I have found.

Edit: and another.

Tim

Oops, I really thought we were running them on Patch W, sorry, but thanks. They are now on Patch X so the problem will be gone.

Thanks again (and sorry again)

Tim

Just tested and when "Voluntary added mass" = 0 kg the "Added mass position (front)" is greyed out and it makes no difference to the cars weight distribution when you move it.

This was tested offline. Maybe when online a server can force the mass and you do not see it. I can't test this 'cos my server is off.

Tim

Hi,

I noticed this bug at our last league race (OLFSL 3 by 500servers - 19:26, 03 Jun 2007 - Fernbay Rallycrss Rev - 35 laps). During the race, I left and decided to watch the race in the Progress window. But it was very strange. There were about 15 in the race, only 3 were shown with positions, 1 was spectating (which he was) and the rest were all showing as "in pits".

Also, during the race, the positions of the three racers that had positions shown moved randomly all over the place.

I took screenshots as different times during the race (one on lap 16 and one on lap 18) and they are attached.

The race server was on Patch W at the time (with no test patches).

Thanks

Tim

Quote from LupusC :

Hmm, don't make a messagebox.

I know, don't worry I am just testing at the moment. And even when this is complete I do not intend releasing it to the masses - only a select few

Quote from LupusC :

Thinking about how to get splitted packages maybe the following wil be a solution:
1. No MCI packets (they are too large and not so good to handle for that)
2. Set receive buffer size to 100-120 Bytes (not kByte!!!)
3. Maximum AI player or a replay from a server with more player
4. Fire out TINY_NPL requests in a loop to get many many many packets

For every request you get at least 20 times 76 bytes in return (with maxium AI)

The IS_NPL packet is 76 bytes long, so your buffer will be smaller than 2 packets and IMHO a splitted package has to occur.

This is the type of thing I need! I am not, by any means, an expert programmer. I know what I need to do when I get less data than I need - wait for some more and then add on the bits I am missing. BUT I can guarantee that it will not work if I code it and just wait for it to happen. I need to test it and make sure, and I can only do that when it happens.

Quote from LupusC :

You are using VB6 so have a look at http://support.microsoft.com/kb/237688/en-us to change socket options.

I will try this, because the one thing I am so far unable to do is find out and change how big the receive buffer is. If I can do this, then I can test it and then I will know I am covered when it occurs.

Thanks very much for the info LupusC.

Tim

Quote from LupusC :

The easiest way to deal with splitted packages is very simple. Just read the first byte of the incoming stream, but without removing the byte (!!). And then test if the ammount of bytes in the input buffer is greater or equal the byte you read. If yes read in the packet, if not wait for more bytes.

If you do this in a loop you have no problem to read multiple packets and splitted packets.

Hi LupusC,

Thanks, and yes that is exactly what I do. I have the routine that receives data from the TCP stream which passes the array of bytes received to a routine which checks the first byte ("size") and then checks it against the size of bytes received on the stream.

As you know, there are three possiblities:

1. The size received matches the size of the LFS packet. I then pass the data to the process routine. The process routine only knows how to deal with full and complete LFS packets.

2. The size received is greater than the size of the LFS packet. In this case, I pass the first LFS packet to the process routine and then re-process the rest of the actual data received.

3. The size received is less than the size of the LFS packet. In this case I know that I need to wait for more data and then add it to the end, and then process it. I have as yet, never encountered this case. All I have here is a message box waiting to pop up and say "Not enough data received".

Last night, I connected to a very full server, which had about 23 people connected and people joining and leaving and talking and pitting and racing and everything. Now, apart from my PC having some issues and my application not being able to keep up with where everybody was (but I know this is a limitation of what I have coded) then I never saw case 3 as described above.

I then connected to another server with about 7 racers and I got the same results again.

Like I say, I do not deny that this is not possible, I am just saying that I would have expected to have seen it by now with the amount of testing I have done.

Thanks

Tim

Quote from the_angry_angel :

It shouldn't do - VB has no understanding of how the insim data is packetized (all TCP data is basically a constant stream, its upto you how you packetize it), so you're probably just very lucky, or you've got a huge buffer..

Connect your InSim client upto LFS and join a really busy server with a fair bit of chat, and start watching the packets, odds are you'll probably see a split one.

Thanks, that is a good point, I haven't yet connected to a "busy" server and tried.

Tim

Quote from Scawen :

The multiple packets case is very easy to deal with - just see if there is more data there after reading the first packet.

The incomplete packets case is a bit more complicated but it's really just a case of your code realising that there isn't enough data received for the specified packet size, so you must leave that incomplete packet in the buffer until you get some more info and find that the packet is complete.

I have been using the new insim over TCP/IP for quite some time now, including connecting to a local guest, a local host and a remote host over the internet and have yet to experience the "not receiving enough data" and have never yet had to buffer the received data and wait for some more to finish the LFS Packet.

Now, I am using VB6 with its standard WinSock control and it fires a routine called _DataArrival when data is received from the TCP socket. I do not know if this function somehow compensates for the fact that TCP can break up the initial "packet".

Getting a few LFS packets in altogether happens all the time and I have been able to accomodate this (as I had it happening and could test and debug it until it worked). However, with the split packet, I have never had it so I have not worked how what to do with it. I am of course looking for it and I just have a message box which will pop up the first time it happens!

Don't get me wrong, I fully understand the reasons that it can and will happen, I just wonder if VB6 compensates already.

Can anyone else confirm of clarify this?

Tim

Oh dear, my bad!

I spot one mistake just like it and then I miss one altogether! How bizarre.

Thanks GeForz.

Tim

Hi,

I think I may have found a bug in InSim. I have a program which can talk to InSim and the first thing it does with received packets is check the amount of bytes received against byte 0 and byte 1 (using a lookup table) to ensure it has received enough or not.

This works fine everywhere apart from one place - when I start a multiplayer replay. I haven't tried it with a single player replay yet as I have been scratching my head hard to make sure I am not missing anything obvious (apologies again, if I have )

When I start a multiplayer replay I get a packet which is 40 bytes long (0 to 39) and the first two bytes are as follows:

byte(0) = 40
byte(1) = 10

The rest of the bytes from 2 to 39 are all = 0.

Now, this packet seems to be an ISP_ISM, but this should be 8 bytes in size, so I expect byte(0) to be 8 not 40. I can't see any LFS packets that are 40 bytes and there is nothing in the rest of the packet which gives me any clue as to what it is.

Can anyone else confirm this before Scawen takes a look? I am using W29.

Thanks in advance.

Tim

Last edited by t1ger, Thu 24 May 2007, 22:30.

Quote from BurnOut69 :

Thanks fel, that will surely do the trick

I have another question: if several players can be bound to one connection (when adding AI), what would be the UCID of these AI drivers if the connection that created them leaves?

AI dont have UCIDs so when the the connection that created them leaves, I would expect the AI to leave also. I can not confirm this at this moment, but I am fairly sure this will happen.

Tim

Hello,

Small mistake noted in the InSim.txt file:


byte Type should have ISP_RES not ISP_PFL as the comment.

Nothing major, but worth noting.

Thanks
Tim

Quote from Scawen :

Admins can now use the IS_REO (race reorder) packet

I know this is spam, but I couldn't let this go with out expressing my deepest thanks, could I!

Thank you.

Tim

Quote from Scawen :

Hi Tim.

Sorry, yes I did read your post and was going to get back to it after thinking a bit. But an unreasonable time has passed with no reply from me.

IS_REO is host only, yes. It would be a bit dangerous to allow guests to do this... and if they could it would be admins only. And if admins can do it then there is a possibilty of conflict with the host. I couldn't see any reason for a guest to send an IS_REO so that's why it's host side only (all race reordering has always been host controlled).

But what is the reason for allowing guests to do it? I think it would be quite easy to allow admins to reorder the race, if there is a good reason and if no-one thinks of any problems with it.

Phew, I am glad you understand my reasons for re-posting.

The reason I ask for this is because I am writing a race control app which will be used for the hosts that watch and manage league races. By the term "host" I mean a guest connecting to the server with admin rights who then just spectates the entire race and ensures that rules etc are followed. In our league, the "hosts" are not hosts in the LFS sense of the word, they are guests who log on with admin rights. (I hope this makes sense so far).

Currently, re-ordering a race to start in the correct order is done by everyone joining in the correct order. The IS_REO function would simplify this immensly and streamline the hosting process.

I would be perfectly happy for an admin to be able to re-order the race, but I can see that there could be issues if there were multiple admins all trying to re-order the race at the same time. Perhaps only the first admin to connect could do the re-ordering or the admin with the lowest UCID only.

If not, then I will have to get the hosts to know the IP address of the server they are "hosting" and connect as the proper host.

I think that is enough uses of the word host now!

Can anyone else think of any issues this may cause?

Thanks
Tim

Last edited by t1ger, Fri 18 May 2007, 18:57.