Jump to content

floop

Members
  • Posts

    17
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

Posts posted by floop

  1. The biggest problem is, that LUA does not bring any really big advantage over C++ scripting, and it is really slow.

    To seriously improve scripting while keeping the speed we'd need some targetted language I am afraid.

  2. floop: btw .. maybe it's better to leave every developer his own repo .. as he might want to send several pull requests at the same time.

    Every developer *does* need have his/hers own repo :)

    They just should also have their own branches for all the tasks they do.

    I wouldn't want to put branches on the main repos, there's no point.

  3. I am working in a place where linear development is something of a past - there is dozens of programmers, and we all do work on code using GIT.

    It's the release management task that makes the 'linear versions' out of all of those things, and it is somethign that MaNGOS admins should do.

    It is how we use git:

    There are three major GIT repositories. One is called "production", another is called "uat", last one is called "testing"

    On "testing" there is always a version that is actually processed by.. um.. testers :). UAT is done by end users.

    On "production" there is always a released version.

    At start, every developer does clone from current production version (some exceptions apply but rare, only when we do the parallel development of few productions at once)

    1) Every task done by any developer is in his/her own branch of the repository clone

    2) After finishing task, they send the confirmation that change from their repository is ready to be picked up from branch 'xyz'

    3) At some point, release manager pulls data from finished tasks into test repository. The version numbering is assigned by release manager

    4) When testing is finished, release manager decides which features will be pulled to the "uat" version

    5) Tests are proceded again, this time on "uat" repository version

    6) If they are fine, everything is pulled ito "production" repository.

    It's the *release manager* task to pick up which tasks are to be combined into release, and his/hers task to assign versions. Normal developer is never able to pull data into even the testing repository.

    If more than one developer should work on one feature, they can do their own repository tree structure themselves. Feel free :)

    The key is to make all development in branches. Every separate task = separate branch, or sometimes even separate repository clone.

    We work like that for quite few months, and after initial whining ('what was wrong with SVN???') nobody is trying to get back to Old Way.

    Especially those who were forced to do few larger merges in SVN :)

    So... how I'd like to see it in MaNGOS?

    I would love to have similar structure, maybe not as complicated but rather:

    + "Released Version"

    +-- "Next version" (nightly?)

    +---- | all developers

    This way the data from developers could be pulled into "Next version" repository, and when all features are tested and complete, they could be pulled into Released Version. How numbering is done, it's up to person responsible for the pulling task.

    Sequential revision numbering is really a bottleneck.

  4. Guys, please, calm down.

    GIT, as any other of the source systems is for *developers*. And it is developers that do the work, regardless whether it makes your life tad more complicated or not.

    Learning how to do a git clone is is like... um.. 5 minutes if you are not drunk. You'll quickly appreciate the speed difference at first checkout, trust me.

    And you wanted patches to appear faster? You have chance now.

    If you want to make such fuss over GIT, you can as well throw away whole linux and quite lot of other systems that went *ahead* of SVN.

    And goodbadguy, in GIT you don't really do patches, you do branches and then they are updating all by themselves whenever you pull something from the master repository. It's *really* easy, but requires you to stop thinking of 'patches'.

    1

  5. I got bit pummelized on trying to fix the buggy RandomMovementGenerator by doing the database changes, so instead I just sat on the code of this class, and wrote it more or less from scratch.

    What is broken: RandomMovementGenerator. Come on.

    What was fixed: For each creature, the new generator builds a list of possible walk points, taking into account the map, vmap and objects (so creatures can walk on objects). Later, the waypoints are choosen randomly, and limited by LOS.

    As you can see, each creature needs quite few of calculations, which can make your server crawl, especially when loading large instances. And yes it does work in instances.

    Here is the patch:

    http://pastebin.ca/1013607

    Stil to do: Make additional table for mangos, to cache up the generated walk points, including a gm command to cleanup them for each creature ect.

    Bugs:

    * Currently, some objects that shouldn't be treated as non-passable, are returned from getObjectHitPos function of IVMapManager. That makes creature be able to walk on trees sometimes, when the tree leaves touches the ground. Common example: Coldridge valley.

    * Sometimes, the creatures still walk through the standing objects, common example: rats in Karazhan

    update: Fixed the wallwalking in few cases in instances, still not perfect but much better now.

    update 2: Made creatures do not attempt wallwalking on pathes that have more than 45 degree up/down, it should fix some cases too.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use