<system>System, Sector</system>
-
Playing around with spawning solars, I’m often encountering the issue whereby the scanner name will be what I defined through the FmtStr, like so:
FmtStr infoname(0, 0); infoname.begin_mad_lib(196614); infoname.end_mad_lib(); FmtStr infocard(0, 0); infocard.begin_mad_lib(0); infocard.end_mad_lib(); ```but the name you get when you select the object will be the annoying <system>System, Sector <sector>. When speaking of INI code, this is usually because the object is of a type that needs a behavior = NOTHING line, but doesn't have it, but in the case of spawning solars, I'm not sure how this applies. I've tried setting an AI for the object through pub::AI::SubmitState with a SetPersonalityParams that has the correct NOTHING state graph, but even then it doesn't change anything. Plus, I'm doing this for jump gates which have neither a pilot nor a behavior line in FW and work fine despite that. The worst by far is that sometimes I'll compile the plugins with a random IDS and it'll work, but then when I change JUST that IDS in the method calls above and recompile, it doesn't work. Changing the IDS back to its working value doesn't make it work again, infuriatingly. It's as though you need the stars to align during compilation for it to actually stick… Does anyone know what the logic is for those names, and if it's possible to fix it? I'd rather fix the root of the issue than just patching the client so it always displays the same thing as the scanner, but I'd take that if no other solution seems apparent. Just for the record, I've also tried setting the IDS in the first parameter of the FmtStr struct, removing the mad_lib calls, setting the IDS for both the name and the card, etc. The behavior is the same: it might work for a name, but it'll stop working on a recompile with a different name.</sector></system>
-
It’s been my experience with ini files that it happens without a reputation line. Just to verify, I removed behavior from the New York->California jg and it still showed okay; removed reputation and there’s the sector. It calls Reputation::Vibe::GetAffiliation and if that’s -1 it does the sector.
-
Checking that, if I call GetAffiliation myself during CSolar::Init on the gate that I spawn, I get the correct affiliation. The buoy also appears green as expected (same faction for the character and the solar). Yet, I still get the sector name.
EDIT: I should note, the above is done on the client, so the data is being correctly transmitted and parsed.
One thing that I think is worth noting is that using your PacketLog.dll, the packet sent to the player has this:
faction = 43985
rep = 0This is in spite of the object being affiliated with the faction. If I compare with a ship, the rep is the one given in initialworld.ini as expected.
-
Maybe you explicitly need to call pub::Reputation::SetAffiliation and/or SetReputation. Otherwise, I’m afraid you’ll have to track it down the hard way - trace 0x4E8100 and discover the circumstances leading to the call to 0x48DC10 (which gets the sector). Note that target names are cached, so remove the jump at 0x4EFE60 to have it called again.
-
That’s actually interesting!
When I spawn the solar, the reputation is incorrect. I need to manually reset its reputation to the correct one by calling pub::Reputation::SetAttitude on each player’s reputation, otherwise the solar is always neutral.
Since this call is done after the solar is fully created, could it just be that the name’s cached and thus not regenerated after the reputation change?
-
For future reference, this problem only arises if the solar’s type is JUMP_GATE. I’ve tested with STATION, PLANET and SATELLITE and they all behave as expected, but JUMP_GATE randomly works 5% of the time and that’s it.