View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006138 | Spring engine | General | public | 2019-02-20 04:49 | 2019-02-20 14:55 |
| Reporter | Google_Frog | Assigned To | hokomoko | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 104.0 +git | ||||
| Summary | 0006138: MAX_UNITDEF_EXPGEN_IDS is too low | ||||
| Description | This commit enforced a limit of eight cegs per unit: https://github.com/spring/spring/commit/518a265e406b65bb8ff1acca11c21cf325bdbaad This breaks the weapon switching used in the ZK dynamic commander system. Dynamic commanders currently have up to 69 assigned cegs (about double the maximum number of weapons, which is 32). See https://github.com/ZeroK-RTS/Zero-K/issues/3424 | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
I am a bit unclear on why the sfxtypes table exists. Does it improve performance at all (say through resource preloading)? Do large sfxtypes tables have a noticeable impact on performance? It seems like the table could be replaced (for LUS) with a form of Spring.SpawnCEG that takes a unitID, piece number, and ceg name. |
|
|
Fixed in https://github.com/spring/spring/commit/01936433215676150b72cce35101cbbb3aa6bf15 |
|
|
> a form of Spring.SpawnCEG that takes a unitID, piece number, and ceg name. aka Spring.SpawnSFX |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-02-20 04:49 | Google_Frog | New Issue | |
| 2019-02-20 04:57 | Google_Frog | Note Added: 0019738 | |
| 2019-02-20 14:43 | hokomoko | Note Added: 0019744 | |
| 2019-02-20 14:43 | hokomoko | Assigned To | => hokomoko |
| 2019-02-20 14:43 | hokomoko | Status | new => resolved |
| 2019-02-20 14:43 | hokomoko | Resolution | open => fixed |
| 2019-02-20 14:55 | Kloot | Note Added: 0019747 |
