[GUI] Auto-Train System v1.1

[Moderator]

12th Dec 2015
IcemanBo: Too long as NeedsFix. Rejected.

21:51, 10th Jul 2014
BPower:
https://www.hiveworkshop.com/threads/gui-auto-train-system-v1-1-a.251331/post-2554611

 

[GywGod133]

:v reserve

 

[Kazeon]

well, must be useful for AI system if one structure can auto-train more than 1 unit types

• Set AT_StructuresCount = 6
• Set AT_UnitTrainCount = 6

if they can only auto-train one unit type so those two variable will always has a same value, so better stick them to one variable.

• -------- > Without using rally ability, set the point and when the units trained, automtically attack-move --------

I think rally point is not important, it has not any relation with "auto-train"

• (Unit-type of (Triggering unit)) Equal to (==) AT_Structures[AT_TempLoop1]

store (Triggering unit) into variable first

those are the major things, and....

where is your importing instructions? :v

 

[GywGod133]

well, must be useful for AI system if one structure can auto-train more than 1 unit types

• Set AT_StructuresCount = 6
• Set AT_UnitTrainCount = 6

if they can only auto-train one unit type so those two variable will always has a same value, so better stick them to one variable.

• -------- > Without using rally ability, set the point and when the units trained, automtically attack-move --------

I think rally point is not important, it has not any relation with "auto-train"

• (Unit-type of (Triggering unit)) Equal to (==) AT_Structures[AT_TempLoop1]

store (Triggering unit) into variable first

those are the major things, and....

where is your importing instructions? :v

Well.. i need know to fix xD Thanks for reviewing

 

[IcemanBo]

Hihi... training only 1 unit type, and set each type in config is just much work and actually it's not dynamic enough, I think. (as Dalvengyr mentioned already)

Also what could be useful is working with death_event. If my food limit is reached for example, the training stops.
But I would want my building to continue training if food limit allows is again.

I doubt the periodic trigger is really needed. It doesnt seem very clean this way.

Try to learn about hashtable, it could simplify code... and you would not need loops to check unitType.

In "AT Trained" trigger - following can be outside your very last If/Then/Else:

Unit - Order AT_CopyTrainedUnit[AT_Y] to Attack-Move To AT_2Player[AT_TempLoop2[AT_Y]]

I think this can be very ueful for an auto-train system.

If you read the API, you will see the functionality. You may use things like GetLastTrainId and so you can easily make your buildings be able to train different unit types at once, without any pre-config or loops to check the index.

You also can use these API function via custom script, excample you want get the unitType of last trained unit for your building:

Custom script: local integer i = GetLastTrainId(GetTriggerUnit())

Overall I think an auto-train system can be useful for certain maps, but first you should try to make it more dynamic and as easy as possible.

 

[deathismyfriend]

This would be more efficient using a hashtable. All of the loops to check if unit type of triggering unit is in the system is very slow and costly.
Also checking like this.

• (Unit-type of (Triggering unit)) Equal to AT_Structures[AT_TempLoop1]

only allows for one unit type in the system which really isn't good.

Also anything used twice or more should be stored into a variable and the variable should be used.
Even when looping.
All your triggers should store triggering unit and (Unit-type of (Triggering unit)) before they loop through everything.

 

[BPower]

I can only agree with what is mentioned above by other users.

Basically you have to learn how hashtables work and then re-design your code.

Need Fix

 

[Chaosy]

isn't this very specific though?

 

[GywGod133]

I can only agree with what is mentioned above by other users.

Basically you have to learn how hashtables work and then re-design your code.

Need Fix

okay... I will do this in Hashtable
Thanks for review