Jump to content
Eternal Lands Official Forums
ttlanhil

The Minimap

Recommended Posts

Original thread (Not posting there because it's so old and a lot has changed since then. A lot of the work for the minimap was already provided by Frak, which has saved a lot of time for me)

 

Now. Since the client update, when not fixing numerous bugs, one of the features I've been working on is the minimap.

For anyone who compiles CVS, you should be able to simply enable MINIMAP and use it (alt+m to open the window). I commit my progress to CVS every now and then... But be warned, some things that don't work correctly will get commit'd. This won't include anything that can cause a crash, but there are some known issues with zooming that are being worked on.

If anyone does get a crash, as usual, please post a backtrace with as much relevant information as possible.

 

As indicated above, there is now zooming. This is still being finished up (when you are at no zoom on IP and go to WS, you will be zoomed in, because of the way it currently records zoom level. This will be fixed).

Each time you zoom in, you decrease the visible area to a quarter. If you could see the whole map (no zoom) one zoom factor will show you a quarter of the map.

When you are zoomed in, the minimap will centre on your character (but since you don't really have a need to see beyond the edge of the map, if you're near it, you will see less map as the 'great unknown' takes up more screen space).

 

There are buttons to go to max zoom, increase zoom, decrease zoom, no zoom.

 

There is the ability to 'pin' the window, so that alt+d doesn't close it (I don't know if anyone else will use this, but I like having the minimap open and I'm used to using alt+d when I leave the storage. This combination was driving me nuts until I added the 'pin' option :happy: ). This is the next button down.

 

There is a plan for the window to be able to be always on top. Even if you have your inventory, for example, in the same part of the screen, the minimap will be drawn above it. This doesn't work yet (the button will toggle the icon, but that's all). This is the next button down.

 

And the last button is to toggle fog-of-war/exploration-display. I'll explain.

Back when this was first being worked on, there was a plan for a 'shared vision' perk that would let you see what your guildies saw. The way this would work is that you would have actor information for the minimap around yourself as well as around guildies on the same map. This didn't end up happening.

As such, Entropy told me that he was unsure whether players would be interested in the fog-of-war... Not only that it no longer does much, but also that it's wrong. Y'see, the perception change at night means the unchanging radius(footnote) of the fog-of-war won't always indicate the distance you will see people at.

I still like the ring, even if it may not be accurate (so far it generally has been, but I haven't tested it on cape-of-camouflage or anything).

There's also exploration data. This shows the areas where you have visited while the minimap code is in effect (in other words, even if you've spent a year in VotD just walking around, it'll be a blank map when you first use the minimap :happy: ).

When I was talking about these features with Entropy, he said that he didn't think players would want this enabled. It does mean you can't see as much of the map around you.

On the other hand, I think it's nice to be able to tell where you haven't been yet, once you've used it for a while and your regular walking is marked.

So the two above (they could have been made separate options, but it would have been a bit more complicated) are toggleable. You can see the full map like on <tab> with dots for people, or you can have the map with areas you haven't visited black and areas you can't see darker than normal.

 

Originally, the minimap was going to use the colour of the guild tag for drawing the dots for where people are. I've done away with this, since it would make it a lot harder to tell where the dots are that actually are different. What are the different dot colours in use now?

Green: yourself (note below)

Yellow: animals and monsters

Red: PKable players (but not monsters. Even if the client seems to think that wolves are marked as PKable :) )

Aqua: someone in your buddy list

All others use the colour of the name (not the tag).

This means most players will be white dots, bots are purple dots, and (theoretically, since I haven't seen it) mods in demigod mode are green and invasion monsters will be red (yes, I know these colours are taken :) )

 

And at some stage, there'll be dots for where landmines are as well. This will come as the landmine work is done.

 

Note that this is what's currently done, or planned. There may be more added, things may be changed, or removed. For example, it may turn out that players aren't shown unless they're very close or you cast a 'radar'-type spell.

 

There's a screenshot as an example Here.

 

Are there any relevant questions/suggestions?

 

Known issues, that will be fixed:

Above button doesn't yet work.

When zoomed, the exploration data can display incorrectly. This can show up as the data moving in the wrong direction, or extra black lines on the minimap, etc.

 

Footnote:

It really is a circle, even if you use CVS and see a square. You simply don't have circle.bmp . Just stick http://users.on.net/~gingerman/circle.bmp in $DATA_DIR/textures/ and change map and you should have a ring

Edited by ttlanhil

Share this post


Link to post
Share on other sites

For anyone who compiles CVS, you should be able to simply enable MINIMAP and use it (alt+m to open the window).

OK, I know this is a bit off-topic and not the input you asked for, but although alt+m might be the "obvious" shortcut for the minimap this is also one of the shortcuts which is taken by most window managers to minimize windows. How about alt+p, or ctrl-m? It doesn't need to be a good mnemonic, people will adapt - and if the minimap is good enough they won't switch it off anyway :)

 

