Jump to content

GuiSpeedometerHud [update]


kent

Recommended Posts

Howdy. Here is an upgraded GuiSpeedometerHud (engine/source/T3D/vehicles/guiSpeedometer.cpp) that provides some bug fixes and added functionality.


This change addresses 3 functionality issues.

  • -Allow the GUI to work with mounted players.

    -Fix mismatched worldmatrix push/pop that was causing a crash

    -Properly translate/rotate needle vertex list to render in the control's view rectangle.

Adds the following fields:

  • clampNeedleAngle: If true the needle will not move past the specified maxAngle.

    forceBitmapRender: If true, the gui will render the dial bitmap when player not mounted

    calibrateSpeed: Cause the gui to react to the specified speed input.

    calibrateAngle: Cause the gui to render the needle at the specified angle.

    torqueUnitScale: Approximate number of meters per torque unit for the current simulation.

Adds the following console methods:

  • calibrateMPH(): sets the calibration speed scaled from MPH based on torqueUnitScale.

    calibrateKPH(): sets the calibration speed scaled from KPH based on torqueUnitScale.

    mphToVel(F32 mph): Return torque unit velocity from MPH based on torqueUnitScale.

    kphToVel(F32 kph): Return torque unit velocity from KPH based on torqueUnitScale.

 

//-----------------------------------------------------------------------------
// Copyright (c) 2012 GarageGames, LLC
//
// Permission is hereby granted, free of charge, to any person obtaining a copy
// of this software and associated documentation files (the "Software"), to
// deal in the Software without restriction, including without limitation the
// rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
// sell copies of the Software, and to permit persons to whom the Software is
// furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in
// all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
// IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
// FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
// AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
// LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
// FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
// IN THE SOFTWARE.
//-----------------------------------------------------------------------------
#include "console/engineAPI.h"
#include "gui/controls/guiBitmapCtrl.h"
#include "console/consoleTypes.h"
#include "T3D/gameBase/gameConnection.h"
#include "T3D/gameBase/gameBase.h"
#include "T3D/vehicles/vehicle.h"
#include "gfx/primBuilder.h"
#include "T3D/player.h"
//-----------------------------------------------------------------------------
/// A Speedometer control.
/// This gui displays the speed of the current Vehicle based
/// control object. This control only works if a server
/// connection exists and its control object is a vehicle. If
/// either of these requirements is false, the control is not rendered.
class GuiSpeedometerHud : public GuiBitmapCtrl
{
  typedef GuiBitmapCtrl Parent;

  F32   mSpeed;        ///< Current speed
  F32   mMaxSpeed;     ///< Max speed at max need pos
  F32   mMaxAngle;     ///< Max pos of needle
  F32   mMinAngle;     ///< Min pos of needle
  Point2F mCenter;     ///< Center of needle rotation
  ColorF mColor;       ///< Needle Color
  F32   mNeedleLength;
  F32   mNeedleWidth;
  F32   mTailLength;
  GFXStateBlockRef mBlendSB;

  bool mClampNeedleAngle;	// KGB
  bool mForceBitmapRender;	// KGB
  F32 mTorqueUnitScale; // KGB: scale of torque units to meters

public:
  GuiSpeedometerHud();

  void onRender( Point2I, const RectI &);
  static void initPersistFields();

  F32 mphToVel(F32 mph);
  F32 kphToVel(F32 kph);
  F32	mCalibrateSpeed;
  F32	mCalibrateAngle;

  DECLARE_CONOBJECT( GuiSpeedometerHud );
  DECLARE_CATEGORY( "Gui Game" );
  DECLARE_DESCRIPTION( "Displays the speed of the current Vehicle-based control object." );
};


//-----------------------------------------------------------------------------

IMPLEMENT_CONOBJECT( GuiSpeedometerHud );

