[Mia Max]

DeeperThought, on Jul 15 2009, 11:39 PM, said:

The machine gun is good and will be a functional stationary gun. The trees are all fine. Duke 3D is very lacking in trees (I am tired of looking at palm trees). I remember that there is a tombstone in the original art which should have an HRP model by now. Can you check that? I will accept two of those tombstones, but I'm not sure which two. The coffin looks good and could be useful in other maps, although it is the sort of thing that could be built out of sectors. I don't like the statue head very much. I'm assuming that the golden gun and DNF hand skin are not part of what you are suggesting.

@Spiker: The only time you would see the models is when you play a map that uses them, so if you hate them so much then just don't play those maps.

Good to know that you like the trees.
I couldn't find a tombstone in the original art. However, I just would like to have the one at the very left. The other tombstones can easily be built with sectors.

Well, I will do some fine-tuning on the trees and then I send you the pak. I guess you won't need the con file for the gun, cause it's pretty much the same as the one used for the cannon.


EDIT: The golden gun and DNF hand skin are from daniel262b. http://forums.duke4....?showtopic=1087

[Jimmy]

DT, I may be able to supply with you 8bit counterparts to the trees, tombstones, and possibly the machine gun. Send me a PM or message me on MSN if you're interested.

[chicken]

Maybe we could start something like an "Alternative HRP" in which we could include models like that.
That would enlarge the repertoire for mappers enormously.

I don't know if DukePlus would be the right platform for this, maybe it could include the 8bit-artfiles (or they could be distributed together with the map) and the AltHRP could be offered as a separate download.

I think it would be a good idea to offer a new batch of highquality artwork that is organized by the community somehow.

Just a thought...

[Spiker]

DeeperThought you know how to bite one's ass. Exactly a year ago you were strongly against including any new art for my map (because of the size) but if now you want to accept every average model that's ok. I just thought that the art included should fit and could be used in more than one map. Otherwise much stuff will appear just once in that single map. Anyway be sure to include these bush models by Hellbound. The best bush models on the net.

Attached File(s)

•  bushes.zip (478.94K)
  Number of downloads: 669

[Danukem]

Spiker, on Jul 16 2009, 01:40 AM, said:

DeeperThought you know how to bite one's ass. Exactly a year ago you were strongly against including any new art for my map (because of the size) but if now you want to accept every average model that's ok. I just thought that the art included should fit and could be used in more than one map. Otherwise much stuff will appear just once in that single map. Anyway be sure to include these bush models by Hellbound. The best bush models on the net.

They are good bush models.

A lot has changed since one year ago, but as I recall you wanted to have normal soldier models for the Duke bots, which I would still be against today.

I'm just going to allow the models to accumulate in this thread until I have some time to deal with it. I have to finish up some stuff on WGR2, then I am going on a trip that will last until the beginning of next month. When I get back it will be almost time to release the first episode of WGR2 so I'll be busy with that again. I probably won't do much with DP until late into August, so there will be plenty of time for people to present better models if they choose.

[Spiker]

I desperately need an ability for the DP canon and possibly a player to move together with a slidedoor sector. I tried setting statnum on the canon to 2 but it didn't work. It's a matter of having another Duke Plus map. I just have to make this fucking canon move with the sector!

[supergoofy]

Bug report:

Testing shrinker and shrunk enemies



As you can see this liztrooper couldn't grow up normally
Devastator seems to not have any effect on shrunk enemies
In fact when I used it in the liztroop, he stopped growing and and then he stayed in the small size you see in the picture above.

I also tested pigcops, octabrains and the fat guys that throw rockets.
The rocket launcher can kill the shrunk enemies, but not instantly. The shrunk enemy first grows up and then dies.
Pistols also have no effect to shrunk enemies.
Shotgun seems to kill shrunk enemies. So I suppose it works fine.

That's my quick report.

[Danukem]

supergoofy, on Jul 16 2009, 08:14 AM, said:

Bug report:

Testing shrinker and shrunk enemies



As you can see this liztrooper couldn't grow up normally
Devastator seems to not have any effect on shrunk enemies
In fact when I used it in the liztroop, he stopped growing and and then he stayed in the small size you see in the picture above.

I also tested pigcops, octabrains and the fat guys that throw rockets.
The rocket launcher can kill the shrunk enemies, but not instantly. The shrunk enemy first grows up and then dies.
Pistols also have no effect to shrunk enemies.
Shotgun seems to kill shrunk enemies. So I suppose it works fine.

That's my quick report.

