temnix

I've run into a very inconvenient property of MYAREA-scope variables, in area scripts. Unlike in creature scripts, where MYAREA refers to the particular place the creature is, like the second floor of "Jovial Juggler," changes to MYAREA variables in area scripts of master areas don't apply to slave (local) areas. For example, if you put SetGlobal("VAR","MYAREA",1) in the main script of Beregost, it is not going to be set for streets and inns. Instead one has to write ActionOverride(Currently-Active-Character,SetGlobal("VAR","MYAREA",1)). This doesn't make much difference if globals need to be only set-unset, it just takes more code to override the action of every party member, in whichever corner they may happen to be, in addition to the impersonal global-setting for the main script. Even then it only covers the areas they are in. If they visit a new house and nobody stays behind on the street to keep the master area active, VAR won't be there. Still, it could be manageable. But if you need to increment MYAREA, this becomes a problem, because the results are going to depend on whether the active characters are on the streets or somewhere inside at the moment the variable changes. In a solo game, where just one character's position needs to be accounted for, code ActionOverride(Player1,IncrementGlobal("VAR","MYAREA",1)) IncrementGlobal("VAR","MYAREA",1)) increases VAR by 1 point for the slave area (only this room or floor) and 1 point for the main area if triggered inside, so if the original value was equal, it still be, but by 2 points for the main area and by zero for any slave area if triggered outside. Suggestions of alternatives are welcome.

Because a class has a certain nature. Rangers are virtuous protectors of the wilderness, just like paladins are virtuous protectors of civilization. Ergo, it is a special kind of ranger who is evil. Or was that a trick question?

Yes, only for EE. There are just too many effects and actions that don't exist in the old game. But, as I've been saying, if you are unhappy with something in EE that is not hard-coded, make a mod and change it. Or poke these other people to. As for this kit, I don't think I'll make it. But anybody can do it. The idea was only to have an evil ranger, so the change would be simple: take the old ranger and restrict to evil alignments. It's not necessary to give him any unique abilities, but a couple of smaller ones could do. Maybe set traps like a thief, maybe poison on ranged attacks. I think "cateran" would be a nice name. That's a Scottish word for highwayman. "Marauder" is another possibility, but "cateran" has got more style. For my next mod I could actually use an evil ranger, but to venture into a whole new field - no.

I mean that creatures produced by spells aren't necessary of the SUMMONED gender, only the default spells use this. I've made some myself that brought out ILLUSIONARY creatures, for example. And besides, as I said, I don't know if Die() has to be on top in every script where it's present. Some of those minions may remove themselves with flash and bang or leave no bodies. Actually, I should experiment with Die() down the line. If I works, I can patch them.

Oh, I see how it is: !CheckSpellState(Player1,SHAMANIC_DANCE) !CheckSpellState(Player2,SHAMANIC_DANCE) !CheckSpellState(Player3,SHAMANIC_DANCE) !CheckSpellState(Player4,SHAMANIC_DANCE) !CheckSpellState(Player5,SHAMANIC_DANCE) !CheckSpellState(Player6,SHAMANIC_DANCE) THEN Technically this means that one shaman doing the dance would be enough to maintain spirits for the whole party. All right. Well, if somebody with an old-fashioned Shadows of Amn, not Beamdog's version, can tell me the names of scripts of minions for spells like Monster Summoning, Conjure Elemental and so on, I can make a small mod to tie them to LastSummonerOf. This would make them disappear at the summoner's death or at reload. Should add challenge for the party side, too. I could also patch SUMMONED blindly, extend the script in OVERRIDE, but shouldn't Die() be on top? And if I put code on the bottom, the script may never get there.

I have a lot of scripts on hand with numerous OR conditions, as thick as bad cholesterol in arteries after a lifetime of butter and margarine. I'd like to make them go faster, if possible. For example, does putting Player1's variable on top make the engine skip the rest of the conditions? OR(9565) TriggerOverride(Player1,Global("VAR","LOCALS",1)) ... Does this make it faster, as opposed to putting Player1 at the end somewhere? Anything else that can be done?

