Zugg Software :: View topic

Posted: Tue Jul 15, 2008 3:38 am

I've been racking my brains trying to figure this out... yet I cannot for the life of me figure out why it's not working... I've converted everything I can think of, yet it refuses to display properly.

Let me back up a little - I've been trying to convert a bigmap script that was written by Fiendish. I thought it would be a rather easy task, but I was wrong. For a display of what it is supposed to look like, click here. There, you can also download the original file for zMUD, and maybe take a closer look there. Here is what I've converted it to so far (at least, I hope it displays correctly...):

Posted: Tue Jul 15, 2008 7:34 am

The first thing would be to say what doesn't work and how you expect it to? As well as some content to actually trigger it.

In addition you are missing the the open "<" bracket in your code tag.

Posted: Tue Jul 15, 2008 12:26 pm

Well, for starters, click on the link I put up there. It's too... exhausting to explain in detail, to say the least. But I'll try.

On Aardwolf, we have continents. Within each continent, there is a "bigmap," and that is displayed with the "bigmap" command. An example of what a bigmap would look like is found by typing "vidblainmap" after installing this script. The reason why Vidblain's map is in there is because it's much different than other maps.

What this script does is takes a map, writes all the lines to a file, then returns those lines back into the Continents window, except it also adds your current position on the map. What it does is not even close to what it's supposed to do. Instead of a map, I'm left with "Location: 32, 20 *" (different variations of it, anyway). That's why I put the link up there - so you can see what it's supposed to look like. As for actual text, the only way I can tell you to do that is by logging into Aardwolf, run 2s9e, and it should automatically update. I'd put the map here, but that would mean using a LOT of %ansi(color) functions because it's based on color...

Charneus

Posted: Tue Jul 15, 2008 5:08 pm

It's possible that the problem is still with #PSUB since I still haven't tested that on Aardwolf with the other problems that were reported for it.

But honestly, why are you using #PSUB at all? #PSUB performs substitution on the text that is already displayed to the window. It is slow because it has to fetch the text from the window, then change it, then update the window.

Since you are capturing the data to send to the Continents window into an array, why don't you manipulate the lines *before* they are sent to the Continents window. Like using %subregex or other string functions. That will be much faster and more reliable.

But I'll really try to check the #PSUB command later today to see if it has a bug that is causing this problem.

SubAdmin Joined: 18 Nov 2001 Posts: 5182

In the drawmap alias:
#PRI {
commands
}
should be reduced to just the commands as #PRIORITY is no longer needed.
I would suggest changing the #ABORT 1 in that section to #EXIT
This:
currentmap.%i=%read( 3)
#WINDOW CONTINENTS %e[0m%arrget( currentmap, %i)
should probably be
#CALL %arrset(currentmap,%read( 3) ,%i)
#WINDOW CONTINENTS %e[0m%arrget( currentmap, %i)

I don't actually see why it needs to hold on to the entire map in memory, also the triggers that preform the capture are only sending it to the file, I would think #CAPping it to the sub window would be appropiate.

You might use the ANSI/VT100 positioning code to eliminate the need of #PSUB, the code is %e[x;yh

Posted: Tue Jul 15, 2008 9:42 pm

I haven't found any problems with #PSUB yet with my testing of this.

Some other "cleanup" suggestions is that you can get rid of most of your %evals. For example:

Wanderer Joined: 19 Nov 2005 Posts: 53

Posted: Tue Jul 15, 2008 10:51 pm

I thought I had got all the priorities out of there, but it appears I've missed a couple. But let me go into a bit more detail as to what this does, and maybe why it needs to hold it in memory plus the usage of #PSUB (though again, I'm sure there are better ways). Again, I'm just converting this over from a zMUD script. The original author IS Fiendish, and he could probably explain it much better than I could.

The purpose of the bigmap is so you can see where you are on the continent. It helps when you're a bit lost and want to know how to get to the next area. An example of what one of the maps looks like is this:

Posted: Tue Jul 15, 2008 10:51 pm

Yes, using the memory data is faster than accessing the disk, so that part is fine. And I understand better now what you are doing. Yes, clearing and redrawing *would* be a lot slower and cause flicker...I didn't realize that it wasn't doing that.

So I assume that what you are doing is saving the current character at the current position, and then using #PSUB to put the * in the current position and then restore the previous character when you move? Is that how it works?

If so, the problem with using #PSUB might be with the red color tag that you are adding. How do you restore the original color of the original character when you move to a new location?

The %eval issue doesn't apply to zMUD because zMUD re-parses *every* line no matter what, which is why it's scripting is so slow. zMUD doesn't perform any script compiling. The %eval statements are absolutely required for zMUD because zMUD didn't perform evaluation automatically like CMUD does. My suggestions were for improving the conversion of the script to CMUD where you don't need all of the %eval kludges.

Wanderer Joined: 19 Nov 2005 Posts: 53

SubAdmin Joined: 18 Nov 2001 Posts: 5182

Ahh, now it all makes sense. I would definitely suggest using the VT100 codes for this instead of #PSUB. A link that give details for all of them is here. The only one you really need is the postitioning, as redrawing the entire line will overwrite anything present. Since you use a #CLR when displaying a new map, and all text displays into the window are controled by your script you don't actually have to worry about cursor positions at the end of the line.

For both zMud and CMud I would reccommend using the %arrset I mentioned above, directly #CAPTURE the map to the window at the same time as capturing it to disk, and also during that capture you should capture it to memory. I would also suggest using a naming convention that can be handled through mininal substitution rather then a complex #IF/#SWITCH series.

For CMud, I would further suggest making all variables use default values, to increase speed.

Posted: Wed Jul 16, 2008 1:54 am

Posted: Wed Jul 16, 2008 2:04 am

An addition to this, however, is now it appears to be putting the red asterisk in the right place, however, it's not drawing the map at all. Therefore, all I'm seeing is a bunch of black space with a red asterisk in the middle. :P

Charneus

Wanderer Joined: 19 Nov 2005 Posts: 53

Posted: Wed Jul 16, 2008 10:49 pm

An update - I tried running the script using the new #FILE format above, and it kicked out this:

Wanderer Joined: 19 Nov 2005 Posts: 53

Wow. So doing

Posted: Fri Jul 18, 2008 6:03 pm

Keep in mind that %array, %arrget and %arrset are actually used to create and manipulate COM-based arrays. These are special arrays used in some Windows COM APIs. They weren't really intended for general purpose arrays. General purpose arrays in CMUD are string lists or database variables, which you can use the currentmap.%i syntax with. For example:

SubAdmin Joined: 18 Nov 2001 Posts: 5182

I think, in the instance of FiendishX's 2 code examples, it is because of the second one using only 1 COM call and it is eliminating the lookup. CMud would likely see the same gain from that particular change. CMud could actually use string lists successfully where zMud still had problems with list items containing the pipe character, which means that switching to lists in CMud would realize an even greater speed gain.

Novice Joined: 25 Aug 2009 Posts: 38

Did this ever get successfully converted? I'm tryign to convert over to cMUD, but I want my bigmap! :P I'm a mapping freak and it helps when making the maps in the automapper to know which map I'm on...