Nyerguds

Just a quick note on that... the C&C95 CD installer is a 16-bit windows program. The DOS installer is 32-bit though. Yes, it's silly.

As the screenshot says, they're Ghosts And yes, that's correct. The readme file has a full credits list of all graphics, btw.

Well, it's a first step anyway. There's still other problems, like the fact all preplaced units going to Hunt right away, but yes, it might be worth experimenting with multiplayer scripting now

1.06c revision 2 will finally support the "Players=" tag under [basic], meaning you can finally limit the number of players in a map More info in the 1.06 dev forum, here: http://forums.cncnz.com/index.php?s=&showtopic=13910&view=findpost&p=193571 In related news, only waypoints below 12 (so 0-11) are used as start locations now, meaning the higher ones can potentially be used for multiplayer scripting

It was just a "our teachers are stupid" thing, trust me

Um, a Dutch-language university, duh. I live in Belgium. IIRC they specifically asked to make the code Dutch... most informatics teachers here are unfortunately people whose only knowledge of English comes from the programming. Their English pronunciation is usually pretty atrocious, too

Mine does that... simply by first reading the default language's settings, and then using these values as defaults for reading the actual one. I'm also working on an ini-based strings system to do both partial and complete replacements of the strings files. I don't really get the storage system associated with your languages code though... but it reminds me of InnoSetup, where you can set custom strings for any number of supported languages, like this: (taken from the C&C95 v1.06 patch installer) eng.langchoice=Set the game language: ger.langchoice=Wählen Sie die Sprache für das Spiel: fre.langchoice=Configurez la langue du jeu: eng.reschoice=Screen Resolution: ger.reschoice=Bildschirmauflösung: fre.reschoice=Résolution graphique: Though I'm not sure how you'd implement that for the entire game... it uses numerical IDs, not strings.

I think he was joking anyway

As for your data stuff: -In the language system I built into C&C95 I don't have an internal list of languages. I parse the 3-character language string from the ini straight into the strings "lang_???.mix" and "lang_???.ini" to read a bunch of file REPLACEMENTS. Meaning that if you start in french, the English version of the strings file, sidebar buttons and game icons are simply not read at all. There is no list, and no language detection logic in the game. Have you looked into the indexing system used in the conquer.eng file? It's pretty straightforward. I think it was four lines of assembler to get the string position if you got the start of the file and the string index. -I haven't really looked into mix headers, except briefly into the TS ones, and that was only to fix them if they were broken as "mix protection". -mouse cursors: Not a clue, really. I've never really looked into that. I kinda expect that to all be hardcoded in the cursor code, setting the click point at the moment it loads the cursor. [edit] I mess up big and little endian too, but it's actually pretty simple... look at the number "123". The "1" at the front is "100", so it's the largest number. The "3" at the end is the smallest number. So the end (since we read from left to right) is the smallest (least significant) number, which makes it little-endian. C&C uses big-endian, where a hexadecimal number 12345678 becomes bytes 78 56 34 12

C&C isn't 16 bit. Has never been 16 bit either. But most programs written for it back in those days were.

Well, basically, in assembler -byte = 1 byte -word = 2 bytes -dword ('double word') = 4 bytes. As for longint, I think the name comes from the specific 32-bit "longer" int at the moment the standard for int (on 16-bit architecture) was still 16 bit. Just googled it. "LongInt is a Borland Pascal extension. Borland Pascal defines LongInt as a 32-bit signed integer type." However, some more recent compilers like GNU Pascal or Freepascal may use it as 64-bit integer. It's basically a problem with evolution... on 16-bit architectures the standard "int" is 2 bytes, on 32-bit it became 4 bytes, and on 64-bit it'll become 8 bytes. It's simply a matter of how much the standard CPU registers hold. I'm just glad they finally got actual bit-specified types (Int16, Int32, Int64) in modern programming languages. In old references, the Borland standard holds though, and you can safely assume longint simply means 32-bit.

Well, my thesis/internship project for university college was a C# desktop app that automatically scanned content from Word documents and uploaded it to an online platform. More specifically, it is a tool for teachers to automate the creation of assessments on the school's online platform. Besides that, I've also completely rewritten CCSetup in C#, and this rewrite includes my very own ini file reading and writing system. I've recently ported that code to Java too. There's quite some pics of the new ccsetup on the ModDB site of the 1.06 patch. I've also made a radar colour editor for TS/RA2 SHP files, and, just for fun, a program to unlock protected mixfiles (but I never released or even announced I made such a thing ) At this moment though, I'm working to make a Java program to be the successor of my internship project (they hired me ), and at the moment that's mostly made up of GUI and database (SQLite) operations. I've also been working again on a java game which was originally made as big project in my first year at the university college. I made a thread about it here. The topic on cncnz I linked to also has a link to the source of that game, though it's mostly in Dutch [edit] Oh, I also wrote a Dune II game data editor in Pascal. With a text UI

Godly: Is there anything to recreate? It's a big open field with trees...

You keep amazing us... these maps are great