I must have mixed this up with memories of Diablo. Fallen shamans resurrecting the dead all the time, going for them first... But then why do in these games shamans' spirit animals disappear when the shaman moves? I don't know if they do when the shaman dies, but they vanish when he takes off, and how is that achieved? I don't see anything special in their scripts. Not to that effect.

Can they be set with a spell?

I seem to remember that minions would vanish when the summoner was killed. It was the best way of getting rid of them - to go for the source. I couldn't have just imagined it... Is there a setting that controls this? Because I can't seem to reproduce it. I mean, it's possible to put a condition specially in scripts to check for non-aliveness of LastSummonerOf, but this anchor slips off after the game is reloaded. They forget.

I hope so. Thanks anyway.

Okay, this is for a different script, but I get an "empty token error" now. By the way, Ardanis, your code suggestion here - are you sure the \s are in the right place? Shouldn't it be \[GOODCUTOFF]\ ? Anyhow, the error I get is in this: COPY_EXISTING ~SHOUT.BCS~ ~override~ DECOMPILE_AND_PATCH BEGIN REPLACE_TEXTUALLY ~Heard(\[NOTEVIL\],99)~ <<< ~Heard(\[NOTEVIL\],99) Detect(LastHeardBy)~ REPLACE_TEXTUALLY ~Heard(\[NOTGOOD\],99)~ ~Heard(\[NOTGOOD\],99) Detect(LastHeardBy)~ END BUT_ONLY

Is there anything known about the mechanics of this, besides the price in the 2DA file? What makes Reputation change? Any way to detect the change?

I think there are quite a few things objectionable objectively, if you respect yourself anyway, about Beamdog's implementation. Even if you like all of the changes in mechanics and accept glitches that are unavoidable, there is still too much, if you respect yourself anyway, hand-holding and "streamlining." Sprite outlines and health bars, which are on by default, are a crime. There is no way to become immersed in a fantasy world when it's presented as a real-time strategy, almost, or at any rate a wargame. How is anyone going to treat this is as a role-playing game and want or expect role-playing mods for it? And people actually play with those on! The fat selection circles are another of those additions. Appearance is very important, we just take it for granted when it's fine and finely done. Plus all those incessant pointers for the very stupid: in BGEE the Friendly Arm inn revealed on the map from the beginning (clearly the big sign at the crossroads "Friendly Arm Inn to the North" together with a couple of express pointers in dialogues before then might still leave some confused), the message upon entering the bandit camp that evidence must be in biggest tent... really? And the ankheg armor can be made in one day with extra money. Just some of those things that are cringeworthy. Beamdog caters to the feckless, attention-deficit crowd it helps perpetuate. Although in all fairness, not all of Beamdog's changes may be for the worse, the bottom line is that none of them strike me as important, and together they strike me as weakening the original gameplay. They can be tolerated, but not comfortably. However, the engine is by and large a serious improvement, even with its hard-coded parts. This is why I called on the "veterans" to stop churning out tweaks and schromances and badger companions and make a reboot of the game that could be offered to new players, not yet spoiled by the "new normal" of Beamdog's standard. And these "veterans" know their stuff, as far as these little mechanics are concerned. They know by how many points kensai have been nerfed or Sleep's save changed or whatever. So, being the good dwarves creatively that they are, they could - hey ho, hey ho - start digging. At least that. They could work it out between them. Because if somebody fresh comes to these boards, or Beamdog's forum, or Spellhold right now looking for interesting additions to the games, they will either leave very disappointed or lower their expectations fatally and become terminally happy. I failed to move them, of course. But maybe a sudden ignition will occur in their guts some time later, a burst of motivation which they will attribute to their own genius.

