ZDoom

by **MartinHowe** » Tue Aug 02, 2005 7:55 am

OK, this thread is rendundant now: see this post.

by **Graf Zahl** » Fri Jul 29, 2005 7:09 am

This wouldn't require big changes. And the functions that have to be altered for this have already been mutilated beyond all recognition.

But I still don't think that it is important enough.

by **David Ferstat** » Fri Jul 29, 2005 6:46 am

Besides, it's not that typical a response when you look at the larger picture. If you read the .96x thread you'll see that he's incorporated a heck of a lot of suggestions from the peanut gallery.

The response in this thread is really on typical for suggestions that ask for something difficult. As Graf has stated on numerous occaisions, he's only interested on adding features that will require small changes, to maximise the chances that Randy will eventually incorporate them into .97 ... .98 ... whatever.

by **Sir_Alien** » Fri Jul 29, 2005 5:30 am

Doomguy0505 wrote:typical feature suggestion reply from graf

Typical response to Graf dismissing an idea. In regards to his port no less. The port he's working on. The one you're not.

So STFU.

by **Graf Zahl** » Fri Jul 29, 2005 2:12 am

The problem is not that it is taking so long. The problem is that Randy is neither answering any questions about it nor commenting on the unofficial version. A little more openness could prevent this from happening quite easily but since Randy prefers secrecy and doesn't even give a hint about how he sees these developmens we can only take guesses and base our work on that. And if it goes bad - then we are in trouble.

And frankly, it wouldn't have happened if Randy had actually bothered to add the weapon code when I first submitted it 7 MONTHS AGO! and released a new version. Instead he went on fixing bugs for some time and then started his conversion - but still didn't release anything before starting with that. Sorry, but if this goes bad I won't take the blame.

by **MartinHowe** » Fri Jul 29, 2005 1:03 am

Nevertheless, I'd be careful about letting that happen. Professionally speaking, I've been where Randy is now. A big program with a large user base; a set of internal changes that in the short term are invisible to end-users; the changes are needed to make a whole lot of things possible that can't be done with the system as it is; end-users whining about "why can't we have <something that isn't actually necessary RIGHT NOW>" because they don't see the bigger picture - or rather, because that picture has been explained to them and they're too selfish to care.

Actually, I hope we aren't that bad to Randy, but you all get the idea

by **Graf Zahl** » Thu Jul 28, 2005 7:02 am

Well, if he wants to let control over ZDoom slip away I won't complain. Because that's what will happen if the current situation continues.

by **Cutmanmike** » Thu Jul 28, 2005 6:04 am

The culprits:

and

by **Graf Zahl** » Thu Jul 28, 2005 4:48 am

We can't bloat the unofficial build with everything that comes along. If we reach a point where Randy says 'no' it was all for nothing. The problem is that Randy isn't saying anything whatsoever...

by **Doomguy0505** » Thu Jul 28, 2005 4:21 am

Graf Zahl wrote:For the unofficial build: no chance if you ask me. For .97: Randy has to decide. But you should be aware that currently there is absolutely nothing there that might make implementing this easier. It all has to be done from scratch.

typical feature suggestion reply from graf

by **Graf Zahl** » Wed Jul 27, 2005 10:43 am

Somewhere in between. Most of it is not that hard to do but there are situations where it might not work.

by **MartinHowe** » Wed Jul 27, 2005 10:33 am

I was thinking in terms of having an actor variable include two pointers to lists of classes and that it should check each of them before "acquiring" a candidate target.

I realise that it would need to be coded, but what I was also concerned with whether this would be "logically" impossible due to the way ZDoom works? I mean some things can be done (but would need a lot of work) while others can't be done at all. Which of those two categories might this fall into?

by **Graf Zahl** » Wed Jul 27, 2005 10:26 am

For the unofficial build: no chance if you ask me. For .97: Randy has to decide. But you should be aware that currently there is absolutely nothing there that might make implementing this easier. It all has to be done from scratch.

by **MartinHowe** » Wed Jul 27, 2005 10:19 am

For friendly monsters and monsters controlled via scripting, it would be useful to filter the kinds of monsters that they attack. For example, I might want a monster that attacks demons and imps, but leaves everything else alone.

In DECORATE, this could be something as simple as a keyword followed by a list or boolean expression on classnames, but how difficult technically is it?

Also, what are the alternatives, other than a lot of messing around with custom action functions and having to give all monsters a TID?

Example DECORATE code:

Code: Select all

// This monster will attack imps and
// demons and leave everything else alone.
hates all DoomImp, Demon

Code: Select all

// This monster will attack everything except
// imps and demons and leave them alone.
hates except DoomImp, Demon

Graf, Grubber, any comments in general and specifically as regards the UO build?

Randy, could this be done for .97 perhaps or do you have something better in the pipeline?

ZDoom

Filter the kinds of monsters that a monster attacks?

Post a reply

Expand view Topic review: Filter the kinds of monsters that a monster attacks?

Filter the kinds of monsters that a monster attacks?