 |
Sabistik
Newbie
Joined: 19 Jun 2005
Posts: 1
Location: Poland
|
 Posted: Mon Jun 20, 2005 9:11 am
#SUBSTITUTE crashing
|
Hellow.
I have some problem with #sub function.
When i use some #sub`s in one line, with zmud option 'auto wrap' i have crashs.
I have three #triger`s:
| Code: |
#TRIGGER {(jednooki krzywonogi krasnolud)} {#sub {%1 (name1)}}
#TRIGGER {(malutki porywczy halfling)} {#sub {%1 (name2)}}
#TRIGGER {(ciemnowlosa zlosliwa elfka)} {#sub {%1 (name3)}}
|
Whene i got following text from mud:
"Jednooki krzywonogi krasnolud, bosa umorusana kobieta, malutki porywczy halfling, ciemnowlosa zlosliwa elfka"
And zmud wrap this txt, subtitite crashs. That looks like this:
This bug don`t show when text is in one line.
This very impede playing in game. ;p (it looks terrible with a lot of text and #sub`s)
What is wrong? How can i eliminate it?
Is this zmud error? or i bad use #sub function?
i have Zmud7.13a and winXP. This crash occur in all previous wersions too.[/img] |
|
Last edited by Sabistik on Fri Jul 22, 2005 8:34 am; edited 1 time in total |
 |
|
|
CJ
Newbie
Joined: 13 Jun 2005
Posts: 2
|
Posted: Fri Jul 22, 2005 8:01 am up up
|
Hi,
I'd like to bring up this topic, as this 'sub crashing' is a real pain in the... neck, as far as I'm concerned.
The problem comes down to this: when word wrapping is performed by client (mud sends long, unwrapped lines) and in one line several substitutions are triggered, the lines start "crashing" - as in the pics above, though they do not present all of the mayhem it may produce (the "crashing" can overflow to following lines, sometimes even making it necessary to restart zmud).
I suppose that zmud first wraps lines and later matches triggers and performs its actions. Therefore, if substitution caused a serious change in line's length, it does not fit anymore into the space given to it, so lines start overlaying themselves etc.
Now, is there any way to overcome this problem (eg. to force zmud to wrap lines after performing triggered actions), or should it be considered a bug and reported as such? |
|
|
|
|
nexela
Wizard
Joined: 15 Jan 2002
Posts: 1644
Location: USA
|
Posted: Fri Jul 22, 2005 11:37 pm
|
as an alternative try it with #PSUB and see if it goes away? #PSUB {%1 ~(name1~)} %x1
|
|
|
|
|
CJ
Newbie
Joined: 13 Jun 2005
Posts: 2
|
Posted: Sun Jul 24, 2005 4:06 pm
|
#PSUB most probably won't crash like described above (I've never tried forcing it to, but I suppose it'd be hard), but is not an answer either, both for the same reason: it does not "update" the %xn's according to the previous substitutions in the line.
Eg.
#tr {(text to sub one)} {#psub {%1 (substitution one)} %x1}
#tr {(text to sub two)} {#psub {%1 (substitution two)} %x1}
#sh text to sub one and text to sub two
Result:
text to sub one (subtext to sub two (substitution two)and text to sub two
Second substitution was made where it sholud be if there was no substitution number one was made - but as substitution one took place, the spot for sub two should be moved. PSUB did not notice.
While the result may look similar to the ones presented by Sabistik, it is actually something different. Using #sub in the example I gave will work just fine - looks like #sub is dealing well with the place of substitution being moved. It wrecks when line wrapping interferes - the substituted lengthened text is "squeezed" into a space ways too small for it - and havoc arises.
I am surprised, that the problem is not well known (or so it seems), as it is something I came about shortly after I had started using zMud. Many subs in a line are something quite handy I suppose. |
|
|
|
|
MattLofton
GURU
Joined: 23 Dec 2000
Posts: 4834
Location: USA
|
Posted: Sun Jul 24, 2005 5:17 pm
|
It's well-known, there's just no practical fix for it until Zugg fixes the bug.
|
|
_________________
EDIT: I didn't like my old signature |
|
|
|
|
|
|
