Removing nearby items from actor state (irrelevant crap split)

Please do not mimic the behavior of the posts shown here.

Moderator: GZDoom Developers

Removing nearby items from actor state (irrelevant crap split)

Postby ketmar » Thu Jan 09, 2020 2:55 pm

convert code to ZScript, and lost compatibility with everything except GZDoom. one of the reasons GZDoom is so much hated in various places.
User avatar
ketmar
k8vavoom developer
 
Joined: 01 Oct 2016

Re: [SOLVED]Removing nearby items from actor state

Postby Enjay » Thu Jan 09, 2020 5:35 pm

ketmar wrote:convert code to ZScript, and lost compatibility with everything except GZDoom.

Are you saying don't use any port specific feature (even if it is the most efficient way to do something) if it means upsetting someone who wants to play a mod on a port other than the one the mod is aimed at?

I don't know, but I suspect in this particular case the mod is aimed at GZDoom so why would it even matter if a GZDoom specific feature was used? And let's not forget that we are talking about avoiding using a hacky method in a once ZDoom only feature (DECORATE) that can now be done much better in another GZDoom only feature (ZScript) - a feature that was asked about, pleaded for, waited for, memed about and even sung about for more than a decade. Are we really meant to avoid adopting it just because of some port haters? Image

ketmar wrote:one of the reasons GZDoom is so much hated in various places.

So what? If someone is getting so upset about something like that (GZDoom forging ahead with new and highly desirable features), I think it's their problem. Much of the time it seems to boil down to "I want to play that mod on my port of choice (or on my toaster that only runs port [X]) but it has features that mean I need to run it in GZDoom and I don't want to". That just means that the mod is not for the person complaining. They can go play something else instead; they have other options. Live and let live.

I think it's the "every port must support this awful convoluted hack instead of a better way of doing things, even if it holds up and otherwise limits the port and give the authors more work" attitude in the Doom community that is far more toxic anyway. IMO, the hate that you speak of is a symptom of that attitude, not a function of what GZDoom does.

Personally, I avoid such attitudes these days by simply not visiting the places where such haters are likely to hang out. I have to say that doing so has improved my quality of life and has not adversely affected my hobby at all. Haters tend to say very little of value anyway (usually hate for hate's sake) and I am lucky enough not to need to hear their complaints. Other than the noise that they make in their own echo chambers, they don't seem to have much actual effect any way. Their hate has not made them powerful. Image


It really sounds like you're advising avoiding using the best method of doing something rather than upset people who are already upset and probably wouldn't be playing this mod any way.

Of course, if Grey-Wolf wants his mod to be played on DECORATE supporting ports other than GZDoom, everything I just said is moot. ;)
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: [SOLVED]Removing nearby items from actor state

Postby ketmar » Thu Jan 09, 2020 5:46 pm

>Are we really meant to avoid adopting it just because of some port haters?
no. i meant avoiding port-specific features if it can be done in cross-port way, even if that way is more hackish. because GZDoom now moves further and further into its own realm, where there are "GZDoom-only things" and "cross-port things", effectively fragmenting the community. and with that, there is less and less incentive for other sourceport developers to make steps into supporting GZDoom features, and more and more incentive to go with their own unique solutions. because why invest time and efforts into cross-port compatibility, if it worth nothing? and in the end of the day, it harms community as a whole. and then Graf is talking about how "retro-community" is fragmented, which is like throwing stones from inside the glass house.
User avatar
ketmar
k8vavoom developer
 
Joined: 01 Oct 2016

Re: [SOLVED]Removing nearby items from actor state

Postby Grey-Wolf » Thu Jan 09, 2020 5:51 pm

It's a GzDoom-only mod, yes. But either the case, chill. No one wants to fight here, I think. I for istance, am just happy I learned something new, period.
Last edited by Grey-Wolf on Thu Jan 09, 2020 5:52 pm, edited 1 time in total.
User avatar
Grey-Wolf
 
Joined: 15 Jul 2018
Operating System: Windows 10/8.1/8 64-bit
Graphics Processor: nVidia (Modern GZDoom)

Re: [SOLVED]Removing nearby items from actor state

Postby Enjay » Thu Jan 09, 2020 5:52 pm