Cheers,

maj

Share this post


Link to post
Share on other sites
OK, I know this is a bit off-topic and not the input you asked for, but although alt+m might be the "obvious" shortcut for the minimap this is also one of the shortcuts which is taken by most window managers to minimize windows. How about alt+p, or ctrl-m? It doesn't need to be a good mnemonic, people will adapt - and if the minimap is good enough they won't switch it off anyway :happy:
ctrl+m is kinda taken, y'know, manu window and all. :)

But you sorta proved the point that it doesn't have to be changed...

I imagine it will likely have a button on the HUD, and most people will simply use that.

 

ed: Also, it's not too off-topic.

The reasons why this is in Programming instead of General Chat are so that there are less casual browsers coming by to say "Cool" and "Me too!", hence making it harder to effectively deal with suggestions and questions; and so that other coders can see the thread and test it out.

I don't want too much chatter, but reasonable suggestions are still welcome.

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Working well, i like it!

 

but on topic.. ctrl-m etc. work if i press ctrl-m using left/right ctrl button, doesn't matter

 

however this only works if i use left alt+m, won't work if i press right alt+m :)

Share this post


Link to post
Share on other sites

I was thinking about perception here: Now perception only works on what you can see in your window. So the minimap only shows the things you can see already, why not doing it so that you can see things on the minimap that you can't see on the screen when you have very high perception? I know it would require some extra servercoding and some extra cpu usage etc from server, but not everyone has very high perception.

Share this post


Link to post
Share on other sites

Working well, i like it!

 

but on topic.. ctrl-m etc. work if i press ctrl-m using left/right ctrl button, doesn't matter

 

however this only works if i use left alt+m, won't work if i press right alt+m :)

 

I have that problem with Ubuntu at times, not just in EL but in various apps.

 

Havent got around to investigating it because I mostly use the left set of alt/ctrl anyway. Probably something to do with the keymap or something in xorg.conf *shrug*

 

S.

Share this post


Link to post
Share on other sites

Working well, i like it!

 

but on topic.. ctrl-m etc. work if i press ctrl-m using left/right ctrl button, doesn't matter

 

however this only works if i use left alt+m, won't work if i press right alt+m :)

It's because in key.ini, the mapping is to LCTRL (left control) m and not RCTRL m.

Share this post


Link to post
Share on other sites

The right ALT key is disabled in EL, because on some keyboards it's actually the AltGr key, and we don't have a reliable test for AltGr.

AltGr is required on some keyboards to be able to type common symbols, so given the choice between only having one ALT key even if your right one is only ALT, and having both, even though that causes trouble for some users, I think it should be obvious which we'll use :)

 

As for perception showing additional dots on the map... Maybe (perhaps a grey dot, no matter what type it is, since you can't see it but can sorta tell it's there). That's up to Entropy.

Share this post


Link to post
Share on other sites

The right alt key (Alt-Gr) is used for example on german keyboard layouts to access special characters like '@'.

 

I tried with the CVS version of yesterday, starting from "most zoomed out" it worked, but out of those 4 zoom levels only 2 worked for me - when zooming in further, most of the minimap went black, only leaving a small rectangle where the map was shown (but with the right zoom level). When I moved the minimap, the map below that rectangle moved too - kinda like doing a selection in gimp, then moving the background layer below that selection. I hope this is understandable, if not I'll supply screenshots :wub:

Pressing any button on the minimap didn't change that, changing maps didn't change it, closing and opening the minimap didn't change anything either. :-/

 

Would be cool IMO if you could also reserve a color for your map markers - just a colored dot, and when you mouse-over that dot it shows the "label" of the mark you made. Would that be possible?

 

