The problem that I see, and was pointed out by Gecko long ago is that the player can close the interface at any time, leave the interface open while he gets a cup of coffee or logout and neither the mob's script nor it's AI knows about it.

We usually would not want the mob's behavior to be changed and then not being reset back to it's normal behavior.

We also have to be able to handle several players talking to the mob at once.

When you start talking to a person in the real world they either stop and respond, talk while walking along side you or they ignore you and continue doing what they were doing.

A player should not be able to converse with an NPC for a quest from a long distance away as that would damage the fantasy. We don't have cellphones in Daimonin. You have to walk up to the NPC to engage it in conversation. You should not normally be able to chat with an NPC through walls, closed windows and doors. Not being able to talk to an NPC with 3 players standing in line in front of you seems reasonable, you wait your turn or move to a closer position. Good gameplay demands that things make sense to the player and are reasonable for the game world.

A new behavior that can handle those problems and make the NPC/player interactions look more realistic to those around them would be nice.

I hate it when an NPC walks off while I am talking to it. So I use this.

The move_towards_waypoint behavior must be above other move behaviors so that when activated it will have highest priority in that section of the AI.

This works well with random movement or other waypoints.

When the pause time expires the mob resumes it's normal behavior.
If other players talk to the npc the pause gets reset, so if many players are gathered around the npc they can all talk to him without him walking off. This was a problem 2 or 3 times last year with the lost soul, he walked off and player didn't get the quest they thought they had gotten.

I believe that if you go up to and start a conversation with an npc it should look to other players like you are having a conversation with the npc. Which means the player and the npc are close to each other and not moving around.

I like this addition 

@Planeskeeper: this is only for scripting, it does not affect normal group battle, which is handled by the server c code.

This would make group quests possible. With appropriate safeguards against exploitation scripted.

Interesting possibility: A scripter could actually write a script to summon the rest of the group members when the group leader enters an instance map.

Might also be used for 2 groups entering opposite ends of an instanced map set for a capture the flag in the middle contest.

You can take an arch object and add an artifact mask to add attributes or modify the existing attributes. Then place that on your map.

You can take an arch object and modify or add attributes with the map editor and place it on your map.

It would be senseless to do arch -> artifact -> map editor.

The use of artifacts is to provide consistency among copies of the object. Typos need be corrected in one artifact file not a bunch of maps.

For a customized unique object it is probably more efficient to modify the base object with the editor, just do not ever change the type (sub types can be safely changed as long as they exist) .

version 107 updated to 108 fine on my vista, keyboard works fine. the updater and daimonin.exe were preset to run as administrator on my computer. working fine for me.

Wait until the new content management system is in place for this web site.

In the real world humans have eyes which automatically adjust to light and dark. Yes, we can see in the dark, just not quite as well.

All of these vision enhancements you are talking about could be mostly done away with if there are no maps where they are needed to be used on.

When MT said that he was going to get rid of cursed items and make all items identified I had to stop and think why? I realized that 21st century games do not put the player through needless, jump through the hoops, procedures.

Modern games do not have players running around retrieving used arrows.

Most games are now well lighted even in dungeons.

Good modern games give the player some freedom to choose, they don't get the feeling that they are being controlled by an evil dev.

Modern RPG's have moved away from the keyword style of npc conversations we had in B3 to the hierarchical finite state machine design. It's simpler and faster for the player to use and can make npc's seem more real when done right.

B4 moved Daimonin from the 1990's to the new century. Simpler, efficient and consistent gameplay.

Daimonin is headed into the future, not going back to being an old school game.

It is not what you can do to the player, it it what you can provide for the player as entertainment.

A player starts to learn the rules of how things work early in the game, and builds on that knowledge throughout the game.

You have to ask yourselves if your ideas are modern or belong in the past.


 

@ Grommit.... there are many ways to hide a mob, even the use of a triggered spawn. Also mobs can have skills, you might look at the currently unused skill of hiding. Forget hiding, code commented out for B4. But you can spawn an invisible mob and the use a trigger event script to make the mob visible when it senses player, I think you have to change both the mob's flag and the flag in the base info in the mob's inventory (it has the same name as the mob).

After some thought and a look at the code, I believe the mob xray vision was removed from B4 for good reasons. For the one or 2 mobs that would use that feature thousands of mobs would be checking for that flag several times a second depending on speed. Inefficient use  of server time I would think. Using xray vision for mobs or players for continous use is a bit of a cheat and current commercial game practices seem to try to remove the appearance of cheating from either side to insure better gameplay.

Xray vision might be a complication for the 3D client.

Go ahead and move this old thread I you wish.

Demoneyes is an old 1990's concept that probably needs changing.

I think it might be better if demoneyes, infravision and see_invisible would be temporary spells, not equipment attributes. Taught by a separate wizards guild, or available as scrolls or potions.

Demoneyes could maybe be changed to just allow seeing by targeting of players and mobs behind obstructions without seeing hidden architectural features.

If all mobs are blocked from seeing through walls then maybe the same should be for players. Ask Michtoen about the future plans of the game design.

In addition to selecting just an arch name or a single mob name the present kill and kill item quests allow the mapmaker to allow a player to kill several variations of a mob all under the same counter.

If the player is told to kill 10 ants either red ant or big red ant then only the total counts not how many of each. And black ants would not count.

This allows mapmakers to set the mob names in a dungeon to match a quest so that the player is limited as to which dungeon or dungeons to go to and how far into the dungeons they have to travel to find the matches as well as exempting some similar mobs as valid targets.

Daimonin uses one object model for it's objects. Many attributes (like slaying) are used for different purposes in different places in the code for different types of objects so the reference to title does not mean the title of the mob. It is just a place to put the data needed for quest. There is no error. The sym_name feature is a good feature to have.

I fail to see any need to target an entire race in a quest. You might as well say kill 100 mobs. It is too general to be useful in any reasonable game play situation. If you made a mid level quest to kill the race of giants then the players would run to the low level ogres and kill them.

Contrary to the title of this thread kill quests are not broken yet, they work as designed into the code and as was demonstrated on the testmaps. The comments in the code may not always be up to date.

Smacky's change would reduce the capabilities of the quest system and not improve game play.

MT has said many times that the donation items purchased from the donation shop will be re given to the original buyers after any wipe.

Several of us have discussed having a job assignment npc in each of the guilds when the guilds get fully implemented. Random quests of different types (pickup and delivery, recover lost item, hunt/gather ingredients, escort/rescue npc among others) could then be given out with a small chance at getting a really good quest.

My first random quest generator got me bored after 10 quests so it is being redesigned.

Random dungeon generation is being worked on by others so hopefully the combination of the two will add more fun to the game some time in the future.

The unofficial maps area is work in progress. Expect some map bugs there.

In this particular case a small set of maps was copied from another area for testing and experimenting so the missing maps were not needed, not copied, not connected.

Daimonin is a beta, it is under development. It is not a final rated and released game.

Daimonin has a violence level equivalent to SNES Legend of Zelda. there is no blood and guts flying everywhere.

All NPC's have a G rated language.

There is no sexual conduct programmed into the game.

There is no nudity programmed into the game.

This game is programmed for the whole family.

The one thing developers can't program is the players.

This is a role playing game with rules for player behavior enforced by our Vol's and GM's.

If you wish to play the game, play by the rules.

Don't like the rules, you can post in the forum to try to get the rules changed.

If you have a problem with a vol you may file a complaint in the appropriate forum.

If you have a problem you must be specific in your posts as generalizations are usually ignored.