New version of NWNX2 needs Linux port

[Mikel of Avalon]

Just for remember in the new Forums...

[DarkstarsDad]

Several of us are trying to learn how to port. (not well in my case) and plasma john got very swamped at work in the real world. so for now unless one of us figures it out or a new member (thats alot more versed at it) steps up. we are all waiting for it.. Im just using it to learn alot more than i ever thought i would about linux and win 32 apps.

[Erik O'Siodhachain]

[PlasmaJohn]

/me waves

Heh, all I added to the Linux NWNX release was plugin support. The hooking was done by Pap. The person who figured out the SCO/RCO entry points used IDA Pro.

[DarkstarsDad]

oh ok. Did not mean to miss state the facts. but glad to see you around again.
_________________
Just because you think you can't. Is the best reason to try it anyway.

[Yirtne]

UP! I'm waiting for that feature too, and I bet there are many more people waiting as well!
_________________

My scripts never have bugs... at most they'll develop unforseen features.
There are only 10 kinds of people: those who understand binary and those who don't.

[obsidian-studios]

I wish people waiting would try to help. At this point we need to find someone who knows assembler.

I have most of the windows nwnx2 SCO/RCO code ported to linux but I need help with the assembler hooks and etc. I have the nwserver binary on linux converted to assembler via objdump.

So it's a matter of finding the hooks in there, and writing code to use redirect the request to nwnx and then back to nwserver. I am very slowly making progress on this, but learning assembler at the same time is really slowing me down.

I am not very profficient in C/C++, but enough to where I have made a plugin for Firebird RDBMS. My plugin has blob support. So once nwnx2 on linux has the SCO/RCO support I can test out that portion of my plugin. So far all other aspects of my plugin have been working great, stable, and quick.

Please if you know anyone who codes, ask them if they know someone who knows assembler. Offer to buy them a copy of nwn if you have to. I am doing the same

[Papillon]

I am a little tight on spare time right now, and while I will not have enough time to do the actual hooking, I can at least try to give you the locations / byte signature of SCO/RCO. Then someone needs to do the actual hooking, which involves keeping the stack clean and identifying the locations of the parameters on the stack. From my experience, the latter is the easier part.
_________________
Papillon

[redils]

Yes, if u could give us some extra infos, it would be nice ! And, also, some informations about the way objects are stored into memory (Structures of course), but i'd like to have the definition of this structures. My E-mail is redils@netcourrier.com if u have any usefull information. I should have a little more time soon, to work on this features.

[redils]

I'll add, that, if we can cleanly access objets structs, we could had features like SetName(), SetDescription(), and everything we would. I know this features are already been implemented, but are they really stable ?

[obsidian-studios]

The byte sigs and etc would help out a bit. As that should help me find the location in the dumped asm version of the nwserver binary. So that I can modify the hooks I ported and test them out.

Still would like to find someone familiar with asm to look over the code or help out on that part. I have no clue about the nwserver stack, and will most likely run into some major problems.

As far as information on the structures I doubt that is possible the way we are going about this. Which is basically reverse engineering or hacking. None of this would be necessary if we had access to nwserver source code.

However most of what you talk about is different than the functionality of nwnx. You want to add functions to nwscripting which I am not sure is possible. NWNX uses existing functions and looks at the parameters to know if it should interrupt the request or not. By interrupt I mean, respond to the request so the client thinks it was the actual server responding. Also allowing the server to think it accomplished the task when it was handled externally.

So the server has no idea what's going on. In order to implement SetName or SetDescription you would have to make someway to do it outside of nwserver. Which I am not sure if is possible. Or find a way to make to make it work with an existing scripting command and special params so nwnx will deal with it like other requests.

At the moment I think it will be good enough to simply be able to store objects. If you can figure out how to manipulate the actual objects. One could in theory do it outside of nwnx and nwserver and have the changes take place when the object is brought back into the game. With a new name, description or etc.

[redils]

So. I don't know where is the problem about functions i speak about. As you should know, in nwnx, only one function is hook, but there's many wrappers to it (SetPersistentString(), SetPersistentInt(), ...). While porting SCO/RCO, you will have to get the memory adress of the object u want to store, ok ? So, u will access the famous struct, and if u can read it, you also can write into it. All of the processing occurs outside server, but u still access some data from it. Perhaps could i help you. If u want to work in collaboration, just send me a private message, i will send u my msn adress. Concerning the asm hook, it's not really hard to deal with.

[NoMercy]

Once youve got the object data out in GFF form (SCO/RCO save objects out in GFF), it's fairly easy to modify it, there's probably a C library out there somewhere which can do it, though it seems popular to write these things in delphi, java or perl :)

I imagine hooking SCO/RCO are a lot easier than tampering with the object data while it's inside NWN, and also bypasses any danger of not updating object hashes/etc for tag and name changes.

Wish I could help with the effort, but I have proably a even smaller grasp of x86 assembley and the C calling standards.

[obsidian-studios]

I am all up for collaboration, and I invite any to join if even if you have minimal C or asm skills. I am not the greatest at C or C++ but am doing ok so far.

All SetPersistent calls on linux are converted to a string, and they are thay way on windows as well except for the object portion. At the moment from what I have seen by breifly looking at windows code, and I know for fact on linux. The only commands with hooks are Set/GetLocalString, on both, and Store/RetreiveCampaignObject. If you look at the aps_include you will see anything other than a object gets converted to a string.

Same thing in the source code only hooks for those. Which makes sense, no need for hooks for the others unless you really want to get crazy.

Only reason I avoid internally messing with any other calls like SetName, SetDescription is due to all the warnings all over the place in the code about messing with the stack. Thus so far my assumption is the asm hooks to stack redirection to the nwnx C/C++(yes mix of both) code and back to the stack. As to not interrupt the flow of the stack, but to "ignore" portions of it. In crude terms.

Also for the record this is crazy to be doing all this for a game

[redils]

I think that... there's no more money to win with this game, and it really could help the comunity if Bioware could release the server sources... Yes... i dream !