View previous topic :: View next topic |
Author |
Message |
Gryphyn
Joined: 20 Jan 2005 Posts: 431
|
Posted: Mon Sep 03, 2007 0:12 Post subject: |
|
|
When I same GameObject I was referring to the object-data, not the string-data which available. In your context, GameObject being the 'string-data', this is still available, it's just been given a new name.
It's also been made semi-safe by providing immutability of the data by using internal memory management to accept a return result.
Sure, there's no reason why BOTH methods could not be available to plugin developers. Papillon made that call when the new NWScript functions became available, he made the justifications then.
If no-one stirs the waters we'd just stagnate.
Cheers
Gryphyn |
|
Back to top |
|
|
virusman
Joined: 30 Jan 2005 Posts: 1020 Location: Russia
|
Posted: Mon Sep 03, 2007 6:45 Post subject: |
|
|
Gryphyn wrote: | When I same GameObject I was referring to the object-data, not the string-data which available. In your context, GameObject being the 'string-data', this is still available, it's just been given a new name.
It's also been made semi-safe by providing immutability of the data by using internal memory management to accept a return result. | I was referring to the in-game object pointer (memory address) that was being passed with SetLocalString function. Not sure what you mean by 'string-data'. |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Tue Sep 04, 2007 21:40 Post subject: |
|
|
The disadvantage of not having the GameObject pointer anymore is a valid point, and it's not the way I want it to be.
At the time I was about to finalize 1.08, nobody was using it (AFAIK) and I was thinking that the NWNXSetObject and NWNXGetObject functions would be available soon - which was not the case. Those functions would offer a much cleaner and powerful interface to manipulating objects, but well - we do not have them.
Currently, I am not sure if those functions will ever make it. I'll ask them again, and I hope I will receive an answer this time (the problem might have been a SPAM filter the last time). If we will not get those functions, we should start thinking about hooking SCORCO again, and maybe other functions that would be appropriate for getting the object pointer.
The thing about the virtual functions was already discussed between us and will be fixed. The point about the prototype not beeing backward compatible to the final version is... uhmm backward . _________________ Papillon |
|
Back to top |
|
|
virusman
Joined: 30 Jan 2005 Posts: 1020 Location: Russia
|
Posted: Wed Sep 05, 2007 1:43 Post subject: |
|
|
NWNX4 Functions and NWNX4 Leto were using the GameObject pointer. NWNX4 Leto requires the old interface as well (I don't know Delphi, so I have to work with what dragonsong gave me).
I doubt that waiting half a year each time for Obsidian to implement 1-2 functions for us is a right thing to do, considering that the same can be done with hooking in 2-3 days. I know that you want to get rid of MadCHook to make NWNX4 x64-compatible, but maybe there is another solution to this? |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Wed Sep 05, 2007 18:54 Post subject: |
|
|
I agree that hooking all other functions expect those OE gave us already, and the (future) object functions, can and should be done without OE by just hooking them. The NWNX* and SCORCO functions are so fundamental, though, that I'd like to have official hooks for them.
This has nothing to do with madcodehook yes or no, though. I can "hook" the functions in 1.08 without madcodehook, but I can not load the NWNX DLL into the server's process space. Well actually I can, but because of some nit-picky problem which I can not quite remember right now, starting the IPC Server does not work once my DLLMain functions executes inside the server process. I guess it is because you are quite limited in what you can do within DLLMain (loader lock and such), and madcodehook probably uses another way to inject the DLL. I am so || close to removing the dependency on madcodehook, and than such a stupid problem gets in the way.. bleh.
_____
Side note: If I see comments like "huh, this is easy, why not just this way or that way"... I can not help but think: Yeah, right, present me a solution. Nothing is holding you back.
Side note 2: Is it just a coincidence that this discussion about 1.08 final takes place in the beta thread ? Since, you know, 1.08 was in beta for quite some time, and comments about it's very core parts would have been somewhat more helpful during that time, but really much less a couple of weeks later. _________________ Papillon |
|
Back to top |
|
|
virusman
Joined: 30 Jan 2005 Posts: 1020 Location: Russia
|
Posted: Thu Sep 06, 2007 0:07 Post subject: |
|
|
Papillon wrote: | If I see comments like "huh, this is easy, why not just this way or that way"... I can not help but think: Yeah, right, present me a solution. Nothing is holding you back. | OK. I'll sort things out with NWNX2 and then try to make a solution for these issues.
Papillon wrote: | Side note 2: Is it just a coincidence that this discussion about 1.08 final takes place in the beta thread ? Since, you know, 1.08 was in beta for quite some time, and comments about it's very core parts would have been somewhat more helpful during that time, but really much less a couple of weeks later. | I haven't been actively developing plugins since 1.08 has been released, so I didn't see the problems at first, until I recently started porting NWNX Functions and Leto from 1.07 to 1.08.
If I was playing NWN2 or haven't been on vacation for 2 months, probably I could notice it earlier. |
|
Back to top |
|
|
Papillon x-man
Joined: 28 Dec 2004 Posts: 1060 Location: Germany
|
Posted: Fri Sep 07, 2007 18:40 Post subject: |
|
|
virusman wrote: | OK. I'll sort things out with NWNX2 and then try to make a solution for these issues.
|
For your info, I have received a positive reply from OE in the meantime (gotta ping those lazy bastards once in a while ). That does not mean I will get exactly what I would like to have, but it's a good sign. So you might want to concentrate on hooking a function that give access to a game object's pointer first, as opposed to hooking the whole SCORCO thingy.
If all goes well, we should get one function that provides a memory pointer to a GFF encoded object, and one that accepts GFF encoded data. _________________ Papillon |
|
Back to top |
|
|
GodBeastX
Joined: 09 Aug 2006 Posts: 65
|
Posted: Fri Sep 07, 2007 21:31 Post subject: |
|
|
Papillon wrote: | virusman wrote: | OK. I'll sort things out with NWNX2 and then try to make a solution for these issues.
|
For your info, I have received a positive reply from OE in the meantime (gotta ping those lazy bastards once in a while ). That does not mean I will get exactly what I would like to have, but it's a good sign. So you might want to concentrate on hooking a function that give access to a game object's pointer first, as opposed to hooking the whole SCORCO thingy.
If all goes well, we should get one function that provides a memory pointer to a GFF encoded object, and one that accepts GFF encoded data. |
That sounds like Hotness. It'd still be good to get Object address too. I see various uses for pulling out backend data scripts otherwise have no access to. Even sticking in data. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|