[Fabian]

Hi,

here we go. Here is a first attempt of modularization of aigoals via a call table. (They could possibly be inlined to make it even faster)

Patch attached.

The old functions at this moment also point into the call table, making some kind of "polymorphism" possible.

The thing is:

I think the current AI code is to difficult to understand and clean up without breaking compatibility somewhere. The only solution to this is to split it up.

As the code has no clean interface at all to the outside I see no other solution than to wrap all functions.

The advantage is that you don't have to copy & paste all code if you just want to add some minimal functionality. (provided the polymorphism I suggested is used)

The disadvantage of the polymorphism is that the current code gets a bit slower as also all internal functions are evaluated through two function calls, which might add up ...

Though I think with inlining this disadvantage could be solved. Also the code is not _that_ efficient from the start on and that should not be a problem on modern computers ...

If you agree with this modularization approach, I'll try to finish it next week end.

ai_profiles imho does not need to be modularized, which leaves aiturret, aibig and aicode to be modularized.

Btw. if you are curious:

- Doxygen now takes 340 MB and a very long time to generate (I needed this for easy overview of which function calls which)
- These functions are defined for extern, but those signed with "-" are never called from external.

-ai_add_dock_name
-ai_add_goal_ship_internal
-ai_add_goal_sub_sexp
-ai_add_goal_wing_internal
 ai_add_ship_goal_player
 ai_add_ship_goal_sexp
 ai_add_wing_goal_player
 ai_add_wing_goal_sexp
 ai_clear_ship_goals
 ai_clear_wing_goals
 ai_copy_mission_wing_goal
 ai_get_subsystem_type
-ai_get_subsystem_type_name
 Ai_goal_text
 ai_maybe_add_form_goal
 ai_mission_goal_complete
-ai_mission_wing_goal_complete
 ai_post_process_mission
-ai_process_mission_orders
 ai_query_goal_valid
 ai_remove_ship_goal
-ai_update_goal_references
-query_referenced_in_ai_goals

- Modularization is heavily scriptable (I love linux ) and such quite efficient work.

cu

Fabian

[attachment deleted by admin]

[Ace Pace]

Sounds good, this might make actual AI modification easier then the current mess it is now.

[Aszarsha]

Haven't read the AI code actually, so i can't comment about it ; but maybe, you should assert against NULL function call.

[Bobboau]

if he's doing this systematically he might as well, this sounds realy neat and could allow us to massively tinker with the AI finaly.

[Goober5000]

Ooh, clever. This should be very helpful.

[jr2]

*Is happy that the coder gods are working on improvements.* 

[vamitul]

good luck. i was trying to do something like that with the networking code, but i just can't get the hang of it.. it's so ... chaotic. anyway.. can't wait too se how it turns up, maybe then i can "steal" from you

[WMCoolmon]

 

How is this going? I'm curious to see how this turns out before I start on Axem's request here. Will any of your plans have anything to do with the way AI handles orders, handles being given orders, the interface used with the AI, etc.

[Fabian]

How is this going? I'm curious to see how this turns out before I start on Axem's request here. Will any of your plans have anything to do with the way AI handles orders, handles being given orders, the interface used with the AI, etc.

First of all: No.

As retail compatibility needs to be preserved it will only give additional ways later on, but I wonder:

Why don't you add a exec-sexp in the scripting code?

That way it could be:

if condition then
-- protect Beta Wing with Alpha wing
exec-sexp("wing-set-goal 'Alpha' (ai-guard 'Beta' 89) ")
endif

My lua got a bit rusty, but I think the idea of dynamic sexps would be quite helpful ...

I even thought of adding them to the debug console myself, so that I can do more than just what debug console allows and cheats allow to test things ...

cu

Fabian

PS: How things are going? No real time on last weekend, but hopefully next one ...

[WMCoolmon]

Running things through the SEXP system is slower and doubles the amount of parse-related bugs that there can be. It's not how I want to start implementing things.

As retail compatibility needs to be preserved it will only give additional ways later on...

Those extra ways are what I'm asking about. Within the codebase, it's not a big deal if you have to completely change a function or even the way that something is done. As long as the external interface to the EXE is the same, nobody outside of the coders has to know or even worry about it.

On the other hand, if I have to change something in scripting later on, that doesn't apply. If I absolutely have to change the behavior of something, it will break existing scripts. If I have to work around it, I'll end up adding bloat. I don't have any idea what additional ways you've been thinking about, so I don't know if I should change my implementation to take those into account.

[Fabian]

On the other hand, if I have to change something in scripting later on, that doesn't apply. If I absolutely have to change the behavior of something, it will break existing scripts. If I have to work around it, I'll end up adding bloat. I don't have any idea what additional ways you've been thinking about, so I don't know if I should change my implementation to take those into account.

First of all: No. The "interface" should remain the same even for a new AI. Then you can additionally add new ways once there is something new in the AI.

I think splitting it up (modularization) and improving the current code within the given interface is the biggest priority for me at the moment though and not directly adding any new ways.

cu

Fabian

[Fabian]

Status update ...

Had some time on the weekend and finished 2 more files. Now only aicode remains to be done and some new table infrastructure be created.

Unfortunately yesterday a big BtRL game took place and I really had to test out that MP functionality ... ;-) ...

That basically killed the time I had assigned to analysing aicode.cpp to check for functions that should be wrapped.

Anyway, status update just for the record ...

cu

Fabian

[attachment deleted by admin]