EDuke32 1.4.0 beta 2 released

[Ding Bat]

I noticed that the Caption Mode has changed starting with the 1.4 beta.
Sprits no longer show thier identification, only SectorEffectors and Sectors show thier ID.
Is this a BooBoo, or was there a reasons for this.
To be able to see all sprites ID is very cool, instaed of having to go back and forth from 2D to 3D.
I'm using Mapster Snapshot 20060130. I like that very much.

Oh yes, i did go through the 8 modes of the '3 caption mode.

[TerminX]

I didn't change anything. Perhaps your names.h is missing?

[DeeperThought]

I have a mystery malfunction here. As a way of seeing how different animation sequences look in the game, I have been using an actor that is spawned by a weapon.

define TESTACTOR 2391

action TESTRUN -2 23 1 1 100

useractor notenemy TESTACTOR TOUGH TESTRUN
sizeat 64 64
ifactioncount 23 killit
enda

In this case it is set to start at the first scrap tile, play them slowly, and then stop after the last scrap tile. It starts in the right place, but then it plays the animations at high speed and goes all the way to the end of the art file. It has never done this before, but I hadn't checked it since getting the new beta or snapshots.

However, if I define TESTACTOR with a different number, say 1950, and then use

action TESTRUN 440 23 1 1 150

...then it works fine (the same tiles it was supposed to play in the first case). So it would seem that whether action works correctly can depend on the tile that you define the actor as, or the offset you use. Note that in neither case did I define the actor as something that already had a definition.

[TerminX]

Maybe the problem is with using such a long delay, who knows.

[DeeperThought]

Originally Posted by TerminX

Maybe the problem is with using such a long delay, who knows.

But it works fine with the exact same delay and everything else, as long as I start from a different tilenum and change the offset accordingly.

[TerminX]

Well, one of the lines you pasted has a delay of 150, and the other has a delay of 100, so I logically did not assume that you used the same delay.

Does it work with a lower delay or does it not?

[DeeperThought]

No, it does not work correctly with a lower delay. It still plays too many frames, and too fast. I tried it using this code, then spawned it in a map with the console:

define TESTACTOR 2391

action TESTRUN -1 30 1 1 25

useractor notenemy TESTACTOR TOUGH TESTRUN
sizeat 64 64
ifactioncount 30 killit
enda

[Ding Bat]

Originally Posted by TerminX

I didn't change anything. Perhaps your names.h is missing?

Ahh.....you are so smart, me so dumb.

That was it. Thanks TX and for the rapid responce.

[NightFright]

I just want to express my gratitude for this cool new eDuke32 release. After thorough playtesting, I have learned to love all the new features it has to offer. It already starts at the menu with the options blinking when selected or the new menu background (I hated that "slime" tile or whatever that was).
Everything else works quite fine as well, as far as I can see. Great work, TerminX - and anyone else who is/was involved!

What I´d really like to see in future versions is
- OGG playback (which of course is announced and coming anyway),
- Antialiasing settings (I know you can do that via drivers, but I´d really prefer to leave everything on "Application-controlled", as I use this setting for most modern games now) and
- a solid solution for the distorted weapon models.

[TerminX]

JonoF was working on anti-aliasing but I don't know that he got it working.. I just force 4x on everything though the control panel anyways. You can try fooling with the "glmultisample" variable in the console.

[Piterplus]

Is there any "anti-alphahack" in new eduke? Model 479 (radardish) is looks completely ruined in last port. Or it (model) should be redone to avoid flickering effect.

[Parkar]

Originally Posted by Piterplus

Is there any "anti-alphahack" in new eduke? Model 479 (radardish) is looks completely ruined in last port. Or it (model) should be redone to avoid flickering effect.

The two old alpha methods has been replaced with a new better one(hence the alphahacks being removed). The problem with the radar dish is probably that it has intersecting polygons with alpha on. To fix it one must split the polygons along the line they intersect. Considering even ue2 has this problem on static meshes this is probably the only solution(also Plagman says it is).

[MagNet]

Hm split.

[Killd a ton]

Or we could site down and wait for some one to make alpha methode version 3, then again it is already working better then in half-life 2

[Parkar]

Originally Posted by Killd a ton

Or we could site down and wait for some one to make alpha methode version 3, then again it is already working better then in half-life 2

