addworld someworldand in the someworld file in the same directory you have the line
url_base_a http://myisp.com/~mylogin/eh_imagesNOTE: Due to a bug in the URL handling code, localhost won't work as a hostname in the url_base_a - use the DNS name or IP address of the host
The images for someworld should be in the eh_images directory (or wherever the eh_images directory is mapped to by the webserver e.g. ~mylogin/public_html/eh_images).
If the problem exists even if you can load the image in your browser, delete the cache directory for that world. The world cache directories are, in Linux, rooted at the location pointed to by the ehwt_home entry in your .ehwtrc file, and in Windows, rooted at C:\Program Files\eh\ehwt\home. (The .ehwtrc file and the world definition files referenced by addworld entries in .ehwtrc are located in your home directory in Linux, and in C:\Program Files\eh\ehwt in Windows). The subdirectory containing the cached objects for a given world is created by appending the ehMOO/miniMOO port number to the name of the world and separating them with an underscore e.g. someworld_11111. To fix the problem, just delete the cache subdirectory for that world, or any 0-length images in the cache to be exact. An indication that you might have 0-length images in the cache would be messages in the console like 'bad texture, using default'.
When I connect to a world, I see 'Looking up' or 'Contacting' in the console, and nothing happens after that.
ehwt/ehwtwin either can't resolve the hostname or can't connect to the hostname/port specified for the world being connected to, or the character/password you're trying to connect as is incorrect or doesn't exist on the ehMOO/miniMOO you're trying to connect to. First, make sure you can ping the host you're trying to connect to. To figure out what the host is, you need to look at the door you're trying to enter in the world file and find the world name. For example, the default world file, home, located in Linux in the directory pointed to by the ehwt_home entry in your .ehwtrc file, or in Windows the directory C:\Program Files\eh\ehwt\home (The .ehwtrc file and the world definition files referenced by addworld entries in .ehwtrc are located in your home directory in Linux, and in C:\Program Files\eh\ehwt in Windows), has as its second-to-last line:
door eh_door [0:to_eh_wall] [WORLD:someworld:62:home_door]This example says that when you walk through the (red) door in the default world, it will try to connect to the world defined in the someworld world definition file, which hopefully exists and is referenced by an addworld entry in your .ehwtrc file.
For example, you're trying to connect to someworld and failing. In your .ehwtrc, you have the line
addworld someworldand in the someworld file in the same directory you have the line
host someworld.com port 11111 character mychar password mypassThis tells you that the MOO you're trying to connect to should be running on the host someworld.com on port 11111 and that you should have a character named 'mychar' with password 'mypass' there.
First try pinging someworld.com:
ping someworld.comIf this fails, someworld.com is either not being found (DNS problem) or isn't up and running (or is behind a firewall that doesn't respond to ping attempts) and is likely the source of the problem. If the ping succeeds (or if it doesn't and you suspect the MOO is behind a firewall - of course if that's the case, it better allow incoming TCP connections to the text/graphics port being used by the MOO), try connecting to the MOO in a text session and logging in as the character you have specified in the world definition file. If that succeeds and you still have problems, the only other explanation would be that the server is accepting graphics connections on another port, and not the one specified in the world definition file.
If I connect to a miniMOO world other than the default supplied with miniMOO, I see only a black or flickering background.
This is due to a miniMOO bug - had to change 0,0 to 20,20 for the default home world x,y position, otherwise when you connect you are embedded in a wall. So if 20,20 in the new world doesn't correspond to a sane position in that world, you'll end up seeing junk (or embedded in a wall).
The solution is to move the player in a text session to a position in the new world that you know is sane before you connecting graphically the first time. For instance,
@move me to 0 0will cause the graphics player to start at 0,0. Subsequent connections don't need this step because the new position will be saved.
Until this problem is addressed, it's probably safest to connect only to miniMOO worlds that have something sane at 0,0. You can ensure a world has a sane 0,0 position by looking at it in ehed and if 0,0 as indicated by the green crosshairs isn't in a good place, move the world so that it is and save. Control-click in ehed will give you x,y of that point, so you can also use that to find a good position to move the player to. This method can also be used to find positions in ehmoo.
BUG: Having non-existent rooms in roomid.persistent_subscribers will cause moocode stacks. To manually change the value to what you know it should be:
@setprop here.persistent_subscribers to {#99}
ENHANCEMENT: Before using ehed, you should have successfully connected to the world you want to edit via ehwt or ehwtwin; ehed looks only at the local world cache, which will be empty unless you've successfully connected to that world at some point. ehed should behave like an ehwt client and download the texturesBUG: if you're already graphically connected you won't see the new room until reconnecting, needs to be fixed. object change events as per gprot spec should be implemented when facings are modified, but aren't.
NOTE: Since the first room is owned by wizard, you you must have programmer and wizard priveleges in order to build off of the first room. Otherwise, you need to own the room(s) you're building off of and be a programmer. Here's how you make someone a wizard:
@chparent #xxx to $wiz @programmer #xxx ;#xxx.wizard=1This is consistent with building works in a non-graphical text session, but ehed doesn't help prevent or diagnose cases where the player doesn't have sufficient permissions to dig new rooms/exits. ehed really needs an undo function to be robustly useful. As it stands now, you have to be really careful, or you'll have to fix things manually on the MOO, which isn't complicated but is tedious.
BUG: text-only players bunch up graphically at the default location. Need to think of a way to generally disallow players/objects from occupying the same space, which must also take into account player's inventories or objects containing other objects.
ENHANCEMENT: make it part of ehed to set the default text player position for each room, rather than having to do it manually.
BUG: objed bug: there isn't really an indication as to whether the facincgs were actually changed on the MOO. You have to drop the object to see, or look at the object's facing_list property.
BUG: minimoo bug : @move objectname to x y doesn't work, need to exam object name, @move objectnum to x y
BUG: You can't have entrances/exits to/from the non-graphical part of the moo. You need to teleport there. (because the moocode tries to get ehPortal from room.exits)
BUG: You can't be in a text-only room when you connect graphically, you need to either not be connected textually or @move me to graphical room. (because real_location is referenced at least in initial_subscription)
ENHANCEMENT: It shouldn't be necessary to have a different character/password for every ehMOO you visit. The solution is architectural, but basically noting her that the .ehwtrc/addworld scheme is onerous and needs to be dealt with in a manner transparent to the user.
BUG (FIXED): submitting facings to minimoo doesn't work?
BUG (in Win98?): I can save as .ehwtrc.tom2, but explorer won't let me do it - says must be a filename????
BUG: max room size 64K - really need to not store di in moo, need to use url.
ENHANCEMENT: plans are to add basic web service to minimoo, so you can host images along with world.
BUG: if you start out in a room other than the first room, your text character won't move to the first room if you graphically go there? Go there then come back then go again and everything works.
BUG: all characters including wizard MUST have a password. If they don't textures won't be loaded from URL. Correction, specifying a password even though the character doesn't have one is necessary and will work.
BUG: ehed: When adding rooms/exits, add them first, then do permanent subscribers, once the room numbers have been assigned. i.e. don't use temporary names.
ENHANCEMANT: ehed: allow worldnames instead of ip/port
ENHANCEMANT: ability to add di to existing rooms: update: won't do this, have to do manually because also need to set event_flag and may be dangerous
ENHANCEMANT: docs: Tell how to manually delete rooms and exits
ENHANCEMANT: docs: Tell how to manually change rooms, especially the first
ENHANCEMANT: docs: Tell how to start adding graphical rooms to existing moo, must retro-manually do it for existing rooms, or modify ehed
BUG: ehed: Portal Dialog: note that in order for things to show up in the browse button dialogs, the world chosen must have been loaded, which only happens when a world is clicked on, otherwise just enter manually.
BUG: objed: no way to set start facing in minimoo.