Suggestions

Sort by date Sort by reaction score
Basically, would you rather us put in level transitions or new levels? We have a finite amount of people at our disposal and I think everyone here would rather us put that work into actual levels instead of cutscenes.
 
NeroTheArmadillo said:
Angled springs. - And adjustable force too. -
Click to expand...
The vertical force can be manipulated on a per-object basis (note a Thing loads an object (or several), so you can't do this on a per-Thing basis (without Lua)), and the same goes for the horizontal force. Regardless, I'd love to make springs where the vertical force can be manipulated on a per-Thing basis, and also horizontal force too some time, but I don't think I can make it truly angled every possible direction and such. Could be fun to try, but I'll leave that for a later time (2.2).
 
Also, would being able to cancel Super Sonic be a viable feature? Or is that too far from how the classics handled it?
 
RomioTheBadass said:
Do it yourself ? there are external programs that allow you to do so .
Click to expand...
No taht not what i mean!
So here's an example of what i mean
so you could make a lua script that
when a song is at 0:02:35 and you press custom 1 button
and then it plays Egg Rock Music from 0:02:35 but when
the button is pressed at 0:03 of the first song the egg rock music starts from 0:03.
It could be used to make in-game song mashups.
I hope you understand.
 
Xkower8181 said:
No taht not what i mean!
So here's an example of what i mean
so you could make a lua script that
when a song is at 0:02:35 and you press custom 1 button
and then it plays Egg Rock Music from 0:02:35 but when
the button is pressed at 0:03 of the first song the egg rock music starts from 0:03.
It could be used to make in-game song mashups.
I hope you understand.
Click to expand...

So, from what I can understand from this, you could use it to make something akin to the credits medleys of the classic Sonic games basically?
 
Fres said:
So, from what I can understand from this, you could use it to make something akin to the credits medleys of the classic Sonic games basically?
Click to expand...
Oh yeah after a bit of thinking I think this is it! but then i could make the medley one song and not waste programming time and posts on this thread.
 
Look at how Fres explained this idea, it almost sounds like you can also have a music shuffler for mid-gameplay. It could be an interesting lua idea alone.
 
All this discussion is a moot point because both our music mixers are terrible and can't start off at an arbitrary position, otherwise we'd be using it for Speed Shoes and Invincibility (and non-Mario 1ups).

Sorry to be the bearer of bad news, since it is something we'd definitely like.
 
Maybe I'm not seeing it, but it doesn't seem there's an easy way to set up scrolling both sides of a linedef. When just dealing with upper and lower textures it usually won't matter, but it would really help with making both sides of a midtexture scroll.

---

It would be good if Lua could read structures like spritedef_t so functions like this:
Code: 
function A_SetFrame(actor)
    if actor.spawnpoint == nil then
        return
    end
    actor.frame = actor.spawnpoint.angle | (actor.frame & ~FF_FRAMEMASK)
end
Can catch this error before it happens:
https://github.com/STJr/SRB2/blob/a...eb04eff088cb54bdc2/src/r_things.c#L1118-L1122
This causes the offending state to have its sprite and frame info set to <!> in the event that an invalid frame is called. This makes sense for most vanilla functions, so the error doesn't have to be spammed every single time the state is called.

The Lua function allows FF_ANIMATE scenery objects to start at arbitrary points in their animation based on spawn angle. It works fine, unless an angle is set that causes it to start at an invalid frame. I tested this by applying it to torches in a small test map with torches of angle 0, 1, 2, 3, and 4 (for reference torch only goes to frame 3). When the map loads the first three torches work fine, and the fourth displays <!>. However, until the game is reset, all newly spawned torches will go directly to <!>, even in other maps. Here's the funny part: this only happens once the torch is seen. So if I were to load my test wad, go to CEZ1, and then enter the test map, the torches would spawn correctly. If I were to go to CEZ1, go look at a torch, and then load the test map, the torches would spawn <!>.
 
I realize this probably is ridiculous for a suggestion, but I'm wondering if implementing a system similar to SRB2CS would be better than using our current netcode? I mean, it seems that there were several issues when it came to synchronizing objects, but I'm wondering how much of that could be actually fixed. Plus you know, the security concerns.

As a secondary alternative, perhaps implementing the Gametic Unlagged system from Zandronum would work somewhat? I'm not entirely sure how well though, honestly.
 
Nomekop said:
I realize this probably is ridiculous for a suggestion, but I'm wondering if implementing a system similar to SRB2CS would be better than using our current netcode? I mean, it seems that there were several issues when it came to synchronizing objects, but I'm wondering how much of that could be actually fixed. Plus you know, the security concerns.

As a secondary alternative, perhaps implementing the Gametic Unlagged system from Zandronum would work somewhat? I'm not entirely sure how well though, honestly.
Click to expand...

As far as I remember, SRB2CS's netcode had lots of issues too, I remember it as worse than the normal 2.0.x netcode.

Anyway, I have little to no knowledge about how srb2's netcode handles stuff, but, if we're throwing ideas for the it, I might suggest trying to send the gamestate over again for synching?

By what I've heard, synch only attempts to synch players back, so it would mean that in the case where a joiner does not appear for everyone (which happens in like, 1/6 of the joins), the game tries to synch something that doesn't even exist for other players, and it leads to a certain failure, doesn't it?
I know sending gamestate would probably affect performance or something, but it's not like it matters since the game technically is frozen when synching happens.

Also another thing, it would be REALLY nice if the game actually got rid of a player taking too long to join, like, those who timed out or something. Because it happens way to often that a server freezes just because a joiner was unable to actually join.
 
Last edited:
I Have a friend who doesn't get an english word from the game's Main Menu, and he barely figured out how to join Netgames because he was supposed to choose a room to list servers from, He told me it was much more easier for him to join Netgames because older version displayed servers quicker and without having trouble of choosing room .

I Think that new thing on Multiplayer Menu just made it Harder / Worse for Non-english players to join Netgames .
 
A small thing that would be nice for a future version would be support for custom transmaps, that would rest outside of the existing 9 lumps. This would allow for neat effects such as those seen in Ritz's thread, or this small modification to the colormap I threw together as an example, without affecting the existing colormaps negatively. something like... "TR_TRANSX01" in regards to objects states?

EDIT: Another suggestion, that might fit in, would be a way to determine the draw order of hud objects, so that a transparent effect could be placed under the rest of the hud items.
 
Last edited:
You must log in or register to reply here.

Who is viewing this thread (Total: 2, Members: 0, Guests: 2)

Back
Top