Like I said, there is no workaround for that other then split the polygons, either in the engine or by hand. I think spliting by hand is the best option, at least on models. Engine splitting them on sprites would be nice though.

[TerminX]

http://www.eduke32.com/stuff/eduke32...t_20060520.zip

Played with the weapon system again, so anyone making a mod might once again be left with a set of guns that don't fire (sorry!). Note that the chaingun and the freezer now have a new weapon flag that didn't exist before. I also played with the aspect ratio correction stuff a bit, and fixed up the HUD model perspective correction stuff quite a bit. You can now toggle the fixed perspective on/off from the video settings menu, and neither the world view nor the weapon should distort anymore if you have a weird screen size.

Also note that the syntax for the findnearactor3d/findnearsprite3d/findnearactor3dvar/findnearsprite3dvar commands has changed, and that the movement_lock member of the player struct has changed in this build as well.

[DeeperThought]

Cool. I'll have to check and see what this does to my mod. I'll get a chance to try it later tonight.

Edit:
I'm not noticing any differences in the weapons. Whatever you did, didn't mess anything up. I am curious about the syntax change to the findnear commands, since I might want to use these.

[NightFright]

Just in case you are experiencing sluggish downloads as I did - mirror for eDuke32 screenshot seen above:

http://www.uploadtemple.com/view.php/1148213714.zip

I really hope this one doesn´t screw up firstperson.def settings again... but I am almost sure it will.

*EDIT*
Well... the new "correct" weapon draw mode works, but... em... the models are so large now you can´t make them fit onto the screen without repositioning them dramatically. The main problem with that are the muzzleflashes from following weapons:

- Pistol
- Shotgun
- Chaingun
- RPG

These are still using the muzzleflashes from the sprites which are still drawn underneath the models. If you remove the sprites, the models won´t have any muzzleflashes at all any more. If you leave them, you´ll see parts of the sprite weapons when firing (with my latest firstperson.def and in old rendering mode, shotgun and RPG have this effect as well). So I think we need new HUD weapons, which is not what one would call breaking news.
Really important is to make the sprite weapons disappear completely when using rendered models, therefore using muzzleflash models.

[DissidentRage]

Or you could use the hi-res art powers to turn the weapon sprites into pure muzzleflashes. Hell, with the Ripper, the muzzleflash is completely separate art from the gun already.

[Parkar]

Lets just leave the hud models alone for now, it will all have to be redone anyway. Just pointless to fix em over and over and over again. Just comment out the firstperson.def in the hrp def and let users that want to turn em on do that manualy.

[Iggy]

Originally Posted by TerminX

JonoF was working on anti-aliasing but I don't know that he got it working.. I just force 4x on everything though the control panel anyways. You can try fooling with the "glmultisample" variable in the console.

Is anti-aliasing a serious feature he is trying to get to work or is it more an experiment?

[NightFright]

If anyone is interested in doing this: We would need additional HUD weapon models with muzzleflashes from the following tiles:

- Pistol: 2525, 2526
- Shotgun: 2614, 2615
- Chaingun: 2541, 2542, 2543
- RPG: 2545, 2546

These could be based on current models. If nobody comes up with a solution, I can offer turning off muzzleflashes completely for the time being (with the same fix Piterplus gave me for the Chaingun). Doing so, you would have no muzzleflashes at all, but the models could be placed wherever you want them.

[NightFright]

OK guys... *sigh*. Here is another release from the "Signs & Wonders" Department... the god-damned 4th version of "firstperson.def", compatible to latest eDuke32 snapshot!

But the most miraculous thing about it: It will work with both "old" *AND* "correct" HUD weapon alignment mode! Now if that´s no achievement, I don´t know what could be one.

Changes:
- Alignments corrected for eDuke32 May 20, 2005 snapshot
- Sprite muzzleflashes for Pistol, Shotgun, Chaingun and RPG removed (Pistol model has its own muzzleflash, so you´ll still see that one).

Oh, and TerminX: PLEASE tell me you´re not planning further changes for the weapon system! PLEASE NOT! I beg you!!!
BTW: What do you mean with these new "weapon flags"?

How do i use the hrp with eduke32??

[TerminX]

Originally Posted by Iggy

Is anti-aliasing a serious feature he is trying to get to work or is it more an experiment?

