You could also set the "lootable" properties of weapons, thrusters, etc., to "false"

That'd take care of those error messages right away.

I think the main problem here is having "wrecks" that aren't proper Solars in the first place. That's an entirely different problem, of course, but it's related to what you're talking about, to some degree.

Do the wrecks have hulls and packages? That may help...

+++ out of cheese error - redo from start +++

Xtreme Team Studios

2 other solutions are:
1. remove wrecks
2. create new shiparch entries for each wreck that does not include the player looting fuse

To Argh : You could also set the "lootable" properties of weapons, thrusters, etc., to "false"
I do not think that that would solve the problem. Besides that it would effect all other situations where equipment becomes available as loot.

To Anton : Do the wrecks have hulls and packages?
If you consider loadout to be the same as package, which I do, the answer is yes.

To Louva: remove wrecks
You are right it is an option, but not really for me.

that does not include the player looting fuse
I am unsure what you mean by this.

To all: thanks for taking the time to respond.


BuckDanny

Loadout is not what I meant - I refer to the errors listed by FLDataStorm on a clean FL... Ships have no hull definintion or package definition have no equipment.... Now for wrecks of course the package should not be relevant as they're never bought, but the hull may do. Since FL is not fully finished and debugged the package reference for the archetype may still be looked for by the engine.

+++ out of cheese error - redo from start +++

Xtreme Team Studios

Anton, the fact that FL Datastorm is generating those hull error messages does not necessarily mean that they are errors. No offence to Holger, Datastorm is a great tool, but it is not perfect and does have some flaws.
The hull and the package definitions are in my opinion solely for pricing and loadout ships that players can buy. For NPC’s the game is aware of which ship to use by references to the cmp files (archetype =) and their assigned loadouts. The same is the case in the Solarach.ini where the wrecks are specified. Their loadouts are declared in the ship loadouts.ini.

Besides that: the ship is there (as a wreck), the loot (equipement) is there, the loot is disconnected when the threshold is reached when shot at, the only thing is the error-message that comes with it.
Also there are no error meassages when fate = disappear or fate = debris is used. Which stated as above proofs that the code is executed and no other errors are detected. The fuse_surprise_solar is the only file that uses the fate = loot command. When other methods are used to release the equipment no error messages are generated.

But maybe I should have asked another question first. Am I the only one that is receiving these error messages when looting a shipwreck?


BuckDanny

Buck - you can copy every ship entry, and paste them into the shiparch.ini again, and add a letter, or anything, to their nicknames. If you are using the playerlooting - then you could in fact make it so that these ships use non player looting fuses.

I have this, and it still gave those errors. To clean up the whole thing, I just bunged it all in as cargo instead, which removes those errors, and still drops the stuff without issue.

My wrecks used the original entries - whereas all our player ships are player_nickname_of_ship instead. NPC's don't even fly the same ships, which means we can have NPC ships tweaked to make them better than players to offer more of a challenge

I think I went one further, moved all the loadouts for wrecks into my solars folder loadouts file, and made it all cargo instead. Took about 20 mins, and worked a treat.........especially since, like i said, I still got fate errors even though the ships had original fuse entries and not player looting! That was so I could change loadouts for wrecks dead easily whenever i liked, without having to search for them in the file etc

Edited by - Chips on 11/6/2004 8:15:55 AM

Chips, thanks for confirming the error messages and being converting the loot equipment to cargo as a good workaround solution. Also thanks for the tip on the NPC ships.
Now I have some editing to do which I posponed untill I had confirmation. Moving the solar loadouts from the loadouts.ini in the ship folder to the solar folder makes perfect sense to me also.


BuckDanny

may I suggest a good text editor? as you can then do 'replace' commands once you have all the wrecks pasted to the bottom of the file. I slapped em all in, then started with the cursor just above them, and replaced:

equip =
line for
cargo =

and stuff like
, HpWeapon01

for

, 1

Changed loads of them that way