ConsoleDocClass( GuiSpeedometerHud,
  "@brief Displays the speed of the current Vehicle based control object.\n\n"
  "This control only works if a server connection exists, and its control"
  "object is a either a Vehicle derived class or a Player derived class mounted"
  "to a Vehicle derived class. If these requirements are not met,"
  "the control is not rendered.\n"

  "The control renders the speedometer needle as a colored quad, rotated to "
  "indicate the Vehicle speed as determined by the <i>minAngle</i>, "
  "<i>maxAngle</i>, and <i>maxSpeed</i> properties. This class extends GuiBitmapCtrl "
  "and will render a specified background image representing the speedometer dial.\n\n"

  "Speed variables (maxSpeed/minSpeed) represent raw object velocity. Calculations"
  "for mph/kph are derived using torqueUnitScale. The torqueUnitScale value defaults"
  "to 1 torque unit = 1 meter.\n\n"

  "@tsexample\n"
  "new GuiSpeedometerHud()\n"
  "{\n"
  "   bitmap = \"art/gui/speedometer\";\n"
  "   maxSpeed = \"35.7632\";\n" 
  "   minAngle = \"135\";\n"
  "   maxAngle = \"300\";\n"
  "   color = \"1 0.3 0.3 1\";\n"
  "   center = \"130 123\";\n"
  "   length = \"100\";\n"
  "   width = \"2\";\n"
  "   tail = \"0\";\n"
  "   forceBitmapRender = \"false\";\n"
  "   clampNeedleAngle = \"false\";\n"
  "   calibrateSpeed = \"0\";\n"
  "   calibrateAngle = \"0\";\n"
  "   torqueUnitScale = \"1\";\n"

  "   //Properties not specific to this control have been omitted from this example.\n"
  "};\n"
  "@endtsexample\n\n"

  "@ingroup GuiContainers"
);

GuiSpeedometerHud::GuiSpeedometerHud()
{
  mSpeed = 0;
  mMaxSpeed = 100;
  mMaxAngle = 0;
  mMinAngle = 200;
  mCenter.set(0,0);
  mNeedleWidth = 3;
  mNeedleLength = 10;
  mTailLength = 5;
  mColor.set(1,0,0,1);

  mClampNeedleAngle = false;	// KGB
  mCalibrateSpeed = 0;
  mCalibrateAngle = 0;
  mForceBitmapRender = false;
  mTorqueUnitScale = 1;	// 1 torque unit = 1 meter
}

void GuiSpeedometerHud::initPersistFields()
{
  addGroup("Needle");

  addField("maxSpeed", TypeF32, Offset( mMaxSpeed, GuiSpeedometerHud ),
     "Maximum Vehicle speed (in Torque units per second) to represent on the "
     "speedo (Vehicle speeds greater than this are clamped to maxSpeed)." );

  addField("minAngle", TypeF32, Offset( mMinAngle, GuiSpeedometerHud ),
     "Angle (in radians) of the needle when the Vehicle speed is 0. An angle "
     "of 0 points right, 90 points up etc)." );

  addField("maxAngle", TypeF32, Offset( mMaxAngle, GuiSpeedometerHud ),
     "Angle (in radians) of the needle when the Vehicle speed is >= maxSpeed. "
     "An angle of 0 points right, 90 points up etc)." );

  addField("clampNeedleAngle", TypeBool, Offset( mClampNeedleAngle, GuiSpeedometerHud ),
     "Clamp needle to maxAngle when the Vehicle speed is >= maxSpeed. ");

  addField("color", TypeColorF, Offset( mColor, GuiSpeedometerHud ),
     "Color of the needle" );

  addField("center", TypePoint2F, Offset( mCenter, GuiSpeedometerHud ),
     "Center of the needle, offset from the GuiSpeedometerHud control top "
     "left corner" );

  addField("length", TypeF32, Offset( mNeedleLength, GuiSpeedometerHud ),
     "Length of the needle from center to end" );

  addField("width", TypeF32, Offset( mNeedleWidth, GuiSpeedometerHud ),
     "Width of the needle" );

  addField("tail", TypeF32, Offset( mTailLength, GuiSpeedometerHud ),
     "Length of the needle from center to tail" );

  endGroup("Needle");
  addGroup("Calibration");
  addField("calibrateSpeed", TypeF32, Offset( mCalibrateSpeed, GuiSpeedometerHud ),
     "Set a forced output speed (as object velocity) to be rendered for calibration. Will cause control to render without vehicle mount/control object. Setting to 0 disables." );
  addField("calibrateAngle", TypeF32, Offset( mCalibrateAngle, GuiSpeedometerHud ),
     "Set a forced output angle to be rendered for calibration. Will cause control to render without vehicle mount/control object. Setting to 0 disables." );
  addField("forceBitmapRender", TypeBool, Offset( mForceBitmapRender, GuiSpeedometerHud ),
     "Clamp needle to maxAngle when the Vehicle speed is >= maxSpeed. ");
  addField("velocitySpeedScale", TypeF32, Offset( mTorqueUnitScale, GuiSpeedometerHud ),
     "Meters per torque unit." );
  endGroup("Calibration");
  Parent::initPersistFields();
}


