Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics

In a way, although I can see why you might want the functionality, I'm struggling to see why you would want this functionality in the specific examples that you're giving.

Your trees and gates would surely be non-conspicuous (i.e. invisible from the object list) scenery items, and would be mentioned instead in the location description... "You are standing in a forest, surrounded by trees."... in which case whether they are created before or after the object list is printed doesn't matter.

If you really want "object list visible" trees in each case, then I would suggest that creating multiple "dumb" tree objects would be the way to go, because it would be probably just as easy to define the interactions with each "tree" based on the location range/zones.

But yes, Adventuron doesn't seem to give you a way of doing something between printing the location description and listing the objects, like a system such as PAWs does.

[Now, if it really was a floating object you wanted... with this theme, literally a ghost (that's defined as an object) that maybe follows you around, then I can definitely see the need of that sort of functionality. You'd probably have to have a "The ghost floats into the room..." message printed in the on_describe section to explain why it was initially missing from the "objects visible" list.]

I actually have something like that, which is another reason why I asked. I don't want to give anything away. Let's just say it's for NPCs that can move around.

I use floating objects a lot in order to avoid duplicated code. The example was just that (to keep it simple). I used scenery for debugging purposes. Now that I know about conspicuous, I would use that for the trees in a real game.

The problem surfaced with doors. I had implemented my own doors and they worked perfectly, except that I had to duplicate the door in each room. "There must be a better way" thinks I to myself. Then I discovered Adventuron's doors, but they are one-way doors and require duplication, but you can't access their booleans and you can't have multiple doors in the same room and you can't unlock a locked door other than with a key, so it's back to square one.

Adventuron's doors are a work in progress, and largely there for absolute beginners. If you need anything atypical, you can certainly code your own doors, which is what you did. Door will get better but I'm wary about introducing a whole bunch of commands just for doors (to interrogate their properties for example). I think that if you need to go that far, maybe a door template is not appropriate anyway.

Your doors look quite flexible with respect to messages, you just need to have a two-way door option and you need to be able to get and set the open and locked properties. For example, a door can be locked (to prevent it being opened), but it is unlocked by using a swipe card, not a key. In fact, this might be an example where unlocking and opening happens at the same time, so you need to be able to set the open property and clear the locked property when you SWIPE CARD. Oh, and you need to be able to customise the description so that you can say whether the door is open or closed within the description. This means you need to be able to get those properties.