Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[2.2]Programmable AI via scripting
#91
Fixed the problems stated above by YinYin.

For those of you who are interested the fault was simply the DLL handling the "itrs"-variable as an array of pointers, while it is a pointer to an array, which should be fixed now (same thing goes for bdys).
On top of that the variables have been renamed to fit their actual purpose. (move_counter, run_counter, weapon_holder, weapon_thrower).
Also another bad typing error was fixed, and you are now able to read more scoreboard data. (total hp lost etc.)
Download: http://www.mediafire.com/folder/pxd026nq...2ddWrapper

Edit: @below: Whoopsies.
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
Trump is an idiot.
Reply
Thanks given by: YinYin
#92
You kind of uploaded the data changer into the wrapper folder too.
Reply
Thanks given by:
#93
(06-05-2013, 03:37 PM)YinYin Wrote:  You kind of uploaded the data changer into the wrapper folder too.
Should be fixed now.
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
Trump is an idiot.
Reply
Thanks given by: YinYin
#94
Did this fix change how itr and bdy are read? - because is now crashes as soon as I try to read the kind of the very first one.

edit: no it crashes upon reading this condition:
//(game.objects[o].unkwn12[0]!=0||
//target.data.frames[target.frame].itrs[i].kind!=4)&&
//(game.objects[game.objects[o].weapon_holder].data.frames[game.objects[game.objects[o].weapon_holder].frame1].wpoint.attacking!=0||
//target.data.frames[target.frame].itrs[i].kind!=5)&&
I think unkwn12 previously was int - now it's char - I use it to read a thrown characters throwinjury (to distinguish him from a normal falling character).

edit: That unkwn12 still works as throwinjury - but the weapon_holder tends to return huge numbers now for characters (that aren't being held via wpoint) instead of 0 - I guess trying to access object number 204800 crashes the game in this case.
edit: If I filter out all the useless cases outside of the object number range it always returns 0.
Reply
Thanks given by:
#95
(06-05-2013, 04:13 PM)YinYin Wrote:  Did this fix change how itr and bdy are read? - because is now crashes as soon as I try to read the kind of the very first one.

edit: no it crashes upon reading this condition:
//(game.objects[o].unkwn12[0]!=0||
//target.data.frames[target.frame].itrs[i].kind!=4)&&
//(game.objects[game.objects[o].weapon_holder].data.frames[game.objects[game.objects[o].weapon_holder].frame1].wpoint.attacking!=0||
//target.data.frames[target.frame].itrs[i].kind!=5)&&
I think unkwn12 previously was int - now it's char - I use it to read a thrown characters throwinjury (to distinguish him from a normal falling character).

edit: That unkwn12 still works as throwinjury - but the weapon_holder tends to return huge numbers now for characters (that aren't being held via wpoint) instead of 0 - I guess trying to access object number 204800 crashes the game in this case.
edit: If I filter out all the useless cases outside of the object number range it always returns 0.
Because of the renaming of the variables unkwn12 is no longer unkwn12 but unkwn9 I believe.
@below: I'll look into it.
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
Trump is an idiot.
Reply
Thanks given by:
#96
No it was 16 before and I changed it to 12 so that's all fine.
The weapon_holder just isn't working.
Reply
Thanks given by:
#97
(06-05-2013, 04:53 PM)YinYin Wrote:  No it was 16 before and I changed it to 12 so that's all fine.
The weapon_holder just isn't working.
OK I forgot about this.
I had messed up the names of the scripting language before which resulted in that.
Try unkwn11.

What happened was that before unkwn13 in the scripting language was actually referring to unwkn12 in the actual files. This carried on from there so unkwn14 is unkwn13 and unkwn16 is unkwn15, which is now unkwn11.
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
Trump is an idiot.
Reply
Thanks given by:
#98
Okay that's confusing now.

I tried every unkwn and none of them return the expected weapon holder number (only tried [0] on the arrays).
Reply
Thanks given by:
#99
(06-05-2013, 05:47 PM)YinYin Wrote:  Okay that's confusing now.

I tried every unkwn and none of them return the expected weapon holder number (only tried [0] on the arrays).
Should work now.
The problem was that it was referencing the wrong variable (unkwn6). Apparently I forgot to change that before.

I also added throwinjury to objects (what was previously unkwn12).
No other stuff has changed. (IE no unkwns with new names)

Download: http://www.mediafire.com/folder/pxd026nq...2ddWrapper
Age ratings for movies and games (and similar) have never been a good idea.
One can learn a lot from reinventing wheels.
An unsound argument is not the same as an invalid one.
volatile in C++ does not mean thread-safe.
Do not make APIs unnecessarily asynchronous.
Make C++ operator > again
Trump is an idiot.
Reply
Thanks given by: YinYin
I have here a patch that adds a previously unknown field in the sObject struct:
Code:
--- sgame.h    2013-06-12 13:18:41.033551073 -0400
+++ my_sgame.h    2013-06-12 13:40:13.569301698 -0400
@@ -213,7 +213,8 @@
     int frame3;
     int frame4;
     char facing;
-    char unkwn3[15];
+    char unkwn3[11];
+    int wait_counter;
     int ccatcher;
     int ctimer;
     int weapon_type;
I haven't actually tested this change. Please tell me if this is not the preferred way to submit patches.
EDIT: Changed name from delay_counter to wait_counter to reflect naming in data files :S
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)