Email System (Release)

[Norby]

I want an "expires" property on the email object

Good idea but I suggest to do not delete just put into an expired folder.

[phkb]

Just thinking about the expiry data idea, I can see there are a couple of options for what to do with the email when it expires: delete it, move it, or how about this: when the email expires, the content of the email is hidden (replaced with "This email has expired" or some user supplied text), and any response options are also hidden? What do you think?

[Diziet Sma]

Treat it the way Gmail handles spam, perhaps? After xx days in the 'junk' folder, it's auto-deleted.

[Wildeblood]

Just thinking about the expiry data idea, I can see there are a couple of options for what to do with the email when it expires: delete it, move it, or how about this: when the email expires, the content of the email is hidden (replaced with "This email has expired" or some user supplied text), and any response options are also hidden? What do you think?

My preference for the user experience, ignoring difficulty of implementation, would be to display the expires field if it exists and have an option, "save this email", to delete that. However, I cannot over-emphasize there's no need to implement any functionality yet, just ensure an email object with an expires property won't be rejected by the createEmail function as malformed.

The most important thing to work on, IMHO, is properly storing and validating those callback functions. Telling OXP authors that their script has to re-establish those links on every start-up just won't fly. It's too complicated. It won't be people like me who couldn't be bothered using such a feature that cause you grief, it will be the enthusiastic, well-intentioned, but can't-follow-instructions people who come whinging.

[phkb]

OK, I think I've figured out a way to store a function and recall it from saved data. This might be obvious but do you think I should allow for parameters in the callback function, or just leave it as a parameter-less function call?

[cim]

OK, I think I've figured out a way to store a function and recall it from saved data. This might be obvious but do you think I should allow for parameters in the callback function, or just leave it as a parameter-less function call?

I think the most forward flexibility would come from making the callback function take a single parameter, which is an object. You can then add extra keys to that object as needed without requiring OXPs to count them, do anything with them, etc.

[Wildeblood]

This is what is concerning me...

Code: Select all

this._emails = [];

Code: Select all

this.startUp = function() {
	this._hudHidden = false;

	this.$restoreSavedData();
}

Code: Select all

this.startUpComplete = function() {
	var p = player.ship;

	if (missionVariables.EmailSystem_Welcome != "yes") {
		this.$createEmail({sender:"MailNET",
			subject:"Welcome to your inbox!",
			sentDate:global.clock.seconds - 100,
			emailBody:"MailNET is proud to welcome you to your new inbox..."});
		var p = player.ship;
		missionVariables.EmailSystem_Welcome = "yes";
	}

	if(p && p.isValid) {
		this.$initInterface(system.mainStation);
		this.$initInterface(p.dockedStation);
	}
}

Code: Select all

this.$restoreSavedData = function() {

	var iTotal = 0;
	iTotal = missionVariables.EmailSystem_TotalEmails;

	if (iTotal != null || iTotal > 0) {
		for (var i = 0; i < iTotal; i++) {
			var msg = new EmailMsg;
			msg.ReadData(missionVariables["EmailSystem_Email" + (i + 1).toString()]);
			this._emails.push(msg);
		}
	}

	if (this._emails) this._maxEmails = this._emails.length;
}

Code: Select all

this.playerWillSaveGame = function() {

	missionVariables.EmailSystem_TotalEmails = this._emails.length;
	for (var i = 0; i < this._emails.length; i++) {
		missionVariables["EmailSystem_Email" + (i + 1).toString()] = this._emails[i].StoreData();
	}

	if (this._emails.length < this._maxEmails) {
		// clear out any old emails
		for (var i = this._emails.length; i < this._maxEmails; i++) {
			missionVariables["EmailSystem_Email" + (i + 1).toString()] = "";
		}
	}

	this._max_Emails = this._emails.length;
}

None of that should be necessary.

Put the introductory message into this._emails where you first define it.

Code: Select all

this._emails = [{sender:"MailNET",
			subject:"Welcome to your inbox!",
			sentDate:global.clock.seconds - 100,
			emailBody:"MailNET is proud to welcome you to your new inbox..."}
];

And just do this to save and reload the whole database:

Code: Select all

this.startUpComplete = function() {
    if (missionVariables.EmailSystem_emails) {
        this._emails =  JSON.parse(missionVariables.EmailSystem_emails);
    }
	if(player.ship.docked) {
		this.$initInterface(player.ship.dockedStation);
	}
}

Code: Select all

    this.playerWillSaveGame = function () {
        missionVariables.EmailSystem_emails = JSON.stringify(this._emails);
    }

[phkb]

