[Fixed] Small Boom incompatabilities

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: [Fixed] Small Boom incompatabilities

by Cyb » Sat Dec 06, 2003 1:18 pm

randomlag wrote:Lol - Just a note Mr Watson that your post is a clear case of trolling. They must have different rules in NY on what this sort of petty behavior means. And of course it can be "all-cyan" :)
you disappoint me, Mr Vermeulen from WA : P

surely trolling of ones forum hero is allowed in WA, because it was recently made law here in NY
randy wrote:If larsboy finds the cause of his second problem, please post a new bug report instead of replying here.
I agree, I've prolly just sent this thread into a downward spiral, apologies

by Graf Zahl » Sat Dec 06, 2003 4:26 am

randy wrote: Mordeth incompatibility (2): I added a second parameter to Teleport, which is the sector tag. If the tid is zero and the tag is non-zero, the old (and hideously inefficient) Doom search method is used. If the tid and tag are both non-zero, then only teleport destinations with a matching tid in a matching sector are used.

Hey, that's even better than anything I had in mind. Now let's find a way to use this effectively! ;)

by randi » Fri Dec 05, 2003 11:42 pm

Mordeth incompatibility (1): I lied. All the Door_* specials now have an additional parameter that serves as the lighttag. This means you can also make the BOOM light effect work on "remote" doors if you wish, since the door tag and the light tag are two distinct parameters.

Mordeth incompatibility (2): I added a second parameter to Teleport, which is the sector tag. If the tid is zero and the tag is non-zero, the old (and hideously inefficient) Doom search method is used. If the tid and tag are both non-zero, then only teleport destinations with a matching tid in a matching sector are used.

If larsboy finds the cause of his second problem, please post a new bug report instead of replying here.

by HotWax » Fri Dec 05, 2003 1:58 pm

Gee it's a good thing we have RL here so we know exactly what is and isn't trolling -- even though he trolls more often than any other poster on these boards and doesn't seem to realise it . . .

by Graf Zahl » Fri Dec 05, 2003 12:33 pm

randomlag wrote: Doing this in HEXEN format (vs scripting) is a much simpler solution too. As I said before, no need for more args since that's an artificial condition that doesn't exist. And as noted, other methods exist for HEXEN format levels.

If you approach every single new idea with the concept of "general solutions", then nothing ever gets done (or it takes too long). WFDS is a good example. KISS wins every single time over complexity. There's always another day to make it more complicated. Nothing ventured, nothing gained and all that stuff.

There we are again...

Ok, if you approach this problem from a purely theoretical standpoint you are right. There are better ways to do stuff like that in Hexen format. But: What if someone comes up with some crazy idea nobody has thought of before that can NOT be done? (as Mordeth effectively proved!) That's what I mean with 'unnecessarily limiting options'. There is no need to do so, my suggestion won't things more complicated because you can safely ignore it if you don't want to use them. The major difference is: if somebody WANTS to use them he CAN! With your approach he can't and in my book that counts as poor planning.

It's the same with many gamemode dependent behavioral differences in ZDoom: some of them just drive me crazy because I can't achieve what I want without some major workarounds. One good example of this are fast crushers: They work fine in Hexen mode but are utterly useless in Doom and I have to use some really ugly things to get what I want.

As a result of those experiences I generally advocate a solution that keeps all options open as long as it doesn't mean major additional work. Clearly that's the case here.

by randomlag » Fri Dec 05, 2003 12:04 pm

Cyb wrote:I'm also disappointed that rl hasn't pointed out that there's no way Mordeth could have changed the teleport destination to be "all-cyan" ; )
Lol - Just a note Mr Watson that your post is a clear case of trolling. They must have different rules in NY on what this sort of petty behavior means. And of course it can be "all-cyan" :)

What I clearly referred to applies only to the DOOM format, not HEXEN format. IOW, the user does not have access to more attributes or scripting. Not everyone likes to use the HEXEN format when editing.

