Can doors be added with the server up?

[jdoran]

I am interested in adding objects to the game dynamically (with the server up). What I would like to do is have a quest create an object only seen by one player (to keep the world from getting cluttered up). A door struck me as a possible solution. There are all sorts of models usable as doors, and I think the collection is sufficient for what I'd like to do.

I see that door information is read in when a zone initializes, but I haven't located where this information is sent to the client. Is there some sort of door packet which could be resent to a client without them zoning?

If that won't work, does anyone have any alternate ideas for me to look into?

[sorvani]

yes you can spawn doors live (gm commands) and via quest scripts. those functions were added a year or so ago. no in game objects are one client only that i know of.

assuming they added that functionality to later clients, it likely is not coded for in the current server base.

[jdoran]

I'm not sure why this was moved to the Windows server forum, since I am not running a Windows server (nor is my question Windows specific).

Sorvani, thanks for the info on spawned doors. If a script can do it, then anything in the server can. I am modifying my (Linux based) server, and am considering sending data to a subset of the clients. I'm sure someone must have used the mechanic before, but I cannot think of an example. In a way it is like instancing.

If only one client is informed of the "door", then nobody else will be able to interact with it.

[Caryatis]

You need to give more explanation about what you want to do in order for people to actually be able to suggest things that are different from what you propose.

For example, adding a door for a single client is kind of retarded as you either add a door to an open space(looks retarded) or you add a door to an empty doorway(ie only blocking that client).

Most people that ask to do crazy shit like that, lack experience and thus are attempting to do something that is relatively easy but they are ignorant of a more elegant solution.

Also not sure why you are putting door in quotation marks.

[jdoran]

Sorry, I thought my first post explained all of this. I am looking to add objects for quests, and am considering using doors as the mechanism. Door objects can use many different models, and can indeed be free standing.

Caratys' belief that this is retarded/crazy shit is most likely the result of a misunderstanding of the use of "door". EQEmu has a door table which contains assorted odd items (palm trees in Oasis for example). I felt that developers would be familiar with this usage, and my message was originally posted in a development forum.

Why only make this available to one client? I have built a prototype quest generator (spent several years on this so far), as a research project. Using only existing objects in a zone is very limiting -- there may not be an object of a specific type already in the zone. Dynamically adding items would solve
this, but could quickly clutter up the zone. If information is only sent to one client, my generator could add a chest to a room if needed without affecting people not running the quest.

This is all experimental, as is the nature of research.

[Caryatis]

Unless you require the functionality of a door(lockpick, open, animations, etc) then there is no point in using a door. Whenever you kill a raid mob in the last 7 years, a chest spawns... do you think that is a door?

Your post simply reinforces my point... you want to spawn a chest so you think you need a door because you don't know how to properly do it(nobody is going to be able to open that "door chest").

Making mobs visible to only certain clients may be doable, if not there is code posted on how to restrict that mob to certain individuals which you could adapt.

[jdoran]

Funny how the database currently has chests in the door table.

Anyhow, a chest was just one example. Any placeable item is of interest.
I mentioned doors mainly to show that I have given the matter some study,
rather than running to the forums immediately. In my original post I asked for alternatives from people who know more than I, fully expecting that doors would be rejected.

@Caryatis I wouldn't mind some constructive feedback instead of your
ad-hominum rants. You might know what you are talking about, but
the tone of your posts causes me to dismiss them (and you) immediately.

[Caryatis]

When I was younger I probably would have linked the definition of ad hominem but suffice to say its not what you think it is. Feel free to point out where I directly called you a name though.

Whether you choose to dismiss my posts or not, in 3 days when you have gotten no further responses you will eventually read my post and then realize you have your answer.

[Akkadius]

Originally Posted by jdoran

I am interested in adding objects to the game dynamically (with the server up). What I would like to do is have a quest create an object only seen by one player (to keep the world from getting cluttered up). A door struck me as a possible solution. There are all sorts of models usable as doors, and I think the collection is sufficient for what I'd like to do.

I see that door information is read in when a zone initializes, but I haven't located where this information is sent to the client. Is there some sort of door packet which could be resent to a client without them zoning?

If that won't work, does anyone have any alternate ideas for me to look into?

Right now yes you can build objects dynamically by using Perl exported objects:

int16 QuestManager::CreateDoor(const char* model, float x, float y, float z, float heading, int8 opentype, int16 size)

in otherwords:

quest::CreateDoor(const char* model, float x, float y, float z, float heading, int8 opentype, int16 size)

Right now it is not implemented to only send a packet to a single entity to spawn an object so that would have to be customly made. The source does the iterations through the entity list to send the object packet to every player. You would have to implement separate functions to specify which client to send the packet update to.

So short answer right now, no.

[jdoran]

@Akkadius, thanks. Adding the client filtering will be trivial. I was worried that the objects wouldn't appear until after the client zoned.

I'm hoping that the .mods in the s3d files correspond to placeable models.