spyderbytes

Apparently so. When I start a new scenario (in Editor 1.0.1), it says 49 and 20, respectively, for the scenario name and filename lengths.

The docs say script names can only be a maximum of 13 characters (not counting the .txt) long. 'hellholeravinedata' is 18 characters. 'hellholeravine' is 14.

And yes, I realize the editor says your scenario filename can be up to 20 characters, in the dialog when you first create it, but I'd bet that your filenames are just too long.

Hehe... I'm a dyslexic reader I guess. I read that as "in one line" instead of "in line one".

Yeah, I didn't copy that part, so I imagine you nailed it: scenario data files probably can't have comments before the beginscendatascript; line (mine doesn't, anyway). Try removing that and see what happens.

Hmm... not a clue. I copied and pasted those lines from your post into my own scenario data file, and it worked just fine (except for the obvious problem of not having graphics with the numbers you gave yours).

Does it give you a line number where it says it's going haywire?

I thought about that, but decided it would actually be more work to track who was dead/alive and what the party had already done in town (so the towns matched except one flooded and one dry) than swapping out some 3 dozen floors.

EDIT: Yes, Daravon, that would work. In this case, however, I would have ended up with almost as many custom floors (considering the edges of the water change significantly) as just a string of set_floor() calls.

Custom items are defined in the INIT_STATE of the main scenario script. They don't have their own separate scripts. Even if they have scripted behavior (i.e., abilities 207 or 208), it's just handled from a state in the scenario script.

Actually, I suppose the main reason I might not have the memory problems is that I'm on OS X (which allocates memory much differently) and have a boatload of physical RAM. If the editor needs more, it just asks the OS and gets it dynamically.

EDIT: My original answer was just plain wrong. Look in the data script (scenario_namedata.txt) for definitions of custom items.

As long as we're dreaming here...

I'd like to have a call that re-inits all floors/terrains to their default state (as set in the editor). I just made a town with a dam, and it's MUCH different depending on whether the floodgates are opened or closed (about 3 dozen squares change--coulda been much worse, I guess, if I hadn't planned so carefully ).

Going through all those squares and saying what they change to when the puzzle is solved was a pain, but understandably necessary. Going BACK through and saying, essentially, "now put it all back like it was when the party entered", in case they decide to undo what they did, seemed like more work than was really required.

No, I can't say I've seen that error... but then, I don't leave the game running (I've almost always got the editor running in the background when the game's going; but I quit out of the game before making changes in the editor).

it_inventory_icon should be a number between 0 and 9, indicating the position within the sheet of the icon to use (each sheet contains 10 icons).

Thanks, y'all. Some good ideas.

Despite it's importance (or actually, because of it--it would become overpowering), the party can only use this item 3 times, and only in a particular city. So the outdoors bit is not a problem.

Hmm... water should definitely do the trick. I had to create a water tile the party COULD walk on to use... well, it's hard to explain and doesn't really matter. I just had to do it.

You are exiting the town and coming back to test, aren't you? I've found you definitely have to do that if you're changing the blocked/not blocked status of terrains/floors. Even then, I've had some seem stubborn about changing for me. I'm not sure, but it might be another of those things that gets set only the very first time you enter a city.

According to JV, when I asked essentially the same question, items are only placed the very first time you ever enter the town in the scenario. So you have to go back to a save before you ever entered that particular town if you want them to show up.

Major PITA for someone like me who likes to add stuff as I need it, rather than all at once, but there you go...

I doubt there's the slightest chance of actualy getting this one, but you never know unless you ask.

I'd like a pair of calls to add/remove our own custom icon as a character status (like drunk, invulnerable, etc., now). I've got a custom status that's vitally important to my scenario, a custom item that grants it, and have gone to tons of trouble to script its effect. And I don't even have a convenient way to let the player know when it's in effect and when it wears off.

Right now, I'm using a sledgehammer to get the job done (a pair of message_dialog()s for start and end); but a simple status icon would be so much nicer.

Ok, I think I figured it out. And if this is the case, this really needs to be mentioned in the docs somewhere, it seems to me.

In order for the player to be able to look at a terrain, it must BOTH be marked te_can_look_at AND have a terrain script on the space (even if it does nothing). Is that correct?

I actually intended to put a script on this particular terrain anyway (but just hadn't gotten around to it yet). But there are times when it seems it would be good to let a player "look" at something they can't really interact with, just to find out "what the heck is that thing, anyway?".

Can you not make a terrain that uses a second icon (double tall) look-at-able? That's the only reason I can figure out for the "there's nothing unusual to look at" message, even though I used te_can_look_at = 1 in the definition.

If that's the case, is that going to be considered correct behavior, or is it a bug?

For posting them on the web, GIF will work, as will PNG as well. Any format that's "lossless" (and JPG is "lossy") is fine. For use in your scenario, yes, they will have to be BMP (on Windows) or PICT resources (on Mac).

Yeah, messaging was one thing I had thought about, but by all means, have at it. I think there are plenty of subjects to go around. Like "faking" item descriptions, making a new type of container, various forms of creature AI, repurposing graphics, special encounters... the list goes on. I'm sure some people might even like a tutorial on dialog that depends on the state of a SDF, or some other of the things that seem simple to the "code jockeys" among us.

That first (faking item descriptions) may be what I tackle first, unless someone would really like to see something else.

If anyone is interested in articles of a more technical nature (tutorials or how to's, etc.), I'd be willing to throw a few into the pot. Just let me know what subjects you'd like to see covered. I'd hate to spend time writing one that's either too simple or too complicated for what people need.

Ah... sorry, the Hawke's mansion reference didn't mean anything to me (and so I guess I should've kept my mouth shut ).

Yeah, if the intent is some place where one party can drop stuff and another party can come pick it up, then, no, it's not possible. As Eldiran pointed out, the SDFs will be reset.

I was thinking of a centralized drop spot within a single scenario, where the party could return and drop off excess baggage. In that case, the SDFs would be in the save file, and it would work.

Actually, you might be able to rig something with SDFs, by stuffing the item number of whatever was dropped into a flag. You'd have to set aside a "block" of SDFs to hold item numbers (so no open-ended storage, but if you're willing to give up enough SDFs you could make storage capability rather high).

Be a major PITA to script, though...

I'll try to explain it, Vent. For various reasons, designers often need to "loop" through the party, doing something to/for each member of the group. The only way this is possible is because we're guaranteed, by Jeff's implementation, that the party will always be characters 0 through 5. Character 0 is the first party member, 1 is the second, 2 is the third, 3 is the fourth.

If you add an NPC to the party, even though that NPC already has his own char number, you can ALSO refer to that char as Character 4. If you add a second, it's Character 5.

Now, say I've designed a town and the very first NPC I placed in it was a giant spider. The moment I place it, the editor assigns it character number 6. I can refer to that spider in all sorts of calls simply by specifying character 6.

Now, let's say Jeff decides you're right and he needs to add capability for another NPC to join the party. The party is currently referred to by numbers 0 through 5, so this new one will obviously need to be referred to by 6 (to keep from breaking the code people are alredy using to loop through all the party members in a while loop). But then, my giant spider in my first town would be treated as a party member by those loops, because he's character 6.

There are ways to get around it, of course; but none that wouldn't require everyone to go back and change code to keep it working the way it's supposed to.

When I call char_has_item_of_class_equip() with a class I gave a particular type of cloak, it's always returning FALSE, even when it should (to my thinking, at least) return TRUE. I know the class of my custom item is set right, because a check of has_item_of_class() behaves correctly.

So... is a cloak not considered "equipped" when it's being worn? Or do I have some insidious bug somewhere that's disguising itself as this call not working properly?

EDIT: I've coded around this by directly checking item_type_in_slot() for slot 10 (which answers the 'insidious bug' question). Still, I'd be interested in knowing if cloaks are not considered "equipped" or if the call is broken.

Good point.

Actually, I decided to sidestep the issue and let the party find a cache of the distinctive cloaks the guards wear, instead. The whole idea is to give the party a disguise that's likely to work if they're spotted from 50 yards, but hasn't a chance of working if they're face-to-face with a real guard.

What I do to put "Zzzz..." bubbles on a sleeping character in one of my towns is something like:

if ((get_current_tick() % 2) == 0) {

// put up your bubble here

}

That makes it appear every other 'tick'. Changing the modulus (of course) changes the number of turns between it showing up.

In a cutscene, a string of text bubbles would look something like this:

text_bubble_on_char(6, "I'm talking...");

force_instant_terrain_redraw(); // draw it

pause(20); // give player time to read it

text_bubble_on_char(6, ""); // clear last bubble

text_bubble_on_char(6, "Saying something else...");

force_instant_terrain_redraw();

pause(20);

etc.

Along the lines of this discussion, I have a town where the party must avoid being seen by the guards and certain officials. At one point, they find a cache of guard uniforms, and have the chance to (imperfectly) disguise themselves.

To the discussion at hand: I can't decide whether it would be better to make the uniforms really nice protection (and quite encumbering for the low-level party you're supposed to be playing the scenario with), or appropriate to the low-level party (e.g., essentially fine leather-ish with a different icon). For story purposes, they'll want to get out of them as quickly as they can, either way.

Any thoughts?