Grimrock

Question about the Dark Tower: why is this a tower that goes down instead of up? I started thinking the three floors for my room would go up then realized my mistake! Also, i see two levels above the entry, but they are marked "LEAVE EMPTY".

I think that a few simple string processors (library functions) would handle all the dialog [that made use of them] just fine.

Common script functions that [optionally] handle gender pronouns, and the lack of four party members; and other concatenations.

Something [pseudo] like :
local PCname = randomPC()
hudPrint("The "..partySize().." adventurers, delve deeper into the dark maze." )
hudPrint(PCname.." has been bitten, and is diseased. "..pcPronoun(PCname).." feels the noxious effects of the poison." )

**We may need something like this for the intro text if there is any. I know that I started Wrath of the Gorgon with three PC, but IRRC, it mentions there being four in the static intro.

Andak, I'm not entirely sure what the design choice was there; maybe to match how most other areas function? I just went with it; if you need your room to go up, I can probably make it work (designing the boss fight to take place in the above floors, but I can just move it up, etc). Designing some rooms to go down (like mine) and others up reinforces the "Tower" feel IMO, so if you still want to do that it should not be an issue.

Jgwman wrote:I had no idea we have a project bug tracker, Isaac; that definitely helps so we don't have to clutter this thread so heavily.

It's John's, so we'll likely need him to associate accounts, or promote another to 'owner'.

*Worst of the worst case we can make a new project page.

Jgwman wrote:Good points from everyone. For your point on the rats, minmay, I agree. I added the hudPrints rather than GUI for a couple reasons - primarily just because it was faster to add (knowing that it wouldn't be too hard to change it later). IMO, we should keep the tavern rat for the third one. I'd be glad to rewrite more interesting dialog and implement it with GrimTK if you can cover fixing the other stuff (animations, etc., and I could use a suggestion for the invulnerability - I disabled the monster component thinking that would do it, but clearly not).

If the monster doesn't need to move around, I'd prefer to not use a MonsterComponent at all.
If it does, return false from the MonsterComponent's onDamage and onProjectileHit hooks. That way none of the effects of being hit (damage test, flinching, sound, sharp projectiles sticking, etc.) will occur. Unfortunately, "Miss" will still appear above the monster's head if you miss with a melee attack.

Jgwman wrote:Good points on party members as well; I assumed you meant balance-wise. These are good things to look out for when testing - I know you mentioned at least one case (Eleven Warrior's room) already. Do we think doing something like multiplying XP gains is a reasonable idea, or leave it as-is since it's pretty clear fewer party members is generally more difficult?

Sorry for the confusion, wasn't talking about balance. I think either way is reasonable. What's important is that having <4 party members doesn't break like it did in e.g. ORRR1.

About the bug tracker, can we find one that I don't have to pay money to use for more than 30 days?

minmay wrote: About the bug tracker, can we find one that I don't have to pay money to use for more than 30 days?

That would be fine with me. I have never had to pay them anything though... I think John must have it on his own account, and added some of us as editors to his project.

There is not so much on there that we couldn't move to it all to a new solution. [What are some other options?]

There is a piece of code I have that checks the Player's level and spawns monster's to suit the player's level. It does not matter if there are 1 or more party members.

I cant check my level anymore as I said I don't have the files so I thought my level was easy as with either one or more party members.

You don't need to adjust the combat in your room depending on the number of party members. Anyone playing a party with fewer than 4 members is specifically trying to make combat harder in the first place. Just make sure your room still functions if there are fewer than 4 party members.

minmay wrote:

Duncan1246 wrote: Well, I suspected it was it, but I have tested it several times, and after saving/loading the "door" stays open. Even if it was not so, the opening mechanism is always working. It's true that when it's open, the door goes on the level up, becoming an illusionary wall (you can pass through it) but this side effect isn't too bad. In addition, replacing this will break the visual "secret" effect (no secret wall in Skuggarsvein set, needs to use another set) or needs to changes all the walls...

The set DOES have a secret door. It's called "urban_town_secret_door". Use that.
However, someone who wasn't paying attention gave it minimalSaveState, so make sure that gets removed before release...

I have downloaded the last version of ORR3 and all mystery vanishes... The urban_town files have been modified, particularly the urban_wall: MSS added and optional occluder added too, so my secret door was broken. Added also the "secret_door", but it's fairly identical to "urban_town_wall_01" without the occluder, but witn MSS! Also, what is the use of "urban_town_wall_03" and "urban_town_wall_03_elev" ??? They differ from the 01 and 02 by one texture, but they look identical ! All that is pretty confusing.
I don't understand why these changes have been made, but anyway I will follow Minmay's advice to make the secret door working.

minmay wrote:

Jgwman wrote:Good points from everyone. For your point on the rats, minmay, I agree. I added the hudPrints rather than GUI for a couple reasons - primarily just because it was faster to add (knowing that it wouldn't be too hard to change it later). IMO, we should keep the tavern rat for the third one. I'd be glad to rewrite more interesting dialog and implement it with GrimTK if you can cover fixing the other stuff (animations, etc., and I could use a suggestion for the invulnerability - I disabled the monster component thinking that would do it, but clearly not).

If the monster doesn't need to move around, I'd prefer to not use a MonsterComponent at all.
If it does, return false from the MonsterComponent's onDamage and onProjectileHit hooks. That way none of the effects of being hit (damage test, flinching, sound, sharp projectiles sticking, etc.) will occur. Unfortunately, "Miss" will still appear above the monster's head if you miss with a melee attack.

Thanks to Isaac asking a question, I've discovered that there's a "NonMaterial" monster flag that gets rid of the "Miss" on melee attacks. So let's use that plus the onDamage and onProjectileHit hooks.