Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[2.2]Programmable AI via scripting
#91
The game keeps crashing whenever I access data that does not exist (frame/bdy/itr/etc).
While I do try to put checks all over to prevent that it still does happen and it's pretty difficult finding the error when the game just shuts down.
Could we easily catch that somehow?

edit: object has a member called umkwn1 - seems to be a movement counter (runs from 0 to 17 while walking/running - probably useful to give AI a reasonable reaction time as to when it should change targets).

While I'm at it may as well describe more of the unkwn object members:

2 seems to have a similar function to 1 - except this is for turning. It goes up to 10 when turning right and runs back down to 0 (-10 when turning left). Can give AI a reaction time to not turn around too quick.

6 is the number of the last object an object was held by (via wpoint)

14 is the number of the last object an object was thrown by (via wpoint - light weapons)

13 is the number of the last object an object was dropped by (via cpoint) scrap that - sometimes it's just anything close when the character last dropped (weapons/opponents) - probably helps AI to choose revenge/kill steal/item depending on the conditions it got knocked down

17 seems to be an object number too as it starts out with -1 like the others - but I don't know which yet


edit: I found my problem: if there are several itrs with the same kind in one frame the second one will return kind 0 and the third will crash the game (returning who knows what). (Falling characters for example have two kind 4 itrs, but the second one will read 0. Henrys flute has 3 kind 10 itrs - the second one will read 0, the third will crash the game.)
Reply
Thanks given by:
#92
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
#93
You kind of uploaded the data changer into the wrapper folder too.
Reply
Thanks given by:
#94
(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
#95
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:
#96
(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:
#97
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:
#98
(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:
#99
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:
(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




Users browsing this thread: 1 Guest(s)