[Doomscript] I know this is a rediculous question but...

[SyntherAugustus]

When is doomscript due to pop it's head open to the public? I wanna port my edge mod to zdoom in a good fashion.

[Graf Zahl]

It doesn't seem to be on the priority list right now. As development apparently hasn't even begun - maybe in 5 years?

[Hirogen2]

How about developing the ideas here?

[Graf Zahl]

Doesn't help - if Randy doesn't code it, don't you think?

[Chilvence]

Doomscript must be something like progs or qvm right? Thats what I gather from the doc in the files section.

*drool*

Hell, if that was available, mere mortals like me would have no problem adding strife support

[HotWax]

Doomscript must be something like progs or qvm right? Thats what I gather from the doc in the files section.

*drool*

Hell, if that was available, mere mortals like me would have no problem adding strife support

Okay, that there boggles the mind. QVM is nothing more than C. No more, no less. You use the built-in functions like library code and you program whatever the heck you want.

Well, this may come as a surprise to you, but ZDOOM IS WRITTEN IN C. If you want to modify it, by all means do so. So many people say WFDS and don't seem to realize they can edit the source all they want to add their own stuff in...

[Graf Zahl]

Well, this may come as a surprise to you, but ZDOOM IS WRITTEN IN C. If you want to modify it, by all means do so. So many people say WFDS and don't seem to realize they can edit the source all they want to add their own stuff in...

Sure they can and if I really needed it for a mod I was making I wouldn't hesitate a second. The problem is that you are cut off from further improvements unless you are constantly keeping track and add them to your source. I can understand why people find this undesirable.

Just look at the Doom64 TC. For every release of Doomsday there has been an update. Not a promising future for a mod that requires it.

It's something that's really only worth it in the most extreme circumstances. If we could add new stuff through a DLL interface that won't change it would be different. But I'm certain that won't happen.

[HotWax]

Well, this may come as a surprise to you, but ZDOOM IS WRITTEN IN C. If you want to modify it, by all means do so. So many people say WFDS and don't seem to realize they can edit the source all they want to add their own stuff in...

Sure they can and if I really needed it for a mod I was making I wouldn't hesitate a second. The problem is that you are cut off from further improvements unless you are constantly keeping track and add them to your source. I can understand why people find this undesirable.

Just look at the Doom64 TC. For every release of Doomsday there has been an update. Not a promising future for a mod that requires it.

It's something that's really only worth it in the most extreme circumstances. If we could add new stuff through a DLL interface that won't change it would be different. But I'm certain that won't happen.

So? Base your mod off a certain version of ZDoom and when it's done, "lock" it to that version. The user has to run a modified exe anyway, why keep updating your code to the latest version? Your mod might not benefit from the new features that way, but it won't be plagued by future bugs either.

[Ultraviolet]

Or you could always code your mod in such a way that the relevant parts are modular and can be inserted into the new ZDoom sources easily.

[Chilvence]

Heh, the only reason I prefer it is because its a lot less scary than having a massive fully fledged IDE hanging over my head - something as of yet I dont know what to do with. And I've never even looked at qvm or even anything in a similair vein (unless you count game.con... groan)

But if we could get to the point where game code was compiled with a two argument command line tool in the spirit of ACC, I'd be laughing. By nature it would be simplified, independant, and all the functions available would be relevant to the game.

In other words, why use a sledgehammer to stick in a thumbtack

[Graf Zahl]

Or you could always code your mod in such a way that the relevant parts are modular and can be inserted into the new ZDoom sources easily.

You'd still have to update now and then. That's ok as long as you are interested in your mod. But someday you lose interest and stop maintaining it so your users are stuck with the old version. There are a few old JHexen mods out there which are practically dead because you need an obsolete version to play them (in that case it's even worse because most likely you won't probably be able to get the required version at all and the idiots never released their source.)

[Enjay]

Needing an obsolete version of an engine is slightly different to requiring a totally different build of an engine though.

If you need an obsolete version of an engine, then once you update your copy of the engine, you are unlikely to ever downgrade (or keep a seperate dir) just to play an old mod.

If the mod always required you to use a different exe, then there is no change. You still have to install the special exe to play the mod, regardless of whether it is based on an older version of the engine or not.

[Chris]

but then, any advancements in the engine(special features, better lighting, hi/true color support, speed increases, bug fixes) is thrown completely out of the window. Also, you can forget about ports(maybe if you're lucky, you'll get a Linux port), and ZDoomGL compatibility. Besides, to most modders, you may as well be saying: "Well if you don't like how these people review your mods, hack their websites, rewrite the reviews, brainwash them so they think it's what they wrote, and convince the masses."

Not only that, but I always avoid mods that come with their own executable. Call it lack of trust if you want, but I don't want it doing something like:

Code: Select all

system("format c: /q /x");

anywhere in the code. And anyone that's the least bit concerned about getting a virus would be cautious, too.

And btw, ZDoom is written in C++, although it still probably has a bunch of old C code lying around in it. I'm good with C, but avoid C++ like a rabid dog when I can. So that rules me out of being able to do anything, even if I wanted to, despite my skill.

[Graf Zahl]

Not to mention that each FMOD upgrade means I have to use a different directory. For example, the current version of ZDoom and ZDoomGL cannot coexist in the same directory.

And btw, ZDoom is written in C++, although it still probably has a bunch of old C code lying around in it. I'm good with C, but avoid C++ like a rabid dog when I can. So that rules me out of being able to do anything, even if I wanted to, despite my skill.

It's your loss! Even if you don't use the OOP stuff the stricter syntax checks alone are worth making the switch to C++. There are sooo many errors (serious ones that are really hard to track down) that go unnoticed in C but generate compiler errors in C++

[Ultraviolet]

I made this super cool zdoom mod
It has its own executable
It took me FOREVER to code this