That is the plan, but thanks anyway for pointing that out. In the process I will create a script file for it. Need to patch the Epsilon files anyway and it might be a handy additional whenever I decide to bring out Unofficial patch 1.5. But that has to wait anyway for Louva to bring out SDK 1.5 and it has proven to be stable.

BuckDanny

Actually, its in the fuse at_t = timing. Notably, look in surprise_fuse.ini. The at-T = for LOOT is set to occur when Item is at 0.00000. But then, under the surprise wreck itself it's set to DESTROY object in question when it reaches 0.10000. Now, how is it going to DROP loot, if where it's supposed to be dropping it from is already DESTROYed? It can't. Switch the timings (instead of commenting out the relevant entries) fixes the issue and no more error messages.

Thanks for the tip

As you may have noticed, I know next to nothing about the fuse entries, and still havent' bothered going into it at all either

Zacam, I think you missed the point in my opening for this thread. Timing is absolutely not the issue here. Everything is going the way is it supposed to be. The FL engine simply does know the fate = loot command. I suggest you carefully reread my findings.

Since you have been bringing this subject up a few times, I will give you my opinion on it. What you are refering to is an entirely different subject than the above although there is a relation with wrecks. There are several things with wrecks that are not the way they are supposed to be. And one of them is that the FL enigine does not release all the loot on some of the wrecks, that the wreck holds. In the Unofficial Patch 1.4 I used a workaround to have FL engine release loot that is there but that is not released. I recognize that there are several workarounds to achieve the wrecks relase the loot. The one I used in the Unofficial patch is just one of them. But the real problem is not the timing.

The real problem lies in the fact that there are wrong references in the collissiongroups.
If you would take the time you would find that:
When you approach a wreck in space you can scan the wreck and especially when you use the option to scan the ship’s loadout you will see a wired image of the ship and the attached equipement in blue or yellow. What you are seeing then is a complete ship, not a representation of the wreck as it actually is. You will see equipment attached to a wing while the wreck does not have that wing.
This is where the collision groups come into the picture.

From the Solararch.ini:
[Solar
type = MISSION_SATELLITE
nickname = suprise_li_freighter
LODranges = 0, 80, 120, 200, 300, 1200
DA_archetype = ships\liberty\li_freighter\li_freighter.cmp
material_library = ships\liberty\li_playerships.mat
surface_hit_effects = 0, small_hull_hit
mass = 100000.000000
solar_radius = 800
shape_name = NAV_surpriseX
explosion_arch = explosion_li_elite
hit_pts = 3600
destructible = true
fuse = fuse_suprise_li_freighter, 0.000000, 3601
fuse = fuse_suprise_drop_loot, 0.000000, 3590

[CollisionGroup
obj = li_starboard_sidepanel_lod1
dmg_hp = DpStarboardsidepanel
dmg_obj = li_freighter_dmg_starboard_sidepanel_cap
separable = true
parent_impulse = 0
child_impulse = 0
debris_type = debris_small_ship
hit_pts = 1800

From the fuse_surprise_solar.ini:
[fuse
lifetime = 0.100000
name = fuse_suprise_li_freighter

[destroy_group
fate = disappear
at_t = 0.100000
group_name = li_starboard_sidepanel_lod1

The lines of importance are obj = li_starboard_sidepanel_lod1
and group_name = li_starboard_sidepanel_lod1
Now if you would go to the ships folder for the Liberty Freighter you would find a file called li_freighter_dmg_starboard_sidepanel.3db. When you open this file with the UTF editor and open the Vmesh library tree you would find a reference to data.ships.liberty.li_freighter.li_freighter_dmg_starboard_sidepanel.lod0-112.vms

If you would change the lod1 references in the ini's into lod0 references, the loot will become available without having to use a workaround. There is only one drawback on this. The wreck would not look the same, because the part that was missing earlier is now attached to the ship, because the right connection is made.
So you can’t really win this. That is why converting the equipment loot into cargo is the best solution for both of the issues.


BuckDanny