Schmoozerd

sart, can you extract and share the part where these spells are used from your sniff? I only have information for spells "Claw Rage" From reading about the spell I thought the AoE should be triggered 9 (wowwiki) times on a timer, and should hit one target, onto whom the boss then charges. (Mainly because I doubt that the many charge spells are cast onto different targets within the same moment)

I cannot tell you if this option exists on VC100 express or not, maybe it is just hidden. For VC2005 you can try the following: * try to use cmake to create project files (it should work) * revert the (recentish) commit where zergtmn removed vc80 support, then you only need to manually add support for creature_linking

thanks for the patch. - I agree that the mana on the aura-target must be removed manually (no spell around) - I cannot see proof that each mana does 1 damage, but this might as well be correct - I am pretty sure that your implementation that the aura-target should not be affected by the spell is wrong I think the AoE spell with TARGET_EFFECT_SELECT, TARGET_ALL_FRIENDLY_UNITS_IN_AREA must NOT target the caster. Don't know yet if this is rather generic or not. this needs more research.

yes, as stated in the README. You must apply a couple of additional updates to keep core and database in sync. In your case you have a newer core than the structure of your database is for

Hmm, maybe very important points. At least I cannot tell what is happening on mangos.ru The main problem is not that I am too lazy to use google translator, the problem is that I have absolutely no feeling on which posts/ threads I might be interested in doing so. But sure, this is mostly my problem - this by the way would be another point that will become easier with adding pull requests. the simple message "Here(LINK!) is something interesting" might indeed be very useful. All I am asking with my plea for pull requests is that this message is transported. A short note on censoring (actually I think it might be worth to split this to another thread..): No, I think I never deleted any message from you sart13 on the mangos forums. (I removed a few posts from this thread here to the subforum called "trash-bin" which should be transparent for the posters in question) @Skirnir - The point where I have a problem is that _sometimes_ (not even related to most stuff rsa does, because I know I could look into the fork sources) when reading "Did this nearly a month ago" I have the urge to write: "Then why didn't you tell, ****** ")

yes, difficult questions how to handle this best. I personally know of no case where respawn-delay should be short and the npc should respawn, so maybe it was a good choice to set the respawndelay for most temp-summon types to some reasonable value (other the 25s) For summoned mobs respawning I know of one case: the adds of majordomo in case of a fail (might ofc also be possible that this should be resummoning) In scripts usually we want to use OOCTIMED_OR_DEAD to have despawning in fail case, and despawning after being dead as most natural choice. Possible this should be replaced with DEAD_DESPAWN and the linking now (despawn on fail)

I disagree strongly in this case. Currently the idea is very simple: the mobs follow in the way in which they are spawned. This enables all sort of formationing. Possible there are some mistakes in the code here in the calculation of angle and distance based on spawn positions. Also maybe following does not support some formation where the mob that is following is walking 'in front of' the mob it follows. But not even sure if this should be considered as bug/ missing feature from the core or bad logical interpretation of following.

I think I might have been misleading. I really did not want to complain about anything you two guys did here (as it is a great job in any way). I just wanted to note a few things that I might miss - before looking into the code. I know mangos has been sloppy on documentating, but the more that is documentated the better. About discussion points I remember we talked in this thread about problems related to AI behaviour in case of non accessible enemies - so I (as I come from scripting side) will directly have as concern how these parts of interaction have been solved. Discussion might for such a project mean that you note in a review-thread how you solved things, which problems you think, and why you have discarded which alternative solutions. Really no complaining intended - I just try to tell what I think might make getting into this code easier (for a newb like me) Btw - even if you did not start this project/ thread, as you are very familar you _can_ post it in the review section when you think. But well by now at least I know that this is topic is hot, and likely I will try to get into it when I have time. (without this one post I wouldn't have known this) Edit: Some example of a thread I really like, because it really contains discussion: In my opinion such threads are the most important of all, because they make it possible to understand what other people are thinking. http://www.scriptdev2.com/showthread.php?t=3930 (though a very simple problem - syntax)

You shouldn't measure time in quantity but by quality. I guess for a project like mmaps we would require * 1-2 serious feedback tests on performance * Some discussion points about parts where it is not clear how they behave. If this would be done within a week, then the time for review is likely 2 weeks, if this feedback wouldn't be given within 2 years, then you cannot expect review to be faster

Short intermezzo: I have split a bunch of posts that didn't lead to nowwhere from this topic into the trash bin; PLEASE do PM me if you think this is bad style of moderating! So, what can I say (as one of the new green guys here) * Interest in contributing is "currently" extremely low - this is ofc also a big reason for slow progress * Silverice does much work, especially to redesigning movement related code - this unfortunately often ends in directions that don't work out, but take big amounts of time. * Laise works on LFG - which also seems to be complicated and there is not much on which one can build. We had some discussions about ways to make contributing for mangos (and sd2) more attractive, I tried my "icc project" on sd2 side, but only counted so far 2 ppl actually doing things there and at least 2 giving feedback that they like it. Also there is discussion to add a "heap" branch where devs can stash commits with which they are not yet happy with. As I wrote in the other topic - the main time killer is not writing code, but to discuss code and even more to discuss concepts. Actually this is - in my view - the thing that splits between power contributors and developers. A dev must be able to discuss and argue about the code, and I see not many ppl around to do so. Unfortunately because there are many ppl around whom I consider as smarter as me(in area of coding) - but without communication this leads to no good. So back to my proposal of using more pull requests: YES, I think this would be serious benefit, _especially_ because atm we are not many active developers. Sure, the biggies won't get in faster with this. But the biggies are not the things that makes development look dynamic, nor are the biggies the real time killers. It would be a huge benefit for all if the 3 line commits would be added to pull requests, maybe we could even make mangos policy in accepting less strict (either a spell fix is right or wrong, but this doesn't destroy our code in any serious ways) Reviewing these then would be rather fast, and accepting might be just a click away. But well, people are not interested in contributing in this way, so no use to come back to this point. It is obviously too much to ask for that mangos clones would be named mangos forks on github to be able to add pull requests. The thing that currently happens is, that some people write enourmous "all cool systems" and stuff, in which they _do_ have good stuff, but instead of adding a pull request for a 3 line change (which could be accepted fast) they seem to be more happy to wait until some time later a dev needs such a feature, and adds the same 3 line change, because then they are able to complain that they have done this months ago. Not much fun to work in this So, all in all: Mangos devs exist, and are motivated to keep mangos going, but some more effort from community would be greatly appreciated - because doing work so that you are told that you are stupid because these things were done years ago already or that you are stupid because they were since long time being improved is really a killer for motivation.

