xeross155

Couple aesthetics issues that I noticed:

1.) For the drop-down registration it would look a lot better if you put the form into tables so that the text and the text boxes were aligned vertically.

2.) On any page other than the main there is a giant space where the flash was, and that makes it look a little funny.

3.) Also on some pages the background that goes under the background at the top of the page (the one with mountains) is missing, so there is no fluid transition between the two backgrounds.

With regards to 1, The proper way to implement it is using <label> tags with a fixed width.

It looks good, other than the few minor quirks here and there.

This was implemented in MangChat just look through the source, only problem was it even asked if you wanted to join World channel even if you already joined. And force joining is apparently not possible due to client limitations.

you're force-applying each update right?

would be interesting to make an updater that asks mangos version via SOAP and then calculates exactly what is needed

Or just fetch it from the db_version table, that's what I did last time, lost the script though.

Perhaps when this happens restart the server after a while, because the way it is now all looks fine except you'll get an error on login because it doesn't have the mysql connection.

#!/bin/sh
while true
do
   ./mangos-worldd
   [ $? -lt 2 ] && exit 1
   sleep 5
done;

This should work

Is there any way to exclude specific item entry ids? for example any item that has the text "zzOLD" or "zzDEPRECATED" should probably not be added to the auctions. Doing a text search on the name field would be slow/imperfect so one would have to know the id's to exclude before hand, but i'm thinking it would make sense to be able to specify a comma separated list in the conf of ids to never load.

Looking at the data provided by UDB there is no data that says an item is obsolete other than the "zz*" text in the name field, so I don't see a truly dynamic way to exclude obsolete/DND items

This is indeed a good idea and shouldn't be too hard to implement.

En het leeft nog steeds

Cyber: Moet ik de main post nog even veranderen of ?

If we are doing this we should just create a stats.xml with a lot more info, or just implement this in a stats.xml and slowly add more.

This can be easily done through a cron script, what benefit would we get if its added to the core ?

For some reason I am getting 2: no such file or directory

Please carefully read the guide and the things people have said here, if you still don't get it, keep re-reading until you do. And you need to apply everything from the current one it says it has to the latest one in the sql updates folder.

A simple solution to the whisper function, intercept the whisper, check if it's a fake player and return a player is AFK message to the person whispering him

I don't think that patch need update, but if you need I post it evening...

Either I'm doing something wrong, or this patch isn't needed anymore

Wouldn't it be possible to parse the entire file with just 1 regex, instead of line by line ?

@Schmoozerd: Hmm if you want a clean branch you'll have origin/master so you don't really need the local clean master. Though that statement is a bit irrelevant.

Just a quick heads-up that might help some people (Even though this is an old thread).

What I now do when I want to make sure my code stays the same is create a branch based on the current one, and rebase it with master. after that switch to the current main one and merge it with master. After that I compare the 2 for any problematic differences.

It seems the patch was causing this issue, and even after removing the patch cross-faction grouping still works fine, quite interesting.

Edit: Due to the uncommon nature of this, it turned up again, so it wasn't this patch.

Additional Info

After a grid unload/load it seems the mobs are randomly affected again so something is going wrong in the core.

I have some odd testing results, I disabled this modification on my test server and I can still group/trade/heal/anything with the opposite faction, could it be this is fixed in the core itself. Removing this patch also seems to have removed my pesky random green mob bug.

Edit: Bug reappeared, disregard the above, I suck cock.

Just download the patches you need, WoWWiki has a list of mirrors

If it is that patch, which I find hard to believe as I never had this problem before upgrading to 3.3.5a I'll try and fix it.

It modifies a players faction temporarily? that would definatly make hostile mobs turn green seems there is your bug. i know you dont want it to be that but ya its not core related if you have a custom patch that messes with factions that is your bug.

So if an alliance player gets temporarily set horde to allow for cross-faction healing. Mobs that are both hostile to alliance and horde will randomly show as friendly and not even all mobs of that type just random ones and the rest still shows fine ?

And this patch only affects player related actions because the player will still be hostile and KOS for any of the opposing factions NPCs (Guards, etc.)

i use udb 0.12.0(388) and have never had this happen are you sure that the flags on the npc's are set correct in db?

try checking that mobs entry in the creature_template for its factions it could be set wrong

and wat is Cross-Faction Groupingm Auto Broadcaster? that says faction it could have an error recognizing a faction and is displaying it as green?

try the core without it and see if that dont fix it?

I have checked DB entry info, and not all mobs of the same type are affected just a few, so some still appear correctly. Yet their DB data is exactly the same.

Also the grouping just modifies a players faction temporarily to the current party leader's faction and as this even happens to people that have never even been in a party it can't be that. And it also looks the same to everyone, Horde, Alliance, any player really.

And the auto-broadcaster just broadcasts server-wide messages, so that's totally unrelated.

GM mode bug maybe?

It's not a GM mode bug as I've checked this on a non-gm account and a friend of mine also had the exact same issue on a non-gm account.

Still present in 10457

Just a quick note from me Cyber, I have added some changes that would remove one of those helper functions you made http://github.com/xeross/mangos/commit/8f23de6bf174531b478d449776fe8d5b125d7736#L0R869

you might want to use std::tr1::regex instead of boost::regex to avoid the extra dependency

I'm not too sure if tr1 is already considered portable enough

Hello,

Nice job, but why do you use "this->" all the time?

Might be an artifact from learning another programming language first, like PHP. And it makes things clearer when you don't prepend member stuff with m_ I guess.