Xcomutte

[stjones]

This is a new progam that is currently consuming all of my free time. XcomUtTE is a non-GUI, Java program, which will be called by XcuSetup. The code is based on my new Java version of SDUMP, which is also under development for use on multiple platforms at work. The purpose of XcomUtTE is to merge and compress existing XCOM and TFTD maps and terrains to form new combined terrains. I plan to deliver it as part of XcomUtil 9.6.

 

At the very least, I hope to be able to merge a subset of the Farm terrain with a subset of the Urban terrain to produce a new map/terrain set which replaces the barn and empty house of the Farm terrain with the house with the picket fence from the Urban terrain. Similarly, I hope to add pyramids from the Mars terrain to the Desert terrain, all without ever actually editing any maps.

 

It should nicely complement DaiShiva's Map Editor, providing high-level terrain manipulation, rather than low-level editing. I will provide more details as I make more progress.

[j'ordos]

Ah, this reminds me of something I wanted to ask (not really anything to do with this great new feature) : as far as I understand, you can use xcomutil.rnt / xcomutil.rnx to randomly swap certain map files with others, but each tile has a chance to either get (one of) the replacement(s), or the original file. It would be handy if you could set it so that it would replace the entire map set and it's terrain file (if necessary), this would be great for terrain mods like those Hobbes made.

[Hobbes]

Sounds great! If you find a way to be able to use 30x30 or 40x40 maps in the process, even better

[Serge]

That's an interesting idea. Some people have asked about using new fanmade ufo2000 terrains in the original x-com. I also had an idea of making export tool (written in lua scripting language) that can be used to reconstruct mcd and pck files so that the terrain can be loaded and used in x-com. The only problem was that I do not know what are the requirements for these generated mcd files to be correctly accepted by x-com and permanent shortage of free time.

 

Another tool that would be very useful is mcd editor. It is required if we want to create completely new terrain types but not only combine existing.

 

Surely I'm interested in having more terrains and maps that can be used in both x-com and ufo2000 and this XcomUtTE program can help in achieving this goal. Probably we can even cooperate to provide interoperability between XcomUtil and ufo2000 - some kind of common format for storing maps or convertor tools.

Edited July 13, 2004 by Serge

[Hobbes]

Another tool that would be very useful is mcd editor. It is required if we want to create completely new terrain types but not only combine existing.

 

There's an MCD Editor made by Koralt. I don't remember where I got it but if you want it I can send it to you.

[stjones]

Sounds great! If you find a way to be able to use 30x30 or 40x40 maps in the process, even better

 

Actually, XcomUtil can probably already do this. I added support similar to BladeFireLight's BattleField Generator back in 1999, when I added support for Hybrid games. The Tiles section of XcomUtil.cfg tells XcomUtil how to generate the maps. Using "xcomutil ufoexe map:cfg wrt", which I appear to have forgotten to document, you can update the terrains used. You can use terrain prompting, which you select in XcuSetup, to force XcomUtil to generate the maps before each combat. As soon as XcomUtTE is finished, I'll add a new interface to do this more easily.

 

XcomUtTE is progressing well. This morning I was able to successfully combine the cultivat and barn terrains into a single MCD, PCK, and TAB. Next, I will add code to remap all of the pointers in the MAP and MCD files, then eliminate all of the unused entries. Once that is finished, I can merge two different reduced terrains to form a new one.

[Hobbes]

Actually, XcomUtil can probably already do this.  I added support similar to BladeFireLight's BattleField Generator back in 1999, when I added support for Hybrid games.  The Tiles section of XcomUtil.cfg tells XcomUtil how to generate the maps.  Using "xcomutil ufoexe map:cfg wrt", which I appear to have forgotten to document, you can update the terrains used.  You can use terrain prompting, which you select in XcuSetup, to force XcomUtil to generate the maps before each combat.  As soon as XcomUtTE is finished, I'll add a new interface to do this more easily.

 

I've just taken a look at XcomUtil.cfg and I think I understand most of the data disposition. Each line corresponds to a terrain and the hexadecimal columns correspond to the terrainXX.maps, indicating their size (1x1, 2x2). In the case of the Port and Island there's an additional number indicating their specific position.

In the case of the Hangars on XBase it seems that the 122 tells the computer to compose a 2x2 map, using the 4 maps, since each individual map is only 1x1.

One thing I don't understand is why the last entry on the XBase and Ubase lines end with a 011, since there isn't a existing corresponding map, but I suspect that's used to fill the 1st and 4th levels with earth tiles.

One thing that I don't understand is the purpose of the first column, named fdf. What do the values represent for each terrain? The number of used tiles? The location for the X-COM craft to land?

Will the "xcomutil ufoexe map:cfg wrt" command detect new maps (30x30, for instance)? Or do I need to change the XcomUtil.cfg file manually?

[stjones]

Will the "xcomutil ufoexe map:cfg wrt" command detect new maps (30x30, for instance)? Or do I need to change the XcomUtil.cfg file manually?

 

I think my comment about map:cfg just confused the issue. The map:cfg option works almost exactly like the shp:cfg option. It simply updates the list of terrain files used with each kind of map. For example, I will be using it to replace "cultivat" and "barn" with my new combined "farm" terrain.

 

I think the "Map Tiles in XCOMUTIL.CFG" section of XcomUtil.txt will answer rest of your questions about the Tiles section.

[Hobbes]

I think my comment about map:cfg just confused the issue.  The map:cfg option works almost exactly like the shp:cfg option.  It simply updates the list of terrain files used with each kind of map.  For example, I will be using it to replace "cultivat" and "barn" with my new combined "farm" terrain.

 

I think the "Map Tiles in XCOMUTIL.CFG" section of XcomUtil.txt will answer rest of your questions about the Tiles section.

 

Just had a look at the manual. I'm curious about the fdf flags and the logic between some of the numbers there, although I understood the 1xxx and so on flags. However, it doesn't seem that I'll need to learn about them for now. I'm going to try later to add a couple of 40x40 and 30x30 maps to the unused Urban slots and see how it goes.

 

Edit: IT WORKS! it works! it works! it works!

 

I've just used a 30x30 building in xcomutil.cfg and it seems to work with no problems! This is amazing! And I like using the Prompt....I can design several 40x40 buildings for the same terrain but only one of them will be randomly picked for the game! Thank you very much Scott....you rule!

Edited July 15, 2004 by Hobbes

[stjones]

Edit: IT WORKS! it works! it works! it works! 

 

I almost missed your cry of joy. Edit doesn't change the date of your original post, so it was lucky that I re-read your post. I'm glad someone is finally using that feature.

 

Coding is basically complete on XcomUtTE, so now the testing begins. Compression of the files seems to work, but I seem to be having a little trouble compensating for the "blanks" terrain that always comes first. There may also be a couple of minor fixup bugs that will require me to discover more about the contents of the MCD files.

 

I probably won't be able to work on it tonight, since I have about 20 inventions to review before the meeting of the Invention Evaluation Board at work tomorrow morning. Last month, I was placed on the board. which decides whether our company should file patents on inventions designed by employees. It is very enjoyable work, but I have to completely forget about Xcom for a while to fairly evaluate the ideas.

 

Sunday morning, my wife goes out of town for 5 nights, so I should have plenty of time to finish XcomUtil 9.6 before she returns.

[Hobbes]

This is sweet!

 

I've been dreaming about being able to use really big maps on UFO for a long time. It opens a lot of possibilities for map designing because it doubles/triples/quadruples the map area that I've been working with. I'm already working on 5 40x40 maps to fill the empty slots on Urban. adding them to my Area51 mod. I've attached a pic of the first one, the HWP Factory.

Good luck with Xcomutte, I'm curious to see what will come this time

Edited July 15, 2004 by Hobbes

[stjones]

This is sweet!

 

I've been dreaming about being able to use really big maps on UFO for a long time. It opens a lot of possibilities for map designing because it doubles/triples/quadruples the map area that I've been working with. I'm already working on 5 40x40 maps to fill the empty slots on Urban. adding them to my Area51 mod. I've attached a pic of the first one, the HWP Factory.

Good luck with Xcomutte, I'm curious to see what will come this time

 

XcomUtTE is DONE!!!! I have just fought a battle on my new Farm terrain. The best part is that it required NO CHANGES to XcomUtil. It even works without XcomUtil even installed! I just have to document it and package it up to release as a beta. I'll save that for the weekend. Good night.

[[stewart]]

 

Being married as well, I'm quite aware of how much the march of civilisation has had to depend on the wife leaving town. :wink:

 

BTW how goes the tech tree editing capabilities of XcomUtil; I recall that a long time ago we chatted briefly about some of the difficulties involved.

[stjones]

BTW how goes the tech tree editing capabilities of XcomUtil; I recall that a long time ago we chatted briefly about some of the difficulties involved.

 

I believe I know how to implement it, but I am not interested in redesigning the actual tree. Without a new research tree to support, I have no motivation to do all the work to just manage the existing tree in a new way. XcomUtTE is a good example of the kinds of things I find myself motivated to do.

 

I would love to have new terrains like Hobbes is developing, but I don't want to design the terrains. I once designed a few new versions of the medium scout using Marco Kaiser's old editor, but after I was done, they didn't interest me. I knew them too well. I would rather spend time on things that can still surprise me, like my random UFOs. Similarly, XcomUtTE allows me to mix terrains to create interesting new combination without the in depth study that has the potential to make it uninteresting. My next project might be an enhanced version of my random UFO algorithm that can be used to randomly design outdoor terrain.

 

I would be glad to work with someone to develop the mechanism for a new research tree. I just haven't been willing to do it by myself. Any volunteers?

[[stewart]]

Couldn't the tree be left as the default (the one provided by the game itself) and the redesign be up to the user using XcomUtil (or whatever) to do it. Or am I missing something here?

[SupSuper]

wouldn't a bug-fixed tech tree be enough? or does xcomutil already fix it?

[stjones]

wouldn't a bug-fixed tech tree be enough? or does xcomutil already fix it?

 

Fixing the tech tree is not really possible. Instead, the whole research mechanism must be replaced, because many events occur in code instead of tables. Since XcomUtil only gets control between geoscape and tactical, and again between tactical and geoscape, there are only certain things that can be done. Research updates can only be made around combat.

 

I can force this to happen by making all research impossibly expensive, then managing things within my own data files. Considering the awkwardness of this approach, I think we need a completely new research tree to make it worth the pain. Personally, I would like one that is random, or at least randomly selected from a collection of possible trees, so you don't know what to research first.

[Hobbes]

Out of curiosity....what is possible to change? I know there's a fixed number of entries but could the unused ones, like Alien Reproduction and Alien Habitat made available?

Would it be also possible to change the order/requirements for each entry? Something like you'd need to capture and research E-115 before you could start researching plasma weapons. Or require Alien Surgery before you can start Laser Weapons.

[stjones]

Out of curiosity....what is possible to change? I know there's a fixed number of entries but could the unused ones, like Alien Reproduction and Alien Habitat made available?

Would it be also possible to change the order/requirements for each entry? Something like you'd need to capture and research E-115 before you could start researching plasma weapons. Or require Alien Surgery before you can start Laser Weapons.

 

All of that would be possible. If you don't mind my requiring Java, I could even implement it with a GUI.

[Hobbes]

Well, I don't know anything about Java other than it's a computer language or what is a GUI interface (although I probably use it not knowing).

I'd like to be able to keep running XComUtil with the DOS version (I dislike CE's sounds) but, oh well, you can't halt the march of progress

 

