Setup:
* S_SKIN needs an "availability" line. Set to 0 to have always available, otherwise is assumed to be UINT8 unlockable number. If it's a valid unlockable, its name will be copied over with the character's realname.
* Define an unlockable via SOC or hardcode. If you don't want it visible on the Secrets menu, just set its type to None. Everything else is as normal - you can set the conditionset to whatever, objective, height, nochecklist, nocecho...
* radius - sets the player's radius for that skin.
* height - sets the player's normal height for that skin.
* spinheight - sets the player's spinheight for that skin.
* shieldscale - see http://i.imgur.com/BQ5DhKC.png for justification
R_SkinUnlock defines the circumstances under which a skin is available. For simplicty's sake, I've currently bound it to an S_SKIN variable so I can toggle it easily, but it WILL be replaced with a hook into the savegame system at some point.
* Currently has three tiers of unlock - freebie (forceskin or modeattacking via a loaded replay), Ringslinger Only, and SP/Coop and Ringslinger.
* I don't know anything about netcode so I basically decided to make R_SkinUnlock relevant only under local circumstances, try as hard as possible to stop bad skin info from getting sent to the server, and then admit defeat once the server has the information. If this is a bad choice, please discipline me and show me how to fix it.
* Character Select now checks for whether the character is hidden or not on menu load and does/undoes it based on that info, but will never touch one disabled via SOC. I also used this opportunity to optimise, checking for/filling out charsel pictures instead of doing it later. (It now also includes special casing for a select screen with zero characters!)
* Mode Attack now hides hidden characters in its character select based on SP rules.
Things that still need to be done:
* ForceSkin_OnChange. Is there a graceful way to handle this?
* No obvious skin name conflicts. Add a salt to the names of hidden skins, and then remove it when they're unhidden?
* The gap between Knuckles' skin number and the first custom character anybody adds will be way too obvious. A seperate hidden skin numbering system? Start at 32 and count up from there? There's a few ways...
* If a character select character image is not set, don't iterate every tic - iterate on first image get and then save to the struct.
* A character select screen with only two characters now has special case handling.
* A memory leak in the making has been plugged. (specifically, picname not being Z_Free'd if the loop fails to do so)
* Logic/operation simplification.
Also, some typo corrections and clarity case movements of stuff in other files I've been looking at.
* SF_NOJUMPSPIN - Player's height is full whilst jumping, SPR2_JUMP defaults to SPR2_SPNG instead of SPR2_SPIN, and the player goes into fall frames if they start moving downwards or use their ability.
* PA_JUMP - for jumping (upwards in the case of SF_NOJUMPSPIN.
* SF_NOJUMPDAMAGE - Ala rosy.wad, don't damage enemies, etc when jumping into them.
* SF_STOMPDAMAGE - Just for fun. Ala in Mario, always damage enemies when you land on top of them (your gravity reference, not theirs).
* SF_MARIODAMAGE - SF_NOJUMPDAMAGE|SF_STOMPDAMAGE is reasonably accurate to the Mario games, and might as well be surfaced as such.
Also, a minor change:
* Instead of not spawning the revitem if your SPR2_ is SPR2_DASH, don't spawn it if it's set to 0. This requires the player.dta I uploaded a couple days ago to behave as it was previously.
* Don't get stuck in spindash frames if your maxdash is 0, and don't flash rolling frames if you're on goop.
* Characters disabled through SOC are outright removed. No awkward gap in scrolling - no hint they were ever there in the first place.
* Vertical loop - the character select images are visually continuous. No matter where you are in the chain, you'll always see a hint of the character above or below your current selection in the chain.
* Smooth scrolling - Moto and Prime showed me a gfy from back during 2.1 development where it was super smooth. I didn't make it as slow as that one, but the smoothness was easy to add and the reason it was removed previously - gaps in the character select leading to varying speeds - is no longer relevant.
* SPR2_PEEL, SPR2_SPEE.
* S_PLAY_PEEL, S_PLAY_SUPER_PEEL.
* PA_PEEL.
* Dashmode actually starts charging from runspeed instead of the arbitrarily calculated (normalspeed - 5*FRACUNIT). This just made things easier, honestly, and it's 1 FU of difference compared to the current test case.
- Press spin in midair to stomp directly downwards (losing horizontal momentum), creating a flickering fireball around you.
- No bouncing on enemies, item boxes, etc - just go straight through.
- Hurts other players on touch whilst you're stomping.
- Spawns a bunch of flames around you when you hit the ground.
Also:
- Electric shield's ability now uses different sounds, because I'm picky.
- Now checks whether the player's top is below the bottom of the fan/gas jet, instead of its bottom. zdist calculation not affected.
- mo->standingslope is NULL'd so the player isn't launched off at a wacky angle. (I also did this for springs, since Prime mentioned it was a problem for them too.)
Some slope improvements/fixes (plus P_GetMobjGravity)
Dear Red, I did some things.
* Made the slope flag SL_NOPHYSICS actually have an effect like we wanted to, but didn't get around to implementing yet - activated by setting the slope's linedef flags to have ML_NOSONIC.
* Made downhill slope thrusts proportional to an object's gravity and friction.
* To make the above happen - seperated out the gravity value finding code in P_CheckGravity into a seperate function, P_GetMobjGravity. (p_mobj.c, p_local.h) I also made this function available to Lua.
* Turned those PANIC n console messages (which would inevitably be followed up with a crash, since we're accessing invalid memory immediately after) into a descriptive I_Error.
* Put the SRB2CB type-shimming behind an ESLOPE_TYPESHIM ifdef.
* Removed SPRINGCLEAN-ifdef'd code.
* Cleaned up some eosteric comments.
* NEW SINCE RED +1'd THIS: The teetering code now takes slopes into account pretty well. There are edge circumstances as outlined in commit 9d221f4f3f, but this is unilaterally better behaviour in every way and the teetering code was kind of a mess anyways.
* NEW SINCE RED AND ALAM +1'd THIS: P_ReverseQuantiseMomentumToSlope. Simple function that replaces the inverse angle stuff (which also wasn't using InvAngle, just ANGLE_MAX - angle - which is inaccurate!!)
Current testing files available at /toaster/slptst3.wad and /toaster/gravitytest.lua on the ftp.
I want to do more to the branch like implement SL_ANCHORVERTEX in the near future, but this is probably safe to merge in its current state.
See merge request !77
The whole thing needs a refactor in general, but it's almost 2am here, I need my sleeb, and this fix would probably break something with 2.1 climbing if I made it any more/less (depending on viewpoint) complicated.
Sectorlist traversal
MOM GET THE CAMERA
There's a LOT of code in the source that ended up mixing m_snext (the node for the next thing in the sector's thinglist) and m_tnext (the node for the next sector in the thing's sectorlist), so I renamed the following:
* m_snext ==> m_thinglist_next
* m_sprev ==> m_thinglist_prev
* m_tnext ==> m_sectorlist_next
* m_tprev ==> m_sectorlist_prev
Then, I changed all the instances where the code was trying to go m_thinglist_next on a mobj's touching_sectorlist (which would've just gone to the node for the next thing in the same sector, instead of the node for the next sector for the same thing). Notable samples:
* FF_SHATTER blocks now disappear the moment you go into their sector. You still can't give FF_SOLID to them because in that case they will still stop you if you never enter their sector at all (ie - clip on corners), but having them nonsolid no longer allows you to phase through entirely without busting them (which was the whole downside of making them intangible in the first place).
* You can now bump into multiple Mario blocks at a time, even if you're not exclusively in their sector.
* No more getting randomly stopped on the edges of bouncy FOFs.
* Landing on polyobjects might behave a little more consistently at the edge of their host sector.
* Teetering did a SHITTON of code that basically never got executed, and then had directly-blockmap-accessing code as a backup. The code was activatable by replacing the m_thinglist_next with m_sectorlist_next, but it behaved SUPER differently from what we're used to with teetering (if the player mobj's edge was JUST off the edge of a platform, you ended up in teetering frames - even if it looked like you could stand) so I ended up removing that section entirely.
Any objections?
See merge request !85
Fixes and changes related to the act of setting up a level (in other words, setup fixes)
Changes made in this branch so far:
* a REJECT lump of zero length (NOT to be confused with a REJECT lump of non-zero length with all-zeros, just to clarify) should no longer cause problems with netgames and otherwise. The game now checks if the lump exists, has the right name, and length is not zero - if it fails any of these, the REJECT lump is not loaded and P_CheckSight won't be allowed to use it. This means ZDBSP (no reject) should be safe(r) to use now!
* there's now a simple devmode-only message (requires "Setup" mode) if a sector is found to have no lines at all during setup. It's a far cry from the plot to I_Error the game I once had for that unsusal scenario, but such a level still works anyway so whatever.
See merge request !87
FF_REVERSEPLATFORM clipping
Ran into an issue whilst testing out one last feature (there's always one more...) for flat_alignment_revamp. This is a backported fix.
The bug was such that if you're falling through a platform with FF_REVERSEPLATFORM and not FF_PLATFORM, you'll be pushed downwards such that your head is against the bottom of the FOF. This just checks momz is greater than zero if it has FF_REVERSEPLATFORM to make sure it's okay to set ceilingz. (OR the alternative in reverse gravity.)
No test map because this was originally done for internal. Instead, test it on the other branch's test map.
See merge request !83
Software crashes fix
This branch SHOULD fix the many crashes people have reported lately that all point to the software renderer. Simply put, the software renderer allowed stuff to be drawn out of the screen even though that wasn't safe, and even the existing checks to prevent that didn't work.
If you saw me worrying about the sky HOMs I discovered in AGZ earlier in the commits for this branch, don't worry - it turns out that issue already existed in 2.1.15's srb2win.exe (and probably srb2dd.exe too) anyway, the changes in this branch didn't cause them. Hopefully nothing else broke then.
See merge request !75
Also, the teetering angle on slopes is now FRACUNIT/2 because there's literally no way to stand still on a slope that steep unless it doesn't have physics.
This means the current skewing-by-default effect isn't changed, and OpenGL's equivalent code doesn't have to be touched since apparently it was already like that.
This should mean that maps built with ZBSDP (no reject) should have less or no problems in netgames compared to the standard ZenNode maps now, hopefully. =)
note: once this is merged into internal, you should probably remove me from "programming assistance" so i'm not duplicated for no clear reason. unless you want me to slowly take over every section in the credits >:3c
"frontsector" in this part of the code isn't actually the polyobject's sector for back-side polyobject segs, it's the in-level sector the polyobject as a whole is being rendered in it turns out.
Red apparently left in code for single-sided linedefs to NOT skew their midtextures ...but it doesn't work because it doesn't stop the skewing code from running instead, regardless of whether Effect 1 is on or not. If it's decided single-sided line midtextures shouldn't do this though, the non-skew code could just as well be thrown out lol (or something else I guess?)
When I first wrote this, I thought the .h file that contained a function declaration needed to have the same name as the .c file the function was in. Now I know that's not the case, off to p_local.h with you.
Two interesting points of note:
* The touchspecial sector flag seems to actually do its job now.
* Detection of sectors with polyobjects in seems to have done this incorrectly, but this doesn't mess with anything about touching the polies themselves so it seems to really only handle edge cases where the polyobject was too close to the border of another sector (which would've likely made rendering glitches anyways).
* There was a whole swathe of teetering code that was basically never run properly because of this mistake. I did a simple fix at first, but you started teetering whenever you were slightly less than your radius away from a sector's edge, which was completely different and undesirable behaviour. Instead, I cut out the code that was never running, and just left the hacky method in instead since it was more accurate to what we want in general.
Issue was caused by attempting to traverse the sector's thing-touching-list across all the things in the sector (which would inevitably have the same sector as the first node in mobj->touching_sectorlist) instead of traversing the thing's sector-touching-list (which has the same thing but different sector references).
I wonder how many times AJ copypasted this code with absolutely no idea why it wasn't working properly. I'll figure that out tomorrow, maybe set up some compiler macros so this mistake is never made again. For now, I must sleeb.
Behaves ALMOST as you'd expect. It gets the z position of the slope at the player coordinates when it comes to the sectorlist check (which is first), though, so there's a few oddities that are amplified with steep slopes:
* If the slope's sloping away from you at a steep angle, you might not be able to step down onto it, but you won't teeter (because it's at a step-down-able height if it extended to directly beneath you)
* If the slope's sloping towards you at a steep angle, you might end up in teetering frames when you're able to step down onto it (because it's NOT at a step-down-able height if it extended to directly beneath you)
HOWEVER, it would be pretty obnoxious to hold back code which is functionally superior in every way otherwise, and it doesn't really seem like there's a good way to get that checked tbph
Also updated any relevant project files that I can think of to include the new files, as well as the makefile of course. Some of the other project files haven't been touched in years so I'll leave those alone ...unless someone objects
Basically this makes sure numwadfiles is updated before loading the SOC/Lua scripts, so if a Lua script calls COM_BufInsertText with the contents "addfile scr_mysticrealm.wad" it can't overwrite the last written wadfile slot! Not that COM_BufInsertText really should be used like that to begin with
*Didn't take into account object scale
*Doubled force when on the ground (ignore what the comment of the line I moved says, it was relevant for slopes...)
This also led to a mistake with slopes, where I was double-multiplying by the gravity constant to get half (because of a quirk of numbers...)
Also took the opportunity to nuke or otherwise neuter a bunch of Kalaron's bizzare ramblings (most are questions which have long-been answered by Red's efforts) at the same time.
*The No Physics flag now works (Red, you might want to doublecheck this to see whether I haven't missed any eosteric stuff out). Going downhill is a little bumpy, and I'm not sure whether that's good or not. Someone help me out here?
*The SRB2CB typeshims are now behind #ifdef ESLOPE_TYPESHIM instead of #if 1 for easier disabling.
*Slopes' downhill thrusts are now scaled with regards to object gravity. This is actually untested in gravities other than normal and reverse normal but it's one line which can be easily reverted in that circumstance. I also checked with MI to make sure this is how it's calculated elsewhere, so fingers crossed this doesn't cause any edge cases.
*As a consequence of the above point, there's now a function in p_mobj.c/h that returns an object's internal gravity - seperated out from the logic of P_CheckGravity, which really didn't need to be so monolithic. Multiply by global gravity to get the thrust. This should probably be available to Lua somehow, but I have absolutely no idea where to start with that. Wolfs, maybe?
Non-comprehensive test file available at /toaster/slptst3.wad on the ftp.
Do we really need to keep it around? If not, I say get rid of it. It seems like useless clutter that is just going to confuse people who are trying to understand the source code.
* -lSDL2_mixer is already added to SDL_LDFLAGS by default, unless NOMIXER=1 is set
* -DSDLMAIN should also be added to OPTS by default for MINGW=1 builds, unless NOSDLMAIN=1 is set
NiGHTS hotfix
Fixes the following issues relating to playing as NiGHTS Super Sonic that apparently popped up between 2.1.14 and next (mostly due to the changes to SRB2's trig stuff it seems):
* Super Sonic drifts to the side at some angles around an axis, and is unable to go directly upwards or downwards as a result
* Drilling to the side when on the ground causes the drill sound to constantly restart
* CEZS's start not actually being lined up properly with the first axis means the player is not able to go backwards along the track (because the player is not actually aligned with the track properly, preventing you from touching the attached line transfer)
* trying to hug some walls such as the tall wall before the library section of CEZS allows Super Sonic to go through them
These fixes needs proper testing before this branch can be merged in, in case they accidentally break other things as a result or something.
See merge request !71
Basically I kind of worked around any potential trig inaccuracies by not using the player position directly for setting momx/momy. This way, if player->angle_pos == player->old_angle_pos, momx/momy are zero
Demo replay fixes
Changes made/bugs fixed in this branch:
* Replay camera is now controllable when climbing (https://mb.srb2.org/showthread.php?t=38668), and in waterslides
* localangle (read: the angle between you and the camera, I think) now doesn't change during demo replays in most situations, unless the player is in analog mode. Exceptions include zoomtubes and NiGHTS super
* Replay camera now doesn't act silly if the player is in analog mode (assuming you also recorded it in that mode to begin with, anyway)
See merge request !66
DO NOT MERGE THIS INTO THE INTERNAL REPO. This is a temporary 2.1.15 only fix. This commit allows an optional boolean for tan(), which when true will automatically shift angles by ANGLE_90.
the most common condition (correct drawing) shouldn't be last, however it can't be first without making the conditions longer anyway.
it's a nitpicky thing, but this is the renderer we're talking about here.
i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs i hate FOFs
Previous overflow fix resulted in extra tall FOFs disappearing up close (see: ERZ1's elevators at start)
This works "better" in that only some lighting bugs and really really finicky visual glitches show now. I give up trying to totally fix this stuff dfsdfgdgf
One more name in the credits
I probably messed up by making toast_credits based on master instead of next. If that's blocking, just delete this branch and I'll re-do it. It's a single line, though - shouldn't exactly matter so much.
Could probably stand to be merged into Internal as well, since I hadn't actually worked on any textures when we'd updated the credits there.
See merge request !69
Fix portal and plane/sky interaction
More portal-related fixes:
* Fixes rendering issue 4 from issue #21 (Slope planes render with wrong height values when visportals are visible on-screen)
* Fixes sky rendering through portals, so that the sky you see through each portal is what you'd expect to see if you were actually there. Easiest way to see what I mean is through sky 22's planet, in a map with portals at 90 degrees to the other sides respectively (the example map on the wiki for ld40, for instance).
See merge request !65
The idea is for the layman Lua user to understand better what range of values to use for mobj types, states, sfxs, player #s etc. Additionally, mobjinfo/states/sfxinfo/hudinfo tables all now have actual bound checks when accessing/editing them. Yikes, why didn't they have any before?!
Slope fixes
This branch fixes the following slope-related physics and rendering bugs:
* Rings in multiplayer stages respawning inside slopes (even despite being able to spawn ABOVE them on map load)
* Player starts spawning players inside slopes
* Elemental flame trails not appearing if a player spindashes UP a slope; see issue #21
* Dying players "jumping" off slopes to the side if they were previously standing on one
* Some issues with FOF slope rendering
* Various issues with sprites displaying through walls adjacent to slopes
Other features added:
* Objectplace now supports slopes (this is Inuyasha's doing)
* Automap in DEVMODE now supports slopes (my doing)
Just making this merge request now rather than later, ~~in case I decide not to make any more fixes for the time being~~ (this branch doesn't seem to want to die lol), and so we can get these merged in as soon as the code's all been checked over.
See merge request !50
xorshift* PRNG
This needs testing to ensure I didn't mess anything up switching function names around.
Our PRNG sucks. This is probably obvious. I wish I had known better at the time I implemented it, but oh well.
The replacement is an xorshift* PRNG variant with period 2^32 - 1 (meaning that the PRNG state will loop after four billion calls ... that's not likely to happen), versus the old PRNG's period of about 2^22 (?). The output is also much more random and less predictable; the old PRNG would fall into a predictable loop of output after about 4000 numbers were generated, which isn't much.
The PRNG here also outputs numbers as fixed point from [0,1) (that's 0 to FRACUNIT-1, in other words) instead of single bytes at a time. This makes it much easier to calculate things for, say, P_RandomRange and P_RandomKey. A new macro, P_RandomChance(p), is now in use that returns true _p_ percent of the time, where _p_ is a fixed_t probability from 0 (0%) to FRACUNIT (100%).
This doesn't affect netgames at all; the code for seed saving and restoring is identical (aside from a check to prevent seed being set to 0, which breaks xorshift PRNGs). Demos break, but A: _duh_ and B: they're already broken by all the changes to physics to accommodate slopes.
P_Random is deprecated in Lua, as the function was renamed to P_RandomByte. Aside from that, nothing special.
See merge request !64
* add skidtime, which we forgot before 2.1 release apparently
* change tics from INT16 to INT32
* change eflags from UINT8 to UINT16
* change actionspd/mindash/maxdash from INT32 to fixed_t
Until we use something besides Native MIDI to play
back MIDI music, MIDI volume changing is disabled
since it causes way too much of a damn headache.
(It's not even our fault, it's fucking MS.)
Fix for teetering on PolyObjects
So... somebody goofed and didn't realise PolyObject sectors could be added to the sector node list for each object (which is referenced by mobj->touching_sectorlist), via their linedefs if they are nearby the player (yes, PolyObject linedefs are special and get to move about the level). As it turns out, this allows even INTANGIBLE PolyObjects to make you teeter in a seemingly inexplicable way.
What is happening is that PolyObject sectors, when they are added to the mentioned lists, are then checked under normal sector teetering conditions - if the player is above the floorheight by 24 FUs, you're officially teetering unless stated otherwise. The actual PolyObject teetering code can't help you here if the conditions are right, especially if they're taller than 24 FU in height.
There are a number of things wrong with the teetering code in general that I'd like to sort eventually, but at least now teetering on PolyObjects is fixed at last ...right? Please check the branch out if you can to check this, obviously.
See merge request !54
Fixes for patch scaling and V_FLIP usage
The following issues are fixed by this branch:
* a patch using both scaling and V_FLIP does not appear in the "correct" place on the screen. Thanks to LJSonic for pointing this out to me on 'fun
* Scaled and/or V_FLIPed patches wrap at the left/right screen edges even though they're not supposed to. V_FLIP patches at these edges may also crop the wrong side of the patch if they're at the right edge.
See merge request !60
Some fixes for portals
Specifically the following things are fixed in this branch:
* a memory leak resulting from not clearing away clipping-related arrays each tic you view a portal
* a very specific crash to do with portals sometimes (unintentionally) using a hack on drawsegs that don't actually belong to them ...which results in a crash if the drawsegs in question have midtextures. I reported it on the MB a year ago, with a test map included there: https://mb.srb2.org/showthread.php?t=38199&page=4#79
* another specific crash to do with mirrored (horizontally flipped) sprites that are scaled, particularly when you cover up the left edge of them via portals at the least. Needs more testing to be absolutely sure this is fixed, and is also reproducable in the test map linked in the post above
May be fine to merge changes into master too, I don't really know exactly
See merge request !42
Camera fix
This fixes the third person camera being silly around intangible PolyObjects, particularly the fact they can affect the camera's floorz and ceilingz even though I see no reason why they should do so.
Also a good reminder that POF_SOLID is the same as POF_CLIPLINES and POF_CLIPPLANES combined, which is probably how this issue came about to begin with. Can't say that with certainty of course.
See merge request !57
P_RandomChance is now a macro for something that should happen a
certain percentage of time.
P_SignedRandom was moved to a macro. Nobody cared.
# Conflicts:
# src/p_inter.c
This actually passes most diehard tests, as opposed to the old RNG.
It's also similarly fast.
Internally the PRNG generates a fixed point number from [0,1) now,
which makes P_RandomKey and P_RandomRange much easier to
calculate. P_Random is just a simple shift, as well.
Also, the lack of floating point math in P_RandomKey and
P_RandomRange now is probably for the best.
Also makes comptime.bat work with git if able.
Development builds will now show the branch and the SHA1 hash of the revision. Also been tested to work with subversion, where it displays "Subversion r####". You know, just in case.
There is a caveat to this: The first time EvalMath is used, a
deprecated function warning will be shown to the user that tells
them to use _G[] instead.
This reverts commit 9d36cf37bd.
This appears to fix a few holes that have been known to appear with FOF slopes sometimes, dunno how they actually came about exactly but this apparently sorts them out
Lua sector lines
Adds support for "sector.lines" in Lua, an array containing all the linedefs in a particular sector variable:
#sector.lines returns the number of lines in the sector.
sector.lines\[ _i_ \] (e.g. sector.lines[0], sector.lines[1], sector.lines[2], etc ....) gives you individual linedefs in the sector. If the number you supply is equal to or greater than #sector.lines, this returns nil.
Test script for your benefit: (see comments)
Type "luatest" in console in any level and you'll get a few print messages that tests these features for sectors[0]
See merge request !32
SOC_**** lump name support
Exactly what it says on the tin: lumps with "SOC_" prefix now are read as SOC lumps like with MAINCFG/OBJCTCFG. Go nuts.
As a bonus, I've changed things with SOC lump detection so MAINCFG, OBJCTCFG and the new SOC_**** lumps are loaded in the order you find them in WAD files (rather than an arbitrary load-MAINCFG-then-load-OBJCTCFG thing as before). All of these are still loaded after Lua scripts though, mind.
See merge request !38
Lua video lib expansion
New video/drawer library functions for hud.add to use:
v.width() and v.height() return the screen width and height respectively (in other words you get the screen resolution), while v.renderer() returns the string for the renderer used ("software", "opengl", or "none").
Possibly add more stuff later, but for now these things at the least can be merged in next
See merge request !40
Add PlayerSpawn hook to Lua
I don't know how I did this but I did. Something about staring at code from 3AM till 5AM...
Here's a test script too:
```Lua
addHook("PlayerSpawn", function(player) player.health = 99 end)
```
See merge request !48
Version constants for Lua
Pretty simple thing. Allows scripters to use VERSION, SUBVERSION, and VERSIONSTRING to check the game's version and potentially futureproof scripts. Have tested and confirmed working on my end.
See merge request !55
BACKPORT: removal of music slots
Relevant commits cherry-picked. Basically everything except the internal music track name switches.
See merge request !43
The funny thing is you really can't see ANY change here unless you have a sloped FOF intersecting a sector floor/ceiling (and a second FOF on the other side), which has other problems anyway lol
BACKPORT: FF_ANIMATE simplistic state animations
this is a lot more complex due to the need to remove the dispoffset related code as well as a lot of the redefinitions; combined with the code changes due to the sprite2 system in internal master.
~~BEFORE ACCEPTING THIS: get sryder to look at and fix any possible brokenness with OpenGL MD2s~~
See merge request !45
Fof flag change hotfix
This fixes rendering issues caused by changing FOF flags mid-level via Lua or linedef type 445. Everything else that toggles FF_EXISTS already had this fix it turns out.
Not sure if this is safe for master too, could someone check that for me?
See merge request !53
This fixes how removing certain flags (such as FF_EXISTS) from FOFs can cause HOMs on walls bordering their target sectors. Also fixes how the force-FOF-to-vanish linedef special can leave behind the FOF's shadow
Fix chain launching
Basically you're not allowed to launch off a chain the frame you touch it anymore.
Coincidentally the changes here allow you to actually use PF_*STASIS in a Lua script now and have it work as you'd expect it to (it lasts for a tic).
See merge request !49
cpuaffinity/sdl_mixer changes
Hopefully this will alleviate SDL2 sound issues.
If not, hopefully this will give us info on what the hell is going on.
See merge request !51
(No, game, you can't allocate a map header for the credits, why were you doing that before and how did it not break anything??)
(cherry picked from commit e1f9a01229)
Use whatever names you want for your music. So long as you prefix the lumps with O_ or D_, it doesn't matter anymore.
DISCLAIMER: Linedef type 413 (change music) and Lua scripting is not tested.
(cherry picked from commit 025ca413a2)
# Conflicts:
# src/p_user.c
Travis-CI builds
Merge support to build SRB2 for Linux system via Travis-Ci
This will build SRB2 with GCC and Clang to make sure we do not break Linux/GNU builds
See merge request !41
Monster Iestyn's Miscellaneous (netplay-compatible) changes
Just cleaning up some unused or unnecessary things left in the source code, see the commits for exact changes made if you like.
May add more stuff to this branch later, there's no rush really.
See merge request !39
Diagonal spring rings tweak
If you didn't know before, those special placement ring lines for diagonal springs only use multiples of 45 for their angles in-game. In other words, they only face any of the 8 basic cardinal directions (N, S, E, W, NE, NW, etc). Considering that springs themselves don't follow the above behaviour, you can probably work out that's a bad thing.
This branch changes that of course, if you couldn't guess from context. Diagonal spring rings can now be placed with any angles like most thing types already could!
See merge request !37
some of the mess in here really bothers me
(cherry-picking this commit of mine from next since it only fixes a small oversight with compiling and adds a comment)
the screen texture does not need an alpha channel.
the fact that it had one made OGL copy the topmost pixel of the screen texture's alpha channel.
which, naturally results in the screen becoming partially transparent and letting you see the working texture in the background.
g_game.c: In function 'G_CheckDemoStatus':
g_game.c:5588:22: warning: logical not is only applied to the left hand side of comparison [-Wlogical-not-parentheses]
if (!modeattacking == ATTACKING_RECORD)
^
Fixed one of Red's mistakes, and used a different struct variable for dashmode. This needs to be changed though, because everything will break if someone loads a circuit map.
