Welcome to the ZDoom Forums!

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.

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

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

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

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

Some new lyrics would spice things up.

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

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.

Zippy wrote: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.

Xtyfe wrote: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.

Xtyfe wrote: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".

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.

Major Cooke wrote:Because no one knows the status of doomscript, and what it will be capable of doing. Only Randy really knows what it will be about because it's his baby. It was first announced back in 1999, was it not? So why not allow for alternative options in the mean time?

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.

Graf Zahl wrote:I'm sorry but this is all just a crutch for the lack of real scripting.

Because no one knows the status of doomscript, and what it will be capable of doing. Only Randy really knows what it will be about because it's his baby. It was first announced back in 1999, was it not? So why not allow for alternative options in the mean time?

I think your remark is even less necessary than mine. I have always been long-winded when communicating in human-language. Conversely, I am more succinct than most programmers I know when writing code. (Fewer intermediate assignments, minimal inclination to make an explicit (X != NULL) condition for an (X) condition, even though the optimiser probably knows how to handle it.)

I can be succinct though, once I've read my words and figured out what they mean: I'm very comfortable not having the final call on what goes into zdoom and exactly how the implementation should look, and I do hope Graf's headaches are relatively benign.

Well, that was long winded

Nearly everything I have submitted has been at least very near WFDS. I feel that the existence of (at least the basic) actor pointer selectors (AAPTR_TARGET) and such is a viable generalisation of such a concept as A_GiveToTarget, because we would otherwise get a growing plethora of such specialised per-pointer duplicates of functions. A_Warp is also very suitable as a highly flexible and decorateable jump method.

The rest... ACS string manipulation (the first take was rejected, the accepted version was a direct response to Graf's technical). Pointer manipulation. And now owner reference. I would find use for these. If I ever complete a project, it will probably involve some of these, even if they're not in zdoom; I can do, and therefore I can barely contain myself.

Graf is more... sober. Occasionally I find him overly restrictive, but there is little I'd put into zdoom without verification from either him or randy even if I were able. Adding properties to players (not this submission) is slightly new to me, adding a new implicit cast for TObjPtr<T> (my suggested solution to maintain const-ness in the VisibilityFilter submission); these are things I find out how to do, but cannot fully verify. Graf occationally says "you cannot do it this way", or "you can not do that". When it is the former, I might find another way. When it is the latter I grumble a bit and put my fancy new thing aside.

I submit everything I do in the spirit of sharing, and in the faint hope that the official zdoom.exe will support my project, should it ever come any further. Oh, and sometimes I submit it because somebody around here really wants it and hopes that it can become part of the engine.

(By the time I get that far, Doomscript may be real though; I'm not sure my overall mapping speed exceeds randy's coding celerity.)

Bottom line: You think you want me among the devs, but you probably have me just where you need me.

One thing though: What's the necessity for the new code pointer?

In my kind of usage it is to have a direct relation between an implementation object (typically a weapon or custominventory) that should contain all its own special features without expecting or modifying anything in particular on the affected object (usually a player). The OWNER keyword only allows you to switch context to state owner, it doesn't allow you to combine information between the two. Storing the related actor in any pointer allows the flexible stable and reliable mechanisms already in place to provide the missing power to use data and implementations from one object on the other, especially through acs library script calls that are capable of changing activators.

Summary: I made it to allow me to keep the special objects generally applicable, with potentially no special requirements to the object they affect.

Xtyfe wrote:Anyone else think FDARI should have SVN access? he seems to be the only one actually doing any developing these days.

Sorry, no, I disagree.

I like his enthusiasm but there's a good reason why I so rarely add his features. This one, like all the rest of the pointer copying just gives me headaches. What's the necessity for the new code pointer, for example? Why do we need yet another method to copy around pointers? I'm sorry but this is all just a crutch for the lack of real scripting.

This is all just one new feature heaped onto the last with no real underlying design goal.