Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

"one port fits all" projects tend to be inaccurate. Quake had FTEQW which is a Quakeworld engine that can also run Quake2, Hexen II and Quake3 with greatly varying inaccuracy., and that was only really possible since their game logic was all modularized from the start (all with thier own traps/pointer functions and protocols as well) as opposed to Build games which were all hardcoded and would require intense evisceration and debug hell to ducttape together as one.

I'm talking from a very flaky memory here but I believe Hendricks (or another EDuke32 team member) has said that a Shadow Warrior EDuke32 port would be separated at first anyway until good enough to be merged with the main port kind of like how PolymerNG was being treated.

The problem is that unlike other engines the BUILD engine has been extensively modified for each game and development on it split,

You're extensively wrong. Ken didn't make the BUILD source code available to the game teams. They had to link their own game code against his engine library. (Though that didn't stop the badasses at Q Studios from reverse engineering parts of it to change things they didn't like.) The engine did change over time, obviously from v5 (Witchaven, TekWar), to v6 (Powerslave) to v7 (all the good games :o), and with minor adjustments after that as Ken writes in his build2.txt, but the stuff that your average ignoramus considers engine modifications like the ROR in SW and Blood is actually bolted on through portal rendering calls and wrappers to hitscan and clipping functions.

Because of this BUILD games are some of the most "one port fits all"-worthy games on any engine.

Lunick, on 09 April 2016 - 06:26 PM, said:

I'm talking from a very flaky memory here but I believe Hendricks (or another EDuke32 team member) has said that a Shadow Warrior EDuke32 port would be separated at first anyway until good enough to be merged with the main port kind of like how PolymerNG was being treated.

It's not about quality, but rather because merging the games into one executable is an entirely separate layer of work. See above.

