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

WinTin 2.00.6 reloading nested list variable problem

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



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

PostPosted: Mon May 02, 2011 10:17 pm    Post subject: WinTin 2.00.6 reloading nested list variable problem Reply with quote

I'm trying to put together a system to make jumps between seperate maps, and I have something that seems to work but I can't seem to save my data, a 'mapjump' table, between sessions.

The data is in the form of an associative list, each 'jump' has 5 data items, example as shown in the #var listing:

#VARIABLE {jump}={{farea}{test1}{fvnum}{1}{name}{TG1}{tarea}{test2}{tvnum}{1}}

And then I put several of these (four in this case) into another list so I get the following:

#VARIABLE {mapjumps}={{1}{{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}}{2}{{farea}{test1}{fvnum}{18}{name}{TG1}{tarea}{test2}{tvnum}{14}}{3}{{farea}{test2}{fvnum}{14}{name}{TG1}{tarea}{test1}{tvnum}{18}}{4}{{farea}{test2}{fvnum}{15}{name}{TG2}{tarea}{test1}{tvnum}{15}}}

I can save it (and also everything else because I can't see how to selective write only some things) into a file with #WRITE - maybe I should get a better understanding of #CLASS but thats a different problem.Confused When I #READ the data in from file the #var display is identical but trying to access the information gives null results, apart from &mapjumps[] and #list mapjumps size var which does return the correct number (of entries).

I note that the data is stored in file as:
Code:
#VARIABLE         {mapjumps}  {{1}{{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}}{2}{{farea}{test1}{fvnum}{18}{name}{TG1}{tarea}{test2}{tvnum}{14}}{3}{{farea}{test2}{fvnum}{14}{name}{TG1}{tarea}{test1}{tvnum}{18}}{4}{{farea}{test2}{fvnum}{15}{name}{TG2}{tarea}{test1}{tvnum}{15}}}

I also note that there is always two space characters between variable and data in files and each line ends with no spaces and a LF only (Unix format); if #message is turned on I see those spaces are still there as the information is parsed (artificially changed to '_' here):

#OK. VARIABLE {mapjumps} HAS BEEN SET TO {__{{1}{{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}}{2}{{farea}{test1}{fvnum}{18}{name}{TG1}{tarea}{test2}{tvnum}{14}}{3}{{farea}{test2}{fvnum}{14}{name}{TG1}{tarea}{test1}{tvnum}{18}}{4}{{farea}{test2}{fvnum}{15}{name}{TG2}{tarea}{test1}{tvnum}{15}}}}.

A quick skim through recent posts suggests there may have been a problem with #list in 2.00.3 that was fixed in a later beta version - has sommat crept back in or do I have a real live bug here (or have I just pushed something to breaking point by using it in a way not anticipated by the designers)? Use your Head
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Mon May 02, 2011 11:09 pm    Post subject: Reply with quote

I can't reproduce this. The spaces aren't a problem, just a displaying issue, though I should probably fix it. After #write and #read I can still access the content:

Code:

#var
################################## VARIABLES ###################################
#VARIABLE {mapjumps}={{1}{{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvn
um}{15}}{2}{{farea}{test1}{fvnum}{18}{name}{TG1}{tarea}{test2}{tvnum}{14}}{3}{{f
area}{test2}{fvnum}{14}{name}{TG1}{tarea}{test1}{tvnum}{18}}{4}{{farea}{test2}{f
vnum}{15}{name}{TG2}{tarea}{test1}{tvnum}{15}}}

#showme $mapjumps[1]
{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}

#showme $mapjumps[1][farea]
test1
Back to top
View user's profile Send private message Send e-mail
Slysven



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

PostPosted: Tue May 03, 2011 9:29 am    Post subject: Reply with quote

Humm, after seeing how you can access the individual elements within the nested list variable 'mapjump' and applying it to my code I seem to be getting the right results. Though I may be a bit confused, what is the difference between #SHOWME and #ECHO:
Code:
#showme $mapjumps[1]
{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}
#echo $mapjumps[1]\n
{}{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}
#echo $mapjumps[1]
farea#echo $mapjumps[1]

Note that for the second #ECHO - without the trailing newline, the cursor is left ontop of the first character on the bottom line ('f') and only one 'thing' is shown as well as the original command being echoed. Also, what is with the empty {} at the beginning of the first #ECHO's output?

