Jump to content

Recommended Posts

Not to put more on you' date=' but another idea - a way to check if refs in a certain radius of the player have a follow package with the player as a target.

 

Combined with a gender check, female non-vanilla companions could be picked up by things like the Tryout scanner.

[/quote']

 

I don't know if I have access to that kind of high level stuff (range to target). I can probably walk some tree and then calculate distance by hand but I'm not sure.

 

http://geck.bethsoft.com/index.php/GetDistance

 

 

 

*smack*

 

Pay attention. :P

Link to comment

Not to put more on you' date=' but another idea - a way to check if refs in a certain radius of the player have a follow package with the player as a target.

 

Combined with a gender check, female non-vanilla companions could be picked up by things like the Tryout scanner.

[/quote']

 

I don't know if I have access to that kind of high level stuff (range to target). I can probably walk some tree and then calculate distance by hand but I'm not sure.

 

http://geck.bethsoft.com/index.php/GetDistance

 

 

 

*smack*

 

Pay attention. :P

This should be scriptable already:

Do a scan loop, filter with (GetPackageTarget == playerRef).

 

As far as I kwow people following the player will keep him/her as GetPackageTarget even if they are running an interrupt package like conversation of combat.

 

 

Link to comment

 

I don't know if I have access to that kind of high level stuff (range to target). I can probably walk some tree and then calculate distance by hand but I'm not sure.

 

http://geck.bethsoft.com/index.php/GetDistance

 

 

 

*smack*

 

Pay attention. :P

This should be scriptable already:

Do a scan loop' date=' filter with (GetPackageTarget == playerRef).

 

As far as I kwow people following the player will keep him/her as GetPackageTarget even if they are running an interrupt package like conversation of combat.

 

 

[/quote']

 

Scan loops only work on the current cell which can be really large, or really small, it's almost impossible to tell in a script. If there is a target 0.1 "units" outside the cell then the scanner won't find them, even if the GetDistance between the two is within the range being searched.

 

My "smack" was for sen4mi suggesting I call a bethscript command (getdistance) from inside the C code of the Extender -- such a thing is unpossible without 900 years of work. Entrypoints to existing script commands are generally not exposed via NVSE, since the whole point of NVSE is to expose functionality that is not already exposed.

Link to comment

 

I don't know if I have access to that kind of high level stuff (range to target). I can probably walk some tree and then calculate distance by hand but I'm not sure.

 

http://geck.bethsoft.com/index.php/GetDistance

 

 

 

*smack*

 

Pay attention. :P

This should be scriptable already:

Do a scan loop' date=' filter with (GetPackageTarget == playerRef).

 

As far as I kwow people following the player will keep him/her as GetPackageTarget even if they are running an interrupt package like conversation of combat.

 

 

[/quote']

 

Scan loops only work on the current cell which can be really large, or really small, it's almost impossible to tell in a script. If there is a target 0.1 "units" outside the cell then the scanner won't find them, even if the GetDistance between the two is within the range being searched.

 

My "smack" was for sen4mi suggesting I call a bethscript command (getdistance) from inside the C code of the Extender -- such a thing is unpossible without 900 years of work. Entrypoints to existing script commands are generally not exposed via NVSE, since the whole point of NVSE is to expose functionality that is not already exposed.

 

You can specify a "width" or rather a radius for scan. 2 should be enough to enclose all followers. Its good also not to miss the person you are talking ti if that person ends up in the next cell.

 

As for calling other functions from a plugin, its "doable" if you limit yourself to a specific version of nvse. Not very portable I agree. One more plugin functionality that would be easy to port from OBSE and would be greatly apreciated (CommandTable interface).

Link to comment

You can specify a "width" or rather a radius for scan. 2 should be enough to enclose all followers. Its good also not to miss the person you are talking ti if that person ends up in the next cell.

 

That's true' date=' but without knowing the cell size, you'll run into situations where one extreme or the other has hampered you. If you find a spot you need to use it where the range encompasses 3 cells, things are really going to go down if you keep scanning 3 cells when in an open wilderness area. You could set the scan cell depth based on the cell you're in, if you've pre-checked all of the ones that are important to you I suppose. This will work in controlled environments like buildings, city areas, etc., but will have to fall back to a 'best guess' in the wild.

 

I think the feature loogie asked for in the extender would work best, even if I have to walk the entire ref tree and calculate the distances myself every time. I'm pretty sure I can walk every loaded ref in a 100 cell range faster than a game script can complete even a 2-cell-wide scan. I just need to make sure I can "see" that stuff easily, and ensure that my distance calculation is the same as the one the game uses; I'm sure it's straight geometry but it won't hurt to check.

 

Another advantage is given a list, I can just run the scan and put the results right into the list, so there would be no need for the getfirst/getnext type of stuff. Just one call, then loop through the list.

 

As for calling other functions from a plugin, its "doable" if you limit yourself to a specific version of nvse. Not very portable I agree. One more plugin functionality that would be easy to port from OBSE and would be greatly apreciated (CommandTable interface).

 

Well not just that, I'd also have to *find* the entry point, and then figure out the proper calling convention -- which is the bigger hurdle by far, it's basically doing exactly what silverlock has done to find all the other entry points. Searching the entire NVSE source tree for getdistance returns nothing, because the team had no need to find that function themselves, as it's already exposed to scripters and really adds "nothing" to nvse.

 

Searching on just distance returns a few results, but none of them are useful.

 

What is there is the code for getfirstref/getnextref which will show me how to walk the ref tree, so I can do that myself on as many cells as I want to at a time, after I've benchmarked it to make sure it's quick enough.

Link to comment

You can specify a "width" or rather a radius for scan. 2 should be enough to enclose all followers. Its good also not to miss the person you are talking ti if that person ends up in the next cell.

 

That's true' date=' but without knowing the cell size, you'll run into situations where one extreme or the other has hampered you. If you find a spot you need to use it where the range encompasses 3 cells, things are really going to go down if you keep scanning 3 cells when in an open wilderness area. You could set the scan cell depth based on the cell you're in, if you've pre-checked all of the ones that are important to you I suppose. This will work in controlled environments like buildings, city areas, etc., but will have to fall back to a 'best guess' in the wild.

 

I think the feature loogie asked for in the extender would work best, even if I have to walk the entire ref tree and calculate the distances myself every time. I'm pretty sure I can walk every loaded ref in a 100 cell range faster than a game script can complete even a 2-cell-wide scan. I just need to make sure I can "see" that stuff easily, and ensure that my distance calculation is the same as the one the game uses; I'm sure it's straight geometry but it won't hurt to check.

 

Another advantage is given a list, I can just run the scan and put the results right into the list, so there would be no need for the getfirst/getnext type of stuff. Just one call, then loop through the list.

 

As for calling other functions from a plugin, its "doable" if you limit yourself to a specific version of nvse. Not very portable I agree. One more plugin functionality that would be easy to port from OBSE and would be greatly apreciated (CommandTable interface).

 

Well not just that, I'd also have to *find* the entry point, and then figure out the proper calling convention -- which is the bigger hurdle by far, it's basically doing exactly what silverlock has done to find all the other entry points. Searching the entire NVSE source tree for getdistance returns nothing, because the team had no need to find that function themselves, as it's already exposed to scripters and really adds "nothing" to nvse.

 

Searching on just distance returns a few results, but none of them are useful.

 

What is there is the code for getfirstref/getnextref which will show me how to walk the ref tree, so I can do that myself on as many cells as I want to at a time, after I've benchmarked it to make sure it's quick enough.

 

The commandtable interface in OBSE let's you query the active command table for the CommandInfo by name. Then you can call the pointer to the _execute function for that command. For parameters, just reuse/duplicate the ones used to call your own function, subtituting the searched ref for your "thisobj" parameter.

 

As for cell size, as far as I know, all exterior cell have the same size. And interiors are limited to 1 cell. So scanning the current cell and the adjacent ones should satisfy Loogie's original request.

Link to comment

The commandtable interface in OBSE let's you query the active command table for the CommandInfo by name. Then you can call the pointer to the _execute function for that command. For parameters' date=' just reuse/duplicate the ones used to call your own function, subtituting the searched ref for your "thisobj" parameter.

[/quote']

 

Yeah, I understand, It's just one more thing OBSE has that NVSE doesn't.

 

As for cell size, as far as I know, all exterior cell have the same size. And interiors are limited to 1 cell.

 

Are you sure? I haven't looked at this in a while, but I thought I remembered 'high traffic' or 'dense' exterior cells being a different size, like the cells comprising cottonwood cove and goodsprings.

 

It could have just been an issue with a central location I was having problems with being right on the edge of two cells or something though. The wiki does say they are all the same size (not that I always believe it!) but the size is pretty small: 192x192 (feet). That also results in there being 21 units per foot, making each foot a little under half an inch, which does sound right; my assumption when I was doing a lot of distance stuff was that 1 unit = 1 cm but that's not the case, though it's close.

Link to comment

My "smack" was for sen4mi suggesting I call a bethscript command (getdistance) from inside the C code of the Extender -- such a thing is unpossible without 900 years of work. Entrypoints to existing script commands are generally not exposed via NVSE' date=' since the whole point of NVSE is to expose functionality that is not already exposed.

[/quote']

 

Unfortunately, I have no idea what is and is not currently possible there, until you tell me.

 

But you should be able to achieve the same end without calling the command?

 

sqrt((ref0->x - ref1->x)^2 + (ref0->y - ref1->y)^2+(ref0->z - ref1->z)^2)

 

The x, y and z position of the object are critical information needed by the render engine and by the scripting engine, so if you can get the right reference you should be able to extract these values.

 

However, finding these values from the inside might be a tedious exercise?

Link to comment

My "smack" was for sen4mi suggesting I call a bethscript command (getdistance) from inside the C code of the Extender -- such a thing is unpossible without 900 years of work. Entrypoints to existing script commands are generally not exposed via NVSE' date=' since the whole point of NVSE is to expose functionality that is not already exposed.

[/quote']

 

Unfortunately, I have no idea what is and is not currently possible there, until you tell me.

 

Fair enough. I thought it was pretty obvious that I can't call gamebryo script commands from a c++ program. Silverlock created a workaround for OBSE but it's not in NVSE.

 

But you should be able to achieve the same end without calling the command?

Yes. I just need to test the existing getdistance function and see if it's using the plane formula, the Euclidean plane formula, the geodesic forumla, or something else. The first two are the ones that really matter; I doubt the geodesic is being used since it's so complicated.

 

 

Link to comment

From my experiments with my slave collar in NCRCF' date=' getdistance does not take height into account. I'm basing this off the fact the collar doesn't blow if you climb a guard tower, when if you go past the fence... boom.

[/quote']

 

Ah so probably normal plane formula then. That's easier.. if lamer. Is that how you'd want this to work? Maybe I need an NX_GetDistance as well that can do either 2D or 3D.

Link to comment
  • 4 weeks later...

Not to be a necromancer or anything, but I've noticed since installing this to use Sexout, every time I load up the game I get the MSVCR100.dll is missing error. It's not preventing me from using the game or using the Sexout plugin functions so far, but it is getting annoying, especially since putting the so-called missing file in with the FalloutNV.exe hasn't helped. Do I just have to live with this or is there a fix in this thread that I missed?

Link to comment

MSVCR100.dll is a part of Microsoft Visual C++ Runtime. Try reinstalling that from from the Microsoft site. If that doesn't work you can manually place the file into the directories C:\Windows\System32 and C:\Windows\SysWOW64 (second one only on 64 bit systems) and reboot your computer.

Link to comment

The problem now seems to be coming and going. Sometimes it doesn't give me the error when starting, sometimes it does.

 

Attempting that last instruction resulted in this error:

 

"The module "msvcr100.dll" was loaded but the entry-point DllRegisterServer was not found.

 

Make sure that "msvcr100.dll" is a valid DLL or OCX file and then try again."

Link to comment
  • 4 weeks later...

I just saw these questions here.. are you sure you're using V5?

 

This problem existed in.. V1 and maybe V2, I forget, but was due to me not statically linking when I built the DLL. I changed that, so there is no reliance on external DLLs in the extender now -- the dll is 'included' within the extender dll.

 

Unfortunately it's a very tedious process for me to test this myself to make sure it's actually fixed -- I have all those files installed obviously, and the only way for me to remove them is to uninstall visual studio.. then reinstall to try to fix.. then uninstall to test.. etc.

 

That or install new vegas inside a virtual machine, which would run like crap if it worked at all.

 

I have doublechecked with a dependency checker, and it says the only imports the extender makes are from kernel32.dll, which is normal. Since you say it "comes and goes" I suspect it's something else gone awry with your system and has nothing to do with this plugin.

Link to comment

I don't have visual studio' date=' and I've never encountered this problem. (Not even entirely sure what visual studio is, but thats not the point). Sounds local to me.

[/quote']

 

VS is how you write code on windows, generally. There are other options, but other than Delphi, they all suck. VS is the standard, as the express versions are free. IDE (integrated development environment) for C, C++, C#, VB, and J#.

 

Installing and uninstalling takes an hour or so, then you get to go through all the configuring business. It's one of those things that once you install, you don't ever remove without a really good reason.

Link to comment

the express versions are dummed down a lot and kinda limited to my thinking... you can sometimes find deals (student, employee, etc.) for them, you do have to spend a bit of time looking for em.

 

the express ones are ok for small projects i guess... also, try to avoid opening anything but your current project otherwise you might end up messing with another program by accident(not sure how much the express suites can do though).

Link to comment

I am not a fan of them either, but it's a work related expense, so I shelled out for pro. Most of the OSS projects out there are built with express though. It would be cool if they'd move to clang or gcc or something though, just to avoid project-file hell. Between visual studio and MAX I go pretty crazy fighting with software versioning.

Link to comment

May i ask what System you are using? I have CTDs with Windows Ultimate 64bit.

 

I found that there are two different versions of the C++ Redristibutable x86 and x64. Just installed the x64 version buit did not helb.

 

Best Regards,

Winston

Link to comment

The DLL is 32bit. It's built on my machine, Win7 Pro x64, with VS2010 Pro. You don't need any redistributable installed beyond what you need for NVSE itself, if any. If you're CTDing it's probably something else unless the crash log specifically says it's in the extender DLL.

Link to comment

For the ease of use it might be a good idea to make the install archive contain the proper folder structure "Data/nvse/plugins/". That way the end users can just give the zip file straight to FOMM or NMM.

 

Not that it's a big chore to do it oneself, but it's one of those tiny things that can go wrong when trying to install Sexout and all the related mods.

Link to comment
Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • 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. For more information, see our Privacy Policy & Terms of Use