I know I'm comparing apples to oranges, but I just think like of all the games that ZDOOM for example can run, and they're all id Tech 1, and Strife has support from being reverse-engineered. I think of a Duke3D hydra that can do Duke Nukem 3D, NAM, WWIIGI, Shadow Warrior, Blood, the Redneck Rampage games, Powerslave (Kaiser's port of the PS1 version to the PC kind of satiated this for me, but as the 3 versions of the game are so different from each other...), and potentially more...

You're extensively wrong. Ken didn't make the BUILD source code available to the game teams. They had to link their own game code against his engine library. (Though that didn't stop the badasses at Q Studios from reverse engineering parts of it to change things they didn't like.) The engine did change over time, obviously from v5 (Witchaven, TekWar), to v6 (Powerslave) to v7 (all the good games :o), and with minor adjustments after that as Ken writes in his build2.txt, but the stuff that your average ignoramus considers engine modifications like the ROR in SW and Blood is actually bolted on through portal rendering calls and wrappers to hitscan and clipping functions.

Because of this BUILD games are some of the most "one port fits all"-worthy games on any engine.

I remember this understandable explanation for programming dummies like me made by the guy who created Chocolate Duke, which is a good read for anyone wondering about how Build works, but I always wondered what part of SW and Blood were changes on the "engine" side of the code. What I mean is, I knew Q Studios made changes to the engine itself (and I heard that was because they were not satisfied with Silvermann's response to their needs), and I always wondered if after DN3D, 3DRealms made or asked Silvermann for changes to the Engine for SW.
For that matter, what about after SW ? Wieder said they were sill working with Build before moving on to Quake engine for DNF, does that include a super efficient and buffed up never released version of Build, or on the contrary just changes on the "game" side of the code? It makes me wonder.

This being said, this means that if you take Powerslave, DN3D and Blood, you have three different versions of the Build engine already; so surely having a "one in all port" already sounds complicated to me.
What happens when you have such a port working and something breaks in it and a new glitch occur, do you have to go through that much more shit to figure out what caused the new glitch ?

Also implying that Powerslave is not a good game deserves some serious whipping, then some lashing, and then some more whipping.

Hendricks, I am sorry if I sounded too negative. I actually appreciete your effort in mantaining SWP and work on ESW. I understand most of that is just inherited from jumble of code original SWP must be. < They are now fixed.
But from where all these glitches came? And no offence to ProAsm, but was it his doing or did very base of it, old JFSW already suffered from those?
(Dont remember well, but it seems to me like even in its day JFDuke was more solid than JFSW.)

EDIT: Just found out newer build was released. Gonna try it out and will let you know later. ;)
---------------------------------------------------------------------------------

FistMarine, on 09 April 2016 - 01:41 AM, said:

I still saved often when I encountered those damn shadow ninjas because of their nasty ability to instantly kill you.

:lol: That is actually one thing I like about Shadow Warrior. That it has its own "Oh sh*t" kind of enemy. You know, that one which makes you immediately reprioritize whole situation. Doom 2 has its archvile, but Duke3D none (well, if you dont count shrinker attack of protector drone, but it can be fairly easily avoided).

Is it just me, or does disabled auto-aim in SW makes game harder and weapons feel clunkier? In Duke3D I prefer to play without it, but here...

Actually, this is true. Fists are among the fastest weapons in the game and they have excellent auto-aim. Punching bees tends to be effective since they won't get close enough to do much stinging while you're throwing punches.

The gas bomb also works if they're in a confined space.

This post has been edited by Inspector Lagomorf: 10 April 2016 - 08:49 AM

:lol: That is actually one thing I like about Shadow Warrior. That it has its own "Oh sh*t" kind of enemy. You know, that one which makes you immediately reprioritize whole situation. Doom 2 has its archvile, but Duke3D none (well, if you dont count shrinker attack of protector drone, but it can be fairly easily avoided).

Battlelord? It can mow you down in seconds.

MrFlibble, on 10 April 2016 - 08:41 AM, said:

I think I'd use Uzis on them, although I don't remember if this works well with auto-aim turned off or not.

The initial encounter yes, but subsequent encounters if you have the shrink ray, you can get rid of them easily. I think the fat commanders are kind of like this too because they shoot rockets, but with that shrink ray...

The initial encounter yes, but subsequent encounters if you have the shrink ray, you can get rid of them easily. I think the fat commanders are kind of like this too because they shoot rockets, but with that shrink ray...

You need to crouch and aim at his balls. :D In EDuke32 it's much easier since you can disable autoaim.

But this is the "top priority" enemy in Duke, comparable to Doom's Archvile. The Protector Drone isn't powerful enough to cause damage unless you're hit by his shrinker blast. Assault Commander fires rockets, those are easy to avoid. Pig Tanks are slow.

This post has been edited by Duke of Hazzard: 10 April 2016 - 09:41 PM

I did notice that the shrinker seems to be less effective than in the vanilla game. I don't know if it's autoaim-related but in the vanilla game, if that projectile hits them, they are going down. With EDuke32 sometimes the projectile definitely hits them and does nothing so it can take a second or even a third (all of them direct hits) to get them to shrink.

The Shrinker as a weapon deals no damage. Its effect is triggered by the enemy being within the blast radius, which is too small for the Battlelord.

It's possible to make the Shrinker always shrink the enemies, if you add damage code to it. A value of 1 is enough. The Battlelord's hitbox is quite large, so if the hit registers, he's shrunk by the blast. The way it is in the vanilla game, weapons reliant on blast radius damage (all the explosives, and the Shrinker) are more effective the closer to the ground the hit lands. Hence why, to shrink the Battlelord, you must aim at his feet (or balls).

In Duke3D, there is Mini Battlelord that can deal a lot of damage and even kill you pretty quick, at least if you are close to him.

Problem with Mini Battlelord is that he mostly behaves as stationary turret, or in Doom allegory - chaingunguy. This lack of more dynamic movement makes him easier to deal with for more maneveurable players, especially if various covers are provided. And not counting his allergy to shrinker. (Do you use it against him, or rather consider it cheating?) He is IMO most effective in long open corridors with lack of cover. Of course he also brandishes mortar with which he loves to spam those grenade mines everywhere and I actually sometimes take more damage from them, especially in heat of big battle when I lose track of them and just ram into them like fool. :D

Quote

The Protector Drone in my opinion isn't that much of a treat, sure the shrink attack can easily put you into a hopeless situation but the shrink rays can be easily dodged.

Maybe as threat not that big. But I had in mind enemy, that creates unpredictable situations and can quickly turn tables. And his shrinking attack seems closest to that. But yeah, in most situations, it can be rather easily avoided. And even if everything else fails, you can still count on steroids to make you immediately grow back to normal.

For some reason I've always assumed that you need to hit a Mini Battlelord with shrinker a couple of times before it works. I guess I got this impression because the first shot(s) would miss, and then drew an analogy with Will Rock where when dealing with non-boss Cyclops (who are kind of like what Mini Battlelords are to the first episode's boss) you need to hit them several times with the crossbow or acid gun before they are affected (regular monsters are instantly affected by these weapons).

Only 80 sectors left in my map (I don't wanna go up the old limit, I want it to be playable in DOSbox). Still got several days of work on it at the very least before release though, plenty of small things need to be checked or finished.

Here is a sneak peek, though looking it at makes me realize I need to improve those mountains in the back, among many other things... This thing is too big.... at first I wanted to make a "classic style" map but got carried away, far far away.

I just dont understand why 3D Realms didnt set this defaultly. If this was meant to be as measure to prevent players from shrinking Battlelord, they should just acustomized his code to it. :huh:

They did intend the Shrinker to work on Battlelord. They even increased its explosion radius on Atomic Edition in order to make it more likely. They did not set the damage of the weapon to 1 because they did not want it to cause damage (ironically 1 does zero damage because of how the damage code works).

Could you help me out find one old map? It was some sort of battleship near coast with bunkers.
You could control turrets on it and even control remotely or hop in and pilot directly some sort of helicopter. I remember being impressed by its interactivity of it and how author managed to create flying vehicle. It was singleplayer map with monsters and detail wise, it seemed older. Thanks for help. ;)