TinTin++ Mud Client The TinTin++ message board

 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
TinTin++ Mud Client

2.00.5 bugs? Fixed except when saving changes to file.

 
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports
View previous topic :: View next topic  
Author Message
taizong



Joined: 19 Mar 2011
Posts: 15

PostPosted: Sat Mar 19, 2011 6:57 pm    Post subject: 2.00.5 bugs? Fixed except when saving changes to file. Reply with quote

I am using tt++ version 2.00.5 using the pre-compiled binary available for download on Mac OS X 10.6. I'm using Terminal.app to run tt++.

First off I want to say I LOVE tt++. A big hug to you developers and users. It's a fantastic MUD client. But there are a couple issues I'm having that are really annoying. In order of importance:

1. Sometimes my changes don't get saved. Extremely annoying, and has cost me lots of wasted time re-writing actions/aliases. I do #write myfile.tin

But if I get disconnected sometimes the changes are not saved? I will try to reproduce this if it's not a known bug.

Sometimes if I quit tt++, then relaunch it with "tt++ myfile.tin" my old aliases/actions come back. So is it not correctly keeping the aliases/actions after I get disconnected or something?

Fix thanks to Scandum:
Code:

#event {SESSION DISCONNECTED} {#write myfile.tin}


2. For some reason if there's a lot of text a line or two gets garbled. What gives?

Fix thanks to Scandum:
Code:

#config {packet patch} {0.5}



3. For some reason my colors are not working consistently on my MUD. They work fine in zmud FWIW.

Fix thanks to Scandum:
Code:

#config {color patch} on


Thanks!

Would it help if I compile tt++ from source?
Code:


Last edited by taizong on Wed Aug 08, 2012 10:27 pm; edited 4 times in total
Back to top
View user's profile Send private message
taizong



Joined: 19 Mar 2011
Posts: 15

PostPosted: Sat Mar 19, 2011 7:17 pm    Post subject: Reply with quote

Noticed 2.00.6 is out so I'll try to see if the bugs are still present in this version. From the release notes it doesn't look like they've been addressed though.
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Sat Mar 19, 2011 9:14 pm    Post subject: Reply with quote

Hiyas,

1. The general idea is to create triggers offline in a text editor, and using #read to load them. Especially when scripts get more complexed you'll find it difficult to write scripts without using a form of indentation. That's why tt++ doesn't autosave.

To address your specific issue, the following trigger will automatically save your changes on disconnect:

#event {SESSION DISCONNECTED} {#write myfile.tin}

2. The problem is likely caused by packet fragmentation. You could try something like: #config {packet patch} {0.5}

3. How exactly aren't they working consistently? On some MUDs color data is lost when using #split, this can be fixed by using: #config {color patch} on
Back to top
View user's profile Send private message Send e-mail
taizong



Joined: 19 Mar 2011
Posts: 15

PostPosted: Tue Mar 22, 2011 7:08 pm    Post subject: Reply with quote

Wow, scandum, you just fixed all 3 of my problems in a single reply.

It would be nice if this information was in a FAQ somewhere or something (maybe it is? -- I couldn't find it though)

Now my text is working perfectly, my colors are working perfectly, and I'm assuming that autosave will work as well Smile I will keep backups just in case though hehe.

I am getting to the point where I think writing triggers offline would be quite useful. So is the idea to basically create separate scripts for each trigger and then do #read myscript.tin? How would I read them all in at start-up?

Many, many thanks.
Back to top
View user's profile Send private message
Chicomecoatl



Joined: 08 Sep 2009
Posts: 73
Location: Kansas

PostPosted: Tue Mar 22, 2011 9:12 pm    Post subject: Reply with quote

I do it a bit more convoluted, but it works very nice.

I do

Code:

#read <char>.tt


and inside <char>.tt it does:

Code:

#ses <ses_name> <ses_addy> <port>;name;password;

#read <char>_vars.tt; /* read variables into local memory*/

#list {classes} {size} {class_size};
#loop 1 {$class_size} {class} {
#class $classes[$class] read $dir/$classes[$class].tt
}


