Card vs Viewer code questions

[Krell]

Hey, guys sorry I've been absent so long. I came to check on progress before Valentine's day in hopes that CTI2 would be closer to ready in time. So here I am hoping to help. Had some questions about how much of the coding is viewer/card side and other various questions.

I don't have much coding experience outside of basic scripting in BASH, DOS, and Python. I do know enough that I feel like we should have some basic standards for variables by now to where we could start pseudo coding simple to mid difficulty cards to be copy and pasted into our eventual CTI2 card creator.

From what I've been reading it sounds like almost everything is card side which would make the cards extremely flexible and powerful. However what I'm not seeing anywhere is any sort of standardization which is crucial when player made card will be holding so much power rather than the viewer itself.

If all I've said above is generally correct so far, I would like to propose some base standards for cards just so everyone is on the same page in the future when making new cards.

Before I go much further could someone clarify how much of card selection is handled by the viewer compared to code in the cards?

[0131]

Welcome back

Do you have / want acess to the git?

The easiest way to make it possible for others to implement cards in the near future would be to make all cards interface dependent.
This way we can give out the interface classes and the card class and people could start creating cards.
But there are serveral reasons why this might not be a good idea at this point...
1. There are still many changes in the software which could make cards obsolete and thats baaaad.
2. I would not like to see that compiled cards are exchanged here as that could be a security issue.

-> 1. I need more time, i am very busy currently but if you want to help we can talk about that.
-> 2. I have some plans to avoid the exchange of compiled cards. We can exchange uncompiled cards and let the teaseviewer software itself compile & add them.

I am not sure what you mean with standardization, ...
There will be some rules, like "Always respect the limits choosen by the user in the personalization menu" do you mean that?^^

[hajtos]

I think the standardization was the interface you spoke of and some set of APIs that would make most cards pretty straightforward to implement.
Examples would include some that you probably already have, like setStrokeRate(), getRandom(), but for example IgnoreCards(type, number) I don;t now if you have.

A well design set interface and APIs could make it possible for non-programmers to make cards as well.

As for the problem of exchanging compiled cards, the issue could be omitted by using a scripting language instead of java, but I suppose you have enough code to not want to switch like that.

[Krell]

I agree about not having cards pre-compiled and as long as there is either a built in compiler, or at least one made easily accessible, we should be fine.

Theoretically we should be able to easily stick together a simple drag and drop interface for non-programmers that spits out a non-compiled card (or even plain text) that can be pasted into a compiler.

The problem I have is that I suck at making functioning GUI's and have no solid working knowledge of Java. So the question becomes, if I throw together a good looking layout and some assets will someone else assist me in getting the thing actually functioning? Because my only other option would be to throw something script based together in a language I'm more comfortable in and translate as it builds which would defeats the entire purpose since it's supposed to be user friendly.

[Simon]

The problem I have is that I suck at making functioning GUI's and have no solid working knowledge of Java. So the question becomes, if I throw together a good looking layout and some assets will someone else assist me in getting the thing actually functioning? Because my only other option would be to throw something script based together in a language I'm more comfortable in and translate as it builds which would defeats the entire purpose since it's supposed to be user friendly.

I can help you with that sweet ass GUI, as long as you're happy with a web-app (and don't hate Bootstrap, it's much easier than throwing something together myself). I use HTML, CSS, JavaScript on a daily basis. Converting JavaScript (or plain text) input to Java (and compiling it) is very much possible, although I'll need to do some research on the topic as I go.

[Krell]

Wait there are programmers who don't look stuff up as they code? =P

In all seriousness though, I think I've come up with a simple outline of what this card maker will need at bare minimum.

-Selection chance
--default weight
--if and notif checks
-Picture/sound selection
--if/elseif checks
--else default picture/sound
-Description text and card info
-Variable/Flag changes caused by card

As you can see this would be for pretty simple cards rather than highly complex unique sets. Though an advanced view to see and edit the code manually for advanced users would be a nice addition if we could make it work.

Anyone see something I missed or things that would be nice to have outside the bare minimum?