View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002115 | FSSCP | FRED | public | 2010-02-07 11:00 | 2012-12-22 21:35 |
| Reporter | FUBAR-BDHR | Assigned To | Valathil | ||
| Priority | normal | Severity | minor | Reproducibility | random |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.6.11 | ||||
| Summary | 0002115: Sexps dealing with rotating subsystems returning errors for valid subsytems | ||||
| Description | Added rotating subobject to a model last week and to another model today. FRED kept giving me <invald> when I tried to use the free and set rotation time sexps. Kept playing with it restarting FRED each time. Finally it let me do it and all worked well in game. I then went back to try to find out why the one from last week wasn't working thinking I just tweaked something that broke it. Nothing worked. Tried the ship that worked a little while ago (no changes at all made to that ship or table) and the sexps didn't allow it either. Loaded mission I had just ran. Bunch of warnings for invalid subsystem name on the rotating subsystem. Tried running it and it works fine in game. Notepaded in the ship from last week and it also works in game. | ||||
| Additional Information | 3.6.11 r5872. Both mission were originally done in FRED so it does apparently work sometimes. Will try to get a retail test mission tomorrow. | ||||
| Tags | No tags attached. | ||||
|
|
Are you using no-rotate on a subsystem here? As far as I can see you can only define something to be a subsystem or to have no_rotate. It doesn't appear that you can do both. Look at Modelread.cpp 1292 |
|
|
Yes I am and V even did both on the Gany so it should be legal no matter what the code currently says. |
|
|
Hmmmmm, I think we all decided this one was more Wanderer's field than mine so I'm going to boot it over to him. |
|
|
Hmm.. so the FRED made the rotation related sexps invalid. I no real idea what it actually is checking (nor when or how). But i'll take a look at it |
|
|
I cant really make heads or tails about this one... Its quite clearly a fred / sexp issue. Unless any one else has anything to comment? |
|
|
I just tried this on a Faustus using retail FRED data and it worked just fine. What ship are you testing? |
|
|
Faustus doesn't have the $special=norotate property. I'll have to see if I can find or modify a retail pof with the same type of setup. |
|
2010-06-17 05:38
|
|
|
|
Attached a modified Orion with RadarDish01 changed to Dish01 (apparently $special=no_rotate doesn't work on radar subsystems) and given $special=no_rotate. Also included ships.tbl (tbm threw errors due to the renaming of the subsystem and it still being in the tbl) with the subsystem changed there and a test mission. Just look at the radar dish right in front of you at start. It should start rotating at 11 seconds and does in my testing. However FRED says this subsystem is illegal for the rotation operations. |
|
|
This is still an issue on build 9414. |
|
|
Ok i looked into the problem: First having both $special=subsystem and $special=no_rotate is not legal. The one that was first declared will be the one parsed. If you would set no_rotate no subsystem would be created -> no way to sexp it. Secondly the FRED warning is IMHO the right way. The game has no way right now to determine if a given subject is CAPABLE of rotating therefore it checks a flag that is only set if the subsystem IS rotating which can only be done by declaring $rotating=n which you didn't -> expected behavior. There is a check for FRED in the sexp validation code that explicitly disables checking the rotating subsystem clause for the relevant sexp's. Why i have no idea. If it were me the game WOULD complain about the invalid sexp cause it IS INVALID. |
|
|
Closing this since its not legal in the first place. Except in one case where the flag is specified wrongly and wouldn't work anyway. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-02-07 11:00 | FUBAR-BDHR | New Issue | |
| 2010-03-20 05:10 | FUBAR-BDHR | Status | new => assigned |
| 2010-03-20 05:10 | FUBAR-BDHR | Assigned To | => karajorma |
| 2010-03-23 13:43 | karajorma | Note Added: 0011827 | |
| 2010-03-23 14:05 | karajorma | Note Edited: 0011827 | |
| 2010-03-23 20:10 | FUBAR-BDHR | Note Added: 0011828 | |
| 2010-04-27 12:25 | karajorma | Note Added: 0011910 | |
| 2010-04-27 12:25 | karajorma | Assigned To | karajorma => Wanderer |
| 2010-05-29 14:40 | Wanderer | Note Added: 0012022 | |
| 2010-06-12 21:29 | Wanderer | Note Added: 0012063 | |
| 2010-06-13 08:39 | Goober5000 | Note Added: 0012065 | |
| 2010-06-13 08:39 | Goober5000 | Assigned To | Wanderer => Goober5000 |
| 2010-06-13 18:47 | FUBAR-BDHR | Note Added: 0012067 | |
| 2010-06-17 05:38 | FUBAR-BDHR | File Added: 2115.rar | |
| 2010-06-17 05:42 | FUBAR-BDHR | Note Added: 0012086 | |
| 2012-12-13 22:59 | MjnMixael | Note Added: 0014438 | |
| 2012-12-16 22:40 | Valathil | Note Added: 0014488 | |
| 2012-12-17 07:57 | Goober5000 | Assigned To | Goober5000 => Valathil |
| 2012-12-18 19:44 | Valathil | Status | assigned => feedback |
| 2012-12-22 21:35 | Valathil | Note Added: 0014565 | |
| 2012-12-22 21:35 | Valathil | Status | feedback => closed |
| 2012-12-22 21:35 | Valathil | Resolution | open => no change required |
