shai

Updated: v170407 Heavily reduced the time it takes to save the map and mis file Replaced the settings bellow with the following new settings: 'numberOfSandSpecialsToAdd', 'numberOfRockSpecialsToAdd', 'numberToAdd', 'numberOfSpiceSquares', numberOfDuneSquares', 'numberOfIslandSquares' 'sandSpecialFreq', 'rockSpecialFreq', 'rockFreq', 'spiceFreq', 'duneFreq', 'islandFreq' These new settings are instead now a percentage. Ex. If 'rockFreq' is set to 0.2, then roughly 20% (0.2 * 100) of all blocks on the map will be a rock tile All areas have been properly altered to prevent it from getting stuck due to a value that is too high Improved the GUI Fixed the AI in the mis files being incorrect Partially fixed the placment of the dune edges Altered how the openings in the cliff faces are added, they can now be varied in size Sped up the placing of player spawns somewhat with 'autoSpaceSpawns' enabled, and the placement of spice blooms After a map is completed, the time it took to make it is displayed Prevented cliff faces and rock-to-sand edges from having two identical blocks right next to each other The new version can be downloaded above in the first post of this thread, apologies it has been a while since the last post

Ok, I've made some quick changes to hopefully reduce the time it takes for now, later on I'll rework it completely. My PC is a Pentium E5300 @ 2.60 GHz with 4GB of RAM, I'm not sure if I'd consider that too fast, since it gets pretty slow sometimes, but I don't know what other people have. The only other spot where it takes a long time is "Entrances edges added" after the islands are added, it runs for about 8 seconds or so on just it, so I need to fix that too I'll work on that some more when I have the time, I wont make it much of a priority just yet. Ok, I'll add those pictures back in and continue adding them. Yes, I know about github and I've checked out the one for your map editor a few times before. Though to be honest, going into it without knowing too much was pretty confusing, and I only got as far as setting up an account before I didn't really know where to go. It didn't help that the program to manage it ran horribly slow on my system. When I'm finished with this version I'll go back and try at it again.

Oh yes, I know it still needs to be majorly improved, in the last version I posted there were still a few points left over where it could get stuck, but in the most current version I'm still working on it should be all good. Hmm, I'm not too sure what was the cause of that crash there, when I try a 16x16 map on that same version it runs fine, but I'll look into the cause of it. But a 16x16 map anyways is pretty much useless, since it's just too darn small. A 32x32 map is better, and mathematically the settings should be about 6.25% of the default values, although they would certainly need to be a little bigger than that, maybe about 10% or so. Now, it obviously would be annoying to manually change each value individually, and while there is the setting 'useSettings' which approximates most of the settings based on the size of the map, it would benefit from a large overhaul in general on that. It's starting to feel a little like all the settings are getting a bit disorganized, so I'll need to start rethinking a fair bit on bringing them all back together. I'm now using a percentage on the special tiles, for example the new setting 'sandSpecialFreq' set to 0.004 would have 0.4% of all sand tiles occupied by a sand special tile, I'll for sure see what I can do about making all settings work on a percentage system like that.

I've started work on the previously mentioned 'Markov' type idea, and to start I compiled a list of all tiles in the 36 stock maps. data.zip Inside are 800 text files, one for each tile. Inside each text file are 8 sections called 'direc_', with '_' being a number from 0 - 7, This 0 - 7 number represents a direction from a particular tile, the directions go in a clock-wise circle starting from the top left. Under each section are all 800 tiles listed again with the number of times that they occurred in that direction, from that particular tile. In case you have no idea what the heck I'm talking about, here's a visible example: The empty square in the middle is any particular tile. Under the section [direc4] are the number of times any other tile appeared in the bottom right of that tile. Looking at one of the text files for another example, in '48.log' under the section [direc4] is '52=561'. This means, with all the stock maps put together, tile 52 appeared a total of 561 times at the bottom right of a 48 tile. In '480.log' under [direc5] is '411=1', tile 411 only ever appeared once directly below the tile 480. This probably isn't enough to make a good working generator of this type, but it's a start

That looks like a pretty creative way to make a map, quite interesting. And thank you!

I realized after that there were still some parts where it could get stuck, but I should have fixed all of those occurrences by now. What settings are you running it on? I have not had it get frozen up on me when I tried values that were higher than the default, and certainly not when they were on the default. But I do notice that those parts do take a little bit longer than all the others, I will have a look at redoing them. For me, it takes roughly 1 minute and 30 seconds to make a map at 128*128, with a .mis file, which I now realize is probably much too long to wait for a map to be made. I suppose it's also worth mentioning that a decent amount of that time over all is spent writing the map and mis file to the disk, so it'd be a good idea to rework that area as well. I only have one computer to test this on, so I appreciate your feed back. Problems like this where it runs slowly on some systems are definitely a big issue

Yes, I am quite glad it's coming all together so quickly now You can find more information under this link. Scroll to the bottom, as the oldest posts starts at bottom and newer appear upwards. It's really interesting to read and there are good examples (screenshots) of the levels it produced. As you can see, the levels it generates are quite cluttered mess which are not playable at all and need lot of human modifications to become playable. However, it's actually improving during the time, and I'm really curious how well this method will work for Dune2000 maps, after creating probability profiles from all stock maps. Very interesting, I briefly thought of this kind of method the other week but I did not dig too far into the idea. I will definitely look more into it now though, but I'll need to first learn how that type of generator generally works The way I was planning on generating the sand-sand cliffs is similar to this, though all I have for it so far are the tiles drawn out on a piece of paper, no real code or anything made for it. Hopefully by the start of next week I will have actually started on it. But doing that for everything like you say would be rather interesting as well, but fairly difficult too. I don't think I'll be trying anything like that too soon, but I will hold onto the idea

Updated: v170322 Implemented safe guards to prevent the program from locking up; you may now set the settings as high as you want All 7 original tilesets are now supported Now creates a .mis file to go with the map Added new setting: 'addMis' Setting to true will create a .mis file, false will not Added new setting: 'autoSpaceSpawns' Setting to true will use a new, better method to add the spawn points in a more evenly distributed layout. 'spaceBetweenPoints' is not used under it A 'README.txt' file is included which explains the settings and how to use the generator The new version can be downloaded above in the first post of this thread

I do recall running into this problem the other day, but I believe I have fixed it. In my case, it was because the other settings were not being resized correctly to account for the smaller map size, and by the time it got to that step there just was no more room left. I will go and add in some measures to prevent any step from getting stuck like that. That's a good idea, I will do that as well.

Hey @Klofkac, I got a question about the other files with your map editor. Why is the 'default_ai.misai' file included only 7607 bytes when the template on the wiki and the game seems to require it to be 7608 bytes? Edit: I think I found out, the first byte is supposed to be the player number, oops

When just a normal custom map is launched through the CnCNet launcher, it uses the tileset as specified in the corresponding .mis file, correct? Is everything else in the .mis file ignored?

Updated: v170317 Added a new system where all you need to do is specify the map dimensions and tileset, and the remaining values will be estimated. Setting 'useSettings' to false will enable this. Added a basic interface which utilizes the above feature. To use it, run the 'runGUI.bat' file. 'Load Defaults' will load the settings last saved and 'Quit and Save Defaults' will save the current settings Picture: Now uses the tileset ini files from Klofkac's Map Editor for the tile info Added new setting: 'numberOfEmptyBlooms' Like how 'numberOfBlooms' would be the start of a spice field that has a spice bloom, 'numberOfEmptyBlooms' is the start of a spice field that does not have one Added new setting: 'addTimeStamp' Setting this to false will disable the time stamp that is added to the end of a map's file name Reorganized the settings file to be more neat Spice blooms are now ensured to be spread across the map more evenly 'Islands' can now become merged with the rock-to-sand openings in the cliff walls Altered the list of rock tiles in use The new version can be downloaded above in the first post of this thread As well, here are things that still need to be done or fixed: Add support for all the other tilesets The auto creating of the values when 'useSettings' is false needs to be done better, the equation used needs to give a result more appropriate for the map size. It is in the method 'autoEq()' The edges of the dune patches are mostly incorrectly put on, they need to be redone to be perfect The rock-to-sand edges are sometimes incorrectly put on, especially on the edge of the map when touching a cliff face, they need to be worked on. Example: Occasionally a cliff wall opening will have a detached end tile, this needs to be looked into and fixed. Example: Occasionally a cliff wall will not connect properly, this needs to be looked into and fixed. Example:

Will do!

Right now, the only way to prevent two areas from connecting to each other would be to increase 'spaceBetweenPoints' so they are more separated, or decrease either 'numberToAdd' or 'numberOfSpawnsToAdd' to make them smaller or fewer. I'll see which settings work best to keep them apart. And like you suggest, I will also look into making a system that would make each area different from each other, so they don't connect at all and stay separated. Yup, I just added this yesterday, 'numberOfEmptyBlooms' will be the start of a spice field that does not have any spice bloom. There was a bit of a problem with some parts of the map not getting any spice at all so setting this much higher than 'numberOfBlooms' will ensure there are spice fields everywhere. I do kind of have a list of things I will/need to do in my head, I'll write in down in the first post too.

Thank you! I highly appreciate you taking the time to write up your thoughts on it The 'divisor' variables are meant to help evenly distribute all the squares. Hopefully I can explain this well enough. So, the idea is that without this in place, all the squares will likely end up being placed very unevenly. This is because once an area starts to get big, it gets a higher chance of becoming even more bigger, compared to the smaller areas. When a rock square is being placed, the program looks for a rock tile that is next to a sand tile, so an edge point. The bigger an area is, the larger perimeter it has, further increasing it's chance to get bigger. So to counter this, the squares are placed in batches. The number of squares in a batch being found like this: (numberToAdd / numberAtATimeDivisor) = numberAtATime ex. (512 / 2) = 256 Here is a example showing how it works: The squares are being applied to the 'mainBoardTemp' array while the edges are being found in the 'mainBoard' array and the changes aren't being applied until the number of squares counted by 'counter' exceed the number of squares to be placed in a batch, which in the example above is 256. This effectively evens out the placement of the squares, making them more equally sized. But, I haven't had the time to properly test it with different numbers so I don't know just how effectively it can work. As for the 'squareTop/Bottom/Right/Left', these simply are the dimensions of each square. From the blue centre square, this example has a 'Top' of 2, a 'Right' of 2, and 'Bottom' of 0, and a 'Left' of 1. Keep in mind that the four of these values are randomly interchanged with one another, to keep things looking less blocky. The methods that are used to generate everything are entirely my ideas, I didn't read any outside material to get any ideas. I hadn't known this, and I didn't notice any abnormal effects during gameplay, but I will keep note of this, thanks. Yes, the official maps, even ones 128x128, only seem to have 3 or 4, I will definitely turn them down some. This is something I will need to do in the future, making sure there safeguards in effect that prevent this sort of thing. I have already done so in, for example, the method 'addInfantryClimbs'. It will try a certain number of times to do what it does, and will stop after a number of times. Another possible way to get around this is have all the variables chosen by the program based on how big the map will be. I can do this too, I just wanted the ini file handling part in working order right away. Yes, like I mentioned above, this is something I will do in the future. I just need to find an acceptable range for all the variables based on the size of the map, or like you suggest, just a range supplied by the user. Ah, I looked around in those folders but I did not notice those tileset ini files, I will definitely have a look at those, thanks. Doing it as it currently works, for all the tilesets would for sure take a vary long time, this would work a lot better, and work for custom tilesets even I think. To make all these changes would probably require rewriting almost everything, but I have no problem with doing that, and even somewhat planned to do so anyway. That would be easily implementable, if you would like to do that you very well may do so. I will add this as well.