Jump to content

blueboy

Members
  • Posts

    723
  • Joined

  • Last visited

    Never
  • Donations

    0.00 GBP 

Everything posted by blueboy

  1. Hi Guys Problem: I've been working on the bot height issue. Occassionally bots will disappear altogether below the ground level. They also tend to hover just above the surface. As you are aware, MaNGOS utilizes two sets of maps to describe the world's surface. maps Basically define the world. These are usable, but game play is abysmal. For instance, if you try to explore dungeons with just maps, hostiles will come at you from all directions, passing through floors, walls, and ceiling. vmaps Facilitate Line-Of-Sight (LOS) calculations, that effectively make floors, ceiling and wall opaque to hostiles. These LOS calculations also go some way to stop bots & NPC's from passing through solid objects. You retort, not very well :rolleyes: At present the calculation will either use the raw calculated (Z) height coordinate, based on maps, or the LOS (vmaps) coordinate, if activated in 'mangosd.conf'. I have found that the contours of 'maps' and 'vmaps' do not match (i.e. peaks and troughs in the landscape). The result is that occasionally bots will disappear into a trough below the visible surface, based on either of the calculated methods. I thought that it might be an improvement if the calculated height could be based on both methods. This is where I need your help. I have created a patch to test, and would be grateful if you could try it out on your servers, diff --git a/src/game/Object.cpp b/src/game/Object.cpp index a0ccace..eab34f2 100644 --- a/src/game/Object.cpp +++ b/src/game/Object.cpp @@ -1428,9 +1428,20 @@ void WorldObject::GetRandomPoint( float x, float y, float z, float distance, flo void WorldObject::UpdateGroundPositionZ(float x, float y, float &z) const { - float new_z = GetBaseMap()->GetHeight(x,y,z,true); - if(new_z > INVALID_HEIGHT) - z = new_z+ 0.05f; // just to be sure that we are not a few pixel under the surface + float map_z = GetBaseMap()->GetHeight(x,y,z,false); + float vmap_z = GetBaseMap()->GetHeight(x,y,z,true); + + // sLog.outDebug("UpdateGroundPositionZ: x: %f, y: %f z: %f vmap_z: %f map_z: %f" , x, y, z, vmap_z, map_z); + + if(vmap_z > INVALID_HEIGHT) + z = vmap_z; // add or subtract say 0.05f, to adjust bot hover height + + if((map_z > vmap_z) && (map_z > z)) + z = map_z; + + // sLog.outDebug("UpdateGroundPositionZ2: x: %f, y: %f z: %f vmap_z: %f map_z: %f" , x, y, z, vmap_z, map_z); + + MaNGOS::NormalizeMapCoord(z); } bool WorldObject::IsPositionValid() const and give me some feedback. Cheers
  2. Hi, O.K there is just one line to add. The declaration of 'pCreature' // Playerbot mod Creature *pCreature = GetPlayer()->GetNPCIfCanInteractWith(guid, UNIT_NPC_FLAG_NONE); If you go to function HandleGossipSelectOptionOpcode() in NPCHandler.cpp @ ~321, add the line just below //Playerbot mod. * Check if there is a declartion further down. If it exists, it should be O.K to remove, to complete the compile. The reason I suggested that you use the patch in post #455 as a guide to remove the 'bot guy', was that I found 'bot guy' caused other issues (i.e. If you select some other NPC's they also caused the server to crash. Once I removed the code, it was fine). Print a copy of the patch from #455 1. Look for lines that begin 'diff --git', this will tell you the file being patched. i.e diff --git a/bot_readme.txt b/bot_readme.txt 2. examine the blocks of code that start with a '+' symbol. Look in the corresponding file for this block of code. Then either delete it or comment it out. As you do not use 'bot guy', I believe it is best if you remove it. Edit:IMPORTANT Lines that begin with a '-' symbol will need to be restored. * Oh one other thing. If you do decide to remove the 'bot guy' code do not delete the 'pCreature' declaration I mentioned above, or you will get the same error again. Hope this helps
  3. Hi Have you managed to compile your server now. Let me know Edii: If the 'bot guy' code is not important, you could remove it like I did. Use the patch in post #455 as a guide to find the code.
  4. Hi gundisalvus , Sorry to sound negative about your issue, but I think the support from the 'wow-v item forum' have given you the brush off. I have never used this item creator myself, I'm quite happy with the standard items. Have you tried running the server without your modified items. The errors suggest that this item creator has tried to modify data in the mangos database, unsuccessfully. Try loading a clean database, to remove the corrupt data. The database is probably using the values for other items, and thus the conflict (still using DB value). This is not a MaNGOS or playerbot issue, but is firmly in the lap of wow-v item creator support. It has nothing to do with poor code compilation. As I said in my last post you can expect some warnings as the database load, these are normal. Hope this helps
  5. You need to use a database that is compatible with the MaNGOS/Scriptdev2 code. Many projects that develop databases for MaNGOS, will suggest the appropriate versions. I assume your maps/vmaps/dbc files are O.K, otherwise the database would not load at all. I personally use PSMDB database, and it works fine. http://svn.assembla.com/svn/psmdb_wotlk/ Look @ 'Supported_Revisions_&_Silvermoon_Contact.txt' for info Edit: Expect some SD2 Table & RegisterSelf warnings. These are normal, the database is being developed and they can't resolve all issues at once Hope this helps
  6. Hi belfedia, I guess you will find that the compile will stop @ CXX NPCHandler.o ../../../src/game/NPCHandler.cpp: In member function ‘void WorldSession::HandleGossipSelectOptionOpcode(WorldPacket&)’: ../../../src/game/NPCHandler.cpp:317: error: ‘pCreature’ was not declared in this scope make[3]: *** [NPCHandler.o] Error 1 Oh boy, I thought this was history. The cause of this is simple, they optimized the MaNGOS code and moved the declarartion of 'pCreature' further down the function. This was part of the controversy, I mentioned earlier. I kept the block of playerbot code (~321) at the top of the function, and added another declaration. Look at post #455, that shows all the 'bot guy' code in one patch. This worked for me, but didn't for other users. They chose the move the block of playerbot code to a point below the new 'pCreature' declaration. I found that this caused my server to crash when selecting the summoned 'bot guy'. If you do not use 'bot guy' it is fine. If you do then, you will have issues. We pulled the 'bot guy' code because there was no mutual resolution. Thus the patch, I included in #455 for those who wish to fix it. If we can find a mutaul fix, then maybe it can be re-introduced to the playerbot code. I personally prefer using macros to summon multiple bots. Hope this helps
  7. I hope you don't mind editing code. Open the patch I sent you. Search for NPCHandler.cpp. The error occurs @ line 321 patching file src/game/NPCHandler.cpp Hunk #3 FAILED at 321. 1 out of 3 hunks FAILED -- saving rejects to file src/game/NPCHandler.cpp.rej patching file src/game/Player.cpp Every patch begins and ends with a three line pattern. If this pattern changes the patch can't be applied, causing the rejection. If you compare the pattern for patch @ 321 with the code in NPCHandler.cpp you will see it has changed. Remove the lower pattern if (!code.empty()) { if (!Script->GossipSelectWithCode(_player, pCreature, _player->PlayerTalkClass->GossipOptionSender(gossipListId), _player->PlayerTalkClass->GossipOptionAction(gossipListId), code.c_str())) replace with // TODO: determine if scriptCall is needed for GO and also if scriptCall can be same as current, with modified argument WorldObject* // can vehicle have gossip? If so, need check for this also. save the file, and try it. It should work. I suggest you do not try using the 'bot guy' as this caused alot of problems at the time, which prompted us to remove the code. Edit: I know these look like four lines of code, but they are three long lines of code that have wrapped. I hope this helps
  8. O.K this is with MaNGOS[8994]. As I remember this is caused by conflicts with the 'bot giver' code in NPCHandler, and changes they carried out to MaNGOS. We have since removed the 'bot giver' code from playerbot. If you are patient, I'll try to sort it out. I'll get back to you.
  9. The reason it appears to work, is that you insist on using 'git reset --hard' As far as I know this will reset the repo to the HEAD. On blueboy this is currently [9422]. I have never used '[8994]'. The easiest way to check the current version or HEAD of your local repository, is by issuing this command, I prefer to use 'git checkout' to switch branches than 'git reset --hard' git log Then observe the closest MaNGOS commit from the top. Edit: I think you are confusing patches with commits. As I said, the patch that is provided with Scriptdev2 does not refer to the version of scripdev2 or mangos being used. The 8759 is given to tell that the patch works with all releases of Scriptdev2 after MaNGOS[8759]. It is used for binding, and has nothing to do with script or code versions. The patch I provided does refer to code versions i.e ManGOS [9865]. Hope this helps
  10. Are you sure your using Scriptdev2 [1513]. The patch '8759-scriptdev2 patch' is used to bind Scripdev2 code to MaNGOS code so they compile together. Edit: '8759-scriptdev2 patch' has been used with every release of Scriptdev2 since MaNGOS [8759]. Sorry typo with Scriptdev version above, :rolleyes: Scriptdev2 is currently @ [1587] Hope this helps
  11. The 'SpellEffectIndex' & SPLINEFLAG errors are caused only in recent changes made on the MaNGOS branch. Are you sure your using MaNGOS[8994] and an earlier version of ScriptDev2, say ~ [1513]. The latest Scriptdev2 will not work with MaNGOS [8994]. Edit: use this bash script I created, and specify the version of scriptdev2, as a command line parameter #!/bin/bash unset VERSION unset DEST VERSION=$1 DEST="/home/mangos/compile/mangos/src/bindings/ScriptDev2" if [ -z "${VERSION}" ]; then echo "No ScriptDev2 VERSION specified, assume latest VERSION"; else VERSION="-r "${VERSION}; fi if [ -d "${DEST}" ]; then rm -R ${DEST}; fi mkdir ${DEST}; svn co [url]https://scriptdev2.svn.sourceforge.net/svnroot/scriptdev2/[/url] ${DEST} ${VERSION} Hope this helps
  12. Hi Guys, Due to popular demand, I'm going to setup a parallel repo to blueboy, called patches. This will contain my current and future standalone patches. The repo will be @ http://github.com/blueboy/patches Please stop sending me requests , I will have it up and running shortly Hope this helps
  13. Hi, The script I posted in #394, just automates the process. If you are using windows, and can't create a compatible script, do it manually. Copy and paste the HASH from the [8894] commit obtained from 'git log'. I see that you might have a problem using blueboy as a remote repo. As I said in my last post, it will default to the current commit or HEAD. You cannot select an earlier commit, to do the merge. Solution: I have archived copies of the patch I created. If you send me your email address by private message on this forum, I can send you a copy. I have patches compatible with the following MaNGOS versions [8874] [8898] [8917] [8965] [9043] Then apply the patch as follows to a clean download of MaNGOS patch --dry-run -p1 < playerbot.patch Note: --dry-run allows you to test the patch before applying it Edit: Alternatively, you could just clone blueboy to your harddrive. git clone git://github.com/blueboy/mangos.git Then switch to the version you require git checkout -b 8894 HASH // 8894 is just a label Add other mods, and then compile. The appropriate version of MaNGOS will be integrated into the code. You need [8994], yes!. Why not download say the [8965] commit (rename 'mangos' to 'b'). That's fairly close to what you require. If you create a parallel repository on your harddrive (rename 'mangos' to 'a') with MaNGOS[8965] only. You could use the 'git diff' command to create a local patch. git diff a b > playerbot.patch a & b refers to the two local repos. The patch created should work with other MaNGOS commits. Download a clean MaNGOS[8994] and try to apply the 'playerbot.patch' created. Hope this helps
  14. Hi Guys, I have just updated blueboy with the adjusted code, that resolves errors caused by the 'SpellEffectIndex' changes. There was a delay between the merge and the commit, so I could test it. I have tested it with the following, and it compiles and runs without issue, Cheers
  15. @nickless & vladex Hi guys, I assume your using the latest code on blueboy. I am running this with I'm having none of the problems you list. If your system differs much from my setup, then conflicts will be expected. I suggest you stick with MaNGOS[9387], until they have sorted out all the renaming, that they are doing.:rolleyes: I will address the issues you list, when I update blueboy next. Edit: edit DBCEnums.h to include 'SpellEffectIndex' enums, i.e EFFECT_INDEX_*. Insert '#include "DBCEnums.h"' in several files, details MaNGOS changelog in commits ~[9410]+ Hope this helps
  16. Hi, I recommend you do the following; git clone git://github.com/mangos/mangos.git cd mangos git log // Find the commit pertaining to MaNGOS[8994], and copy the HASH git checkout -b 8994 HASH // This will create a local branch called 8994, that points to MaNGOS[8994] git log // check that 8994 is the current HEAD git branch * 8994 // current branch master Now you can setup a remote branch to merge with this local branch. If you wish to merge with an earlier version of playerbot code, compatible with MaNGOS[8994], you will need to create a standalone patch. Then, apply this to the local branch manually using Gnu patch utility. I have detailed how to create a standalone patch in a previous post. patch -p1 < playerbot.patch Note: A remote branch always points to the current HEAD, of that branch. In the case of 'blueboy' repo, this is only compatible with a latter version of MaNGOS i.e. [9387]. I suggest you update your client to 3.3.2 and run with the latest playerbot code on blueboy to avoid too much hassle. Hope this helps
  17. If you take a closer look at this thread, you will see that we have been using http://github.com/blueboy/mangos since December last year, for playerbot code. The code in the original github http://github.com/playerbot/mangos is only compatible with MaNGOS[8898]. Edit: The current code is compatible with server MaNGOS[9387] & client 3.3.2 (11403). Hope this helps
  18. Hi, I'm no expert either. When I first setup 'blueboy', I forked off the main playerbot branch that was labelled 'master'. If I understand your question, your concerned that the playerbot branch 'master' is labelled the same as the MaNGOS branch, also master. When you do a merge, you setup a remote branch to merge with the local branch on your harddrive. The local & remote branches can be labelled to anything you want, e.g. #>git checkout -b orange <version HASH> // create a branch locally called orange, #>git branch * orange master // 'master' refers to the HEAD of the branch #>git remote bananas git://github.com/<repo>/mangos.git //arbitrary label 'bananas' #>git pull bananas orange Hope this helps
  19. Hi, We are current downloading playerbot code from the blueboy repo @ git://github.com/blueboy/mangos.git How difficult is it to install? That depends on you.. You can either create a standalone patch, and apply this to a clean download of MaNGOS, or merge the blueboy repo with your existing install. Then compile as normal. I have provided info on creating a patch in a previous post on this thread. If you want to merge with an existing install, take a look at the first post on this thread. Because of continuous changes to the MaNGOS branch, be advised by the version of MaNGOS used with the playerbot code on the repo. This is shown in square brackets in the commit description. If you disregard this, expect conflicts! Edit: sorry, I just noticed that vladex posted an excellent reply to your question Hope this helps
  20. Hi Guys, Sorry for my absence, I've been re-building my server. I have just updated blueboy, merging it with MaNGOS[9387] & I have tested the server with, auctionhousebot[Naicisum] autobroadcast[Xeross] PSMDB[292] updated SD2[1573]updated It compiles without issue and appears to run well :rolleyes: P.S I'm sure your aware that you will need to update your client to 3.3.2 and create new [maps] & [dbc] files. Cheers
  21. Hi, are you entering the command as 'FREE', it most probably is case sensitive. Try either /w <botname> free or /p free Yes, I have just tried it. I'll have to revise the code to handle all permutations. In the meantime use 'free', its impolite to shout anyway Hope this helps
  22. I agree, mine played up too later. I have found a way to minimize the risk of crashing, until such time as we can fixed it. This issue seems to occur after compiling a new server. 1. Exit the client completely, and delete the 'cache' folder from the World of Warcraft folder. // should only have to do this once 2. If you then logon, and summon the bots indiviually, it behaves. //should only have to do this once 3. It then allows you to load multiple bots using macros without issue from then on. Try it, and hopefully it will work for you too Cheers
  23. I believe the bottleneck issue has been solved, with a change to the core. I have tested the latest MaNGOS[9284] with playerbot, and I can't get the server to crash :cool: Before MaNGOS commit [9284], it was very sensitive, and if you tried to load multiple bots, using macros, it went down like a brick. Please try this yourselves and confirm it is so (I know nyko was having the same issue) I have updated blueboy if your interested Cheers
  24. Thanks for the info, but I posted a workaround for this issue yesterday #699. The issue was drawn to my attention by shum But thanks all the same. I will update blueboy when I can. Who knows why they decided to change the flag names from MOVEMENTFLAG_* to MOVEFLAG_*, perhaps its just because the name is shorter. The change is only cosmetic, and I agree with erazare that these changes just cause additional work, without much benefit. I have just tested the latest MaNGOS[9284] (with the MOVEFLAG_FLYING changes in PlayerbotAI.cpp) with SD2[1557]. It compiles without issue, and I have again tested the 'mounting' . Everything checks out.
  25. Until we get this matter sorted, I think it best to keep the mods to a minimum. I am presently compiling the latest MaNGOS[9284] & SD[1557] with blueboy code. I'll get back to you Cheers
×
×
  • 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