821 replies to this topic

[Ascension64]

I don't get the conversation. Obviously, a bow that has proficiency type set to Bow, will use the proficiency Bow details. Are you actually asking whether someone using a bow will benefit from a two-handed weapon proficiency star?

[Dakk]

[W]hy you can't re-ignite an NPC romance by getting them drunk.

Hahaha, what an awesome idea. Could we have this added to the wish list?

[i30817]

No

[Miloch]

Are you actually asking whether someone using a bow will benefit from a two-handed weapon proficiency star?

Yes, that's what he's asking. A bow is a two-handed weapon per the "Type" as listed in its description.

I don't quite understand the fuss about this. The rules from which the proficiency system derives (2nd ed. Combat & Tactics and Skills & Powers) do not distinguish between melee and ranged weapons in the discussion of weapon style proficiencies. In fact, the rules specifically imply that bows count as two-handed weapons, since it says a halfling could not use the two-handed weapon specialty for longbows or halberds, since they're too big for him, but he could use it for a broadsword (which would be a two-handed sword to him) and presumably a shortbow (Combat & Tactics p. 49).

[phordicus]

Can you quote the relevant passage? Fair use and all.

[Dakk]

Can you quote the relevant passage? Fair use and all.

Fighting Styles:

Spoiler

Fighting Styles
There are almost as many different ways of fighting as there are
fights. Every character and monster has his or her favorite weapon and preferred means
of attack. Fighting styles are general ways in which a character can equip himself for a
fight and execute his attacks during the battle.
If a character doesn't know a fighting style, he can learn it at the cost of a proficiency
slot. Warriors can actually specialize in fighting styles to gain bonus attacks or defenses;
this is covered in Chapter Four.

The headings are:
Single Weapon
Two-handed Weapon
Weapon and Shield
Two Weapon
Unarmed
Missile or Thrown Weapon
Weapon-Specific Styles

Under Two-handed weapon it says:

Spoiler

Two-handed Weapon
The largest and most damaging weapons available to PCs are usually two-handed
weapons. Obviously, a character with a two-handed weapon is not going to be able to use
a shield or a secondary weapon, but he does have a lot of offensive capability.
Many two-handed weapons are polearms and extended-range weapons that provide the
wielder with special tactical benefits in addition to their raw damage potential. Note that
a character doesn't have to use both hands just to hold a two-handed weapon; he can hang
on to it with one hand to free up the other for another activity, but he can't attack until he
gets both hands on the weapon again.
Size and Two-handed Weapons
Generally, a character can use a weapon equal to his own size in one hand, and a weapon
one size larger in two hands. For example, a halfling (size S) can use a short sword or
hand axe in one hand, since they're size S weapons, but if he used a broadsword (size M)
he'd have to use it two-handed, and there's no way he could use a longbow or halberd.

[there are also two additional but irrelevant subheadings]

Edited by Dakk, 11 April 2012 - 07:04 PM.

[phordicus]

Thanks. As expected, missile weapons are their own category. The mention of a longbow is just an example in a tangential paragraph about weapon sizes vis wielder size. The rules aren't implying anything about longbows being 2-handed, only large. On the contrary, the implication is that a halfling could take the 2-handed style and have it apply when he uses a broadsword, which for him has to be wielded with 2 hands.

Anyway, I'm being tremendously hypocritical by going off on this side issue. My apologies to Sasha and Asc64.

[Suslik]

Hey Asc64! I've done something like an investigation into weird kind of game stuttering. More info here: http://www.shsforums...the-stuttering/

It seems that a simple script block containing a check like this: Global("123456789012345678901234","GLOBAL",5) may start stuttering somewhere in the middle of gameplay. Loading previous savegame with almost the same condition does not stutter. Renaming the value to anything shorter will make the stuttering disappear while renaming to anything longer will still make the game stutter. More info is in that thread, read only the first post if you want the short version of what's going on.

Edited by Suslik, 12 April 2012 - 05:19 PM.

[Galactygon]

...we are talking about opcode-specific conditions which are not kept track in a list but rather are triggered when something specific happens. What I am thinking of is a set of external effects being applied (via externalized list), and then removed when something happens that prematurely purges the opcode.

Only effects in the game work via opcode. Most hard-coded changes bypass effects directly and simply directly change the internal structure in question. The problem with trying to conceptualise the entire engine with effect opcodes and stats is simplistic in view and limited in scope, because effects must follow certain rules of application/removal. What you are suggesting for an example of:

if (target.bIsInvisible && !source.bSeeInvisible) target.savingThrows += 4