Cheers,

maj

Share this post


Link to post
Share on other sites

Segmentation Fault with client compiled from CVS ( ~15 minutes old)

Only change made: enabled MINIMAP in make.defaults

As soon as I press alt+m, the client crashes; I've also totally deleted the source folder and got a fresh cvs, still same result.

 

Slackware 11.0

Graphic Card: Intel 915GM

 

$ gdb el.x86.linux.cvs.bin

GNU gdb 6.5

Copyright © 2006 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB. Type "show warranty" for details.

This GDB was configured as "i486-slackware-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

 

(gdb) r

Starting program: /opt/games/elc/el.x86.linux.cvs.bin

Failed to read a valid object file image from memory.

[Thread debugging using libthread_db enabled]

[New Thread -1217226400 (LWP 4913)]

[New Thread -1295533136 (LWP 4916)]

[New Thread -1304052816 (LWP 4917)]

CampfireEffect (0xbf42c88) created.

Deactivating effect 0xbf42c88(6139.87 > 182.25)

 

Program received signal SIGSEGV, Segmentation fault.

[switching to Thread -1217226400 (LWP 4913)]

0x00000000 in ?? ()

(gdb) t 1

[switching to thread 1 (Thread -1217226400 (LWP 4913))]#0 0x00000000 in ?? ()

(gdb) bt

#0 0x00000000 in ?? ()

#1 0x0808b2e0 in make_color_framebuffer (width=256, height=256, FBO=0x8334304, FBORenderBuffer=0x8334308,

FBOTexture=0x833430c) at framebuffer.c:63

#2 0x080ed81f in minimap_make_framebuffer () at minimap.c:88

#3 0x080eff69 in change_minimap () at minimap.c:861

#4 0x080f00ac in display_minimap () at minimap.c:883

#5 0x08092e7c in view_window (window=0x81b4f44, id=0) at hud.c:635

#6 0x0808ebfd in keypress_root_common (key=536871021, unikey=109) at gamewin.c:1251

#7 0x0808f2e2 in keypress_game_handler (win=0xc205060, mx=387, my=405, key=536871021, unikey=109) at gamewin.c:1492

#8 0x080846cb in keypress_in_window (win_id=0, x=387, y=405, key=536871021, unikey=109) at elwindows.c:1490

#9 0x08081dce in keypress_in_windows (x=387, y=405, key=536871021, unikey=109) at elwindows.c:491

#10 0x080878ca in HandleEvent (event=0xbfa69510) at events.c:95

#11 0x080a98da in start_rendering () at main.c:103

#12 0x080a9cc3 in main (argc=1, argv=0xbfa695f4) at main.c:247

(gdb) t 2

[switching to thread 2 (Thread -1295533136 (LWP 4916))]#0 0xb7e8699c in __nanosleep_nocancel ()

from /lib/tls/libpthread.so.0

(gdb) bt

#0 0xb7e8699c in __nanosleep_nocancel () from /lib/tls/libpthread.so.0

#1 0xb7f0d05a in SDL_Delay () from /usr/lib/libSDL-1.2.so.0

#2 0xb7f0d0c2 in SDL_Delay () from /usr/lib/libSDL-1.2.so.0

#3 0xb7ec12cb in SDL_RunThread () from /usr/lib/libSDL-1.2.so.0

#4 0xb7f0a33d in SVGA_keyboardcallback () from /usr/lib/libSDL-1.2.so.0

#5 0xb7e8120e in start_thread () from /lib/tls/libpthread.so.0

#6 0xb7a7d0de in clone () from /lib/tls/libc.so.6

(gdb) t 3

[switching to thread 3 (Thread -1304052816 (LWP 4917))]#0 0xb7a75d57 in ___newselect_nocancel () from /lib/tls/libc.so.6

(gdb) bt

#0 0xb7a75d57 in ___newselect_nocancel () from /lib/tls/libc.so.6

#1 0xb7d28301 in SDLNet_CheckSockets () from /usr/lib/libSDL_net-1.2.so.0

#2 0x080b216e in get_message_from_server (thread_args=0x8332ef4) at multiplayer.c:1785

#3 0xb7ec12cb in SDL_RunThread () from /usr/lib/libSDL-1.2.so.0

