[Plagman]

Diaz, on 08 May 2012 - 10:00 PM, said:

Hmmm... do we have any news about implementation of non-shadow-casting spotlights?

I don't remember, was a consensus ever reached on which SE member should be used for that?

[Fox]

Plagman, on 09 May 2012 - 09:31 AM, said:

Can you elaborate on a specific case so that I can try taking a look?

Currently I am using the following def code:

highpalookup { basepal 0 pal 6   file "tiles/misc/pal_invulnerability.png" }

And this is the result:



But if I change to this...

tint { pal 6   red 255 green 255 blue 255 flags 3 }

highpalookup { basepal 0 pal 6   file "tiles/misc/pal_invulnerability.png" }

This is what it looks like:

[Plagman]

So the problem is only with HUD sprites? It could just be a bug rather than a general highpal thing, since HUD sprites re-use some of the Polymost code as-is.

[Fox]

I see. From what I can tell, it seems that once you set up a flag for the tint values, the highpal uses it as a basis (for HUD sprites).

[Diaz]

Plagman, on 09 May 2012 - 09:32 AM, said:

I don't remember, was a consensus ever reached on which SE member should be used for that?

Mmmm, you're right... proposals were palette, clipdist and wall/floor alignment. Palette looks like it could be used for something that actually needs a scale in the future, and same goes for clipdist. Alignment looks like the best option and I hightly doubt it will break existing maps...

[Fox]

Is it possible to increase the moving speed in Mapster, or to use some sort of autorun option?

[Micky C]

When I hold down shift in mapster, I seem to move a lot faster, or do you mean move even faster then that?

[Fox]

I got a little problem with Shift. But I would prefer to always run instead of using another key.

[Mblackwell]

Hold Right Mouse and drag to move (yes in 3D mode).

[Jblade]

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?

[TerminX]

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.

[Jblade]

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.

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

[TerminX]

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.

[Tea Monster]

How about getting a map loader written for UDK then ( jk )

[Jblade]

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)

[TerminX]

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.

[Diaz]

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...

[Jblade]

nice work TX, thanks for the quick fixes

[Diaz]

Nice work indeed, everything is working fine now

[TerminX]

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.

[Jblade]

Seems like setting RETURN -1 on the weapon keys doesn't disable changing weapons anymore:

Quote

M210, on 16 May 2012 - 10:39 AM, said:

Yeah, I have a some bugs now too.
For example at EVENT_WEAPKEY7 doesn't works setvar RETURN -1, therefore I received an unwanted ability to switch weapons (shrinker/expander )

This problem I got in rev2656

Just went into my stuff and got this too.

[Fox]

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.

[Helixhorned]

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.

[Fox]

Is there going to have control for actorless sounds in the future?

[TerminX]

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.

[Diaz]

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.

[Fox]

Funny how fast TerminX actually works.

[TerminX]

What do you mean by that?

[Fox]

Well, normally you are too busy. But now it's just ask something and you give.

[TerminX]

That's true! You guys had better get your requests in while it lasts.