#SHOWME seems to behave reasonably for any argument put to it:
Code:
#showme $mapjumps
{1}{{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}}{2}{{farea}{test1}{fvnum}{18}{name}{TG1}{tarea}{test2}{tvnu
m}{14}}{3}{{farea}{test2}{fvnum}{14}{name}{TG1}{tarea}{test1}{tvnum}{18}}{4}{{farea}{test2}{fvnum}{15}{name}{TG2}{tarea}{test
1}{tvnum}{15}}
#showme $mapjumps[2]
{farea}{test1}{fvnum}{18}{name}{TG1}{tarea}{test2}{tvnum}{14}
#showme $mapjumps[2][tarea]
test2

Whereas #ECHO:
Code:
#echo $mapjumps
1#echo $mapjumps\n
{}{1}{{farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}}{2}{{farea}{test1}{fvnum}{18}{name}{TG1}{tarea}{test2}{tv
num}{14}}{3}{{farea}{test2}{fvnum}{14}{name}{TG1}{tarea}{test1}{tvnum}{18}}{4}{{farea}{test2}{fvnum}{15}{name}{TG2}{tarea}{te
st1}{tvnum}{15}}
#echo $mapjumps[2]
farea#echo $mapjumps[2]\n
{}{farea}{test1}{fvnum}{18}{name}{TG1}{tarea}{test2}{tvnum}{14}
#echo $mapjumps[2][tarea]
test2
#echo $mapjumps[2][tarea]\n
test2

Thank you for you past prompt replies it has really helped me - I'll try and post my map jumping scripts when I have ironed out the niggles...! Bye
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Tue May 03, 2011 7:06 pm    Post subject: Reply with quote

#echo combines #format with #showme, see #help echo. The weirdness you're seeing is because of substitution order. It's most obvious when using:

Code:

#showme $mapjumps[1]

#showme {farea}{test1}{fvnum}{15}{name}{TG2}{tarea}{test2}{tvnum}{15}


The 2nd call basically means: show "farea" at row "test1", as test1 isn't a number it's displayed on row 0, which is the input line.

Guess I shouldn't have used #showme in that example as the correct way to display nested variables is:

#variable mapjumps[1]
Back to top
View user's profile Send private message Send e-mail
Slysven



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

PostPosted: Tue May 10, 2011 7:15 pm    Post subject: Still got problems but found a workaround and more details Reply with quote

I did some further investigation - I found that if I inserted a new element into my nested list variable $mapjumps with:

#list mapjumps insert -1 $jump

none of the elements of the new n'th entry from $jump showed up if I use #echo to return the data either as the whole thing: #echo {$mapjump[n]} or individually eg: #echo { %s } $mapjump[n][farea]: the entries existed but null data was displayed.

#showme works fine on the same things and using #var to see all variables shows the right things too.

If I substituted 1 in the above #list command to put the new item as the 1st item of the list rather than the last it was still that entry that seemed to have null data.

What I initially found was saving everything and reloading produced no visible change in what "#variable" displayed but the data I added showed up with the previously non-working #echo commands above.
I also found that if I copied the variable to another tempory one and back using "#variable temp $mapjumps; #variable mapjumps $temp; #unvariable temp" this also corrected the issue.

What I'm thinking is (string) pointer issues...

As a side issue I also found that if I used the #list ... 'add' I had to surround my 'record' variable with TWO pairs of braces {{#jump}} otherwise the individual elements of that variable - 5x data items + 5x associated titles were each added as a seperate element to my nested variable $mapjump (and ALL of them showed up as null items when I tried to #echo the data held in $mapjump) - even after copying the data back and forth.

Also how would the #list ... 'sort' insertion method behave with this sort of data - what would it sort on - the alphabetic contents of $jump as a string as #showme would display it?

Can you tell me under what circumstances you are not able to reproduce the bug I'm getting? Sad
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Tue May 10, 2011 10:41 pm    Post subject: Reply with quote

#showme and #echo are really not the way to display nested variables.

#list sort is kind of out dated as tables are alphabetically sorted, but I assume it'd be sorted as the data shown with the #variable command.

Regarding the bug, there really is not a bug as tables aren't displayable variables. #echo loses data because it calls #format which saves the resulting data in a variable before #showme is called. #showme {{bli} {bla} {blo}} will have a different result than #echo which is the equivalent of: #variable result {bli} {bla} {blo};#line sub variables #showme {$result}