Where classes variable contains all my classes. And dir variable holds the path to my class scripts. (ie, #var {dir} {/home/colby/tintin/Classes/Aardwolf/Chicomecoatl}
_________________
Chico
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
taizong



Joined: 19 Mar 2011
Posts: 15

PostPosted: Wed Aug 08, 2012 10:23 pm    Post subject: Reply with quote

Scandum wrote:
Hiyas,

1. The general idea is to create triggers offline in a text editor, and using #read to load them. Especially when scripts get more complexed you'll find it difficult to write scripts without using a form of indentation. That's why tt++ doesn't autosave.

To address your specific issue, the following trigger will automatically save your changes on disconnect:

#event {SESSION DISCONNECTED} {#write myfile.tin}


Still having a problem with this unfortunately, even though I set the following events:

#event {PROGRAM TERMINATION} {#write myfile.tin}
#event {SESSION DEACTIVATED} {#write myfile.tin}
#event {SESSION DISCONNECTED} {#write myfile.tin}

My file is still not keeping it's state, it's losing changes when I rent/disconnect, etc! Very confusing/annoying.

I'm now using version 2.00.8 on FreeBSD.
Back to top
View user's profile Send private message
Slysven



Joined: 10 Apr 2011
Posts: 365
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK

PostPosted: Thu Aug 09, 2012 7:13 am    Post subject: Reply with quote

Well one almost solution is to have an #EVENT or #TICKER that saves everything to a backup file periodically - that is not perfect as obviously it'll lose stuff that might have changed since the last backup - but for instance it can prevent you losing everything from a session. For instance I use the following to backup MAP data (if I'm on-line and not tweaking it locally when not connected) every 5 minutes... :
Code:
#TICKER  {MapAutosave} {#IF {"$ingame"!="no"}{#MAP WRITE $mapname.mpt}} {300}
But this can be extended to scripts as well.

Writing/modifying scripts off-line is a great way to do it, especially with a multiple window editor which can display the current script files you are using from which you can copy individual #ACTIONS/#ALIAS etc. into a transfer file and just #READ that one in to update the live version in use. However, particularly with #ACTIONs but also with other types of command, if you modify the first name or arguments to those commands you may need to remember to #UN<command> the original if it does not work as you wish before planting in the new one. Easiest way is to copy the #<command> <arguments...> part when you copy the #<command> into the transfer file, stick an "UN" at the beginning and a ';' on the end of the line and position it on the line BEFORE the #<command> before you start to amend the latter. Thumbs Up

WinTin++ / TinTin++ on Cygwin users may find Notepad++ a useful GPLed editor for this (set EOL type to "Unix", and Encode to "ANSI" or "UTF-8 without BOM" as appropriate for your setup).

Just remember to find a safe place to do this in-game so you don't get attacked by the enemy whilst you are distracted by tweaking your gaming environment. Smirk
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Thu Aug 09, 2012 4:36 pm    Post subject: Reply with quote

taizong wrote:

Still having a problem with this unfortunately, even though I set the following events:

#event {PROGRAM TERMINATION} {#write myfile.tin}
#event {SESSION DEACTIVATED} {#write myfile.tin}
#event {SESSION DISCONNECTED} {#write myfile.tin}

My file is still not keeping it's state, it's losing changes when I rent/disconnect, etc! Very confusing/annoying.

I'm now using version 2.00.8 on FreeBSD.

The PROGRAM TERMINATION event is probably the reason why you're losing changes as it saves the settings of the startup session, and not your mud session.

There's also no real reason to have the SESSION DEACTIVATED event and it can cause the same problem as with PROGRAM TERMINATION if you switch in and out of the startup session by using #gts.
Back to top
View user's profile Send private message Send e-mail
taizong



Joined: 19 Mar 2011
Posts: 15

PostPosted: Thu Aug 09, 2012 10:48 pm    Post subject: Reply with quote

Scandum wrote:
taizong wrote:

Still having a problem with this unfortunately, even though I set the following events:

#event {PROGRAM TERMINATION} {#write myfile.tin}
#event {SESSION DEACTIVATED} {#write myfile.tin}
#event {SESSION DISCONNECTED} {#write myfile.tin}

My file is still not keeping it's state, it's losing changes when I rent/disconnect, etc! Very confusing/annoying.

I'm now using version 2.00.8 on FreeBSD.

The PROGRAM TERMINATION event is probably the reason why you're losing changes as it saves the settings of the startup session, and not your mud session.

There's also no real reason to have the SESSION DEACTIVATED event and it can cause the same problem as with PROGRAM TERMINATION if you switch in and out of the startup session by using #gts.


I do not use #gts (I think? I don't even know what that is...) but I do get kicked from MUD time to time.

I think the #event {SESSION DISCONNECTED} {#write name.tin} works if I RENT safely, but if I otherwise get disconnected/go LINKDEAD from the MUD (i.e. kicked from MUD by IMP, or session dies, etc.) then it will not work?

I just want to like have my settings saved to file regardless of whether I lose connection to the internet, rent safely, or get booted from the mud...
Back to top
View user's profile Send private message
Slysven



Joined: 10 Apr 2011
Posts: 365
Location: As "Jomin al'Bara" in WoTMUD or Wiltshire, UK

PostPosted: Fri Aug 10, 2012 10:37 am    Post subject: Reply with quote

My two cents worth on these #EVENT types:

When you first fire up TinTin++ you are in the "default" session which - for reasons unknown to me - is called "gts". This means that any #ALIAS/#ACTION/etc. (#EVENTS ?) that you type in at this point belong to the "default" session until you start a new session with the #SESSION <name1> <ip/url> <port> ... command. Of course you can run multiple sessions with different names if the MUD you are playing permits multi-playing (many do not!) [ or if you are really weird and want to play two MUDs at once Confused ] and you change between which session is currently receiving your attention with e.g. #<name1> and #<name2> (And you can also take a peek at a different session with #SNOOP... I believe). In the background there is always also the "gts" session which you can access with "#gts". If the session you are using is terminated for whatever reason, I think the screen will clear and drop you back to the default one when you hit any key.

I hope this might help to explain that the #EVENT {SESSION ACTIVATED} / {SESSION DEACTIVATED} belonging to each session are run as you switch between different sessions and the data they work with is that of their particular session. So if you are in a session you have called "foobar" if you use #gts you will trigger any #EVENT {SESSION DEACTIVATED} event for "foobar" with all the data for that session then trigger any #EVENT {SESSION ACTIVATED} for the default "gts" using data specific to it.

In the same way #EVENT {SESSION CONNECTED} / {SESSION DISCONNECTED} are fired as a particular session starts / ends, though it can be counter-intuitive to LOAD the former as by the time the #SESSION has connected it is too late to set an event to fire upon it starting. I think the way to do THAT is to have an #EVENT {SESSION CONNECTED} in the #gts default which gets inherited by the sessions that are started from it.

Finally #PROGRAM {START} / {TERMINATION} get fired as TinTin++ (or more probably the "gts" default session) starts / ends and to get around the chicken-and-egg situation that a command to execute as the program start implies, the first can only be used by it being in a file that is read in as specified on the command line (in Linux or Cgywin environments with the "-r filename" arguments).

Quick final thought - use a different filename, (and use a variable in the name which you can set to a different value in the #gts and your normal session) for the different #EVENTS so they don't clobber each other - then see afterwards which one has saved the things you want!
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Fri Aug 10, 2012 4:29 pm    Post subject: Reply with quote

gts stands for 'global tintin session' I had to name it something. Smile

taizong wrote:

I think the #event {SESSION DISCONNECTED} {#write name.tin} works if I RENT safely, but if I otherwise get disconnected/go LINKDEAD from the MUD (i.e. kicked from MUD by IMP, or session dies, etc.) then it will not work?

As far as I know it will always work.
Back to top
View user's profile Send private message Send e-mail
Metaljaz



Joined: 29 Dec 2009
Posts: 1
Location: Maryland-USA

PostPosted: Sun Aug 19, 2012 3:08 pm    Post subject: Reply with quote

I to am having the same problem using mac osx. Whenever I ctrl-d and end session then start tt++ up again all the actions and aliases that I have created are gone. I have tried writing them and saving them within the text editor as well as writing them and saving them while in the mud and I get the same results. Can't figure out why my myfile.tin file would be changed even with the actions and aliases saved.
Back to top
View user's profile Send private message Yahoo Messenger
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3770

PostPosted: Sat Aug 25, 2012 10:24 pm    Post subject: Reply with quote

Kind of hard to tell what your problem is.
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic   Reply to topic    The TinTin++ message board Forum Index -> Bug Reports All times are GMT - 5 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads Get TinTin++ Mud Client at SourceForge.net. Fast, secure and Free Open Source software downloads
TinTin++ Homepage

Powered by phpBB © 2001, 2002 phpBB Group