On the topic of CTI2 cards

[Simon]

So I was thinking about the ease and compatibility of CTI2 cards. Currently, the cards do most of the work, they're little programs in themselves. Fun, flexible, but not very practical. This is because CTI2 cards will need to be compiled into the viewer which means that they'll always be relying on the rest of the viewer. So I was wondering if instead of compiling the cards as little programs into the viewers, why not make the viewer follow instructions. An example:
Say we want a Stroke It cards which ups the strokerate by one each card until say, the next instruction card:
We can use an object:

Code: Select all

{
	info: {
		type: "Stroke It",
		text: "Hurry up! Add 1 to your strokerate every slide until the next instruction card. Also lube up!",
		deck: "Supplemental",
		artist: "Jack the Belter"
	},
	condition: { //a contion required for the card to be drawn (see initialize in the next code block)
		chastity: false, //checks if the player is in chastity for example
		item: {
			check: "available", //checks if a certain item is available, could also be something like "equipped" or "in_use"
			item: "lube"
		}
	},
	action: {
		data: "strokerate", //Or a number representing strokerate
		action: "+1", //first character representing a mathamatical function + for adding, = for setting or for formula's, - for substracting, * for multiplication, etc.
		on: "slide", //could be "instruction" or "all" or something else
		until: "instruction" //could be "end" (of tease) or "strokit", the next stroke it card.
		item: {
			item: "lube" //Yes, lube up!
			enabled: "true" //Put lube in use to true so other cards will be able to notice.
		}
	},
	after: {
		//instruction same-y to action for an action after completion of the card.
	}
}

We could also add extra code simply by adding another block to the object:

Code: Select all

	code: {
		action: {
			//some action not bound to an event occuring
		}
	},
	initialize: {
		//some action on loading the card, preferably before the card is ever drawn or the order of cards is decided.
	},
	query: {
		options: { //A query adding options to a card, could perhaps also be added in 'after' (see previous example)
			1: {
				text: "Yes, give it to me!",
				action: {
					//Some action which only happens when you select this.
				}
			},
			2: {
				text: "No, your examples are stupid.",
				action: {
					action: "noaction" //Nothing happens when you press this.
				}
			}
		}
	}

Now to summerize the pros and cons:
Pro's:

• Easy to read & write for everyone who's willing to put some time into this.
• Easy to integrate, you can have .json files just in a folder, instead of compiling them into the code.
• Easy to share, because they dont have to be compiled or anything.

Cons:

• Less flexibility, because the lack of direct programming POWAA!
• New work for 0131

Whelp I hope I was clear enough, let me know what ye think. ~ Simon

[​​/]

It's a much better alternative to what we have now, but the lack of programming would be a problem when creating more complex cards, because you'd be limited to stuff that's already programmed in the teaseviewer.
Here's how that card would look like in the teaseviewer I'm working on, which uses a scripting language called Lua.

Code: Select all

function on_setup()
	cti.this_card.add_required_item("lube")
end

function get_draw_probability()
	if cti.player.is_in_castity then
		return 0
	else
		return 1
	end
end

function on_activate()
	cti.player.is_lubed = true
end

function on_slidechange()
	if cti.current_slide.type == "instruction" then
		cti.this_card.active = false
		-- stops event handlers like on_slidechange from triggering,
		-- is automatically set to true on on_activate if the card
		-- has those event handlers

	else
		cti.player.add_strokecount(1)
	end
end

It's just as easy to share as json because there's no need to compile it, and it isn't very difficult to learn.

[Simon]

It's a much better alternative to what we have now, but the lack of programming would be a problem when creating more complex cards, because you'd be limited to stuff that's already programmed in the teaseviewer.
Here's how that card would look like in the teaseviewer I'm working on, which uses a scripting language called Lua.

Got to love LUA, always. You're right about the lack of flexibility in my solution. I'm also looking at it from a javascript standpoint: I'd like a format that can easily be created by a web-based card creator (wow, my secret project). Writing LUA from Javascript is slightly harder, but undoubtably possible. I also didn't want to propose a non-java solution because I don't want 0131's work to go to waste, but hey, you gotte do what you gotte do.

[0131]

Are you proposing an official CTI 2 - Script language? Never thought there would be so much demand on such a thing.

Your idea is good most if it sould be possible using plain uncompailed Java code.
Thats how my plan was for the future:

1. Write a card using Java Code like you do with the scripting language using some interfaces which are available for everyone.

2. Share the file.

3. Use an integrated tool in the teaseviewer to import & compile the card on the fly into the teaseviewer.
(you can already share compiled cards but thats not the best way i know)

4. Offer a simple editor for cti 2 cards to "click"-create your cti 2 card. (I also had the idea for a webtool )

Only difference i see here is that the user needs to have a Java + compiler installed. But therefore its more powerful to use compared to scripting.
Oh and it would be hard to make these cards work on non java-applications... but either distribution or power and i would choose power here as it was my goal to improve cti sessions.
Maybe i could write an interpreter if you come up with a good CTI - Scripting language for my teaseviewer to support both.
If this is the case we should give these cards another name maybe just "CTI - Script" cards.

[Simon]

Are you proposing an official CTI 2 - Script language? Never thought there would be so much demand on such a thing.

I wouldn't nessecarily call it a scripting language yet. I was thinking about an implementation in TeaseViewer to read the above example (JSON) files as cards. I may look into creating such a mod myself, but I'm really a bit of a goof when it comes to Java... A keyword language for the teaseviewer to read will be necessary and I'll be happy to help.