However, I would suggest that the feature in question (ZScript) is such a desirable, long awaited and valuable one that it doesn't fit well into the advice to use the hacky cross-port method instead, especially when the hacky method is one that uses a ZDoom and derivatives feature (and therefore, is not particularly cross-port) any way.

No fighting here Grey-Wolf, just discussion. If a fight breaks out, the thread dies. :yup:
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: [SOLVED]Removing nearby items from actor state

Postby ketmar » Thu Jan 09, 2020 5:59 pm

yeah, i didn't meant to fight with Enjay too. i am just exceptionally bad in explaining myself. ;-)

>especially when the hacky method is one that uses a ZDoom and derivatives feature
decorate is not exclusive to ZDoom family. ;-)


p.s.: full disclosure: just take a look at my title. it is possible to implement decorate if your port is not ZDoom fork/derivative. but ZScript is out of question, you HAVE to be ZDoom to have it, there is no other way.
User avatar
ketmar
k8vavoom developer
 
Joined: 01 Oct 2016

Re: [SOLVED]Removing nearby items from actor state

Postby Enjay » Thu Jan 09, 2020 6:31 pm

And I'm certainly not trying to fight with you. :)

ketmar wrote:p.s.: full disclosure: just take a look at my title. it is possible to implement decorate if your port is not ZDoom fork/derivative. but ZScript is out of question, you HAVE to be ZDoom to have it, there is no other way.

I'm really quite excited to see where you take k8vavoom. I always thought Vavoom had great potential but never seemed to get to a point where it was able to fully deliver on its promise. When I heard that you were resurrecting it, i was really pleased.

I have no idea how easy or difficult Zscript is to implement in a non GZDoom environment but I'm guessing it makes a lot of "under the hood" calls to GZDoom specific engine code.

So I guess I understand the frustration there but the long, long wait for Doomscript, the many, many requested features that were put on hold with the WFDS tag and the sheer power of what zscript can do, in my opinion, justify its existence even if it is so closely tied to GZDoom. It was probably the single most anticipated feature in the entire history of the ZDoom line and people are certainly using it (and using it to do some fascinating and innovative things). If it is becoming some sort of focus for GZDoom hate, I just think that's rather disappointing. (Indeed, wasting time, energy and words hating on aspects of a hobby is rather disappointing any way.)
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: [SOLVED]Removing nearby items from actor state

Postby ketmar » Thu Jan 09, 2020 7:16 pm

>When I heard that you were resurrecting it, i was really pleased.
thank you! ;-)

>I have no idea how easy or difficult Zscript is to implement in a non GZDoom
>environment but I'm guessing it makes a lot of "under the hood" calls to GZDoom
>specific engine code.

yeah. ZScript closely reflects the design of the engine (just like VavoomC), so no other port except Vavoom can implement VavoomC (not the compiler, but the API and design), and no other port except [G]ZDoom can implement ZScript.

>So I guess I understand the frustration there but the long, long wait for
>Doomscript

yeah. decorate is far from the best tool, i know it very well. ;-) but "just switch to ZScript" is not the best move from my PoV too. what i envision is that ZScript could be used to implement new decorate features only, and everything else is done with decorate. this way, it will be much easier to re-implement new decorate features in another sourceport, and that port will not require to implement ZScript (and ZDoom engine design with it).

like, if mod author need some feature, and it is impossible (or very-very hard) to do it with decorate, than they can use ZScript to implement new decorate action, and use that new action in their code. then i can take a look at the implementation, and add that feature to k8vavoom, and BOOM! the mod works even without ZScript support. other sourceports can do the same. it will require some design to mark "mod-specific decorate actions", so other ports would be able to detect the mod and put "feature alias", but i am sure that it is doable, and will better serve the community as a whole. good new implementations can be promoted to mainline then. and i can send mod author k8vavoom implementation of the feature, which will be automatically loaded by k8vavoom, for example. ;-)