The system for changing Reputation will be different, it's already done. This is about taking stock of Reputation. The area global is one thing, and the game-wide global is another. It's also necessary, otherwise no one at the Nashkel Carnival would ever know that the party has wiped out Nashkel itself. Both need to be set and tracked (I hate that word). The global value is going to affect the local reputation with a delay. Fallout had an enviable system, with Karma but also reputation in every town. I think Torment has this too, in faction reactions. A town would simply be one faction. But for BGs and Icewind Dale nothing like this naturally exists, a lot of scripting has to be mounted instead.

Continue() works perfectly at the end of an addition, there are no problems or glitches with it. But I still would like to avoid stuffing BALDUR so much. The constant checking here is to keep track of Reputation. Every master area will have a separate Reputation value, recorded in a global and restored from it when the party returns from a different area. But there will also be an overall Reputation global to follow the party around everywhere, catching up with a delay for new areas. At least that's the idea. I'm still thinking about the mechanism, but either way Reputation has to be tracked all the time, because it's not going to be a fixed value anymore. The concession to making the check once every three rounds with a minion is already a bit of a stretch - the characters may rush out of an area after killing someone, and the global won't be set to reflect this. About the frame rate I can say that a fast computer may not speed up the gameplay, I wouldn't know, but a slow computer can definitely bog it down. Switching between screens, numerous creatures running scripts, special effects, all of them have an effect.

I'm thinking of adding quite a large chunk of code to BALDUR.BCS for my next mod. It's unusual for me, but this kind of checking and variable-setting needs to be done on a constant basis. I could put the code in area scripts instead, but that's probably not much different in terms of impact on performance. Or is it? In any event, in place of both of those I might only put a self-resetting timer in BALDUR, to cast a custom spell on the party, say, every 3 rounds, which would summon an invisible minion who would take account of the changes in statistics, adjust variables and disappear. This makes me wonder, though: are creature scripts run in parallel with BALDUR, or are the same resources distributed between actions in creature scripts and engine-level scripts? Doing the check all the time with a minion has a couple of drawbacks and it is only worthwhile if it frees up whatever attention span the engine dedicates to BALDUR.

Finally a real contribution. Almost a plan. Not that those who keep posting in my thread will move their mossy butts to put together something like that. I can point out, though, that ignoring EE NPC is easy enough, though Neera and Dorn are introduced in ways that are too pushy. And in truth they aren't bad NPC, maybe a little overwrought. I have an idea about better places to put them where they don't intrude, but it's another of those things the hoary old-timers here would be better suited for. Ah, to hell with them. But if you don't use the EE engine, you are missing out on potentially great mods that the old technology just can't support.

