ZDoom

Yes, it does.

I'm just wondering: Does today's slope fix help here as well?

There are no missing textures as far as I can tell.

Hm, I'll just send the map via PM.

The first half of that video looks like you're missing wall textures. You can send me a sample if that's not the case.

The second half looks like the problem this bug report originally opened, which I honestly don't understand. It only happens if you rotate the texture. :( Maybe I should merge my changes into the trunk so I feel safe changing the way aligned flats are handled.

Another error with the slope rendering that looks really bad in my map; something goes horribly wrong with very steep slopes.

Made a little vid out of it (the second bit of it, there's also three other buggy parts of the map in the video.): http://www.youtube.com/watch?v=chyJmay--kI

I hope it's possible to fix it... I can't release the map looking like that. x-x

[quote="Bio Hazard"]I don't think DoomScript can be done easily and effectively with all the other crap iun the engine. I'd fork it off to another branch for development. That way you won't back-up the flow of releases while you are writing that monster.

** EDIT: Here comes another one of those rants I make every time I read about the future of ZDoom, sorry. ***

I'd still go through the code and eliminate all the backward-compatible crap, but nobody wants to do it in fear of breaking some jokewad that nobody really cares about. I say if a great wad gets broken, people will fix it. Look at ZDCMP for an example. .90 broke it and the community rose up and fixed it. Why wouldn't that happen for other wads? I'm sure if a wad is good enough, the community would fix it.
[/quote]

no, No, NO!!!

Backwards compatibility is important. Imagine a Doom port which has constant problems playing vanilla maps. It'd get a massive beating from the community - and a very bad reputation. Wait a minute: such a port already exists and it's called Vavoom...

[quote]
Would it reall be that difficult to branch ZDoom and make a clean engine out of it? SVN makes managing paralell projects very simple. It could have the newest features and be free of backwards compatibility code slowing it down. Graf could put in his GL renderer, the cross-platform could be less hacky, the actors could be moved out of the EXE (via DoomScript), the sound engine could be updated, ACS could get totally rewritten to make it more useful (or just ditch it completly for DS), the filesystem could be totally switched to path-based PK3, the map format could be extended, the code could be tweaked for speed and many other advantages that would just make the current ZDoom [i]huge[/i]. If it was branched, you could still keep [i]the old ZDoom[/i] in development for the backwards compatibility. Again, SVN would make this very easy. [url=http://svnbook.red-bean.com/en/1.0/svn-book.html#svn-ch-4]Go read the docs on branching.[/url]
[/quote]

1. The moment ZDoom is no longer compatible enough with vanilla maps I'll quit. Period. Such a project is not worth developing for IMO.
2. Same for ditching ACS and other stuff that's been used in many, many maps.
3. Any engine that is not backwards compatible is no engine at all (ok, I'm repeating myself)
4. Guess why I re-introduced the sector-based soundtarget code for 2.1.0. The actor based replacement just broke far too many WADs and these were issues that are not easily fixed.

[quote]
Gah, I'm ranting about the future of ZDoom again, who am I kidding? You guys don't want to make ZDoom cleaner. Sorry for wasting your time again, it just really bothers me that you go out of your way to support dirty hacks that [i]we all agree are dirty hacks[/i]...[/quote]

Ranting indeed. Making what you suggest would destroy ZDoom, not save it and therefore it won't happen.

If DoomScript is implemented it will be an extension to DECORATE and in no way interfere with the compatibility code you so despise.

Yeah, ZDoom editing revolves a lot around hacks. A lot of great things you see people doing in ZDoom are accomplished by exploiting this feature, or using that feature in a way it was not meant to be used, etc.

But I still love it... I mean, it's tons easier to edit than, say, Doom 3. :(

I don't think DoomScript can be done easily and effectively with all the other crap iun the engine. I'd fork it off to another branch for development. That way you won't back-up the flow of releases while you are writing that monster.

** EDIT: Here comes another one of those rants I make every time I read about the future of ZDoom, sorry. ***

I'd still go through the code and eliminate all the backward-compatible crap, but nobody wants to do it in fear of breaking some jokewad that nobody really cares about. I say if a great wad gets broken, people will fix it. Look at ZDCMP for an example. .90 broke it and the community rose up and fixed it. Why wouldn't that happen for other wads? I'm sure if a wad is good enough, the community would fix it.

Would it reall be that difficult to branch ZDoom and make a clean engine out of it? SVN makes managing paralell projects very simple. It could have the newest features and be free of backwards compatibility code slowing it down. Graf could put in his GL renderer, the cross-platform could be less hacky, the actors could be moved out of the EXE (via DoomScript), the sound engine could be updated, ACS could get totally rewritten to make it more useful (or just ditch it completly for DS), the filesystem could be totally switched to path-based PK3, the map format could be extended, the code could be tweaked for speed and many other advantages that would just make the current ZDoom [i]huge[/i]. If it was branched, you could still keep [i]the old ZDoom[/i] in development for the backwards compatibility. Again, SVN would make this very easy. [url=http://svnbook.red-bean.com/en/1.0/svn-book.html#svn-ch-4]Go read the docs on branching.[/url]

Gah, I'm ranting about the future of ZDoom again, who am I kidding? You guys don't want to make ZDoom cleaner. Sorry for wasting your time again, it just really bothers me that you go out of your way to support dirty hacks that [i]we all agree are dirty hacks[/i]...

[quote]Knowing Randy's schedule, this won't happen until 2005[/quote]

You were wrong by one year. :(

http://forum.zdoom.org/potato.php?p=8309#8309 - or not? ;)

I kid, I kid.

If that happens I'll familiarize myself with parser generation and do my own thing. Of course due to my limited knowledge that most likely won't be as good as it should be.

- Finally, DoomScript is now part of ZDoom!  DoomScript is a package of various tools and addons to ZDoom that together make up a complete and powerful method to create an unlimited amount of custom content.  DoomScript is made up of the following items:

     - ACS (Including the LOADACS lump)
     - DECORATE
     - DEHACKED
     - MAPINFO

Now you can stop bugging me for DoomScript!!! =)

[quote="Graf Zahl"]I'd rather see DoomScript or a floating point engine. ;)[/quote]

My prediction for the 2.1.7 changelog:

[code]- Finally, DoomScript is now part of ZDoom! DoomScript is a package of various tools and addons to ZDoom that together make up a complete and powerful method to create an unlimited amount of custom content. DoomScript is made up of the following items:

- ACS (Including the LOADACS lump)
- DECORATE
- DEHACKED
- MAPINFO

Now you can stop bugging me for DoomScript!!! =)[/code]
:roll:

I'd rather see DoomScript or a floating point engine. ;)

Secret things? Let me guess: flat decals support, software-based 3-d floors, real-time scalable and rotatable textures and sprites, moving sectors or... *gosh* Polymost!

(okay that's not a guess, that's a wish list. >=))