//-----------------------------------------------------------------------------
/**
  Gui onRender method.
  Will only render if the controlObject is a vehicle or vehicle-mounted player
  unless mCalibrateSpeed || mCalibrateAngle > 0 or mForceBitmapRender = true.
*/
void GuiSpeedometerHud::onRender(Point2I offset, const RectI &updateRect)
{
if(mForceBitmapRender) Parent::onRender(offset,updateRect);	// Show bitmap no matter what if flag is set
Vehicle* vehicle = NULL;
if(mCalibrateSpeed == 0 && mCalibrateAngle == 0){
	// Must have a connection
	GameConnection* conn = GameConnection::getConnectionToServer();
	if (!conn)
		return;
	// Requires either a vehicle control object or a vehicle-mounted player		
	vehicle = dynamic_cast<Vehicle*>(conn->getControlObject());
	if(!vehicle){
		Player * player = dynamic_cast<Player*>(conn->getControlObject());
		if(!player) return;
		if (!player->isMounted()) return;
		vehicle = dynamic_cast<Vehicle*>(player->getObjectMount());
		if(!vehicle) return;
	}
}
if(!mForceBitmapRender) Parent::onRender(offset,updateRect);	// If not already done, show base bitmap.

// Set up the needle vertex list
Point3F vertList[5];
vertList[0].set(+mNeedleLength,-mNeedleWidth,0);
vertList[1].set(+mNeedleLength,+mNeedleWidth,0);
vertList[2].set(-mTailLength  ,+mNeedleWidth,0);
vertList[3].set(-mTailLength  ,-mNeedleWidth,0);   
vertList[4].set(+mNeedleLength,-mNeedleWidth,0); //// Get back to the start!
if(mCalibrateSpeed > 0 || !vehicle){
	mSpeed = mCalibrateSpeed;
}else{
	mSpeed = vehicle->getVelocity().len() * mTorqueUnitScale;
}
 //mSpeed = vehicle->getVelocity().len();
// Calculate center point if none specified
Point2F center = mCenter;
if (mIsZero(center.x) && mIsZero(center.y))
{
	center.x = getExtent().x / 2.0f;
	center.y = getExtent().y / 2.0f;
}
// Calculate view center with all offsets
F32 fillOffset = GFX->getFillConventionOffset(); // Find the fill offset
Point2F viewCenter(offset.x + fillOffset + center.x, offset.y + fillOffset + center.y);

// Handle rotation calculations
F32 rcos,rsin;
F32 rotation;
rotation = mCalibrateAngle > 0 ? mCalibrateAngle : mMinAngle + ((mMaxAngle - mMinAngle) * (mSpeed / mMaxSpeed));
if(rotation>mMaxAngle && mClampNeedleAngle) rotation = mMaxAngle; 	// Clamp the angle if desired and necessary
mSinCos(mDegToRad(rotation),rsin,rcos);

// Translate and render the needle
if (mBlendSB.isNull())
{
	GFXStateBlockDesc desc;
	desc.setBlend(true, GFXBlendSrcAlpha, GFXBlendInvSrcAlpha);
	desc.samplersDefined = true;
	desc.samplers[0].textureColorOp = GFXTOPDisable;
	mBlendSB = GFX->createStateBlock(desc);
}
GFX->setStateBlock(mBlendSB);
GFX->setTexture(0, NULL);
PrimBuild::color4f(mColor.red, mColor.green, mColor.blue, mColor.alpha);
PrimBuild::begin(GFXLineStrip, 5);
for(int k=0; k<5; k++){
	Point2F pt( rcos * vertList[k].x  - rsin * vertList[k].y,
			    rsin * vertList[k].x  + rcos * vertList[k].y);
   PrimBuild::vertex2f(pt.x + viewCenter.x, pt.y + viewCenter.y);
}
PrimBuild::end();
}