#4 0xb7f0a33d in SVGA_keyboardcallback () from /usr/lib/libSDL-1.2.so.0

#5 0xb7e8120e in start_thread () from /lib/tls/libpthread.so.0

#6 0xb7a7d0de in clone () from /lib/tls/libc.so.6

Share this post


Link to post
Share on other sites
zoom
As above, zoom is known to be broken. Don't use it or don't report it.
Would be cool IMO if you could also reserve a color for your map markers - just a colored dot, and when you mouse-over that dot it shows the "label" of the mark you made. Would that be possible?
Possible? Certainly. But I don't know if I like the idea... If I copy too much out of the tabmap, will there be any point to using tab? (Yes, there will be, since the map itself will eventually be different, but that's another issue)
Segmentation Fault with client compiled from CVS ( ~15 minutes old)
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x0808b2e0 in make_color_framebuffer (width=256, height=256, FBO=0x8334304, FBORenderBuffer=0x8334308,
FBOTexture=0x833430c) at framebuffer.c:63

That would be the creation of a framebuffer that Xaphier helped me add... I don't know much about framebuffer usage, so I'll chat with him and see if we can get this sorted out

 

ed: Should now be fixed in CVS

Edited by ttlanhil

Share this post


Link to post
Share on other sites

Taking this out of the update thread and put it where it belongs

 

Okay, I took a quick look at the minimap yesterday. I haven't really done anything with the code yet (except replace the calls to pow() with repeated addition, which is about 10 times faster, so the frame rate might go up with 0.000000001 FPS), so the observations below should reflect current CVS.

Zoom issues: Sometimes when zoomed in, it will mis-apply the clipping (which is for the edges of the map). I've seen this when going from IP to WS.

Hmm...I do see an ugly white line when I move too close to the edge on IP, but

*) this also happens without moving to WS first

*) also shows up when fully zoomed out

Other than that, I haven't noticed clipping issues yet.

Sometimes it also applies the fog-of-war incorrectly (perhaps just rotated 90 degrees, not sure exactly what it is), also only when zoomed in.

Couldn't reproduce that in my 10-minute test. I am missing the circle texture though, so perhaps there's an issue with that.

It also does not translate properly when changing maps (eg when you go from one size map to a larger map, what was max zoom is no longer max, which will get annoying). My plan on that was to change it from a simple zoom factor to different increments based on the size of the map:

1 = far out, 5 = right in (tiny maps)

1 = far out, 3 = half, 5 = right in (small maps)

1 = far out, 3 = half, 4 = quarter, 5 = right in (med maps)

1 = far out, 2 = half, 3 = quarter, 4 = eighth, 5 = right in (large maps)

So if you're in a tiny map, zoomed out, and you zoom in, you go to far-in. If you then go to a large map, you're still at 5, max zoom-in, but zooming out will only take you one step back out. It needs to be checked when the map size changes and the increment on a zoom-click adjusted, but it should be more logical.

Well, there is something to be said for the current system, in that the area you're able to see (as in number of tiles) is the same when the zoom level stays the same on map change. If we really want to keep the zoom level relative to the maximum zoom, we could do something like

new_zoom = new_max_zoom - (old_max_zoom - old_zoom);

(and make sure it's >= 0 of course).

Minimise-to-HUD was supposed to draw a smaller 'radar' version of the minimap above the quickbar, below the EL icon (perhaps replacing the EL icon would be simpler, since a decent part of what I did change was making it adjust to move the quickbars). It wouldn't draw any map, only have a ring overlaid on the HUD bar (the same ring as used for fog-of-war) and people/critter dots (due to the smaller size). You then still have a look-around, without it taking up screen space.

The minimise flagging and checking for available space (resolution, etc) works, the minimising action works mostly (except that when you first log on, it might be confused, until the minimap is opened); the minimised minimap does not work at all, although this is probably just a matter of drawing part of what the normal minimap does at a decreased size and fixed zoom. What work I did get done is not drawing it in the right place or size.

The patch I have is here: http://users.on.net/~gingerman/minimap.patch

A fair bit of that patch is cosmetic; when Xaphier added framebuffer support he changed the bracing style in CVS in many places, and I didn't bother adjusting all of my tree to match (ref. wikipedia, I prefer K&R, Allman makes it so you can see less code per vertical screenspace, GNU style makes it so you can see less per horizontal). The moving of the quickbars generally works except on startup, but does seem somewhat a hack (hence the TODO).

Ok, I'll take a look at it, thanks.

And to explain the last TODO, the plan was (in later versions of the client) to draw the minimap from the map itself, which allows the minimap to change automatically when the map is changed, eg by Grum's Pawn code. Since the server would only send updates to part of the map at a time, I was going to just update each 'pixel' (at minimap size resolution) as a top-down snapshot of the ground; and save the colour data to where exploration data is saved in the current version.

That's a fun idea, would be interesting to try and make it look good. I don't think that's not going to happen before November, though.

One other thing I thought of recently was that it might be a good idea to move out the range figures (used to size the fog-of-war ring) to a define or variable, since the visible range may change (especially if FPV gets working).

Looking at the code, the minimap currently makes a wild guess (?) as to what this size should be, but yes, we should probably do that.

Share this post


Link to post
Share on other sites
Taking this out of the update thread and put it where it belongs
;)
Hmm...I do see an ugly white line when I move too close to the edge on IP, but