is flawed and highly dangerous because the modification is available to every function. It is much more optimal and to use a copy of the savingThrows variable and directly adjust that within a single function.

We agree here on principle – I can only guess at the source code so my suggestions are off on the details.

int savingThrowsLocal = target.savingThrows;
if (target.bIsInvisible && !source.bSeeInvisible) savingThrowsLocal +=4;

There is not a chance externalising this effect will provide much return, because all I would let you do is to change the number 4 to something else.

I'm personally fine with the current -4 AC bonus and hadn't known it existed ingame before aVENGER mentioned it. The saving throw bonus against SEEINVISIBLE=0 for non-area effect projectiles is more of a fix to something the developers intended to do than a request. I am always in favour in externalising those numbers as much as possible in order to anticipate future mod requests, but my life is not in danger if it doesn't happen.

On the other hand I still haven't changed my stance of the effect-carrying request. This is essentially part of something I have been pushing for a time and will come up through various other requests from other modders: partially externalizing opcodes that can be purged via hardcoded conditions so that any extra effects are also purged via those hardcoded conditions.

[Galactygon-happy suggestion]
Maybe this might work: turning these prematurely-purgable opcodes (20, 218, 223, etc. , ) as kind of an opcode 177. The difference between these prematurely-purgable opcodes and 177 would be the following:
a. 177 has conditions in params 1&2 in order for the .eff to affect, while the .effs carried through prematurely-purgable opcodes do not (unless they have another 177 nested in the .eff, which is handled normally)
b. unlike 177, these .effs can be purged prematurely (depending on the parent opcode and circumstances) regardless of what opcode there is in the .eff file
c. along with the .eff file, the parent opcode has its normal hardcoded effects on the .cre

Because all of these hardcoded prematurely-purgable opcodes are non-cumulative it would be possible to have multiple instances of the same effect with different resource fields in the same header, making externalized .2da lists unnecessary and inefficient from the modder's perspective.
[/Galactygon-happy suggestion]

On the other hand, it should be feasable to externalize which headers use which charges, so that additional headers can use indexes other than 0, and items with multiple abilities can be tied to a single charge count (index 0). A problem with more than 3 abilities that wasn't mentioned is the GuI problem when you choose the item's abilities in the quickslot via the inventory. That would need a scroll bar. tooltip.2da is not limited to 3 entries, but I'm not 100% sure and needs some testing.

With this we can fix an oversight where wands should not be using seperate charge counts for the different abilities. (Note to Fixpackers: inserting additional blank headers at 1 and 2 should do this, but there still might be problems with the GuI).

I need to question the usefulness of such a 'fix' in relation its usefulness relatively to requests of broader scope. For example, the expansion of stats has a much larger potential than to make items with more than 3 abilities.

I have heard this mentioned more than once, so it's somewhat important but not as much as the expansion of stats or the stutter problem.

-Galactygon

[Ascension64]

We agree here on principle – I can only guess at the source code so my suggestions are off on the details.

I totally agree with the principle of externalisation and customisability. That is one of the main aims of TobEx. However, I need to consider what is practicable as well. Someone may as well make the source code available if you wanted to edit everything up to dotting i's and crossing t's.

On the other hand I still haven't changed my stance of the effect-carrying request. This is essentially part of something I have been pushing for a time and will come up through various other requests from other modders: partially externalizing opcodes that can be purged via hardcoded conditions so that any extra effects are also purged via those hardcoded conditions.

That is fine. It still sits on the to-do list. I need to nut down on the details of the implementation, though.

[Galactygon-happy suggestion]
Maybe this might work: turning these prematurely-purgable opcodes (20, 218, 223, etc. , ) as kind of an opcode 177. The difference between these prematurely-purgable opcodes and 177 would be the following:
a. 177 has conditions in params 1&2 in order for the .eff to affect, while the .effs carried through prematurely-purgable opcodes do not (unless they have another 177 nested in the .eff, which is handled normally)
b. unlike 177, these .effs can be purged prematurely (depending on the parent opcode and circumstances) regardless of what opcode there is in the .eff file
c. along with the .eff file, the parent opcode has its normal hardcoded effects on the .cre

Because all of these hardcoded prematurely-purgable opcodes are non-cumulative it would be possible to have multiple instances of the same effect with different resource fields in the same header, making externalized .2da lists unnecessary and inefficient from the modder's perspective.
[/Galactygon-happy suggestion]

Will take Galactygon-happy suggestion into account.

With this we can fix an oversight where wands should not be using seperate charge counts for the different abilities. (Note to Fixpackers: inserting additional blank headers at 1 and 2 should do this, but there still might be problems with the GuI).

