Paradox

This thread almost makes me want to stay with 3.3.5a forever...

This could mean you overupdated, by updating your DB, and not compiling a new core... repacks cannot be updated by simply updating the SQL...

Also, be sure to fix your GIT path. http://www.trinitycore.org/f/topic/345-howto-properly-install-git-on-windows-fix-trinitycore-rev-1970-01-01-000000-0000/

If you read the actual error log, maybe that would help. Also, it looks like you hit generate without configuring first. Edit: Well, I just tried hitting generate without configuring first, and, it seems to have worked just fine, so, without that log, I'm baffled at what you did wrong.

NO NO NO NO Do not get navicat. and the rest of your post seems like a great way to really fuck things up.

WTF is this supposed to mean? adding a 4.3.4 DB to a 3.3.5a core will just get you errors, it will not get you 4.3.4.

conversion from 3.3.5a to 4.3.4 is also likely to be very painful and will likely require some special conversion tool or SQL, which will likely not happen until 4.3.4 is closer to being supportable... There have been far too many changes on both sides, and almost no care for proper development procedures that would make the task more user friendly.

I can't believe they have still not fixed this issue after more than 5 years, or, that people still use that crap.

When you start the worldserver, it will tell you if maps are out of date, or, you could carefully read all the commit messages before updating... don't expect any kind of announcements like you would get from most projects.

I use a batch file like this: (if you don't want it to delete the sql files after adding them, remove the echo y|del %1 line, or add a ; in front of it.) Also, be careful if you don't delete the sql files, it may be hard to tell if there were any that didn't get added, such as when a dev forgets to put the word "world" in the filename, although, since updates are now in their own folders, you could change set files=*world*.sql to set files=*.sql the only problem with that is, the misnamed ones would be out of order and could cause a problem. @echo off setlocal set files=*world*.sql set output=merged_world.sql echo. > %output% for %%A in (%files%) DO call :MERGE %%A %output% goto end :MERGE if '%1'=='%output%' goto EOF echo -- %1 >> %2 type %1 >> %2 echo. >> %2 echo y|del %1 goto EOF :END :EOF

what about the updates/world folder?

You cannot update just by updating the SQL. Derp

Some spelling and grammar errors, but, looks good.

Why do you idiots keep lying to us? we can't help you if you can't be straight with us. That + at the end of the hash means it has been modified with a PATCH or manually before compiling. And, yes, that includes adding fucking scripts, which is probably where the problem is, and is an UNSUPPORTED configuration. Get the same with a CLEAN UNMODIFIED compile, and start an issue on the tracker, not here, otherwise, go ask the authors of the patch you have added.

I have a feeling it has to do with whatever patch(es?) you added to it. Which is an unsupported configuration.

don't use the external address for the mysql connections.

TrinityCore rev. 5da508c0a0e2 2013-12-04 14:43:35 -0330 (master branch) (Unix, Release) (worldserver-daemon) where do you see 4.3.4 in that? I think you skipped a step with the word branch in it.

well, none of this is anything to do with trinitycore, you should visit VS help sites for these.

Someday everyone will know about this small thing called google, until then, I guess I will continue to be the only person using it. http://stackoverflow.com/questions/16837650/failed-to-configure-cmake-with-visual-studio-2010-express

http://lmgtfy.com/?q=error+MSB3073%3A+The+command+%22setlocal

Well, it has to be you, many other people are doing it just fine.

Because 4.3.4 is Alpha and only meant to be used by those who know what they are doing, we shouldn't even have supported you this much.

my batch file mapextractor.exe vmap4extractor.exe md vmaps vmap4assembler.exe Buildings vmaps md mmaps mmaps_generator.exe pause Shoot, I didn't notice that, but, i have a feeling he is getting that from the extractor itself, which reports the wrong version for some reason.

I don't understand why you are doing it, are you applying a patch that doesn't work with latest revision, but, does with an older one? (probably more than 10 commits back now...)

Why step 3? Also, if you are reverting 10 commits, you should make sure you don't apply updates from those 10 commits, by not batching them together that way.