-
Posts
6190 -
Joined
-
Last visited
Everything posted by Nyerguds
-
It's clearly stored as dword in the struct though. There's no need to treat it as anything else when it's clearly retrieved as dword, and the data in the structs clearly shows that it's indeed just the range accurate to two figures after the hexadecimal point, and, to store that as pure int, simply multiplied by 100h. The only thing that really matters in a struct is how data is stored and retrieved. What exactly that data is irrelevant; only the grouping really counts. Well, unless they're bit flags or something, in which case you could define them as boolean bits in a theoretical struct (though not in a real implementation), but that's not the case here at all. Well, anyway, I'm not going to argue with you about what appears to be a "style choice"
-
Question remains... why? Why are you making humongous sidebar graphics if iran's sidebar uses a smaller repeating SHP to pave it? [edit] Mmkay, so, cleared up in the IRC. He didn't know about the repeating gfx :-\
-
I'm... not exactly sure where this fits in with the range calling code, since I can't trace the "call dword ptr [ebx+168h]" stuff without debugging.... but that seems to be related to the fact that the stored value is the range x100h They probably need to shift it down at some point to do by-cell range calculations, or something.
-
Ohh. Right. I misunderstood. So that's the place to sniff around to see why single player nukes don't repeat, then... and what makes the difference with one-shot superweapons from crates in multiplayer Awesome.
-
Uhh, I don't think they use any bit shifting for that value... the function at 0x004B1F78 is the weapons range getter. With the struct properly configured, it gives this code: 004B1FA5 mov eax, array_weapons.Range_x100h[ebx+eax*8] 004B1FC0 mov eax, array_weapons.Range_x100h[ebx+eax*8] (with the *8 being there because that's the length of the struct)
-
C&C95 player production/building stuff
Nyerguds replied to peterthepigeon's topic in The Tech Center
Ah, all right. Just testing the limits of the system, then. I've seen the AI madly produce hundreds of units in my experiments when adding new units to the game (see also, the "Tiberian Sun 100 units bug"). Then again, without that specific bug, I guess they'll stick to the teamtype amounts set in the mission ini files, and the actual build speed wouldn't be that noticeable, with other factors like the AI money possibly holding them back anyway. -
ANYTHING that "Westwood didn't implement" is technically difficult to apply. The very statement that "Westwood didn't implement it" sufficiently implies that, since it means there isn't a byte of code for it already present inside the game
-
I can't, actually. I can give you a 640x480 forcing command line parameter, but if they got any cnc-ddraw settings enabled, the result might be royally screwed up.
-
...wow. They recycled that for the reveal trigger just because it's also a radius around a point? That is so fricking dumb.
-
Jacko, this is the C&C1 forum. C&C1 didn't have a rules.ini before I added one, and the one I added doesn't contain any unit stats. Pwn Call: this might help you out, though it helps to know how the weapons/warheads/armour system links together. http://nyerguds.arsaneus-design.com/cnc95upd/inirules/
-
Uhh, iran's repeating sidebar system uses repeating graphics. It doesn't need humongously big sidebar graphics.
-
Rule #1 Of Playing Old Games: DON'T COMPLAIN ABOUT FEATURES THAT WERE ADDED IN ITS SUCCESSORS. Nyerguds, over and out.
-
Paint is horrible for this kind of stuff, since it can't preserve colour palettes. You really need palette support for these things.
-
Umm... I have no idea what you mean by any of that, really. Need moar infoes.
-
Player vs Computer harvesting in Tiberian Dawn
Nyerguds replied to peterthepigeon's topic in The Tech Center
...the hell? Really? Woah. That's awful Thanks for this information, it's really really useful -
The struct for weapons is not exactly correct. Those m_bUnknown/m_bRange/m_bUnknown2/m_bUnknown3 bytes are actually simply one dword containing one value, which is the weapon range * 100h. Note that the Bullet types (projectiles) aren't really identifiable by those names, since those are just the ptrs to the filename strings of the SHP graphics they use. They can't really be uniquely identified by anything except ID, unless they're given new names. I've got a list of those, with better names, in my bullets.ini, by the way.
-
C&C95 player production/building stuff
Nyerguds replied to peterthepigeon's topic in The Tech Center
so... why exactly are you posting interesting disassembly information here, and then immediately perverting it to a cheat? Also... is that player only, or would it also affect the AI? -
Umm, doesn't the game kinda, y'know... do that automatically anyway? The block at 0041848E will give you the ion cannon data. You'll see the warhead value 5 (special warhead reserved for the ion cannon) and damage 600 (0x258). The stuff for the nuke is at 00418013 Hmm, I never really looked at this before. It seems the nuke damage is 0x3E8 (1000), but I didn't know its warhead was 4... that's "SUPER" (100% vs everything). Really odd. The multiplayer behaviour seems to give the nuke a damage of only 200 (and not 300 as previously thought), and the Fire warhead. Interesting. By the way, this is in no way a "superweapons" function in the exe. It's a function that makes animations play in a way that does damage. Any situation in which the ion cannon or nuke animation is played will automatically make it do the associated damage. There are some more animations defined in there, like the grenadier death explosion and the fire bursts when flamethrowers and flame tanks die. All of those do damage independent from any real weapon systems. And it's all done in code, without any general objects system X_x ...I'm tempted to build one now, though.
-
I'll probably just update it; the PS/Saturn/soundtrack version sound better.
-
You can't go below Windows 640x400. The game can't handle it. Anyway, there's no resolution forcing in TS either. Never bothered many people afaik.
-
Actually, that one kinda grew from removing the Funpark mode. To remove Funpark, I had to create a bunch of extra systems to allow me to add the minicampaign to the New Missions list. Because, well, I wanted to get rid of the horribly buggy special game mode, but not at the cost of actually losing the awesome dinosaurs minicampaign. Those systems were: -The minicampaign system itself, that allows one entry in the New Missions list to be a campaign up to 15 missions (using the EA-EB-EC-ED etc. alternate choices as next missions) -The custom colour changing system, to allow both the GDI and Nod version of the Funpark campaign to have silver colour ingame, despite technically simply being GDI and Nod -the custom radar logo, to give the player the JP logo -a logic for skipping the score screen The extra colours were nothing more than a very small addition to the added custom colour changing system. I didn't even manage to make them usable in multiplayer...
-
Thank you! It is indeed because of the way none of the unofficial patches for these games ever managed to become the de facto standard that I chose never to change the game balance. Did I specifically say that you have to balance things out? Wait, you honestly think the "hard work" I mentioned was the balancing? A new game option seems like something simple to you, but in reality, UI changes like adding a new button are nigh-impossible to do on assembler level. Seeing as I don't have a single clue where to even start looking for these thing (including what it is that actually makes the SP nuke one shot only, or where the nuke damage for multiplayer is stored), it could be months of research before I can even start any experiments. -I have no idea how/where superweapon timing is handled. Or any other build time stuff, for that matter -I don't know how superweapons are linked to buildings. I just know it probably uses the same system as prerequisites, because it has the same overflow bug with high building IDs being seen as the same building as certain lower ones. However, since the logic used for prerequisites is so incredibly simple (and because of that, flawed) there's no way the two systems would actually use any common functions. -I don't know what controls the amount of planes for the airstrike logic, and from previous experiences with the "Unrevealed Terrain" mouse tooltip and some other things like that, it's very possible that the MP airstrike uses the exact same logic as the SP one, meaning you get more airplanes on maps that happen to have higher map numbers. ANY of these things might take months of research to crack. Let me just add another one to that... -I have a day job. Any work I do on the patch, I do in my free time, and I don't have all that much of it.
-
Huh, didn't know Reaperrr was active on the OpenRA forums :O
-
You just asked me "Hey, what if you do all the hard work first, and then we'll see if it'll actually be useful for anything?" Guess what. Nope. Map file thing? Oh, I thought some people were proposing making that special superweapons behaviour setting you mentioned into a map-specific ini option. Like the PassiveHelis option, it'd then need to be added to maps, and would only activate in the maps that have the option. Small note on this... both of these are features implemented by Westwood. All I did was exposing them. I didn't put weeks of work into them, like I would need to do to accomplish the thing you're asking me now. My general philosophy for my patch is to fix bugs, reactivate lost features and assets, and expand modding and mission making capabilities, all without changing the way the game is played. Undeploying construction yards is a reactivated beta feature, and one that I never even exposed in multiplay; the CnCNet people did that. Adding airstrikes to multiplayer is changing the way the game is played. Hence, I won't do it. end of story.
-
Gimme a break, I was at work when I wrote that. I couldn't exactly compare them there Anyway, I just compared them, and you're right, the clip in the ingame .var version is different from the one in the soundtrack/PS/Saturn version. Beside that, I noticed that in the Saturn version, the voice clips are less loud than in the soundtrack version, most probably to let them blend into the music better. So I guess that if I update the track, I'd better use the Saturn version. Are there other tracks with noticeable differences like that?