Baldur's Gate : The Sword Coast Chronicles : NWN2 Persistent World

blittable types
p/invoke
decompiler quickstart (ollydbg)

Batch doesn't support these mechanisms (that I'm presently aware of), but the p/invoke should help you along under the .NET CLR.

Err....

Aspect of Sorrow wrote: NWN2 has the scaling mechanism that I'd suggest enumerating clientside rather than appearance fiddling. Write a script that loops, adjusting the player scale. Load the game into the module containing that script and start a debugger like olydbg. Look for patterns of data in memory flipped, find their position and the context wrapping it. If you find a pattern that can be easily identified after every client reset via olydbg, create an application that determines the process name, call kernel32.dll, search and marshal the area to enumerate, read it's current state, set scale x,y,z to 0.001.

That's bad idea. I see what you're trying to do here, but it won't work well.

Kernel32.dll will not have any code related to camera position.
Because kernel32 handles creation of processes, opening of files and such. Camera-related stuff will not happen there. You can hook kernel32 dll, of course, but you'll gain nothing by doing that.

Camera-related code will be happening in the game exe or game-specific dll, and you will not be able to pinpoint it easily, because it'll be statically linked and object oriented.

However.

ClientExtender already messes with camera settings by extending camera range, and can adjust its zoom range.

So instead of wasting time looking for stuff (that isn't there) in kernel32, fork ClientExtender and see if there's a portion of it that deals with camera directly. Because client extender already provides standalone client, and can mess with client player position via /mpredict, it is possible that this can be done.

Pinpointing player scale will also take forever, because you don't know how it is stored, and whether a scale even stored anywhee, because it is entirely possible (and adviseable) to write a program that operates on player scale, but does not store the value itself.

And in the end, it is almost guaranteed that player scale - even if it is stored in the program, will be never stored at the same memory location.

----

Short version: Don't bother with ollydbg, try to modify clientextender instead. It has source code available, somewhere.

A bit off topic but did anyone complete that Drizzt challenge so you could unlock him as a playable character? I remember spending hours trying to finish that dungeon in the allotted time and when I finally did it I was so happy . I never did wind up doing a play through with Drizzt though, he seemed rather weak.

NegInfinity wrote:Err....
That's bad idea. I see what you're trying to do here, but it won't work well.
Kernel32.dll will not have any code related to camera position.
Because kernel32 handles creation of processes, opening of files and such. Camera-related stuff will not happen there. You can hook kernel32 dll, of course, but you'll gain nothing by doing that.

The kernel32 call is solely to simplify determining the process to hook, once accomplished you can manipulate the camera on the loaded process. (Irrespective of where the file is stored, where the game files are stored, what have you).

NegInfinity wrote: Camera-related code will be happening in the game exe or game-specific dll, and you will not be able to pinpoint it easily, because it'll be statically linked and object oriented.

iirc, the camera is close to one of OEI's symbols.

NegInfinity wrote: Pinpointing player scale will also take forever, because you don't know how it is stored, and whether a scale even stored anywhee, because it is entirely possible (and adviseable) to write a program that operates on player scale, but does not store the value itself.

It's visible with every object rendered in the scene. Players and placeables alike. It doesn't become apparent for objects outside of that (I don't know when the transition happens, onclient enter event for another PC or if it's within the player's drawing range)

NegInfinity wrote: And in the end, it is almost guaranteed that player scale - even if it is stored in the program, will be never stored at the same memory location.

Hence the suggestion of looking for the pattern therein. On a cursory glance, I searched for my character name. Parsing that block is cursory and repeatable.

Aspect of Sorrow wrote:Hence the suggestion of looking for the pattern therein. On a cursory glance, I searched for my character name.

Sigh.

Just fork client extender. It already does half of the job and modifies camera parameters.

Searching for patterns will be a waste of time, because every time you start exe, you'll get different memory location for object scales (because dynamic memory allocation), and if you pinpoint a "pattern" in code where scale is used, then you can mess it up for everything (because object oriented programming).

NegInfinity wrote:Searching for patterns will be a waste of time, because every time you start exe, you'll get different memory location for object scales (because dynamic memory allocation), and if you pinpoint a "pattern" in code where scale is used, then you can mess it up for everything (because object oriented programming).

Hence the point of creating a program that handles this for you.

Forking Ken's work isn't going to help him understand why it was written the way it was.

Aspect of Sorrow wrote: Forking Ken's work isn't going to help him understand why it was written the way it was.

He does not need that.

----

Either way this is not a place where I would want to discuss anything programming-related.

Have a nice day.

NegInfinity wrote:He does not need that.

If he's willing to work on this, maybe a few additional contributions can come to light as a part of his endeavor to the benefit of players who want it. What's wrong with that?

Aspect of Sorrow wrote:

NegInfinity wrote:He does not need that.

If he's willing to work on this, maybe a few additional contributions can come to light as a part of his endeavor to the benefit of players who want it. What's wrong with that?

Alright, since you asked.

The wrong thing is needlessly wasting a lot of time.

The point of programming is getting things done. Ideal solution is the one where you solve a problem in 30 seconds while writing nothing.

In no even while programming should any problem be solved twice. If solution exists, you use it and build on top of it. So, when someone already did half the job, you need to grab existing solution and build on top of that. Which is in this case a client extender.

Trying to disassemble nwn2 or search for code patterns, is a waste of time, because for someone who wans to "learn" it is simply a bad training exercise, due to the size or complexity of the code (you need to have few years of experience with C++ to know what to look for).
For someone who's experienced, it is also a waste of time, because it is a tedious error-prone process. "Camera" is a not an easily pinpointable state/call pattern like rendering a mesh, setting a texture, etc (which can be solved by hooking a dll or writing a proxy).

The right thing to do in this kind of situation when someone wants "first person fix", is to grab existing work and reuse. Doing things via ollydbg will only waste up to 6 months of person's time while most likely ultimately producing no result. Forking extender will take less time, because someone already did most of the job reversing most of the formats and protocols used by the nwn2. There's no reason to redo things by yourself.

Either way....

I REALLY don't want to discuss this further. Have a nice day.

I remember one back in the past that that the wizard Rasael made a spell in the game that could make you completely invisible so it was like first person view

it was call shadow door and you where completely invisible not like the invisiblets spell where you could see you self but other can not but think of this if it was other away around then you couldt see you self but other could, you will all most have it in first person view but not in the combat mode only for RP face to face you will not see you back but others face and eyes mouth couse you back head will not be there and the bodie and that one could be made as like a feat so you could swift on and off if you wish to be in "first person view"