View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001581 | FSSCP | FRED | public | 2008-01-18 22:25 | 2008-12-01 22:36 |
| Reporter | Tolwyn | Assigned To | karajorma | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.6.10 | ||||
| Summary | 0001581: key-reset & key-reset-multiple are broken | ||||
| Description | In the latest CVS builds both sexp are not working. Here is my sexp every-time true reset-key <key> | ||||
| Tags | No tags attached. | ||||
|
|
Which key? Key-reset is horribly picky about the keys used. You will get different results depending on the key you pick. 1, Z and T all react differently to use of the SEXP. What matters is whether you are using them in repeating events or not. |
|
|
would you like to give us more information or provide a sample mission? |
|
|
lets say I write an event like this: everytime keypressed TAB resetkey TAB or something like this. That should deactivate the afterburner, but doesn't. We noticed this when we tried to deactivate the afterburner like this before the next SEXP was done. It didn't work. |
|
|
That's not broken. Key-Pressed/Key-Reset don't work like that. They're training SEXPs that check if a key has be pressed at any time since the last reset. They won't eat the key-press or stop it from doing any of the lower level functions it's meant to do in the code. |
|
|
not a bug then? |
|
|
Don't think so. I'm just waiting to hear back from WCS to see if I've understood what KeldorKatarn incorrectly but the behavior he describes isn't a bug. |
|
|
If this is so, then we really missunderstood what the SEXPs are supposed to do. In that case this can be closed. However, a final question. How difficult would it be to create such a SEXP (one that REALLY eats up certain keys/key-combinations) |
|
|
Hmmm. It might be possible. it might even be easy actually. I'm going to assign this one to me and look into it once the code freeze is over. |
|
|
No priority. A SEXP we could definately use is one to lock all user input without giving control to the AI. We'd like to use this one in cutscenes. But since we either lock ALL keys or none at all, locking single keys is no priority. locking all input would be cool though, even though no must have. |
|
|
Okay, added this one to my to-do list. No need to have it cluttering up my assigned bugs page. :D |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-01-18 22:25 | Tolwyn | New Issue | |
| 2008-01-19 02:31 | karajorma | Note Added: 0008825 | |
| 2008-01-19 02:31 | karajorma | Note Edited: 0008825 | |
| 2008-07-25 17:45 | phreak | Note Added: 0009503 | |
| 2008-09-15 05:47 | KeldorKatarn | Note Added: 0009680 | |
| 2008-09-15 07:02 | karajorma | Note Added: 0009681 | |
| 2008-09-15 22:03 | phreak | Note Added: 0009682 | |
| 2008-09-16 06:03 | karajorma | Note Added: 0009684 | |
| 2008-09-17 00:20 | KeldorKatarn | Note Added: 0009686 | |
| 2008-09-21 21:03 | karajorma | Note Added: 0009702 | |
| 2008-09-21 21:03 | karajorma | Status | new => assigned |
| 2008-09-21 21:03 | karajorma | Assigned To | => karajorma |
| 2008-09-21 21:04 | karajorma | Severity | minor => feature |
| 2008-09-21 21:04 | karajorma | Status | assigned => acknowledged |
| 2008-09-21 22:49 | KeldorKatarn | Note Added: 0009703 | |
| 2008-12-01 22:36 | karajorma | Status | acknowledged => resolved |
| 2008-12-01 22:36 | karajorma | Fixed in Version | => 3.6.10 |
| 2008-12-01 22:36 | karajorma | Resolution | open => fixed |
| 2008-12-01 22:36 | karajorma | Note Added: 0010315 |
