The WIP Thread

DoomRater · Post by **DoomRater** » Thu Oct 04, 2007 9:23 am

I don't think ZDoom will throw an error over it, right?

HotWax · Post by **HotWax** » Thu Oct 04, 2007 11:39 am

No, it will simply ignore it.

Zippy · Post by **Zippy** » Thu Oct 04, 2007 2:29 pm

Unless ZDoom gets a new flag to A_SpawnItemEx with flag 128, at which point compatibility breaks. Functionality of existing ZDoom maps which use it would or wouldn't break depending on what said hypothetical flag does.

DoomRater · Post by **DoomRater** » Thu Oct 04, 2007 2:35 pm

Like Graf's gonna want to do that.

Anyway, here's a shot of a gun I'm taking pics of to attempt to Doomify since I thought it looked so badass (may have to retake these with a better camera): http://img213.imageshack.us/img213/9967 ... adymi8.jpg

Post by **Nash** » Thu Oct 04, 2007 2:36 pm

Wouldn't have have really weird effects if the actor spawned with that flag has collision properties? Like it's solid or something?

Zippy · Post by **Zippy** » Thu Oct 04, 2007 7:15 pm

It's possible, but that's for the SkullTag coders' to worry about.

DoomRater wrote:Like Graf's gonna want to do that.

I suppose it depends. I doubt the client side flag can't be backported to ZDoom unless it changes networking model, so it doesn't have a value in that regard. But when it comes to Graf I suspect the decision would rest on just how many ZDoom maps use the flag, either for intended SkullTag support or for the hell of it, and thus how many maps would be broken by a new ZDoom flag. If there's not a whole lot to lose, then I can't see him really caring.

DoomRater · Post by **DoomRater** » Thu Oct 04, 2007 8:24 pm

Right now I can take a Skulltag map and run it in ZDoom for the most part. Some things are missing but the map still works. Why break a good thing? Maybe 128 will mean something concerning demo syncing on ZDoom's side (something Skulltag doesn't have AFAIK?)

Zippy · Post by **Zippy** » Thu Oct 04, 2007 11:51 pm

DoomRater wrote:Why break a good thing?

I don't know. Sometimes the situation calls for it. It's really also could happen for any of a number of unpredicted reasons. It also just may never come to ZDoom needing an extra A_SpawnItemEx flag. Compatibility with SkullTag is an overall good thing to be sure, but it's cracks like this that threaten that. Personally I think the burden of compatibility is on SkullTag's side. I don't know how far the developers intend to go with maintaining friendly compatibility relations, but to me SkullTag is a specialized offshoot port, as opposed to ZDoom which is more general and base, so SkullTag needs to be maintaining compatibility with ZDoom if they want it.

HotWax · Post by **HotWax** » Fri Oct 05, 2007 9:26 am

Sorry, Zippy, but that post is a steaming pile of shit. (and I mean that in as nice a way as possible.)

There is absolutely no harm in ST implementing a useful flag that happens to only make sense for their port.

On the contrary there would be very much harm in Graf (or another coder) blatantly ignoring ST's flag and intentionally breaking compatibility.

The flag is known to be used by a ZDoom port. The smart thing to do would be to put a note in the source code marking flag 128 as "reserved by SkullTag" so it doesn't get accidentally used.

And what if SpawnItemEx does have need for a new flag? Oh no, what to do then!?

Um...

256
512
1024
2048
4096
8192
16384
32768
65536
.
.
.

Duh.

DoomRater · Post by **DoomRater** » Fri Oct 05, 2007 9:38 am

Not to mention that unless ST added demos recently ZDoom can always use the flag for demo syncing sensitivity (might add less demo overhead?)

HotWax · Post by **HotWax** » Fri Oct 05, 2007 10:04 am

While that's certainly a possibility, I'd shy away from it. You never know what may happen down the road. If ST at some point does implement support, then they'll be stuck having to find a new flag number to use to do the same thing ZDoom's flag 128 would do... which then ZDoom would have to mark as reserved. In short, it would be a mess. The same would hold true if at some future point randy decides to implement a C/S model into ZDoom.

As unlikely as either possibility is, there's still a slight chance of either happening and it would just be better coding practice to avoid such conflicts.

There's just no reason not to leave 128 as an unavailable flag permanently (or until the same facility becomes useful to ZDoom). Even if you run out of numbers, you can just move on to a second (or third, or fourth) flag argument.

DoomRater · Post by **DoomRater** » Fri Oct 05, 2007 10:08 am

Now that I think about it, why would it need a different one? People don't play demos over a network. Or basically, change the description to Lazy Syncing.

Zippy · Post by **Zippy** » Fri Oct 05, 2007 12:06 pm

HotWax wrote:Sorry, Zippy, but that post is a steaming pile of shit. (and I mean that in as nice a way as possible.)

Oh, don't worry about that. I think we've dealt with each other long enough for me to know that that's just how you express your endearment.

Yeah, it's not a serious issue because there are ways around it. I still think that it is SkullTag's concern, though. I think they could have taken a more compatibility friendly approach (maybe attaching client-side-ness to specific actors, etc.). I just don't see it as ZDoom's concern if it were to get in the way as a problem, in part because it doesn't appear to me that development between the two is tied closely enough together to merit it. There's also the matter that the directions between the two ports are different, and how far things will diverge/converge as the developers of their respective ports decide in which direction they want to continue or what direction they are willing to part from.

Also, what got me giggling the most about this:

HotWax wrote:there's still a slight chance of either happening and it would just be better coding practice to avoid such conflicts.

There's just no reason not to leave 128 as an unavailable flag permanently (or until the same facility becomes useful to ZDoom).

My, my, how the tables have turned! This seems to be somewhat the opposite of the HUD discussion.

HotWax · Post by **HotWax** » Fri Oct 05, 2007 1:15 pm

Maybe I'm missing something, but I don't see how the two have anything to do with each other.

Unless you're making the assumption that intentionally withholding changes to the HUD code is "good coding practice", which is an opinion I don't share in the least.

Post by **Nash** » Fri Oct 05, 2007 1:30 pm

The reason why I love visiting the ZDoom forums is to read Hotwax-Zippy discussions.