Is it possible to increase the moving speed in Mapster, or to use some sort of autorun option?
EDuke32 2.0 and Polymer! "talk about the wonders of EDuke32 and the new renderer"
#2881 Posted 11 May 2012 - 08:12 PM
#2882 Posted 11 May 2012 - 08:15 PM
When I hold down shift in mapster, I seem to move a lot faster, or do you mean move even faster then that?
#2883 Posted 11 May 2012 - 08:53 PM
I got a little problem with Shift. But I would prefer to always run instead of using another key.
#2885 Posted 14 May 2012 - 02:08 PM
Just saw the new event commands, pretty amazing stuff thanks However something seems off about jumping...I can't describe it but there seems to be a really tiny delay now between press jump and doing it in this snapshot compared to the last one. I didn't notice anything in Duke but I did in the AMC TC...could anybody else who has the AMC TC installed grab the latest snapshot and compare jumping in it to the previous one and tell me if I'm going crazy or not?
#2886 Posted 14 May 2012 - 02:17 PM
I think you're going crazy.
Edit: I reviewed the changes line by line and found one problem, but I don't see how it could have any effect on jumping. Try the new revision and see what happens.
Edit: I reviewed the changes line by line and found one problem, but I don't see how it could have any effect on jumping. Try the new revision and see what happens.
#2887 Posted 14 May 2012 - 11:24 PM
TerminX, on 14 May 2012 - 02:17 PM, said:
I think you're going crazy.
Edit: I reviewed the changes line by line and found one problem, but I don't see how it could have any effect on jumping. Try the new revision and see what happens.
Edit: I reviewed the changes line by line and found one problem, but I don't see how it could have any effect on jumping. Try the new revision and see what happens.
Hmm, it's still there BUT maybe the 'problem' is that one of the other misc tweaks mentioned effected some of my jumping animation code or something, so it probably is just due to something I did a while ago
#2888 Posted 15 May 2012 - 08:07 AM
I'll keep looking at the changes because someone else reported an issue with jumping too. The thing is, I've gone over every line I changed and nothing stands out as possible being able to affect jumping at all. I'm wondering if maybe it's some nasty bug elsewhere that has only come up now because some behavior it depends on is different, but I'm not seeing it at this point. I really hate how this game's code is a house of cards that just falls down whenever you do anything.
#2890 Posted 15 May 2012 - 01:49 PM
TerminX, on 15 May 2012 - 08:07 AM, said:
I'll keep looking at the changes because someone else reported an issue with jumping too. The thing is, I've gone over every line I changed and nothing stands out as possible being able to affect jumping at all. I'm wondering if maybe it's some nasty bug elsewhere that has only come up now because some behavior it depends on is different, but I'm not seeing it at this point. I really hate how this game's code is a house of cards that just falls down whenever you do anything.
Well the issue is a minor delay between jumping and the actual movement; I have no idea if this helps but event_jump still seems to be triggering when I press the button, but it just seems as if there's a delay somewhere; and it's seemingly random, one moment it works fine and then the next I can hold it down for several seconds and nothing will happen, but eventually you WILL jump even if you don't let go of the key.
I do remember you and most of the other coders saying as much in the other topic; it's too bad for people re-writing the code but at least we had real mod support compared to SW's complete lack of (Although the very few mods did some really cool things even without being able to change the gameplay, at the very least the mapping effects were far superior even if they were harder to work with)
#2891 Posted 15 May 2012 - 04:51 PM
I just commited r2656 which internally changes the way that events are handled in regards to cancelling them with the RETURN variable. Please thoroughly test this build and report any issues with it here. The jumping problem appears to have been caused by EVENT_SOUND's use of the RETURN var... any event that played a sound would get its RETURN value mangled by the event firing. This is actually a longstanding problem and also would have occurred when spawning a sprite or doing anything else that would cause an event to execute from within another. It should be resolved now. What this means for the end user is that whenever an event is triggered, the value of RETURN is saved off and restored when the event is over.
#2892 Posted 15 May 2012 - 09:47 PM
So I guess this is what was causing the problem I described in the EDuke32 scripting thread.... I was playing a sound inside EVENT_DOFIRE. I kinda managed to fix it but let me see if it works with the old code and r2656...
This post has been edited by Diaz: 15 May 2012 - 09:47 PM
#2895 Posted 16 May 2012 - 09:51 AM
I'm glad you guys like the fix and that it seems to be working well. I was afraid I would break something since it involved changing the code of every event in the game individually. They were really simple changes but with something like 90 or so events I wouldn't be surprised if an error crept in somewhere.
#2896 Posted 16 May 2012 - 01:33 PM
Seems like setting RETURN -1 on the weapon keys doesn't disable changing weapons anymore:
Just went into my stuff and got this too.
Quote
Just went into my stuff and got this too.
#2897 Posted 17 May 2012 - 03:31 AM
Thanks for the EVENT_SOUND function, TX.
Edit: I noticed this event only works for actors, but not for menu sounds. Is that right, since it was supposed to be a workaround for hard-coded sounds? I would like to control the sounds on menu and other screens, with THISACTOR set to -1 during these events.
Edit: I noticed this event only works for actors, but not for menu sounds. Is that right, since it was supposed to be a workaround for hard-coded sounds? I would like to control the sounds on menu and other screens, with THISACTOR set to -1 during these events.
This post has been edited by Fox: 17 May 2012 - 06:55 AM
#2898 Posted 17 May 2012 - 08:27 AM
Yeah, it hooks into A_PlaySound(), which only runs when a sound is played from an actor. This also means that THISACTOR works as expected.
#2899 Posted 17 May 2012 - 08:32 AM
Is there going to have control for actorless sounds in the future?
#2900 Posted 17 May 2012 - 09:34 AM
Committed 2657, 2658 and 2659. 2657 addresses a longstanding issue with lockups after alt+tabbing in windowed mode, 2658 fixes the WEAPKEY events and 2659 changes the EVENT_SOUND implementation to cover all sound types.
#2901 Posted 17 May 2012 - 11:33 AM
So it was true that you're getting some free time to work on EDuke32 again...
That's great news, and great work as well! Thanks a lot for the new stuff.
That's great news, and great work as well! Thanks a lot for the new stuff.
#2904 Posted 17 May 2012 - 06:22 PM
Well, normally you are too busy. But now it's just ask something and you give.
#2905 Posted 17 May 2012 - 06:24 PM
That's true! You guys had better get your requests in while it lasts.
#2906 Posted 17 May 2012 - 06:41 PM
Since you are there...
I am not a fan of Edukes' alternate Hud replacing the default mini-Hud. Can't it be simply set as a new "screen size"? That's at least how the source ports of Doom defines a custom Hud, I.e. press + and - to select the port unique Hud.
I am not a fan of Edukes' alternate Hud replacing the default mini-Hud. Can't it be simply set as a new "screen size"? That's at least how the source ports of Doom defines a custom Hud, I.e. press + and - to select the port unique Hud.
#2907 Posted 17 May 2012 - 06:52 PM
Doom source ports don't have to worry about running 10 year old mods that manipulate the screen size value in various ways, because Doom source ports don't have real scripting systems, just inflexible stuff like ACS.
#2908 Posted 17 May 2012 - 07:08 PM
That's true, but I find it weird to erase one of the game Huds. Not that I am a big fan of Duke's mini-Hud that omits the armor and keys displays. To tell the truth, the right thing to do would be to include these in the mini-Hud. But that would require new art and that's outside of Eduke's spectrum.
Eduke prevents the "mighty foot engaged" message of replacing other messages. Since the XBLA version completely removed that message from the game, isn't it time for Eduke to do the same? I mean, the XBLA is kinda of a newer version of Duke afterall.
Eduke prevents the "mighty foot engaged" message of replacing other messages. Since the XBLA version completely removed that message from the game, isn't it time for Eduke to do the same? I mean, the XBLA is kinda of a newer version of Duke afterall.
#2909 Posted 17 May 2012 - 07:27 PM
Removing it was considered (hence the fact that the behavior was altered at all), but I decided against it since it's the original behavior and some mod somewhere might rely on it in some way. I agree that the message is kind of pointless... it made a lot more sense back in earlier versions of Duke where pressing quick kick actually switched weapon to the knee, fired, and then switched back.
#2910 Posted 17 May 2012 - 08:27 PM
I know a lot of Doom source ports come with their own little archives for some new art and stuff. If you guys aren't opposed to coding an extended version of the original mini-HUD, I'd be happy to provide art for it. My mod already has basic functionality for it, so I've got some art for it ready. But if you wanted something different, I could whip it up. Just let me know. I'll create whatever art I could for you guys, just ask.