F32 GuiSpeedometerHud::kphToVel(F32 kph){
return ((kph * 1000 * mTorqueUnitScale) / 60) / 60;
}

F32 GuiSpeedometerHud::mphToVel(F32 mph){
F32 kph = kphToVel(mph * 1.609344);
return kph;
}

DefineEngineMethod( GuiSpeedometerHud, calibrateMPH, void, (F32 mph),,
"@brief Set the calibration speed (in MPH)\n\n"
  "Set the calibration speed, first converting input from mph to velocity\n"
  "Will result in the needle being rendered as if the controlObject is moving at the set speed.\n"
  "@param F32 mph\n"
  "@return void\n\n" )
{
object->mCalibrateSpeed = object->mphToVel(mph);
}

DefineEngineMethod( GuiSpeedometerHud, calibrateKPH, void, (F32 kph),,
"@brief Set the calibration speed (in KPH)\n\n"
  "Set the calibration speed, first converting input from kph to velocity\n"
  "Will result in the needle being rendered as if the controlObject is moving at the set speed.\n"
  "@param F32 mph\n"
  "@return void\n\n" )
{
object->mCalibrateSpeed = object->kphToVel(kph);
}

DefineEngineMethod( GuiSpeedometerHud, kphToVel, F32, (F32 kph),,
  "@brief Convert KPH to approximate object velocity\n\n"   
  "@param F32 speed in kph\n"
  "@return F32 linear velocity\n\n" )
{
return object->kphToVel(kph);
}

DefineEngineMethod( GuiSpeedometerHud, mphToVel, F32, (F32 mph),,
  "@brief Convert MPH to approximate object velocity\n\n"   
  "@param F32 speed in mph\n"
  "@return F32 linear velocity\n\n" )
{
return object->mphToVel(mph);
}

 

To apply the patch, this code should entirely replace the code found in "engine/source/T3D/vehicles/guiSpeedometer.cpp".


Notes:

To calibrate the control to a bitmap, the calibrateAngle can be used to precisely align the needle with indicator marks on a speedometer bitmap to determine the correct max/minAngle values. When the angles are set, calibrateSpeed, calibrateMph() and calibratekph() can then be used to check the alignment of the needle and bitmap across the range of expected vehicle velocities.

Edited by kent
Link to comment
Share on other sites

Hey, awesome!


Any chance I could bug you into turning this into a pull request for the main repo?


If not, I'll make one if you don't mind, but it's always good to get bugfixes into the main branch when possible :)


Thanks for your hard work!

Sure, you are welcome to integrate the changes. Glad to be useful. This has been tested in 3.8 if that makes a difference. I'm in a bit of a learning curve with Github - never done a pull request. It would probably be better/faster if you did it on this one.


I've been out of the Torque loop for quite some time and still need to figure out how things work in these Harvard-license days. With stuff like this, is the usual approach to submit it as a pull request and not do a forum post/resource ... or is it better to post in the forums and only submit a pull request when someone asks for it?

Link to comment
Share on other sites

I just wanted to chime in here to thank @kent for his contribution and sharing with the community. Also thank you for bringing up this same question that has been on my mind for quite some time:

 

With stuff like this, is the usual approach to submit it as a pull request and not do a forum post/resource ... or is it better to post in the forums and only submit a pull request when someone asks for it?

 

For a number of reasons, I personally would prefer not to submit PR's to the T3D branches directly from my company's GitHub account. However, I strongly feel the need to share some of the small updates and corrections I stumble across while developing. So I can either A)make another GitHub account and create an entire fork for each small change then PR it - or B)Copy/Paste the code in a resource here on the forums. It's like if I go with A) it's pretty cumbersome - especially with the sort of scheduling I have to deal with. If I go with B) it seems much simpler although then I feel as if I am not being helpful if I don't go the extra mile and submit the PRs. lol.


