spyderbytes

About the only way I can think to do it that would even come close to being easy is to replace the graphic for either horses or boats... but then you have an unsupported hack with the same old transportation that just has a different picture pasted on it. You could probably "fake" it fairly easily by asking the player for a destination, putting up a dialog describing the trip, and then just moving the party to the new town. You'd essentially have no outdoors whatsoever, though, that way (assuming players can use your transportation anytime they please). Off the top of my head, I really can't think of a good way to fake a full-fledged transportation mode in BoA. I'll give it some more thought, though... -spyderbytes

They covered the obvious, but if you want to make SURE whether your state 10 is ever being called or not, you can always put something like: message_dialog("Yep, it's being called...", ""); as the first line of the state. If you don't see the dialog, it's not making it to your script. -spyderbytes

Assuming I'm understanding the intended implementation, yes, that should be possible (if somewhat "messy")... the caveat that springs to mind being that you'll eat up your available dialog nodes very quickly if you do too much of that. Used sparingly, however, I think it could be quite effective. -spyderbytes

Agreed, Drakefyre. It's not that there are that many times I end up iterating the group (mostly when I'm just being fiddly about where they are for a cutscene and such--in a neat little row starting from a particular loc). I probably wouldn't have discovered this at all if I hadn't been working on a, well, I guess you'd call it a trap, that has some rather, well, I guess you'd call it odd, behavior. I was testing what happens if players are both stupid and unlucky, and all but one of the characters ended up dying... before the trap was going through a final iteration to turn the thumbscrews a bit more. I'm toning the worst case down a tad... -spyderbytes

I may well just not be thinking of something, but I don't really see how the current behavior of party_size() would be more advantageous than the behavior I expected (that is, seems better to me to know total size of party, not just learn how many are alive and kicking). Not that we're talking a massive number of cycles either way, but I would think a single call to a party_size() (or equivalent that returned what I expected) would certainly incur less overhead than the unnecessary iterations through a loop (which is why I was querying party_size() in the first place ). -spyderbytes

