Written by 
[Ed. Note: We welcome Mothgirl Dibou to the pages of SL Sailing with her new column “A Peek Inside”. For some time now we all have enjoyed watching Mothgirl’s work in pushing the envelope of SL sailing. When I asked her if she might like to do a column on her thoughts and insights she was at first hesitant because she feared the people would think she was just promoting her boats. On the contrary, I said, people want to know the inside stories about how boat designers go about their work. They would love to know the sense of struggle and successes that designers feel. So here is the first installment of “A Peek Inside”.]
As a person I think fair play in racing is something that should come from the people themselves. If someone wins by cheating he should ask himself if that victory is really as fantastic as he imagined beforehand. If you loose from someone that cheated I think the victory is double. You were the first on the non-cheaters and you played it fair. If you extend this thought, fair play is a self-regulating system and no one has to worry about it too much.
As a boat builder I think I have an obligation to prevent cheating in any way I can. This seems contradictory to what I just said, but it isn’t. I need to prevent people from tampering with scripts or configuration parameters, because I owe this to race directors that want to ensure a fair race and to contestants that want to be free from any suspicion. Even if no one would ever cheat, I still have to make sure cheating is as impossible as I possibly can.
With the start of the Fizz Cup 2009 this topic is more important than ever. The stakes are high and the organization wants to be absolutely sure that everyone has an equal chance at winning.
People can cheat in many ways of course, but the ones I can do something about at the moment are editing the scripts inside the boat, editing the configuration parameters of the boat, changing the appearance of the boat in a way that it brings an advantage and wearing attachments that bring some advantage. It is up to the race directors to decide what is allowed and what not, but it is up to the builders to inform them on what is altered and what not.
This is what I am working on at the moment. Integrity checks for the Flying Fizz and for the Boat Building Kit. It is not something very spectacular I’m afraid. In fact, if I do my job well and everyone plays fair you will never even notice it.
Don’t get me wrong here. I don’t really mind if people change their boats in any way they like. Any check that is performed should never disable the boat. I think checks should simply inform everyone that something is not original upon entering a race.
To do this, the configuration notecards are now checked to see if they are genuine by reading their contents. And I equipped all scripts with passwords. The scripts are checked by asking them a question and waiting for a reply that can only be generated if the password inside the script is correct.
To eliminate the far fetched possibility that someone would replace all the scripts at once I extended the SLSA protocols. The subscription message that is send from the boat to the WWC Setter now also includes an encrypted checksum (which should be the same for each boat).
Changing the appearance is not checked yet. One could for instance make a transparent sail to have a better view, with big colored telltales or with illustrations of the up/down keys to tell you what to do. One could make the whole boat phantom to easily round marks or make it smaller. I am figuring out a way to check this, but most of these things are clearly visible already.
Next up is checking attachments. That’s a tough one, since they often cannot be seen by anyone else. It is possible to check the number of running scripts inside the sim for this, but for any race other than the Fizz Cup this would be too much to ask. I have a few attachments on my to-do list as well and I intend to extend the SLSA protocols for it. The WWC Setter announces a race and the minute a boat subscribes to the race, each official attachment worn should shout a message revealing its presence. It is up to the RD to decide if the attachment is allowed or not. Of course this only works if all builders of attachments would do this. And even then one could still make their own.
Oh well.. Who knows… in time you might not even be able to ignore a boat coming in on starboard tack anymore. Big Brother is sailing with you. Nah, I should never come that far. Double plus ungood.
As a non-scripter, I am awed by the ingenuity of those who can figure out how to use the Linden Scripting Language to accomplish things. Moth’s description of what she is doing to try to do to lessen the ability to cheat is very interesting. My only question would be: Are there scripters out there that can “beat her system”? I sure hope that no one can. Thanks Moth for this explanation!
Someone pointed me to this post due to the fact that i script and host road racing events in SL. I’m not familiar with these boats, but here’s a few things i’ve noticed in general that may or may not be helpful.
The ultimate way to prevent cheats is to not allow any scripted attachments. Put a check in the boat. Each time they hit “gas” or the sailing equivalent it can check seated avs for scripted attachments. (though impulse no longer works in attachments once you are seated in something (like a car or boat)).
While doing auto racing i found that different shapes can have drastic effects on physical behaviour and even CPU use due to garbage shape definition code that over defines complex shapes creating too much math for the limp hardware that runs SL sims (hi Andrew!). Some car shapes (containing complex parts like cut tubes and torii) can use half the sims CPU by itself. To combat this we switched to a common low prim physical base with worn attachment bodies (attachments are phantom and not included in the sims physics math). This allows us to run 8 cars on track with another 40 avs viewing and stay out of time dilation. A FormulaSL race uses about 15-16ms (of about 22 total) of sim time.
During our MotoSL bike racing people discovered that the size of an av effects the physical shape of the vehicle and therefor the physics of the vehicle. A taller av also has more mass. Thickness of the av doesn’t factor into physics at all. Some found that a taller av changes the center of mass and average center of all prims in such a way to allow quicker banking, which relates to quicker turning on a motorcycle…and perhaps a boat? I had to instate a min and max av size to kill the trend of 10 foot tall avs making it all look silly.
I also check region/debug/script time during events to see if anyone is out of the norm.
Either i’m blind or the people in my community are generally good sports. I haven’t found a true cheat yet. Though i have many cases of people using the vehicles complex set up options in odd ways in an effort to cheat my limited understanding of vehicle physics! This is something i combat by reading far too much about vehicle physics and then applying to create a more natural model.
Les White
CTO RaceSL
Wow Les,
Reading about your experiences, I think our 2 worlds have a lot in common.
I am glad we don’t use SL physics to the extend that you do though. The vehicles are much slower and the effect of the size of the avatar is not really noticable as far as I know. In sailing it is more about computation of invisible things like the effect of the wind on heel, steering and speed. Lucky for us, banking and “road grip” are not really a big issue.
But a lot of other things you mentioned are very recognisable.
It sounds like a good idea to exchange some experiences soon. I will contact you in-world.
Moth