Jump to content

Nyerguds

Global Moderator
  • Posts

    6190
  • Joined

  • Last visited

Everything posted by Nyerguds

  1. C&C1, RA1, Tiberian Sun and Dune 2000 all use exactly the same AUD format. I explained how to convert to it in the other thread. He meant file format
  2. So then, an Upgrade Complete sound clip was made, and used in the song, but it wasn't put in the EVA sounds
  3. Whoops. Fixed a little bug that caused it not to correct the file size in the header when converting back from 1x1 to normal dimensions. Note that the only way to get rid of a file's "1x1-multiple" status is such a dimensions import from another file, since simply giving a types mask won't fix its dimensions, and I can't be arsed to add dimension changing parameters for a case that probably won't ever be used anyway. After all, that's stuff the pcx2rtm converter can already produce.
  4. btw, I didn't actually make any parameter to simply fill an entire file with one terrain type, but generally, "-t! I -d I" (force if not enough cells, and set default fill value to the same thing) works pretty well (with both I's replaced with whatever terrain type you want). This is wrong, by the way. 1x1-multiple tileset files only have a single byte of terrain type info. The others you edited were simply part of the information before the terrain type. As I said, you can check where it starts in the header.
  5. I don't really get your point... if the tiles aren't 1x1-multiples, then there's not much of a problem with them, is there? Anyway... to help you all along.... here's the finished tool: http://nyerguds.arsaneus-design.com/cncstuff/rtmtype.zip Examples: Convert file to 1x1 with repeating cells: Import from file: (note: dimensions changing ONLY happens when importing from a file with the same amount of cells, into a 1x1-multiple that thus doesn't have real dimensions) Use of the '!' switch to force the tool to write the mask regardless of size: Use of the '!' switch with a file larger than the input, padded with a default value given as hexadecimal
  6. Right, well, now you should at least know what to adapt to make it work correctly. Though you're right about pcx2rtm adding a ton of extra stuff that doesn't seem to be needed... not a clue what that's for. Still, as long as it works, I'm staying off that.
  7. Wellll nevermind that, the header actually has a position of the offset of the start of the terrain types (the dword at 0x20). I can just ignore all the rest even when changing between 1x1 repeating and normal types [edit] Wait seriously? that won't help you once you're working with custom graphics that take more or less space than the original. My guess, it'll just fail because the file size in the header is incorrect (dword at 0x0C) after your fix of the footer info. Did you actually test that ingame before replacing its header? Because xcc fails far more easily than the game. Full header: 0x00 int16 tile_X (always 24) 0x02 int16 tile_Y (always 24) 0x04 int32 frames 0x08 int16 frames_x 0x0A int16 frames_y 0x0C int32 file_length 0x10 int32 offset_endofheader (always 0x28) 0x14 int32 unkn_00 (seems to always be 0x00000000) 0x18 int32 unkn_01 (Not a fricking clue what this is. May be a load of boolean options) 0x1C int32 offset_footer02 // points to some bytes between the start of the footer and the type frames 0x20 int32 offset_footer03 // offset of the start of the type frames 0x24 int32 offset_footer01 // offset of the start of the footer Mind you, if it really doesn't work ingame without copying the header, I'll probably have to copy the Mystery Values unkn_00 and unkn_01 when doing an import from file. I may take a look into the xcc code to see if Olaf has more info on them. Anyway... I just completed the system to read the types from another file. Now I just have to implement writing it to the given file
  8. yeeah, and then there's stuff like the file size in the header, and the odd cell counter at the end before the terrain type listings. My tool will hopefully be able to adjust all of that automatically. Do note I'm not sure whether the tool will be able to correctly support these odd 1x1 tiles as input for the file to modify. It'll work as 'souce to take tile info from' though, don't worry... but I still need to figure some things out related to the rest of the end bytes which also change for a 1x1...
  9. Right. I got working on a tool to fix this stuff. So far, only the parameter reading is done, but that at least means that part is already well-defined: Red Alert Template File Terrain Type Editing Tool Created by Nyerguds Basic syntax: RTMType file -[t|f|1][x][!] [arguments] -d[x] [defaultval] Parameters: Types reading: t: Give terrain type codes as arguments f: Read terrain types from file given as argument 1: Force tile to 1x1 with multiple entries. Terrain type arg is optional. Modifiers: x : (behind any terrain code reading param) Read byte values (0-F) as codes. ! : (behind t or f) Don't abort if amount in file and in types don't match. Default value: d: Specify default value to fill with when using '!' mode. (Can use as -dx) If not given, this defaults to Clear (3). Can't be used when using '-1'. Start with -l to list all terrain types and their codes. Start with -x to show explained examples. Terrain types listing: Code Byte Description X 0 Unused cell. [Clear] on 1x1 with multiple entries. C 3 [Clear] Normal clear terrain. B 6 [beach] Sandy beach. Can't be built on. I 8 [Rock] Impassable terrain. R 9 [Road] Units move faster on this terrain. W A [Water] Ships can travel over this. V B [River] Ships normally can't travel over this. H E [Rough] Rough terrain. Can't be built on. Examples: RTMType hill01.tem -t HIIIHIHHIIHC Set the terrain types in 'hill01.tem' to the specified type codes. RTMType hill01.tem -tx e888e8ee88e3 Set the terrain types in 'hill01.tem' to the specified type bytes. Exactly the same effect as above, but can hack in normally-unused types. RTMType hill01.tem -f! orig\hill01.tem -d I Set the terrain types in 'hill01.tem' to the ones set in 'orig\hill01.tem'. Continue even if the amount of cells doesn't match. If amount of cells in 'orig\hill01.tem' is less than in 'hill01.tem', pad with 'Impassable' type. RTMType arro0001.int -1 Set the given tile to act as 1x1 tile with different choices. The terrain type defaults to 0 since no type codes/bytes are given.
  10. Ohh, true! http://www.cncworld.org/wwr/games/pcidx.html Bam, in the official games listing. And it seems the title of the actual C&C1 page also uses it For those not familiar with that old WW mirror I built from archive.org material: Westwood Remembered
  11. Give it a CD? The patch only switches to NoCD mode if it detects a TFD or Origin install. The reason for this is that RA's mixfiles-inside-mixfile system makes it impossible to check if an installation on hard disk is actually capable of NoCD, and giving people the option to use a nocd exe while they don't have the files on disk will just cause loads more problems.
  12. Last I checked, it doesn't support NOT embedding them unless you link through youtu.be X_x
  13. Simply rename it from ".ini" to ".mpr".
  14. Well, it was literally the first custom track ever truly added to C&C95 (besides the Nod score and map themes and the Credits theme, but those don't count because they're made by Frank Klepacki, and don't show up in the tracks list anyway)
  15. The original readme included on the Covert Ops CD (v2.7 of the official C&C readme document) had these sections on Tiberian Sun and Red Alert, both mentioning the name: [pre] ---------------------------------------------------------------------------- 8.1 When will "Command & Conquer II: Tiberian Sun" be released? ---------------------------------------------------------------------------- "Coming Soon." We expect to release it late in the fourth quarter of 1996. As soon as details are available about the game, we will let everyone know through the Westwood Studios WEB site. Tiberian Sun is an entirely new game, not a data disk for C&C: Tiberian Dawn. ---------------------------------------------------------------------------- 8.2 What is COMMAND & CONQUER: RED ALERT? ---------------------------------------------------------------------------- RED ALERT is the next Command & Conquer game from Westwood Studios, and is expected to release in the 3rd quarter of 1996, (or sooner!). A FAQ for RED ALERT will be released later on that covers the details of this PREQUEL to COMMAND & CONQUER: TIBERIAN DAWN. [/pre] As far as I know, these are the only official mentions of the name, ever. Does that answer your question?
  16. That's just Tore's mirror of my version I think... exactly the same installer.
  17. This topic has been moved to The Tech Center. [iurl=http://cnc-comm.com/community/index.php?topic=2111.0]http://cnc-comm.com/community/index.php?topic=2111.0[/iurl]
  18. Did he actually implement the Placement stuff now?
  19. Funniest game intro ever
  20. Yeah, that's the game asking for a CD all right. Not sure why it messes up like that.
  21. And high resolution, and ability to play with 6 players online
  22. heehee, fireworks.
  23. Well, got this so far (thx to iran): Array at 005FEC94 in RA95.EXE matched to the terrain types array at 00604AE0: 00 = Clear, seems to be used for missing tiles in corners of tilesets, and for random-choosing 1x1 tilesets with multiple tiles in them, like CLEAR1 01 = Clear 02 = Clear 03 = Clear, the one normally used for clear terrain in the terrain files 04 = Clear 05 = Clear 06 = Beach 07 = Clear 08 = Rock 09 = Road 0A = Water 0B = River 0C = Clear 0D = Clear 0E = Rough 0F = Clear Oh, and people with Win7+ can invest in a sturdy DosBox boat to stay afloat
  24. Nyerguds

    Happy X-mas!

    Merry Christmas and all that, folks!
  25. Really? Woah. Didn't know that...
×
×
  • Create New...