#list add takes multiple arguments, guess I should properly document that. If you execute: #list test add {bli} {bla} {blo} it will add those three items to the list. If you input a table it'll treat it as a list of items to be added.
Back to top
View user's profile Send private message Send e-mail
Slysven



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

PostPosted: Wed May 11, 2011 7:29 pm    Post subject: Reply with quote

Is it perhap unreasonable of me to try and store an array of multiple instances of a group of five different pieces of related data in one place in the first place? I see that associating each different piece of data within that group with a distict name is required to order the elements in the group when they are added to the table as otherwise the order could be indeterminate. Currently what I have (spaces and LF inserted just for readability here):

Code:
#VARIABLE {mapjumps}=
{
{1}{{farea}{Eye_of_World}  {fvnum}{9915} {name}{EF_} {tarea}{Emonds_Field}  {tvnum}{1}}
{2}{{farea}{Caemlyn}       {fvnum}{288}  {name}{CGN} {tarea}{Outer_Caemlyn} {tvnum}{37}}
{3}{{farea}{Outer_Caemlyn} {fvnum}{37}   {name}{CGN} {tarea}{Caemlyn}       {tvnum}{227}}
{4}{{farea}{Caemlyn}       {fvnum}{273}  {name}{CGE} {tarea}{Outer_Caemlyn} {tvnum}{2}}
{5}{{farea}{Outer_Caemlyn} {fvnum}{1}    {name}{CGE} {tarea}{Caemlyn}       {tvnum}{269}}
{6}{{farea}{Caemlyn}       {fvnum}{276}  {name}{CGS} {tarea}{Outer_Caemlyn} {tvnum}{54}}
{7}{{farea}{Outer_Caemlyn} {fvnum}{54}   {name}{CGS} {tarea}{Caemlyn}       {tvnum}{276}}
{8}{{farea}{Caemlyn}       {fvnum}{275}  {name}{CGW} {tarea}{Outer_Camlyn}  {tvnum}{150}}
{9}{{farea}{Outer_Caemlyn} {fvnum}{151}  {name}{CGW} {tarea}{Caemlyn}       {tvnum}{182}}
}

After I had a good thunk (past participle of think Big Smile ) I think I understand a bit more. Do you think then that for the above example it is reasonable to refere to items in the table by say using an expression such as:
#IF { "$mapjumps[$index][farea]" == "$mapareaname" }{ ... };#ELSE { ... } ?

Thanks for the incidental reference to the #LINE command - I hadn't previously spotted that as a means to write external data files, can I also apologise for dwelling on this subject area so much I hope it clarifies rather than obfusticates... Thumbs Up
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Wed May 11, 2011 8:49 pm    Post subject: Reply with quote

I'd suggest indexing by vnum:

Code:

#VARIABLE {mapjumps}
{

     {1}{{farea}{Outer_Caemlyn} {fvnum}{1}    {name}{CGE} {tarea}{Caemlyn}       {tvnum}{269}}
    {37}{{farea}{Outer_Caemlyn} {fvnum}{37}   {name}{CGN} {tarea}{Caemlyn}       {tvnum}{227}}
    {54}{{farea}{Outer_Caemlyn} {fvnum}{54}   {name}{CGS} {tarea}{Caemlyn}       {tvnum}{276}}
   {151}{{farea}{Outer_Caemlyn} {fvnum}{151}  {name}{CGW} {tarea}{Caemlyn}       {tvnum}{182}}
   {273}{{farea}{Caemlyn}       {fvnum}{273}  {name}{CGE} {tarea}{Outer_Caemlyn} {tvnum}{2}}
   {275}{{farea}{Caemlyn}       {fvnum}{275}  {name}{CGW} {tarea}{Outer_Camlyn}  {tvnum}{150}}
   {276}{{farea}{Caemlyn}       {fvnum}{276}  {name}{CGS} {tarea}{Outer_Caemlyn} {tvnum}{54}}
   {288}{{farea}{Caemlyn}       {fvnum}{288}  {name}{CGN} {tarea}{Outer_Caemlyn} {tvnum}{37}}
  {9915}{{farea}{Eye_of_World}  {fvnum}{9915} {name}{EF_} {tarea}{Emonds_Field}  {tvnum}{1}}
}


You can lookup if an index exists using: &mapjumps[1] &mapjumps[9915] etc.


It'd be easier to use one map file. If you only want one area shown at a time you could set the hidden flag on exits leading to other areas.
Back to top
View user's profile Send private message Send e-mail
Slysven



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

