Jump to content

hettoo

Regular member
  • Posts

    18
  • Joined

  • Last visited

  • Days Won

    1

hettoo last won the day on June 30 2021

hettoo had the most liked content!

About hettoo

  • Birthday 01/08/1993

Profile Information

  • Gender
    Male
  • Location:
    London, UK

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

hettoo's Achievements

Rookie

Rookie (2/14)

  • One Year In
  • One Month Later
  • Dedicated Rare
  • Collaborator
  • First Post

Recent Badges

15

Reputation

  1. hettoo

    A big thank you

    Thanks a lot everyone for keeping this game alive and the developers and server admins in particular!
  2. I don't know what version the servers use, but here is a modification of the script from the etlegacy repository if you want to take any of its code. It creates a cvar g_reviveConvergence for the convergence point, defaulting to 0.5. I've made the behaviour consistent across the two needles, so the weak one heals 1% to 49% and 20% to 30% for instance. Since it doesn't heal much anyway an alternative could be to just revive to the minimum of 50% and the convergence point in this case (so it's never better than the strong one but also never better than healing to 50%). I've attached this version too (but not tested the weak needle with that version because I got to level 3 on my server testing the other and don't know how to reset :p). Edit: added a third version, which has a separate g_reviveWeakConvergence cvar for the weak needle, set to 75% (of half the health) by default. It also fixes an error due to forgetting to round (setting HP to non-integers fails) that may occur with the other versions if the cvar isn't set to 0.5... For the original behaviour set both cvars to 0.5. medic-syringe-heal.lua medic-syringe-heal-alternative.lua medic-syringe-heal-twocvar.lua
  3. Great idea indeed. I think the reason it hasn't been done is because the reviving alive players feature is not part of etlegacy but implemented with a server-side lua script, which cannot change such client-sided view features. So unless the feature officially gets incorporated this probably won't happen. Thinking a bit about the revive feature, this is seems to have been the development: Originally players could only be revived when dead. It thus became easiest to heal almost dead players by tk'ing them before reviving, which is not great. As a solution the alive revive feature was introduced. However, now if players are slightly less than almost dead (just above 25%) they still need to be shot before able to get a revive. It seems that the feature is more of a partial fix, as teamdamage is still needed/expected but just in a different way. (Not needing the tk is of course a big improvement though.) One alternative I thought of is allowing revives below a certain threshold but proportional to how far below the threshold the player is. For instance, say the threshold is 50%. A fully dead player would be fully revived, but a 25% alive player would be revived to 75%, 49% to 51%, and so on. This still means doing some teamdamage allows for a bigger revive, but (I think) to an extent that it's more sensible to use medpacks instead of doing so.
  4. Ok, after playing a bit with bots on saberpeak I realise it's indeed not great. I'd still like to try falcon2 and/or mlb_temple though
  5. It's a bitflag with, gathering from the code, the following functionality: 1 - pushing a player upwards becomes dependent on your upwards viewing angles and proportional to the value of g_shove 2 - unused 4 - unused 8 - dynamites show owner identity when aimed at 16 - landmines show owner identity when aimed at
  6. 😛 indeed, but you can take a good position and aim at the spawn killer without receiving damage, which is an advantage that should balance out the advantage the other has. I don't currently count how many seconds I think I have spawn protection left. Most of the time I don't think about it at all. It's just there to help out, and the suggestion is about helping out more. On top of that the potential ability to keep track of these more complex rules would add another dimension of skill to the game.
  7. How about additional spawn protection as long as the player doesn't fire a weapon _and_ stays within a certain radius of their spawn point _and_ doesn't switch to pliers/dynamite?
  8. Right, ideally this would be implemented directly into the game. Even then though I'm not sure how feasible it is to automatically detect which objectives to lookout for, as it seems the objective status can just be set anywhere in the map script. That's probably why the issue has been open for a year now. Edit: etpub seems to do a simulation of what would happen if the dynamites exploded... seems a little dicey to me, as not the entire gamestate is backed up and in theory side-effects could come through.
  9. Ah, so if I understand correctly what's going on in this video the server can playback a demo and clients can connect to watch it together (but it's buggy)? What I had in mind was that the demo files would become visible somewhere on the website for instance and people could download them and watch locally by themselves. Does that have the same issues? When I did a little test earlier it seemed to work fine. The only thing that was weird was that I was watching as a spectator with the same name as the player I was in the demo, which gave some funny warning messages.
  10. I thought I saw this suggestion in a thread somewhere, but can't find it anymore: if a dynamite is planted that may end the map but the timelimit is below 30 seconds, increase the timelimit to allow the dynamite to explode. Attached is a simple lua script that does this. Some notes about it: Map and objective names need to be hardcoded, as it cannot figure out which objectives might end the map. I've put some for current ETL1 maps. Apart from the map/objective names there is a third parameter in seconds, which is extra seconds to add. This is because on fueldump there is a 3 second delay after the objective is blown up when axis can still win (a map bug imo, but that's how it is). Maybe I'll make it read the data from a separate file later. If there are multiple blowup targets (as on oasis) any one of them will trigger the functionality, just in case the other is already blown up or also being dynamited. Perhaps ideally the timelimit would be reset to what it should have been once the dynamite is defused, but the lua interface does not have access to dynamite identifiers, so they cannot be tracked individually when multiple have been planted. For some reason adding 0.5 of a minute wasn't enough and I had to increase it to 0.53 to be safe. Sometimes it shows as 30 seconds, sometimes as 31. I'm not sure where this (apparent) flimsiness comes from. I don't know if people really want this, but maybe it could be fun to try. dynamite_overtime.lua
  11. I would suggest automatically deleting the demos from over say 48 hours ago. I think people would appreciate the functionality also for other reasons... occasionally someone notes something funny happened but they weren't recording a demo and so can't look back on it.
  12. Server-side demo functionality is already implemented (demo_record, demo_stop, demo_play commands). When playing such demos you can spectate any player. It would be cool to have the servers automatically make these recordings and publish them somewhere.
  13. Hello it seems it's been a while since there has been much activity in this subforum, so I thought I'd post an overview of what I think is the general sentiment about the current map selection and make some personal suggestions as well. Do take this with a grain of salt; it's just my impressions and opinions. These are the maps I think everyone is enjoying, as they get voted frequently: caen2 frostbite sp_delivery_te venice (I get tired of this, but it gets voted a lot) goldrush-gals (same as above) adlernest / etl_adlernest_v1 bremen_final braundorf_final sw_oasis_b3 supply erdenberg_b3 pirates UJE_italy tc_base sw_battery These ones I haven't played enough to judge: raid_final (I quite like it) UJE_carentan radar decay_b7 lighthouse2 (so far I think it's cute, but axis do get massacred at their spawn and trying to climb up) frost2_final mlb_hotchkiss (seemed very easy to get lost here the one or two times I played... not convinced) Finally, these ones I'm pretty sure people don't like so much: western tits_b2 baserace_desert (although some love it... but there is a dedicated baserace server) UJE_fueldump_cp (perhaps this is more popular when the server gets busy; I usually play earlier) dubrovnik_final (it's not that bad, but I'm pretty sure half of the players are still confused about what's going on in the beginning... I know I am) dingenskirchen (very pretty map, but the objective may be a bit much I think) Personally I would really like to see falcon2 and saberpeak_final, which were played a lot back when I first played this game. These are nice and bright maps (too many dark concrete jungles deter at least me from playing) with what I think are reasonably understandable objectives. I know the first bit of saberpeak may seem a bit big and open, but there is room for closer fights behind the mountains, and there is always the second part. I also wouldn't mind trying mlb_temple (perhaps instead of hotchkiss?), although I realise it's quite big... is the server currently using the player count filtering for votable maps (https://github.com/etlegacy/etlegacy/commit/128b9a829704a2929f6d1e94fc7e1844efdcbc66)? This could be useful also for fueldump for instance, and maybe certain small maps could be allowed only with few players. As one last crazy request I wouldn't mind seeing more roofs and ledges in goldrush-gals unclipped (the way they are in SuperGoldrush_Final for instance) if there is any mapper around able to do so. That would make the map a bit more exciting again for me. 😛 Anyway, I hope this is of any use! I'd be happy even if it just turns into a conversation starter on what to add/remove next.
  14. Awesome, thank you!
  15. Thanks here's a few more for you. caen01.dm_84 caen02.dm_84 caen03.dm_84 caen04.dm_84 caen05.dm_84 frostbite01.dm_84 raid01.dm_84 raid02.dm_84 venice01.dm_84 venice02.dm_84
×
×
  • Create New...