Well, I must say, I'm a little mixed up right now about how this is supposed to work. The other day when you said it was a bug that monsters could only be killed by stomping when shrunk, I tested it in the unmodified game. I found that liztroops, at least, could be killed by both explosives and bullets when shrunk. So at that point I figured that DP really did have a bug and I made a simple change to fix it. But after some more testing, it's obvious that the AI in the original cons is not designed to have monsters getting hurt when shrunk. For example, if you shoot a liztroop a few times and he survives, he can start shooting back and acting normally but continue to be shrunk forever. This is what I experienced when playing without DP, using only the CONs in my duke3d.grp. Now maybe that grp was not copied directly from my cd and had changed cons, but I doubt it. Another possibility is that there was some hardcoded stuff in Duke that put restrictions on shrunk monster behavior, and that hardcoding was mistakenly removed from EDuke32 somehow. But that doesn't seem very likely either. So I don't know what the hell is going on. I sure don't remember monsters ever being shootable by bullets when shrunk, and allowing them to be shot opens up a can of worms. You see, when monsters are hit, they change their AI to counterattack or flinch, etc. This changes them away from their shrunken AI and messes things up. I can try to fix this, but it means going into the code of each individual monster and making changes, maybe substantial ones.

What I really want to know is, are shrunk monsters supposed to be hittable with bullets and explosives? I just don't remember it working that way.

[The Commander]

DeeperThought, on Jul 17 2009, 08:24 AM, said:

What I really want to know is, are shrunk monsters supposed to be hittable with bullets and explosives? I just don't remember it working that way.

Definitely not hit scan weapons, though I'm not 100% sure on explosive type.

[Danukem]

Hmmm, I think they are supposed to change to cstat 0 when they shrink. That would prevent them from blocking or getting hit with bullets. Then they cstat 257 when they grow. But then why was I able to shoot monsters with bullets (and get buggy results) when I played with normal CONs just now? Perhaps something changed in EDuke32 that forces the hitscan bit on monsters?

[Sangman]

In vanilla Duke, you could harm monsters with explosives, but they would only blow up or die when they had grown back. Sortof like how you can shoot a Liztroop sitting on a toilet, but it won't actually die until it stands up.

[supergoofy]

Well, DeeperThought you have right. The original game seems to have similar behavior with shrunk enemies.

I think that it's not a big issue. After a lot of testing I would say that the code about shrinking and shrunk enemies needs a rewrite. Anyway for now Duke Plus is fine.

When you later find some time look at this. It's not that important though.

Sorry for troubling you.

[Danukem]

supergoofy, on Jul 16 2009, 01:43 PM, said:

Well, DeeperThought you have right. The original game seems to have similar behavior with shrunk enemies.

I think that it's not a big issue. After a lot of testing I would say that the code about shrinking and shrunk enemies needs a rewrite. Anyway for now Duke Plus is fine.

When you later find some time look at this. It's not that important though.

Sorry for troubling you.

The original game is not supposed to work that way. I believe this is an EDuke32 bug. Looking at the original CON code, it contains nothing that would prevent shrunk monsters from getting shot and the ensuing buggy behavior (such as the monsters shooting back and never growing). Therefore, there must have been something hardcoded which prevented shrunk monsters from getting hit. Maybe it forced the hitscan bit off on small badguys? In any case, whatever the hardcoded thing was is not working in the current EDuke32. Not that it wouldn't be cool to have shrunk monsters getting hit, but it would mean changing the AI on all the monsters and I don't have time right now.

[The Commander]

Yes, I just looked myself. It seems to be something Eduke32 related as I'm sure you could never hit a shrunk monster in vanilla duke with hit scan weapons. As soon as I hit a liztrooper it would resume it's normal behavior with out resizing it's self.

[Sangman]

I can recall that before Jonof or even the source code was around, I was attacked by a little miniliztrooper who got stuck in his shrunken state. I don't remember how I pulled that one off, it might have had something to do with the freezer weapon.

To be sure you'd have to launch the original Duke exe with Dosbox and do some testing.

[Danukem]

Ideally, all the enemies should have their code modified so that they can be hit by weapons when shrunk, but then grow back to normal size (if they survive) and resume normal behavior. And actually, there is nothing wrong with a little liztroop shooting you or using his jetpack when small, so long as his shots are tiny and only do 1 damage, and he flies at a slow speed as befitting his size. Likewise for other monster behaviors. But it's a lot of work to code small versions of everything.

[Sangman]

DeeperThought, on Jul 17 2009, 12:39 AM, said:

But it's a lot of work to code small versions of everything.

Which is probably why 3DR didn't want you to shoot at shrunken monsters..

[atlas]

