Skip to content

Conversation

ifeldshteyn
Copy link
Contributor

Prevents you from starting the level by holding a weapon that is removed during MOD_CONF overrides.

// Internal types need to be included in this case.
#include <TFE_Jedi/InfSystem/infTypesInternal.h>
#include <TFE_Jedi/Renderer/jediRenderer.h>
#include <TFE_DarkForces/Scripting/gs_player.h>
Copy link
Contributor

@jerethk jerethk Sep 13, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would be uncomfortable doing this.
I think referencing scripting functionality from the base-game is a pattern best avoided.
Scripting has a dependency on the base-game; the reverse should not be true.
(what do you think @luciusDXL ?)

What you could do instead is use the existing player_hasWeapon() function in player.cpp
Note that this function (annoyingly) does not use the WeaponId Enum as its parameter, it instead uses weaponIndex which appears to be based on the keyboard hotkeys, i.e. fist = 1, pistol = 2, rifle = 3....
So you will have to translate from WeaponId to weaponIndex -- but AFAICS it is simply a matter of adding 1 to the WeaponId.

So this should work:

if (!player_hasWeapon(s_playerInfo.curWeapon + 1))
{

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, factor out any common functions and use those. Don't call script functions from within the game (unless it is related to scripting).

Copy link
Contributor

@jerethk jerethk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Couple more issues buddy - thanks


default:
return false;
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @ifeldshteyn
Can you please revert this -- you can't directly use player_hasWeapon from player.cpp because the argument it takes is not based on the same data.

The argument here is the WeaponId enum where
FIST = 0
PISTOL = 1
RIFLE = 2
etc.

Whereas player.cpp player_hasWeapon uses the keyboard numbers
FIST = 1
PISTOL = 2
RIFLE = 3
...

There are also a couple of other minor differences -- eg. player_hasWeapon also assesses whether you have detonator and mines ammo.
And the return value is JBool instead of primitive bool

So it is best to just leave the gs_player function as is.

public:
bool scriptRegister(ScriptAPI api) override;
};
bool hasWeapon(s32 weapon);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This can now be reverted too, it doesn't have to be exposed

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is complete @jerethk

}

// Don't start the game with a weapon you don't have after overrides.
if (!player_hasWeapon(s_playerInfo.curWeapon))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this will have to be s_playerInfo.curWeapon + 1 to work correctly

But you should double check to be sure.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ifeldshteyn
I think u missed this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ifeldshteyn
I think u missed this

Copy link
Contributor

@jerethk jerethk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks good now, thanks Karjala

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants