• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

Latest dev release

Messages
5,214
Hi Arno,

I downloaded your latest "test" development release and I am trying to check if it works OK or not but I have not gotten that far yet!
First, the program keeps saying I have to download the latest, although I have (I put it in a seperate folder under "testMCX" and open it from the "test" execute).
Next, I made a lot of night textures for my ferry but when finished and I wanted to resize and convert them to dds: error! imagetool not found. So I went to the options and put in the imagetool path again.
When I had finally managed to have all textures ready and wanted to export the dae file to FSX as an mdl: error! makemdl not found! the path was no longer complete (first part of the path missing). I gave it in again but had to reload MCX and everything I did was lost.
Everything else works so well and therefore it is a pity this happens. There must be a way avoid this kind of waste of time? Or should I add to the 'common mistakes' thread another item namely that when updating your MCX you should first check your paths before doing anything else?

Roby

PS When adding texture paths under options and if the path is a bit long, you can no longer see it. You either see the first or the last part of the path but not the whole path and no way to show the whole of it with the slider either because the slider switches from the first part of the path to the last party of the path and nothing in between.
 
Hi Roby,

Is this something you mainly notice since the last few days? I changed the way I build the development release a bit.

I have seen a couple of older threads were users defer to the fact that the settings sometimes get messed up. So it might also be that there was always a little problem with this.

I will look into the issue, although I have not seen such problems a lot myself.

About the texture path, the editor is not that user friendly. I think I should update it.
 
Hi Roby,

I tried it here, but it seems there are no problems on my side with remembering the settings.

I have to look how the .NET settings are saved, I think with new versions of the tool they old saved settings are no longer used. Maybe it is time to move to another way to store settings, since it is annoying when they get lost all the time.

At startup ModelConverterX will check all the paths and if they are not correct and the SDK location is in the registry they will be automatically corrected.
 
Hi Roby,

I have been doing a little more reading how .NET stores the settings. There are two things that influence where they are stored (and that also influences if they are kept with updates of versions).

The first is the version of the application. I only change that with a new release, so all development releases use version 1.3 for now.

The second is the path where the application is stored. So are you maybe storing the new development release in a different folder every time? That could result in having to manually put back all your settings every time. It is probably better to keep using the same folder name.
 
Evening Arno,

You will probably read this only tomorrow night but I was off line before because of the weather, but here is the story.
- Each time I download a new dev release I put the zip on my external harddisk and unzip into the same old MCX folder (except for the latest test MCX).
- Each time I open MCX, be it the regular updated one or the new test MCX, I get a message in the down right corner saying I should download the latest.
- Not each time but irregularly, I have to check the paths again because the first part of the path is missing and MCX will not find the paths tot the necessary tools (imagetool, Xwriter, etc.) anymore. They are not automatically corrected (well maybe the program tries to but ends up with only the last part of the path).
- I noticed it some time ago already but did not want to bother you with only a rather small inconvenience.

In the meantime I found some other minor hiccups:
- the night textures in the preview are too bright compared to the paint programs (but I still have to find out if it is true for FSX as well).
- sizing (not converting) dds textures in the mass texture editor flips the dds textures once more.
- night texture preview in the latest test dev release provokes an error but you can ignore it and continue (although this could be because of my night textures not being right yet).
- And some more small things that I have no time to mention right now because I have to shut down my computer again because of this rogue weather.

Roby
 
Hi Roby,

- Each time I open MCX, be it the regular updated one or the new test MCX, I get a message in the down right corner saying I should download the latest.

That's weird, I do not get that kind of message here. Let me do some testing, maybe the date information is parsed wrong. Which country/language settings do you have in Windows?

- Not each time but irregularly, I have to check the paths again because the first part of the path is missing and MCX will not find the paths tot the necessary tools (imagetool, Xwriter, etc.) anymore. They are not automatically corrected (well maybe the program tries to but ends up with only the last part of the path).

Looks like you settings are lost. As I explained that should only happen if you change the name of the folder. Also if they are not set correctly at startup again, that probably means that your registry entries for the SDK are not OK.

- I noticed it some time ago already but did not want to bother you with only a rather small inconvenience.

Feel free to always report these issues. I will put them in my bugtracker anyway. And if they are minor issues I will give them less priority in fixing :).

- the night textures in the preview are too bright compared to the paint programs (but I still have to find out if it is true for FSX as well).

FSX will also not render them exactly as the paint program. But the colours shown in ModelConverterX are probably not exactly as FSX either. If I receive feedback from users I will try to make the colours match better.

- sizing (not converting) dds textures in the mass texture editor flips the dds textures once more.

Let me check that. ImageTool does flip automatically while saving, but I will check if I do not by accident do it twice.

