MantisBT - Zandronum |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0001958 | Zandronum | [All Projects] Suggestion | public | 2014-10-12 17:31 | 2016-02-21 22:00 |
|
| Reporter | Fsn76 | |
| Assigned To | | |
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | no change required | |
| Platform | | OS | | OS Version | |
| Product Version | | |
| Target Version | | Fixed in Version | | |
|
| Summary | 0001958: Player radar for showing where allies are. |
| Description | Like in ZDaemon, a radar is really useful for seeing where allies are when you cannot communicate with them through Teamspeak. It is also great for other modes like Coop to see where your allies are. Should be nice to customize it (ex: show flag carriers as a certain color...) |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | |
| Attached Files | |
|
| Issue History |
| Date Modified | Username | Field | Change |
| 2014-10-12 17:31 | Fsn76 | New Issue | |
| 2014-10-12 18:05 | Watermelon | Assigned To | => Watermelon |
| 2014-10-12 18:05 | Watermelon | Status | new => assigned |
| 2014-10-12 18:07 | Watermelon | Note Added: 0010552 | |
| 2014-10-12 18:08 | Watermelon | Assigned To | Watermelon => |
| 2014-10-12 18:08 | Watermelon | Status | assigned => feedback |
| 2014-10-12 18:16 | Fsn76 | Note Added: 0010553 | |
| 2014-10-12 18:16 | Fsn76 | Status | feedback => new |
| 2014-10-12 18:30 | Watermelon | Note Added: 0010554 | |
| 2014-10-12 18:30 | Watermelon | Status | new => feedback |
| 2014-10-12 20:44 | Fsn76 | Note Added: 0010558 | |
| 2014-10-12 20:44 | Fsn76 | Status | feedback => new |
| 2014-10-12 23:48 | Dusk | Note Added: 0010564 | |
| 2014-10-13 13:51 | Karakurt | Note Added: 0010568 | |
| 2014-10-15 05:48 | hjalg | Note Added: 0010590 | |
| 2014-10-15 10:42 | Leonard | Note Added: 0010592 | |
| 2014-10-15 12:28 | Karakurt | Note Added: 0010593 | |
| 2014-10-15 16:10 | Watermelon | Note Added: 0010597 | |
| 2014-10-15 16:12 | Watermelon | Note Edited: 0010597 | bug_revision_view_page.php?bugnote_id=10597#r5768 |
| 2014-10-16 02:51 | Watermelon | Assigned To | => Watermelon |
| 2014-10-16 02:51 | Watermelon | Status | new => assigned |
| 2014-10-16 03:02 | Catastrophe | Note Added: 0010607 | |
| 2014-10-16 03:03 | Catastrophe | Note Edited: 0010607 | bug_revision_view_page.php?bugnote_id=10607#r5778 |
| 2014-10-17 12:37 | Watermelon | Note Added: 0010614 | |
| 2014-10-17 12:39 | Watermelon | Note Edited: 0010614 | bug_revision_view_page.php?bugnote_id=10614#r5788 |
| 2014-10-17 12:50 | Karakurt | Note Added: 0010615 | |
| 2014-10-17 12:50 | Karakurt | Note Edited: 0010615 | bug_revision_view_page.php?bugnote_id=10615#r5790 |
| 2014-10-17 20:17 | Dusk | Note Added: 0010617 | |
| 2014-10-17 20:18 | Dusk | Note Edited: 0010617 | bug_revision_view_page.php?bugnote_id=10617#r5792 |
| 2014-10-18 01:46 | Catastrophe | Note Added: 0010618 | |
| 2014-10-18 02:53 | Watermelon | Note Added: 0010619 | |
| 2014-10-18 02:55 | Watermelon | Note Edited: 0010619 | bug_revision_view_page.php?bugnote_id=10619#r5794 |
| 2014-10-18 03:42 | Catastrophe | Note Added: 0010620 | |
| 2014-10-18 03:46 | Catastrophe | Note Edited: 0010620 | bug_revision_view_page.php?bugnote_id=10620#r5796 |
| 2014-10-18 03:47 | Catastrophe | Note Edited: 0010620 | bug_revision_view_page.php?bugnote_id=10620#r5797 |
| 2014-10-18 03:48 | Catastrophe | Note Edited: 0010620 | bug_revision_view_page.php?bugnote_id=10620#r5798 |
| 2014-10-18 12:58 | Frits | Note Added: 0010621 | |
| 2014-10-18 13:00 | Frits | Note Edited: 0010621 | bug_revision_view_page.php?bugnote_id=10621#r5800 |
| 2014-10-18 16:36 | Watermelon | Note Added: 0010625 | |
| 2014-10-18 16:39 | Watermelon | Note Edited: 0010625 | bug_revision_view_page.php?bugnote_id=10625#r5802 |
| 2014-10-19 08:38 | Dusk | Note Added: 0010630 | |
| 2014-10-19 08:39 | Dusk | Note Edited: 0010630 | bug_revision_view_page.php?bugnote_id=10630#r5804 |
| 2014-11-11 03:09 | Watermelon | Note Added: 0010857 | |
| 2014-12-01 13:27 | Watermelon | Target Version | => 1.4 |
| 2015-01-06 08:15 | Dusk | Target Version | 1.4 => |
| 2015-03-03 10:16 | Karakurt | Note Added: 0011768 | |
| 2016-02-21 22:00 | Dusk | Note Added: 0014471 | |
| 2016-02-21 22:00 | Dusk | Status | assigned => closed |
| 2016-02-21 22:00 | Dusk | Assigned To | Watermelon => |
| 2016-02-21 22:00 | Dusk | Resolution | open => no change required |
|
Notes |
|
|
|
This is very useful in other ports for sure.
How much customizable ability would we like to put into this? I figure some cvars for size, color, location of rendering?
In case anyone recommends it, am_overlay 1 is not a proper fix for this (it looks bad, cant be fit in a corner, requires pressing a button and is insanely messy when rendered on a moving screen in most maps). |
|
|
|
(0010553)
|
|
Fsn76
|
|
2014-10-12 18:16
|
|
Yes water, that was exactly what i wanted.
And to have the choice to set your radar transparent or solid, like the zd scoreboard. |
|
|
|
|
|
Can you comment about the sizes and how it works at ZDaemon? Like do they allow you to change the size of it no matter the resolution? Does it scale? Can you customize anything on it? ...etc |
|
|
|
(0010558)
|
|
Fsn76
|
|
2014-10-12 20:44
|
|
|
Yes. You can change the size, the scaling and the position. That all you can change in zdaemon. |
|
|
|
(0010564)
|
|
Dusk
|
|
2014-10-12 23:48
|
|
|
I don't think this is necessary to implement on the engine side as this can already be implemented as a mod. |
|
|
|
|
|
I second this. Zandronum should have that feature as well. |
|
|
|
(0010590)
|
|
hjalg
|
|
2014-10-15 05:48
|
|
|
Absolutely useless. It can be implemented as a mod, like Dusk said. |
|
|
|
|
|
Then go ahead hjalg. Do a mod and put it in your skin folder. If it ever works online we'll be glad to hear about it. |
|
|
|
|
THIS IS USELESS IT CAN BE IMPLEMENTED WITH A MOD, JEEZ!!!!!!!!!!!!!!
If you have the skill and the will for, then go ahead.
Still this would require some skill, so yeah, it'd be better that devs try working on it. |
|
|
|
(0010597)
|
|
Watermelon
|
2014-10-15 16:10
(edited on: 2014-10-15 16:12) |
|
Quote
Absolutely useless. It can be implemented as a mod, like Dusk said.
I 100% disagree on it being useless.
While a mod can make it (as other mods have done), there are things that can be done though the actual code that cannot be done otherwise (without probably gigabytes of images, many algorithms, thousands if not tens of thousands of lines of code) and most likely other things I'm forgetting.
|
|
|
|
(0010607)
|
|
Catastrophe
|
2014-10-16 03:02
(edited on: 2014-10-16 03:03) |
|
Unless this shows linedefs w/o pressing tab then it's pointless imo.
|
|
|
|
(0010614)
|
|
Watermelon
|
2014-10-17 12:37
(edited on: 2014-10-17 12:39) |
|
Really really basic test:
'http://imgur.com/XAWveFp [^]'
Proof of concept works, I'm going to apply the Cohen-Sutherland algorithm to clip that leak outside the radar (as I only apply a really quick check to see what can be drawn).
So far the radar can:
- Zoom in, zoom out
- Render all players on your team, or everyone as spec
- Specify which lines you want (white, gray, both, or none)
- Can put it at any corner
- Can change dimensions on the fly
Actually just see this:
'http://imgur.com/bvmyIgK [^]'
A lot more to be done however.
|
|
|
|
|
God, this is already looking awesome !
Kudos for making the radar options.
Keep it up!!!!!!
|
|
|
|
(0010617)
|
|
Dusk
|
2014-10-17 20:17
(edited on: 2014-10-17 20:18) |
|
... okay I'm impressed.
Some notes about the menu interface:
- "map units per pixel" looks like could probably be simplified down into a "radar scale" slider
- the two "draw one/two-sided linedefs" options could be condensed to "draw linedefs" with three options "no", "1-sided only", "all".
- I don't see the reason for the space between "draw radar" and "radar alpha". The second space could possibly also be axed.
- perhaps the radar sizes could also be sliders? It's more convenient to press left-right arrows to change the size than entering a number.
Any reason why it's specifically for teamgames? Couldn't deathmatch also benefit from it? And it could also be useful as all heck for survival if you hide the lines appropriately. Also maybe you could make it use automap colors?
|
|
|
|
|
This certainly puts my ghetto minimap to shame. I have a couple things to suggest.
1. Make it usable in all gamemodes.
2. Some mods have icons for locations in the minimap (Like zombie horde), could that be shown as well?
3. (A little controversial opinion) Could this show where BFG's are in DM maps? Hidden BFGs are seriously pointless and serve no purpose but for people to stomp noobs. |
|
|
|
(0010619)
|
|
Watermelon
|
2014-10-18 02:53
(edited on: 2014-10-18 02:55) |
|
@ Dusk:
Those are great ideas, I'm going to clean up the code and add those in
@ Catastrophe:
I like the idea of using it in all the gamemodes. I assume it couldn't be used in DM for players, but it can be used for other things. I'll remove the gamemode limits and set it to only render players if its online or only allies in a team game.
Since this mini radar can literally show anything, the question is... what should be allowed to be drawn?
It can be extended far past the basic example I gave, and maybe even opened up to modders to mark things on them like the minimap.
Since some people might be against certain things being shown, possibly a 'radarflags' could be added to allow and disallow what can and can't be shown?
So far I've set the player images and background to actually be an image. Even though they could be drawn to the screen as lines, this allows me to apply alpha to them, and to scale them as desired. It also allows for people to customize the images later on if they wish.
|
|
|
|
(0010620)
|
|
Catastrophe
|
2014-10-18 03:42
(edited on: 2014-10-18 03:48) |
|
Though I'd like an option to allow people to render enemy players in competitive modes. As I'm working on a racing mod, and in most racing games you are allowed to know where your enemies are at all times.
As for things that should be allowed to be rendered. Imo, if you can see it in doombuilder, you should be allowed to render it on the minimap. Of course, I don't mean slave away at rendering meaningless things like decoration, but instead weapons, powerups, etc.
|
|
|
|
(0010621)
|
|
Frits
|
2014-10-18 12:58
(edited on: 2014-10-18 13:00) |
|
What steps are you going to take to stop someone from using this radar in a malicious way?
I'm not a coder but it probably won't be hard to make a build where the radar shows everyone all the time. Zdeamon does not have this problem because its source is closed.
|
|
|
|
(0010625)
|
|
Watermelon
|
2014-10-18 16:36
(edited on: 2014-10-18 16:39) |
|
With the source being open, it's very easy for anyone to take this -- or any part of the engine -- and adapt it to be malicious.
Hopefully I can answer these as best as I can for you:
Quote
What steps are you going to take to stop someone from using this radar in a malicious way?
Sadly there isn't much that can be done. I can obfuscate the variables so it goes from something like:
ulPlayerPoint.x = ClipPlayer(myVariable + anotherVariable) >> 1;
and turn it into
int c1_=2;ka.z=v(-c1_+x7_+__z_+c1_)/c1_;
The only problem there is that the radar becomes unreadable for developers and we'd quickly be unable to add things or fix bugs.
Quote
I'm not a coder but it probably won't be hard to make a build where the radar shows everyone all the time.
I did a test where I tweaked the radar to show everyone, and I tested it with the time it took for me to edit the actual rendering functions to show me people behind walls. It took me the same amount of time to achieve both a wallhack and showing everyone on the radar. In probably 2-3 minutes I could make it so I'd have a functioning aimbot.
It's quickly exploitable to almost anyone who knows how to code. Our only solution is to just ban anyone who looks like they are cheating. Luckily doom is a small community and we know most people, plus it's obvious at times when someone just knows exactly where to go each time ;)
Quote
Zdeamon does not have this problem because its source is closed.
I talked to the ZD devs who are in charge of stopping hacks, and they have multiple hacking attempts every week of people who modify/inject code into ZD. Even with closed source, they still get common attacks. It is of course easier with zandronum since as you said, the source is open. Usually though getting this project to compile properly can be enough of a pain that it deters pretty much anyone anyways who wants to make hacks (which is sort of funny now that I think of it).
This is worth reading if you are interested on the subject:
'http://stackoverflow.com/questions/533965/why-is-security-through-obscurity-a-bad-idea [^]'
|
|
|
|
(0010630)
|
|
Dusk
|
2014-10-19 08:38
(edited on: 2014-10-19 08:39) |
|
Quote
I can obfuscate the variables so it goes from something like:
ulPlayerPoint.x = ClipPlayer(myVariable + anotherVariable) >> 1;
and turn it into
int c1_=2;ka.z=v(-c1_+x7_+__z_+c1_)/c1_;
No no no no no NO. We shouldn't need to alienoverlord the source just because it'd be 'too easy' to hack the binary. If you want to cheat like this, you can already make a wallhack with a few simple modifications, or hack the automap with even simpler changes.
And even if you obfuscate it like that, whoever already has taken the measures to hack the source won't be put away with some math in the source just like that.
|
|
|
|
|
|
ZDoom allows for subsector texturing, but I'm unsure if I want to go that far (at least yet). |
|
|
|
|
|
Sorry to dig up the ticket but I wanted to know where this is at? |
|
|
|
(0014471)
|
|
Dusk
|
|
2016-02-21 22:00
|
|
|