Tease AI General Discussion

[genome231]

Nice with the image tagger!!

Can someone tell me..
Found quite a few bugs with MiniScripts (Like a lot of other people)
Should I convert my scripts to @CallReturns?
Pro/cons?
Any known bugs/problems with @CallReturns?

Regards
Genome

[SensEx]

Found quite a few bugs with MiniScripts (Like a lot of other people)

What kind of errors?

Also @CallReturn doesn't behave like @MiniScript commands do.

An example,
When you're stroking and a mini script txt is called it will not stop it
With @CallReturn it will stop every actions you are doing

@MiniScript offers much more possibilities, haven't encountered any bug with it yet

[genome231]

Found quite a few bugs with MiniScripts (Like a lot of other people)

What kind of errors?

Also @CallReturn doesn't behave like @MiniScript commands do.

An example,
When you're stroking and a mini script txt is called it will not stop it
With @CallReturn it will stop every actions you are doing

@MiniScript offers much more possibilities, haven't encountered any bug with it yet

This is one example that will crash a MiniScript
Choosing 1 or 2 Then choosing return will kill your script
Because it cant move "up"

Code: Select all

(Base)
Choose 1 or 2
[1]@NullResponse @Goto(2)
[2]@NullResponse @Goto(1)
@DifferentAnswer 1 or 2
(1)
End or return
[end]@NullResponse @Goto(End)
[return]@NullResponse @Goto(Base)
@DifferentAnswer end or return
(2)
end or return
[end]@NullResponse @Goto(End)
[return]@NullResponse @Goto(Base)
@DifferentAnswer end or return
(End)
@End

Other annoying things are when ending one out of multiple MiniScripts it will end ALL of them, not just return to previous.
Launching a MiniScript from custom/module is also a bad thing since it wont return you to the line from where it was launched.


I dont agree that you can do more with MiniScripts.
They just work differently than @CallReturns.
Written about 300 @MiniScripts so far :P Quite familiar with how they work

Regards
Genome

[SensEx]

This is one example that will crash a MiniScript
Choosing 1 or 2 Then choosing return will kill your script
Because it cant move "up"
Genome

Ok that is not good at all.
I will do some testing tonight with @MiniScript mixed with other commands.
My personality being heavily dependent on it to communicate with you...

Oh well, it is our job to find ways around these things to express our creativity!

Thanks for letting me know this,
you've probably saved me hours of scripting something buggy

Genome... Do you might have a list of all known bugs @MiniScript gives?
I'm sure a lot of people working quietly on their own personality will appreciate if you could publish a list here.
It will also help 1885 when he returns to have everything in one place.

[genome231]

This is one example that will crash a MiniScript
Choosing 1 or 2 Then choosing return will kill your script
Because it cant move "up"
Genome

Ok that is not good at all.
I will do some testing tonight with @MiniScript mixed with other commands.
My personality being heavily dependent on it to communicate with you...

Oh well, it is our job to find ways around these things to express our creativity!

Thanks for letting me know this,
you've probably saved me hours of scripting something buggy

Genome... Do you might have a list of all known bugs @MiniScript gives?
I'm sure a lot of people working quietly on their own personality will appreciate if you could publish a list here.
It will also help 1885 when he returns to have everything in one place.

First! I discovered something new about it
See my latest post in this thread:
viewtopic.php?f=2&t=16203&start=210

So far the bugs known to me are as I wrote
If you have modules/links whatever in your customfolder. You can call a miniscript inside one of these but you cant return to the custom module/link. It wont return to the line it should (See post, others wrote about it).
Lets say that you inside a module have launched miniscript1 then from there miniscript 2 and again miniscript 3.
If you end miniscript3 it will go back to point of origin which is the module. It will end ALL your miniscripts :)

Regards
Genome

[mrcom4t]

Lets say that you inside a module have launched miniscript1 then from there miniscript 2 and again miniscript 3.
If you end miniscript3 it will go back to point of origin which is the module. It will end ALL your miniscripts :)
Genome

When any Miniscript reaches @End, it will return to where the program first entered "Miniscript mode".
You can nest as many Miniscripts inside of each other as you want, but as soon as one gets to @End you will be back where you started. If, Miniscript1 has choices in it that lead to Miniscript1a, Miniscript1b, and Miniscript1c those can only get back to Miniscript1 at the first line. They will never return there on their own.

Compare it to digging a hole. No matter how far you dig, you have to climb out before you can try to fill it in.

[avatarbr]

Found quite a few bugs with MiniScripts (Like a lot of other people)

What kind of errors?

Also @CallReturn doesn't behave like @MiniScript commands do.

An example,
When you're stroking and a mini script txt is called it will not stop it
With @CallReturn it will stop every actions you are doing

@MiniScript offers much more possibilities, haven't encountered any bug with it yet

You can use this in any script to check the stroke state:

Code: Select all