- night texture preview in the latest test dev release provokes an error but you can ignore it and continue (although this could be because of my night textures not being right yet).

Let me try if I can reproduce that here.
 
Hi Roby,

I can't reproduce the error when showing night textures. What is the exact error message you get?
 
Hi Arno,

Sorry but I cannot reproduce the error any longer either. Seems to have been a quirk in Windows or lack of memory because I had been working with a lot of programs open at the same time (MCX, GIMP, FSX and Irfanview) to check the night textures each time I changed something.
Regarding the conversion of GSU JPEG textures, I noticed two things:
If I paint a GSU jpeg night texture with RGB value 7-10-10 and convert it to dds, I end up with a texture with an RGB color value of 8-9-8 or worse depending on the size of the texture sheet. In short, the conversion is not consistent as it has a habit of changing a bit and that makes the FSX real night texture much brighter and lighter than it should..
And regarding these FSX night textures, I notice that even when I make the night texture completely black, it is always a 'blend' of the day texture and the night texture!? (For instance, I colored the ferry bow almost completely black (7-10-10 RGB) but still the lettering shows up as if it were daytime).
Can you confirm this is always the case or just something that I am doing wrong (it also shows up in MCX as 'blended').
The lettering on the bow and the rump should no longer be visible and the whole boat should be darker.
Just to show you what I mean I will risk another screenshot: see attachment.

Hope you can enlighten me.
Thanks,

Roby

PS I have not changed the location of MCX and it (uncomplete paths after updating) happened before as I noticed this a long time ago.
PS2 the jpeg-dds conversion is somewhat confusing but no bug. It turns out to be a matter of not converting to dds twice (so unchecking the dds option is the solution).
PS3 I still have this message coming up that I have to download the latest version.
PS4 (as an afterthought): can I safely download the latest dev release without bungling up MCX and induce some bugs? Sorry, just to make sure, because I would like to get rid of the 'test dev' and use the latest regular dev release once more.
 
Last edited:
Hi Roby,

Sorry but I cannot reproduce the error any longer either. Seems to have been a quirk in Windows or lack of memory because I had been working with a lot of programs open at the same time (MCX, GIMP, FSX and Irfanview) to check the night textures each time I changed something.

OK. Let me know if it happens again. When switching to the night mode the additional night textures will be loaded. So that could indeed require more memory.

Regarding the conversion of GSU JPEG textures, I noticed two things:
If I paint a GSU jpeg night texture with RGB value 7-10-10 and convert it to dds, I end up with a texture with an RGB color value of 8-9-8 or worse depending on the size of the texture sheet. In short, the conversion is not consistent as it has a habit of changing a bit and that makes the FSX real night texture much brighter and lighter than it should..

That the RGB values change a little bit when going to DDS is normal. That's what the compression is doing to the texture. So a change of 1 or 2 in the colour value is not weird.

And regarding these FSX night textures, I notice that even when I make the night texture completely black, it is always a 'blend' of the day texture and the night texture!? (For instance, I colored the ferry bow almost completely black (7-10-10 RGB) but still the lettering shows up as if it were daytime).
Can you confirm this is always the case or just something that I am doing wrong (it also shows up in MCX as 'blended').
The lettering on the bow and the rump should no longer be visible and the whole boat should be darker.

You can select different blend modes, but the default is AdditiveNightOnly. You might one to try one of the other modes. I never tried to compare them all.

PS2 the jpeg-dds conversion is somewhat confusing but no bug. It turns out to be a matter of not converting to dds twice (so unchecking the dds option is the solution).

OK, let me still take a look. I might be able to make it more user friendly :).

PS3 I still have this message coming up that I have to download the latest version.

It is on list to have a look at this. I don't get the false cues here, so hopefully I can find out why you get them.

PS4 (as an afterthought): can I safely download the latest dev release without bungling up MCX and induce some bugs? Sorry, just to make sure, because I would like to get rid of the 'test dev' and use the latest regular dev release once more.

There is a bug in the current development release that gives trouble on 64 bit systems. If you run a 64 bit system you better get this version:

http://www.fsdeveloper.com/forum/showpost.php?p=208537&postcount=7
 
Hi Roby,

I can't reproduce the problem with the update notification here. I don't get the warning here. Are you sure you are using the latest version? If you are using a one week old version for example you are supposed to get some message, since there is an update.
 
Sorry, my mistake. I updated the test version but the regular one I did not and that was the one that caused the update pop up.
 
Ah, that would make sense then :).

I had a look at the texture size issues you reported as well now. I can't reproduce it here that a second conversion flips the DDS texture again.

What I did was convert my textures to DDS with the mass texture editor. Then I went back into the editor and resized one of the textures. But that did not flip it.
 
Hi Arno,

