Any way to determine how many companions the player has?

[Danneyo]

Alright, so I managed to fix it. I remade the script in the QuestScript, and that seems to have done the job.

scn ABHMquest01

short DoOnce
short LastDay
short CurrentDay
short basepay
short payout
short tfollowers
short BountyVars
array_var pfollowers

Begin GameMode
set CurrentDay to GameDaysPassed
let pfollowers := player.GetFollowers
let tfollowers := (Ar_Size pfollowers) + 1

	if (DoOnce == 0)
         set LastDay to GameDaysPassed
		let pfollowers := Ar_Construct "array"
         set DoOnce to 1
	endif
	
	if (CurrentDay - LastDay) >= 1
		SetStage ABHMmain 20
	endif

	if (BountyVars == 10)
		set basepay to 3000
		set payout to (basepay / tfollowers)
	endif
end

I'll probably try and set up something where the amount of followers is only set when the actor dies, but I'm just happy it works right now.

 

EDIT: Just made an unset variable in the main Quest script that the OnDeath Script changes to 1, which in turn sets the number of followers.

Edited November 10, 2018 by Danneyo

[Mktavish]

What about when followers die , are they then not counted , is that intentional ?

Was assuming you wanted the "OnDeath" block of the boss to create a time stamp so to speak.

 

Ahh caught your edit.

 

But does it seem like that code did require multiple frames to register it's outcome ?

[Danneyo]

What about when followers die , are they then not counted , is that intentional ?

Was assuming you wanted the "OnDeath" block of the boss to create a time stamp so to speak.

 

Ahh caught your edit.

 

Pretty much. The idea is that, when you fight each of the Bounties, your followers are counted, and the bounty is "divided" between your entire party. So, if you roll into an encounter with 10 people in your party, the amount of money you'll get for turning it in will be peanuts in comparison to what you'd get with one or two people total. I want it to be a time stamp so players can't just beat the boss, then dismiss everyone before they turn it in.

[Mktavish]

So if they skillfully let people die ... they could end up with a bigger bounty ?

[Mktavish]

It seems you probably missed my final edit at post #12 ... sorry my member status does not show post edits.

I didn't pick it , cuz I did find those time stamps useful back then :laugh:

 

Anyways , I feel a more in depth explanation coming on. Like how the single frame block fails next to the multi frame block.

 

I find it helpful to think of the checks/results as dip switches ... as in on a circuit board.

 

When the check comes accross as true , it then flips a switch. That within a 1 frame block did not have time to be flipped and registered in the same code block , no matter how many lines below it is.

 

Therefore it requires another looksee at the code ............. was gona expand on that , but I think that explanation needs no expounding as of yet :sick:

 

Add edit : or this is in theory .... you could have multiple single frame blocks working together to simulate a game mode block ...

 

For example :

 

~~~~~~~~~~~

SCN MyActivator01Script

 

Begin OnActivate

 

; Bla bla

; Bla bla

; bla Bla

Activate MyActivator02

;endif

End

~~~~~~~~~~~~~

SCN MyActivator02Script

 

Begin OnActivate

 

; Bla bla

; Bla bla

; bla Bla

Activate MyActivator03

;endif

End

~~~~~~~~~~~

SCN MyActivator03Script

 

Begin OnActivate

 

; Bla bla

; Bla bla

; bla Bla

Activate MyActivator01

;endif

End

~~~~~~~~~~~~~

 

Which in theory ... guess needs some testing :wink:

[Danneyo]

So if they skillfully let people die ... they could end up with a bigger bounty ?

 

Quite possibly! It would fit with the kind of sinister tone of the mod. As long as they die before the bounty dies, they won't be counted when dividing the bounty up.

 

It seems you probably missed my final edit at post #12 ... sorry my member status does not show post edits.

I didn't pick it , cuz I did find those time stamps useful back then :laugh:

 

Anyways , I feel a more in depth explanation coming on. Like how the single frame block fails next to the multi frame block.

 

I find it helpful to think of the checks/results as dip switches ... as in on a circuit board.

 

When the check comes accross as true , it then flips a switch. That within a 1 frame block did not have time to be flipped and registered in the same code block , no matter how many lines below it is.

 

Therefore it requires another looksee at the code ............. was gona expand on that , but I think that explanation needs no expounding as of yet :sick:

 

Hmm... How is that different compared to what I'm using now? Practically, I mean. Like, would it have an effect on the system in actual gameplay?

Edited November 10, 2018 by Danneyo

[Mktavish]

Game mode blocks are a cumulative effect ... it just depends on what you have going already.

 

So for starters in that code of ...

"let pfollowers := player.GetFollowers

let tfollowers := (Ar_Size pfollowers) + 1"

 

It does not need to spam this check always.

Certain events could check it , like you mentioned.

(the "GetFollowers")

 

You said "I'll probably try and set up something where the amount of followers is only set when the actor dies"

 

The Boss actor ? Doesn't it do that already in the OnDeath block ?

It's just that "OnDeath" only occurs once and for 1 frame.

Could ressurect and kill them again to loop it I guess ^shrug^

[Mktavish]

And to clarify why I keep mentioning the 1 frame block.

Sorry is just to drive the point home about 1 frame blocks, and to add that there are only 2 kinds of code blocks.

Those that fire every frame under certain circumstances.

And those that fire for 1 frame under a certain event.

 

Only 3 code blocks fire continually

 

GameMode

MenuMode

ScriptEffectUpdate

 

The rest are 1 frame occurances