Teleporters (or rather everything else) can have a no teleport flag.

The thing about players only is it does exactly that -- spells, missiles, monsters, etc are all blocked. Which seems unjustifiably extreme for eg, a barrel.

Still, I've figured out a modified use. (Increasingly) monsters can apply objects, so an object can be player only meaning only players can apply it. So only player only floors actually block progress.

I'm a bit restless so here's a teaser of sorts. This doc is unfinished but I think gives a fairly good overview (0.10.7 touches on a lot more areas than covered here but the focus is on maps and msps).

The doc is not a highly technical reference for everything the server can and cannot do nor a tutorial for new mappers. It is in between: aimed at intelligent and inquisitive mappers and players -- a good working knowledge of how maps work in earlier versions is helpful but don't let the status quo blinker you.

MAPS, MSPS, AND TILESETS

1 Introduction

A map is essentially a small section of the gameworld. Each map is a 24x24 grid
of squares (AKA spaces or, here, msps) and may have up to 8 neighbours (as may
each of those and so on without limit). Maps connected in this way are said to
be tiled, collectively known as a tileset. Each msp has on it one and only
one floor (see [3.2] below), and zero or more objects. When an object is an
exit of some sort this will relocate its user to a different msp on (usually) a
different map on (often) a different tileset.

Note that all maps must be exactly 24x24 msps whether or not they actually use
all this area as playable space. This is a balance of various technical issues
(primarily memory usage -- on average more msps means more map objects means
more memory) and tiling requirements (tiling only works if all the tiles are
the same size) that is a nice area to work with from a mapper's perspective
(fits nicely on most screens in the editor, large enough to portray a sensible
(chunk of) narrative, small enough to not overwhelm the author.


2 Maps And Tilesets Relative To One Another

Tiled maps are horizontally connected to one another; it is possible -- msps
with impassable floors or objects notwithstanding -- to walk from one to the
other.

Travel between tilesets is only possible via exits (scripts and some gmaster
commands allow this too); a tileset is not actually physically connected to
another although it is often convenient to think that they are.

2.1 The Physical Separation Of Tilesets

For example, a dungeon that is three layers deep (or a castle that is three
storeys high) is going to be spread over three tilesets. Each of these tilesets
may comprise multiple tiled maps. Somewhere on these maps is an exit (eg,
stairs down or up) to another layer (tileset). Conceptually these three
tilesets can be thought of as stacked one on top of the other. Physically they
are entirely separate.

2.1.1 Consequences And Considerations

This dichotomy has several important consequences:
  o as each tileset occupies its own physical space there is no issue with
    tilesets 'overlapping' -- two vast dungeons (different tilesets) can
    have exits only a few msps apart on the same map;
  o it follows that a tileset may be larger than its 'outside' would seem to
    allow --eg, a tardis;
  o there need be no structural issues with larger tilesets 'above' smaller
    ones or unbalanced stacks -- a tower may have lower storeys just one
    tiled map wide but upper storeys several tiled maps wide;
  o the floor of an 'above' tileset is not the ceiling of a 'below' tileset --
    if an item is dropped out of an 'upper' storey window of our tower, it will
    not fall down through 'lower' tilesets;
  o this further means that maps do not physically have a ceiling or height.


3 Meta-Information

As might be expected, there is a certain amount of meta-information pertaining
to maps. This information is primarily held in the header of each map, and
certain complimentary and supplementary information may be held in the floor
settings of any msp.

3.1 Map Header

Meta-Information in the map header affects every msp on the entire map. It does
not affect tiled maps but maps in the same tileset tend to have similar headers
for consistency.

3.1.1 Name

A player-visible string giving useful info about the map (see ^Naming^).

3.1.2 Background Music

The filename of the music file to be played (on a loop) to players on this map.

3.1.3 Message

Arbitrary text.

By convention the map editor, Gridarta, uses this field to note the map's
author and date of creation and last editor and date of modification.

3.1.4 Enter X/Y

The x/y coordinates of the default msp a new entrant to the map will be placed
on.

3.1.5 Swap Time

The number of seconds of inactivity until the map is swapped out.

Inactivity basically means there are no players on the map. Swapping out means
an exact copy (minus monsters and players and the like) of the current state of
the map is temporarily saved to disk and the original is freed from memory.

The server has a default and it is usually best to stick to this default.

3.1.6 Reset Timeout

The number of seconds after the map has been swapped out until it is reset.

Resetting a map means the swap file is deleted so next time the map is loaded
into memory it is loaded from the original, vanilla state.

The server has a default and it is usually best to stick to this default.

3.1.7 Difficulty

The recommended player level *for a single player*.

It is used in a number of situations, such as to autogenerate treasure and
autocalculate monster stats and environment damage.

This must be set for all maps.

3.1.8 Darkness

The map-wide darkness (see ^Lighting^) value.

A positive value means no msp can be darker than this and a negative value
means no msp can get lighter than the absolute value of this. Zero means total
darkness.

3.1.9 Map Flags

There are several boolean flags which variously affect what can or cannot be
done on a map or some aspect of its general behaviour. Of these flags several
may be toggled on particular msps by setting the corresponding msp flag.

3.1.9.1 Daylight

This map is subject to variable ambient lighting according to the game time of
day and calendar.

3.1.9.2 PvP

There is PvP on this map.

3.1.9.3 No Spells

No spells can be cast on this map.

3.1.9.4 No Prayers

No prayers can be invoked on this map.

3.1.9.5 No Harmful Castables

No damage-dealing spells/prayers can be cast/invoked on this map.

3.1.9.6 No Summoning

No monsters/pets/henchmen may be summoned on this map.

3.1.9.7 No Swap

The map will never be swapped out which effectively means its so-called swap
time is actually the time until reset.

3.1.9.8 Fixed Reset

The map will reset after the reset time regardless of swap status or activity.

3.1.9.9 Fixed Login

Players always respawn at the Enter X/Y msp on this map.

3.2 Msp Floor Settings

Meta-information in the msp floor settings affects only that particular msp.
Some floor settings define meta-information found nowhere else while others
modify that found in the map header.

3.2.1 Face

3.2.2 Terrain

3.2.3 Darkness

3.2.4 Msp Flags

3.2.4.1 Daylight

3.2.4.2 PvP

3.2.4.3 No Spells

3.2.4.4 No Prayers

3.2.4.5 No Harmful Castables

3.2.4.6 Player Only

3.2.4.7 No Pass

I'm not sure msp flags are explained too well ATM. Essentially, each msp has certain flags which reflect either certain aspects of one or more objects on it, and/or certain settings of that msp's floor. Basically this allows us to, for example, distinguish between building interiors (no natural light) and exteriors (bathed in daylight) in towns or have dungeons with porous ceilings that let in patches of daylight. Another nice feature is we can have, eg, towns that disallow harmful castables (100%) as well as (and I have yet to test this but the theory works) dynamic anti-magic shields that block harmful castablesless often (we can also do all this for just spells or just prayers, including to reflect them).

The priest stairs issue is because the server (always has)   temporarily stored the exit's exit path in ->title. This is then cleared at the end of that bit of code so is normally invisible/irrelevant to players.

However because that exit (presumably) returns from its script to block /apply it apparently doesn't get as far as clearing it.

Since early 0.10.5 the temp storage has been pointless anyway AFAICR but I left it in... well no reason really. So I'll fix this in code in a bit.

This all should be fixed on dev now. As a bonus it is also safe to apply an exit in your inv (which potentially could open some interesting possibilities in future (eg, town portal-esque magic items, etc)  (but more specific thought on this is needed).

My local testing has been quite basic so on dev MMs/SAs try picking up/dropping on different maps exits before applying.

Especially try this with exits in instances that go elsewhere within the same instance. Pick up such an exit, go back to the mplayer world and apply it there. And vice versa. Try taking an instance entrance into the instance (pick it up, apply in your inv). Then apply it again. What happens?

If anyone reads the code, the new bits are heavily commented but ATM it is just grafted into the old code, no tidying, etc. Next gen 0.10.7 is quite different.

EDIT: BTW the original bug was actually because old servers made a special exception for exits to the usual way ->title works; 0.10.7 no longer does.

First, sorry things have, well, stopped over the last few months I will get back on this soon (someone else testing is always a good source of encouragement).

Yes, over time I'd rewritten stuff like the underlying stacking logic and added features like homeless mobs (mobs without spawnpoints so, eg, scripts can add/move/modify them without side effect), but the pick up/drop code was still decades old and creaky.

So I brought that into this century. IIRC the only thing you (SA/MM) can't pick up is a player (and floors/fmasks which aren't real objects anyway). Mobs/NPCs become homeless when you do, meaning that their spawnpoint will probably respawn soon.

This all makes minor dynamic map editing/live quests easier/possible.

Yes the messaging probably needs work but for testing I wanted it to tell me too much rather than too little.

Also, additional point, is there any chance of a mobile client? even just for windows 8? I think it might help a bit with accessing a new kind of player.

As I've said, Android is increasing support for their Native Development Kit (NDK) with the eventual goal of making it as seamless as the normal Java SDK. The NDK allows developers to write apps in C (which our client uses). IIRC there is a SDL port already, so it shouldn't be too difficult to port the client.

As Shroud mentions, a Windows mobile version theoretically wouldn't be too difficult but we'd have to migrate to C++ so that we could use the .NET bindings which are required. Unfortunately C++.NET opens up a new can of worms in that it's a huge pain in the rear to use.

iOS uses Objective C, which is compatible with the syntax of standard C. Not necessarily the details of implementation, however. I believe it's possible but cannot yet estimate how much effort it would take to make this port.

Main issue apart from recompiling code is also deciding how a player would control character with a phone as most phones don't have access to a whole keyboard

Pupnik has made a nice client for Nokia phones which at the time ran a real Linux distro out of the box. He made some huge changes to the UI to make it look and perform better. While it doesn't have on-screen controls (that phone had a full keyboard) it would be quite easy to add them due to the mobile-optimized UI.

So anyway I'm aware that my latest server changes are the blockage here. Because I tell people that such-and-such bit of code will change profoundly so it's not really worth independently developing it, but then I don't commit my changes.

Well part of the reason is that I have been trying to comment/doc everything which really takes a lot of time. For various reasons this got me into a bit of a bottleneck a few months ago and everything ground to a halt.

I've picked up again today but I'm not entirely sure if I simply had commenting todo or if I left something fundamental unfinished. So I need to do a bit of local testing at least.

When I'm convinced it all works I'll commit just to get it out and worry about comments and such later (when I say comments I mean this in a pretty heavy way -- I've reimplemented fundamental parts of the ever (not least the way it thinks about maps) and I'm not sure how much sense it'll make without a detailed overview of the intent/reasons.