I need to question the usefulness of such a 'fix' in relation its usefulness relatively to requests of broader scope. For example, the expansion of stats has a much larger potential than to make items with more than 3 abilities.

I have heard this mentioned more than once, so it's somewhat important but not as much as the expansion of stats or the stutter problem.

Yep, my list is still so long I have to triage everything. I'm working on requests more than a year old at the moment.

[Suslik]

Asc64, please do take a look at my thread. Everyone finds it extremely hard to understand what the hell I am talking about except for you =(

Just take into consideration the possibility that GetGlobal under certain circumstances may start executing like 100(probably more, I do not know) times slower with variable names longer than 23 characters(or so). It can be disastrous!

I need just approval of what I'm doing is right and that my methods are acceptable, because it looks like people only tend to blame tons of mods/buggy scripts instead of the way these scripts are executed =(

If you don't have time/unwilling to investigate the problem on your own, would you kindly give me some basic procedure call addresses so that I can try to reverse the thing myself?

I have summarized everything in the first post:
http://www.shsforums...post__p__539311

Edited by Suslik, 13 April 2012 - 05:26 PM.

[Galactygon]

That is fine. It still sits on the to-do list. I need to nut down on the details of the implementation, though.

Will take Galactygon-happy suggestion into account.

Yep, my list is still so long I have to triage everything. I'm working on requests more than a year old at the moment.

Thanks very much.

-Galactygon

[Sasha Al'Therin]

I know you did some work regarding bags of holding already. Not sure tho if it touched on this. Reading the thread didn't shed much light.

See here for details on the problem.
http://forums.gibber...showtopic=24300

Short version is this:
item in container & item in inventory.
if on the same player only the inventory item is taken.
if on different players and the container is read first then both the 1st item in a container AND the 1st inventory item is taken.

TakePartyItem() needs to properly terminate if an item is found in a container of an earlier party member and there is still a copy of the item in other party members' inventories. Or it needs to wait to search containers until after ALL party members' inventories have been searched.

[Suslik]

I have a request regarding currently playing background music:

It seems that regular game music occasionally starts every few seconds or under other circumstances I do not know. The thing is, when the game is saved, music is interrupted and after save process is complete, it does not continue playing, waiting for the same trigger to fire again. Will it be difficult to continue playing the same track after the save process is done?

It also affects soundtracks triggered by dialogs which stop when the game is saved. It makes suslik sad : (

Edited by Suslik, 20 April 2012 - 01:02 PM.

[Ascension64]

I don't plan on touching the music system any longer due to the changes that BG:EE will be making.

[Galactygon]

I wonder to what extent BGEE will include ToBEx and to what degree will the source code change so that you don't have to restart from scratch.

-Galactygon

Edited by Galactygon, 21 April 2012 - 10:50 AM.

[phordicus]

I don't plan on touching the music system any longer due to the changes that BG:EE will be making.

And the schism begins?

[edit] Meant for that to be a question!

Edited by phordicus, 23 April 2012 - 03:55 AM.

[Sasha Al'Therin]

How about looking into how fonts are controlled?

in baldur.ini there is a line

Font Name=

If you put the name of a font that is on your system, ALL game text will be changed to that font. However, the game lags noticeably every time a large amount of text needs to be converted.

What I'm hoping for is that you could determine if there is a font size control switch that could be enabled so that
Font Size=
would allow for increasing/decreasing the base font or assigned font. It would make life so much easier for those who use widescreen mod as there isn't really any decent font mod that can cover a wide range of sizes

[Sam.]

How about looking into how fonts are controlled?

in baldur.ini there is a line

Font Name=

If you put the name of a font that is on your system, ALL game text will be changed to that font. However, the game lags noticeably every time a large amount of text needs to be converted.

What I'm hoping for is that you could determine if there is a font size control switch that could be enabled so that
Font Size=
would allow for increasing/decreasing the base font or assigned font. It would make life so much easier for those who use widescreen mod as there isn't really any decent font mod that can cover a wide range of sizes

In addition to Font Name, I think there is also:

[Program Options]
F NORMAL [=NORMAL]
F REALMS [=REALMS]
F STONEBIG [=STONEBIG]
F STONESML [=STONESML]
F TOOLFONT [=TOOLFONT]
F FLOATTXT [=FLOATTXT]

but I have never tested them to see if they work (default values are in [] ). Has anyone else? There are also:

[Program Options]
Double Byte Character Support
Drop Capitals

which relate to fonts, but I've never seen anything (even disabled) that controls font size.