An experiment, I think.

Originally Posted by Hansie

How do i use the hrp with eduke32??

Either change the HRP shortcut to use eduke32.exe instead of duke3d.exe, or create a file in your Duke3D directory called duke3d.def with the lines "loadgrp duke3d_hrp.zip" and "include duke3d_hrp.def" in it.

[Plagman]

What Parkar said is correct. The current version of EDuke32 has model-level polygon sorting and a more general sprite / masked wall sorting, allowing true alpha-blending without too much depth artifacts.
However, those are the cases where such artifacts may still appear :

• crossing sprites : a sprite is drawn in its entirety and two or more translucent crossing sprites will cause blending problems.
• crossing polys : a model with crossing triangles will cause the same exact problem as above. It should never happen, even for optimization purposes. Two overlapping models may cause the same issue.
• weakness of the sprite / masked wall sorting algorithm : it's not perfect right now, so problems with glass may appear.

If you encounter blending issues and don't think they match the above cases, feel free to contact me.

[djimd]

TerminX
Thanks again for your regular updates. Just tried out the latest eduke32_snapshot_20060520.zip and the joypad that i use is disabled with no way of enabling it - If i play with an earlier snapshot or JFduke it works again. Maybe the joystick code was missed out in this release??

[TerminX]

Try "usejoystick 1" in the console.

[NightFright]

Does anyone know what´s up with Duke Talk not working in the difficulty selection screen? Besides, level end screens are missing DT for a while now, too.

[kaotic_oz]

I swear TX said its becouse hes working with adding Jonofs audio addon

[Usurper]

Fixed as of May 22nd. No public builds out yet. I imagine a beta 2 is coming.

[Chip]

Right then - time for a question,

In my mod I would like to dissable the ability to save the game from any of the "F" keys or from the main menu. The only way I want it to save is by the new command which will auto save the game at certain times.

So then, how do I dissable manual saving?
I fear it will be realated to them event things (which I'm not particually good at)

[TerminX]

There's no way to disable the save menu.

[NightFright]

Mapster32 specific question:

I am using Mapster together with the HRP in order to check newly added models for their alignment. It´s easier and faster than loading up the whole game in order to see in which direction the models are facing, as you all probably know. Some models however are aligned in Mapster32 differently to the way they actually are ingame.
I noticed this phenomenon with the two shopping carts "parked" outside the supermarket in E4L3: In Mapster32, the modelled carts would face each other (without maphacks), while ingame, they are facing into the same direction (towards the supermarket window). Is this related to the editor or something having to do with the models/shading behavior etc?

[Chip]

Originally Posted by TerminX

There's no way to disable the save menu.

And out through the windows goes my plan.
Could this feature be somewhat implimented then?

You see, I want people to make more effort when playing the game and when you can save anytime / anywhere it sort of makes the game much easier.
So by disabling the save feature and only allowing autosaves in certain places makes the game more challenging as dieing becomes more horrid then before as you'll have to re-do some parts again.

[Boinky]

Save isnt stored in an event? Liek you couldnt override the saveevent and possibly disable it?

[DeeperThought]

Originally Posted by Boinky

Save isnt stored in an event? Liek you couldnt override the saveevent and possibly disable it?

Just take a look at the event list on the Wiki. No save events. And even if you could stop the player from doing a quick save by blocking the keyboard input, how are you going to stop them from accessing the save command in the menu?

The best you can do is flash a message on the screen that says, "PLEASE, FOR THE LOVE OF GOD, DON'T SAVE THE GAME!!"

[DeeperThought]

TerminX, there have been times (like now) when I have wished there were a command to force a certain event to occur, even when the things that normally trigger it aren't happening. For example, I want to force events associated with pressing certain keys. It would probably make the most sense if the forced event happened in the next tick, rather than the tick in which the command is issued. Would such a command be possible to implement?

[TerminX]

I don't see a point. Any code you planned to run in the event could simply be run from where you'd trigger such a thing.

[DeeperThought]

Originally Posted by TerminX

I don't see a point. Any code you planned to run in the event could simply be run from where you'd trigger such a thing.

The point is not to execute CON code associated with an event; the point is to do the hardcoded stuff associated with the event itself. Some events do things that are (as far as I can tell) difficult are impossible to do in CON.