Help me make my new variant! (please!)

[Nick]

(This isn't really a coding question, but whatever)
IIRC, in 3.4.1 if you were targeting (say) a pile of rubble, you could press 'r' to recall a description for rubble, but that isn't working in the current version. Why was that removed? (I want it so people can easily see descriptions for the new terrain I'm adding)

I can't see any reference to this in the code for 3.3 or 3.4 - it seems you could only do this for objects, same as now.

[will_asher]

(This isn't really a coding question, but whatever)
IIRC, in 3.4.1 if you were targeting (say) a pile of rubble, you could press 'r' to recall a description for rubble, but that isn't working in the current version. Why was that removed? (I want it so people can easily see descriptions for the new terrain I'm adding)

[will_asher]

Good to know.

[Julian]

Today when I opened up Visual Studio to work on RubberBand, it gave me a ton of errors saying "pointer to incomplete class type is not allowed". These errors weren't there yesterday. I hadn't changed anything before those errors appeared and it seems to build and run just fine. Does anyone know why it might suddenly give me all these errors that weren't there when I closed VS yesterday?

EDIT: So I went on working on Rubberband ignoring the errors for now, and after a while they disappeared for no discernable reason. weird.
EDIT: ...and then they reappeared. wth?

I don’t use Visual Studio, but that sounds like a C++ error, so it may be getting confused about the nature of your project.

[Nick]

Another question: Why are the newer vaults not allowed in the classic mode of dungeon generation?

IIRC it was because some of the new vaults did not connect nicely with the classic generation algorithm, or at least I suspected they might not. backwardsEric has done quite a bit of work recently on connectivity of vaults, so it's likely that this is not a problem any more.

[will_asher]

...Those errors eventually stayed gone, so I'm assuming they're nothing to worry about.
EDIT:...and those error messages are back.

Another question: Why are the newer vaults not allowed in the classic mode of dungeon generation?

[will_asher]

Today when I opened up Visual Studio to work on RubberBand, it gave me a ton of errors saying "pointer to incomplete class type is not allowed". These errors weren't there yesterday. I hadn't changed anything before those errors appeared and it seems to build and run just fine. Does anyone know why it might suddenly give me all these errors that weren't there when I closed VS yesterday?

EDIT: So I went on working on Rubberband ignoring the errors for now, and after a while they disappeared for no discernable reason. weird.
EDIT: ...and then they reappeared. wth?

[Julian]

I believe the answer is no, but it's just possible it's compiler dependent - I'm not the world's greatest C expert.

As Pete said, || is guaranteed to only evaluate the second part if the first is false.

This is also true of &&. It must short-circuit evaluation if the first part is false.

If (self_destruct_flag && initiate_self_destruct()) {
    printf("Ten seconds remain";
}

Is not going to blow you up unexpectedly.

(I do not, however, suggest writing your doomsday device in C. Use a safer language.)

[Julian]

No, the second clause will not be executed. (If you use a single |, it will.)

I’d not recommend using bit-operators in if clauses like this. (They’ll _work_ , at least most of the time, but it’s not what they’re for.)

If you want the second part of your or to evaluate regardless, either rearrange things, or just evaluate it into temporary variable first.

[Pete Mack]

BTW, if you do decide to use boolean arithmetic (|, &, ~, ^) for any reason, always use parentheses.

   x == 1 | y

is not synonymous with

  ( x == 1)| (y)

Even if the unparenthesized code is correct, anyone reading it will flag it as a likely error (and the compiler will warn.)

[will_asher]

cool. thanks.

[Pete Mack]

No, the second clause will not be executed. (If you use a single |, it will.)

Quick question:

Say you have:

if ((something) || (get_check(really?))) {
do_stuff();
}

If (something) is true, will it still ask you the get_check question?

[Nick]

Quick question:

Say you have:

if ((something) || (get_check(really?))) {
do_stuff();
}

If (something) is true, will it still ask you the get_check question?

I believe the answer is no, but it's just possible it's compiler dependent - I'm not the world's greatest C expert.

[will_asher]

Quick question:

Say you have:

if ((something) || (get_check(really?))) {
do_stuff();
}

If (something) is true, will it still ask you the get_check question?

[Julian]

NULL is the usual. But it is immaterial, since Nick will use a hard assertion.

It’s returning an index, not a pointer.