Download Support script release: dioFlag

Diogenes

Diogenes

New Member
I'm releasing a support script to simplify some flag state and event tracking. Expect my future scripts to use it, feel free to include it with your bundles.

http://wtfimleet.com/legions/_dioFlag.cs

Its purpose is that your script can query one of the boolean properties for logic like:
Code: 
if(dioFlag.friendlyFlagHeld){
  echo("foo");
}

For hooking all flag events like:
Code: 
function dioFlag::event(%this, %msg, %event, %player){
  parent::event(%this, %msg, %event, %player);
  echo("foo" SPC %event);
}
Or for hooking a specific flag event:
Code: 
function dioFlag::playerGrabbed(%this,%player){
  parent::playerGrabbed(%this,%player);
  echo("foo");
}
Code: 
Default Properties:
    class = "dioFlagObject";
    playerHasFlag = false;
    enemyFlagAtHome = true;
    enemyFlagHeld = false;
    enemyFlagDropped = false;
    friendlyFlagAtHome = true;
    friendlyFlagHeld = false;
    friendlyFlagDropped = false;
    version = 1.0;
    highestVersion = 0;
    highScript = "";
    warningSent = false;
    playerName = "";
    friendlyCarrier = "";
    enemyCarrier = "";

  Methods:
    dioFlag.requires(%this,%version,%scriptName) : call to request a version of this library.
    dioFlag.dump(%this) : lists all properties and current values

  Hook Methods:
    dioFlag::event(%this, %msg, %event, %player) : master event for flag stuff, calls the following 7 based on the message. individual ones provided for simplier scripts.
    dioFlag::playerGrabbed(%this,%player)
    dioFlag::enemyFlagWasGrabbed(%this,%player)
    dioFlag::enemyFlagWasDropped(%this,%player)
    dioFlag::enemyFlagWasReturned(%this,%player)
    dioFlag::friendlyFlagWasGrabbed(%this,%player)
    dioFlag::friendlyFlagWasDropped(%this,%player)
    dioFlag::friendlyFlagWasReturned(%this,%player)

In the near future I'll probably release a few others that use this. It's currently used in dioFlagTalk, dioPunt, and dioThirdPersonGrab. Enjoy, all input is welcome.
 
Diogenes

Diogenes

New Member
Give me a moment before you bundle it because I just discovered a bug on a pub that I'm fixing ;) But just include the _dioFlag.cs in your .zip file, and at some point in your script use the line:

Code: 
dioFlag.requires(1.0,"MyScriptName");
If they don't have dioFlag v1.0 loaded (which you included), they will get a warning their version is out of date. This prevents your script from breaking if someone later on replaces it with an old version, although I plan on maintaining as much backwards compatibility as possible.

I wrote it so that everyone doesn't have to hook every server message, and figure out if it was a flag message. Dumb to have 10 scripts parsing every message when they're all looking for the same info.
 
Diogenes

Diogenes

New Member
It's a support volume working behind the scenes tracking yer flagz. Lets scripters hook into specific flag events instead of needing to read all the server events to see if it pertains to their script.
 
RockeyRex

RockeyRex

Legions Developer
Aaand if you change teams?

Edit: Also I know I'm a slight criminal here as well with the flaghud. I already have an update done but haven't released just yet.
Rather than hooking up to the clientCmdServerMessage I'd recommend doing new message callbacks. This way other scripts don't interefere with each other.
 
Mabeline

Mabeline

God-Tier
RockeyRex said:
Rather than hooking up to the clientCmdServerMessage I'd recommend doing new message callbacks. This way other scripts don't interefere with each other.
Click to expand...
Yeah, I pretty much wrote the game to allow multiple scripts to respond to server messages without stomping all over each other. You should check *really hard* for that sort of thing before releasing example code. Try to overload functions as little as possible, and make sure you are responsible with the return values when you do.

