faramir118

Your only real hope to see it broken before you die: http://en.wikipedia.org/wiki/Shor's_algorithm

I guess that it's possible, but not in the sense that you specify arbitrary angles at runtime...

With the generator, we currently discard all parts of the terrain that are too steep.

It should be possible to flag those areas instead, which would allow for more flexibility in certain situations.

Start multiple instances of the generator, tell each one to build a different map.

Sounds like you have 4 cores, which means you can do 4 maps at a time; or 2 hyperthreaded cores, which means you'll probably be better off doing 2 maps at a time.

Sorry for not following through on some of these maintenance and support things - I've shifted most of my attention to real life issues, trying to improve my lot in life (nothing is wrong - I just want a better lifestyle for me and my gf)

The charge movement generator patch is still around. Movement works, but you should test it before really using it - not 100% sure I return correct values in the Update function.

If you report a bug, please use map number and coordinates! If you can't/don't use the gps command, our capacity to help you will be greatly diminished!

As far as testing goes:

• make sure the pathfinding log filter is disabled
  
• judicious use of mmap debugging commands when investigating issues
  
• use RecastDemo to inspect the meshes
  I will find out why it's not working on zero - until then, you should be able to use the master branch's version instead
  

At this point, since Undergarun is apparently still using mmaps, things seem to be going well.

On the other hand, some people seem to be having lots of trouble with pathfinding, yet they I don't think they've been around to ask for help. For example, this pserver says they bugged alot of the server (don't worry, that pserver and its website seem to be defunct)

Thus, I don't know where we stand - are there really that many problems, or is it just a usage problem? Which leads me to...

It would be nice if someone created a mmap guide thread - details on how to do the generation, configuration options, commands, proper ways to test in-game and through RecastDemo, etc. Maybe include a list of community-provided offmesh connections?

Just haven't had the resources (time, equipment) to test and develop further.

Ignoring the AIOCB synchronization, here is a general state as I see it:

Outgoing synchronization is as good as it will get

• synchronized queueing, can't be done in batch (SendPacket places packets in buffer)
  
• fast batch dequeueing (double buffering, all data sent at once)
  

Incoming synchronization could use some work

• batch queue operations should reduce synchronization overhead
  
• packet processing throughput is hindered by implementation of ACE_Based::LockedQueue::next (the template version).
  Should be more eager, IMHO - inspect more than just _queue.front()
  

Accommodating AIOCB adds some complexity and locking overhead, but I believe it is stable.

Some of this work is directly applicable to master, so I guess at the very least I can put together something that will provide an immediate benefit...

What is the full path to the directory in the screenshot above?

Is windows x86 or x64?

Is mangos x86 or x64?

What is the exact error you receive (screenshot or copy/paste)?

Don't use Internet Explorer (unrelated, but )

I have mangos zero on a computer at work, I will try to steal time this week to look at that tile

Also need to update mmaps branches when I get a chance

Both of these use open-source MMO engines:

http://www.planeshift.it

http://worldforge.org

2011-03-23 15:36:11 a You have: --> `11234_01_mangos_command.sql`

You need to update to at least mangos [11234]

Update the core to a revision that is compatible with the database.

For terrain height, look at GridMap::getHeightFromFloat(float,float), it should give you a lot of information on the height calculation itself.

The vmap uses ray intersection (the BIH speeds things up by limiting which models are tested)

Do you have to use 3.1.3, or can you upgrade to 3.3.5?

Some general information, which should help you set it up correctly for all clients you wish to play with...

In the realmd.realmlist table:

• The second entry is not necessary (and also incorrect - you can't have 2 realms with the same id).
  
• The address must be resolvable by internal and external clients (qorwynn.dyndns.org)
  
• The port and id must match the values in your mangosd.conf
  

On client hosts:

• On all client computers, realmlist.wtf should say set realmlist corwynn.dyndns.org
  
• On client computers on your LAN, modify the hosts file so that qorwynn.dyndns.org resolves to 192.168.1.10
  

Not sure how to do it with sqlyog, but you can do it easily with a query (your life will be easier in general if you know at least a little sql )

UPDATE `realmlist` SET address = 'myserver.no-ip.org' WHERE id = 1;

I pushed these changes to github so that my motivation is more apparent.

Look at the 4 most recent commits: https://github.com/faramir118/mangos/commits/pets

I will look into it, but I don't know if I will be able to help since your codebase is so different (saw the stack trace before you deleted it )

Not related to mmaps, but I think you can prevent corpse falling in Creature::setDeathState by removing

if (CanFly() && FallGround())
   return;

On windows the 'limit' is FD_SETSIZE - this is how many sockets you can pass to select. You can make simultaneous select calls in multiple threads, and spread the sockets out - this effectively increases your limit even if the console doesn't reflect that at startup.

I guess you can change FD_SETSIZE in ACE srcs - by default ACE set it to 4096. Select performs poorly though, better to switch to *nix or async sockets

Someone will investigate further and fix it, check back here or watch commit log.

I have updated the mmaps_one branch

All branches fast-forwarded earlier today

cherry-pick, modify the file, then compile

It needs to be exactly like what I put above, or you will get compile errors

11222 is the commit that probably caused the problem - we need to use something before then to see if it was working before that

To resolve the cherry-pick conflict, edit src/shared/revision_nr.h

It needs to look like this:

#ifndef __REVISION_NR_H__
#define __REVISION_NR_H__
#define REVISION_NR "11234"
#endif // __REVISION_NR_H__

You don't need to commit afterward, because you will want to discard these changes later in order to pull from mangos master again.

No, you can do this to keep the database working:

git cherry-pick -n 1ae9b1eaf