*) this also happens without moving to WS first

*) also shows up when fully zoomed out

Other than that, I haven't noticed clipping issues yet.

Okay, nasty thought, maybe it's the off-by-one-pixel that has been a problem with OpenGL before (on some systems), such as drawing GL_LINES over textures, eg the inventory window, or when drawing progress bars. Since there is a clipping used when near the edge of the map (otherwise the texture repeats itself, which isn't a good thing in this case). On the other hand, maybe there's just some white on the texture (I can hope).
Couldn't reproduce that in my 10-minute test. I am missing the circle texture though, so perhaps there's an issue with that.
Maybe. I might have fixed that intentionally and forgotten, or accidentally while fixing other things. You can grab the circle I made from http://users.on.net/~gingerman/circle.bmp (it can be any size, really, but if it's too small then you get jaggies)
Well, there is something to be said for the current system, in that the area you're able to see (as in number of tiles) is the same when the zoom level stays the same on map change.
Here's the problem: try playing without zooming in. Go from a map like IP to WS, and what used to be the entire map no longer is. That's why I had the "magnification factor" idea, which I think would be the most intuitive (alternatively, the minimap could be used to only show the surrounding area, and do away with full-map size displays, relying on the tabmap for that, but I don't think that'd be as useful)
Looking at the code, the minimap currently makes a wild guess (?) as to what this size should be, but yes, we should probably do that.
The numbers there are from Frak's original work... The numbers seemed correct (I would see dots show up or disappear at roughly the range of the circle), so I kept them... But then perspective came in to use, and the circle then became the normal for day and max for night (if it's changed to a variable that's updated from the server, you can then shrink it during dusk to the 'average' the player will see... However, camo cape wearers will show up well inside, and people lit up like a festival will be seen outside the ring)

Share this post


Link to post
Share on other sites

First off, sorry for the long delay in doing some EL work. RL as been quite busy, and in addition I got somewat sidetracked by the Eternity II puzzle (a name well deserved...)

 