The docs for party_size() simply say "Returns the number of characters in the party." Based on that, and since I can't really be sure of how big a party was brought into my scenario, I've taken to doing something like this: Code: short i,max;...max = party_size();i = 0;while (i < max) { if (char_ok(i) == TRUE) { // do something with PC here } i = i + 1;} However, say you have a 4-character party, but all of them except, say, character 2 is dead. In that case, party_size() returns 1 (when I expected 4, based on the docs). So my loop runs through once, with character 0, who is dead, and nothing happens. I suppose it's easy enough to work around by always doing: Code: i = 0;while (i < 6) { if (char_ok(i) == TRUE) { // do stuff here } i = i + 1;} (Or at least I'm presuming char_ok() will return FALSE on a non-existant character... anyone know for sure?) -spyderbytes EDIT: typo in 2nd code block

Jeff has said he'll be adding some more advanced string management utility (see this thread ). That won't address pronouns, but they can often be sidestepped (even if grammatically uncorrect) with 'them'. If that's too awkward, you could always ask the player for genders at the beginning of the scenario and stuff them into SDFs. I think it's unlikely we'll see changes to character management. That being the case, I personally think your option A, Octavo, is the best approach, especially now that we will soon be able to single party members out by name. And yes, I think your original post covers the available options quite well, unless there's something else I just haven't thought of yet. -spyderbytes

As we say here in the South *clears throat*, YEEEEEEEEEHAWWWW! I'm especially looking forward to the string manipulation calls. In addition to the intended purpose, I've wished for the capability append_number() will give to simplify debugging. And I think I've made my views on the need for append_char_name() clear already. -spyderybtes

Just off the top of my head... the first thing I'd probably try is to call set_terrain() from the creature's DEAD_STATE to draw a normal wall where it was (if I'm understanding what you're doing). I'm almost positive DEAD_STATE is called (just) before the dead creature disappears. -spyderbytes

Hmmm.... I'll do some more checking on my end to make sure there's not just some stupid error lurking in my code. But I can tell you this: if I comment out the te_special_property = 40; // container line in the definition of the original terrain, my code behaves exactly the way I want (except my item is not contained, of course ). When I uncomment it, the party can't move into the square after the set_terrain() call. -spyderbytes EDIT: Harrumph! I decided to try it in 1.0 to see if that made a difference, and lo and behold!, it worked as it should with the original terrain being a container. So I figure, OK, it just got broken somehow in 1.0.1. But then I go back to verify in 1.0.1, and it's working THERE now. I haven't changed a line of code since it didn't work, I posted here (after hours of isolating it), then switching to 1.0 and back to 1.0.1. Go figure...

This is a bit complicated to explain, so bear with me. I've created a custom terrain that's a "container" (in that it hides something else in its location). To simplify things (and keep from giving away too much of my plot), let's say that the very act of searching this container destroys it and turns it into a different type of (non-container) terrain. If I simplify this a bit more and make the original terrain NOT a container, I can get the basic behavior I want: I can block the party from entering the square until after they search it, then call set_terrain to swap to what I want there after the container is gone. After that, the party can freely walk through the space (as long as my terrain script says they can). However, as soon as I make the original terrain a container, the party can't enter the square after the set_terrain call replaces it with a non-container, even if the script explicitly calls block_entry(0) to let them. IOW, once you place a container in a square, that square is apparently blocked to entry by the party forever and eternity after that, even if you change the terrain on the square to NOT a container and specifically grant access to the square in a script. I can script around it (by leaving the original terrain not a container and just putting the item I wanted it to contain in inventory when the party searches the square), but it doesn't seem like correct behavior, to me. -spyderbytes

Quote: Originally written by Thuryl: ...but I'd argue that allowing you to keep using your PC's old name only encourages you to keep identifying with the PC that you've always used... One final point, and then I really will hush and work on my own scenario (which I've been avoiding because I haven't come up with a good enough puzzle for the spot I'm at ): That's not generally what I do, especially if there's an easy way to get a new character to the recommended level (as in the built-in character editor in BoA ). I create a brand-spanking new character/party that, from what I know (based on reading the designer's description and Read Me), fits into the scenario's premise. I just want to be able to choose name, race and gender when I do. As a player, that doesn't seem too much to ask for my end of the contract of trusting you, as a designer, to provide me with adequate enjoyment for the hours' of attention I give your scenario. -spyderbytes

i*, I, personally, certainly wouldn't have any problem with the designer telling me I need to play with a single PC and not a party, and that it shouldn't be a healer. I already conceded that class restrictions can be valid, and I can see party size as a valid restriction as well. Those things affect the scenario's balance. However, from there, my argument is that you should let ME pick my name, race and gender, which are things that won't mess with your carefully balanced scenario in the least. Don't have your NPCs call me Fred (or whatever) just because you supplied a character named Fred I can play the scenario with. That'll just tick me off and make me stop playing, when I might be thoroughly enjoying the scenario playing it with my Xena (or whatever). -spyderbytes

Quote: Originally written by Imban: The romantic parts of Quintessence are unusual and trippy enough without having to be homosexual as well. EDIT : Generally, the strongest scenarios plot-wise make SOME assumptions about the party. For example, the leader of the party in Redemption has a brother who was McNemier's apprentice. So flip the gender of the party member's romantic interest--what have you really lost? I realize JV hasn't given us tools to determine gender of any of the PCs, but you could always just pop up a dialog asking the player if they want a male or female love interest. Much more work for the designer, but you broaden your (potential, anyway) playerbase. I don't know who McNemier is, but couldn't anyone, of any race, gender or with any name, have a brother who was his assistant? Or are you saying the brother was part of the PC party? And if so, couldn't it as easily have been a sister if the designer had set it up that way? As far as the engine is concerned, name, race and gender are completely irrelevant. If your scenario arbitrarily makes them NOT irrelevant, all you've really accomplished (as far as I can see) is alienating a portion of your playerbase. Anyawy... 'nuff sed (by me at least) on this subject. -spyderbytes EDIT: Thuryl, I don't universally turn down scenarios that give me a starting character I need to use... if they character is interesting enough for me to want to roleplay. I just find that I can generally come up with a more interesting PC (to me, at least) then pre-supplied ones. And I don't have any problem with relationships/family or forced situations... you'd be awfully hard-pressed to design an RPG/scenario without them. You have to have backstory, or moving forward becomes pointless. I just want to be able to "personalize" my character by choosing my own race, name, gender and toon. That doesn't seem to me to be too much to ask, considering the tools to let me are already in the engine.

Thuryl, you're coming close to putting words in my mouth with your first paragraph. You'll find I'm not one noted for beating around bushes. There's no moral issue about it. The point is simply that a designer limits his/her playerbase (I think more than you might realize) by making a scenario that insists on referring to a female PC as "he" or vice versa (as an example, though extend that at least as far as race and name as well). I've never played BoE, so enlighten me... in what way would the scenarios you refer to have really suffered if the main PC(s) had been male if they were female, or vice versa? Or if the designer had made them slith instead of human, or simply changed their names? If they depended that much on such incidentals, it would seem to me they depended entirely too much on stereotyping in place of "real" story development. Though as I said, I haven't played them, so I could be wrong. I can see where the odd scenario might, with validity, depend on the class of a character (though certainly not as the norm); but not name, race or gender. And for the record, I do pass by almost any RPG/scenario/whatever that doesn't offer me choices as to what my PC will be. You might consider that "my loss", but I consider it my preservation of actually enjoying the time I spend playing them. -spyderbytes

*sigh!* I should keep my mouth shut. I know I should. But having taken up a crusade against designers arbitrarily limiting player initiative, I find I can't. The issue I'm talking about is not cheating by bringing in a more powerful party than the one supplied--it's just bringing in a DIFFERENT party than the one supplied. I might (for example) just prefer to look at four female avatars for the hours I'll be playing your scenario, rather than the four male ones you provided. I might be xenophobic and refuse to play any non-human characters (or vice versa). I might have deep-seated psychological reasons for it, or I might just think they're prettier graphics. It doesn't really matter one whit WHY, it just matters that the designer arbitrarily limited my ability to do that when s/he has the NPCs blindly assume that the party is exactly the provided party. You don't think it matters? Look at the boards of any RPG that only allows certain genders or races to be particular classes. You'll see plenty of complaints about it, I assure you. People play RPGs to develop their OWN characters, in large part. A game, to me, should be a cooperative effort between a designer and his/her players. That means, to me, at least, giving the players as much initiative as I can within the limitations of the engine. JV's engine doesn't place any limits on the player's race or gender, so I find a scenario that won't let me choose those as I please unacceptable, as a player. I wouldn't at all mind a scenario that PENALIZES me for being a particular race (if the penalty was integral to the story--say people in these towns discrimate against humans or sliths or whatever as the scenario's main plot element). But I DO mind a scenario that won't play correctly if I choose to be a different race or gender (or even just have a different name!) than what the designer arbitrarily decided I should be saddled with. And I totally fail to see how it could be "my loss" to refuse to play a scenario that I wouldn't find entertaining because it has so boxed me in that I have no initiative remaining. If I want a story "told" to me, I'll watch a movie or read a book. I don't have to interrupt my "couch potato-ism" to click buttons, that way. I play RPGs to cooperate with the designer in forming a story. Sure, when it comes right down to it, I might have very little input in determining the ultimate outcome of the story; but a talented designer can make me FEEL I'm having an impact on the unfolding storyline. But not by taking away my ability to choose such details as even my race, gender and name. -spyderbytes

Premade parties don't completely address the issue here. First off, no one HAS to use the party you supply. They're perfectly free to play the scenario with any party of their choosing. Even if they DO use a party you supply, it might not REALLY be the premade party. Players can change PC names and graphics at any point, making your burly male named Fred a lithe female named Wilma, for example. So your NPCs can't really assume the party will have the names/genders your provided. Sure, you can warn against doing that in the Read Me, but you're going to lose some players who happen to hate, for one reason or another, the makeup of your premade party--or just happen to hate not having the ability to customize the characters to their liking. After all, that ability to make the PCs "yours" is a big part of the draw of RPGs in the first place... -spyderbytes

DBSM? -spyderbytes

New "standardized" calls COULD be added while still leaving the current ones for backwards compatibility. That said, yeah, I guess I'd have to say I find the inconsistencies mildly irritating. But fixing them is nowhere near the top of the list I would personally make for Jeff's priorities. -spyderbytes

Give Morgan a cigar... calling move_to_new_town() with arguments of the party's current town and location does indeed reset the group to be hidden again. If I'm understanding you, Eldiran, that's irrelevant in my case. I activate the hidden group to participate in a cutscene when the party first enters the town. Once the cutscene is over, I want them hidden unless/until the town turns hostile (why I hid them in the first place ). The number of guards needs to be "beefier" than what the player sees just wandering around (i.e., making this town hostile will be a BIG mistake ). -spyderbytes

Not really a call, but... I'd like to see some sort of token we could put in strings that would expand to a given party member's name. E.g., something like %char0% would expand to whatever name the player gave the first character in the party. -spyderbytes

Exactly what I hoped to avoid. Although erase_char on the first group coupled with a second hidden group (same creatures, just different group number) might not be TOO bad, I guess... Thanks, anyway. -spyderbytes

Once you've activated a hidden group (with activate_hidden_group()), is there any way to make the group hidden again (short of the party leaving town and returning, of course)? -spyderbytes

Quote: Originally written by Eldiran: Maybe you can use "set_state_continue" to go to another state and then use the call. That didn't work, at least for EXIT_STATE (the only one I tried). The way it behaves, I'm guessing the party has already left the town (as far as the engine is concerned) before EXIT_STATE is called. EDIT: I meant to add that START_STATE is called every turn the party is in the town. INIT_STATE is the one called when the party enters the town. So, no, a move_to_new_town() in START_STATE wouldn't be equivalent to variable town entry. -spyderbytes

Quote: Originally written by Isaac: Why not use a variable? They last as long as you stay in the town, and can hold values up to 32767. DOH! That's what I get for trying to figure something out when I'm still up at 6:00 am. Yeah, that WOULD be the obvious solution, now, wouldn't it? -spyderbytes