In any case, I don't have time right now but I'll give the research tree a look in the future.

[stjones]

Well, I don't know anything about Java other than it's a computer language or what is a GUI interface (although I probably use it not knowing).

I'd like to be able to keep running XComUtil with the DOS version (I dislike CE's sounds) but, oh well, you can't halt the march of progress

 

In any case, I don't have time right now but I'll give the research tree a look in the future.

 

I am NOT abandoning the DOS version. I also prefer the sounds on the DOS version. Java and DOS are not mutually exclusive. There is supposed to be at least one JVM (Java Virtual Machine), the Java interpreter, that runs on DOS. JVMs for most modern platforms are available for FREE from java.sun.com.

 

By platforms, I mean Hardware/OS combinations. At work, I typically use four different platforms every day: Pentium-III/Win2K, Pentium-III/United Linux, 32-bit PowerPC/AIX, 64-bit PowerPC/United Linux. C programs compiled for one of these platforms usually won't run on any of the others. However, a Java program written on any of them will also run on any of the others.

 

Many people are running XCOM on Windows, or even other platforms, using DOS emulators. Since XcomUtTE runs only at XcuSetup time, you should still be able to run using your DOS emulator and get the benefits of the new terrain. You can even run XcuSetup on a Windows machine, then copy the results of XcuSetup to your machine running real DOS.

 

If I start using Java at runtime, especially if I use it to write a GUI (Graphical User Interface) for XcomUtil, then DOS will be less of an option. However, I won't be taking anything away from the DOS users, I'll just be giving more to the users on other platforms.

 

Please don't give up on XcomUtil just because I want to write programs using the same language at home and at work. I should create a poll to see what portion of the XCOM users have Java installed or even know what it is.

[Hobbes]

Please don't give up on XcomUtil just because I want to write programs using the same language at home and at work. I should create a poll to see what portion of the XCOM users have Java installed or even know what it is.

 

Never!

 

I ran the DOS version on Win98 and I'll install Java if it's necessary. Right now I need to be very conservative ("do I really need it?") upon putting new software on my unstable laptop but I'll always open exceptions for XCOM/XComUtil.