Anyway, I've checked in a patch that fixes the clipping issue when not using a framebuffer (I *think* clipping with framebuffer should be correct, but I'm unable to test it :D ) Also, the exploration data will now be stored in the configuration directory when the client is compiled with NEW_FILE_IO (and I'm not going to bother fixing it for clients compiled without it).

 

Didn't take a look at minimise-to-hud yet, will do so this week. Hopefully...

 

Please test, and report if there are more issues (e.g. I couldn't find any FOW problems).

Share this post


Link to post
Share on other sites
Also, the exploration data will now be stored in the configuration directory when the client is compiled with NEW_FILE_IO (and I'm not going to bother fixing it for clients compiled without it).

Ummmm... looking at the CVS update email (cos I can't reach Berlios - again!)... you have a problem in update.c. Both cases of mkdir_tree that you updated to have 2 arguments (under NEW_FILE_IO) will fail to compile completely now without NEW_FILE_IO. This is kinda odd, given the first one of them is inside the !NEW_FILE_IO #ifdef. ;-)

The assumption of course being that you weren't going to fix the issue with the config directory under !NEW_FILE_IO, not actually break compilation of !NEW_FILE_IO.

 

(sorry if that doesn't make a whole lotta sense. It's too early -10:30am- and I haven't had enough coffee yet.)

 

Index: update.c
===================================================================
RCS file: /cvsroot/elc/elc/update.c,v
retrieving revision 1.30
retrieving revision 1.31
diff -u -d -r1.30 -r1.31
--- update.c	5 Aug 2007 07:10:55 -0000	   1.30
+++ update.c	10 Sep 2007 18:09:01 -0000	  1.31
@@ -134,7 +134,7 @@
#ifdef NEW_FILE_IO
			mkdir_res= mkdir_config("tmp");
#else // !NEW_FILE_IO
-			   mkdir_res= mkdir_tree("tmp/");
+			   mkdir_res= mkdir_tree("tmp/", 1);
#endif //NEW_FILE_IO
	}
	if(get != NULL){
@@ -411,7 +411,7 @@
	if(get->status == 0){
			// the download was successful
			// check to see if the directory tree needs to be created
-			   sts= mkdir_tree(download_cur_file)? 0:1;
+			   sts= mkdir_tree(download_cur_file, 1)? 0:1;
			if(!sts){
					// replace the current file
					// TODO: check for remove/rename errors

Share this post


Link to post
Share on other sites

Yes, my bad, there are two mkdir_tree()'s: apparently the one in misc.c was copied into io/elpathwrapper.c at some point. I only fixed the one in io/elpathwrapper.c and forgot to test without NEW_FILE_IO.

 

Grmbl. Fixed it in my tree, but Berlios is still down. Again.

 

I'm starting to think we should find a more reliable host, accessing CVS has become somewhat of a lottery with Berlios in the past few weeks.

 

EDIT: fix checked in.

Edited by Grum

Share this post


Link to post
Share on other sites

What else needs to be done with the minimap? Or is it finished?

Yes and no.

 

AFAIK, all bugs have been stamped out (testing welcome, as always), and the minimap works. However, at least one item on ttl's wish list, the ability to keep a small version of the minimap on the hud, isn't implemented yet. Personally I don't consider this much of a showstopper[*], but that's open for discussion.

 

[*] but I'm biased, I promised to implement that option...

Share this post


Link to post
Share on other sites

What else needs to be done with the minimap? Or is it finished?

I hope ttlanhil will not mind me jumping in here, he's obviously the expert. :medieval: Anyhow, I've been using it walking around and it looks to be working nicely. Previously, there were problems with bits of map getting blanked but that looks to be fixed now. The most obvious things that could easily be finished are to include the fog-of-war circle bmp in the client data package and add a HUD icon to open/close the window. The icon will be a problem on the lowest resolution as we're out of space. The option to keep the window above others is not yet implemented and I could not see any code to display mine information as suggested.

 

edit: Note to self, check others have not posted since starting to reply then going off for tea...

Edited by bluap

Share this post


Link to post
Share on other sites
I hope ttlanhil will not mind me jumping in here, he's obviously the expert. :)
Not at all, and I'm not so much an expert on it anymore :medieval:
The most obvious things that could easily be finished are to include the fog-of-war circle bmp in the client data package
That's just an example image, might be better to have a larger or smaller one or whatever *shrug*
and add a HUD icon to open/close the window. The icon will be a problem on the lowest resolution as we're out of space.
HUD icon would be a good idea, although being able to minimise to sidebar would solve the problem of space (sorta), when the window is 'closed' you can have a smaller version, and click on it again to open the full window. But HUD button would still be needed if you close it and don't have room on sidebar... Maybe the HUD buttons should be set 2-high for low resolutions... They use more screen space, but then you have a lot more room for buttons (either that or the scalable HUD patch)
The option to keep the window above others is not yet implemented and I could not see any code to display mine information as suggested.
I scrapped the above-others idea, since it'd mean nasty code that's rarely used, the minimise button was added instead (to have a number of buttons that looked right :icon13: ). Mine information was only experimental and subject to change when I handed off, but it should be simple to add, just walk the list of mines the same as the list of actors is walked (and use different colour).

Share this post


Link to post
Share on other sites

Ok, so is the code usable and stable enough to be included this update?

In my opinion, yes.

Share this post


Link to post
Share on other sites

Ok, so is the code usable and stable enough to be included this update?

In my opinion, yes.

I think so too. I've not experienced any problems in use and it provided a useful function.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×