As to whether is has been used before or not - silly argument. Isn't that what this forum is all about - presenting NEW ideas?

Doing this in HEXEN format (vs scripting) is a much simpler solution too. As I said before, no need for more args since that's an artificial condition that doesn't exist. And as noted, other methods exist for HEXEN format levels.

If you approach every single new idea with the concept of "general solutions", then nothing ever gets done (or it takes too long). WFDS is a good example. KISS wins every single time over complexity. There's always another day to make it more complicated. Nothing ventured, nothing gained and all that stuff.

by Cyb » Thu Dec 04, 2003 3:10 pm

I don't think it's really necessary to fix it since it's never been used before, at least not in any wads I can recall. If Mord sticks with Eternity it won't matter (unless randy wants eternity support in zdoom ; ) and if he switches then it's not really necessary to fix since you can create the same effect with scripting, plus I believe zdoom allows you to use any thing as a teleport destination, so you could even mess with a random decoration and use that.

I'm also disappointed that rl hasn't pointed out that there's no way Mordeth could have changed the teleport destination to be "all-cyan" ; )

edit: tho graf brings up a good point of the possibility of it being used in vanilla or boom maps in the future

by Graf Zahl » Thu Dec 04, 2003 3:03 pm

I never said it has to be done. I fully agree that right now there is really no need to do so. I merely made a suggestion how it could be done if Randy wants to. Nothing more. But once this feature is used in a WAD you can bet that others will copy it. And if this is really required to br implementes for something to work I'd just prefer a more general solution that is not map format specific, that's all.

by randomlag » Thu Dec 04, 2003 2:02 pm

IIRC, the original ? was about DOOM style levels, not Hexen format. I admit that's a little leap, but Eternity is stock DOOM format, so not unreasonable to assume this.

Besides, pretty sure a moving teleport is rare so even then not required. IOW what is there to be backward compatible with since it doesn't exist?

Remember KISS

by Graf Zahl » Thu Dec 04, 2003 11:13 am

Why not? If the old behavior is implemented someone might want to use it in Hexen-style levels, don't you think?

As in

Teleport(tid,0) for Hexen-style

and

Teleport(tag,1) for Doom-style.

by randomlag » Thu Dec 04, 2003 11:08 am

Don't need to add any more parameters.

by Graf Zahl » Thu Dec 04, 2003 3:31 am

Cyb wrote:though of course what his teleporters do is already possible in zdoom with a little scritping ;)

Of course. ZDoom's (Hexen's) teleport functionality is significantly better than Dooms because you can do so much more with it. But this isn't about new features but backwards compatibility. I agree that it's easy to fix (add an additional parameter to the teleport specials that activate the old destination selection method.) If there were actually any WADs that use it...

by Cyb » Wed Dec 03, 2003 11:56 pm

randy wrote:Fixed Cyb's bug. Mordeth bug (1) is already documented, and I probably won't try and support that Boom feature. For Mordeth bug (2), the Mordeth TC requires the Eternity engine anyway, so should I really fix it? :-)
perhaps mord is thinking of switching to zdoom? (dun dun dun)

though of course what his teleporters do is already possible in zdoom with a little scritping ;)

by randomlag » Wed Dec 03, 2003 10:47 pm

randy wrote: For Mordeth bug (2), the Mordeth TC requires the Eternity engine anyway, so should I really fix it? :-)
Yes. Sounds like an interesting twist to teleports. Seems it should be easy to "fix" - even easier than stock DOOM format.

by Graf Zahl » Wed Dec 03, 2003 3:47 pm

randy wrote:For Mordeth bug (2), the Mordeth TC requires the Eternity engine anyway, so should I really fix it? :-)

Frankly, I have never seen a WAD that manipulates teleport destinations in this way but my first thought when I saw the way ZDoom handles this was 'What if somebody finds a way to abuse it?' Still, I don't really think this is worth much effort (unless it is really easy of course ;) )

Top