Spring RTS Engine

https://github.com/EvolutionRTS/Evoluti ... ictory.lua

Over time and constantly for the past several months I have been hacking away at this gadget. Smoth did a lions share of the work by revamping the scoreboard and setting the stage for proper coloring for team names and rings (some of which seems to be broken in 101+).

The color issue is by far one of the more important issues, but this issue makes it nearly unplayable.

That is the fact that the rings that get drawn on the minimap get cleared randomly. Sometimes it's caused by zooming in too far on a feature, or moving the camera around too quickly. I've spent a shitload of time ruling out any widgets or gadgets clearing the minimap.

Well the first problem with it is that all the drawing happens in an "unsynced" side of a gadget, which is automatic set sail for fail. I've been trying to figure out how to port the drawing stuff out to a widget, but I'm not having a lot of luck. I have a feeling that once it's in a widget, the minimap drawing will be easier to control/diagnose. Not having the rings visible on the minimap makes the game unacceptably unplayable. I found that some players (koyotekamper on a laptop and I believe ikinz uses an amd card) have never even seen the rings on the minimap, either that or they have never noticed them before they disappear. Reloading luarules does not bring them back. Neither does /luarules disable -> /luarules enable.

The "unsynced" portion starts at line 278:
https://github.com/EvolutionRTS/Evoluti ... y.lua#L278

Could someone help me move this over to a widget? Either that or if you don't want to deal with my questions/inexperience do it for me? This poses a complete block for me moving evo forward as the gameplay is hinged on this gameplay aspect working properly.

As I said, I'm thinking that it's likely that once it's in a widget, the minimap drawing issue will likely disappear, and if the issue persists, I am thinking that it will be much more simple to diagnose.

Are you sure you shouldn't use the parameters of DrawInMiniMap(mmx, mmy) ?

gajop wrote:Are you sure you should use the parameters of DrawInMiniMap(mmx, mmy) ?

^^FTFY (I think)

After spending the better part of all day trying to figure out what you were trying to say (because I couldn't test until much, much later), I think you meant to say that perhaps using the params there was not a good idea. So, I removed them. Seems to work fine. I'll keep testing. Thanks

No, that's not what I meant. Removing them shouldn't have an impact.
I saw that you weren't using them, so maybe if you did, you could have correct rendering. I'm not entirely sure what they do.

Those parameters are (normally) not needed, I don't remember exactly which ratio is supplied but in terms of information they tell you how deformed the minimaps current rectangle is from the true map dimensions.

What is often handy is something like http://imolarpg.dyndns.org/trac/balates ... x.lua#L111, which allows you to use gl inside addon:DrawInMinimap as though you were drawing in the xy plane onto the true maps xz plane, as in http://imolarpg.dyndns.org/trac/balates ... x.lua#L301

I can't see an advantage in moving the unsynced part of that gadget into a widget.

Silentwings wrote:I can't see an advantage in moving the unsynced part of that gadget into a widget.

Scoreboard in a chili widget
If something gets messed up graphically, luaui reload does not require cheats
More control from a user perspective
etc

******************************

Why the hell do the rings show up or not show up on the minimap? Sometimes they get drawn, sometimes they don't. It's completely random.

Can someone help me out here? Is it an issue wrt WHEN they are drawn?

Ah - my comment that there is no gain to widgetizing refers to your original reason:

I have a feeling that once it's in a widget, the minimap drawing will be easier to control/diagnose.

widget:DrawInMinimap and gadget:DrawInMinimap will behave essentially identically.

I suggest debugging the output of the synced part of your code, it looks unlikely that your DrawInMinimap code would behave in some cases and not in others, when passed proper information -> maybe sometimes it's sent the wrong info.

That's just it, line 338 is DrawPoints()

Both DrawWorld() (drawing rings on the map itself)
and DrawInMiniMap()

both call DrawPoints()

The rings on the map ALWAYS work. The rings on the minimap sometimes show up, but when they go away, they are gone for good. No amount of reloading luarules will bring them back. Only way to get them back is to completely restart spring. It doesn't even come back when you exit to menu and restart the game. You have to exit spring entirely and then start it up again.

If they are showing up for me and I delete the cache folder, they disappear. Undeleting the cache folder brings them back.

As you can seem there is some real fuckery going on.

If they are showing up for me and I delete the cache folder, they disappear. Undeleting the cache folder brings them back.

If you suspect your archives are corrupt, you should address that before thinking of anything else.

Also, as it stands this statement cannot be correct, since deleting the cache folder alone will not change the contents of the VFS while Spring is running (e.g. you presumably also luarules reload and/or restart Spring).

The rings on the minimap sometimes show up, but when they go away, they are gone for good. No amount of reloading luarules will bring them back.

If archives are fixed, and DrawWorld suceeds whilst DrawInMiniMap doesn't, and you have an Echo to check that the DrawGroundCircle call recieves the correct info when used in DrawInMinimap, then I suspect its worth checking if some other gadget runs in between the two callins and leaves unwanted stuff behind in the gl state. You can check for this by testing with all other gadgets that use Draw* calls removed from the start.

Whether you intend it or not, your tone is insulting. There is nothing wrong with the "archives". The cache was an effort to cause the problem to reliably repeat itself instead of opening a game and waiting for the rings to randomly disappear.

I made a video that addresses ALL of your concerns and covers every single scenario that I can come up with. PLEASE watch it all the way to the end, and pay attention. I was very thorough.

Video: https://youtu.be/wrH9kQodYxY

I streamed it in 1080p, so if it's not showing 1080p for you it means that youtube hasn't finished processing it yet. The video covers basically everything and should hopefully be somewhat enlightning. Perhaps it can provide a clue as to something that is missing, or maybe thar be dragons...

Give it a try: https://github.com/EvolutionRTS/Evolution-RTS.git
Here's a map to test with: https://springfiles.com/spring/spring-m ... wastelands (you need a map that has a point config)

I tried but I couldn't reproduce.

Well that sucks :-/

For me the rings show up most of the time. For Ikinz and Koyote, they have never seen them.

I don't get it

Regardless, Thanks for trying.

Ok, so this happened:
So I started thinking outside the box...

Drawinminimap happens twice a second from what I can tell, same for drawworld. Therefore, if the circles are there one moment but not the next, something really weird is wrong, so I started working down the list of params given to each.

In drawinimimap I noticed that scale is supplied... ok that makes sense, it's the minimap, but what doesn't make sense is that it's supplied thusly:
mapsizex, mapsizez, 1

wtf?

gl.Scale() in the wiki is xyz... So I started thinking, what if they were being drawn, but just off of the minimap screen size. So I started playing around. First I echoed the mapsize just to make sure that they returned pixel dimensions of the map... they do.

Next Instead of calculating it, I simply put the map size numbers in, which didn't work at all... wtf? It's the same number, so why would the actual number not work but a calc does?

So then I started looking at Z and trying to sort it out. Ok, it makes sense if the Y in scale is on a flat plane representing north and south, instead of up and down. But still, why a third param if it's a 2d plane?

I started to suspect that Z played more of a part than I realized. I have read on these forums of issues where coords are flipped, so what if gl.Scale is actually XZY (3d coords), that would make PERFECT sense, because then perhaps that's why using mapsizeX (which resolves to 6144 in this test) works, because if it is drawing at a distance ABOVE the minimap, then 6144 would certainly be higher than anything else.

Weird logic and it's difficult to wrap my head around, but in a perverse sense I understand it.

So in 3d terms, is gl.scale actually XZY (north/south, east/west, raise/lower)? If so, that solves months of frustration and anger.