821 replies to this topic

[Suslik]

because what I do is completely unpredictable

lol, Asc : D

I think TobEx and GemRB are not even close to rivals - they do completely different things. TobEx fixes errors/adds features to existing the binary, while GemRB reproduces its open-source analog from scratch.

[Ascension64]

Thanks for explaining how the bard song works, I'd like to know how cleric's turn undead works.

I believe if cleric's level exceeds undead's level by 7 it applies opcode #13 param 8 if cleric is good/neutral, and opcode #241 if evil, but I'm not sure how the fear effect is simulated.

You are pretty much, right. Here is a faked-up pseudocode of the entire turn undead chunk

bool bTurnSuccess = false;
for_each ("creTarget of general UNDEAD [4] in sight and in front of creSource") {
  if (creSource.e % 4 == 4) continue; //never true
  if (creTarget.immuneTurnUndead) continue;

  if (creSource.turnUndeadLevel >= creTarget.levelPrimary + 7) {
	bTurnSuccess = true;
	if creSource.turnundeadlevel >= creTarget.levelprimary + 7 {
	  if (creSource.alignment & MASK_EVIL) {
		creTarget.ApplyEffect("#241 (0x0F1) Charm: Control Creature [241] timing = 0, duration = 60, param2 = 4");
	  } else {
		creTarget.ApplyEffect(CEffectInstantDeath, param1 = 0, param2 = <img src='http://www.shsforums.net/public/style_emoticons/<#EMO_DIR#>/cool.png' class='bbc_emoticon' alt='8)' />;
	  }
	}
  } else if (creSource.turnUndeadlevel >= creTarget.levelprimary) {
	bTurnSuccess = true;
	PrintEventMessage("38h Turned")
	creTarget.ApplyEffect("#141 (0x08D) Graphics: Lighting Effects [141] param2 = 0");
	creTarget.AddTrigger("TurnedBy()");
	creTarget.AddAction("184 RunAwayFromNoInterrupt(O:Creature*,I:Time*) O = creSource, i = creSource.turnUndeadLevel * 100");
  }
}

if (bTurnSuccess) creSource.PlaySound("ACT_06");

if (creSource.alignment & MASK_EVIL) {
  for_each ("creTarget of class PALADIN_ALL [207] and general ANY [0] in sight and in front of creSource") {
	int nRand = rand(4);
	if (nRand == 4) continue; //never true
	if (creSource.turnUndeadLevel - 3 >= creTarget.levelprimary + nRand) {
	  PrintEventMessage("Turned Paladin");
	  bTurnSuccess = true;
	  creTarget.ApplyEffect("#141 (0x08D) Graphics: Lighting Effects [141] param2 = 0");
	  creTarget.ApplyEffect("#24 (0x018) State: Horror [24] timing = 0, duration = 41 - target.GetMeanLevel(nClass)");
	  creTarget.ApplyEffect("#142 (0x08E) Graphics: Display Special Effect Icon [142] timing and duration as above, param2 = 24h");
	}
  }

  if (bTurnSuccess) creSource.PlaySound("ACT_06");
}

Edited by Ascension64, 05 February 2012 - 12:32 AM.

[Miloch]

Interesting... I thought there was more to turning undead than just General=Undead - doesn't it take into account undead class/race (skeleton, ghoul, zombie etc.) as per PnP turn undead tables, or is it just General=Undead + level?

[phordicus]

Interesting... I thought there was more to turning undead than just General=Undead - doesn't it take into account undead class/race (skeleton, ghoul, zombie etc.) as per PnP turn undead tables, or is it just General=Undead + level?

Considering those creatures generally are at fixed levels, Undead Level Z = Undead Class/Race Z, pretty much (skeleton 1, zombie 2, ghoul 3?, ghast 4? wight 5? etc).

[Ascension64]

I have simply reversed the code directly.

[Galactygon]

You'd have to introduce a completely new opcode: Use EFF file (use stats of caster to determine eligibility) in order to externalize this or mess around with shell spells.

If we're talking of doing a PnP style limit to turning power based on number and types of creatures, then I believe that is best solved by introducing the concept of selective targeting and limited number of creatures in the PRO of the .spl. GemRB has something like this implemented, but I can think of a more efficient way to do this. It would allow other PnP/IWD area-effect spells that limit their effectiveness to total hitpoints/hit dice possible, like Death Spell and Power Word Blind.

-Galactygon

[Pol]

I imagine implementing all of the PnP aspects of turning would be a lot of code; particularly the increasing probability of undead ignoring the turning as they increase in level relative to the priest - even the highest level priest should need a 10 or better on a 1-20 roll to turn a lich and 13 to turn a "special" undead. Because this wasn't implemented undead are pretty irrelevant in the late game.

Also, turning is only supposed to be usable once/encounter - that's easy enough to do for a spell but making undead flee can't be replicated through an opcode, since they're immune to fear... Which makes me doubt if turning should be externalized as a spell. Also, any creature with effect #297 (immune to turning) would have to be protected from this spell, I suppose that can be done through Weidu patching.

[Turambar]

Hi... I've googled around, but found nothing about that.
This is actually a quite cosmetic tweak, but it would be really nice IMO...
Is it possible to externalize the list of portraits you can chose at character creation? It would be nice to be able to chose between mod-added portraits, too, without having to select "custom" and scroll through the list (especially the list for choosing the small portrait is quite small, in a corner of the screen)

[cremo]

Hi all, and cheers for TobEX getting another release!

I've got a new wish I would like to express: the creation of a "stamina pool" (that, hopefully, will lead to an overhaul of the whole resting system).

It was something I was discussing a few time ago on the g3 forum, only to find out that it wouldn't have worked easily within the vanilla engine; that, even if I tried to shape my thoughts in order to exploit the intoxication mechanism already in the game.

Basically, I would like to create a new engine mechanic that would allow the making of limited-usage-abilities that still don't rely on the traditional vancian-system but, instead, on a threshold of fatigue that regenerates with in-game time.

In vanilla BG a character can drink as much alcohol at inns & taverns as its constitution allows him to before becoming drunk (or, technically, "intoxicated"). This status gives him fighting penalties/bonusses (to Thac0 and save against fear, IIRC) and only wears out with time (it's not necessary to sleep though I guess, since even travel time worked).

The intuition is that it should be possible to use a similar system in order to make some abilities that can be used only at a certain rate (since, let’s say, they “intoxicate you”) before a character becomes "exhausted", getting heavy combat malusses to his statistics and being prevented to use special abilities further until this state ends.

This “fatigue” will thus wear out with time without the need of resting, yet putting you at risk of going into this state while in combat.

I think that such a system would suit for a lot of abilities that could be virtually repeated many times in a day.. the limit being that if someone repeats them without any rest, it would eventually become “exhausted” for some time (you can run at high speed for some seconds in a while.. yet there’s virtually no limit to the number of times you can do that in a day, provided you take some rest from a dash to another).

E.G.

Clodgar has a Constitution of 17, which gives him 68 stamina points (4 stamina points per Con point).
Every time Clodgar uses a special ability he adds some fatigue points to his stamina pool (precise amount depending on the ability).

If “total fatigue points” > “total stamina points” -> then, “exhausted”

Note that “fatigue points” wear out with time (let’s say, for instance, at a rate of 4 points for round) and, thus, only an excessively intense usage of abilities would actually induce someone to become exhausted.

Note that exhaustion has “short time effects” (which go away in a matter of rounds) and “medium time effects” (which require a character to sleep to go away).

Short time effects:

• Can’t use ability which require fatigue points until exhausted has ended (after x turns?)
  
• Heavy malusses to statistics

Medium time effects:

• When “exhausted” state ends the stamina pool isn’t completely reset, but, instead, has some fatigue points on it that won’t go away until the char takes a sleep.

This medium time effects stack with each other if a character becomes exhausted consecutive times before taking a sleep, progressively reducing the effective dimension of his stamina pool (and thus his ability to “spam” special abilities into few rounds without becoming exhausted) and eventually forcing him into a perma-exhausted state until he takes some rest (since fatigue points will eventually > stamina points even when exausted state is reset).

This could be integrated with the general resting-system, equating x hours without sleeping with a certain amount of medium-time fatigue points.

This would mean that character with high constitution could – without going into exaustion state due to excessive usage of special powers – stay asleep effectively more time than a low con one.. adding tactical value to constitution.
So, what do you say, could TobEx do such a thing?

Edited by cremo, 07 February 2012 - 03:25 PM.

[Ascension64]

Is it possible to externalize the list of portraits you can chose at character creation? It would be nice to be able to chose between mod-added portraits, too, without having to select "custom" and scroll through the list (especially the list for choosing the small portrait is quite small, in a corner of the screen)

Sure.

Stamina

That sounds like a pretty huge overhaul. I will add to to-do list but don't expect it to occur any time soon. I'm still drowning in engine bug fixes at the moment.

[Turambar]

Is it possible to externalize the list of portraits you can chose at character creation? It would be nice to be able to chose between mod-added portraits, too, without having to select "custom" and scroll through the list (especially the list for choosing the small portrait is quite small, in a corner of the screen)

Sure.

Thanks.
If it can help, I think GemRB uses the pictures.2da file, whose structure is:

2DA V1.0
-1
			  GENDER	 HAIR	SKIN	MAJOR	MINOR
NCERND		1		  0	85	40	46
NKELDOR	   1		  6	12	57	63
NANOMEN	   1		  2	84	59	45
NEDWIN		1		  0	10	47	50
NHAER		 1		  18	84	103	66
NHORC		 1		  0	15	39	38
NJAN		  1		  0	84	35	71
NMINSC		1		  110	85	58	50
NVALYGA	   1		  0	87	45	57
NYOSHIM	   1		  0	84	39	66
NKORGAN	   1		  6	85	66	47
MAN1		  1		  6	84	52	46
MAN2		  1		  2	12	37	45
GENDWRF	   1		  4	85	39	49
GENMELF	   1		  91	10	21	60
GENMHLF	   1		  0	85	40	50
AJANTIS	   1		  3	 3	 3	 3
CORAN		 1		  2	12	45	55
EDWIN		 1		  91	12	47	41
ELDOTH		1		  0	12	41	36
GARRICK	   1		  0	12	41	50
KAGAIN		1		  6	85	39	49
KHALID		1		  4	12	48	41
KIVAN		 1		  1	84	37	39
MINSC		 1		  110	84	60	58
MONTAR		1		  91	10	21	60
QUAYLE		1		  110	8	45	66
TIAX		  1		  91	12	47	46
XAN		   1		  0	12	45	64
XZAR		  1		  91	84	54	66
YESLICK	   1		  92	85	39	42
NNALIA		2		  4	13	57	41
NMAZZY		2		  2	12	46	66
NAERIE		2		  3	13	48	50
NJAHEIR	   2		  2	109	52	66
NVICON		2		  79	83	58	62
WOMAN1		2		  3	84	61	46
WOMAN2		2		  0	84	45	58
ALORA		 2		  4	12	60	45
BRANWE		2		  3	12	37	41
DYNAHEI	   2		  2	12	60	46
FALDORN	   2		  91	84	54	65
IMOEN		 2		  4	13	45	61
JAHEIRA	   2		  92	12	41	65
SAFANA		2		  4	12	60	60
SHARTEL	   2		  4	84	66	21
SKIE		  2		  0	12	66	45
VICONIA	   2		  79	83	54	60

Edited by Turambar, 08 February 2012 - 02:21 AM.

[Galactygon]

Stamina

That sounds like a pretty huge overhaul. I will add to to-do list but don't expect it to occur any time soon. I'm still drowning in engine bug fixes at the moment.

I think it should be possible to realize this without a major overhaul.

An expanded opcode 177 to be able to use conditions from .bcs blocks would allow extensive usage of local variables/scripting in spells. This can allow for an implementation of many systems, including this stamina system. You can then use combinations of opcode 272 and embedded .eff files to check for a certain local variable and apply other effects (like restoring certain .spl files to the character's memory).

-Galactygon

[GeN1e]

Found another bug, I think.
The speed field (0x12) in the ITM's extended header is ignored if the type (0x0) is set to 3 (magical ability). Instead it activates immediately.

[aVENGER]

Cross posting from here.

It appears that opcodes #27, #28, #29, #30, #31, #84, #85, #86, #87, #88 and #89 all exhibit the same behaviour. In summary, all physical and elemental resistance altering opcodes can't be used to set the relevant stat to a fixed value nor do they accept a percentile modification of the original stat value.

Would it be possible to alter the aforementioned opcodes so that they would work like this:

Parameter #1: Statistic Modifier
Parameter #2: Type
Description:
Applies the modifier value specified by the 'Statistic Modifier' field in the style specified by the 'Type' field.

Known values for 'Type' are:
0 Cumulative Modifier -> Resistance = Resistance + 'Statistic Modifier' value
1 Same as 0
2 Non-functional
3 Flat Value Modifier -> Resistance = 'Statistic Modifier' value
4 Percentage Modifier -> Resistance = (Resistance * 'Statistic Modifier' value) / 100

'Statistic Modifier' can be positive or negative.

The bolded part is the proposed new content. I'd suggesting doing it this way in order to prevent breaking backward compatibility in case some spell/item uses values 1 or 2 for Type. I think there might be a few items that do this even in the unmodded game.

[GeN1e]

It appears that opcodes #27, #28, #29, #30, #31, #84, #85, #86, #87, #88 and #89 all exhibit the same behaviour. In summary, all physical and elemental resistance altering opcodes can't be used to set the relevant stat to a fixed value nor do they accept a percentile modification of the original stat value.

Param2=1 works fine. I've used it to bypass target's magic damage resistance (opcode=31, duration=0, timing=0, param1=0, param2=1), and I can swear it did work.

Edited by GeN1e, 15 February 2012 - 01:42 PM.

[aVENGER]

Param2=1 works fine. I've used it to bypass target's magic damage resistance (opcode=31, duration=0, timing=0, param1=0, param2=1), and I can swear it did work.

I wouldn't call it working fine, but it does seem to have some effect. Still it doesn't do what one would expect from it and my namesake explained why.

Therefore, my request for parameters 3 and 4 still remains.

[GeN1e]

I've just checked it myself. Doesn't work for prolonged time indeed.

I second the request then. However, I would instead fix parameters 1 and 2 - I imagine those who may have used them were assuming they worked as stated in IESDP.

[Avenger_teambg]

If you "fix" it, it will break other parts. You definitely need new parameters if you want the new functionality.

[Avenger_teambg]

Spoiler

From the other thread:

• having a way to check for barbarian and/or wild mage kit (as Miloch said here).
  
• giving penalties to thieving skills even when the unusability doesn't exactly match the Assassin / Bounty Hunter ones. Current behavior (I don't know how the code actually is, but this is the end effect):
  
  points = 25;
  if (cre.unusability == KIT_ASSASSIN) points = 20;
  if (cre.unusability == KIT_BOUNTY_HUNTER) points = 15;
  
  Desired behavior:
  
  points = 25;
  if (cre.unusability & KIT_ASSASSIN) points = 20;
  if (cre.unusability & KIT_BOUNTY_HUNTER) points = 15;
  
• Forcing a full window redraw every tick, to avoid problems with external overlays (E.G. Steam Community). Currently, only the game area is redrawn, along with area under the mouse and/or otherwise animated (buttons etc.).

Actually, I prefer an even more flexible system, where you can use arbitrary skills (even new ones), with arbitrary amount of points distributable, for any kit/class:

Spoiler

2DA	V1.0
-1
				DESC_REF	CAP_REF	ID	THIEF	MAGE_THIEF	FIGHTER_THIEF	CLERIC_THIEF	FIGHTER_MAGE_THIEF	ASSASIN		BOUNTY_HUNTER	SWASHBUCKLER	MONK
FIRST_LEVEL		*			*		*	40		40			40				40				40					15			20				40				10
RATE			*			*		*	25		25			25				25				25					15			20				25				10
PICK_POCKETS	9597		9463	29	1		1			1				1				1					1			1				1				-1
OPEN_LOCKS		9598		9460	26	1		1			1				1				1					1			1				1				-1
FIND_TRAPS		9599		9462	28	1		1			1				1				1					1			1				1				1
MOVE_SILENTLY	9600		9461	27	1		1			1				1				1					1			1				1				1
HIDE_IN_SHADOWS	9601		34120	135	1		1			1				1				1					1			1				1				1
DETECT_ILLUSION	34123		34121	136	1		1			1				1				1					1			1				1				-1
SET_TRAPS		34124		34122	137	1		1			1				1				1					1			1				1				-1