Anyways just some thoughts, and I'd be interested in hearing the SC's stance on this. I would prefer to use the proper etiquette when sharing.

Link to comment
Share on other sites

Hey, awesome!


Any chance I could bug you into turning this into a pull request for the main repo?


If not, I'll make one if you don't mind, but it's always good to get bugfixes into the main branch when possible :)


Thanks for your hard work!

Sure, you are welcome to integrate the changes. Glad to be useful. This has been tested in 3.8 if that makes a difference. I'm in a bit of a learning curve with Github - never done a pull request. It would probably be better/faster if you did it on this one.


I've been out of the Torque loop for quite some time and still need to figure out how things work in these Harvard-license days. With stuff like this, is the usual approach to submit it as a pull request and not do a forum post/resource ... or is it better to post in the forums and only submit a pull request when someone asks for it?

 

@JeffR: With the update, it's gone a bit beyond a simple bug fix now. Is this still appropriate for a pull request?


If so, think I'm set up to properly make one.

 

Sorry for not seeing your update on this. Somehow it totally slipped past my perusings of the threads.


Anywho. Yeah, if you're ready for it, feel free to toss it up. Worst case, we'll just go over it and decide it should be broken up a little. But obviously we don't have anything against larger changes :)


As for when to make PRs and stuff, feel free to just toss one up if you think it's ready. It'll show up in the github list, so you're not obligated to make a forum post/thread here, though you certainly can if you want some additional discussion/ideas about it.

 

I just wanted to chime in here to thank @kent for his contribution and sharing with the community. Also thank you for bringing up this same question that has been on my mind for quite some time:

 

With stuff like this, is the usual approach to submit it as a pull request and not do a forum post/resource ... or is it better to post in the forums and only submit a pull request when someone asks for it?

 

For a number of reasons, I personally would prefer not to submit PR's to the T3D branches directly from my company's GitHub account. However, I strongly feel the need to share some of the small updates and corrections I stumble across while developing. So I can either A)make another GitHub account and create an entire fork for each small change then PR it - or B)Copy/Paste the code in a resource here on the forums. It's like if I go with A) it's pretty cumbersome - especially with the sort of scheduling I have to deal with. If I go with B) it seems much simpler although then I feel as if I am not being helpful if I don't go the extra mile and submit the PRs. lol.


Anyways just some thoughts, and I'd be interested in hearing the SC's stance on this. I would prefer to use the proper etiquette when sharing.

 

I'd say go with whatever's comfortable for you. If you can hock it with two accounts, neat. If you wanna just toss the code up on here or a pastebin or whatnot so someone else can slap together a PR, that's fine too. Much better to have people put code up and take a little bit of additional wrenching to get it sorted than no code at all :)

Maybe if you have something PR-able, you could possible make an issue and link back to the code/post for it to be PRed? That may work.

Link to comment
Share on other sites

Sorry for not seeing your update on this. Somehow it totally slipped past my perusings of the threads.


Anywho. Yeah, if you're ready for it, feel free to toss it up. Worst case, we'll just go over it and decide it should be broken up a little. But obviously we don't have anything against larger changes :)


As for when to make PRs and stuff, feel free to just toss one up if you think it's ready. It'll show up in the github list, so you're not obligated to make a forum post/thread here, though you certainly can if you want some additional discussion/ideas about it.

Cool. So, in order to properly break it up using git, is the typical procedure to make a series of commits in the same branch before pushing/doing the pull request?


For this, I forked the T3D repo and made a branch called "guiSpeedometerHud" (or something similar), then did a commit of all the changes and finally pushed them. I presume doing a pull request would be the next (final) step.


If the changes had been committed to my repo's branch in chunks, maybe as "Fix rendering", "Handle mounted players.", "Add calibration/debugging console fields/functions", and then pushed ... would that break them up correctly to do with a single pull-request? Or is it necessary to do a separate pull request for each bit?


Also, I am assuming that I'd use the same branch for all changes that are being made in relation to this specific control, right? Or is it necessary to make a new branch for each change?