The problem I had with the JSON.parse was that I'm storing a specific local object type, "EmailMsg" into the array of emails. I'm using this local object to provide additional functions related to individual emails (things like "InboxDisplay", which returns a formatted line for the inbox). When JSON.parse puts the data back into the array, they go in as a general object, without the additional functions.

Anyway, I'm moving to the code you suggested, but it wasn't quite as simple as the JSON functions lead me to believe.

[Norby]

"This email has expired"

I would like to read the content after expired, so just put this expired message into the begin of the email. The response options can be replaced by a single "Send a late response" which mean that was not interested before but would like to get a similar thing next time.

[phkb]

There's lot of ways the expiry option can be implemented, and I'm not sure which ones will stick. Here's what I'm doing at the moment:

Added the following properties:
expiryDate : sets the expiry date to a specific time (in seconds)
expiryDays : set expiry date number of days in future
expiryHours : set expiry date number of hours in future
expiryMinutes : set expiry date number of minutes in future.
expirySeconds : set expiry date number of seconds in future
expiryText : text to display in header after email expires

If you just set the expiry date, the email will be deleted after the expiry date passes. If you supply the expiryText, the email stays but with the text in the header. I'm still uncertain what to do with any response options after the expiry date passes. Hide them, display them anyway. I'm leaning toward displaying them, and leaving it up to oxp authors to work out that the player responded after the expiry date.

You can combine the days, hours, minutes and seconds properties. So if you want the email to expire in 2 minutes and30 seconds, use expiryMinutes:2, expirySeconds :30.

[phkb]

I've almost finished the next version. Quick one for those who have downloaded this (and there are only 6 of you, according to the stats on box.com): the saved data methodology for all the emails has changed, which means when you install the next version you will loose any saved emails. I'm happy to put in conversion code, but as there are so few of you, and at the moment the possible emails you would have are just of the confirmation type, I'm thinking it's not critical, and it keeps the code cleaner not to have to look at the old way of doing things.

More on the expiry functionality:
The "allowExpiryCancel" option allows you to control whether the the player will have the option of stopping an email from expiring.
The "expiryOptions" gives you the opportunity to add response options that will only be available if the email expires.

I think with those options the system is pretty flexible: you can create an email that will expire and be deleted, or just switch over to an expired state, with options that are only available when expired.

Here's an example of what it looks like now:

Code: Select all

	w = worldScripts.EmailSystem;
	w.$createEmail(
		{sender:"The Chaser",				// senders name or email address
		subject:"Something for you do look at...",	// subject line
		sentDate:global.clock.seconds,			// the time the email was sent
		emailBody:"Would you like to play a game?",	// body text of the email
		expiryMinutes:2,
		expirySeconds:30,
		allowExpiryCancel:false,
		expiryText:"This email has expired",
		expiryOptions:"3",
		responseOption1:{displayText:"Yes", replyText:"Sure. Why not?", worldScriptsName:"EmailSystemDemo", callbackFunction:"$AcceptChallenge", functionParam:"mydata"},
		responseOption2:{displayText:"No", replyText:"Sorry. Too busy right now.", worldScriptsName:"EmailSystemDemo", callbackFunction:"$DeclineChallenge"}
		responseOption3:{displayText:"Too late", replyText:"Sorry I didn't respond to your email in time. Can I still join in?", worldScriptsName:"EmailSystemDemo", callbackFunction:"$TooLate"}}
		});

In this example, the email will expire in 2:30 minutes, the player won't have the option to cancel the expiry, and option 3 only becomes available when the email expires.

Another question: do you think "Logs" is the place to put this functionality? Does it make more sense in "Ship Systems"? Open to suggestions here.

[Wildeblood]

Another question: do you think "Logs" is the place to put this functionality? Does it make more sense in "Ship Systems"? Open to suggestions here.

Yes, no. Not a ship system since it's only available at stations. (Although, if you went back to the purchased equipment, I wouldn't stand by that assertion.)

[Norby]

Category names in Interfaces are flexible, there are no strict rules here. I think "Activity" is better than "Logs" due to todo will be here, but a brand new category is good also.

[phkb]

Version 1.1.0 has been uploaded, link is in the first post. As previously noted, if you have the old version, and install this one, any email history will be lost as a new save methodology is in place. Gone also is the need to reconnect emails to their originating worldScript. Now you can pass the worldscript name and function name, and the email system will store this and call the correct procedure when executed.

New in this version is the expiry system, details as noted in previous posts.

As always, feedback is most welcome.

[Wildeblood]

I made this version of my Autotrade Report Screen plug-in so Autotrade can send you email reports of its activities.

Updated version now available at same link.