Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: DLPB_ on 2015-02-20 00:52:25
-
Rather than keep creating threads for every single fix/question, I may as well use this one.
Wallmarket Scroll Fix
I have no idea how I forgot that Dziugo had fixed this issue when I asked him (back in 2012). For others wanting to fix the broken scrolling here is what he said:
Ok, instead of PM-ing you, I'll post it here for reference. There is no bug in the code! Square made a mistake when creating the script. To fix it, open flevel.lgp with flevel editor (Makou Reactor is great!), go to file mrkt2, group "camera" (Id=3), Script1 and change:
Scroll to location (X=0, Y=-240, speed=470)Into:
Scroll to location (X=0, Y=-240, speed=480)The panning is from 240 to -240 which gives you 480 "pixels", but the length of the animation is set to 470. So it skips sometimes to end it at -240 when the timer hits 470. Changing it to 480 fixes it.
Here is the log from debugger (logging Y value):
00643F7A LOG: 0F0 (240.)
00643F7A LOG: 0EF (239.)
00643F7A LOG: 0EE (238.)
00643F7A LOG: 0ED (237.)
00643F7A LOG: 0EC (236.)
00643F7A LOG: 0EB (235.)
00643F7A LOG: 0EA (234.)
00643F7A LOG: 0E9 (233.)
00643F7A LOG: 0E8 (232.)
00643F7A LOG: 0E7 (231.)
00643F7A LOG: 0E6 (230.)
00643F7A LOG: 0E5 (229.)
00643F7A LOG: 0E4 (228.)
00643F7A LOG: 0E3 (227.)
00643F7A LOG: 0E2 (226.)
00643F7A LOG: 0E1 (225.)
00643F7A LOG: 0E0 (224.)
00643F7A LOG: 0DF (223.)
00643F7A LOG: 0DE (222.)
00643F7A LOG: 0DD (221.)
00643F7A LOG: 0DC (220.)
00643F7A LOG: 0DB (219.)
00643F7A LOG: 0DA (218.)
00643F7A LOG: 0D9 (217.)
00643F7A LOG: 0D8 (216.)
00643F7A LOG: 0D7 (215.)
00643F7A LOG: 0D6 (214.)
00643F7A LOG: 0D5 (213.)
00643F7A LOG: 0D4 (212.)
00643F7A LOG: 0D3 (211.)
00643F7A LOG: 0D2 (210.)
00643F7A LOG: 0D1 (209.)
00643F7A LOG: 0D0 (208.)
00643F7A LOG: 0CF (207.)
00643F7A LOG: 0CE (206.)
00643F7A LOG: 0CD (205.)
00643F7A LOG: 0CC (204.)
00643F7A LOG: 0CB (203.)
00643F7A LOG: 0CA (202.)
00643F7A LOG: 0C9 (201.)
00643F7A LOG: 0C8 (200.)
00643F7A LOG: 0C7 (199.)
00643F7A LOG: 0C6 (198.)
00643F7A LOG: 0C5 (197.)
00643F7A LOG: 0C4 (196.)
00643F7A LOG: 0C3 (195.)
00643F7A LOG: 0C2 (194.)
---
00643F7A LOG: 0C0 (192.)
00643F7A LOG: 0BF (191.)
00643F7A LOG: 0BE (190.)
00643F7A LOG: 0BD (189.)
00643F7A LOG: 0BC (188.)
00643F7A LOG: 0BB (187.)
00643F7A LOG: 0BA (186.)
00643F7A LOG: 0B9 (185.)
00643F7A LOG: 0B8 (184.)
00643F7A LOG: 0B7 (183.)
00643F7A LOG: 0B6 (182.)
00643F7A LOG: 0B5 (181.)
00643F7A LOG: 0B4 (180.)
00643F7A LOG: 0B3 (179.)
00643F7A LOG: 0B2 (178.)
00643F7A LOG: 0B1 (177.)
00643F7A LOG: 0B0 (176.)
00643F7A LOG: 0AF (175.)
00643F7A LOG: 0AE (174.)
00643F7A LOG: 0AD (173.)
00643F7A LOG: 0AC (172.)
00643F7A LOG: 0AB (171.)
00643F7A LOG: 0AA (170.)
00643F7A LOG: 0A9 (169.)
00643F7A LOG: 0A8 (168.)
00643F7A LOG: 0A7 (167.)
00643F7A LOG: 0A6 (166.)
00643F7A LOG: 0A5 (165.)
00643F7A LOG: 0A4 (164.)
00643F7A LOG: 0A3 (163.)
00643F7A LOG: 0A2 (162.)
00643F7A LOG: 0A1 (161.)
00643F7A LOG: 0A0 (160.)
00643F7A LOG: 9F (159.)
00643F7A LOG: 9E (158.)
00643F7A LOG: 9D (157.)
00643F7A LOG: 9C (156.)
00643F7A LOG: 9B (155.)
00643F7A LOG: 9A (154.)
00643F7A LOG: 99 (153.)
00643F7A LOG: 98 (152.)
00643F7A LOG: 97 (151.)
00643F7A LOG: 96 (150.)
00643F7A LOG: 95 (149.)
00643F7A LOG: 94 (148.)
00643F7A LOG: 93 (147.)
00643F7A LOG: 92 (146.)
---
00643F7A LOG: 90 (144.)
00643F7A LOG: 8F (143.)
00643F7A LOG: 8E (142.)
00643F7A LOG: 8D (141.)
00643F7A LOG: 8C (140.)
00643F7A LOG: 8B (139.)
00643F7A LOG: 8A (138.)
00643F7A LOG: 89 (137.)
00643F7A LOG: 88 (136.)
00643F7A LOG: 87 (135.)
00643F7A LOG: 86 (134.)
00643F7A LOG: 85 (133.)
00643F7A LOG: 84 (132.)
00643F7A LOG: 83 (131.)
00643F7A LOG: 82 (130.)
00643F7A LOG: 81 (129.)
00643F7A LOG: 80 (128.)
00643F7A LOG: 7F (127.)
00643F7A LOG: 7E (126.)
00643F7A LOG: 7D (125.)
00643F7A LOG: 7C (124.)
00643F7A LOG: 7B (123.)
00643F7A LOG: 7A (122.)
00643F7A LOG: 79 (121.)
00643F7A LOG: 78 (120.)
00643F7A LOG: 77 (119.)
00643F7A LOG: 76 (118.)
00643F7A LOG: 75 (117.)
00643F7A LOG: 74 (116.)
00643F7A LOG: 73 (115.)
00643F7A LOG: 72 (114.)
00643F7A LOG: 71 (113.)
00643F7A LOG: 70 (112.)
00643F7A LOG: 6F (111.)
00643F7A LOG: 6E (110.)
00643F7A LOG: 6D (109.)
00643F7A LOG: 6C (108.)
00643F7A LOG: 6B (107.)
00643F7A LOG: 6A (106.)
00643F7A LOG: 69 (105.)
00643F7A LOG: 68 (104.)
00643F7A LOG: 67 (103.)
00643F7A LOG: 66 (102.)
00643F7A LOG: 65 (101.)
00643F7A LOG: 64 (100.)
00643F7A LOG: 63 (99.)
00643F7A LOG: 62 (98.)
---
00643F7A LOG: 60 (96.)
00643F7A LOG: 5F (95.)
00643F7A LOG: 5E (94.)
00643F7A LOG: 5D (93.)
00643F7A LOG: 5C (92.)
00643F7A LOG: 5B (91.)
00643F7A LOG: 5A (90.)
00643F7A LOG: 59 (89.)
00643F7A LOG: 58 (88.)
00643F7A LOG: 57 (87.)
00643F7A LOG: 56 (86.)
00643F7A LOG: 55 (85.)
00643F7A LOG: 54 (84.)
00643F7A LOG: 53 (83.)
00643F7A LOG: 52 (82.)
00643F7A LOG: 51 (81.)
00643F7A LOG: 50 (80.)
00643F7A LOG: 4F (79.)
00643F7A LOG: 4E (78.)
00643F7A LOG: 4D (77.)
00643F7A LOG: 4C (76.)
00643F7A LOG: 4B (75.)
00643F7A LOG: 4A (74.)
00643F7A LOG: 49 (73.)
00643F7A LOG: 48 (72.)
00643F7A LOG: 47 (71.)
00643F7A LOG: 46 (70.)
00643F7A LOG: 45 (69.)
00643F7A LOG: 44 (68.)
00643F7A LOG: 43 (67.)
00643F7A LOG: 42 (66.)
00643F7A LOG: 41 (65.)
00643F7A LOG: 40 (64.)
00643F7A LOG: 3F (63.)
00643F7A LOG: 3E (62.)
00643F7A LOG: 3D (61.)
00643F7A LOG: 3C (60.)
00643F7A LOG: 3B (59.)
00643F7A LOG: 3A (58.)
00643F7A LOG: 39 (57.)
00643F7A LOG: 38 (56.)
00643F7A LOG: 37 (55.)
00643F7A LOG: 36 (54.)
00643F7A LOG: 35 (53.)
00643F7A LOG: 34 (52.)
00643F7A LOG: 33 (51.)
00643F7A LOG: 32 (50.)
---
00643F7A LOG: 30 (48.)
00643F7A LOG: 2F (47.)
00643F7A LOG: 2E (46.)
00643F7A LOG: 2D (45.)
00643F7A LOG: 2C (44.)
00643F7A LOG: 2B (43.)
00643F7A LOG: 2A (42.)
00643F7A LOG: 29 (41.)
00643F7A LOG: 28 (40.)
00643F7A LOG: 27 (39.)
00643F7A LOG: 26 (38.)
00643F7A LOG: 25 (37.)
00643F7A LOG: 24 (36.)
00643F7A LOG: 23 (35.)
00643F7A LOG: 22 (34.)
00643F7A LOG: 21 (33.)
00643F7A LOG: 20 (32.)
00643F7A LOG: 1F (31.)
00643F7A LOG: 1E (30.)
00643F7A LOG: 1D (29.)
00643F7A LOG: 1C (28.)
00643F7A LOG: 1B (27.)
00643F7A LOG: 1A (26.)
00643F7A LOG: 19 (25.)
00643F7A LOG: 18 (24.)
00643F7A LOG: 17 (23.)
00643F7A LOG: 16 (22.)
00643F7A LOG: 15 (21.)
00643F7A LOG: 14 (20.)
00643F7A LOG: 13 (19.)
00643F7A LOG: 12 (18.)
00643F7A LOG: 11 (17.)
00643F7A LOG: 10 (16.)
00643F7A LOG: 0F (15.)
00643F7A LOG: 0E (14.)
00643F7A LOG: 0D (13.)
00643F7A LOG: 0C (12.)
00643F7A LOG: 0B (11.)
00643F7A LOG: 0A (10.)
00643F7A LOG: 9
00643F7A LOG: 8
00643F7A LOG: 7
00643F7A LOG: 6
00643F7A LOG: 5
00643F7A LOG: 4
00643F7A LOG: 3
00643F7A LOG: 2
---
00643F7A LOG: 0
00643F7A LOG: FFFFFFFF (4294967295.)
00643F7A LOG: FFFFFFFE (4294967294.)
00643F7A LOG: FFFFFFFD (4294967293.)
00643F7A LOG: FFFFFFFC (4294967292.)
00643F7A LOG: FFFFFFFB (4294967291.)
00643F7A LOG: FFFFFFFA (4294967290.)
00643F7A LOG: FFFFFFF9 (4294967289.)
00643F7A LOG: FFFFFFF8 (4294967288.)
00643F7A LOG: FFFFFFF7 (4294967287.)
00643F7A LOG: FFFFFFF6 (4294967286.)
00643F7A LOG: FFFFFFF5 (4294967285.)
00643F7A LOG: FFFFFFF4 (4294967284.)
00643F7A LOG: FFFFFFF3 (4294967283.)
00643F7A LOG: FFFFFFF2 (4294967282.)
00643F7A LOG: FFFFFFF1 (4294967281.)
00643F7A LOG: FFFFFFF0 (4294967280.)
00643F7A LOG: FFFFFFEF (4294967279.)
00643F7A LOG: FFFFFFEE (4294967278.)
00643F7A LOG: FFFFFFED (4294967277.)
00643F7A LOG: FFFFFFEC (4294967276.)
00643F7A LOG: FFFFFFEB (4294967275.)
00643F7A LOG: FFFFFFEA (4294967274.)
00643F7A LOG: FFFFFFE9 (4294967273.)
00643F7A LOG: FFFFFFE8 (4294967272.)
00643F7A LOG: FFFFFFE7 (4294967271.)
00643F7A LOG: FFFFFFE6 (4294967270.)
00643F7A LOG: FFFFFFE5 (4294967269.)
00643F7A LOG: FFFFFFE4 (4294967268.)
00643F7A LOG: FFFFFFE3 (4294967267.)
00643F7A LOG: FFFFFFE2 (4294967266.)
00643F7A LOG: FFFFFFE1 (4294967265.)
00643F7A LOG: FFFFFFE0 (4294967264.)
00643F7A LOG: FFFFFFDF (4294967263.)
00643F7A LOG: FFFFFFDE (4294967262.)
00643F7A LOG: FFFFFFDD (4294967261.)
00643F7A LOG: FFFFFFDC (4294967260.)
00643F7A LOG: FFFFFFDB (4294967259.)
00643F7A LOG: FFFFFFDA (4294967258.)
00643F7A LOG: FFFFFFD9 (4294967257.)
00643F7A LOG: FFFFFFD8 (4294967256.)
00643F7A LOG: FFFFFFD7 (4294967255.)
00643F7A LOG: FFFFFFD6 (4294967254.)
00643F7A LOG: FFFFFFD5 (4294967253.)
00643F7A LOG: FFFFFFD4 (4294967252.)
00643F7A LOG: FFFFFFD3 (4294967251.)
00643F7A LOG: FFFFFFD2 (4294967250.)
---
00643F7A LOG: FFFFFFD0 (4294967248.)
00643F7A LOG: FFFFFFCF (4294967247.)
00643F7A LOG: FFFFFFCE (4294967246.)
00643F7A LOG: FFFFFFCD (4294967245.)
00643F7A LOG: FFFFFFCC (4294967244.)
00643F7A LOG: FFFFFFCB (4294967243.)
00643F7A LOG: FFFFFFCA (4294967242.)
00643F7A LOG: FFFFFFC9 (4294967241.)
00643F7A LOG: FFFFFFC8 (4294967240.)
00643F7A LOG: FFFFFFC7 (4294967239.)
00643F7A LOG: FFFFFFC6 (4294967238.)
00643F7A LOG: FFFFFFC5 (4294967237.)
00643F7A LOG: FFFFFFC4 (4294967236.)
00643F7A LOG: FFFFFFC3 (4294967235.)
00643F7A LOG: FFFFFFC2 (4294967234.)
00643F7A LOG: FFFFFFC1 (4294967233.)
00643F7A LOG: FFFFFFC0 (4294967232.)
00643F7A LOG: FFFFFFBF (4294967231.)
00643F7A LOG: FFFFFFBE (4294967230.)
00643F7A LOG: FFFFFFBD (4294967229.)
00643F7A LOG: FFFFFFBC (4294967228.)
00643F7A LOG: FFFFFFBB (4294967227.)
00643F7A LOG: FFFFFFBA (4294967226.)
00643F7A LOG: FFFFFFB9 (4294967225.)
00643F7A LOG: FFFFFFB8 (4294967224.)
00643F7A LOG: FFFFFFB7 (4294967223.)
00643F7A LOG: FFFFFFB6 (4294967222.)
00643F7A LOG: FFFFFFB5 (4294967221.)
00643F7A LOG: FFFFFFB4 (4294967220.)
00643F7A LOG: FFFFFFB3 (4294967219.)
00643F7A LOG: FFFFFFB2 (4294967218.)
00643F7A LOG: FFFFFFB1 (4294967217.)
00643F7A LOG: FFFFFFB0 (4294967216.)
00643F7A LOG: FFFFFFAF (4294967215.)
00643F7A LOG: FFFFFFAE (4294967214.)
00643F7A LOG: FFFFFFAD (4294967213.)
00643F7A LOG: FFFFFFAC (4294967212.)
00643F7A LOG: FFFFFFAB (4294967211.)
00643F7A LOG: FFFFFFAA (4294967210.)
00643F7A LOG: FFFFFFA9 (4294967209.)
00643F7A LOG: FFFFFFA8 (4294967208.)
00643F7A LOG: FFFFFFA7 (4294967207.)
00643F7A LOG: FFFFFFA6 (4294967206.)
00643F7A LOG: FFFFFFA5 (4294967205.)
00643F7A LOG: FFFFFFA4 (4294967204.)
00643F7A LOG: FFFFFFA3 (4294967203.)
00643F7A LOG: FFFFFFA2 (4294967202.)
---
00643F7A LOG: FFFFFFA0 (4294967200.)
00643F7A LOG: FFFFFF9F (4294967199.)
00643F7A LOG: FFFFFF9E (4294967198.)
00643F7A LOG: FFFFFF9D (4294967197.)
00643F7A LOG: FFFFFF9C (4294967196.)
00643F7A LOG: FFFFFF9B (4294967195.)
00643F7A LOG: FFFFFF9A (4294967194.)
00643F7A LOG: FFFFFF99 (4294967193.)
00643F7A LOG: FFFFFF98 (4294967192.)
00643F7A LOG: FFFFFF97 (4294967191.)
00643F7A LOG: FFFFFF96 (4294967190.)
00643F7A LOG: FFFFFF95 (4294967189.)
00643F7A LOG: FFFFFF94 (4294967188.)
00643F7A LOG: FFFFFF93 (4294967187.)
00643F7A LOG: FFFFFF92 (4294967186.)
00643F7A LOG: FFFFFF91 (4294967185.)
00643F7A LOG: FFFFFF90 (4294967184.)
00643F7A LOG: FFFFFF8F (4294967183.)
00643F7A LOG: FFFFFF8E (4294967182.)
00643F7A LOG: FFFFFF8D (4294967181.)
00643F7A LOG: FFFFFF8C (4294967180.)
00643F7A LOG: FFFFFF8B (4294967179.)
00643F7A LOG: FFFFFF8A (4294967178.)
00643F7A LOG: FFFFFF89 (4294967177.)
00643F7A LOG: FFFFFF88 (4294967176.)
00643F7A LOG: FFFFFF87 (4294967175.)
00643F7A LOG: FFFFFF86 (4294967174.)
00643F7A LOG: FFFFFF85 (4294967173.)
00643F7A LOG: FFFFFF84 (4294967172.)
00643F7A LOG: FFFFFF83 (4294967171.)
00643F7A LOG: FFFFFF82 (4294967170.)
00643F7A LOG: FFFFFF81 (4294967169.)
00643F7A LOG: FFFFFF80 (4294967168.)
00643F7A LOG: FFFFFF7F (4294967167.)
00643F7A LOG: FFFFFF7E (4294967166.)
00643F7A LOG: FFFFFF7D (4294967165.)
00643F7A LOG: FFFFFF7C (4294967164.)
00643F7A LOG: FFFFFF7B (4294967163.)
00643F7A LOG: FFFFFF7A (4294967162.)
00643F7A LOG: FFFFFF79 (4294967161.)
00643F7A LOG: FFFFFF78 (4294967160.)
00643F7A LOG: FFFFFF77 (4294967159.)
00643F7A LOG: FFFFFF76 (4294967158.)
00643F7A LOG: FFFFFF75 (4294967157.)
00643F7A LOG: FFFFFF74 (4294967156.)
00643F7A LOG: FFFFFF73 (4294967155.)
00643F7A LOG: FFFFFF72 (4294967154.)
---
00643F7A LOG: FFFFFF70 (4294967152.)
00643F7A LOG: FFFFFF6F (4294967151.)
00643F7A LOG: FFFFFF6E (4294967150.)
00643F7A LOG: FFFFFF6D (4294967149.)
00643F7A LOG: FFFFFF6C (4294967148.)
00643F7A LOG: FFFFFF6B (4294967147.)
00643F7A LOG: FFFFFF6A (4294967146.)
00643F7A LOG: FFFFFF69 (4294967145.)
00643F7A LOG: FFFFFF68 (4294967144.)
00643F7A LOG: FFFFFF67 (4294967143.)
00643F7A LOG: FFFFFF66 (4294967142.)
00643F7A LOG: FFFFFF65 (4294967141.)
00643F7A LOG: FFFFFF64 (4294967140.)
00643F7A LOG: FFFFFF63 (4294967139.)
00643F7A LOG: FFFFFF62 (4294967138.)
00643F7A LOG: FFFFFF61 (4294967137.)
00643F7A LOG: FFFFFF60 (4294967136.)
00643F7A LOG: FFFFFF5F (4294967135.)
00643F7A LOG: FFFFFF5E (4294967134.)
00643F7A LOG: FFFFFF5D (4294967133.)
00643F7A LOG: FFFFFF5C (4294967132.)
00643F7A LOG: FFFFFF5B (4294967131.)
00643F7A LOG: FFFFFF5A (4294967130.)
00643F7A LOG: FFFFFF59 (4294967129.)
00643F7A LOG: FFFFFF58 (4294967128.)
00643F7A LOG: FFFFFF57 (4294967127.)
00643F7A LOG: FFFFFF56 (4294967126.)
00643F7A LOG: FFFFFF55 (4294967125.)
00643F7A LOG: FFFFFF54 (4294967124.)
00643F7A LOG: FFFFFF53 (4294967123.)
00643F7A LOG: FFFFFF52 (4294967122.)
00643F7A LOG: FFFFFF51 (4294967121.)
00643F7A LOG: FFFFFF50 (4294967120.)
00643F7A LOG: FFFFFF4F (4294967119.)
00643F7A LOG: FFFFFF4E (4294967118.)
00643F7A LOG: FFFFFF4D (4294967117.)
00643F7A LOG: FFFFFF4C (4294967116.)
00643F7A LOG: FFFFFF4B (4294967115.)
00643F7A LOG: FFFFFF4A (4294967114.)
00643F7A LOG: FFFFFF49 (4294967113.)
00643F7A LOG: FFFFFF48 (4294967112.)
00643F7A LOG: FFFFFF47 (4294967111.)
00643F7A LOG: FFFFFF46 (4294967110.)
00643F7A LOG: FFFFFF45 (4294967109.)
00643F7A LOG: FFFFFF44 (4294967108.)
00643F7A LOG: FFFFFF43 (4294967107.)
00643F7A LOG: FFFFFF42 (4294967106.)
---
00643F7A LOG: FFFFFF40 (4294967104.)
00643F7A LOG: FFFFFF3F (4294967103.)
00643F7A LOG: FFFFFF3E (4294967102.)
00643F7A LOG: FFFFFF3D (4294967101.)
00643F7A LOG: FFFFFF3C (4294967100.)
00643F7A LOG: FFFFFF3B (4294967099.)
00643F7A LOG: FFFFFF3A (4294967098.)
00643F7A LOG: FFFFFF39 (4294967097.)
00643F7A LOG: FFFFFF38 (4294967096.)
00643F7A LOG: FFFFFF37 (4294967095.)
00643F7A LOG: FFFFFF36 (4294967094.)
00643F7A LOG: FFFFFF35 (4294967093.)
00643F7A LOG: FFFFFF34 (4294967092.)
00643F7A LOG: FFFFFF33 (4294967091.)
00643F7A LOG: FFFFFF32 (4294967090.)
00643F7A LOG: FFFFFF31 (4294967089.)
00643F7A LOG: FFFFFF30 (4294967088.)
00643F7A LOG: FFFFFF2F (4294967087.)
00643F7A LOG: FFFFFF2E (4294967086.)
00643F7A LOG: FFFFFF2D (4294967085.)
00643F7A LOG: FFFFFF2C (4294967084.)
00643F7A LOG: FFFFFF2B (4294967083.)
00643F7A LOG: FFFFFF2A (4294967082.)
00643F7A LOG: FFFFFF29 (4294967081.)
00643F7A LOG: FFFFFF28 (4294967080.)
00643F7A LOG: FFFFFF27 (4294967079.)
00643F7A LOG: FFFFFF26 (4294967078.)
00643F7A LOG: FFFFFF25 (4294967077.)
00643F7A LOG: FFFFFF24 (4294967076.)
00643F7A LOG: FFFFFF23 (4294967075.)
00643F7A LOG: FFFFFF22 (4294967074.)
00643F7A LOG: FFFFFF21 (4294967073.)
00643F7A LOG: FFFFFF20 (4294967072.)
00643F7A LOG: FFFFFF1F (4294967071.)
00643F7A LOG: FFFFFF1E (4294967070.)
00643F7A LOG: FFFFFF1D (4294967069.)
00643F7A LOG: FFFFFF1C (4294967068.)
00643F7A LOG: FFFFFF1B (4294967067.)
00643F7A LOG: FFFFFF1A (4294967066.)
00643F7A LOG: FFFFFF19 (4294967065.)
00643F7A LOG: FFFFFF18 (4294967064.)
00643F7A LOG: FFFFFF17 (4294967063.)
00643F7A LOG: FFFFFF16 (4294967062.)
00643F7A LOG: FFFFFF15 (4294967061.)
00643F7A LOG: FFFFFF14 (4294967060.)
00643F7A LOG: FFFFFF13 (4294967059.)
00643F7A LOG: FFFFFF12 (4294967058.)
---
00643F7A LOG: FFFFFF10 (4294967056.)I've marked missing values with ---, that's where you see the skip. I've looked at the PSX version at YouTube and it's there too.
You can fix it without modifying flevel.lgp by hooking the opcode and correcting the steps value on the fly. Sorry, it was that simple. FPS bug is elsewhere.
As a side note, memory offsets in the 2012 release are the same as the 1998 one (1.02 ff7.exe), so anything that doesn't rely on the opengl thing should work if the patcher is not picky (again, the one working in the memory - to patch the file you'd either have to adaptively patch or make the static AF3DN linking to old exe described in the other thread).
You also need to change the "wait frames" from 2 to 1.
-
Need confirmation on whether this works. It is likely something to do with script here.
-
Materia Caves
There is a bug with the four Materia Caves because they've used location lines to determine if user can pick up the item. This can sometimes fail and mean the item is missed.
There is an easier way to do this than the convoluted way it has been done originally - use a hidden NPC model. I spotted this approach to the problem in the Train Graveyard. The items inside the barrels are actually a hidden NPC model in the same place as the graphic. Nifty.
-
NFITC1 said somewhere that this bug was harder to fix than you'd expect. I have just noticed that there is more than one bug here too.
1. W-Item can be used to repopulate the inventory
2. If you cancel the menu after using one item, it is lost forever.
It is very easy to stop W-Item bug 1 by 006DB67F = 80 C1 00 (or extending the jump above it).
It will, at least, stop the duplications. I am going to have a quick look to see if 2 can be fixed properly.
Yup, I can't be bothered with that mess. Looks like the second bug will remain for the moment, but no more repopulating at least ;)
I think what needs to happen is the jump at 6DB650 being extended to 6DB682, and whatever part closes the menu after using the first item needs to invoke the part that is skipped by the new jump (which adds the item back).
-
NFITC1 said somewhere that this bug was harder to fix than you'd expect. I have just noticed that there is more than one bug here too.
1. W-Item can be used to repopulate the inventory
2. If you cancel the menu after using one item, it is lost forever.
It is very easy to stop W-Item bug 1 by 006DB67F = 80 C1 00 (or extending the jump above it).
It will, at least, stop the duplications. I am going to have a quick look to see if 2 can be fixed properly.
Yup, I can't be bothered with that mess. Looks like the second bug will remain for the moment, but no more repopulating at least ;)
I think what needs to happen is the jump at 6DB650 being extended to 6DB682, and whatever part closes the menu after using the first item needs to invoke the part that is skipped by the new jump (which adds the item back).
You know that you will make many people mad with that? Good to see that it is fixed now. It is really hard to resist and not to abuse this bug. ::)
-
Does anyone really understand how this works? I've read Terence guide on stat increases, but as per my convo with NFITC1, it seems WM does not give accurate curve depiction (which is essential for Weapon... I need to know exactly how much a stat will increase at each level).
Take the following:
http://i.imgur.com/r8nZzFJ.png
How do the red areas interact? What is their relationship? Both are for MP in Weapon.
At the moment, WM shows that Cloud will gain a maximum of 100 MP over 99 levels... but on his first level increase, despite WM showing a 1 MP increase, it actually adds 10.
Unless there is some "minimum" thing that the game checks.
-
There IS a minimum check... of 10.
See 5CB7C5, for example. How ferning irritating.
I understand how the stats work now. It sucks, like everything else.
-
Need help. I'm getting there... somehow.
FF7 is programmed needlessly complicated.... it really is. I am currently trying to reprogram the way battle speed is used. See... *sigh* the developers of FF7 decided to make this a mess and I need proper values to work with so I can gauge how strong an enemy should be at a given time. Sadly, even enemy speed is different to how character speed is determined, and both use another timer as well as relationship between them to decide how fast a character is. And even that's CRAP.
What I need is this:
Cloud Dexterity = 100 = twice as fast as 50. No ifs, no buts. Cloud at 100 dex should make his bar move twice as fast as it did at 50.
Enemy dex = 100 = twice as fast as 50. Same as above. And totally equivalent of Cloud's speed.
This means that if both characters have dex of 100, their bars will fill up at the same time, and if both are 50... they will fill up at same time.
Also, each character's bar should be totally dependent on their overall dex and in NO WAY related to the overall dex of the party.
Just look at this NONSENSE >>
http://www.gamefaqs.com/ps/197341-final-fantasy-vii/faqs/22395
--- --------------
2.5 The Turn Timer
--- --------------
Finally, the Turn Timer. This is the most complicated of the four timers,
since it is based around the relative Dex stats of the combatants.
First, we must find the normal value: the base Dex to be used for this
battle. This is calculated by taking the average *BASE* Dexterity of all
three combatants in your Battle Party, making sure to round up any fractions.
Finally, we add 50 to this average. We call this the Normal Speed.
For example, if you enter battle with Cloud at 31 Agi and Barret at 24 Agi,
then the Normal Speed would be:
Normal Speed = RU((31 + 24) / 2) + 50
= RU(55 / 2) + 50
= RU(27.5) + 50
= 28 + 50
= 78
Keep in mind that only *BASE* Dexterity counts for Normal Speed. The use of
Speed Sources, Materia and Dex-altering abilities or equipment do *NOT* count
towards this value.
Now, the amount your Turn Timer increases by revolves around the V-Timer. As
such, the Turn Timer will also pause when the V-Timer pauses, and change
speed when the V-Timer does so.
Furthermore, the amount of increase you get is different from party members
to monsters. Your party members get the following increase:
Turn Timer Increase = [(Total Dex + 50) * V-Timer Increase / Normal Speed]
While monsters get this per tick instead:
Turn Timer Increase = [Dex * V-Timer Increase / Normal Speed]
If you've noticed that enemies seem to have rather high Dex values, this is
why. Also, while Sources, Materia and Equipment are not used for Normal
Speed, they *are* used to calculate your Total Dex - so the use of Sources
will make you much much faster than normal.
Finally, the Turn Timer itself (but not the V- or C-Timers) will be halted
under the following statuses: Paralysed, Petrify and Sleep.
You'll find that unless you use a lot of Sources or Dex-increasing items,
your Turn Timer Increase will tend to be very close to your V-Timer Increase;
after all, we're dividing your character's 'Dex + 50' by the party's average
'Dex + 50'. This also means that no matter what your level, you will seem
to get your turns just as quickly as you used to.
However, as you achieve higher Dex ratings, it will begin to appear to you
that the monsters are moving *SLOWER* than they used to. A L6 Cloud only has
a Dex of 6, while a L99 Cloud has an average Dex of 59. Going by what we
know about the Turn Timer now, this means that the L99 Cloud is almost twice
as fast as the L6 Cloud. However, to you, it'll likely look like the exact
same speed as before. Instead, the *monsters* will be moving twice as slow
to you.
One final thing we'll look at in detail is the use of Sources or Dex-
modifying equipment here. As stated, our L99 Cloud has an average Dex of 59.
Using Sources, we can increase his total Dex up to a nice total of 255.
Cloud with 255 Dex is 2.8x faster than when he was at 59 Dex. However,
unlike the natural growth, we will *see* his Turn Timer increasing that much
faster, since the Normal Speed hasn't changed. Understanding this is one of
the keys to understanding how the four different timers interact.
This is one of the reasons the original difficulty SUCKS. The people in charge of modifying all the stats had an impossible job of gauging what difference each stat made to the overall battle. Already I've had to reprogram the needlessly complicated damage equations for the same reason.
So, how the heck am I going to achieve this... Is it doable?
-
I managed it.... Terence's guide is a bit more confusing than it needs to be also.
Assuming I haven't wrecked something, I now have a situation where dexterity is all that matters to the normal turn time.
-
It's taken god knows how long, but I've done it. Here are the differences:
1. The constant timer really will be constant (4096/68). A second will be a second when you are in a status. So Stop will last a fixed length of time, so will sleep, so will death sentence and so on. They will all use the constant timer. Originally, the constant timer could be altered with Haste, stop and Slow... no more. Active time battle is forced. The battle also has a set speed that cannot be altered.
2. The global timer and main timer will also be a constant time value (8192 / 136) and the ability to change speed in config disabled.
3. V-timer is abolished for the Turn Timer calcs and made constant (8192 / 136) .
4. The Turn Timer is now all-powerful and relies 100% on Dexterity stat.
I have created a set of simple calculations to determine how long the next turn will take:
Seconds until turn = 1092 / ( (dexterity + 44) * 4)
This means that at a Dex of 1
Seconds until Turn = 1092 /( (1+44) * 4) = 6 Seconds until turn.
The Haste and Slow functions have been incorporated into my new function also.
The full equation for Slow is:
Time for Turn = 1092 / ( Dex + 44 * 4 * (48 / 32) )
The full equation for Haste is:
Time for Turn = 1092 / ( Dex + 44 * 4 * (24 / 32) )
I had to totally rewrite a function to make all this work, and I am guessing it will need some more additions in time. For example, function checks for death and resets timer to 0.
I have simplified the above equations by balancing it out. In other words, 1092 comes from 65535 / 60. Trust me... it works.
Enemies also now use these formulas... so the dex stat for enemy is fair and consistent with characters. Battles now have a fixed, real-time flow to them.
-
Just for documentation, the time that certain effects wear off are held in a table (one byte each) starting 7B74F0 and accessed from 433B63.
These are as follows:
Stop: 7B74F0
Paralysis: 7B74F1
Death Sentence: 7B74F2
Slow Numb: 7B74F3
Barrier: 7B74F4
M-Barrier: 7B74F5
Poison: 7B74F6*
Sleep: 7B74F7
Regen: 7B74F8
Shield: 7B74FA
Peerless: 7B74FB
*Poison's value is how long it takes to deduct HP
The maximum time is 255 seconds, but the timer display on screen is programmed to work with 60 as a maximum (for Death-Sentence and Slow Numb).
-
I am going to attempt to make the field appear centred. Already I can see this is going to take more than one value being changed.
cff1e4 = 10 00
This will centre the screen, but other values I have found are needed to centre it during scroll and transitions. Unfortunately, there are obviously more of these that need changing so that the NPC etc move correctly in relation to the field. But I think it's possible. I am not sure about FMV yet, that probably also requires a new value offset.
Searching for 80 02 00 00 c0 01 00 00 should come up with a few of the needed areas.
-
It must have been a long time since I played if I don't remember fields being off centered.
-
It must have been a long time since I played if I don't remember fields being off centered.
There is a large black area at the bottom of all fields equal to 32 pixels (480 - 448). This is from the PSX game where it is 16 (240 - 224).
-
Oh, I thought you meant left to right. Totally forgot about the Big Black border. Yeah getting rid of that would be awesome. Seems like something Aali could knock out easier with his driver though.
-
Oh, I thought you meant left to right. Totally forgot about the Big Black border. Yeah getting rid of that would be awesome. Seems like something Aali could knock out easier with his driver though.
He'd need to edit the same values I am though.... his driver would just patch the same code, I'm thinking. But I'll ask him.
-
Maybe so. Either way, Reunion is quickly becoming the second must-have for playing these days.
-
OK, so I redid the code for autosizing the attack message box while at same time maintaining the help bar (they are linked by same code normally). If anyone (looking at NFITC1) wants to look over this, then do so. I'm sure someone more in the know about assembly will see easier ways to do things. I managed to do this with no byte to spare.
Starting 6D21A2
8B C5 66 2D 58 01 8B 10 80 F9 19 75 0F 66 C7 00 0D 00 83 C2 18 66 89 15 1C D2 91 00 BB 80 02 00 00 29 D3 D1 EB 80 F9 19 74 05 66 89 18 31 DB 66 89 58 E4 66 C7 40 F0 0B 00 66 C7 40 10 00 00
This is for the original game.
-
You've got to have made more changes. None of this makes sense with just these changes.
-
You've got to have made more changes. None of this makes sense with just these changes.
It works perfectly fine in game. And it does what the original game does too. Have I missed something?
-
It works perfectly fine in game. And it does what the original game does too. Have I missed something?
Original Game code block:
.text:006D21A2 imul ecx, 98h
.text:006D21A8 mov edx, dword_DC3630
.text:006D21AE movsx eax, word ptr [edx+ecx+4]
.text:006D21B3 cdq
.text:006D21B4 sub eax, edx
.text:006D21B6 mov ecx, eax
.text:006D21B8 sar ecx, 1
.text:006D21BA movsx eax, [ebp+var_158]
.text:006D21C1 cdq
.text:006D21C2 sub eax, edx
.text:006D21C4 sar eax, 1
.text:006D21C6 sub ecx, eax
.text:006D21C8 mov [ebp+var_158], cx
.text:006D21CF mov [ebp+var_168], 0Ch
.text:006D21D8 mov [ebp+var_148], 0
v5 = *(_WORD *)(dword_DC3630 + 152 * a2 + 4);
v4 = (((_DWORD)v5 - HIDWORD(v5)) >> 1) - v117 / 2;
v118 = (((_DWORD)v5 - HIDWORD(v5)) >> 1) - v117 / 2;
Your block:
.text:006D21A2 mov eax, ebp
.text:006D21A4 sub ax, 158h
.text:006D21A8 mov edx, [eax]
.text:006D21AA cmp cl, 19h
.text:006D21AD jnz short loc_6D21BE
.text:006D21AF mov word ptr [eax], 0Dh
.text:006D21B4 add edx, 18h
.text:006D21B7 mov word_91D21C, dx
.text:006D21BE
.text:006D21BE loc_6D21BE: ; CODE XREF: sub_6D1CC0+4EDj
.text:006D21BE mov ebx, 280h
.text:006D21C3 sub ebx, edx
.text:006D21C5 shr ebx, 1
.text:006D21C7 cmp cl, 19h
.text:006D21CA jz short loc_6D21D1
.text:006D21CC mov [eax], bx
.text:006D21CF xor ebx, ebx
.text:006D21D1
.text:006D21D1 loc_6D21D1: ; CODE XREF: sub_6D1CC0+50Aj
.text:006D21D1 mov [eax-1Ch], bx
.text:006D21D5 mov word ptr [eax-10h], 0Bh
.text:006D21DB mov word ptr [eax+10h], 0
v7 = a2;
HIWORD(v5) = HIWORD(ebp0);
LOWORD(v5) = ebp0 - 344;
v6 = *(_DWORD *)v5;
if ( (_BYTE)a2 == 25 )
{
*(_WORD *)v5 = 13;
v6 += 24;
word_91D21C = v6;
}
v8 = (unsigned int)(640 - v6) >> 1;
if ( (_BYTE)v7 != 25 )
{
*(_WORD *)v5 = v8;
LOWORD(v8) = 0;
}
*(_WORD *)(v5 - 28) = v8;
*(_WORD *)(v5 - 16) = 11;
*(_WORD *)(v5 + 16) = 0;
These aren't equivalent at all.
-
A lot of the original code is redundant (for example, part of that is just pulling the value 280h from a memory location, something I could remove and just add manually). Have a look at it in game and see if there is an oversight (even if there is, it can't be catastrophic since everything is working as I want it to)? My code does what it's supposed to do - it sorts the help box and autosizes / positions the attack caption and box. Comparing the two codes won't really give you an idea of what has been changed visually.
-
Covarr informs me that FF7 port (using PC version) on the PS4 has fixed the broken frame limiter. I've looked into it before but don't know where to start. But at least we know it can be done.
-
I cross my fingers for it.
-
I cross my fingers for it.
I mean I know I keep going on about this - but it really really is a big issue. A frame limiter is a main component of the engine and it needs fixing.
-
I am still looking at the frame limiter. The world map limiter is not the same... prob why it actually works. Still... It's gonna take time, if I can at all.
-
It looks like I am not going to have any success (I'll keep trying). But I'll leave here what I think is going on and what Dziugo posted to me, in the hope someone else can figure this out. I think I've found the same function that Dziugo was editing too.
As far as I can see, the reason the limiter isn't accurate and drops frames under heavier load is simply because the calculation is bad. I remember when I programmed my own limiter for my own game using timegettime. If it isn't done right, you'll get frame drops where there shouldn't be. This is noticeable when trying to record games with something like Fraps. It will work perfectly if you set the frame rate of FF7 to 60 and then let fraps limit the game to 30 - but it will drop to 24-28 if you don't. This isn't a problem with Fraps - it will happen with any high load (although game recording shows the bug up more). For some people, attaining 30fps in normal play won't happen either. This is also not fixed by Aali's driver - which uses timegettime / qpc. Because it's the limiter that is broken and leading to this issue.
This is what Dziugo sent me:
How it works currently:
while (notEnd) {
doStuff1();
doStuff2 { // dynamic function, calling address changes depending on the module we're in
startTheRDTSCTimer(); A
doStuff2a(); // here the actual processing work
idleUntilRDTSCReachesTheDesiredValue(); B
doStuff2b(); // here some other work
}
doStuff3();
}
So, the game makes sure that the time between A and B is at least the time it calculated the frame processing should take... Wait a minute! What about the time it takes to get from B to A again? That's assumed to be exactly 10000 RDTSC ticks (for field).
This could affect the FPS slightly (now I see what you mean). One could correct it (slightly ;p) by moving the B just before A, or actually modding the limiter to take into account at least the last frame processing time (each additional frame will add precision, but with exponentially lowering results - something like 4-5 frames should be enough).
Note that the 10000 RDTSC ticks actually mess things up further. This is corrected when you do this >
7B7848 = 00 00 00 00 00 00 00 00 *note this part of the calculation is taken into account when going from a different module to field. So, going from world map to field recalculates and uses this Double floating point value.
Ok, got it to run at exactly 30.0 FPS (average of last 3 frames). I've merged A+B into one point, and made it CPU frequency independent, all that with just timeGetTime. Now, time to make it actually usable... ;p
And then I ran out of time. I've nailed down the frame limiter for field (field is special as there are actually two framelimiters, it allows ff7 to make a little bit of frame-skipping) and most of the other modules. The rebuilt framelimiter (really simple one) works fine, although it didn't get much of testing
The function that seems to deal with the frame limiter is 6384E6.
The better news is that the world map limiter seems to work - so maybe can do a comparison? The world map limiter is at 74C7E4.
-
Ok I'm getting somewhere now. The frame limiter above is probably not broken. It basically keeps the game in a loop until a number of ticks has been satisfied. It's very simple to reprogram despite how ridiculous the code looks above.
Unfortunately, that's not where the issue lies. At least, not how I thought. I am going to cook something up later!
-
Like I PMed you, it's got to be based on TimeGetTime to be accurate. RDTSC is unusable on modern CPUs. Instead of looping until the ticks are done, it SHOULD be pre-rendering the next frame (unless that's what it's waiting on).
-
Good luck!
-
Like I PMed you, it's got to be based on TimeGetTime to be accurate. RDTSC is unusable on modern CPUs. Instead of looping until the ticks are done, it SHOULD be pre-rendering the next frame (unless that's what it's waiting on).
It's a silly system... it's not doing what a normal limiter does. It's keeping the game in a while loop for a period of ticks before letting it carry on. I've never seen something like that before. If it's simply incrementing ticks in that function, then that's also a weird way of doing it. When using TGT or QPC, there is no increment... it's done independently of the function. I should be able to quite easily fix this up with a TGT or even QPC. And it should work fine.
-
QPC is the "correct" way to go as TGT is OS clock dependent and QPC is more CPU cycles dependent. QPC is the more modern version of TSC and still has to be calibrated prior to use.
At best you'd want a timer with better than 16.6 ms resolution. TGT gets 1 ms precision at best and QPC is measured in μs.
Optimally there'd be a single timer thread in the background that's sending signals back to the draw thread to display what it has ready and begin processing the next frame. (V-Sync, anyone?) HOWEVER, since FFVII has THREE graphics modes (15, 30 and 60 fps) it can't rely on a fixed timer. It's always adjusting it when transitioning from one module to the next.
-
TGT doesn't have the same issue that the older method does - and I think the way they did this limiter was completely bollocks anyway. You're right that TGT is close to 1ms (when timebeginperiod(1) is called), but that should be good enough when your target rate is 30fps.
QPC has issues with older CPU but shouldn't with the massive majority out now.
QPC is already there at CFF8D8, so that's convenient (aali's driver prob adds that support).
-
The frame limiter is fixed - it will give a perfect 30 (or 60 in battle) recording or otherwise. The scroll, like at Wallmarket is also now great. And it should be v easy to export this to Steam and to all other problem areas.
8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-)
This is how you fix it:
StartQpc:= currentqpc;
DeltaQPC := StartQPC - LastQPC;
While (Deltaqpc + CurrentQPC) - startqpc < clocktarget do
begin
// do nothing. Effectively suspend play.
end;
LastQPC:= CurrentQPC;
The delta time was not being correctly factored in with the old process. Clocktarget is the number of Qpc ticks a second * 30, for field. It's saved at cff890.
-
Dude. Congrats. I know this has been bugging you for a long time.
-
Dude. Congrats. I know this has been bugging you for a long time.
Thanks man!
And yeah, it has!!!!
it's a definite improvement, as you'll see. Much smoother. Even the screen fades.
-
The frame limiter is fixed - it will give a perfect 30 (or 60 in battle) recording or otherwise. The scroll, like at Wallmarket is also now great. And it should be v easy to export this to Steam and to all other problem areas.
8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-) 8-)
This is how you fix it:
StartQpc:= currentqpc;
DeltaQPC := StartQPC - LastQPC;
While (Deltaqpc + CurrentQPC) - startqpc < clocktarget do
begin
// do nothing. Effectively suspend play.
end;
LastQPC:= CurrentQPC;
The delta time was not being correctly factored in with the old process. Clocktarget is the number of Qpc ticks a second * 30, for field. It's saved at cff890.
I have to ask (LOL) why isn't it using the Vsync event at all?
Swaping rendered buffers is what it is for. I'm pretty sure the PS1 version does that (I could be wrong though).
That would make it asynchronous. What they are doing is consuming lots of time with looping (software timing is very poor in accuracy). And trying synchronise timing.
Most of the time you create threads that handle different sets of event processing on the PC however it may have been old enough for the PC microsoft hadn't implemented threads (win32 / win95-98 era?).
Anyhow I digress, congratulations. Remember Square I don't believe did the porting and according to halkun they didn't have the released PS1 code as their base for the port.
Many of the PC bugs didn't exist in the PS1 (likely because on the PS1 they would have used the vsync event by setting a bit in an ISR then having an event loop check it and swap the frame buffer viewed and do the next image of the frame). Swaping the buffer frame likely would take micro seconds durring the vsync interval.
Unfortunately I doubt you can do this with how the constructed the PC version of the game without some major adjustment to the original code.
Cyb
-
Vsync does affect delta time (if enabled, of course)...and will limit the game if the limiter does not (so if your maximum refresh rate is 60, the best fps you will get is 60. But since no module (field etc) goes over that, most players are unaware of that limit).
In other words, if you had no code above at all, your refresh rate was 60, and vsync enabled... the whole game would run at 60 (meaning field, battle, world map would be incorrect speed without fixes... and the menu would be fine).
-
Anyone wanting to change texture placements on screen in chocobo minigame the function to search is call 0077A469
With that you can see the table address above it, which includes its ID and X Y pos.
-
For 1998 English game using latest Aali's driver, this is how:
#These 4 entries shift the field down (all layers).
640C77 = B8 E8 00 00 00
640FD4 = B8 E8 00 00 00
641397 = B8 E8 00 00 00
{Aali's latest driver}
10045A32 = BB E8 00 00 00
# offset screen Y by 16 pixels.
CFF1E4 = 10 00
#Shift cursor down 16 pixels.
CFF200 = F0 00
# offset FADE in/out Y by 16 pixels.
CFFAE0 = 10 00
That's not to say I am confident that this is complete. But a few testers would go a long way. It does look ok. But who knows? It's hard to tell!
The FMV isn't centred yet - but that shouldn't be much of a problem.
The Steam version of the game needs AF3DN.p patching. The memory addresses move, so here is the file address:
C6B2 = BB E8 00 00 00
-
That's awesome but is there any chance to shift the fields down in the 2012/Steam version ?
-
That's awesome but is there any chance to shift the fields down in the 2012/Steam version ?
It uses Aali's driver, so yeah, it's possible. But it means having to find the correct place in it (pretty easy) - like with Aali's 1998 driver. It is getting out of hand having to support Reunion for both, though. Esp since it's possible to just convert. But for now I'm willing to support both.
-
We'd be far better off if we had Aali's driver source.
This isn't fully tested, but it does look like it works (I assume this is gonna fail somewhere because I can't see why there is a calculation at all, if these values were meant to be 0 and 1 originally :P. I am testing that.)
It isn't ideal since the FMV will never work properly with a full screen - and some fields don't have enough data to satisfy the areas where the black bars go. But....
Basically... this is what to do:
{No field borders by DLPB
#Extend layer range
640C77 = B8 F0 00 00 00
640FD4 = B8 F0 00 00 00
641397 = B8 F0 00 00 00
10045A32 = BB F0 00 00 00
#cursor
CFF200 = 00 01
# Fade in/out
CFFAE8 = E0 01
#Stop screen resolution being changed to 448 - and force 480 in Aali's driver.
This isn't a problem since World map uses 480 regardless.
100483C7 = 90 90 90 90 90 90
1008f178 = E0 01
But here's the issue. These 2 floating point values have to be the following with field:
10085534 needs to be set to 0.93333
10085554 needs to be set to -0.066667
BUT the following with world map:
10085534 needs to be set to 1
10085554 needs to be set to 0
So the question is how to get the game to calculate 2 different values depending on WM/Field
Made more annoying by the fact Aali's driver is handling it.
The calculations are probably supposed to be this for field:
448 / 480 = 0.93333
and
-16 / 240 = -0.067
But these are becoming 480 / 480 = 1 at 100484CE
and 0 / 240 = 0 at 10048543.
Actually, the above is EXACTLY how it should be.
-
It seems opcode 28 - KAWAI is broken in PC game. As a consequence there are a number of errors - including:
1. Treasure chests do not return to the correct colour after collecting them. The shine effect is stupid regardless - to turn it off they set the shine to 2. So that brightens the object - to fix this they then use the same opcode to reset the colour after stopping shine. This is failing on treasure chests.
https://www.youtube.com/watch?v=6mEqB5_oUwE&t=54m10s Note that the chest colour change fails, so it stays bright.
2. Materia does not shine correctly.
I can't fix it.
Unless someone out there feels up to the task of reverse engineering that opcode - the best thing to do is to just remove all shine / colour change operations completely.
-
Can I share my frustration here too? This game has been out since 1998 and very very little appears to have been done to fix all these issues. That's a rather sorry indictment of the modding community - that some of this hasnt been tackled at all. Recently the music lock bug I had to fix for example. The level of attention this game has and the modders available really should have yielded far more fixes.
-
That's a pretty silly thing to say. We not under any obligation to fix *anything* in the game. Heck the only reason why the Wiki exists is because I got tired telling everyone to aggregate their findings in one spot. I decided to make a PDF with everything I could find... Then I put it all in the wiki when Qhimm set it up.
Sisyphus rolls his own boulder.
-
Never said anyone was under any obligation ;) I said it was a sorry indictment of the modding community - mostly that it seems to have the body but no head. But I do like the wiki. Needs more people adding to it really - but it's easier I just place what I know here for time being. I haven't got the skill to reverse engineer entire graphic based functions. But what I can do - I will :)
The priority from the beginning should have been to fix the biggest bugs in the game - and a lot of them still remain. I don't know if the graphic function for field Kawai 28 can be fixed. If I knew how, I'd certainly try. But there appears to be no information on its bugs or why it is bugged - for example.
-
As many of you will know, when the Highwind does a sharp turn (while holding Circle), you can see the edge of the sky / cloud texture. You can even see past the end of the viewable area. Since the graphics cannot support the sharper turn, the best way to fix this issue is to disable that operation entirely.
To Fix:
74F3B2 = 90 90 90 90 90 90
L1 and R1 can still be used for a full turn and do not affect the background.
-
I just added Otyugh encounter to the Ancient Forest on one of the maps. At first, the game just loaded the pyramids with error message. I knew there was nothing wrong with the code, so it had to be a bug. Checked Terrence's guide, and it turns out that you should never use a battle chance greater than 31 in the field encounter list. 32-64 are bugged because the signed number is not calculated correctly. You'll get weird effects, like the pyramid battle if you do.
So if you ever need a battle to have 50% + chance of being seen, use two encounter slots (same battle ID) with maximum value of 31 for each.
-
it turns out that you should never use a battle chance greater than 31 in the field encounter list. 32-64 are bugged because the signed number is not calculated correctly.
There are 5 examples of this glitch occurring in the Vanilla Game. The effect isn't that the battle will play out incorrectly, but rather, the battle check will cease to continue, and every formation placed after the formation with >31 enc rate will be ignored. This is why we will never encounter: (formation IDs are in dec)
mtcrl_4 - #505 2x Cokatolis (Mt. Corel Rollercoaster screen)
mtcrl_9 - #514 1x Bagnadrana (Mt. Corel Bridge)
mtnvl3 - #585 2x Sonic Speed (Mt. Nibel Bridge)
junsbd1 - #762 2x SOLDIER:2nd (Red Submarine Dock past barking dog)
junin2 - #945 2x SOLDIER:2nd (Outside press conference room, during escape).
I have written up on this glitch, along with several other similar glitches within the Bug Report section of my Enemy Formation Charts. (http://pastebin.com/raw/MUcyFwwi) Look in Section E - Final Notes, although I believe White Wind may have tracked them all in the bug tracker. It's still worth checking.
In regards to the battle with the pyramids, are you sure that you didn't have encounter "0" set with an encounter rate of >0? I've done it myself in the past, the likely culprit is when editing the four "special battle" slots.
One other thing worth mentioning for those that didn't know, the total encounter rate for all 6 "normal battle" slots must total 64, otherwise the game will just freeze as soon as you try to traverse on it.
-
Nah, definitely not. It was set to above 31 with correct ID.
-
I don't mean the Otyugh battle, i mean all of the slots which have a battle ID of 0 - does any of them have a probability that isn't 0?
-
you should never use a battle chance greater than 31 in the field encounter list. 32-64 are bugged because the signed number is not calculated correctly. You'll get weird effects, like the pyramid battle if you do.
I think you can "fix" this by changing 0x60B5FA to EA instead of FA. That changes the signed SAR to the unsigned SHR.
-
Ah, thanks for that!
-
I don't mean the Otyugh battle, i mean all of the slots which have a battle ID of 0 - does any of them have a probability that isn't 0?
No. I only added one battle to a slot further down. The code was correct. Once I changed it from 32 to 31 (and added 1 elsewhere), the pyramid battle did not show up and Otyugh did.
-
I needed to place "Delete Materia" opcode 5C (http://wiki.qhimm.com/view/FF7/Field/Script/Opcodes/5C_DMTRA) back into the game. The function is not there in the PC version. To fix, make Function 61EF43 do the following:
B9 C8 00 00 00 49 8B 1C 8D B4 04 DC 00 39 D8 75 10 C7 04 8D B4 04 DC 00 FF FF FF FF 4A 85 D2 74 04 85 C9 75 E0 C3
0: b9 c8 00 00 00 mov ecx,0xc8
5: 49 dec ecx
6: 8b 1c 8d b4 04 dc 00 mov ebx,DWORD PTR [ecx*4+0xdc04b4]
d: 39 d8 cmp eax,ebx
f: 75 10 jne 0x21
11: c7 04 8d b4 04 dc 00 mov DWORD PTR [ecx*4+0xdc04b4],0xffffffff
1c: 4a dec edx
1d: 85 d2 test edx,edx
1f: 74 04 je 0x25
21: 85 c9 test ecx,ecx
23: 75 e0 jne 0x5
25: c3 ret
You'll need to jump to a new area and add that.
This will check through all materias to see if the AP matches. If it does, it will then "delete" the materia by making the entry FF FF FF FF. It will decrease edx (the number of times to delete this materia).
-
Dziugo had a look into the Chocobo minigame, which has a problem. The problem is that Mountain and River chocobos are not behaving correctly for their abilities.
The long map has a water area - this should slow Yellow (Regular) and Green (Mountain) down.
The short map has a hill to climb (the spiral part) and a hill just before the finish line - this should slow Yellow (Regular) and Blue (River) down.
This is what's really happening:
Yellow (Regular): Being slowed down correctly.
Black (River / Mountain): Being unaffected correctly.
Gold (Ocean): Being unaffected correctly.
Green (Mountain): Being unaffected. This is incorrect behaviour, as it should be slowed down in the river area.
River: Being slowed down by both areas. This is incorrect behaviour, as it should be slowed down only on hills.
The area that sets the values is 7725E8. For some reason it deducts 1 from the chocobo type value, and then jumps to an area based on this. If the yellow chocobo is chosen, it will deduct 1 from 0 and end up with a massive value, but since the "ja" is unsigned, this is still OK. It will jump to mov word ptr [eax+00000086],0003.
The values for eax+00000086 are:
0: Black Chocobo, Gold Chocobo [Will not affect speed in either area]
1: Green Chocobo [Will not affect speed in either area]
2: Blue Chocobo [Will affect speed in both areas]
3: Yellow Chocobo [Will affect speed in both areas]
Values of 1 and 2 are not being correctly used at whatever area decides the speed of a chocobo. I think this *may* be at 774A5C, but I am unsure how it calculates things.
So to recap. Gold, Black and Yellow are working fine. Green and Blue are not. It isn't the values that are wrong (unless 1 and 2 should be some other value) - it's the part that uses these values in hard code.
-
I thought that it worked fine with the changes I sent you? I can't run the game, but it looks like this:
Long map bits:80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
Short map bits:80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 00 00 00 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
Values are in hex, let's only look at the lowest 2 bits of each byte. From what you say it looks like short map has 0x01 (hill) first and 0x02 (water) after that. Long map has only 0x02 (so water, looks good).
Now, the case is ok, it's just how it works. Values are:
0 (yellow): 0x03 (so 0x01 + 0x02, or more correctly 0x01 | 0x02)
1 (green hills-chocobo): 0x01
2 (blue water-chocobo): 0x02
3 (black water-hills-chocobo): 0x00
4 (gold all-wonders): 0x00
Those are handicap bits - if a bit is set, a chocobo will be affected by terrain with that bit set. We can clearly see, that setting 0x02 (so a water handicap bit) for a water chocobo is a big wtf.
And yes, the speed corrections are at 0x00774A5C, it just does a bitwise AND between chocobo handicap bits and terrain bits. So for a terrain 0x82 (water) and a blue chocobo (0x02) we get 0x02 (affected). Yellow chocobo with 0x03 will also get 0x02 (affected).
If the bit is set, it looks like the speed is reduced by "result / 4" (so 1/4 for hill bit and 2/4 for water bit). So, the fix I proposed was switching 0x01 and 0x02 in that case. If that doesn't work, you gotta debug it, since I can't run FF7 for now.
==========
I take no credit for that, that's based on ergonomy_joe's work.
Also, I looked at that NOPed part of the chocobo fix, it looks like what was missing is a lower right coordinate of some rectangle, but the drawing function disregards it anyway (only using left-top corner and width + height). So a proper fix wouldn't be noticable, I post it anyway.
Before:0076EC29 6BC0 18 IMUL EAX,EAX,18
0076EC2C 8B0D F010E700 MOV ECX,DWORD PTR DS:[E710F0]
0076EC32 0FBF9401 B8860100 MOVSX EDX,WORD PTR DS:[ECX+EAX+186B8]
After:0076EC29 6BC0 48 IMUL EAX,EAX,48
0076EC2C 0FBF90 6CB7E300 MOVSX EDX,WORD PTR DS:[EAX+E3B76C]
0076EC33 90 NOP
0076EC34 90 NOP
0076EC35 90 NOP
0076EC36 90 NOP
0076EC37 90 NOP
0076EC38 90 NOP
0076EC39 90 NOP
Patch:0076EC29: 6B C0 48 0F BF 90 6C B7 E3 00 90 90 90 90 90 90 90
I take no credit for that, that's based on ergonomy_joe's work
-
The problem above is that the actual data on the map is wrong (if you're values above are correct). Both maps have value 82... while only one map (long) has water. So both maps affect the water chocobo. If you see what I mean?
I'll edit the map data. That should do it.
-
Now I see it, I misread your post. You really should debug it before attempting any fixes, it might be that the part of the map is disabled or something like that. I never really bothered to check which is a hill and which isn't, just assumed that the map in the file is linear.
-
The issue is entirely the actual data. Starting 326D in chocobo.wat (found on chocobo.lgp), the list of values with 82 should be 81. If your list above is right, it seems that there is also a sequence of 00 as opposed to 80. Which is a bit strange?
Hmm and I think all those 01s at the start of the short map should be 02s (to stop river but not mountain)
It depends whether that "outer space" part at the end of short course is meant to stop river but not mountain. It isnt a water area... so I'd have to go hill.
-
It depends whether that "outer space" part at the end of short course is meant to stop river but not mountain. It isnt a water area... so I'd have to go hill.
Well, if you're into map editing then you should just disable handicap bits for that part, as it's neither water nor uphill (as downhills are in the other part of both tracks and they don't slow chocobos down).
Second thought: Actually, if you think of it - water chocobos are able to cross rivers and shallow waters, so places with no solid ground. It might be that the space was supposed to be that "not-that-solid" ground.
Third thought: How the chocobos behave on PSX? The maps were probably converted from some other format, there might be a difference.
Oh, and the highest bit (0x80) is supposed to mark some places on the map, as it's checked in the code, but dunno what. It's not connected with 0x01 & 0x02 though, so just don't change that bit and you should be fine.
-
I would say that the space area is meant for the black and golden Chocobo.
-
That's an interesting idea. Technically, if the slowing down would be done the way it is done now, given one blue and one green chocobo, one would be slowed down by 25% (the one affected by 0x01 bit) and the other by 50% (the one affected by 0x02 bit). Yellow chocobos would be slowed down by 75%.
-
The psx data does appear to be different. I don't think the "chocobo.dat" file is compressed - and its contents bear no resemblance to "chocobo.wat". I'd have to look at the PSX game and see if they fixed this error there already.
-
I had the same thought for a moment, technically space is not water, and maybe space was meant to favour Blacks and Golds only, or even just Golds only.
Like:
Blue's strength: Water.. Green's: Hills.. Black's: Water and Hills.. Gold: Water, Hills and Space.
Green is already a better choice than Blue overall for racing (more hills than water), and with space not being water, it'll be even more true.
So what will this mean from a player's pov..
Do I choose the short course? Nope, I have no Gold Chocobo yet. So, the long course where we have water.. but more hills than water..
So we'll end up always choosing the long course with a Green Chocobo. Then later, always the long course with a Black.
Then bingo I've got my Gold, it's finally become a thing to choose the short course.
I'm not saying it's especially a bad thing.
The only thing I find meh, is to unbalance even more Green/Blue, but the unbalance has more to do with both tracks being often hilly, and that's the original game.
-
I'd disagree with space for gold only because the black chocobo ridden by Joe is meant to be difficult to beat across all classes - and that would kill the competition. I'd say short is meant to be harder since you are being lazy.
-
I agree.
Here's what I come up with. It's balanced.
Each number represents the %age of handicap. For the best, we can assume that the handicap from a big hill = from water = from space (the only change is which colour(s) will be unaffected).
small Hill Gold&Black:0 Green:0 Blue:25 others:25
big Hill Gold&Black:0 Green:0 Blue:50 others:50
Water Gold&Black:0 Green:50 Blue:0 others:50
Water+smallH Gold&Black:0 Green:50 Blue:25 others:75
Space Gold&Black:0 Green:50 Blue:50 others:50
Space+smallH Gold&Black:0 Green:50 Blue:75 others:75
Big hills are the ones like in the spiral, in opposition to the slighter slopes.
-
I encountered an odd bug. When you have to sleep in Aerith house and are out to leave, but think “Hey, why not move before her door and do some run action? :-D” (and do this of course) Aerith will come out and surround you like a bee a flower, endlessly. I guess I blocked her point with Cloud. The script needs an alternative point if it is blocked.
-
That was fixed, I think. I'll recheck when I get time.
-
I am working on fixing quite a few things (for example Game Over and Credits are being limited to 60fps), but first I needed to document the module calls. I've got everything I need now, but I guess I should share...
Modules Main Jump at 40919E
ebp-10 Main loop
ebp-C Mouse
ebp-8 keyboard
ebp-18 Enter
ebp-14 (?)
ModuleEnterAddress Enter call at 666CDA
ModuleMainAddress Main call at 67DD8A
ENTER MAIN LOOP
NA MAIN 408FA6 NA
00 FIELD 60E0BD 60E5B7
01 BATTLE 41B300 41BAB3
02 WORLD 74BAF5 74BE49
03 NOT USED
04 MENU 6CD3B0 6CC623
05 G-BIKE 650310 650412
06 CHOCOBO 76D597 76DBD1
07
08
09 SUB 77D030 77DF72
0A COASTER 5E8D49 5E8E7E
0B
0C
0D SNOWBOARD 722C10 722CCF
0E NOT USED
0F
10 BAT MENU See 04 See 04
11 NOT USED
12
13 TITLE SCR See 04 See 04
14
15 NEW GAME See 00 See 00
16 SWIRL 40164E 4021E9
17 NOT USED
18
19 GAME OVER 406367 4064D7
1A CREDITS 7A776F 7A7A33
1B
1C
1E
1F
20 Same as 1F
21 Same as 1F
22
23
24
25
}
-
The "teleport bug" is fixed. I am not sure why exactly these bytes need to be reset to 0 - but they do. If they aren't the game is instructed (after a world map battle + jump to a field flag) to jump back to the previous field that is still in memory. Once these bytes are zeroed, the bug will go away.
More fixes made:
1. Sound effects are also terminated on battle game over.
2. field and battle vars that need zeroing to prevent issues are now zeroed (these include teleport bug, countdown timer in world map battles bug, and others).
-
I am currently fixing up the credit screen to look like it did on the PSX. Here are the differences:
1. Programming error on the part of the porting team. Text is traversing a distance 2x what it should be (because it's starting position is outside of 2 screen widths instead of 1). That's why there is a huge pause between each credit. Each text has its own starting X / Y and other data, which is part of a large table.
2. PSX black text is faster than the white text, but in the PC version, both texts are the same speed. This may explain 1. I can;t be sure yet, but perhaps the reason 1 is the way it is is because the black text, now running at same speed as the white, has been corrected to move 2x the distance so the timing works. I will check.
3. Text size is wrong. PSX appears to the eye to be 2x larger. This is because the text is being displayed at 320 * 240. This may prove to be a real pain in the arse to correct - and if I do, a lot of the table data will need correcting also to start the text X ending pos to be further left (or text will be chopped).
I really shouldn't give a shit about the credit screen, but it's been annoying me for years.
-
I've added a few that I have documented:
ENTER MAIN LOOP
NA MAIN 408FA6 NA
00 FIELD 60E0BD 60E5B7
01 BATTLE 41B300 41BAB3
02 WORLD 74BAF5 74BE49
03 NOT USED
04 MENU 6CD3B0 6CC623
05 G-BIKE 650310 650412
06 CHOCOBO 76D597 76DBD1
07 same as 0D
08 CONDOR 5F47B5 5F4A47
09 SUB 77D030 77DF72
0A COASTER 5E8D49 5E8E7E
0B CDCHANGE 404688 4047F6
0C WUTAI N/A N/A
0D SNOWBOARD 722C10 722CCF
0E NOT USED
0F Force battle? N/A N/A
10 BAT MENU See 04 See 04
11 NOT USED
12 End_Game N/A N/A
13 TITLE SCR See 04 See 04
14 Load Game N/A N/A
15 NEW GAME See 00 See 00
16 SWIRL 40164E 4021E9
17 NOT USED
18 Play Ending Movie
19 GAME OVER 406367 4064D7
1A OPCREDITS 7A776F 7A7A33
1B ENDCREDITS 7A776F 7A7A33
}
Past these values are nothing.
The Wutai event apparently has several sub events related to materia including:
-Stealing materia at the beginning of the quest
-Returning materia at the end of the quest
-Granting master materia
-Granting bahamut zero
-
Ah, cheers for that NFITC! ;) Very nice. Why nothing after 1B? I remember jumps to code exist, This code doesn't do anything?
Also, I've worked out where the porting team's mistake was. They assumed the bl;ack and white text was the same speed. When they came to port the game, they couldn't make the timing work because they were under this assumption. To compensate for their own mistake, they made the black text travserse 2x the distance. What they really needed to do was half the speed of white text.
As I have here:
99C57C = 02
99C58C = 02
99C538 = FE
99C540 = 02
99C548 = 02
99C550 = FE
99C584 = FE
99C594 = FE
I now have to alter all black text starting X / Y pos - so the timing again works. Some white text pos will also need fixing.
-
Ah, cheers for that NFITC! ;) Very nice. Why nothing after 1B? I remember jumps to code exist, This code doesn't do anything?
Jumps exist and they do things, but they're used by the Wutai event. The actual event driver variable (0xCBF9DC) has a max value of 1C, but is subtracted by 1 when the event is selected. If that subtracted value is greater than 1C it goes to a non-event. In practice, this never happens. Quite strange and I'm not really sure what the point of subtracting by 1 is. It's only ever dynamically assigned in three places: loading a game (including new game), exiting the main menu and changing CDs. That's only to redirect it back to the world map and the field. As a matter of fact, this might be the source of the Yuffie warp glitch. I can't confirm that right now, however.
-
I've seen this subtraction nonsense a lot actually. I'm thinking it may have been the compiler that did it. I know that when I look at my own code it often uses fancy tricks like that, usually for efficiency.
-
The warp glitch has been fixed by me actually for my dll. It's caused by some temp vars not being reset on game over - here:
{reset field vars to stop teleport bug}
mov dword ptr [$CFF594],$00
mov dword ptr [$CFFAB2],$00
mov dword ptr [$CC0B60],$00
mov dword ptr [$CFFC60],$00
They were a bitch to find and I had to use some nifty comparison trickery to isolate them.
3 of these contain addresses. If they aren't cleared on game over, then reloading to world map will not clear them either. After world map battle, it will use these to attempt to jump back to field. When cleared, the behaviour changes and will be correct. As far as I can see, these addresses are used for a simply "jump back to previous field" operation. And, as I noted, they take precedence over other jump field operations.
Other addresses need to be cleared to stop other bugs. For example, countdown timer being visible in world map battle after reloading game. World map / game over / load do not reset any of the vars. Only entering a field will. I've added these fixes too.
-
credit screen fix is going well, but I will have to hold off until I have got the original text in place from psx... since a lot of this is a manual changes to the table.
Anyway, here is how it works. Each text uses 16 bytes. Four texts to a corner means 64 bytes per fix. And, since there are 29 corners needing repair, that is 29 * 64 bytes in total (1856).
99B5E8 = C2 01 00 00 08 00 00 00 80 FF FF FF 08 00 00 00
99B5F8 = 02 01 00 00 00 00 00 00 03 01 00 00 00 00 00 00
99B608 = BB 00 00 00 94 FF FF FF BB 00 00 00 50 01 00 00
99B618 = 00 00 00 00 28 00 00 00 00 00 00 00 29 00 00 00
Red: Starting X of white text1 and black text 1
Orange: Ending X of white text1 and black text 1
Blue: Fixed Y of white text 1 and black text 1
Green: Starting Y of White text 2 and black text 2
Brown: Ending Y of white text 2 and black text 2
Purple: Fixed X of white text 2 and black text 2
When in the top right, black text 1 X pos dictates the timing. In this case, 80 FF FF FF (minus 127).
*** These are unused above as top right calculations do not need them. Two of the corners use these values, while discarding 4 others.
Yellow: Fixed X of of white text 1 and black text 1
Pink: Fixed Y of white text 2 and black text 2
In order to get the top right working properly, part of the calculation phase also needs amendment:
7A53FB = 90 90
7A554B = 90 90
Another 6 of these will be nopped to fix the other 3 corners.
-
NFITC1. Why does the World Map not use the main jump at 40919E when calling the menu. Everything else seems to use this no matter what.
-
It's a memory thing. If it changed modules it would have to unload itself before loading the menu THEN it would have to reload when the menu ends. That's too slow for the PSX (I guess) so the WM module sets the menu handlers and calls them itself at the bottom of its draw method.
-
But it doesn't have any problem doing it from field? It uses less memory than the WM?
-
That'd be my guess. If you destroy the WM you'd have to destroy it and recreate it each time you'd use the menu. That's a long enough task when transitioning to/from a field. I'd imagine the team wanted menu use to be less of a hassle and just made an internal menu event.
-
Why didn't they just overlay the menu on top for field? Surely that could have been done since the menu is next to no memory? Or perhaps because people worked on different modules, they just didn't have time to make that idea fly.
n other news, I managed to create a way to jump to any module instantly. I am using it to jump back to the credit screen with a master reset. Aali's driver is interfering with screen height / width (it uses field version, which I've altered), but it's fixable. Master reset seems to work fine.
It's initiated by certain addresses being placed at certain addresses. It then uses
CC0D84 = 26
CBF9DC = 27
To decide what to do. The above is "Jump to Credit screen". CBF9DC is the main identifier.
-
Sorry to butt in; I searched the bug tracker database for bugin1c but couldn't see this issue there.
I'm trying to fix the problems in the Observatory scene; I've got the character placements done using offset object, but the sound is a problem. There's supposed to be 4 sound effects played in tandem using AKAO 35 but only the fourth one plays. After some testing, I found that other sound effects will behave correctly with this and play all at once but these four won't.
AKAO: 35? (param1=64, param2=110, param3=111, param4=112, param5=113)
So it seems to be something to do with these particular sound files themselves and how they're handled. I saw in Dan's notes that there's code to determine if sound files loop or not, is there maybe some kind of override that might be causing these sounds to not play together?
-
It could also be broken in original pc / aali's driver. Since you have to remember field script is only script... it's the sound functions that do the work. And they are definitely broken in some areas. You'll likely find that my dll fixes the issue you have. There is a condition to allow up to 4 sounds to play together using AKAO function. I didn't know that field did it, but battle does - some Summons use 3 sound effects together.
The bugin visual bug is known and has been fixed with Reunion by Spy__Dragon. But this is the first time I have heard of the sound issue.
I should note, actually: Aali doesn't do anything with the sound effects that I've seen. So all the original errors with PC version are there. With music, he took over the midi functions - but, by that time, the music is already broken. Which is why certain functions like tempo, fade do not work properly. I've rewritten akao and other sound functions from scratch and fed them to bass.dll. This fixes all the issues.
-
I'll check out your bass.dll; thanks for the info.
-
It isn't released yet. Soon :) bass.dll allows for dsound operation and isn't made by me. My dll project is called ff7ddraw / ff8ddraw. But obviously that will go in the game root as ddraw.dll. Same thing for FF8.
-
Updated akao documentation. This should be 100% correct now.
http://wiki.qhimm.com/view/FF7/Field/Script/Opcodes/F2_AKAO
Notes:
PC specific problems:
1. All tempo functions do not exist in original PC version. Steam added operation 0xD0 back in, but it does not have pitch correction.
2. Operation 0x30 cannot be stopped by using an effect on channel 4 like it should. 0x30 is supposed to work on channel 4.
3. Operation 0x20 to 0x23 are apparently broken.
4. Operation 0xC2 does not exist.
I have fixed these issues with my dll.
PSX issues:
Operation 0x10/0x14 and 0x18/0x19 do not seem to work. I think they have been intentionally disabled to force script programmers into using Opcode 0xF0 : http://wiki.qhimm.com/view/FF7/Field/Script/Opcodes/F0_MUSIC
No such limitation exists on the PC version. F0 calls akao Operation 0x10 anyway, so I am not sure why akao operation 0x10/14 has been disabled on the PSX version. Perhaps the design team wanted to keep it consistent.
It may also be that I don't understand how the PSX version handles music.
-
PC port used an older version of the source. They didn't have very good versioning control software back then, unless you count backup tapes.
-
I am looking at assembly to learn more about the field and how it is coded (especially regarding script calls). I will note any findings. So far, it should be noted that
a. 16 models (Model ID 0-15) are supported per field. Any more than that will cause a crash, due to overflow of data.
b. 48 Groups are supported, with Group ID of 0-47. If you exceed this, the field will crash. It certainly does if using a Wait operation on Group 48 (the 49th group), since this overflows and uses the address CC0960 (which is critical for running the field module).
The field does not do checks to make sure that unsupported groups and models are not used. As stated, it will crash.
About the Wait operation (Opcode 0x24). Each Group has an instruction executed, one to the next (usually) . Because each group can be executing, at most, one Wait operation, each group must have its own 2 byte storage address for the delay remaining (in frames). These start at CC0900. If the delay is still in progress, Wait is called, the counter is deducted, and the instruction will only move on to the next instruction (when its turn comes around again) when the delay is 0. For some reason, the Wait function [9055a0 + (4 * 24)] checks for both a remaining delay of 0 and 1 and does different things on both.
-
Normal field operations.
The maximum number of field operations per group is 8 a frame, as long as the instruction is not told to wait (for example, some Move operations must complete before the next instruction is allowed to execute, like an NPC walking from A to B.).
8 field operations that have no delay (i.e., the instruction doesn't have to wait for something like a Move operation to complete) will execute for one group, each frame, where possible. This is not affected by how many total groups there are. This means that each group will execute 30 * 8 instructions a second at a maximum (240), meaning 48 * 240 (11520) instructions a second, at the most, for all groups. Each group is given control, one to the next, starting at ID 0. If it has already reached a return, the return will simply be executed on the group's every turn from that point on. All groups are therefore given control once a frame, whether they end up doing 8 instructions or 1. There will always be at least one instruction per group, each frame, even if it's the final return of group's Main. A return is therefore seen by the engine as nothing more than a "no operation - go to next group".
If the instruction is waiting for an action to complete, it is still executed again, but the opcode's function (in the exe) works out what to do. Only when the function itself is satisfied that the operation has been completed will it mark the instruction as completed. It does this simply by advancing the script's progress by a number of bytes (the number of bytes that the opcode + arguments required).
Jumps: When a jump backwards instruction is executed, the current group is skipped and the next group is automatically given its turn. For example, if you have 8 instructions in Group 0, but the 4th one is a jump backwards, it will execute the 4th instruction for that frame, move to the next group (Group 1), and only continue with the 5th instruction for Group 0 on the next frame. There are other instructions that also have this effect.
Init and Main both have their own functions to execute instructions in field. Inits of all groups are executed once (when you enter a field), starting from Group ID 0, at 0060C78D. Placing instructions here that require a delay will also cause a delay in the field loading (which is why these types of instructions should be avoided in the init sections). Using loops inside an init section will hang the field indefinitely. Unlike the Main function, Init will execute all instructions of a group's init section before moving to the next group. In other words, it doesn't execute 8 instructions a frame, then move to the next group. Assuming it is still executing 8 instructions a frame in total, this does mean that a very large list of instructions in the init section will also cause a delay in the field opening (240 instructions would be 1 second delay - IF the Init function is working like Main in terms of execution time). This many total instructions for the groups' inits is very unlikely to happen (and the original game didn't come close to it), so it's not a worry regardless. I'd like to think that Init executes as fast as your processor will allow. It very likely does.
Main's function is at 0060CDAE.
Instruction Progress
Each of the 48 groups must keep their current instruction location saved, so that when focus moves to other groups and returns, the game can continue where it left off. Each group is assigned a 2 byte value to store the instruction offset, starting at 00CC0CF8. The first instruction will not be at value 0 (byte 0), because the instruction progress value includes the offset to the actual instruction list, which begins after other data (such as the field header). The current group's instruction progress value is retrieved at 60CD98.
mov dl,[ecx+eax]
Where ecx is the address of the field data itself, eax is the offset to the instructions of the field from that address (The instruction progress value), and dl is the opcode retrieved (FF7 field only has one byte opcodes) from that location. The asm code there is a little dumb(?), but that's probably because optimization was turned off for the executable:
xor edx,edx
mov dl,[ecx+eax]
and edx,000000FF <<< redundant.
The parameters for the operations are retrieved from inside the opcode's function itself (which is easy, since it's just the addresses after the opcode) . For example, the 8 bit jump forward opcode (0x10) retrieves the one-byte jump value at 61311B.
Because the instruction progress value is only 2 bytes, there is a limit to how big a field script can be. Even if the headers and other data were discounted, the limit would still be 65535 bytes for ALL instruction data (for all groups). As it is, it seems to me that 65535 bytes is actually the maximum size an uncompressed field DATA section can be (not to be confused with the uncompressed field size total), and so the number of operations available per field is even more limited. It's pretty difficult to exhaust this limit, even with 48 large groups. Even 100 addition (arithmetic) operations, for 48 groups (5 * 100 * 48 [24000] bytes of data) is not a problem. The game will crash / behave incorrectly if it is not able to properly advance the instruction progress value, as it just did when I deliberately added 5 * 1000 * 48 (240000 bytes) of addition operations.
Execute a Script (Async Wait, Async NoWait, Sync Wait, Priority)
This is probably the most confusing part of field programming for modders. That's because no-one has really written anything about how the engine actually deals with these functions.
Regardless of whether a script is called or not, the field engine still loops from ID 0 to the last ID. If a script has been called for, say, ID 6, then ID 6 will try to execute 8 instructions from that script. This mean that its MAIN script is superseded. So, the following:
Execute script #2 in external group Untitled (No6) (priority 1/6) - Only if the script is not already running
means that Group 6 (ID 6) will begin running through its Script 2 list of instructions INSTEAD OF its Main instructions when ID 6 gets its turn (remember, each ID/Group gets one turn every frame). Once all the instructions in Script 2 have been completed, it automatically switches back to its own Main. This is a difficult thing to explain with words, so, at a later time, I will make a video.
The 'Execute a Script' instruction has 3 modes:
Sync Wait, Async Wait, Async No Wait.
Sync Wait:
Execute script #2 in group Untitled (No6) (priority 1/6) - Waiting for end of execution to continue
Each loop (each frame) will execute up to 8 instructions in ID 6. Until this is done, the calling script (for example, ID 0 > Main) will not continue when it gets its turn.
Async Wait:
Execute script #2 in external group Untitled (No6) (priority 1/6)
Each loop (each frame) will execute up to 8 instructions in ID 6. If ID 6 is already busy running through one of its scripts from a previous 'Execute a Script' instruction, the calling script (for example, ID 0 > Main) will not continue when it gets its turn. So, this instruction differs with Sync Wait only because it will wait if an ID is busy running through a called script, and not wait otherwise. This means that Async Wait, like Sync Wait, is guaranteed to eventually run.
Async No Wait:
Execute script #2 in external group Untitled (No6) (priority 1/6) - Only if the script is not already running
This is the same as Async Wait, except... it doesn't wait. The next instruction (of the script that is calling the 'Execute a Script' instruction) will always be executed as soon as possible. If the request for ID 6 (in my example) to run through Script 2 cannot be granted, it will never be initiated. This instruction should only be used when you require a script to be skipped if already running.
Some things to consider:
- If a target ID's script is looped / does not end, Async Wait and Sync Wait will cause the calling ID's execution to be put on hold permanently.
- If an ID has one of its scripts (Script 0-31) looped / unable to complete, all calls to execute any of its other scripts from any other location will fail. An ID can only have one of its scripts (Script 0-31) executing at a time.
- Every time an ID has one it its scripts (Script 0-31) executing, it will be in place of its Main script (Script 0). Only when all script call operations are completed will the Main script resume for that ID.
The game queues any scripts to be run at 612B5F
mov [ecx+eax*8+00CBF9E8],dl
Where ecx is the priority (0-6), eax is the ID (0-47), and dl is the script (0-31) that has been told to execute. This means that each ID can queue up to 7 "Execute a Script" instructions. Priorities are, basically, queued scripts to be run - with a priority order. Although parts of the engine support 0-7 queued items, only 0-6 will work. If priority 7 is called, it will be completely ignored.
Note: Calling Script 0 of an ID is supported, but it will be the "init" part of Script 0 (since it always ends with a return). It is not recommended nor essential to ever do this.
-
Finally, 8 instructions a frame per Group can be increased at 0060CD77. A modern CPU can easily do 256 instructions a frame for each group. This would only have side effects where a. math counters have been used (if they have), compared to using Wait. and b. Where the script programmer perhaps wanted the slight delay in computation. Although, I am doubtful this is ever the case. The benefits may be things like better controller response during "Has X been pushed", and no frame delays at all when executing instructions that place objects. Sync between instructions from different groups would also be improved. I can't see increasing it being a problem for the most part... but maybe someone would like to test :P
And whether a function will cause the group to be skipped (like Move [until completed] and Jump Back do) depends on the return value from the opcode function at 0060CDAE.
0 = Do not skip current Group. Execute next instruction.
1 = Skip current group by going to next group.
This is, of course, hard coded for each function.
The Wait function, for example, simply returns 1 until the frames-to-wait counter reaches 0, when it will return 0 and increment the script progress value for the Group.
-
So, as my SFX mod finally nears a close - here are the unused IDs from the original PSX game (PC game differs slightly due to error. I have fixed this by using the correct SFX in the correct place.) My dll won't allow you to use these IDs at all - so you'll have to use 751 - 65535 if you want to add more SFX / voice acting. There's plenty there, no?
000, 199, 210, 476, 477, 488, 524, 575, 576, 580, 618, 732 - 750.
PC differs as follows:
1. Effect 731 does not exist. This is part of Sepher Sephiroth's death. In the PC version, this isn't heard (it's the disintegrating part) It may have been missed because it starts with a long silence. Perhaps the sound programmer for the port thought it was a silent file.
2. The Kefka laugh in the Ghost Hotel is not looped.
-
740-743 are called, as it turns out. The PSX version uses some of the other effects to create some variations for this attack. Since PC can only use streamed data, the porting team have created the 4 effects as streamed files. Clever of them to realize.
edit.
Nope. They weren't clever. They just couldn't get this part working right so created these 4 effects to do the job that existing effects already do when called right.
-
I am not the original person who wanted you to start a tut, but I would be ever grateful if you did.
-
that is fine, I already found a work around for that.