freghar

To be more exact - most 32bit systems can use up to 64GB of RAM, they just can't address it directly. Even more accurately, 32bit VAS is always 2^32. No more, no less. However a 32bit app can't use entire 4GB, because it needs already-mapped (loaded) system/user libraries, it needs addresses for various system calls (like mmap()) and so on. That gives 3GB of RAM on newer (AFAIK post-2.6.13) Linux systems for in-process user data (ie. 3GB can be malloc()'ed).. Windows have 2GB by default, but it can be changed to 3GB via some /3GB switch in boot.ini or so, it never worked for me. The situations is the same on 64bit system using 32bit userspace application. The app stil needs to access all those shared/system calls, it needs _some_ way to talk to the kernel and since the app itself uses 32bit pointers, it can't use addresses larger than 2^32-1 for it. This is not true for 64bit userspace applications, obviously.

Back then when I used to work with this, there was something I remember as HasSpell() in Player.cpp, perhaps it's still there.

Please forgive me for being a bit offtopic. I don't get it. I'd get it if some git-newbie had used it this way, but I think you're smart enough to have some logic explanation behind it. Because having a replica of mangos/master just doesn't make sense to me, but perhaps there are graphic tools I don't use (tortoisegit, ...) that need to have origin/master reflect some foreign branch, so please enlighten me, I'd really like to know. Thanks.

Probably *both*.

Did your research include http://portforward.com/ ?

In ideal case, there would be something like git fetch git://github.com/mangos/mangos.git 2cb35a12 git cherry-pick FETCH_HEAD but, unfortunatelly, git won't eat it that easily. However there's still noob-proof git fetch git://github.com/mangos/mangos.git git cherry-pick 2cb35a12

Because it makes a dynamic memory allocation. Doing it like mangos *pMangos; mangos f; pMangos = &f; not only removes the need to call "delete", but it creates all the variables directly on function's stack, saving a few kernel mmap() calls. On the other hand, it's total nonsense to create a pointer to "f" in the same scope (no, it won't speed up anything, it'll even slow things down a bit). Learning pointers in C++ code might be a lot harder, i'd suggest learning those in C99 instead. No C++ complexity involved + you can easily disassemble the binary and see how it works.

That's why I pointed out the "NATs". The traffic can actually go through router (making *.thruhere.net work from everywhere) - most small embedded routers do that by default. It's not a clean solution, though.

Sure, mangos uses intel's TBB library to speedup windows allocations (for example). ICC compiler isn't as cool as it might look like, it negatively (and intentionally - proven) affects non-Intel CPUs.

Notice the difference: http://openpaste.org/en/20497/ (ending NULL doesn't really matter, I've tried to (ACE_Thread_Mutex*)NULL it, but the error obviously remained). The problem probably lies in the "reference". Might be related to http://gcc.gnu.org/ml/gcc-help/2006-09/msg00322.html: edit: btw; The performance gain from map preloading won't be THAT much, .. since most modern OSes use free RAM for block-level (LBA) disk cache. It will be somewhat faster (no additional layers, no extensive in-memory copies, ...), but it won't be really that much.

That's probably not the issue, I'll take a look at it if Zor has it in his github repo. edit: yes, it looks like some namespace issue

First check your firewalls and NATs, then check your BindIP (should be 0.0.0.0). Also try putting *.thruhere.net to the realmlist table. It might also be DNS caching delay problem.

Because I'm deleting any new "it would be nice to have LUA in mangos" threads ... perhaps?

btw .. there's no need for dedicated svn mirror anymore - http://github.com/blog/626-announcing-svn-support so you can use http://svn.github.com/mangos/mangos.git

What about you trying to find something yourself? Seriously, your questions and errors here belong to person with IQ below 50. I've suggested the rc.local way (which would work on OS startup as well), perunio here provided the simpliest working process restarter ever, xeross supplied his python script, so I'd simply choose one way and try my best with it. Google included. Simply said - run the small loop (with added sleep delay) in a screen session started by rc.local. That's it. No need for PID lookups, no need for every-minute checks.

Not enough mana.

You can make cronjob for that ... or do something like su mangosuser -c "command to run mangos" from /etc/rc.local

As far as C is concerned, you can't. It'll throw a compilation error about undeclared variable. Simply because "test" is a data type (class), not actual variable (and thus you can't get it's address).

Using black magic.

Go for ASM if you need low level embedded non-portable programming. Go for C if you need "somewhat" portable code and want to have control _how_ your program actually does things. C is generally good for system-level programming, I say it's a good compromise between assembly and high-level languages. If you turn off all compiler optimizations, you can write all the functions, variables, structures (almost) exactly the same way they'll appear in the final executable. Go for C++ if you need higher-level portable programming and OOP style. Some people say it's "an extension" to the C language, they also say it's "not really a good way to extend C". C++ could indeed have better design and syntax specifications, but anyway - it's the most common language today (imho) and that's what counts. You can use C-like variables and structures in C++ to some degree. With C++ comes great responsibility for code concept, you can do MUCH more things in MUCH more ways than in C, which can result in a total code crazyness - don't forcefully use everything C++ offers just because it compiles fine. Go for C# if you .. well, I can't really say. Many people warn about Microsoft's claims on intellectual property in relation to mono. On the other hand - it *might* be a good language for Windows-only apps, I haven't really tested that. Don't expect to get the same portability as with C++. Go for Python/Java/Perl/whatever if you want ultra-portable code and true high-level syntax. Many people use Python with PyGTK to make nice GUI apps without having to fight the low level issues. Some guys here might say "naah, those high-levels are WAAAY too slower than C++". Yes, they're right. But the slowdown isn't really noticeable in common applications. It's even less noticeable when it comes to PyGTK/PyQt as the same graphic lib gets used anyway.

What about *_respawn tables?

And sad news; I'll be shutting down the mirroring service in about a month. It shouldn't impact anything really, all those mangos mirrors are probably not used by anybody and github stability has increased over time, so ..

.... which doesn't work.

Their "really very soon" (= "we're working on it") work has taken ~3 months so far and still isn't finished. So I expect "soon" to be "maybe in 2015".

That is exactly the reason why people don't like it. They don't want / have no time to spend on "learning git". I understand that, I really do. Why bother learning windows when I have my good old easy DOS prompt, which has even some advantages over windows. Git isn't perfect as well. But - in the end - I don't care. SVN isn't really bad at all, the problem here could be misleading revision number (different from mangos).