Map Editor: Self Lit Object Function doesn't show preview in editor

[EternalAcelon]

When placing a 3d Object, you are able to select "L" to toggle Self Lit on/off. When toggled on, you are able to adjust the Red/Green/Blue elements of the object, which also affects the light of the surrounding area. In past iterations of the map editor client (12+ years ago), you were able to see the preview of what color the object would appear ingame, but one of the updates removed this option.

As of now, the only way to truly know what color the object will become is to save the map and test it in the ingame client. (This maps editing the color quite difficult and tedious.)

Screen shot of the current functionality attached. As you can see, the object had the red increased, and should appear red itself. Map editor shows how it affects the surrounding area light (the grass is red) still.

[feeltheburn]

Just a note: If this is implemented (no opposition here, it would obviously be useful), there should be a way to easily single-keypress toggle all self-lighting on/off for the entire map as needed.

This because I can picture times it would be easier to work without it on.

[EternalAcelon]

I'd classify it more as a bug vs a feature recommendation, as this used to be available and something broke it.

[feeltheburn]

I'm not submitting a fix because I haven't tested this enough to ensure it works properly. However:

Possible fix: In map_editor/e3d.c

Change line 94: glDisable(GL_LIGHTING);
to: glEnable(GL_LIGHTING);

And just turn the Dungeon setting on/off to see/not see it?

Here's the result. The exact same map example, the left editor has my fix, the right is the current status.

[feeltheburn]

Here's a better example, the current Kusa temple entrance (cont2map9_temple). The fixed left-side version looks much closer to the actual lighting seen in the client than the right.

The self-lighting slowly changes to the yellowish color at the bottom of the stairs from that of the entrance. On the right, it's just the color of the actual objects used to make the stairs and floor. The mushrooms and other growth at the entrance also fails to show their colorization (or being turned almost black) in the current format but show them in the fixed version.

[feeltheburn]

I've submitted a pull request, as it seems this is how it should have been in the first place.

@pjbroad bluap (or any other Windows compiler): Could we get an updated map editor build including this fix for Windows? (For Acelon, I don't use Win.)

[pjbroad]

I've submitted a pull request, as it seems this is how it should have been in the first place.
@pjbroad bluap (or any other Windows compiler): Could we get an updated map editor build including this fix for Windows? (For Acelon, I don't use Win.)

Sure, I can do that.

[feeltheburn]

@pjbroad Thanks. Don't forget to merge the pull request for the fix. I see you've done some compiler warning stuff for the editor. #192

[pjbroad]

Well, this is taking more effort than I expected. Nothing to do with your change, but I'm having problems building a version that does not crash immediately.

[pjbroad]

Interesting that it builds and runs on Ubuntu 20.04 but not Arch (which I've recently switched to) or Windows that uses the latest libraries (like Arch). Could we finally have been forced to update to newer GTK and SDL versions? The crash is deep within GTK calls.

[feeltheburn]

Well that's not good. :-/ Not the best-designed program, but it's never been crash-happy here on my OpenSUSE.

[gvissers]

Not sure if this is conincidence, but the map editor also crashed upon start on my Arch installation immediately (in SDL_WM_SetIcon, and when I removed that call, in GTK when I tried to open a file). In my case though, it was caused because I was messing around with video drivers and was using xf86-video-intel at the time. After removing that and reverting back to using the kernel modesetting driver, the map editor runs normally. Using xf86-video-intel was a bad idea overall, some fonts became tiny, I had random hickups, tab expansion took forever, so good riddance to that.

[gvissers]

No luck on windows though. Immediate crash w/ exit code 0xc0000139. Which appears to be a failure to load a DLL. Would be useful if it said which DLL.

[pjbroad]

I've got it running on Arch now, I committed a couple of minor fixes. The XInitDisplay() call is interesting, because I've seen reference to that with client crashes too. When I investigated it looked to be a library issue and I've never seen it on Arch or current Ubuntu.

The up side of the issue and the fixes, is that the editor now works using SDL2 (there's a minor change to update an addition made since I did the SDL2 port). It previously crashed on dialogues too.

I also have a working map editor in windows but the DLLs are a mess as many have changed. I'll finish sorting that out this evening.

[feeltheburn]

Just FTR, I've now tested this more than enough to qualify that it's working as it should.

[pjbroad]

I've merged it. I'm still chasing down bugs to get updated builds.

[pjbroad]

Here is a build for windows containing this fix and the other fixes I've committed.

1. Extract the zip into a new directory as the DLLs will clash with the client.
2. If the buttons and maps don't load, you need to set your data_dir in ".../Documents/Eternal Lands/mapedit.ini"

Let me know how you get on.

[EternalAcelon]

Thanks bluap! So I'm noticing something off with the coloring right away. It seems the color in map editor doesn't match up to what actually appears ingame (it's much more muted in map editor). I've included a screen shot of the exact same spot - ingame on the left and map editor on the right.

[feeltheburn]

I don't really know enough to look into that myself, even the fix I posted was something I luck-stumbled on. ;-)

Maybe we're getting into the territory of why it got removed in the first place? Or there may just be underlying reasons why they can't be exactly the same?

[EternalAcelon]

Not sure! It seems that it works fine on your side, Burn. So not sure what the main difference is between your build and the windows build

[feeltheburn]

Actually it may be the same for me... in the Kusa temple image I posted above, the dragon statues are a lot darker in the client.
It's a lot closer though. I think client testing can't be completely removed, this just makes it closer.

[feeltheburn]

Hmmm, I honestly don't think we're gonna get better than the patch I submitted. It's enough to work with, it at least shows the items better. I didn't see how it could be any better, the rendering in the editor is just "different".

Unless someone thinks they can make it better, I'm thinking we can close this.