I used DXTBMP to convert to dds and Mass texture editor to resize.
But I come back to the night mode error. I just had it once again (see attached screenshot). I tried it several times with always the error coming up.
No error report from MCX though.
And to make sure I was not doing anything wrong I tried it once more and it worked again but my windows have become completely transparent at night in MCX (but not in FSX). So I try to open the material editor to check and I get the error message again.
And one more thing regarding "night textures" and "night additive only": in my former models (made with earlier MCX versions) I do not have this blending of day and night textures so that day textures become darker and night textures lighter. So maybe something has been changed?

Roby

PS I ran the task manager to check if it had to do with lack of memory but that was not the case at all.
 
Last edited:
Hi Roby,

That error is not very informative. It does not tell more than the fact that the program stopped working, not even during which operation it went wrong or so. So I am afraid I can do little with that at the moment.

About the night textures, I recently changed how they are rendered in ModelConverterX, but no changes have been made about how they are exported by default. So that behaviour should not have changed.
 
Hi Arno,

I wish somebody would or could confirm what I am experiencing but, for the time being, leave it be as it is until somebody else chimes in.
I cannot give you more info than I did because nothing else I have available.
I do not know what you changed but the result is that night textures blend with day textures.
Thanks for all your efforts and enjoy the rest of your weekend.
 
Hi Arno,

I know you are lying in a tent in some pasture somewhere but I think you still keep on eye on what is going on on your site from time to time.
So I am pleased to tell you that your latest dev release fxed the problems with the normals and the night textures as far as I can ascertain at the moment.
Have a nice holiday.

Roby
 
Hi Arno,

Hope you have had a nice vacation.
So, back to work!:)

Following things I noticed that I think could be imperfections:
- Ground Polygon wizard: I imported a previously made ground polygon, ran it through the ground polygon wizard again and converted once more. Result: texture position does not coincide with the polygon any longer;
- Viewing semi-transparent xxx_LM textures in MCX: they are completely transparent (or do not show), changing alpha test level to 134 e.g. and you have no longer transparency, clicking on set transparency as default automatically sets alpha test level back to 230 but maybe that is normal?;
- almost completely black night textures show up in FSX as if they have been blended with the day texture. Is that normal? (textures that do not have an accompanying night texture remain a lot darker) If I compare my night textures to the ones you showed in your YouTube tutorial, mine are a lot brighter;

I suggest that others that may find possible bugs or think they have found some, put their comments in this thread so as to have them all together and surprise Arno when he comes back ;).

Roby
 
Hi Roby,

Yes, with some help from Paul I was able to fix the night texture bug before I left on vacation.

And during my vacation I did not look at the forum once. I prefer to stay away from a computer during my vacation :).

- Ground Polygon wizard: I imported a previously made ground polygon, ran it through the ground polygon wizard again and converted once more. Result: texture position does not coincide with the polygon any longer;

Humm, I will try to reproduce that here. Importing and exporting should not affect the texture positions. On the other hand, if you exported before with the FSX curve and then import again things might go wrong. You would better import the original MDL/DAE or whatever file that you made in your editor and work from there.

- Viewing semi-transparent xxx_LM textures in MCX: they are completely transparent (or do not show), changing alpha test level to 134 e.g. and you have no longer transparency, clicking on set transparency as default automatically sets alpha test level back to 230 but maybe that is normal?;

I made a change so that the alpha test level now depends on the actual alpha value, so 134 is no longer the default value. But I need to test how this works with night textures. FSX uses the day alpha for such textures, but I am not sure what ModelConverterX does. Let me take a look at this.

- almost completely black night textures show up in FSX as if they have been blended with the day texture. Is that normal? (textures that do not have an accompanying night texture remain a lot darker) If I compare my night textures to the ones you showed in your YouTube tutorial, mine are a lot brighter;

I would have to check again. I changed the default blend mode setting a little while ago because the default was wrong. So that might explain the difference. But I would really have to experiment with the different settings to give you the right answer.
 
Last edited:
Because I was having some troubles (see other thread about On Transparent Textures) I decided to download the DEV RELEASE. I used it on a model that had a flag pole in which the flag was a transparent texture.

The problem I noticed with the DEV RELEASE was that it indeed treats transparent (Set As Transparent) differently than before. With the stable release it always defaults to Greater than 134 but so far the transparency worked on all my textures (other than the double sided issue).

However, with the DEV release I noticed that when I used the Set As Transparent option (the button) the properties changed with Greater than -1. I found the -1 value odd and suspicious. When put the newly generated model and textures in FSX (after the whole conversion and library stuff) I noticed that my flag had completely disappeared.
 
Hi,

I changed how the setting works recently, but I thought it should never become negative. That is indeed not valid. Let me double check this.
 
Back
Top