Posts made by Ashen-Shugar

@Thenomain said in @scan and search tools for MUX:

@Ashen-Shugar

Is there, er, a help file?

Narp.

But, here's the help.

• @scan <command> -- Find the dbref# in your search path that contains the exact match of the command.
  • Example: @scan +who
  • Example: @scan +finger Thenomain
  • Switches:
    • /global -- default - shows all locations
    • /room - show only current room
    • /self - show only on current person and inventory
    • /zone - show in zone only
• @listenscan <command> - Find dbref# in search path with exact listen (^) match
  • Examples: Same as with @scan
  • Switches: Same as with @scan
• +commandtree [<dbref#>] - Show all commands in the master room. Optionally specify a dbref# to just do that specific object.
  • Example: +commandtree
  • Example: +commandtree #1234
• +searchtree <partial command prefix> - Search the master room for all dbref#'s that contain a command starting with the partial.
  • Example: +searchtree +fi
  • Example: +searchtree +set
• +searchbyobj <object>=<partial command prefix> -- Search the target and anything around target for dbref#'s that contain a command matching partial match
  • Example: +searchbyobj #123=+fi
  • Example: +searchbyobj %#=+set
• +searchall <partial command prefix> - Search the entire db for dbref#'s with the partial command match.
  • Example: +searchall +fi
  • Example: +searchall +set strength=

And that's that.

This is Penn's @scan and some additional tools for MUX2. Enjoy.

@create ScanObj=10
&CREDITS ScanObj=Ashen-Shugar@RhostMUSH
&CMD_SCAN ScanObj=$@scan* *:@pemit %#=[u(do_scan[not(words(%0))][match(/room /self /zone /global,%0)],%0,%1,%#,$,@scan)]
&DO_SCAN00 ScanObj=Unrecognized switch '[lcstr(secure(%0))]' for command %4.
&CMD_SCAN2 ScanObj=$@scan:@pemit %#=What command do you want to scan for?
&CMD_SCAN3 ScanObj=$@scan/*:@pemit %#=[u(do_scan00,/%0,x,x,x,@lscan)]
&DO_SCAN10 ScanObj=[u(scan_contents,%0,%1,%2,%3,%4)][u(scan_self,%0,%1,%2,%3,%4)][u(scan_zone,%0,%1,%2,%3,%4)][u(scan_master,%0,%1,%2,%3,%4)]
&DO_SCAN01 ScanObj=[u(scan_contents,%0,%1,%2,%3,%4)]
&DO_SCAN02 ScanObj=[u(scan_self,%0,%1,%2,%3,%4)]
&SCAN_CONTENTS ScanObj=%rMatching on contents of your location:[iter(setdiff(lcon(loc(%2)),%2),u(scan_obj,##,%1,%2,%3,%4),%b,@@)]
&SCAN_OBJ ScanObj=[setq(v,0)][setq(1,trim(iter(lattrcmds(%0),u(scan_obj[hasflag(%0/##,regexp)],%0,%1,%2,%3,##),,@@)))][if(gt(words(%q1),0),%r[name(%0)]%(%0[flags(%0)]%) %[%qv: %q1%])]
&SCAN_SELF ScanObj=%rMatching on self and carried objects:[iter(setunion(lcon(%2),%2),u(scan_obj,##,%1,%2,%3,%4),,@@)]
&SCAN_ZONE ScanObj=%rMatching on zones in vicinity:[iter(setunion(lzone(loc(%2)),lzone(%2),u(dozone,[lcon(%2)] [lcon(loc(%2))])),u(scan_obj,##,%1,%2,%3,%4),,@@)]
&DOZONE ScanObj=[iter(%0,lzone(##))]
&DO_SCAN04 ScanObj=[u(scan_master,%0,%1,%2,%3,%4)]
&DO_SCAN03 ScanObj=[u(scan_zone,%0,%1,%2,%3,%4)]
&SCAN_MASTER ScanObj=%rMatching on master room:[iter(lcon(config(master_room)),u(scan_obj,##,%1,%2,%3,%4),,@@)]
&CMD_LSCAN ScanObj=@listenscan* *:@pemit %#=[u(do_scan[not(words(%0))][match(/room /self /zone /global,%0)],%0,%1,%#,^,@lscan)]
&CMD_LSCAN2 ScanObj=@listenscan:@pemit %#=What listen do you want to scan for?
&CMD_LSCAN3 ScanObj=@listenscan/*:@pemit %#=[u(do_scan00,/%0,x,x,x,@lscan)]
&CANUSE ScanObj=[gte(bittype(%#),5)]
@lock/UseLock ScanObj=CANUSE/1
&SCAN_OBJ0 ScanObj=[if(strmatch(%1,before(after(get(%0/%4),%3),:)),[setq(v,add(%qv,1))]%0/%4%b)]
&SCAN_OBJ1 ScanObj=[if(regmatch(%1,before(after(get(%0/%4),%3),:)),[setq(v,add(%qv,1))]%0/%4%b)]
&FUN_SCAN ScanObj=[u(scan_contents,%0,%1,%2,%3,%4)][u(scan_self,%0,%1,%2,%3,%4)][u(scan_zone,%0,%1,%2,%3,%4)][u(scan_master,%0,%1,%2,%3,%4)]
&CMD_COMMANDTREE ScanObj=$+commandtree*:@pemit %#=[switch([gt(words(setr(1,locate(%#,%0,*))),0)][gt(words(%0),0)],?0,list(lcon(config(master_room)),[ansi(hc,[name(%i0)]%(%i0[flags(%i0)]%))][u(fn_pipe,%i0)]),01,CommandTree: Target not found[setq(1,X)],11,[ansi(hc,[name(%q1)]%(%q1[flags(%q1)]%))][u(fn_pipe,%q1)]%r)][if(not(match(X,%q1)),ansi(hc,<--END))]
&FN_PIPE ScanObj=[setq(0,lcmds(%0,beep()))][iter(lattrcmds(%0),[if(or(not(words(%1)),regmatch(extract(%q0,#@,1,beep()),%1)),%r[ljust(if(hasflag(%0/%i0,noprog),ansi(hr,*LK*)),5)][ansi([ifelse(hasflag(%0/%i0,regexp),<#ffaf00>,<#af00ff>)],%i0)] -> [edit(edit(ansi(hg,extract(%q0,#@,1,beep())),*,ansi(hr,*)),?,ansi(hr,?))])])]
&CMD_SEARCHTREE ScanObj=$+searchtree *:@pemit %#=[list(lcon(config(master_room)),[ansi(hc,[name(%i0)]%(%i0[flags(%i0)]%))][u(fn_pipe,%i0,edit(%0,+,%[+%]))])][if(not(match(X,%q1)),ansi(hc,<--END))]
&CMD_SEARCHBYOBJ ScanObj=$+searchbyobj *=*:@pemit %#=[list([setdiff([setq(0,locate(%#,%0,*))] [lcon(loc(%q0))],#-1 #-2)],[ansi(hc,[name(%i0)]%(%i0[flags(%i0)]%))][u(fn_pipe,%i0,edit(%1,+,%[+%]))])][if(not(match(X,%q1)),ansi(hc,<--END))]
&CMD_SEARCHALL ScanObj=$+searchall *:@pemit %#=[list(search(eval=%[grep%(##%,*%,%0%)%]),[ansi(hc,[name(%i0)]%(%i0[flags(%i0)]%))][u(fn_pipe,%i0,edit(%0,+,%[+%]))])][if(!match(X,%q1),ansi(hc,<--END))]
@set ScanObj=INHERIT
@set ScanObj=SAFE

@Ominous said in MU Flowchart:

@Ashen-Shugar Since he asked for 'the good old flowchart' rather than 'a good old flowchart,' I am assuming he is referring to some specific one that may be an old joke/meme.

Ah, in that case, this is the one I used to pin up in my cubicle a lot.

@Bubasti said in MU Flowchart:

Good evening.

Does anyone have the good old flowchart? I need to show it for a friend.

A flowchart in... what?

• Hardcoding?
• Softcoding?
• Building?
• Design and staffing?
• Design and infrastructure?
• Time from starting a mush to opening to the public?
• Process of how to build a mush?
• Timeframe it takes to build a world based on theme?
• How mushes came about in existance?
• What people were involved in mushing?
• The general population that uses mush and how they trend?
• The average connections during a given period in the year?
• The average connections during a given period in a day?

You're leaving a lot open by just saying 'I want a MU flowchart'. We kinda need more than that.

Always wanted to start a mush based on H. G. Wells Time Machine.

With realities and zones handling each different 'timezone' and having the 'past' effect the future, the possibilities would be fun.

Same with a Doctor Who mush.

Maybe one based on TRON with some fun virtual reality.

Then of course, Guardians of the Galaxy.

And to throw one out there that will make people lynch me and beat their heads to remove the imagery:

Smurfs Vs My Little Pony -- The apocolypse death battle.

@Mercutio said in Star Wars: Dawn of Defiance:

@Faceless
No. Kitty has departed, as has Ysalamir, Soresu, and Ataru - the latter handing me the mantle of Headwiz. Vaapad was left behind as per the change from GoD to DoD. Ashen still hangs out from time to time.

This is me, peeking around a corner having heard my name...

Steam: mrsenile

@_Haven_ said in Guest Names:

@Thenomain Is it? That's great! Thanks for the info. It really put my mind at ease about switching!

As a general follow up on things that 'break' when switching from MUX2 to Rhost:

1. @mail is not transferrable. So that is lost.
2. comsystem is not transferable. So that has to be recreated.
3. Some features are 'different' and require some mucking around.. these are:

• columns(). Columns() in MUX is not compatible with columns() in Rhost, as @Thenomain mentioned. However, part of the db converter script renames 'columns()' to 'column()' and part of the softfunctions.minmax (@function wrapper tool) is a MUX compatible column() function. It also contains various other MUX compatible functions that ease transition. This file is located in the ~/Rhost/Mushcode directory when you set up your Rhost.

• Mail out of the box is not MUX compatible. However, there are mail wrappers that will work (again under Mushcode) that you can install that provides wrappers to the hardcoded mail system. Essentially, like Penn and MUX, Rhost has it's own hardcoded mail system which while very powerful is somewhat different in syntax. There are mail wrappers that mimic penn's mail and mux's mail available.

• MUX 2.7 and later have a built in UTF8 hardline encoding. Whenever you extensively use ansi or unicode (utf8), and store the RAW format in attributes, that will have to be converted. Luckily, Kage made a utf8clean program that converts RAW ansi and utf8 to Rhost's meta-characters for conversion.

• Sideeffects. Rhost has all the sideeffects that MUX has, and honestly all the ones Penn has as well. The difference is any object/room/etc that DIRECTLY uses a sideeffect must be set with the flag SIDEFX. This is a safty reason, so while annoying on a conversion is handy to have.

• LBUF size by default in Rhost is 4K. At compiletime you can increase this up to 64K. I would suggest 8K if you want to match what MUX had, or 16K if you want to get a bit greedy. 32K is fine as well, but 64K can potentially cause issues on older network routers between you and the people connecting with it cutting off after 32K for TCP packet sizes. It's goofy, but I tend to just say don't go over 32K. You ABSOLUTELY MUST have at least 8K lbufs compiled BEFORE loading in the flatfile or you''ll lose data loading it in.

• The comsystem in Rhost is softcode. Very fast, very powerful, and compatible with MUX and Penn. This is also in the Mushcode directory.

• MUX has wizard and royalty for bits. Rhost has immortal, royalty (wizard), councilor, architect, and guildmaster. Each bitlevel grants varying levels of power. Nothing should be owned by #1 other than #1 (and garbage). There's debate when it's good to use Immortal or Wizard for global code and/or head builders/coders/etc. In essence, immortal bit gives someone effectively #1 access to your game, so use it responsibly.

• Zones are different in MUX than Rhost. If you use zones, they will not convert. The reason why is MUX's zones, like TinyMUSH's zones, are like psudo-zone where it has a one to one relationship. Rhost's zones are a hybrid of Penn and MUX and in addition allows you to have multiple zones belong to a single thing.

• Reality Levels -- Fully compatible. Whee.

• Variable exits -- They should convert but you may run into issues. Variable exits are done a bit differently in Rhost so if you use them you may want to mark down where so you can double check them on conversion.

• RAW ANSI in names of things. Rhost does not support RAW ansi of names. While it'll convert fine and Rhost will seem to work fine with it, you can tell pretty early on that Rhost doesnt' like it. It breaks formatting and other things, but doesn't 'damage' the mush with it done. The correct solution to this is re-name the ansified named items with a normal name, then just use extansi to colorize the name of the item (help @extansi)

There's likely other small issues with command or functions you may run across here or there, but honestly most everything else should work 'out of the box' between codebases.

Hope that helps.

@Ghost said in Codebase Pot Pie - Or what I like or wish I could have:

I wish I could code in shell or kornshell.

Not happening, but I wish that I could.

Clarification: I can script just fine in sh/ksh. Its just not supported on codebases for MU

That's the beauty of the API, you don't need to code in shell. Any language at all that allows webapi with headers, including, but not limited to java, javascript, cgi, php, python, or such, will work with this API interface.

I just gave curl as an example.

@Ashen-Shugar said in [Codebase Pot Pie - Or what I like or wish I could have](/post

curl --user "#dbref:password" -H "Exec: commands-go-here" -H "Parse: no/yes/strip" http://mymush.is.here:API-PORT

Rhost's RESTapi is effectively completed and live.

It uses a header-driven API engine to push (POST) and pull (GET) requests from the API port. Everything is documented in-game.

It uses multi-level authentication and has varying levels of safeguards to avoid any DoS/DDoS attacks as well as methodologies from in-game attacks. You know me and my paranoia

The interface is nearly what I said above, but it is this instead:

For POST action:

curl -X POST --user "#dbref:password" -H "Exec: commands-go-here" -H "Time: seconds-for-queue-to-run" --head http://mymush.is.here:API-PORT

So for example:

$ curl -X POST --user "#123:test" -H "Exec: page bob=hi!;&BOB me=[secs()]" -H "Time: 30.5" --head http://localhost:1234

For GET action:

curl -X GET --user "#dbref:password" -H "Exec: functions-go-here" -H "Parse: parse/noparse/ansiparse/ansinoparse/ansionly" --head http://mymush.is.here:API-PORT

So for example:

$ curl -X GET --user "#123:test" -H "Exec: My string ran at [time()]" -H "Parse: parse" --head http://localhost:1234

It returns results and error conditions via HTTP headers just as submissions go.

So guys, enjoy, and go forth and cause havoc.

Cheers.

@Groth said in UX: It's time for The Talk:

@Ashen-Shugar said in UX: It's time for The Talk:

It will take thinking outside the box and finding a way to do external tags to and from the mush to send async data to and from a mush to an outside application.

Can this be done? Absolutely. A lot of applications do this already, and they're nothing more than an extensive TCP/IP engine, so why can't mushes?

The answer. Of course they can. It just takes coding to wrap the feature set around this. Then once the feature set is done, hand it off for others to interface to it who have a bigger understanding of GUI, or html tools, or what have you.

It's really easy to set things up to send data to and from the mush to an outside application. However if we're going to change the mush protocol and require new clients to be written, why do we even stay with telnet? If we switched from telnet to http/json we could have smart clients who are given information as data rather then raw text. It would know what represents the exits, what represents the players, what represents a pose and what's a command echo etc.

That's exactly what I'm going to do. I'm making an API that hits a separate port that allows HTTP GET and POST responses to PULL and PUSH data into and out of the mush.

Syntax via curl as a rough example (and yes, this is currently a working example on my dev site as I work with this):

curl -X POST --user "#123:MyPassword" -H "Exec: &FOO #345=bar;@emit whee;page wizard=test" http://mymush.com:12345

In the example, #123 is the dbref# you want to interface with (which can be room, exit, player, or thing, any valid dbref#), the MyPassword is the SHA2 hashed password for the API handler for that object (different from @password). It also defaults to localhost only unless you specify the API IP's (wildcarded) allowed for that dbref#, and it requires an API @power to work. The port 12345 is a separate port from the main mush port, and tags the connection API.

Using -X GET will work with functions only but should allow you to fetch pretty much any data within the game. Return values will be in a header -H "Return: <value>"

But that's the general design flow as it stands right now. Still a lot of tweaking and work, but the general under-hood work is already done. It uses headers only (no data), and uses standard HTML send/responses so anything that encapsulates url should work with it. So a fully working API engine.

@Lithium said in UX: It's time for The Talk:

@Thenomain Note: Roll20 has a CLI as well as buttons. Almost anything you can make a button for you can also input as a command. Especially when it comes to rolling dice but it's not /only/ a CLI.

This again though, is not only a change in code base, it's also a change in programs, gui, etc.

It's also one of the things I said would need to be done before there could be an entire UX overhaul. A complete change in code base.

Not... necessarily.

The issue is people are looking too far up at the 'big picture' and not toward the middle of the conceptual design.

Will it be nice to have a GUI interface to a mush? Absolutely.
How about a web page interface with the mush? Absolutely.

Will this require a top down rewrite to make happen? Not... necessarily.

It will take thinking outside the box and finding a way to do external tags to and from the mush to send async data to and from a mush to an outside application.

Can this be done? Absolutely. A lot of applications do this already, and they're nothing more than an extensive TCP/IP engine, so why can't mushes?

The answer. Of course they can. It just takes coding to wrap the feature set around this. Then once the feature set is done, hand it off for others to interface to it who have a bigger understanding of GUI, or html tools, or what have you.

I know my limitations. While I can keep up with most people at the back end development, I would not be the best at GUI design. I've not done that type of work for 17 years. And HTML I've rarely had a reason to work with. On or off the job. So no, I'm not the right person for an HTML or GUI front end.

But I can provide the tools to allow others the ability to do it, and that's what I'm doing.

There's no reason others who design codebases can't do the same.

@WTFE said in UX: It's time for The Talk:

No, seriously. Enjoy your DOS box. I won't begrudge you the joy that CONFIG.SYS so clearly brings to your life.

And this is the issue with a good number of people in the mudding world.

Some people like their DOS box. The issue is not converting someone to not use DOS box.

The issue is allowing them to use DOS box in addition to the new method you'd prefer them to use.

That way you have the new method for the new crowd, you pull in the old people with the old magic, and introduce them to the new magic.

Ignorance and unbending mentality works just as well for those who want a change as it does for those who do not.

Try not to fall into that pit.

@faraday said in UX: It's time for The Talk:

So yes, it sucks. But I really don't see a good solution that doesn't involve gutting the way the hardcode works. That's something the hardcode devs can help with, but it's beyond the reach of the average game admin/coder.

Made this possible with Rhost with dynamic help files you can create on the fly then access with textfile(), dynhelp() or @dynhelp in your code.

You just need to create two server side files to make it happen.
whatever.txt and then mkindx it for a whatever.indx.

There's also a corresponding mkhtml that you can convert a whatever.txt and a whatever.indx file into an HTML translated file with built in indexing.

I've always believed the solution for the nitch environment is providing an environment that is flexible, that can be easily maintained, and easily modular to go in nearly any direction the admin want it to go.

We're close to that end point, and it's a moving target so I doubt we'll ever reach it. But it's been a fun ride getting there and every day we think of new things to add for modularity and configuration control.

With how the world is going with direction with containers, cloud computing, virtualization, dynamic start-ups and any number of other things, environments and codebases generally have to follow the pattern at the back-end or frankly be left behind as people choose things that will do it.

It's a tough target to keep up with.

@WTFE said in UX: It's time for The Talk:

@Groth said in UX: It's time for The Talk:

Sidenote: @WTFE strictly speaking and syntaxical sugar aside. Mushcode has the same lamba support as any other string based scripting language as it can pass along arbitrary strings and call eval()

So leaving aside the part that makes lambdas useful (and you haven't addressed closures) it's just like having lambdas!

Lua:

function addxplus3(x)
  local z = x + 3
  return function (y)
    return z + y
  end
end

add5plus3 = addxplus3(5)
print(add5plus3(3))  -- 11
x = 100              -- what happens when we change "x"?
print(add5plus3(3))  -- 11

MUSHcode:

???

From my reading of it, there's no convenient way to do the equivalent in MUSHcode. Doing that code in MUSHcode would be about as painful and as error-prone as doing the equivalent in, say, Rexx or in C. It's doable in both those languages because ANYTHING you can express in one Turing-complete language can be expressed in another modulo hardware limitations, etc. (if you'd like I'll put up the Rexx version), but it's painful, it's error-prone, and thus it's something that's going to be avoided as a result.

"Store this function as a string and call eval()" (roughly how I'd do the Rexx equivalent) is theoretically very similar to the above, but its the very lack of that syntax sugar is why nobody would ever actually use it.

Syntax is nothing. Syntax is everything. Both statements are true.

It's one of the reasons I introduced execscript() to Rhost so that you could execute external scripts, schema, binaries, programs, executeables, or whatever and feed back the result as a native function. To bypass some syntactical hell that's prevalent in mush code. While it's powerful, it does have serious limitations when all you can do is feed it a block of crap and split up the args based on pre-built filters and handlers.

I mean sure, I've added dynamic functions, variables, declarations, redefinitions, empowerment and depowerment localization of variables, syntax, and functions, and a global handler of the same. But boil it down, and it's still mush code and still has the limitations of the interpreted parser.

The beauty of execscript() is it lets you step out of the box and do... anything else.

I'm currently working on a STEP-like API so that you could actually do curl/web calls right from the shell to execute code within the mush to both send and receive results.

Goal is to be able to do low-level cross-platform/cross-software plugins that work right into the mush.

It's always possible to work around limitations, it just sometimes takes a hell of a lot of scotch to do it.

Advice for headwiz. Huh. Um... huh.

I guess it boils down to just a simple philosophy.

Set rules and guidelines down, set up your ethical and moral obligations that you want for the game upfront, and try your very best not to deviate from it. People loathe change. This includes good change as well as 'bad change'. Try to avoid changing once you have the rules in place. If you do change, make sure it's well documented on what changed. It's to protect yourself more than other people

People will whine regardless of what you do. Never do it to please people, it's a straw man. As mentioned earlier, build a game you want to build. Build a game that you'll enjoy. Build a game that you dream about. Then share that dream with other people.

If other people come on and find it enjoyable as well. Awesome! You have a game to share.

If no one comes on and no one finds it enjoyable? Awesome! You have a game that you had an absolute blast designing.

In the end, setting up a mud is about having fun. If it's no longer fun, you don't do it.

Wish I could help more, but it's like hunting the white stag. It's a fun chase, and a great hunt, but never expect to bag it and eventually it'll end.

But man oh man, what a ride.

Figure I'll keep this in this thread as it talks about 'Codebase Pot Pie' just as well as adding a new thread.

First, Rhost 4.0 supports full unicode. Have fun those who are on Rhost 4.0.

Second, I'm working on a somewhat passible STEP API into the mush.

Essentially, using curl, you will be able to submit GET and POST responses to the mush to push and pull entries to and from the mush queue and return them to the outside application.

You should be able to use this in junction with execscript() and interactively as it pushes and pulls right from the queue itself.

The goal for this is to allow outside applications full reign into the mush engine to pass any data async into it.

It obviously won't be the fastest thing in the world as, hey, it's an API engine, but it should allow unlimited flexibility into the mush.

The reason of bringing it up here, other than the obvious of giving people a heads up what may be coming down the line with Rhost, is ideas and interfaces you would like to see on the API as it's being built. It's in the design stages right now (I have a working PUSH/PULL engine, still have to build the parser around it).

So, anyone interested to dive on the band wagon, feel free. All constructive ideas are welcome.

An example of the interface will be:

curl --user "#dbref:password" -H "Exec: commands-go-here" -H "Parse: no/yes/strip" http://mymush.is.here:API-PORT

The 'password' will be generated per-dbref# (non-player allowed!) in a SHA2 hash.

@skew said in IC Message Code/Alternative to @mail:

And I'm going to keep yammering...

Any chance anyone has the help files for Brandy Mailer? They're not on the MUSH code website. It has you create the help file, but doesn't give you any actual stuff to put into it.

I did a few google searches, but didn't find anything.

Brandy Mailer Help Files

There you go.

@Monogram said in State of Things:

We have got to somehow break the link between profit and sensationalism/misinformation and/or really invest in educating consumers to be savvier media consumers, but we’re doing neither.

One of the biggest failings of the modern era is that we didn’t use the rapid increases in knowledge and technology to try to mitigate the negative sides of human nature, instead we just put them all on steroids.

This will never, ever, happen.

Why? Simple truth. It doesn't make money.

Those in power want to keep the power, and that includes the hefty nest egg that they clutch to their belly like a dragon with gold.

They want people ignorant. They want people unthinking. They want people who panic easy. They want people who will just follow those who yell the most and just capitulate because 'that's just the way things are'. They relish in that. Because then they get to dictate the why, how, who and when's and everyone dances to the pied piper.

Sure, there are those of us who realize the sinking ship and absolute apathy and stupidity rampent everywhere.

But ask you this. When you see what is going on around you and can point and say 'why isn't anyone seeing that?!?' and realize it's true, very few others are seeing it, then you know the problem.