Nope, not a clue what SpriteBatch is, and seeing as the only occurence of the word there is a VARIABLE and not a class, I had no way of knowing there was even a class called that. And no, I've never worked with XNA (or, anything else than backend and forms, for that matter) on C#. As for WWLib, um, I dunno, where would you get it? As far as I know it's built into the games, and never as external library. Though if you got it as dll (I heard somewhere that a lot of it is in some leaked Renegade code, so it's possible to make a dll from that), I don't see why not. I think it's possible to combine different programming languages in the same project anyway.

I really don't get what this code is or does without any references. What exactly is this used for? What type is that "spritebatch"? Is that Draw() function your own function or something of an existing object type? Also, I don't really know what a Vector2 is. I never used vectors, except in assembler... don't even know what the difference with a normal (Array)List would be, or the difference between Vector and Vector2. If it just needs an IEnumerable, a normal array should suffice. btw, I think there's an error in that "new Vector2(X, Y)]". I can't imagine any syntax with just a closing bracket oh, and as for "stuff not feasible via pure x86 ASM", actually, adding a rules.ini is perfectly feasible

umm... the only thing I know about the accuracy is that the randomization algorithms for them are pseudo-randoms that work in such a way that they're the same on all players in a multiplayer game without needing to send any information about them. Which is kinda scary As for the vector thing, do you mean for storing unit frames? As far as I know, the game doesn't store them. It just reads the correct frame from preloaded files at the moment it needs it. So basically the equivalent of unit.getSHPFile().readFrame(12);

Oh wow... this map is really beautiful. It also looks pretty balanced, and there's plenty of resources. Please re-save the image as png though... this bmp takes 6 mb :|

You must be thinking of Hyper. He's a graphics designer in real life. Heh. If you're talking about the unit lists and such, the answer to that is actually very simple. They're NOT indexed at all. The game simply reads all keys. So the only requirement there is having a unique key. You could even put both "1" and "001" in there, and it'll still read them both. I kinda just answered that... the rest isn't indexed at all. Except for the [base] section. Though I do believe the [base] section is indeed 0-indexed. Fun fact... the original game actually still contains some leftovers of an inbuilt map editor mode Accuracy? To do what, exactly? As far as I know, most stuff in C&C can simply be kept in one global list in the Map object. Sure. I'll send a PM. Do note that the exe that goes with it is the 1.06c revision 2 one, which will probably not run on the currently released version. I could always give you a full beta though. Well, chips may have gotten faster, but the CPU still executes exactly the same commands as the first 8086 computer lol, no problems there. It's what everybody calls me I know the projectiles (Bullet class) contain a flag to make them inaccurate, but that's all I know. And it's just a boolean, not an inaccuracy value.

He hangs around on the IRC chat (freenode.net#cncnet) and on cncnz. I don't quite understand this. Could you explain this in a bit more depth? Right. Map cells in the .bin file are byte pairs that quite simply say [tileset ID, cell from the set]. However, for clear terrain this isn't needed; there's a special code ([FF,00] I think) that can be used for all clear terrain, and the game will automatically tile the entire 4x5 clear terrain block over it (rather than repeating one cell, as you'd expect from repeating the same byte pair). XCC Editor ignores this special 'clear' value though, and actually paves the map with the real tile codes of the clear terrain, cell by cell. Now, the reason I made the tool. The old cc-scen editor I still use from time to time doesn't show map graphics, but just colours each cell according to its terrain type. The problem is that it expects clear terrain to be the special code, and only diplays those as 'green', whereas the actual clear tileset's tiles are shown as white, just like it shows roads, ruins, dirt patches and rivers. This obviously means that maps saved with XCC are displayed completely white (besides the rocks), making it impossible to discern the details of the map. This is the editor. Even with roads and rivers in the same colour, it's still quite easy to see the layout. Now imagine that but with all the green turned white So the only thing my tool does is go over all the bytes and replace the actual cells of the Clear terrain by the general code for "nothing". Now you might wonder why I still use this... the answer is simple: it's the only editor available that allows single cell manipulation, and actually shows the bytes for each cell. (in fact, I think this editor was my first encounter with hexadecimal numbers, ever) Extracting files from a ROM is a huge mess though, involving memory state (emulator 'quick save') dumps. As you can see in this folder, there's 2 images showing the map and the height map (roughly converted to ascii) http://nyerguds.arsaneus-design.com/N64Project/editing/ The names of these 2 images are the actual filenames inside the ROM: SCB21EA.IMG for the height map, and SCB21EA.MAP for the map file. I think they used .map for the maps to avoid confusion, because their normal extension, .bin, was already used for the music files. Do note that you can't just extract all height maps and expect them to work anyway; some of the maps were edited for the N64 version of the game, usually to make them easier, to compensate for the harder controls. (I know of 1 so far, but never looked deeper into it, so there could be more.) Also note that the height maps work differently than the normal maps; the heights are put on the corners of the cells, meaning a height map is 65x65. I program Java and C# for a living, so yes, I'm all too aware of the systems of OO programming. ASM is really just a hobby

Well, that's not too hard to see from its table of functions, but I'm not all that familiar with the class names; Hyper knows a lot more about that.

Well, I just want the AI to act like a smart player would act. This was a really obvious failure. The original (1.11) already did this anyway, but it did it in a way that messed up the "is the enemy visible?" check, since an enemy was already deemed 'visible' if the attacker could see that diagonal cell, rather than when seeing the actual enemy So yeah, this was really just a final fix on the rewritten algorithm

Game updated, and rar pack uploaded. If you got savegames, make sure you don't overwrite the "data/gevechtsspel.db" file when updating. 1. The mouse-over information on enemies will now show whether they're visible or not. 2. AI update: Enemies that come towards you will take one less step if they can attack diagonally. Original behaviour: New improved behaviour: (this gives the enemy one more action point to attack you with)

So, um, exactly what are you trying to do? Make a C&C clone, or a C&C map editor?

Well, it's not exactly like it... just sort of based on it. Just now, I added an extra info label when you mouse over an enemy that shows if your hero can actually see the enemy. This is especially handy since it also tells you whether the enemy can see you I'm still planning some other minor adjustments, like an indicator in the shop showing which spells you already bought, and a general "armoury" / "spellbook" feature to show the weapons and spells you got without needing to attack enemies with it just to get the list.