Warextdll release

[HansW]

New Release.

Just Bugfixes.

I also released a new version of BotPoc that should no longer crash the client with the 0.92 dll release.

For those of you actually working with the dll, i changed some table key names in the Entity and Target result tables. You will need to change them in your code too. ( e.g. DistanceFT is now distanceFT). Sorry for that.

[HansW]

Version 0.93 released

- minor bug fixes
- New options for EntityList : "targetingme"

[PharmerPhale]

twocents

To Lua, or not to Lua? That is the question. (for me) :yuck:

[rockman319]

To Lua is the only way to use HansW awesome dll.

[PharmerPhale]

OH THE HORROR!

...

Ugh, I know this - I've been putting off getting back into Lua for some time now.

[Da_Teach]

To Lua is the only way to use HansW awesome dll.

Actually this isnt totally true, you could load the DLL, load your own DLL and then use C/C++ to call the LUA functions from his DLL.

Ok, I have to admit it probably wouldnt be very sensible, but it could work

[HansW]

you would need to inject your dll into WAR too, because my dll assumes its inside the war process. if someone wants to do this ( which i doubt, cuz when you can code c++ you are able to code lua ), i can export the functions called by my lua functions from the dll. This way you would not need to do lua calls from c++.

The best way to stay out of process would be to inject functions into the war client ( by allocating memory from the outside and copy then over) and then start a new thread in the war client to execute them. You would need to some kind of framelocking in this case, because you run in your own thread, that war knows nothing about.

The reasons for me to use "the lua way" are the following:
- allot of information and functions is/are already present in the original interface code
- no need to take care of any locking because everything runs in a thread managed by the client. ( not true in any case,depends on the functions called )
- the more i work with lua the more i like it.
- if i need threads to do things in the background without stalling the lua vm i can easily create them from the dll and use lua events to communicate. (like pathfinding)

[Da_Teach]

Well personally I dont use warextdll as I hate lua, doesn't matter as I find it interesting to see what you find I also think it'll be an easy pray if/when mythic/goa decide to build in detection.

I do have my own 'bot' running though (its not really a bot the way people here use a bot, I use mine to help me multi-box better). The multi-boxing is exactly the reason I am so interested in the pathing.

Currently 'my group' is all stuck to 1 of the group members (its easy to switch if, for example, the MA dies). But this means the healers are stuck too, which means their easy pray.

Pathing would allow me to build an AI which would let the healers stand back and avoid enemies. At least thats my next 'project'

But I'm having a serious issue with time, major project at work so working too many hours a week atm. Did look briefly into the nif -> obj converter for you, figured I might be able to hack nifskope for you so it'll allow it to export obj's through command line (shouldnt be 'that' hard).

I'll get the source in a few mins, see if I can get it to compile under windows. In theory it shouldnt be too hard

[Da_Teach]

Proved a little harder then I expected
(my cpp skills are getting rusty)

Anyways I modified the load function of NifSkope to automatically export the obj file and after exporting the obj file it will quit nifskope. Nifskope already allowed to load nif files from command line so I didnt need to modify anything there.

Basically this will allow you to make a batch file (shouldnt be hard ) which execute (my modified) nifskope executable with the nif you want to convert. It will then export the obj file with the same name in the same directory. (e.g. "nifskope test.nif" will export "test.obj")

You can download the modified nifskope here:
http://213.189.19.216/NIFSkope_ExportToOBJ.zip

Have fun with it
(note it might still throw convert-errors)

[HansW]

Great. Thanx alot. i will try it right away.

[Da_Teach]

Btw, I was looking into auto-generated navmesh programs and found this one:
xaitMap

Playing with it atm, looks funny but only imports .wrl files.

[HansW]

Btw, I was looking into auto-generated navmesh programs and found this one:
xaitMap

Playing with it atm, looks funny but only imports .wrl files.

works good, i already tested it using a scenario map ( the one with the vulcan in the middle). But converting a 600mb .obj file to .wrl and then loading it will take ages. Also its not free and i would need to write an importer for it. There are some other programs available, but none is free.
According to Autodesk , Mythic used Kynapse (Autodesk - Autodesk Kynapse) to generate their nav-mesh.
There are allot of different approaches on how to automaticly generate a nav mesh from the level geometry.

[Da_Teach]

Also its not free

Mine was an eval version for a very short time

I cant exactly shy away from hacking a program if I'm already hacking a game

[HansW]

Mine was an eval version for a very short time

I cant exactly shy away from hacking a program if I'm already hacking a game

did you manage to remove the limitations of the free version also ? it's limited to 3000 navnodes.

BTW: can you please remove the warnings from the export code. they are in obj.cpp in the the importex folder. Simply remove all the QMessageBox::warning(..) calls. I cant batch convert with the boxed poping up.

UPDATE: no need for a recompile, i just patched the call out in the .exe. Hope you did not start working on that.

[Da_Teach]

I've uploaded version 2 of my modified nifskope, you can find it here:
http://213.189.19.216/NIFSkope_ExportToOBJ_v2.zip
(its only the exe, you will still need the dll's from the old version)

Also you should have a PM about that other thing.