[ER] QOL binding for retrieving local player's PlayerIns

[ArloFilley]

Adds two small quality-of-life methods to the eldenring crate, mirroring functionality in the DS3 crate.

+ PlayerIns::Instance

Adds a manual FromStatic impl for PlayerIns that returns the local main player via WorldChrMan.main_player. This creates a simple binding for accessing the main player. Useful for finding players stats, data, and position.

Mirrors previously existing implementation

fromsoftware-rs/crates/darksouls3/src/sprj/chr_ins.rs

Lines 250 to 264 in 25b909c

	impl FromStatic for PlayerIns {
	fn name() -> Cow<'static, str> {
	"PlayerIns".into()
	}
	/// Returns the singleton instance of `PlayerIns` for the main player
	/// character, if it exists.
	unsafe fn instance() -> InstanceResult<&'static mut Self> {
	unsafe {
	WorldChrMan::instance()
	.and_then(|man| man.main_player.ok_or(InstanceError::NotFound))
	.map(|mut ptr| ptr.as_mut())
	}
	}
	}

+ CS::ChrIns.kill()

Adds a kill() method to ChrIns and all subclasses. Kills characters by setting current hp (ChrIns.module_container.data.hp) to 0.

Mirrors previously existing implementation

fromsoftware-rs/crates/darksouls3/src/sprj/chr_ins.rs

Lines 177 to 188 in 25b909c

	#[for_all_subclasses]
	pub impl ChrInsExt for Subclass<ChrIns> {
	/// Returns the character ID string for this character, of the form `c1234`.
	fn id(&self) -> String {
	self.superclass().modules.data.id()
	}
	/// Set this character's HP to zero, killing it.
	fn kill(&mut self) {
	self.superclass_mut().modules.data.hp = 0;
	}
	}

[vswarte]

Maybe we should implement this as a new method PlayerIns::main_player() as well as for DS3? I don't really feel like it's intuitive to have PlayerIns::instance() give you the main player thinking about it now. Thoughts?

[ArloFilley]

It feel intuitive to me that PlayerIns::instance returns the main player. I do agree however that it should be immediatly obvious to everyone what PlayerIns::instance is returning, which is not currently the case. Personally I'd like to keep the current pattern, but I'm not sure there's a way to make the return type more explicit without a wrapper around PlayerIns. Unless I'm missing something?

If there isn't a way to make the return type more obvious then a new main_player() method is the way to go.

[ThomasJClark]

main_player() (or local_player()?) makes sense to me too. issue isn't the return type, it's that there are multiple player instances for NPCs and networked players but instance() implies it's a singleton

[ThomasJClark]

the main player also doesn't have a static lifetime. it's reallocated when reloading the game, so maybe this shouldn't be a FromStatic anyways

[vswarte]

I kind of agree that this is stretching the definition a bit. What do you think @nex3?

[vswarte]

fwiw I think PlayerIns::local_player() would be more appropriate than PlayerIns::main_player()

[nex3]

the main player also doesn't have a static lifetime. it's reallocated when reloading the game, so maybe this shouldn't be a FromStatic anyways

This is also the case for several much broader types that are currently FromStatic, like MapItemMan. We definitely want a global way to access these singleton instances, but they don't follow the requirement that the 'static lifetime last the remaining duration of the program. This is probably worth a separate discussion.

For this case, I'm fine with changing the name here and in DS3 to local_player().