@NullResponse @CheckStrokingState
(Sub Stroking)
Stop stroking #SubName @StopStroking
(Sub Not Stroking)

I think the big difference its in @MiniScript, the image dont change each line (Not sure, because I think I saw changing and not changing).

[SensEx]

You can use this in any script to check the stroke state:

Code: Select all

@NullResponse @CheckStrokingState
(Sub Stroking)
Stop stroking #SubName @StopStroking
(Sub Not Stroking)

I think the big difference its in @MiniScript, the image dont change each line (Not sure, because I think I saw changing and not changing).

What would make more sense at this point is, making templates.
Test commands to see how they function and communicate, not just "how we think they do"
Some bug described previously doesn't seem to be actual bug but miscomprehension on how commands were designed to function.
Which is understandable, we have tons to work with

Your script to check the state gave me an idea avatarbr.
Thank you, mrcom4t for your explanation

I'm going to create few scripts to test the most commonly used commands and simulate the whole process (complete cycle) before I write anymore lines.

[blah824389750732]

Not sure if this has been reported before, but the save/restart session options do not appear to be working, it will give me an error after saving and try to restart that the savestate file is not found, yet when I look for that file, it's there.

EDIT 1: Nevermind, just searched through the forums to see that this was mentioned previously.

[Sisyphuster]

We still in the planned break on dev of this project?

[Drblaze2]

To be honest, I think we are beyond the break now. Not quite sure what the future holds for Tease AI

[VanHellsing]

I think it's about time for the community to take over the project for real and don't stop developing it (not just until 1885 comes back). I respect 1885 for what he did, but there hasn't been much going on for almost a year now and 1885 being online for maybe a month with several monts of absence every time is the reason.

It looks like everybody is trying to stay away from developing community edition of TEASE AI out of respect to 1885. He said the community should take over the project if he doesn't show up for 3 months, and he's been absent for longer than that 2 times now. He also said last time, he'd like to focus on the TEASE AI personality he's creating than the program itself, so TEASE AI being developed by the community shouldn't be a big problem when he comes back next time.

It's not like we're cutting him off - he can always join the developers team.

[genome231]

Hey guys!

Asking about oppinions and wether its possible or not xD
I like writing scripts for tease-Ai. But one part that always annoys me just a Little bit.
Is that I cant really put "secrets" or put something behind a password in the script, because well basicly everyone can just open them Up an see whats inside :)
I think it would be awesome if you could encrypt them so that they cant be read by you, but by tease-Ai :)

Thoughts?

Regards
Genome

[OxiKlein]

Hey guys!

Asking about oppinions and wether its possible or not xD
I like writing scripts for tease-Ai. But one part that always annoys me just a Little bit.
Is that I cant really put "secrets" or put something behind a password in the script, because well basicly everyone can just open them Up an see whats inside :)
I think it would be awesome if you could encrypt them so that they cant be read by you, but by tease-Ai :)

Thoughts?

Regards
Genome

Well, as much as I like the idea of this, I am unsure of how to accomplish such a task. I can't think of a plausible solution, though I'll post my thought process and ideas with my concerns for each.

1. Password-Based Authentication

Scenario: Window to encrypt and/or decrypt a script with a given password.

Issue: A password would need to be in the script or Personality folder somewhere to unlock the content. How can the key be transmitted to Tease-AI without it being visible to the user? Even if the content itself appears as scrambled nonsense when opening the script, the password itself would need to be stored in plaintext somewhere.

Solution: No solution I can think of. This is simply security through obscurity.


2. Obfuscation by input only

Scenario: Window to encrypt scripts with a given password. There would be no option to decrypt scripts, only Tease-AI could decrypt to its memory while reading the script.

Issue: This would be a pain for scripters to work with. Just like the end-users, they also would not be able to decrypt their scripts when it came time to change or add a feature. With constantly evolving scripts over the course of development, being unable to decrypt the parts of scripts that are already encrypted could be a hassle.

Solution: The easiest way to solve this is that scripters could simply make a copy of any parts of the script before they are encrypted and put them in another file, allowing for changes to it to be sent back through. If you lose the copy, however, there would be no way to retrieve what was originally input.



These are the only methods I can think of after brainstorming and, personally, neither of them are appealing with the downsides of each.

[pepsifreak]

Yeah if someone wants to peek, they are gonna peek. Being open source there isn't anything that can really be done that couldn't be reversed by someone with the know-how.

Same kinda idea with the token system, it's easy to go in and give yourself thousands, so everyone just has to trust the user won't do that.

That said, assuming the user isn't very technical, you could try making scripts hidden in windows with Right Click>Properties>Check "Hidden".
Or something a little more advanced, @Call and @CallReturn currently requires that the file extension be included, so you could finish your script and rename it "script.jpg" then use it that way (I just checked and this does work). That way, you can't simply double click and have it open as text like usual, requiring extra effort to open, which might be enough to stop some users from peeking