scripting and scripting related stuff

[BielBdeLuna]

I'm currently adding the path routines to the AI and tried something: in c++ and other languages you can write parts of the methods of a class in another file. This might prove useful in order to have the code well separated in groups of methods or functions that correspond to an area, could this be done in idTechX script? it can be done

as long as in the script-object (idTechX has no objects, but has script-objects which depends on entities) those functions are introduced, you can then extend them in any other file, as long as then the file is included

so you can have:

a ai.script file an then a ai_extra.script file

and in ai.script you can have this:

object super_cool_ai : super_cool_ai_base {

    void super_cool_fucntion();
    void not_so_super_cool_function();

};

void  super_cool_ai::not_so_super_cool_function(){
    // not so super cool code here
}

and in ai_extra you have this:

void  super_cool_ai::super_cool_function(){
    // super cool code here
}

you then in the main.script file add this:

#include ai.script
#include ai_extra.script

idTechX will accept the code, so this means that the engine will keep searching unfound functions until the end of the files and if he doesn't find it then it will error out to desktop with the pertinent message.

this is great to have the AI code not in a single file like how it was in doom3 scripting but have it well separated in different files

it would be great though to have those separated methods be able to be reused whenever it's necessary for the user, but this can only be done in two different occasions:

• it needs to be used in a superclass form the class the user is reclaiming that method, so the method can use variables already initiated by the superclass
• or have those methods be self contained so they can be used anywhere, but then this is more akin to the "subs" (subroutines) than those out of the class defined file methods.

maybe the best practice would be to make an AI that uses the least amount of variables so it's more process intensive but allows for even more flexibility? and maybe use variables just for the most generalist functions so they are initiated in the well above superclass stratification?

[BielBdeLuna]

idTechX c++ code controls the direction of the character with a desired direction and a current direction, this is accessible in the scripts via getTurnDelta().

With this I've implemented a 100 degree turn + a doge turn so we could have characters doing a 180degree-like turn, no monster or npc in Doom3 can walk backwards, to the point that the boolean that connects idAI with every script that this entity uses is called "AI_FORWARD" when in reality it should be called "AI_MOVE" so it makes sense to have a "AI_MOVE_DONE". So I'm using "AI_FORWARD" as if it were "AI_MOVE" to move the character to any direction not only forward.

I've implemented a "legs_stay", "legs_move", and "legs_move_corrector", the first controls the char legs when he is not in a translational movement, the second controls when the character is in a translational movement, and the third controls when the character is turning whether he is in a translational movement or not.

when I consider finished the legs I'll turn my attention to combat routines, and then the enquiry routines (where the character goes to investigate noises) this should be all optional.

I've been uploading my code here: https://github.com/BielBdeLuna/idTechX_GPL_scripts

keep in mind that I haven't tried any of it yet, so it contain massive breaking errors.

[kortemik]

It looks quite the thing I thought it should be like. I tried the same kind of thing, only that I had run animations working nothing else. The upper and lower body animations are split, right? It has only two channels for them afaik, torso and legs.

[BielBdeLuna]

yes, I added a motion channel back in dhewm3 but adding threads might not be the right decision so I didn't pursuit that direction further.

it would be great to have tow threads for the arms, so we could have sword fighting with shields. Anyway we can try it once we have a working AI scripting.

[BielBdeLuna]

finished with the translational movement

now onto combat, and one I finish combat, I'll try to test the code to make it functional so we could have enemies (not yet prepared for the player)

It's interesting how d3 code was done:

idPlayer is a idActor idAi is a idActor

idActor is mostly the motor part of the characters in-game, the animation part, and the ikpart, also almost all the scripting character-related part

so both the player and the NPC were once the same, this lead and the fact the boolean in the code that makes the characters move "AI_FORWARD" (why AI_FORWARD why not the more obvious AI_MOVE), and also the fact that back in Alpha times the states and animations where done in a much different way that it is done now, makes me think that the scripting related functions for player and enemies were worked in the same manner at the same time, and probably where meant to be the same, I bet they cut down the characters capabilities before they released the game, and this left those strange and similar names in this boolean and functions, I bet animations played a key role in this decisions once they started to diverge from player animations, I'm looking at bipped animations, specially the soldier's capacity to dodge different than the player's, also the fact that the characters have a very specific ( almost robot-like routines when it comes to shooting ) or the fact that they have the weapon not separated than the rest of the monster, when the player does, I bet they wanted to make the monsters more "cinematic" in their motions, so they added that pseudo-cover system (I think it wasn't there in the Alpha)

also the fact that some monsters have the heads replaceable, like the player has, but some don't, why they wanted different zombies but then only wanted one single Imp (when they then added different skinned Imps for hell) makes not much sense.

I think once they realised the animations where diverging, and specially the animation needs, either sky rocket, or where too particular to the enemy, I bet they resorted to cut-down the whole scripting system related to enemies making enemies only able to walk forward, and cut down the developer capacity to influence on the direction of the movement of the enemy, or the incapacity to search in the surrounding entities (making a credible cover system impossible) I find all of this pretty interesting.

[BielBdeLuna]

I'm becoming more embroiled with the strategy and node stuff, and since this is lasting too long, I'll just slap a remake of the code of id software there without any node action for the moment and I will start making the code functional. Because I want to test all that code and I want to try some things ( I would like to try to have a different animation thread for every leg in bippeds )

at the same time I'll keep working on the strategy system (at the moment pretty simple strategies) but it should be extensible. I've devised a way to score different situations and with this communicate what strategy the npc has to take. Therefore all this scoring influences other scores and this should make the enemies less robot-like.

[kortemik]

You mean you'd like more channels than just torso and legs?

Once we have the character in I can investigate into that :)

On Thu, Aug 27, 2015 at 12:56 AM, Biel Bestué de Luna < notifications@github.com> wrote:

I'm becoming more embroiled with the strategy and node stuff, and since this is lasting too long, I'll just slap a remake of the code of id software there without any node action for the moment and I will start making the code functional. Because I want to test all that code and I want to try some things ( I would like to try to have a different animation thread for every leg in bippeds )

at the same time I'll keep working on the strategy system (at the moment pretty simple strategies) but it should be extensible. I've devised a way to score different situations and with this communicate what strategy the npc has to take. Therefore all this scoring influences other scores and this should make the enemies less robot-like.

— Reply to this email directly or view it on GitHub https://github.com/OpenTechEngine/Discussions/issues/6#issuecomment-135182309 .

[BielBdeLuna]

yes, I already have coded new loops per monster in Dhewm3, another thing is the blending of animations. it could be cool to have an independent direction for every leg, this should be doable if every leg has it's own blend group.

[BielBdeLuna]

I'm still working on it but the current political movements in my country makes me collaborate on the ongoing politic moment, independence of Catalonia, I'll go back to coding after the 27th of September.

[BielBdeLuna]

I'm done with the scripting of enemies, now I'm proceeding to make it playable in IdTechX:

https://github.com/BielBdeLuna/idTechX_GPL_scripts/tree/untested/script/ai

ATM the code is there but it's not tested in IdTechX, only the actual FSM is untested the rest is working fine in-engine. (at least compiles fine)