View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005901 | Spring engine | General | public | 2018-02-21 06:35 | 2018-02-21 19:08 |
| Reporter | Google_Frog | Assigned To | Kloot | ||
| Priority | normal | Severity | major | Reproducibility | N/A |
| Status | resolved | Resolution | no change required | ||
| Product Version | 104.0 +git | ||||
| Summary | 0005901: Perfectly replicating engine cloak behaviour is not quick or trivial | ||||
| Description | I feel like I have been assigned an afternoon of work for no reason. Naively it may look like I just need a gadget to check decloak distance against separation and cost in Spring.UseUnitResource. However, many edge cases occur: * Spring.SetUnitCloak can (effectively) change cloak cost and radius. Am I now meant to override Spring.SetUnitCloak with something that sets UnitRulesParams? * I have no guarantee that using Spring.GetUnitSeparation will even result in the same behaviour. * When does a unit count as moving? Figuring this out requires a delve into engine code. The task is demotivating because it is just going to make performance worse. To fully replicate the engine behaviour I expect to by querying unit velocity, separation and a bunch of UnitRulesParams as well as UseUnitResources. To make this replacement trivial (and faster) gadgets need to be sent decloak radius, enemy distance and cloak cost (taking movement and Spring.SetUnitCloak level into account). | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
I think I have all the cases. Does this looks correct? https://github.com/ZeroK-RTS/Zero-K/commit/7aa8e3260b34314e2526b53bb643656d1ce28ba0 |
|
|
Sorry, I mean I found all the cases relevant to the variable costs and radii in ZK. This is not a general gadget. |
|
|
Why would "perfect replication" even be your end goal? Come up with your own more flexible schemes. "To make this replacement trivial (and faster) gadgets need to be sent decloak radius, enemy distance and cloak cost" First two are not needed because the engine will scan for the enemy passed to AllowUnitCloak within a unit's current decloak-distance, so a non-nil value implicitly indicates it should decloak or be blocked from cloaking. Default costs can be accessed via ud.cloakCost and ud.cloakCostMoving respectively. "Am I now meant to override Spring.SetUnitCloak with something that sets UnitRulesParams?" For the cloaking "levels" above zero, you can use any mechanism to remember per-unit state and adjust calls to Spring.UseUnitResource accordingly. "When does a unit count as moving? Figuring this out requires a delve into engine code." Only a very shallow dive: (speed.w * speed.w) > 0.2 |
|
|
Ah, thanks. I thought that the engine would send the closest enemy unit, regardless of whether it is within decloak radius. The event sounds fine upon learning that the event is only triggered if the enemy is within decloak radius. For performance I was worried about an army of cloaked units triggering the event every slow update regardless of whether an enemy is nearby. |
|
|
A correction: I know that the event is called every slow update. I didn't want to constantly do the separation check. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2018-02-21 06:35 | Google_Frog | New Issue | |
| 2018-02-21 08:10 | Google_Frog | Note Added: 0018827 | |
| 2018-02-21 08:10 | Google_Frog | Note Added: 0018828 | |
| 2018-02-21 11:34 | Kloot | Note Added: 0018829 | |
| 2018-02-21 11:36 | Kloot | Note Edited: 0018829 | |
| 2018-02-21 11:46 | Kloot | Note Edited: 0018829 | |
| 2018-02-21 13:51 | Google_Frog | Note Added: 0018831 | |
| 2018-02-21 13:53 | Google_Frog | Note Added: 0018832 | |
| 2018-02-21 19:08 | Kloot | Assigned To | => Kloot |
| 2018-02-21 19:08 | Kloot | Status | new => resolved |
| 2018-02-21 19:08 | Kloot | Resolution | open => no change required |
