View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000703 | FSSCP | --------- | public | 2006-01-11 12:28 | 2006-11-01 04:57 |
| Reporter | thesource2 | Assigned To | taylor | ||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Summary | 0000703: Intelligence database is empty in tech room when FreeSpace2 main campaign is selected | ||||
| Description | If I select Derelict for example everithing is ok, but if main campaingn is selected - no intelligence available | ||||
| Tags | No tags attached. | ||||
|
|
This sounds like a known bug, but I'm not 100% sure...assigning to taylor, he should know. |
|
|
I kinda thought this was Mantis'd already, but apparently not. Anyway, this is fixed in the new pilot code but since the fix was insanely minor I'll go ahead and commit this one thing. There is more wrong with the code in this respect but this will at least fix the intel entries getting reset when using the default campaign. The bug is that it gets reset to default (if campaign name is "freespace2") *after* the pilot data is read in. Simply switching the order of those two blocks prevents it from screwing up what's in the pilot file. |
|
|
Fixered. |
|
|
Reopening just because I had a few questions about this bug. This was actually my doing originally; my intent was to set the tech db to *default* (not clear it entirely) so that playing through the campaign would reveal the ships gradually just as for a brand-new pilot. So: 1) How come the tech db was cleared completely, as opposed to just pared back to the default ships? This may be a separate but related bug. 2) What does switching the order of the statements do... i.e. what does the fix accomplish? |
|
|
Goober5000, I didn't say that ships database was empty, I said it about Intelligence database. |
|
|
Oh. Well then change question 1) from "ships" to "intelligence". Actually the intelligence db should have been "pruned" without any entries being removed. :p I'll wait for taylor's answer to 2), as it may illuminate 1). :) |
|
|
The problems are related (same basic thing) so I'll just hit them both at once... In the function to reset to defaults it checks that the default flag is set and if so then it makes sure to add the visible flag, but if the default flag is *not* set then it removes the visible flag. Since the data in the pilot file is read first, and is correct, the defaults will override what is in the pilot file. This isn't a big problem for ships and weapons (though it is a problem) since the flags are separate, but for the intel entries the flags can end up getting reset. So when a pilot file is saved it runs through Intel_info[] and if the techroom flag is set it writes it out as set. When it reads back in it sets the normal flag but not the default flag. It ends up being a init order thing since if you switch to a different campaign it saves correctly, but when you switch back to the main fs2 campaign it goes through and gets the flags wrong and the function to revert to defaults mistakenly clears the flag instead. Now if you go through the code it looks like it should work (a problem I've had with it in testing since nothing appears wrong) and it doesn't always mess up, but if you do it all in just the right order (which isn't that difficult) then the entries will get cleared. This obviously hints at a larger bug, a complex series of bugs actually, but that is what the total pilot file rewrite is supposed to fix. Most of the new pilot code has these steps consolidated so it shouldn't be much of a problem anymore (hopefully never a problem again). What you did was right with the default entries, but because of the order things are reset when a campaigns are switched, you can end up with the unwanted affect. The basic problem, as far as this bug report is concerned, stems from how the campaigns contain the intel entries now (they didn't before) and switching campaigns doesn't cause you to reset the campaign. The in-between state saving (something the code totally sucks at) had been fixed to reset or not the various entries which actually compounds this particular problem rather than fixing it, which was the original intent. The current fix merely makes sure that the pilot file has final say in what entries are visible or not, since it should, and it should simply add to what the default settings are rather than cause an unintentional reset of what the parsed tbl had. It's as much a problem with the pilot code as the defaults, but switching the order of the statements is something that can be done easily, have the same basic affect and do so without hurting anything (unlike a proper change to the pilot code, hence the rewrite). EDIT: I missed all of the updates while I was typing. Don't ask me to explain something unless you are really serious ;) Anyway, the "pruning" is done by the pilot file code, though it doesn't reset everything to 100% default, it just removes the basic in-tech-database flag. Part of the problem is that it can't always be pruned, it kills in-between progress. That's the fault of the reset_to_defaults function which is why the pilot code needs to have more say in what's visible. If the defaults code did it's job then the pilot code will have the correct values for everything, but it has to let the pilot code assume that it's right. The pilot code, mixing with the fact that the campaign code wasn't originally supposed to work like we're using it, is the rest of the problem. edited on: 01-13-06 12:54 |
|
|
Ah, very good - your explanations are always much appreciated. :) Any projections on when we'll finally see the pilot rewrite? :D |
|
|
Just need the time to do it. I had hoped to have it done last week but other than the small bug fixes that I've done I haven't done anything code related in a couple of weeks. I'm still messing around with the campaign savefile, which is the only real holdup, and I still need to get the DirectInput code up to the SDL code so that it all of the new controlconfig settings work. I've redone the campaign safefile twice from scratch already, just haven't been real happy with it. The new way I'm doing the formats (a main header and then section headers and sizes, like a wave file) allows both backwards and forwards compatibility but having everything get loaded/saved/reset is still an issue. I'm still trying to get even better mod support in there too. |
|
|
Sorry to dissapoint you, but this bug is not resloved. Intelligence database is still empty but now in any campaign. |
|
|
It won't magically make the entries appear, if they were gone they will stay gone. Previously there was a carry-over bug but that is part of what was fixed. Because of the the carry-over it wouldn't clear out everything properly and intel entries would should up when they weren't supposed to. Make a new pilot and see if switching campaigns with that pilot works. If it's still not good enough then this will just have to wait for the new pilot code since fixing it properly isn't an option right now. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-01-11 12:28 | thesource2 | New Issue | |
| 2006-01-13 07:45 | WMCoolmon | Note Added: 0004216 | |
| 2006-01-13 07:45 | WMCoolmon | Assigned To | => taylor |
| 2006-01-13 07:45 | WMCoolmon | Status | new => assigned |
| 2006-01-13 09:14 | taylor | Note Added: 0004219 | |
| 2006-01-13 09:14 | taylor | Status | assigned => resolved |
| 2006-01-13 09:14 | taylor | Resolution | open => fixed |
| 2006-01-13 09:14 | taylor | Note Added: 0004220 | |
| 2006-01-13 16:53 | Goober5000 | Status | resolved => feedback |
| 2006-01-13 16:53 | Goober5000 | Resolution | fixed => reopened |
| 2006-01-13 16:53 | Goober5000 | Note Added: 0004238 | |
| 2006-01-13 16:59 | thesource2 | Note Added: 0004239 | |
| 2006-01-13 17:03 | Goober5000 | Note Added: 0004240 | |
| 2006-01-13 17:42 | taylor | Note Added: 0004242 | |
| 2006-01-13 17:54 | taylor | Note Edited: 0004242 | |
| 2006-01-13 18:19 | Goober5000 | Note Added: 0004243 | |
| 2006-01-13 19:02 | taylor | Note Added: 0004246 | |
| 2006-01-13 19:03 | taylor | Status | feedback => resolved |
| 2006-01-18 18:11 | thesource2 | Status | resolved => feedback |
| 2006-01-18 18:11 | thesource2 | Note Added: 0004381 | |
| 2006-01-18 18:40 | taylor | Note Added: 0004383 | |
| 2006-01-18 18:40 | taylor | Status | feedback => resolved |
| 2006-11-01 04:57 | taylor | Resolution | reopened => fixed |