Okay, I'm not going to go ahead with implementing, but I will leave the idea up for grabs: I thought of patching all triggers of the Travel type with a script; here there is another problem, that they may already have a script, some way of extending to it instead would have to be devised; assuming that can be managed, this script addition would make the trigger start shouting when a global was set or when it, the trigger, itself heard a shout. It'd be better to allow both. This way from the area script the global could be set or from within a conversation a shout sent, followed by SmallWait(3) ActionOverride(Player1,MoveToObject(LastHeardBy)) ActionOverride(Player1,LeaveAreaLUA("AR1234","",[X.Y],Z). The number shouted by the triggers in response doesn't matter, the point is simply to get party members to tune in to the shouter (a short interval is required for party members to process the shout). The same commands would be given to the rest of the party after Player1, making them walk towards the trigger first and only then disappear into another area, because this is how commands given after MoveToObject are followed - they are delayed until arrival. This I know. The problem that I wanted to circumvent this way is that triggers can't be represented by objects in scripts, so it's impossible to tell a character to go to the nearest trigger, especially if it must be a travel trigger and not, say, a trap or an info box. Even Doors aren't present in every area: NearestDoor may fail even when there is, in fact, a door object in the area. This system would have to be universal to be really useful, covering all games and mods, so going by the names of the triggers themselves, "Door4845" and so on, is not an option. Triggers need to shout to be noticed or, if regions can't shout, which is also possible, their scripts need to spawn, OnCreation(), invisible minions to serve as objects the party can approach. This is not such a complicated system, and if all travel triggers could be patched one way or the other, it would be possible to send characters to areas of choice in a natural way, by walking towards entrances, easily. But it's complicated to write the code for. I'm going to leave it to those who want to sit down at Weidu. And jastey, I didn't mean to hijack the thread. I thought this was a good place to ask. I'm done here.

How do I unsubscribe from this thread or get you people to stop gabbing? I'm sick of getting notifications that one of you had another brilliant snippet to contribute.

I have a related problem: patching triggers. Just like containers, they have no fixed offset. Actors come before them, so their position in AREs shifts all the time. But even worse than containers, they can't be patched by their number, only by their particular name, and I'm looking for a way to patch all of them in all areas - assign a script to them, specifically. Actually, extend that script, if there is one, which is a separate problem. Anybody has suggestions?

I took an area, copied its tileset, map files and everything else, except that I did a some re-drawing in the area center. Compiling all this into a PVRZ-based TIS, however, I saw that water was not being drawn correctly. Does anybody know the reason?

I'm looking for an action that will enable a party member to walk naturally towards a point without leaving the party, disappear and reappear in another area. I have sorted through a few options; for example, EscapeAreaMove will take the character out of the party, and for Player1 that means Game Over. LeaveAreaLUAEntry(S:Area*,S:Entry*,P:Point*,I:Face*Dir) is the action I'm looking at now, but I can't figure out how it is supposed to work. I added the current area, a point in it, to ENTRIES.2Da, and I use "ENTRY1" as the point name to go by, and I run this action from a creature script, as the G3 guide says, but the character only strains in his constipated way. If this action can be made to work, it is a way, in principle, to travel naturally between areas. All of the normal areas have at least one entrance, this entrance's coordinates could be stored in variables together with the area's name, and a point added to the 2DA, automatically for all areas. Nobody says a point for this action can't be on top of existing entrances. But then, if this action only works in a creature script, it's not too useful. Maybe the "Panic" version of this action can be used from the outside? It also only causes creatures to strain, however, even in an area listed in ENTRIES.2DA from the beginning, one where this action should work, if at all. I suspect that ENTRIES.2DA in BGEE is really for the sequel, but still, why doesn't a custom point respond? Does anybody understand this action? I'm not hell-bent on it, but I would like to be able to move the party to places by walking instead of mysterious teleports.

But clones can use items, just not take them off. Anyway, in the absence of a way to prevent dropping, I had to invite others to pick up the stuff.

I don't think you understand how this engine works yourself, Imp. You may happen to be right, but you are no expert. I can imagine different ways these sprites could be drawn to produce what we see, for example, a separate mechanism that pulls character sprites on top of area stacks. This could be so, though I may happen to be wrong. But don't pretend to know for certain what you don't.

I have strayed into area editing, and it occurs to me there should be a better way of drawing water - pools, rivers, troughs, fountains and so on. Area overlays are stacked like a pie: the lowest layer is the one with the ground, buildings, trees and so on. If the area has some bodies of water, the corresponding spots on this layer are made lighter - this is the way BG, at least, goes about representing transparency of water. Over this layer goes the water layer, or layers if the water should look different in different places and different tilesets should be drawn from. These water layers only have a few titles, and those titles contain only the water shapes corresponding to the places left for them in the basic layer. The whole system is like rolling out a sheet of fabric with some spots marked out in chalk, then putting exact patches of fabric of another color on top - a collage, basically. This seems like an enormous pain in the butt. Every little water hole has to be cut with a jigsaw. Why not make the ground layer the top layer instead, in the manner of a paint mask? Leave the basin spots unfilled - make them holes in the layer. Is this possible? Can a layer have holes? One of the colors made transparent, possibly? If so, whole water layers could be put beneath the ground, without bothering with shapes. Water would be visible wherever holes in the top layer were made.