tbh, now i almost gave up implementing GZDoom compatibility in my sourceport. because old decorate mods are usually full of bugs (those bugs went unnoticed due to poor ZDoom error checking), and there is either nobody to fix them, or if the author is working on the mod, they move mod to ZScript, and again, nobody's there to fix decorate version. so even if i'll get more GZDoom decorate actions/features implemented, old mods won't work, and new mods won't work. and then there is almost no reason for me to spend my time trying to be compatible. and then the agrument "other sourceports don't want to support GZDoom decorate features, so there is no reason to prefer decorate to ZScript" becomes kind of self-fulfilling prophecy. ;-)

i strongly believe that there should be a common ground for all advanced sourceports. decorate is not the best thing out there (it is close to the worst, tbh ;-), but this is the only thing we have that can be independently implemented. and we have alot of decorate code already. i believe in choice, and with this common ground people will have more choice among the sourceports (hopefully).

i have nothing against GZDoom adopting features from k8vavoom, for example (as much as i love to be the developer of "That Cool Port With Lightmaps", i'll be glad to see lightmaps implemented in GZDoom), and i am implementing some GZDoom features too. we together can make supporting more than one sourceport easier, and other ports will eventually join the crowd (of two ;-). at least i believe that this is way better plan than moving exclusively to ZScript and thus dropping all non-ZDoom ports out of the window for ever.
User avatar
ketmar
k8vavoom developer
 
Joined: 01 Oct 2016

Re: [SOLVED]Removing nearby items from actor state

Postby Graf Zahl » Fri Jan 10, 2020 1:01 am

ketmar wrote:>Are we really meant to avoid adopting it just because of some port haters?
no. i meant avoiding port-specific features if it can be done in cross-port way, even if that way is more hackish.


Well, it's too bad if your port cannot play such a map - but that's solely at the mapper's discretion if they prefer something robust that works only in GZDoom or something hacky that doesn't work well anywhere. Because that's normally the alternative.
User avatar
Graf Zahl
Lead GZDoom Developer
Lead GZDoom Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: [SOLVED]Removing nearby items from actor state

Postby ketmar » Fri Jan 10, 2020 1:11 am

this alternative actually means "oh, stop caring about GZDoom compatibility at all. because they'll use their ZScript anyway." actually, this (ZScript) is what happens even if decorate is perfectly enough, and ZScript code only contains flags and decorate actions. because "decorate is obsolete". no wonder that non-ZDoom-derivatives never bothered to implement proper decorate support -- because that mindsed was always the mark of ZDoom. just add features, never properly document them (hello, ACS extensions, i am talking about you!), then whine about "others don't want to support that", and switch to some another solution (this time to completely unportable one). i absolutely cannot see any possible source of animosity towards GZDoom with such course of actions.
User avatar
ketmar
k8vavoom developer
 
Joined: 01 Oct 2016

Re: [SOLVED]Removing nearby items from actor state

Postby Rachael » Fri Jan 10, 2020 6:08 am

@ ketmar:

There's nothing stopping other port authors from taking GZDoom's ACS VM *and* its ZScript VM and porting it to their port. Yes, it will be hard because ZScript has its tendrils everywhere, but luckily most of its reach can be grep'd up since it uses compiler macros for most of its operations, anyhow. Worst case scenario - you can fork GZDoom itself, gut the renderer, input, and platform backends, and put your own in its place if you wanted to.

Yes, I'll agree that GZDoom has gone too far when it comes to cross-port compatibility these days, especially as far as ZScript is concerned. It would be quite an effort to reimplement it correctly elsewhere, ie Vavoom or Eternity or Edge.

Keep in mind though - this forum really is focused on GZDoom, and generally 99% of the people who come here prefer it as their port. You're directly in the port's home forum. So trying to encourage people not to use GZDoom features just because it won't work with other ports (of which you author one, so you have a vested interest here) is kinda dicky at best.

With the things you have been saying here, I can see why Grey-Wolf was afraid of there being fighting here. Don't be "that guy" who makes that actually happen.
User avatar
Rachael
Webmaster
 
Joined: 13 Jan 2004
Discord: Rachael#3767
Twitch ID: madamerachelle
Github ID: madame-rachelle
Operating System: Windows 10/8.1/8 64-bit
OS Test Version: No (Using Stable Public Version)
Graphics Processor: nVidia with Vulkan support


Return to Hall of Unpleasantness

Who is online

Users browsing this forum: No registered users and 1 guest