Posted: Tue Mar 19, 2013 7:34 pm Post subject:
InvisibleInGame and Invisible
Have you experienced problems with these keys? I keep hearing bad things about them, like crashes and other serious problems being caused by them. Personally I've never used Invisible, but I've been using InvisibleInGame for like 3 years (on structures that the AI builds) and I haven't noticed it causing any problems. My mod has frozen some times, but these problems have most often been linked to other things (such as unfinished AI). What kind of problems should these keys specifically cause? Instant problems? Or something that appears only after a long while? Random or consistent? Are they both equally bad, do they cause the same problems? If you've had problems with the keys, did you confirm the problem really was due to these keys (like checking the except.txt?).
On similar note I think I heard bad things about the RandomLoopDelay key in art.ini. Can this key cause problems, and what kind of problems? I have a few animations that use this key. Even the original TS uses it for the refinery fireball anim. Also, are there any other keys that should be avoided? _________________ QUICK_EDIT
I'll do some tests with the invisible keys again. Not sure when i've time though. But in the past, modder experienced independent from each other similar things with them, so there must be something true about these keys causing issues.
Concerning RandomLoopDelay:
-definitely causes reconn errors in online gaming when used on Overlay CellAnims (IIRC was the same true for RandomRate on CellAnims) The reason why for a long time CellAnim was said to be not working fine, which in fact does work.
-definitely causes sync losses in online gaming when used on animations that cause damage or are followed by an (spawned) anim that causes damage (e.g. TI used it once to spawn randomly dirt devils which can harm units. This caused sync losses)
-on normal animations like the refinery fireball, this might not be a problem if used. Though refineries are quite rare compared to the constant TI dirt devils. Since the dirt devils didn't cause instantly but only after a random duration a sync loss, this might explain the rare sync losses even in vanilla TS.
I don't remember why it is done like this exactly, but the random loop delay feature uses the non-shared randomizer to generate the new loop delay. This should be the reason for REs. Usually, the synchonized randomizer is used for something like this, and it is shared among all players.
Edit: It might be enough to change some bytes at offset 0x15AE2:
"B9 40 BE 74 00" (global randomizer) to "B9 50 26 7E 00" (shared randomizer). Of course, everybody would have to use the same change, otherwise it would still desync. _________________ QUICK_EDIT
I don't remember why it is done like this exactly, but the random loop delay feature uses the non-shared randomizer to generate the new loop delay. This should be the reason for REs. Usually, the synchonized randomizer is used for something like this, and it is shared among all players.
Edit: It might be enough to change some bytes at offset 0x15AE2:
"B9 40 BE 74 00" (global randomizer) to "B9 50 26 7E 00" (shared randomizer). Of course, everybody would have to use the same change, otherwise it would still desync.
AlexB to the rescue once again Do you have any knowledge about the InvisibleInGame and Invisible keys supposedly causing problems? Maybe we need enough people test using them, and try to cause a crash. Then look at the except.txt's and see where the problem is. If I get another random freeze in my mod I'll post the except here. Though they happen quite rarely, and usually when I run the game at game speed 6. _________________ QUICK_EDIT
Nope, I don't know which one (or whether any of them) causes desyncs, and I heard about sync problems with fastest game speed. _________________ QUICK_EDIT
Tested the RandomLoopDelay hack in a skirmish with 7 AIs. When I quit the match and tried to close the game, I got this IE. Also the animations with RandomLoopDelay seemed to play much more often than before the hack.
If it isn't crashing right away it means the hack works to some degree. Are you sure this crash is related to this hack? Singleplayer games would not be affected by the RandomLoopDelay desync. _________________ QUICK_EDIT
InvisibleInGame should not be used for any player stuff what I recall, if any of them opens fire by means of any weapon or do damage, it will recon online but Haven't done same test in TS tho...
Alex: What would be the randomloop hack offset in YR and values? Granted its only used for ore twink but yeah... Also might be good thing for ARES add if same case. QUICK_EDIT
Im not at my computer (hard are these days), but by shared i'm guessing you mean the Scenario Seed? Otherwise i dont remember FreeRandom and so being shared... QUICK_EDIT
If it isn't crashing right away it means the hack works to some degree. Are you sure this crash is related to this hack? Singleplayer games would not be affected by the RandomLoopDelay desync.
Did another test with the hack enabled, and again it crashed after I quit the match. As soon as I tried to move back to the main menu from the skirmish menu, the IE popped up. And the hack does remove the randomness from the RandomLoopDelay. There simply is no delay, the fireball anim on refineries plays nonstop. Here's the new IE attached.
EDIT: Without the hack I don't seem to be getting the IE.
ApolloTD wrote:
InvisibleInGame should not be used for any player stuff what I recall, if any of them opens fire by means of any weapon or do damage, it will recon online but Haven't done same test in TS tho...
None of the structures I use InsivibleInGame for have weapons or any other way of doing anything. They just either work as prerequisite for the AI, or give it a unit with FreeUnit. They are all Immune and Insignificant.
I also confirm an IE happening after applying the hack (although you have to wait long enough before quitting back to the main menu or it doesn't happen).
Are you sure your patching the bytes in the correct location? That crash is inside MapPreview::Get_Map_Data()...
Make sure you are actually going to 0x15AE2 (hexdecimal, not decimal) and check for the original byte sequence "B9 40 BE 74 00".
Yes I am 100% certain I changed the right bytes. Like I mentioned it even affected the RandomLoopDelay animations, making them play nonstop. _________________ QUICK_EDIT
I think I know why. Maybe I shouldn't jump CnCs so often
Scenario isn't allocated statically and thus I shouldn't have added the offset of the randomizer to the pointer, but to the value of the pointer. Huge difference.
Atm I don't have a fix for it, because it would require five more bytes than there are. The five bytes need to be replaced by ten, which obviously doesn't fit: "8B 0D 38 24 7E 00 81 C1 18 02 00 00". Sorry. _________________ QUICK_EDIT
@ 0x15AE2, replace B9 40 BE 74 00 with E9 29 3F 2B 00
@ 0x2C9A10 type in A1 38 24 7E 00 8D 88 18 02 00 00 E9 C7 C0 D4 FF
What it is basically doing is jumping out of the code block inside AnimClass::AI() and to a empty space at the end of the code segment, does the required hack (same code as exists in YR, this is what AlexB copied originally), then jumps back. QUICK_EDIT
Gave it a try and everything seems to work normally. RandomLoopDelay anims play randomly and no crashes when quitting a match. LKO can you test this hack with the dirt devils so we know if it solves all the problems with RandomLoopDelays dealing damage in multiplayer matches.
As I said in my first post, my mod does sometimes randomly freeze (usually long into the match, with game speed 6). No IE pops up, the game just completely freezes and need to kill the process. While testing this hack it happened to me again. Here's the except if anyone can make any sense of it. Would be nice to know if this freeze really does relate to the InvisibleInGame key.
EDIT: oh yeah lol, guess if the game just completely freezes you don't get an except.txt. The one I uploaded was an old one. _________________ QUICK_EDIT
I used to have issues with the game freezing after a while in DTA as well, although this only happened on temperate maps (although they're "desert" maps in DTA).
After quite a while of searching for the cause I eventually found that having replaced tile sets 0002 and 0003 was the reason for the freezes and after removing any tiles from those tile sets from DTA's maps the freezes stopped happening.
Maybe the cause of the freezes you're getting is the same or similar. An easy way to figure out whether terrain is the cause of the freezes is to simply make a blank (so no terrain other than clear ground) map on which the AI doesn't deploy its MCV (it should be easy enough for you to figure out how to achieve that by now =P) and then let it run for a few hours. If it hasn't frozen after 1 or 2 hours, it should be clear that terrain is the cause.
If you happen to know whether all maps or just a few maps freeze in your mod, that can also help with narrowing it down; you'll just have to check which tile set is unused on the maps that don't freeze or vice-versa. _________________ QUICK_EDIT
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum
InvisibleInGame and Invisible
Do you have any knowledge about the InvisibleInGame and Invisible keys supposedly causing problems? Maybe we need enough people test using them, and try to cause a crash. Then look at the except.txt's and see where the problem is. If I get another random freeze in my mod I'll post the except here. Though they happen quite rarely, and usually when I run the game at game speed 6.
