View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004109 | Spring engine | Lua | public | 2013-11-03 14:25 | 2013-11-03 20:55 |
| Reporter | Google_Frog | Assigned To | Kloot | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 94.1.1+git | ||||
| Summary | 0004109: 94.1.1-1465 SetFeatureBlocking isProjectileCollidable does not affect targeting or BeamLaser | ||||
| Description | If isProjectileCollidable is set to false for a feature then all units should ignore the feature when targeting. Currently they do not, it seems that isRaySegmentCollidable determines whether they target with the feature in mind. Additionally isProjectileCollidable does not affect whether BeamLasers collide with the feature. This behaviour is not useful because isRaySegmentCollidable controls whether the feature is mouseoverable. | ||||
| Tags | No tags attached. | ||||
| Checked infolog.txt for Errors | |||||
|
|
"If isProjectileCollidable is set to false for a feature then all units should ignore the feature when targeting." Wrong assumption. "Additionally isProjectileCollidable does not affect whether BeamLasers collide with the feature." BeamLasers are *rays*. |
|
|
It is not an assumption, I am saying how the engine should work. Currently SetFeatureBlocking seems to partition its options by how related the behaviour is within the engine. This makes no sense, things related within the engine are not necessarily related in game mechanics. From a game mechanics point of view BeamLasers are weapons just like projectiles so they should be grouped in the same option. It makes no sense to allow projectiles to pass through a wreck without taking this feature into account when aiming. I know that aiming, BeamLasers and mouse-raytraces are all rays. This is irrelevant. They are very different things in a game so we need to be able to control them independently. From a previous ticket: I only want to use SetFeatureBlocking to implement the behaviour of features with blocking=false as it was in 91.0. I want these features to not collide with or block units or weapons but they should be hit by mouse-raytraces for the purpose of tooltips and reclaim commands. If this cannot be done then the engine has gone backwards. So, given the current signature how do I do this? |
|
|
"It is not an assumption, I am saying how the engine should work." And I am saying how it currently works *and how* the engine has previously worked because the extended options are only a generalization of what was possible before. The fact that the options as they are implemented in the engine don't fit your ideas of how things "should" work is not exactly my concern. "SetFeatureBlocking seems to partition its options by how related the behaviour is within the engine." OF COURSE IT DOES, JFC... the engine knows NOTHING about game mechanics and isn't going to make any assumptions to partition them in other ways that *some* game developer *somewhere* might prefer. "So, given the current signature how do I do this?" Figure it out please... |
|
|
Any hints? I have tried every combination of values in SetFeatureBlocking, none of them produce the desired behaviour. I only care because functionality has been lost. Tell me how to replicate the old behaviour in your generalization. I don't care if your add extra partitions. It is nice to be able to control things more finely. I just care if you have destroyed partitions which used to exist. |
|
|
I haven't and the constant insinuations are a bit too tiresome to make me want to spell it out for you. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2013-11-03 14:25 | Google_Frog | New Issue | |
| 2013-11-03 14:30 | Kloot | Note Added: 0011937 | |
| 2013-11-03 14:36 | Kloot | Note Edited: 0011937 | |
| 2013-11-03 17:36 | Google_Frog | Note Added: 0011943 | |
| 2013-11-03 18:37 | Kloot | Note Added: 0011944 | |
| 2013-11-03 18:38 | Kloot | Note Edited: 0011944 | |
| 2013-11-03 19:09 | Google_Frog | Note Added: 0011945 | |
| 2013-11-03 19:34 | Kloot | Note Added: 0011946 | |
| 2013-11-03 20:55 | Kloot | Status | new => closed |
| 2013-11-03 20:55 | Kloot | Assigned To | => Kloot |
| 2013-11-03 20:55 | Kloot | Resolution | open => no change required |