By the way my TorqueScript coding style is as follows:
Code: 
// packages are the only case in which the brace goes on the same line
// always put a space between the identifier and the bracket
package DemonstrationPackage {
// packages are the only time braces do not cause the following code to be indented

// Every level of indentation is exactly 3 spaces.

// Name all functions camelCase, all objects CamelCase
// all variables %camelCase, all globals $CamelCase::AtAnyDepth::YouHave

// Function definitions have spaces around the argument list, a single space between the parenthesis there aren't any arguments
function argFunction( %arg0, %arg1 )
{
}

function noArgFunction( )
{
   // Indent all inner code blocks by 3 spaces
   functionCall(%really, %long, %parameter, %lists, %that, %go,
      %beyond80ish, %columns, %should, %be, %indented, %with, %the
      %opening, %parenthesis, %next, %to, %the, %function, %name
   );
   // With the closing parenthesis on its own line, same level of indentation
   // as the function name
   // All keywords have a space between them and the next symbol, that means
   // if statements, for statements, while loops, switch statements, whatever
   // This clearly distinguishes them from function calls + constructors
   if (false)
   {
      while (true)
         break;
   }
   // you can only omit the braces from an 'if' if you have a simple
   // one line call
   if (true)
      smallCall(%arg);
   else
      otherSmallCall(%arg);
   if (true)
   {
      aCallWithAReallyLongNameAndSomeParametersThatICbaToThinkOf(
         %functionArgumentThatIsReallyLong
      );
   }
   else
   {
      // The else statement needs to have braces if the if does, and vice-versa
      smallCallTwo(%arg);
   }
   // Don't use if-else chains if you don't need to
   // cases labels are the same level of indentation as the open switch brace
   switch$ (%string)
   {
   case hello:
      code();
   default:
      moreCode();
   }
   // use of the ternary conditional operator cleans up code, so know what it is
   %val = (%check) ? %option0 : %option1;
   // but make sure to make it very clear what it's doing
   %val = ((%complexConditions == %areHard) ? 10 : 30) - 10;
   // because you do not want to debug an operator precedence bug
}

// All of my conventions are there to minimize errors while being easily
// readable

// Remember, TorqueScript is a crappy language with a crappy compiler -
// you WILL make mistakes and run into weird stuff, try to write in a way that
// will minimize the amount of time you spend slogging through code in Torsion!

// Above all, be explicit, be neat, be easy to maintain, and be readable!

};

I may make some better documentation, but whatever.
 
Diogenes

Diogenes

New Member
Caught the team change last night (oops) but didn't get a chance to update it yet, I needa strip the colors on join and in the .event() method. There will be a 1.2 this eve. There a good way to chat with you over IRC or some kind of IM Rocky? You appear to be the other active scriptard doing releases at this stage. Might as well align our efforts and create stuff that plays well together, and prevent duplication of efforts.
 
RockeyRex

RockeyRex

Legions Developer
IRC I be in. Although you might wish to wait till tomorrow evening as I get home before lurking out for me in there.
 
Diogenes

Diogenes

New Member
are you east coast or left coast? i haz jitz tonight after work, but will start dropping in to catch ya.
 
Diogenes

Diogenes

New Member
Mabeline said:
You should *really* check before releasing
Click to expand...

Ummm, don't take this the wrong way but two weeks ago I wrote Bugz saying:
One last thing, do you want me to run them past you before I publish them to the community? This is your baby in a lotta ways, and I don't wanna break your game (balance); especially before you're done with it.
Click to expand...

Then he included you in the convo, and you didn't bother replying; even when I bumped it twice.

I'm happy to keep an open line of dialog with the devs, but you're going to have to meet halfway if you have any expectations of me.
 
Mabeline

Mabeline

God-Tier
Diogenes said:
Then he included you in the convo, and you didn't bother replying; even when I bumped it twice.

I'm happy to keep an open line of dialog with the devs, but you're going to have to meet halfway if you have any expectations of me.
Click to expand...

Sorry, I just meant check this sort of thing with someone who knew what they were doing before releasing example code. Example code is the hardest kind to write, because if there are any bugs they are bound to be reproduced several times over without any easy update path.

I appreciate the work you guys are doing and am happy to see how much you've gotten done, even if it's not completely up to my architectural ideals (which I routinely fail to meet!) :).
 
Diogenes

Diogenes

New Member
Ummm, correct me if I'm wrong, but this unit works as advertised outside of the team changing bug. Outside of being one more package being wrapped, which I knew T2 would choke on after a while, is there some other glaring bug that I missed?

Pretty sure releasing a working support unit with documentation qualifies me as someone who "knows what they're doing", and I did contact you (through bugz), and you never responded. It doesn't fit your style of coding, because it was written by me; its line/tab spacing doesn't make it bad or wrong. If you want to tell me a reason you don't find it sound, then by all means dig in. Next time though, I'd prefer you just responded to me privately, instead of waiting for release and then complaining in a public forum after the fact.
 
You must log in or register to reply here.
Top