oh - I didn't even know you consider this patch as "finished". A thing I missed about AHbot: Do you have serious and clear enough documentation? (both user side as code side) Other then that, I think we need someone to explain what this code actually does, where remaining problems lie, etc. In short: communication. I won't be around this weekend, and also don't have much time currently available, but I know that I won't look into such a complicated and big patch without being sure that there is somebody who explains it to me (as I am usally slow and stupid I would need assistance) Also ofc some more communication with Silverice is required, because he has always good ideas for changes related to movement handling in his mind, and maybe we would be better advised to schedule such projects. Also especially directed to qsa and faramir: One big step about developing is not "only" to write code, but to discuss the code and argue about weaknesses in the code. This is actually one of the things that slows mangos down the most: we try to discuss most serious changes, and this takes most of the time.

Hmm, If I see this correctly, this was added in [11835] Thank you

71328 I think should be cast when queuing up to lfg Indeed 72221 is cast after the teleport is finished. However it is possible that this must be cast genericly whenever a player is logged in into a dungeon while in a lfg group. (relog problem). I think probably a good place would be to use a procedure of OnLogin-Handling, especially related to spell 836. I don't think that 72221 should be cast by the dummy effect of 836, because I have this kind of log: (however I cannot be sure that the order in this case of things in my log is the order that must be used) - cast 836 - MSG_MOVE_TELEPORT_ACK - A bunch of aura updates - cast spell 72221 (clearly later than 836)

can you give example what spell you need to cast related to teleporting? And also the information when this spell must be casted?

Well, I'll just give my reasons why I did it the way i did: * Entry based tables are much better to maintain for DB-guys -- hence it should be easier/ faster to get the table filled with values * Lots of cases can work with entries * The patch already got big enough as it is (~1000 lines) - guids would have enlarged this again * Entry support is more complicated as it is dynamic, hence it was necessairy to implement the entry support first But yes, guid support is planned, but I don't know yet when I will find the time to implement it - ofc I will look into any patch that might be posted for review

obviously at sd2 site. take a look into http://www.scriptdev2.com/showthread.php?t=4411

then please tell my any post on this page where he actually discussed code. He is - as anybody else - invited to post stuff _at topic_. If he did so, I wouldn't have complained. Laise's edit : Yea I deleted all useless(to vehicles development) posts after this one

Yes this should do it. However I cannot tell you if this is correct in terms of what should be done from retail

Use a cmd to start the ad.exe - this way you will catch the output of it (maybe just need to pass a param for the directory - in your case . )

A few thoughts I had: * EventAI cannot be extended reasonable to support this, mainly because we need such a "onGossipHello" feature for both npcs and GOs * npc_spellclick_spells also is no reasonable place because of the required GO support So from current point it looks like: - either do these cases with sd2 - or do it like you suggest

In my opinion such "filtering" should be done as part of the threat management. If you are interested, maybe look here: http://paste2.org/p/1400454

Well, I would say within 3 days more actually. Counting from the moment there was the first serious feedback.

it depends if the first target will lose its state of control due to damage.

Well, I think it is enough. Rsa, if you cannot manage to contribute in any way to a thread, then stop posting.

I just updated (without understanding) the old code, which Kid10 prepared. it can be found at https://github.com/wow4you/mangos/commits/Vehicles But as it did never work proper, nor is it very beautiful code, and likely I just screwed everything when merging to recent changes - don't expect much. (Actually I really don't care much about custom code)