Opened 8 years ago
Last modified 5 years ago
#4286 new defect
unlock_sharedlos and unlock_dropsites techs modifications array
| Reported by: | fatherbushido | Owned by: | |
|---|---|---|---|
| Priority: | Should Have | Milestone: | Backlog |
| Component: | Simulation | Keywords: | patch |
| Cc: | mimo | Patch: |
Description (last modified by )
I wonder if we should let the modification array in those 2 techs. Indeed the modifications are not implemented in our code, it's hardcoded (is the tech searched or not). So I find a bit misleading to let that array.
EDIT: in fact, I am perhaps wrong. It's used by the AI for the unlock_sharedlos tech.
Attachments (1)
Change History (6)
by , 8 years ago
| Attachment: | unlock_techs.diff added |
|---|
comment:1 by , 8 years ago
| Cc: | added |
|---|---|
| Description: | modified (diff) |
| Summary: | unlock_sharelos and unlock_dropsites techs modifications array → unlock_sharedlos and unlock_dropsites techs modifications array |
comment:2 by , 8 years ago
comment:3 by , 8 years ago
thanks for your input, it was my first idea too but i wondered if i missed something. now, i know.
comment:4 by , 8 years ago
| Keywords: | patch added; rfc removed |
|---|
comment:5 by , 5 years ago
| Component: | UI & Simulation → Simulation |
|---|
Move tickets to Simulation as UI & Simulation got some sub components.
Note:
See TracTickets
for help on using tickets.
I would rather have the opposite move: try to remove what is currently hardcoded, and use that modification array to apply the effect of such a tech. Having for example the convention that a value "Player/something" means that the property something of the Player component is modified, or whatever more clever way to do it which would remove these hardcodings. Anyway, this array is currently the only way for the AI to know what is the effect of these tech (except once again by hardcoding).