PostPosted: Thu May 12, 2011 6:53 pm    Post subject: Reply with quote

Nah, the whole point of what I wanna do is use seperate maps - I'm just working out a mechanism of how to string 'em together, obviously searching and running from one map to another is out: I do agree that one big map does have its advantages - but I was toying with 'selling' in game maps I make of different areas in the particular MUD as a craftsman...? There is something about not putting all you egss in one basket. Smile Of course it depends on whether the MUD players are using TinTin Cool or another client - some areas have been mapped by ZMud users and there are some pretty .jpgs of its mapper output I believe but ZMud goes against my open source inclinations. Wink

For that reason indexing by vnums may not be particularly useful as they would be duplicated between different maps. Of course if I ever got around to stitching the individual map files together I would have to write a stand alone utility to 'vnumber renumber' individual map files into non-overlapping vnumber ranges; probably be easiest just to add an integer but different number of 1000's onto all the vnumbers in the map file. But hey, let's burn that bridge once I've got to it.

No need for a reply to this - I'll just see where I can go with it...
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: Tue May 24, 2011 7:35 pm    Post subject: Well I've found one reason for separate maps...! Reply with quote

The rooms per unit area of a MUD is not always uniform. For example in the MUD I'm currently on I've mapped out a Town and seperately mapped the area around it - only to find that because there are many more rooms in the Town map I'm having a lot of difficulty stretching the rooms apart on the outside area map to get enough space to plop the town map inside. I've tried inserting a large amount of void rooms in to get all the Town gates to physically coincide for both maps but I can't distorting the outside one enough to marry the two together - instead I'll have to resort to using "#map exitflag <dir> hide on" on the rooms either side of the Town Gates. Nope

On the other hand the way of adding on an integer number of 1000 onto the inner map vnum numbers in the file for the inner map with a series of text replacements eg: replace "R { " with "R { 100" & "E { " with "E { 100" etc and then copying all but the first few lines of text in that file to the end of the other one did work to merge the files together.... Smirk Obviously this is a one-way, one-time process for any new area.

I note that when a new room is added to the map it seems to be allocated the next unused room number; this means that after editing here and there and stitching together different sections, the room numbers of adjacent rooms can end up being widely different and with gaps that make it less easy to iterate through all the rooms to find a detail with the "#map get <option> <variable>" command: I was wondering whether a "#map compact" would be relevent to squeeze out any gaps in the 'database' that holds the map data and return the total of rooms in use (c.f. "#map get worldsize <var>" which yields only the potential maximum of rooms) - if that can also renumber the individual room vnums in some sort of adjacency order it would be wonderful but an algorithum to do so is beyond me (and would probably not even justify placing on the bottom of the to do list)! Confused
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Tue May 24, 2011 8:53 pm    Post subject: Reply with quote

Adding compression would be too much trouble.

You can count the total number of rooms using:
Code:

#math total 0;

#loop 1 15000 cnt
{
  #map get roomvnum {tmp} {$cnt};

  #if {$tmp} {#math total $total + 1}
}


Last edited by Scandum on Tue May 24, 2011 10:11 pm; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail
Slysven



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

PostPosted: Tue May 24, 2011 9:51 pm    Post subject: Reply with quote

I was thinking of 'compaction' as getting rid of spaces in the sequence of room 'vnum's from 1 to whatever. Is that what you mean here by 'compression' - or do you actually mean using a data reduction technique to reduce the storage space used to hold the map data, of relevence particularly for map room descriptions which can be a significant chunk of the total quantity of data.

I think I understand the example you gave but shouldn't it be checking $tmp not $cnt in the #IF:

Code:
#math total 0;

#map get worldsize maxcnt;

#loop 1 $maxcnt cnt
{
  #map get roomvnum {tmp} {$cnt};

  #if {$tmp} {#math total $total + 1}
}

Is there any significance that you used #math total 0; rather than #variable total 0; ?
Back to top
View user's profile Send private message
Scandum
Site Admin


Joined: 03 Dec 2004
Posts: 3796

PostPosted: Tue May 24, 2011 10:23 pm    Post subject: Reply with quote

My mistake, it's indeed $tmp.

I meant compressing/condensing/compacting the vnum range.

It should be possible to script it by obtaining the data of the room with the highest vnum, delete the room, recreate the room (tintin should pick the lowest available vnum), and restore the info and exits from the saved data. Then repeat until nothing changes.
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