Link to comment
Share on other sites

Does anyone see value in making a simplified version of this control to provide a general-purpose analog dial?


Technically, the hud can be used that way as it sits by controlling the calibrateAngle field in script. It wouldn't take much to strip out the vehicle-specific stuff and maybe add a bit of functionality to tweak it for general use.

Link to comment
Share on other sites

Sorry for not seeing your update on this. Somehow it totally slipped past my perusings of the threads.


Anywho. Yeah, if you're ready for it, feel free to toss it up. Worst case, we'll just go over it and decide it should be broken up a little. But obviously we don't have anything against larger changes :)


As for when to make PRs and stuff, feel free to just toss one up if you think it's ready. It'll show up in the github list, so you're not obligated to make a forum post/thread here, though you certainly can if you want some additional discussion/ideas about it.

Cool. So, in order to properly break it up using git, is the typical procedure to make a series of commits in the same branch before pushing/doing the pull request?


For this, I forked the T3D repo and made a branch called "guiSpeedometerHud" (or something similar), then did a commit of all the changes and finally pushed them. I presume doing a pull request would be the next (final) step.


If the changes had been committed to my repo's branch in chunks, maybe as "Fix rendering", "Handle mounted players.", "Add calibration/debugging console fields/functions", and then pushed ... would that break them up correctly to do with a single pull-request? Or is it necessary to do a separate pull request for each bit?


Also, I am assuming that I'd use the same branch for all changes that are being made in relation to this specific control, right? Or is it necessary to make a new branch for each change?

 

Yeah, that's pretty much the right process. Sometimes it's a good idea to break up really big stuff into completely separate PRs, but for something like this, where all the changes are related and it's not massive, usually just making sure to do the commits in bits to the same branch so it's all documented is perfectly fine.

 

Does anyone see value in making a simplified version of this control to provide a general-purpose analog dial?


Technically, the hud can be used that way as it sits by controlling the calibrateAngle field in script. It wouldn't take much to strip out the vehicle-specific stuff and maybe add a bit of functionality to tweak it for general use.

 

Yeah, that sounds like that could be pretty useful.

Link to comment
Share on other sites

@JeffR : Cool man, I appreciate the feedback, it's good to know you encourage "share it if at all possible". In my case, I've been full speed ahead polishing up our site and blog so it's ready for public consumption - a big part of that will be blogging specifically about developing Torque tech.


In order to do things right and proper I will ultimately be sharing via GitHub and PR's by request(i.e. if something is actually decent enough to warrant integration, a lot of the stuff I code is project-specific). For example, the extended GuiObjectView class I'm sharing real soon. It has a lot of bells and whistles but we're talking about tech that's been through a few iterations by now and while one version may be general later ones include things like very project-specific animation blends. BUT the big challenge is I really want to share a bit about the thinking process, identifying and solving the problem using Torque3D, and providing information and source code for people to learn from it. It's like, I want to show people how those animations and stuff were blended and the end result was achieved but at the same time it wouldn't be super helpful to share our exact files because we literally hardcode in specific model information built around our design for players.


So what this leaves me with is blogging about it as we go and drop out different versions of the class as the blog series unfolds. So Tim who wants to just use the GuiObjectView to add sub-meshes can DL v.1.0 and Josh who wants to learn how to blend in a custom eye size can follow the blog for 2.0, DL the example source, and armed with that knowledge make it happen for his project. Anyways, yea, that's the idea and it is under way as we speak - I'll be poised to share more about that pretty soon!


@kent : I think any and every chance we get to toss out resources, regardless of how simple they may seem, we should be doing it. Be it even as small as a forum response - Torque is community. Take away community, take away Torque.


We're fortunate to have a good group of smart guys watching our backs and doing a lot of heavy lifting around the engine for us. In the meantime, community efforts can and will reverberate for long amounts of time throughout the interwebs. I know personally I always have a great day when I stumble on some old resource code that forces me to solve a problem more elegantly than I had prior. It is not uncommon as a Torque developer to find some code that's many years old and you still get totally excited by it as if you had hit the mother lodestone! Yes, add your input, it will be useful to some person one day!

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...