Owner-code for decorate

[Xtyfe]

Why don't we just make official what everyone's been thinking for the past 13 years and call it a day and move on? DoomScript is never going to happen.

And with in mind we can finally let loose without worrying about it.

[Edward-san]

Why don't we just make official what everyone's been thinking for the past 13 years and call it a day and move on? DoomScript is never going to happen.

No way! DoomScript will be created no matter what! Even if it takes other 10 years, it doesn't mean "it is never going to happen".

[Major Cooke]

Because maintenance. Every change made has to be maintained into the future indefinitely. So careful consideration has to be made as to the value of having the feature around, particularly with regard to the complexity of the code to maintain, and especially so if it's known that new features will supersede it in the future. The basic reality is that it's not a thing you can keep adding stuff to without consequence.

I understand that, and FDARI surely does too. That's why I keep supporting his works, because he knows what he's doing at least.

Why don't we just make official what everyone's been thinking for the past 13 years and call it a day and move on? DoomScript is never going to happen.

And with in mind we can finally let loose without worrying about it.

I agree but we don't truly know if he's hiding it in a pocket leg just waiting to let it burst forth or not.

[Enjay]

Heh, people born when Doomscript was first mentioned are now teenagers.
And I've just realised how young I was when it was first mentioned.
And I still have the MP3 of Nash's song "Waiting for Doomscript".

Seriously, I know that it doesn't account for 13 years worth but I think it is fair to say that Randy has had more serious things taking up his time in recent weeks/months what with the flooding and all.

I know it's a difficult situation but we have to accept that there are features that we want that Doomscript should be able to give us but which we simply can't have right now. And, yes, some features are wanted much more than others and could be added in as individual entities right now (or should that be "NAOW!!!"?). The cost, however, is as Zippy pointed out the maintainability of the code in future. The more "sticking plaster" and special case features that are added right now, features that fall within the scope of what Doomscript should be able to handle, the harder Doomscript (and the game in general) will be to maintain and keep robust in future. The best case scenario in this situation would be a whole bunch of features that are added in the interim period being deprecated and simply shelved (and carried around as baggage in the exe) when DS becomes a reality. Perhaps more realistically, it could mean a bunch of features that interfere with Doomscript and which, perhaps, could cause a significant headache to keep working even with their initial functionality or which could break or even need to be removed, thereby breaking mods that use them (something which Randy has gone to great lengths to avoid in the past wherever possible). The whole thing could become a mess very easily.

If Randy still has the goal of introducing Doomscript then we simply have to wait and accept that some suggested features will be incompatible with that goal and so cannot be implemented before Doomscript. We have to work with what we have right now (and with any future features that are deemed to be acceptable). I know that I've had my own little tantrums about this in the past too but that's just the way the situation is and, if Doomscript is still something Randy wants to create (and I have seen nothing to suggest it isn't), then that's the only sensible way to operate: accept that some things cannot be added because they will possibly cause problems in the future and will be covered by Doomscript at some point.

[Nash]

I should make another song when we've waited for 15 years.

And another one at 20. If I'm still around that is. XD

XD

[DBThanatos]

I should make another song when we've waited for 15 years.

Some new lyrics would spice things up.

[Major Cooke]

I'd like to hear any you've made Nash.

Also, laughing at how far the minecart (thread) has flown off the rails

[MartinHowe]

It's a good thing that ZDoom has become the default source port of choice for anything other than straight Boom compatibility; it's nice to have a standard and I believe in having standards. But it can also a bad thing; even when I thought of rolling my own fork of ZDoom I realised that it would never catch on precisely because it would be a minority engine.

The problem with standards is that they should be flexible and allow many things to hang off them; this just hasn't happened enough with ZDoom. I don't mind having to code around problems, but there are so many things where the necessary hook into the engine just isn't there or is delayed for ages in case it damages DoomScript years in the future; look how long we had to clamour for monster-damaging sectors, for example.

Given that ZDoom is provided free of charge and Randy and Graf have spent years on it, I wouldn't have minded waiting so much for DoomScript (and another year or two, given randy being flooded and all). But to mention it all those years ago AND keep people waiting AND not allow them a decent alternative is just painful. It's like a woman who dallies with a man for years but never commits; it would have been better for her to have just said NO, NEVER in the first place.

Sorry if that sounds depressing, but this is how I feel about it. In my opinion, it would have been better to have consigned DoomScript to the dustbin of history ages ago, in favour of an improved DECORATE. I believe that there is an arguable case that compromising DoomScript by improving DECORATE is not reckless, but might even be the responsible thing to do, given the risk that DoomScript has missed its chance.

Personally, I would have liked to have seen the current ZDoom continued on with DECORATE and a cleaned up, back to basics, version created for DoomScript; but then, it would be a lot of work for Randy and Graf (or whoever) and for many people wouldn't be ZDoom any more. Especially as so much of the basic monster coding is now in DECORATE anyway.

It will be interesting to see if, when I finally complete all my outstanding ZDoom projects, whether DoomScript exists by then. I guess Vavoom C is the nearest thing to it right now. Bizarrely, 3D Realms did have the last laugh after all - even I didn't see that coming

EDIT:

I just took a look at Vavoom's guts - they seem to have been colonised by DECORATE and what looks like Vavoom C ports of much of the ZDoom source code. See what I mean about standards

[FDARI]

I wrote this code a while ago, and figured it could be used to make pickups a lot more scriptable. It could.

However... I have just realised there may be scenarios where it doesn't work as intended. Not because the code doesn't do what it's supposed to, but because the situation isn't really what you'd expect:

When picking up an item (custominventory or otherwise, but most relevant for custominventory) that matches one already in your inventory, which item is actually processed (custominventory) and added (any inventory)?

When playing with respawning items (deathmatch), is a duplicate item created for pickup processing?

The question in both these cases is really: Will the pickup processing access the spawned inventory actor?

The question is also relevant in the case of items with code in both pickup and use-state. Especially if you can carry multiple instances. Does inventory maintain individual properties of items?

This inspires a question about inventory (respawning) in general: If you modify a spawned item, and have it picked up, will the respawning item retain all modifications? I think it will, because it appears to be put in a hidden state and then returned from it, not actually being replaced with a new item.

I can test such things, but that's more work than just asking, and I'm not working on this right now.

These concerns would also be relevant in Doomscript, since the issue is mainly concerned with the inner workings of inventory.