i have a request. I understand that the new effects, textures, and custom art and sounds are there for mappers to use, but can you make it possible so that when you revert back to classic settings it removes all DP features? i mean i love DP and the DP maps, but sometimes i want to go back and play the classic maps without any modification. I'm not asking you to remove the features - leave them there for those that want them and for the DP maps.. but it would great to be able to play classic duke and duke plus side by side, without having to use two different eduke32 versions. unless there is a way that you can play classic duke and mods through eduke that i am unaware of.

[Sangman]

So you want to play Classic Duke without Duke Plus? Easy way: Don't use Duke Plus, use Eduke32 in classic mode.

[Danukem]

Run eduke32.exe. The start window should come up and there should be a little box for "Custom game content directory". Select None (if you have DukePlus selected, it will use DukePlus).

If the game just starts without a start window, that means you have disabled it. You need to re-enable it in the EDuke32 menu, then quit and start again.

[atlas]

oh! right on then.. now if i'm using duke plus and a new version of eduke32 comes out.. how to update eduke32 without harming duke plus?

[Sobek]

I love to nitpick. Just getting that out of the way...

I was wondering if you might be able to fix / improve two small things. The first is with the sleeper effect (again!), it's great that the player's viewpoint can now be locked, but I noticed that while they can't jump, they can still crouch. Is it possible to disable the crouching during the sleep transition too? It's a bit wierd being able to crouch up and down while trying to fall unconcious (and some impatient players might try and spam random keys - as they do. Just a bit of an immersion breaker I feel).

The other thing was with the fireflies. I know you're doing some other tweaking to them as it is, but I was really hoping it'd be possible to alter the speed they move at via a CSTAT or additional tag or somesuch. I had a great idea to simulate a distant firefight / battle in space using some really small & fast moving fireflies buzzing about another model (that is under attack). It looks great as it is, but if they could move much faster that'd be perfect. I was also wondering if the strength of light they emit under the Polymer renderer can be reduced or adjusted in Mapster, without needing to go digging around the CON or DEF code for them. At the moment they seem equivalent in intensity to a Xenon globe!

*edit* I'm not sure what you've got planned to keep the fireflies from clipping through walls, but what are the chances of being able to tag a sprite to act as a blocking wall against them? That would allow you (the mapper) to setup a 'box' of any size using sprites that they could be contained within, or even create an invisible passageway to funnel them through (maybe even by using the invisible hitscan sprite?)... Just a thought.

You know, if you have the time or the care

[The Commander]

atlas, on Jul 17 2009, 02:30 PM, said:

oh! right on then.. now if i'm using duke plus and a new version of eduke32 comes out.. how to update eduke32 without harming duke plus?

Just download the new version of Eduke32 and extract it to the Duke Plus folder and overwrite your existing Eduke32.exe and Mapster32.exe. It will not harm Duke Plus in any way. (Though there are exceptions to this that I wont get into)

[TerminX]

Think I found a bug in DP just now... I had just fired the last shell that was loaded in the cruiser shotgun and picked up a chaingun before the first shell had been reloaded. Chaingun wouldn't fire until I switched back to the shotgun, let it reload a bit and switched back to chaingun.

Edit: btw, that "alien technology at its finest" quote gets really annoying once you've heard it 10 times in a level.

[Danukem]

TX, on Jul 17 2009, 02:25 PM, said:

Think I found a bug in DP just now... I had just fired the last shell that was loaded in the cruiser shotgun and picked up a chaingun before the first shell had been reloaded. Chaingun wouldn't fire until I switched back to the shotgun, let it reload a bit and switched back to chaingun.

I just uploaded some code which should fix that. It also reduces the intensity of light given off by lightbugs, adds jetpack on/off sounds when it is activated in the new double-jump way, and should prevent the player from crouching during a scene transition effect.

[TerminX]

Another bug... hold down alt fire with the freezer, and then hold down primary fire and release alt fire. It still acts like alt fire is held instead of primary fire. This also happens if you release alt fire and press primary fire simultaneously.

[LeoD]

"Alien technology" cannot destroy turrets.

[Danukem]

TX, on Jul 17 2009, 03:45 PM, said:

Another bug... hold down alt fire with the freezer, and then hold down primary fire and release alt fire. It still acts like alt fire is held instead of primary fire. This also happens if you release alt fire and press primary fire simultaneously.

Fixed. That happened because I had the code for switching back to primary fire in EVENT_FIRE, but the freezer is one of those automatic weapons that doesn't trigger EVENT_FIRE again if you hold down the key.

[Danukem]

LeoD, on Jul 17 2009, 03:54 PM, said:

"Alien technology" cannot destroy turrets.

Yes it can. I just tested the laser pistol against a turret and it killed it just fine.

[LeoD]

Hm, it seems to be a matter of the position to the Turret.
Try this one in E3L1.

Attached thumbnail(s)

•