https://temp.ufopaedia.org/api.php?action=feedcontributions&feedformat=atom&user=J%27ordos 2026-05-01T10:15:51Z User contributions MediaWiki 1.43.6 https://temp.ufopaedia.org/index.php?title=Air_Taxi_(Apocalypse)&diff=59788 2014-10-01T21:33:59Z

<p>J&#039;ordos: commanders travel in airtaxis</p> <hr /> <div>[[Image:Apoc_airtaxi_pedia.png|Airtaxi UFOPedia picture|right|100 px]]<br /> &lt;br clear=&quot;all&quot;&gt;<br /> == General Information == <br /> [[Image:Apoc_airtaxi_icon.png|left|50 px|]]<br /> '''''Official Entry:''''' &quot;The wealthy citizen would not normally travel by [[People Tube (Apocalypse)|people-tube]] or road, but instead hire the services of a fast and reliable Airtaxi. The styling is conspicuously based on the more humble road going version, but the ride is more refined. Expect the occasional Airtaxi you see to contain a VIP, or flamboyant [[Sensovision]] celebrity.&quot;<br /> <br /> == [[Cityscape (Apocalypse)|Cityscape]] Information == <br /> An automated airborne taxi, although a person aboard is required by city regulations for the personal contact factor. Celebrities are the most noticable user of air taxi services, making a flashy entrance to many occasions.<br /> <br /> Newly-hired X-com personnel don't use Air Taxis, presumably since they're too expensive. They will travel in [[Autotaxi_(Apocalypse)|Autotaxis]] instead. This privilege is reserved for the agent with the rank of commander. When you transfer him he will be carried away in an airtaxi instead.<br /> <br /> ==Statistics==<br /> <br /> &lt;table {{StdCenterTable}}&gt;<br /> &lt;tr {{StdDescTable_Heading}}&gt;&lt;th align=&quot;left&quot;&gt;Statistics&lt;/th&gt;<br /> &lt;th&gt;Value&lt;/th&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Armor&lt;/td&gt;&lt;td&gt;0&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Weight&lt;/td&gt;&lt;td&gt;600&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Constitution&lt;/td&gt;&lt;td&gt;25&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Engine&lt;/td&gt;&lt;td&gt;[[SD Deluxe (Apocalypse)|SD Deluxe]]&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Engine Size&lt;/td&gt;&lt;td&gt;2x2&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Top Speed&lt;/td&gt;&lt;td&gt;11&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Cost&lt;/td&gt;&lt;td&gt;6000&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Manufacturer*&lt;/td&gt;&lt;td&gt;[[Transtellar]]&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Passengers&lt;/td&gt;&lt;td&gt;4&lt;/td&gt;&lt;/tr&gt;<br /> &lt;tr&gt;&lt;td align=&quot;left&quot;&gt;Score points&lt;/td&gt;&lt;td&gt;10&lt;/td&gt;&lt;/tr&gt;<br /> &lt;/table&gt;&lt;br /&gt;<br /> <br /> * This vehicle cannot be normally purchased by X-COM.<br /> <br /> &lt;br clear=&quot;all&quot;&gt;<br /> <br /> {{Vehicles (Apocalypse) Navbar}}<br /> <br /> [[Category:Mega-Primus Craft (Apocalypse)]]</div>

J'ordos https://temp.ufopaedia.org/index.php?title=Sentient_Engine_Liberation_Front&diff=28202 2010-05-26T15:32:00Z

<p>J&#039;ordos: no infiltration for these guys</p> <hr /> <div>[[Image:Apoc_self_pedia.png|S.E.L.F. UFOPedia picture|right|100 px]]<br /> <br /> == General Information == <br /> [[Image:Apoc_self_icon.png|left|50 px|]]<br /> '''''Official Entry:''''' &quot;The city edict of 2076 effectively banished Androids from most areas of city life. They were forced into slum areas and treated as little more than vermin. They considered themselves to be artificial life forms of equal intellect to human beings and decided to fight back. S.E.L.F. is an organization dedicated to fight for equality for all sentient life forms, whether flesh or machine. Their activity has been limited to pressure group politics, but there are demands within their ranks to resort to more direct, violent action.&quot;<br /> <br /> == [[Cityscape (Apocalypse)|Cityscape]] Information == <br /> Non-hostile relations with S.E.L.F. will allow more android recruits to appear for hire. This organization cannot be infiltrated by the Aliens.<br /> <br /> === Buildings Owned ===<br /> * [[Offices (Apocalypse)|Offices]]<br /> * [[Slums (Apocalypse)|Slums]]<br /> <br /> === Initial Attitude ===<br /> <br /> ==== Friendly/Allied To====<br /> * [[Image:Apoc_mutant.png]] [[Mutant Alliance]]<br /> <br /> ==== Unfriendly/Hostile To====<br /> * [[Image:Apoc_govt.png]] [[Government]]<br /> * [[Image:Apoc_megapol.png]] [[Megapol]]<br /> <br /> ==See Also==<br /> *[[Organizations]]<br /> *[[Relations (Apocalypse)|Relations]]<br /> <br /> &lt;br clear=&quot;all&quot;&gt;<br /> <br /> {{Organizations Navbar}}<br /> <br /> [[Category: Organizations]]</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Xusilak&diff=28161 2010-05-12T01:45:31Z

<p>J&#039;ordos: no problem</p> <hr /> <div>Feel free to discuss anything related to my projects here! --[[User:Xusilak|Xusilak]] 15:42, 24 March 2010 (EDT)<br /> ----<br /> <br /> == I'm smiling for a reason. ==<br /> <br /> TSIA ;) - [[User:Amphibious Tentaculat|Amphibious Tentaculat]] 18:45, 24 March 2010 (EDT)<br /> <br /> == Potential Projects ==<br /> <br /> Good set of potential projects, I like! [[User:Spike|Spike]] 19:28, 24 March 2010 (EDT)<br /> <br /> Especially looking forward to the TFTD patches! By the way, xcomutil already allows you to set the difficulty value to any number you wish. [[User:J'ordos|J&amp;#39;ordos]] 08:40, 2 April 2010 (EDT)<br /> :Interesting; I didn't know that. However, my experiments with high difficulty levels showed that exceeding the defaults will break certain aspects of the game, like spawning arbitrary numbers of aliens in missions. My primary goal there is to make those difficulty levels fully functional, with expected results for spawn numbers, capping overflows, and so on. My secondary goal is to make it easier to use those difficulty levels by adding the Advanced Difficulty configuration to the main difficulty screen. Thanks for the tip, though.<br /> :As for TFTD, I have a few usable patches implemented already, but I think I'll leave it up to Seb to compile and release it with his current patcher, if he wants to. Seb, if you happen to see this, let me know how you feel about the TFTD patches I'm working on. I'd prefer if you compile and release it alongside the X-COM patcher, to ensure compatibility, as I use VS2010 RC for developing right now. Either way, it'll be a while before that happens, as I'm working on testing and adding more functionality. Thanks! --[[User:Xusilak|Xusilak]] 13:18, 2 April 2010 (EDT)<br /> ::I do not work on TFTD mainly for 2 reasons: first, I don't play it; second, redoing the same things all over again is not that much interesting to me. If you want to make it happen though, I'll gladly take the opportunity to make that available for everyone in the loader. Also if you need some help analysing some bits of asm don't hesitate to ask; I'll help if I can. Good luck and have fun! [[User:Seb76|Seb76]] 15:46, 2 April 2010 (EDT)<br /> :::OK, that's fine. I don't know how much work I'll get done on TFTD, but I do want to get it to the point where all of the basic UI upgrades are done. Since you're not interested in working on it, I may just release it independently as a separate project on my own user page here, if you don't mind. That way it won't interfere with your other work. I will credit you as the main developer of it, of course, and continue to contribute original X-COM patches to UFOExtender as I develop them. --[[User:Xusilak|Xusilak]] 17:33, 2 April 2010 (EDT)<br /> :::Also, for clarity, I'll provide the source code for the TFTD patcher when I start releasing them. --[[User:Xusilak|Xusilak]] 17:38, 2 April 2010 (EDT)<br /> <br /> == TFTD Database ==<br /> <br /> Maybe you could publish the TFTD patch database on this site, as it evolves. Initially it will have a lot of gaps, but if you publish the gaps people will know what to look for. You will probably get volunteers who will hunt down the patches for the things that they are particularly interested in. The work will go faster with collaboration. [[User:Spike|Spike]] 05:19, 3 April 2010 (EDT)<br /> :For now, I think it will go faster if I focus on it. I'm already about 40% done naming the variables and functions that are already known from X-COM, thanks to Seb. Once I've gotten that bit done (should be within a week or so) and gotten the patcher itself to a useful state, I'll go ahead and publish both the IDA database and the patcher source code here. --[[User:Xusilak|Xusilak]] 11:24, 3 April 2010 (EDT)<br /> Any reason why IDA crashes when I load the .idc file? It says: Attempt to call a database related function without a database. Do I need a plugin? Using v5.2 [[User:J'ordos|J&amp;#39;ordos]] 17:23, 28 April 2010 (EDT)<br /> :never mind just realized I need to add this over the disassembled file, right? [[User:J'ordos|J&amp;#39;ordos]] 17:26, 28 April 2010 (EDT)<br /> ::Yep. Disassemble the TFTD CE exe, then load the IDC on top of it. --[[User:Xusilak|Xusilak]] 19:09, 28 April 2010 (EDT)<br /> <br /> Hi Xusilak, Where can I get ready version of your TFTD mod? I don't know how .idc file in .exe file. Whether can to get ready version for so illiterate users such me? ))<br /> :The IDC file is a database you can use with the IDA pro disassembler. There is no way to turn it in a program like seb's loader. You will have to wait until Xusilak finishes that. On that note, how is progress Xusilak? :) [[User:J'ordos|J&amp;#39;ordos]] 17:01, 8 May 2010 (EDT)<br /> ::I'll have to apologize. I've had a combination of sickness and other things coming up lately that have kept me from working on it as much as I'd like. The current progress is largely still as is listed on my page. Sorry for the long delay. If I can't get more patches translated for it soon, I'll go ahead and just polish it up and release it in its current form, then work on it as I have the time. --[[User:Xusilak|Xusilak]] 18:30, 9 May 2010 (EDT)<br /> :::I'm already happy knowing you're still working on it! [[User:J'ordos|J&amp;#39;ordos]] 21:45, 11 May 2010 (EDT)<br /> <br /> == KeeperFX ==<br /> <br /> Hello, first of all, i would like to say that you guys (you and Seb) are doing great job :)<br /> <br /> I've found some project for Dungeon Keeper, which can be considered similar to what you're doing, but it's done quite different way (i believe). If i understand correctly, you're somehow altering x-com code in memory after launching it? Author of keeperfx is doing it such way (qoute from website):<br /> <br /> http://keeper.lubie.org/html/dk_keeperfx.php<br /> <br /> ''Instead, I've learned binary formats of EXE and DLL files, and modified the Dungeon Keeper executable file to become a DLL. With my new DLL, I was able to create very simple executable file which may be used as complete code to run the game. Now I'm incrementally rewriting DK; functions which are not yet rewritten are called from the DLL, so the project functions like whole game, even tho it wasn't completely rewritten yet.''<br /> <br /> Here's instruction how to change exe to dll: http://keeper.lubie.org/other_docs/change_exe_to_dll.htm<br /> <br /> I wonder if such way could be useful (and possible) for x-com (tftd) extender? Would it be easier to add new things? Would it allow to gradually rewrite whole game from scratch? What do you think? --[[User:Michal|Michal]] 13:11, 13 April 2010 (EDT)<br /> :Interesting idea. Thanks for mentioning that. What we're doing now is similar, but essentially the inverse of this. We're using DLL injection to replace X-COM functions and code at run-time. So, we have the game using its normal EXE and the patcher using a DLL. His method is focused specifically on rewriting the game, but in an incremental way that doesn't require him to go for years without seeing any results. That method would be very poor for doing the kind of patching we're doing now, because we'd have to rewrite all of the core loop code in X-COM before we could get to a point where we could start implementing our new functionality. This is because the replacement game EXE can't simply inject functions at certain points in the original game DLL's function calls, at least not without doing what we do now (patching memory directly). In the end, there's no particular benefit to doing small patches through that EXE-based method. It would be an advantage if we were trying to rewrite the game entirely, with an emphasis on rewriting the core code and working our way up, but that's not what we're doing; if we did want to do that, it could be done through the DLL injection method painlessly, and then converted to its own EXE once we finished rewriting the game. It is unlikely that we'll try to rewrite the game, however, because it would be an extremely lengthy and arduous task; if I were doing it alone, it would take years. Our current technique of simply extending X-COM's existing code produces much more immediate and beneficial results.<br /> :Thanks again for posting a link to this, though. It might be useful to me in the future. --[[User:Xusilak|Xusilak]] 19:33, 13 April 2010 (EDT)<br /> <br /> ==X-COM bugs that TFTD inherits==<br /> Since I'm going to be translating patches from X-COM to TFTD now, I could use some information on which bugs need to be fixed in TFTD that existed in X-COM. If anyone has such information, I'd greatly appreciate it, as it would save me the effort of testing each bug. In particular, a list of which of Seb's bug-fix patches could still usefully apply to TFTD would be awesome. Note that I don't need information on TFTD-specific bugs, just bugs that TFTD inherits from X-COM. Thanks in advance! --[[User:Xusilak|Xusilak]] 20:20, 15 April 2010 (EDT)<br /> :Scroll speed in tactical mode is reduced. It is too fast for certain hardware configurations <br /> :Phantom radar bug fixed. Radar coverage is updated when facilities are destructed <br /> :Pay for dirt bug removed. The cause was a funny one ^_^ <br /> :If you're tired of having to reselect your TU reserve mode at the begining of each turn, then the &quot;Save Reserve Mode&quot; patch is for you :) <br /> :Base disjoint bug <br /> :Radar stacking enabled. Credits go to Spike for I used something close to his formula. <br /> :Vertical waypoints blaster bomb bug <br /> :Garbled video output due to ignored pitch <br /> :Problem with last salvo during dogfights. The ship won't retreat when running out of ammo, allowing the last salvo to hit. Not the perfect solution, but you may still find this useful.<br /> :Armed state issues with proximity grenades when reloading a game. Should also fix &quot;What just exploded?&quot;<br /> :Experience issue with proximity grenades. The thrower now gets the experience, not the poor alien that blows up... <br /> :Refueling issue when transfered crafts arrive (enabled by default if you use the &quot;Crafts Always Ready&quot; mod) <br /> :Elerium fueled crafts bug when fuel level is 50% <br /> :Displayed Base Maintenance Cost Bug <br /> :Door jam <br /> :Robotic Manufacturing / Cybernetic Laboratories. You cannot get more than 255 engineers/scientists, buying more will just result in them being lost during transfer... <br /> :Funky fire fix: Fire/stun damage applied only at the end of the turn. Maximum fire damage increased from 5 to 10 to compensate <br /> :Hostile Civilians fix. Not really tested, may fix some mind control abuses. <br /> :Animations Speed: Reduce the animation speed of cursors and smoke/fire. <br /> :Almost all bugs were transferred over AFAIK :) can't remember if the game did remember the TU reserve mode though. [[User:J'ordos|J&amp;#39;ordos]] 10:22, 20 April 2010 (EDT)<br /> ::Thanks! I really appreciate this list; it should save me a good deal of time. Hopefully I'll be able to get most of them fixed by the end of the month. --[[User:Xusilak|Xusilak]] 13:14, 20 April 2010 (EDT)<br /> <br /> == FORMULES ABOUT FLOATING BASE ATTACK MISSION ==<br /> <br /> Hi, Xusilak<br /> <br /> Firstly, I Am so-so so sorry that I reverted your file acidentally. I don't know English good, pressed acidentally and 'llnot know undo it.<br /> I am sorry for disturbance<br /> I informed that you are great specialist in TFTD executable.<br /> My great respect for you for work, which you are doing.<br /> <br /> At discussion file Missions.dat (XCOM-EU) Seb 76 posted this formules: After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours ). A retaliation mission will be scheduled if RAND()*100 &lt; 4*(24-difficultyLevel). <br /> If RAND()*100 &lt; (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.<br /> <br /> At first, Formule 2 and 3 probably contins mistake. formule 'll have to have symbol &gt; instead symbol &lt;. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange. <br /> I ask generously to you to check this 3 formules in TFTD. Is these same or not? and would check indicated me probably mistake.<br /> <br /> Thank you for this help very great<br /> <br /> == Research tree in executable ==<br /> <br /> Do you know location (starting offset) of research tree in TFTD? and how much entries it contains ? how much rows it contains?<br /> <br /> Or at least where are located requirements for technologies? (for example - vibro blade, aqua plastics)<br /> <br /> == Terror ship route and alien artefact site ==<br /> <br /> Maybe do you know where locate offset responsible for probability of appearing at 1-st day of month these events?<br /> <br /> If you would be know it, I didn't know how I could thank you for so valuable help to me</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Xusilak&diff=28155 2010-05-08T21:01:14Z

<p>J&#039;ordos: /* TFTD Database */</p> <hr /> <div>Feel free to discuss anything related to my projects here! --[[User:Xusilak|Xusilak]] 15:42, 24 March 2010 (EDT)<br /> ----<br /> <br /> == I'm smiling for a reason. ==<br /> <br /> TSIA ;) - [[User:Amphibious Tentaculat|Amphibious Tentaculat]] 18:45, 24 March 2010 (EDT)<br /> <br /> == Potential Projects ==<br /> <br /> Good set of potential projects, I like! [[User:Spike|Spike]] 19:28, 24 March 2010 (EDT)<br /> <br /> Especially looking forward to the TFTD patches! By the way, xcomutil already allows you to set the difficulty value to any number you wish. [[User:J'ordos|J&amp;#39;ordos]] 08:40, 2 April 2010 (EDT)<br /> :Interesting; I didn't know that. However, my experiments with high difficulty levels showed that exceeding the defaults will break certain aspects of the game, like spawning arbitrary numbers of aliens in missions. My primary goal there is to make those difficulty levels fully functional, with expected results for spawn numbers, capping overflows, and so on. My secondary goal is to make it easier to use those difficulty levels by adding the Advanced Difficulty configuration to the main difficulty screen. Thanks for the tip, though.<br /> :As for TFTD, I have a few usable patches implemented already, but I think I'll leave it up to Seb to compile and release it with his current patcher, if he wants to. Seb, if you happen to see this, let me know how you feel about the TFTD patches I'm working on. I'd prefer if you compile and release it alongside the X-COM patcher, to ensure compatibility, as I use VS2010 RC for developing right now. Either way, it'll be a while before that happens, as I'm working on testing and adding more functionality. Thanks! --[[User:Xusilak|Xusilak]] 13:18, 2 April 2010 (EDT)<br /> ::I do not work on TFTD mainly for 2 reasons: first, I don't play it; second, redoing the same things all over again is not that much interesting to me. If you want to make it happen though, I'll gladly take the opportunity to make that available for everyone in the loader. Also if you need some help analysing some bits of asm don't hesitate to ask; I'll help if I can. Good luck and have fun! [[User:Seb76|Seb76]] 15:46, 2 April 2010 (EDT)<br /> :::OK, that's fine. I don't know how much work I'll get done on TFTD, but I do want to get it to the point where all of the basic UI upgrades are done. Since you're not interested in working on it, I may just release it independently as a separate project on my own user page here, if you don't mind. That way it won't interfere with your other work. I will credit you as the main developer of it, of course, and continue to contribute original X-COM patches to UFOExtender as I develop them. --[[User:Xusilak|Xusilak]] 17:33, 2 April 2010 (EDT)<br /> :::Also, for clarity, I'll provide the source code for the TFTD patcher when I start releasing them. --[[User:Xusilak|Xusilak]] 17:38, 2 April 2010 (EDT)<br /> <br /> == TFTD Database ==<br /> <br /> Maybe you could publish the TFTD patch database on this site, as it evolves. Initially it will have a lot of gaps, but if you publish the gaps people will know what to look for. You will probably get volunteers who will hunt down the patches for the things that they are particularly interested in. The work will go faster with collaboration. [[User:Spike|Spike]] 05:19, 3 April 2010 (EDT)<br /> :For now, I think it will go faster if I focus on it. I'm already about 40% done naming the variables and functions that are already known from X-COM, thanks to Seb. Once I've gotten that bit done (should be within a week or so) and gotten the patcher itself to a useful state, I'll go ahead and publish both the IDA database and the patcher source code here. --[[User:Xusilak|Xusilak]] 11:24, 3 April 2010 (EDT)<br /> Any reason why IDA crashes when I load the .idc file? It says: Attempt to call a database related function without a database. Do I need a plugin? Using v5.2 [[User:J'ordos|J&amp;#39;ordos]] 17:23, 28 April 2010 (EDT)<br /> :never mind just realized I need to add this over the disassembled file, right? [[User:J'ordos|J&amp;#39;ordos]] 17:26, 28 April 2010 (EDT)<br /> ::Yep. Disassemble the TFTD CE exe, then load the IDC on top of it. --[[User:Xusilak|Xusilak]] 19:09, 28 April 2010 (EDT)<br /> <br /> Hi Xusilak, Where can I get ready version of your TFTD mod? I don't know how .idc file in .exe file. Whether can to get ready version for so illiterate users such me? ))<br /> :The IDC file is a database you can use with the IDA pro disassembler. There is no way to turn it in a program like seb's loader. You will have to wait until Xusilak finishes that. On that note, how is progress Xusilak? :) [[User:J'ordos|J&amp;#39;ordos]] 17:01, 8 May 2010 (EDT)<br /> <br /> == KeeperFX ==<br /> <br /> Hello, first of all, i would like to say that you guys (you and Seb) are doing great job :)<br /> <br /> I've found some project for Dungeon Keeper, which can be considered similar to what you're doing, but it's done quite different way (i believe). If i understand correctly, you're somehow altering x-com code in memory after launching it? Author of keeperfx is doing it such way (qoute from website):<br /> <br /> http://keeper.lubie.org/html/dk_keeperfx.php<br /> <br /> ''Instead, I've learned binary formats of EXE and DLL files, and modified the Dungeon Keeper executable file to become a DLL. With my new DLL, I was able to create very simple executable file which may be used as complete code to run the game. Now I'm incrementally rewriting DK; functions which are not yet rewritten are called from the DLL, so the project functions like whole game, even tho it wasn't completely rewritten yet.''<br /> <br /> Here's instruction how to change exe to dll: http://keeper.lubie.org/other_docs/change_exe_to_dll.htm<br /> <br /> I wonder if such way could be useful (and possible) for x-com (tftd) extender? Would it be easier to add new things? Would it allow to gradually rewrite whole game from scratch? What do you think? --[[User:Michal|Michal]] 13:11, 13 April 2010 (EDT)<br /> :Interesting idea. Thanks for mentioning that. What we're doing now is similar, but essentially the inverse of this. We're using DLL injection to replace X-COM functions and code at run-time. So, we have the game using its normal EXE and the patcher using a DLL. His method is focused specifically on rewriting the game, but in an incremental way that doesn't require him to go for years without seeing any results. That method would be very poor for doing the kind of patching we're doing now, because we'd have to rewrite all of the core loop code in X-COM before we could get to a point where we could start implementing our new functionality. This is because the replacement game EXE can't simply inject functions at certain points in the original game DLL's function calls, at least not without doing what we do now (patching memory directly). In the end, there's no particular benefit to doing small patches through that EXE-based method. It would be an advantage if we were trying to rewrite the game entirely, with an emphasis on rewriting the core code and working our way up, but that's not what we're doing; if we did want to do that, it could be done through the DLL injection method painlessly, and then converted to its own EXE once we finished rewriting the game. It is unlikely that we'll try to rewrite the game, however, because it would be an extremely lengthy and arduous task; if I were doing it alone, it would take years. Our current technique of simply extending X-COM's existing code produces much more immediate and beneficial results.<br /> :Thanks again for posting a link to this, though. It might be useful to me in the future. --[[User:Xusilak|Xusilak]] 19:33, 13 April 2010 (EDT)<br /> <br /> ==X-COM bugs that TFTD inherits==<br /> Since I'm going to be translating patches from X-COM to TFTD now, I could use some information on which bugs need to be fixed in TFTD that existed in X-COM. If anyone has such information, I'd greatly appreciate it, as it would save me the effort of testing each bug. In particular, a list of which of Seb's bug-fix patches could still usefully apply to TFTD would be awesome. Note that I don't need information on TFTD-specific bugs, just bugs that TFTD inherits from X-COM. Thanks in advance! --[[User:Xusilak|Xusilak]] 20:20, 15 April 2010 (EDT)<br /> :Scroll speed in tactical mode is reduced. It is too fast for certain hardware configurations <br /> :Phantom radar bug fixed. Radar coverage is updated when facilities are destructed <br /> :Pay for dirt bug removed. The cause was a funny one ^_^ <br /> :If you're tired of having to reselect your TU reserve mode at the begining of each turn, then the &quot;Save Reserve Mode&quot; patch is for you :) <br /> :Base disjoint bug <br /> :Radar stacking enabled. Credits go to Spike for I used something close to his formula. <br /> :Vertical waypoints blaster bomb bug <br /> :Garbled video output due to ignored pitch <br /> :Problem with last salvo during dogfights. The ship won't retreat when running out of ammo, allowing the last salvo to hit. Not the perfect solution, but you may still find this useful.<br /> :Armed state issues with proximity grenades when reloading a game. Should also fix &quot;What just exploded?&quot;<br /> :Experience issue with proximity grenades. The thrower now gets the experience, not the poor alien that blows up... <br /> :Refueling issue when transfered crafts arrive (enabled by default if you use the &quot;Crafts Always Ready&quot; mod) <br /> :Elerium fueled crafts bug when fuel level is 50% <br /> :Displayed Base Maintenance Cost Bug <br /> :Door jam <br /> :Robotic Manufacturing / Cybernetic Laboratories. You cannot get more than 255 engineers/scientists, buying more will just result in them being lost during transfer... <br /> :Funky fire fix: Fire/stun damage applied only at the end of the turn. Maximum fire damage increased from 5 to 10 to compensate <br /> :Hostile Civilians fix. Not really tested, may fix some mind control abuses. <br /> :Animations Speed: Reduce the animation speed of cursors and smoke/fire. <br /> :Almost all bugs were transferred over AFAIK :) can't remember if the game did remember the TU reserve mode though. [[User:J'ordos|J&amp;#39;ordos]] 10:22, 20 April 2010 (EDT)<br /> ::Thanks! I really appreciate this list; it should save me a good deal of time. Hopefully I'll be able to get most of them fixed by the end of the month. --[[User:Xusilak|Xusilak]] 13:14, 20 April 2010 (EDT)<br /> <br /> == FORMULES ABOUT FLOATING BASE ATTACK MISSION ==<br /> <br /> Hi, Xusilak<br /> <br /> Firstly, I Am so-so so sorry that I reverted your file acidentally. I don't know English good, pressed acidentally and 'llnot know undo it.<br /> I am sorry for disturbance<br /> I informed that you are great specialist in TFTD executable.<br /> My great respect for you for work, which you are doing.<br /> <br /> At discussion file Missions.dat (XCOM-EU) Seb 76 posted this formules: After a shootdown, the next UFO for that mission is delayed between 1 and ~9 days ( the formula is 48+RAND()*400 half hours ). A retaliation mission will be scheduled if RAND()*100 &lt; 4*(24-difficultyLevel). <br /> If RAND()*100 &lt; (50-6*difficultyLevel), the retaliation mission will use the same zone as the shot UFO, else it'll be the zone containing the base the craft in coming from.<br /> <br /> At first, Formule 2 and 3 probably contins mistake. formule 'll have to have symbol &gt; instead symbol &lt;. Otherwise retaliation mission activates more often on Beginner diificulty than Superhuman difficulty. Is is strange. <br /> I ask generously to you to check this 3 formules in TFTD. Is these same or not? and would check indicated me probably mistake.<br /> <br /> Thank you for this help very great<br /> <br /> == Research tree in executable ==<br /> <br /> Do you know location (starting offset) of research tree in TFTD? and how much entries it contains ? how much rows it contains?<br /> <br /> Or at least where are located requirements for technologies? (for example - vibro blade, aqua plastics)<br /> <br /> == Terror ship route and alien artefact site ==<br /> <br /> Maybe do you know where locate offset responsible for probability of appearing at 1-st day of month these events?<br /> <br /> If you would be know it, I didn't know how I could thank you for so valuable help to me</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Xusilak&diff=28068 2010-04-28T21:26:20Z

<p>J&#039;ordos: nevermind</p> <hr /> <div>Feel free to discuss anything related to my projects here! --[[User:Xusilak|Xusilak]] 15:42, 24 March 2010 (EDT)<br /> ----<br /> <br /> == I'm smiling for a reason. ==<br /> <br /> TSIA ;) - [[User:Amphibious Tentaculat|Amphibious Tentaculat]] 18:45, 24 March 2010 (EDT)<br /> <br /> == Potential Projects ==<br /> <br /> Good set of potential projects, I like! [[User:Spike|Spike]] 19:28, 24 March 2010 (EDT)<br /> <br /> Especially looking forward to the TFTD patches! By the way, xcomutil already allows you to set the difficulty value to any number you wish. [[User:J'ordos|J&amp;#39;ordos]] 08:40, 2 April 2010 (EDT)<br /> :Interesting; I didn't know that. However, my experiments with high difficulty levels showed that exceeding the defaults will break certain aspects of the game, like spawning arbitrary numbers of aliens in missions. My primary goal there is to make those difficulty levels fully functional, with expected results for spawn numbers, capping overflows, and so on. My secondary goal is to make it easier to use those difficulty levels by adding the Advanced Difficulty configuration to the main difficulty screen. Thanks for the tip, though.<br /> :As for TFTD, I have a few usable patches implemented already, but I think I'll leave it up to Seb to compile and release it with his current patcher, if he wants to. Seb, if you happen to see this, let me know how you feel about the TFTD patches I'm working on. I'd prefer if you compile and release it alongside the X-COM patcher, to ensure compatibility, as I use VS2010 RC for developing right now. Either way, it'll be a while before that happens, as I'm working on testing and adding more functionality. Thanks! --[[User:Xusilak|Xusilak]] 13:18, 2 April 2010 (EDT)<br /> ::I do not work on TFTD mainly for 2 reasons: first, I don't play it; second, redoing the same things all over again is not that much interesting to me. If you want to make it happen though, I'll gladly take the opportunity to make that available for everyone in the loader. Also if you need some help analysing some bits of asm don't hesitate to ask; I'll help if I can. Good luck and have fun! [[User:Seb76|Seb76]] 15:46, 2 April 2010 (EDT)<br /> :::OK, that's fine. I don't know how much work I'll get done on TFTD, but I do want to get it to the point where all of the basic UI upgrades are done. Since you're not interested in working on it, I may just release it independently as a separate project on my own user page here, if you don't mind. That way it won't interfere with your other work. I will credit you as the main developer of it, of course, and continue to contribute original X-COM patches to UFOExtender as I develop them. --[[User:Xusilak|Xusilak]] 17:33, 2 April 2010 (EDT)<br /> :::Also, for clarity, I'll provide the source code for the TFTD patcher when I start releasing them. --[[User:Xusilak|Xusilak]] 17:38, 2 April 2010 (EDT)<br /> <br /> == TFTD Database ==<br /> <br /> Maybe you could publish the TFTD patch database on this site, as it evolves. Initially it will have a lot of gaps, but if you publish the gaps people will know what to look for. You will probably get volunteers who will hunt down the patches for the things that they are particularly interested in. The work will go faster with collaboration. [[User:Spike|Spike]] 05:19, 3 April 2010 (EDT)<br /> :For now, I think it will go faster if I focus on it. I'm already about 40% done naming the variables and functions that are already known from X-COM, thanks to Seb. Once I've gotten that bit done (should be within a week or so) and gotten the patcher itself to a useful state, I'll go ahead and publish both the IDA database and the patcher source code here. --[[User:Xusilak|Xusilak]] 11:24, 3 April 2010 (EDT)<br /> Any reason why IDA crashes when I load the .idc file? It says: Attempt to call a database related function without a database. Do I need a plugin? Using v5.2 [[User:J'ordos|J&amp;#39;ordos]] 17:23, 28 April 2010 (EDT)<br /> :never mind just realized I need to add this over the disassembled file, right? [[User:J'ordos|J&amp;#39;ordos]] 17:26, 28 April 2010 (EDT)<br /> <br /> == KeeperFX ==<br /> <br /> Hello, first of all, i would like to say that you guys (you and Seb) are doing great job :)<br /> <br /> I've found some project for Dungeon Keeper, which can be considered similar to what you're doing, but it's done quite different way (i believe). If i understand correctly, you're somehow altering x-com code in memory after launching it? Author of keeperfx is doing it such way (qoute from website):<br /> <br /> http://keeper.lubie.org/html/dk_keeperfx.php<br /> <br /> ''Instead, I've learned binary formats of EXE and DLL files, and modified the Dungeon Keeper executable file to become a DLL. With my new DLL, I was able to create very simple executable file which may be used as complete code to run the game. Now I'm incrementally rewriting DK; functions which are not yet rewritten are called from the DLL, so the project functions like whole game, even tho it wasn't completely rewritten yet.''<br /> <br /> Here's instruction how to change exe to dll: http://keeper.lubie.org/other_docs/change_exe_to_dll.htm<br /> <br /> I wonder if such way could be useful (and possible) for x-com (tftd) extender? Would it be easier to add new things? Would it allow to gradually rewrite whole game from scratch? What do you think? --[[User:Michal|Michal]] 13:11, 13 April 2010 (EDT)<br /> :Interesting idea. Thanks for mentioning that. What we're doing now is similar, but essentially the inverse of this. We're using DLL injection to replace X-COM functions and code at run-time. So, we have the game using its normal EXE and the patcher using a DLL. His method is focused specifically on rewriting the game, but in an incremental way that doesn't require him to go for years without seeing any results. That method would be very poor for doing the kind of patching we're doing now, because we'd have to rewrite all of the core loop code in X-COM before we could get to a point where we could start implementing our new functionality. This is because the replacement game EXE can't simply inject functions at certain points in the original game DLL's function calls, at least not without doing what we do now (patching memory directly). In the end, there's no particular benefit to doing small patches through that EXE-based method. It would be an advantage if we were trying to rewrite the game entirely, with an emphasis on rewriting the core code and working our way up, but that's not what we're doing; if we did want to do that, it could be done through the DLL injection method painlessly, and then converted to its own EXE once we finished rewriting the game. It is unlikely that we'll try to rewrite the game, however, because it would be an extremely lengthy and arduous task; if I were doing it alone, it would take years. Our current technique of simply extending X-COM's existing code produces much more immediate and beneficial results.<br /> :Thanks again for posting a link to this, though. It might be useful to me in the future. --[[User:Xusilak|Xusilak]] 19:33, 13 April 2010 (EDT)<br /> <br /> ==X-COM bugs that TFTD inherits==<br /> Since I'm going to be translating patches from X-COM to TFTD now, I could use some information on which bugs need to be fixed in TFTD that existed in X-COM. If anyone has such information, I'd greatly appreciate it, as it would save me the effort of testing each bug. In particular, a list of which of Seb's bug-fix patches could still usefully apply to TFTD would be awesome. Note that I don't need information on TFTD-specific bugs, just bugs that TFTD inherits from X-COM. Thanks in advance! --[[User:Xusilak|Xusilak]] 20:20, 15 April 2010 (EDT)<br /> :Scroll speed in tactical mode is reduced. It is too fast for certain hardware configurations <br /> :Phantom radar bug fixed. Radar coverage is updated when facilities are destructed <br /> :Pay for dirt bug removed. The cause was a funny one ^_^ <br /> :If you're tired of having to reselect your TU reserve mode at the begining of each turn, then the &quot;Save Reserve Mode&quot; patch is for you :) <br /> :Base disjoint bug <br /> :Radar stacking enabled. Credits go to Spike for I used something close to his formula. <br /> :Vertical waypoints blaster bomb bug <br /> :Garbled video output due to ignored pitch <br /> :Problem with last salvo during dogfights. The ship won't retreat when running out of ammo, allowing the last salvo to hit. Not the perfect solution, but you may still find this useful.<br /> :Armed state issues with proximity grenades when reloading a game. Should also fix &quot;What just exploded?&quot;<br /> :Experience issue with proximity grenades. The thrower now gets the experience, not the poor alien that blows up... <br /> :Refueling issue when transfered crafts arrive (enabled by default if you use the &quot;Crafts Always Ready&quot; mod) <br /> :Elerium fueled crafts bug when fuel level is 50% <br /> :Displayed Base Maintenance Cost Bug <br /> :Door jam <br /> :Robotic Manufacturing / Cybernetic Laboratories. You cannot get more than 255 engineers/scientists, buying more will just result in them being lost during transfer... <br /> :Funky fire fix: Fire/stun damage applied only at the end of the turn. Maximum fire damage increased from 5 to 10 to compensate <br /> :Hostile Civilians fix. Not really tested, may fix some mind control abuses. <br /> :Animations Speed: Reduce the animation speed of cursors and smoke/fire. <br /> :Almost all bugs were transferred over AFAIK :) can't remember if the game did remember the TU reserve mode though. [[User:J'ordos|J&amp;#39;ordos]] 10:22, 20 April 2010 (EDT)<br /> ::Thanks! I really appreciate this list; it should save me a good deal of time. Hopefully I'll be able to get most of them fixed by the end of the month. --[[User:Xusilak|Xusilak]] 13:14, 20 April 2010 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Xusilak&diff=28067 2010-04-28T21:23:27Z

<p>J&#039;ordos: ida database</p> <hr /> <div>Feel free to discuss anything related to my projects here! --[[User:Xusilak|Xusilak]] 15:42, 24 March 2010 (EDT)<br /> ----<br /> <br /> == I'm smiling for a reason. ==<br /> <br /> TSIA ;) - [[User:Amphibious Tentaculat|Amphibious Tentaculat]] 18:45, 24 March 2010 (EDT)<br /> <br /> == Potential Projects ==<br /> <br /> Good set of potential projects, I like! [[User:Spike|Spike]] 19:28, 24 March 2010 (EDT)<br /> <br /> Especially looking forward to the TFTD patches! By the way, xcomutil already allows you to set the difficulty value to any number you wish. [[User:J'ordos|J&amp;#39;ordos]] 08:40, 2 April 2010 (EDT)<br /> :Interesting; I didn't know that. However, my experiments with high difficulty levels showed that exceeding the defaults will break certain aspects of the game, like spawning arbitrary numbers of aliens in missions. My primary goal there is to make those difficulty levels fully functional, with expected results for spawn numbers, capping overflows, and so on. My secondary goal is to make it easier to use those difficulty levels by adding the Advanced Difficulty configuration to the main difficulty screen. Thanks for the tip, though.<br /> :As for TFTD, I have a few usable patches implemented already, but I think I'll leave it up to Seb to compile and release it with his current patcher, if he wants to. Seb, if you happen to see this, let me know how you feel about the TFTD patches I'm working on. I'd prefer if you compile and release it alongside the X-COM patcher, to ensure compatibility, as I use VS2010 RC for developing right now. Either way, it'll be a while before that happens, as I'm working on testing and adding more functionality. Thanks! --[[User:Xusilak|Xusilak]] 13:18, 2 April 2010 (EDT)<br /> ::I do not work on TFTD mainly for 2 reasons: first, I don't play it; second, redoing the same things all over again is not that much interesting to me. If you want to make it happen though, I'll gladly take the opportunity to make that available for everyone in the loader. Also if you need some help analysing some bits of asm don't hesitate to ask; I'll help if I can. Good luck and have fun! [[User:Seb76|Seb76]] 15:46, 2 April 2010 (EDT)<br /> :::OK, that's fine. I don't know how much work I'll get done on TFTD, but I do want to get it to the point where all of the basic UI upgrades are done. Since you're not interested in working on it, I may just release it independently as a separate project on my own user page here, if you don't mind. That way it won't interfere with your other work. I will credit you as the main developer of it, of course, and continue to contribute original X-COM patches to UFOExtender as I develop them. --[[User:Xusilak|Xusilak]] 17:33, 2 April 2010 (EDT)<br /> :::Also, for clarity, I'll provide the source code for the TFTD patcher when I start releasing them. --[[User:Xusilak|Xusilak]] 17:38, 2 April 2010 (EDT)<br /> <br /> == TFTD Database ==<br /> <br /> Maybe you could publish the TFTD patch database on this site, as it evolves. Initially it will have a lot of gaps, but if you publish the gaps people will know what to look for. You will probably get volunteers who will hunt down the patches for the things that they are particularly interested in. The work will go faster with collaboration. [[User:Spike|Spike]] 05:19, 3 April 2010 (EDT)<br /> :For now, I think it will go faster if I focus on it. I'm already about 40% done naming the variables and functions that are already known from X-COM, thanks to Seb. Once I've gotten that bit done (should be within a week or so) and gotten the patcher itself to a useful state, I'll go ahead and publish both the IDA database and the patcher source code here. --[[User:Xusilak|Xusilak]] 11:24, 3 April 2010 (EDT)<br /> Any reason why IDA crashes when I load the .idc file? It says: Attempt to call a database related function without a database. Do I need a plugin? Using v5.2 [[User:J'ordos|J&amp;#39;ordos]] 17:23, 28 April 2010 (EDT)<br /> <br /> == KeeperFX ==<br /> <br /> Hello, first of all, i would like to say that you guys (you and Seb) are doing great job :)<br /> <br /> I've found some project for Dungeon Keeper, which can be considered similar to what you're doing, but it's done quite different way (i believe). If i understand correctly, you're somehow altering x-com code in memory after launching it? Author of keeperfx is doing it such way (qoute from website):<br /> <br /> http://keeper.lubie.org/html/dk_keeperfx.php<br /> <br /> ''Instead, I've learned binary formats of EXE and DLL files, and modified the Dungeon Keeper executable file to become a DLL. With my new DLL, I was able to create very simple executable file which may be used as complete code to run the game. Now I'm incrementally rewriting DK; functions which are not yet rewritten are called from the DLL, so the project functions like whole game, even tho it wasn't completely rewritten yet.''<br /> <br /> Here's instruction how to change exe to dll: http://keeper.lubie.org/other_docs/change_exe_to_dll.htm<br /> <br /> I wonder if such way could be useful (and possible) for x-com (tftd) extender? Would it be easier to add new things? Would it allow to gradually rewrite whole game from scratch? What do you think? --[[User:Michal|Michal]] 13:11, 13 April 2010 (EDT)<br /> :Interesting idea. Thanks for mentioning that. What we're doing now is similar, but essentially the inverse of this. We're using DLL injection to replace X-COM functions and code at run-time. So, we have the game using its normal EXE and the patcher using a DLL. His method is focused specifically on rewriting the game, but in an incremental way that doesn't require him to go for years without seeing any results. That method would be very poor for doing the kind of patching we're doing now, because we'd have to rewrite all of the core loop code in X-COM before we could get to a point where we could start implementing our new functionality. This is because the replacement game EXE can't simply inject functions at certain points in the original game DLL's function calls, at least not without doing what we do now (patching memory directly). In the end, there's no particular benefit to doing small patches through that EXE-based method. It would be an advantage if we were trying to rewrite the game entirely, with an emphasis on rewriting the core code and working our way up, but that's not what we're doing; if we did want to do that, it could be done through the DLL injection method painlessly, and then converted to its own EXE once we finished rewriting the game. It is unlikely that we'll try to rewrite the game, however, because it would be an extremely lengthy and arduous task; if I were doing it alone, it would take years. Our current technique of simply extending X-COM's existing code produces much more immediate and beneficial results.<br /> :Thanks again for posting a link to this, though. It might be useful to me in the future. --[[User:Xusilak|Xusilak]] 19:33, 13 April 2010 (EDT)<br /> <br /> ==X-COM bugs that TFTD inherits==<br /> Since I'm going to be translating patches from X-COM to TFTD now, I could use some information on which bugs need to be fixed in TFTD that existed in X-COM. If anyone has such information, I'd greatly appreciate it, as it would save me the effort of testing each bug. In particular, a list of which of Seb's bug-fix patches could still usefully apply to TFTD would be awesome. Note that I don't need information on TFTD-specific bugs, just bugs that TFTD inherits from X-COM. Thanks in advance! --[[User:Xusilak|Xusilak]] 20:20, 15 April 2010 (EDT)<br /> :Scroll speed in tactical mode is reduced. It is too fast for certain hardware configurations <br /> :Phantom radar bug fixed. Radar coverage is updated when facilities are destructed <br /> :Pay for dirt bug removed. The cause was a funny one ^_^ <br /> :If you're tired of having to reselect your TU reserve mode at the begining of each turn, then the &quot;Save Reserve Mode&quot; patch is for you :) <br /> :Base disjoint bug <br /> :Radar stacking enabled. Credits go to Spike for I used something close to his formula. <br /> :Vertical waypoints blaster bomb bug <br /> :Garbled video output due to ignored pitch <br /> :Problem with last salvo during dogfights. The ship won't retreat when running out of ammo, allowing the last salvo to hit. Not the perfect solution, but you may still find this useful.<br /> :Armed state issues with proximity grenades when reloading a game. Should also fix &quot;What just exploded?&quot;<br /> :Experience issue with proximity grenades. The thrower now gets the experience, not the poor alien that blows up... <br /> :Refueling issue when transfered crafts arrive (enabled by default if you use the &quot;Crafts Always Ready&quot; mod) <br /> :Elerium fueled crafts bug when fuel level is 50% <br /> :Displayed Base Maintenance Cost Bug <br /> :Door jam <br /> :Robotic Manufacturing / Cybernetic Laboratories. You cannot get more than 255 engineers/scientists, buying more will just result in them being lost during transfer... <br /> :Funky fire fix: Fire/stun damage applied only at the end of the turn. Maximum fire damage increased from 5 to 10 to compensate <br /> :Hostile Civilians fix. Not really tested, may fix some mind control abuses. <br /> :Animations Speed: Reduce the animation speed of cursors and smoke/fire. <br /> :Almost all bugs were transferred over AFAIK :) can't remember if the game did remember the TU reserve mode though. [[User:J'ordos|J&amp;#39;ordos]] 10:22, 20 April 2010 (EDT)<br /> ::Thanks! I really appreciate this list; it should save me a good deal of time. Hopefully I'll be able to get most of them fixed by the end of the month. --[[User:Xusilak|Xusilak]] 13:14, 20 April 2010 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Xusilak&diff=28049 2010-04-20T14:22:58Z

<p>J&#039;ordos: genetic bugs</p> <hr /> <div>Feel free to discuss anything related to my projects here! --[[User:Xusilak|Xusilak]] 15:42, 24 March 2010 (EDT)<br /> ----<br /> <br /> == I'm smiling for a reason. ==<br /> <br /> TSIA ;) - [[User:Amphibious Tentaculat|Amphibious Tentaculat]] 18:45, 24 March 2010 (EDT)<br /> <br /> == Potential Projects ==<br /> <br /> Good set of potential projects, I like! [[User:Spike|Spike]] 19:28, 24 March 2010 (EDT)<br /> <br /> Especially looking forward to the TFTD patches! By the way, xcomutil already allows you to set the difficulty value to any number you wish. [[User:J'ordos|J&amp;#39;ordos]] 08:40, 2 April 2010 (EDT)<br /> :Interesting; I didn't know that. However, my experiments with high difficulty levels showed that exceeding the defaults will break certain aspects of the game, like spawning arbitrary numbers of aliens in missions. My primary goal there is to make those difficulty levels fully functional, with expected results for spawn numbers, capping overflows, and so on. My secondary goal is to make it easier to use those difficulty levels by adding the Advanced Difficulty configuration to the main difficulty screen. Thanks for the tip, though.<br /> :As for TFTD, I have a few usable patches implemented already, but I think I'll leave it up to Seb to compile and release it with his current patcher, if he wants to. Seb, if you happen to see this, let me know how you feel about the TFTD patches I'm working on. I'd prefer if you compile and release it alongside the X-COM patcher, to ensure compatibility, as I use VS2010 RC for developing right now. Either way, it'll be a while before that happens, as I'm working on testing and adding more functionality. Thanks! --[[User:Xusilak|Xusilak]] 13:18, 2 April 2010 (EDT)<br /> ::I do not work on TFTD mainly for 2 reasons: first, I don't play it; second, redoing the same things all over again is not that much interesting to me. If you want to make it happen though, I'll gladly take the opportunity to make that available for everyone in the loader. Also if you need some help analysing some bits of asm don't hesitate to ask; I'll help if I can. Good luck and have fun! [[User:Seb76|Seb76]] 15:46, 2 April 2010 (EDT)<br /> :::OK, that's fine. I don't know how much work I'll get done on TFTD, but I do want to get it to the point where all of the basic UI upgrades are done. Since you're not interested in working on it, I may just release it independently as a separate project on my own user page here, if you don't mind. That way it won't interfere with your other work. I will credit you as the main developer of it, of course, and continue to contribute original X-COM patches to UFOExtender as I develop them. --[[User:Xusilak|Xusilak]] 17:33, 2 April 2010 (EDT)<br /> :::Also, for clarity, I'll provide the source code for the TFTD patcher when I start releasing them. --[[User:Xusilak|Xusilak]] 17:38, 2 April 2010 (EDT)<br /> <br /> == TFTD Database ==<br /> <br /> Maybe you could publish the TFTD patch database on this site, as it evolves. Initially it will have a lot of gaps, but if you publish the gaps people will know what to look for. You will probably get volunteers who will hunt down the patches for the things that they are particularly interested in. The work will go faster with collaboration. [[User:Spike|Spike]] 05:19, 3 April 2010 (EDT)<br /> :For now, I think it will go faster if I focus on it. I'm already about 40% done naming the variables and functions that are already known from X-COM, thanks to Seb. Once I've gotten that bit done (should be within a week or so) and gotten the patcher itself to a useful state, I'll go ahead and publish both the IDA database and the patcher source code here. --[[User:Xusilak|Xusilak]] 11:24, 3 April 2010 (EDT)<br /> <br /> == KeeperFX ==<br /> <br /> Hello, first of all, i would like to say that you guys (you and Seb) are doing great job :)<br /> <br /> I've found some project for Dungeon Keeper, which can be considered similar to what you're doing, but it's done quite different way (i believe). If i understand correctly, you're somehow altering x-com code in memory after launching it? Author of keeperfx is doing it such way (qoute from website):<br /> <br /> http://keeper.lubie.org/html/dk_keeperfx.php<br /> <br /> ''Instead, I've learned binary formats of EXE and DLL files, and modified the Dungeon Keeper executable file to become a DLL. With my new DLL, I was able to create very simple executable file which may be used as complete code to run the game. Now I'm incrementally rewriting DK; functions which are not yet rewritten are called from the DLL, so the project functions like whole game, even tho it wasn't completely rewritten yet.''<br /> <br /> Here's instruction how to change exe to dll: http://keeper.lubie.org/other_docs/change_exe_to_dll.htm<br /> <br /> I wonder if such way could be useful (and possible) for x-com (tftd) extender? Would it be easier to add new things? Would it allow to gradually rewrite whole game from scratch? What do you think? --[[User:Michal|Michal]] 13:11, 13 April 2010 (EDT)<br /> :Interesting idea. Thanks for mentioning that. What we're doing now is similar, but essentially the inverse of this. We're using DLL injection to replace X-COM functions and code at run-time. So, we have the game using its normal EXE and the patcher using a DLL. His method is focused specifically on rewriting the game, but in an incremental way that doesn't require him to go for years without seeing any results. That method would be very poor for doing the kind of patching we're doing now, because we'd have to rewrite all of the core loop code in X-COM before we could get to a point where we could start implementing our new functionality. This is because the replacement game EXE can't simply inject functions at certain points in the original game DLL's function calls, at least not without doing what we do now (patching memory directly). In the end, there's no particular benefit to doing small patches through that EXE-based method. It would be an advantage if we were trying to rewrite the game entirely, with an emphasis on rewriting the core code and working our way up, but that's not what we're doing; if we did want to do that, it could be done through the DLL injection method painlessly, and then converted to its own EXE once we finished rewriting the game. It is unlikely that we'll try to rewrite the game, however, because it would be an extremely lengthy and arduous task; if I were doing it alone, it would take years. Our current technique of simply extending X-COM's existing code produces much more immediate and beneficial results.<br /> :Thanks again for posting a link to this, though. It might be useful to me in the future. --[[User:Xusilak|Xusilak]] 19:33, 13 April 2010 (EDT)<br /> <br /> ==X-COM bugs that TFTD inherits==<br /> Since I'm going to be translating patches from X-COM to TFTD now, I could use some information on which bugs need to be fixed in TFTD that existed in X-COM. If anyone has such information, I'd greatly appreciate it, as it would save me the effort of testing each bug. In particular, a list of which of Seb's bug-fix patches could still usefully apply to TFTD would be awesome. Note that I don't need information on TFTD-specific bugs, just bugs that TFTD inherits from X-COM. Thanks in advance! --[[User:Xusilak|Xusilak]] 20:20, 15 April 2010 (EDT)<br /> :Scroll speed in tactical mode is reduced. It is too fast for certain hardware configurations <br /> :Phantom radar bug fixed. Radar coverage is updated when facilities are destructed <br /> :Pay for dirt bug removed. The cause was a funny one ^_^ <br /> :If you're tired of having to reselect your TU reserve mode at the begining of each turn, then the &quot;Save Reserve Mode&quot; patch is for you :) <br /> :Base disjoint bug <br /> :Radar stacking enabled. Credits go to Spike for I used something close to his formula. <br /> :Vertical waypoints blaster bomb bug <br /> :Garbled video output due to ignored pitch <br /> :Problem with last salvo during dogfights. The ship won't retreat when running out of ammo, allowing the last salvo to hit. Not the perfect solution, but you may still find this useful.<br /> :Armed state issues with proximity grenades when reloading a game. Should also fix &quot;What just exploded?&quot;<br /> :Experience issue with proximity grenades. The thrower now gets the experience, not the poor alien that blows up... <br /> :Refueling issue when transfered crafts arrive (enabled by default if you use the &quot;Crafts Always Ready&quot; mod) <br /> :Elerium fueled crafts bug when fuel level is 50% <br /> :Displayed Base Maintenance Cost Bug <br /> :Door jam <br /> :Robotic Manufacturing / Cybernetic Laboratories. You cannot get more than 255 engineers/scientists, buying more will just result in them being lost during transfer... <br /> :Funky fire fix: Fire/stun damage applied only at the end of the turn. Maximum fire damage increased from 5 to 10 to compensate <br /> :Hostile Civilians fix. Not really tested, may fix some mind control abuses. <br /> :Animations Speed: Reduce the animation speed of cursors and smoke/fire. <br /> :Almost all bugs were transferred over AFAIK :) can't remember if the game did remember the TU reserve mode though. [[User:J'ordos|J&amp;#39;ordos]] 10:22, 20 April 2010 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Xusilak&diff=27963 2010-04-02T12:40:34Z

<p>J&#039;ordos: forgot signature</p> <hr /> <div>Feel free to discuss anything related to my projects here! --[[User:Xusilak|Xusilak]] 15:42, 24 March 2010 (EDT)<br /> ----<br /> <br /> == I'm smiling for a reason. ==<br /> <br /> TSIA ;) - [[User:Amphibious Tentaculat|Amphibious Tentaculat]] 18:45, 24 March 2010 (EDT)<br /> <br /> == Potential Projects ==<br /> <br /> Good set of potential projects, I like! [[User:Spike|Spike]] 19:28, 24 March 2010 (EDT)<br /> <br /> Especially looking forward to the TFTD patches! By the way, xcomutil already allows you to set the difficulty value to any number you wish. [[User:J'ordos|J&amp;#39;ordos]] 08:40, 2 April 2010 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Xusilak&diff=27962 2010-04-02T12:39:56Z

<p>J&#039;ordos: </p> <hr /> <div>Feel free to discuss anything related to my projects here! --[[User:Xusilak|Xusilak]] 15:42, 24 March 2010 (EDT)<br /> ----<br /> <br /> == I'm smiling for a reason. ==<br /> <br /> TSIA ;) - [[User:Amphibious Tentaculat|Amphibious Tentaculat]] 18:45, 24 March 2010 (EDT)<br /> <br /> == Potential Projects ==<br /> <br /> Good set of potential projects, I like! [[User:Spike|Spike]] 19:28, 24 March 2010 (EDT)<br /> <br /> Especially looking forward to the TFTD patches! By the way, xcomutil already allows you to set the difficulty value to any number you wish.</div>

J'ordos https://temp.ufopaedia.org/index.php?title=Alien_Ship_Combat_(Apocalypse)&diff=25413 2009-11-23T02:24:02Z

<p>J&#039;ordos: lower flying heights remark</p> <hr /> <div>Tactics in no particular order:<br /> <br /> * Your craft DO NOT need to be at your own base building once you have equipped them! Spread you craft around the cityscape buildings (make them land at buildings which have multiple launch tubes). When you have an alien ship come through the gates, you'll have a little welcoming party very quickly close nearby (if you have your craft based at a building with multiple launch tubes, they will launch in such a way to use all available tubes - even if the yellow craft icon doesn't appear over an actual tube. Try it at the Transtellar space port with its 12+ tubes using 10 X-Com vehicles). You'll have to fly back to base however once the engagement is over, if you need to rearm. Send them out again afterwards.<br /> * If you use hoverbikes, then three stationed at the middle of each quadrant of the cityscape works best. (All sports engines with loadouts: 1xRendor, 1xBolter, 1xProphet + Weapons control)<br /> * If you use hovercars, then two work well. (All turbo engines with loadouts: 1xRendor + 1xProphet + 1xMedium weapon control)<br /> * One valkyrie can easily be overwhelmed. Use more (6xHoverbikes per quadrant, or 4xHovercars, or 2x Valkyries) if you can afford it.<br /> * Using agressive combat controls can sometimes be worthwhile when up against a difficult enemy, because your ship(s) is concentrating on downing the enemy instead of trying to avoid its guns/missiles. It can get to the point where your ship rarely fires its armaments due to constant evasiveness. Be offensive not defensive.<br /> * If your craft has sustained massive damage, try to land at the nearest building instead of trying to run back to base. Sometimes the best option, though, is a nearby and not the nearest building so that the enemy craft do not get a potshot at the landing vehicle, which are always easy targets. You'll have to judge this yourself.<br /> * Lower flying heights are important if you want to limit damage to the cityscape. Corporations get pissed more quickly if you hit the buildings when you miss in combat, relative to the aliens hitting them. The added bonus is that sometimes the corporation will launch its own craft to combat the alien menace. This also can make the corp hostile to the aliens. Use it to your advantage (Transellar and Cultists), but remember the city damage will lower your score that the end of the month. WHY?? When flying lower, you'll have to shoot upwards at the alien craft. If you miss, then the shots just go into space and not into a building. It should be noted that large vehicles (Valkyrie Interceptor, Hawk Air Warrior, Retaliator and Annihilator) have slightly weaker top armor so they will sustain more damage when flying low once their shields are gone.<br /> * Running low on powerful engines? Giving lower powered engines to missile launching craft can help the overall battle because these craft will be slower to get to an engagement (if you have to fly long distances across the cityscape quadrant). Hence, they will be able to lauch missles directly at the hostile craft instead of getting up close and personal and hoping that the missile can turn sharp enough to hit the hostiles. If you aren't lacking powerful engines, then this could be an option you'd may like to keep using.<br /> * Hoverbikes are very weak. Use them as a swarm. 2xBikes Vs 1xAlienship only works in very early game. You'll need more.<br /> * Hovercars can mount small shields later on. Remember this when you think you should have used hoverbikes instead.<br /> * A mixed force of hovercars and hoverbikes are best. It can work well either way! If you want quick evasive bikes up close and personal with the hostile craft, then give them guns and give the hovercars missile weapons. You don't need to give shield to the cars, just weapon control modules. since then should be near a standoff range. If you want the opposite effect, give shields and guns to the hovercars for up close combat, and missiles to the bikes.<br /> * Changing combat attitudes of your attacking craft throughout the battle can help immensely. Fly to the alien craft using evasive control (don't waste missiles on hostile human cars), briefly switch to standard agressiveness so that everyone fires once (mainly for missile launching), change to full agression for craft with guns, change to cautious for craft with missiles. If a craft takes heavy damage, change to evasive control and disengage this craft. PAUSE BUTTON WORKS WELL!<br /> * A good tactic, although slightly uninspired, is to buy as many hoverbikes as possible and attack in swarms of 5-8 bikes per alien craft, set them on the second lowest height and set them to evasive. You should expect to lose one or two hoverbikes in each engagement in the early and middle stage battles. When fighting the larger alien craft it is better to barrage them with guided missles to soften them up before the hoverbikes get there, otherwise they will be dropping like flies.<br /> * Also when employing the &quot;Swarm&quot; tactic, try to break up the groups of hoverbikes so they dont all get destroyed by a hail of missiles and cannon. Try to have 3-4 max coming from any one direction. It may be a bit of work but it pays dividends in the end.<br /> * This point cannot be stressed enough: make sure that you remove your agents from their vehicles/aircraft before sending them to engage Alien ships. If your craft is destroyed, the agent piloting it will perish too along with his/her equipment. Isn't that irritating?<br /> <br /> [[Category: Apocalypse]]</div>

J'ordos https://temp.ufopaedia.org/index.php?title=Talk:Biochemistry&diff=25402 2009-11-20T12:02:10Z

<p>J&#039;ordos: </p> <hr /> <div>it seems to me that the values under &quot;cost&quot; are WAY off. First off, I am making the assumption that by cost we mean &quot;skill hours&quot; and not financial cost. Some of them could be simply mistakes, such as the multiworm being listed as 90k and 15k, which is (according to Apoc'd) 9k and 15k; yet others are so different that it cannot have been a simple typo. Is there something I am missing? [[User:Talon81|Talon81]] 23:30, 18 November 2009 (EST)<br /> : Looking at it the Hyperworm, Multiworm Egg and the Multiworm seem to have all typos. The original poster that added the skill hours was Blaimjos but he doesn't mentioned his source. Either he got it from one of the forums or from the Official Strategy Guide. Can you check with Apoc'd all of the values that don't match? [[User:Hobbes|Hobbes]] 05:57, 19 November 2009 (EST)<br /> :: Yeah, I noticed those ones seem to be typos. I have only been around this wiki for at most a year, and only on Apoc wiki for a couple months. I didn't want to be presumptuous in making major edits, but I have fixed a few things here and there. Anyway, I am going to edit all of them to match Apoc'd now, and you can review my changes and undo anything you know to be wrong... but I am pretty certain Apoc'd is correct.[[User:Talon81|Talon81]] 14:00, 19 November 2009 (EST)<br /> ::: Modesty is a virtue but don't let it restrain you from doing edits if the information is incorrect or outdated. No one here holds the truth... perhaps someone will come in a year and tell us that Apoc'd values are all wrong :) [[User:Hobbes|Hobbes]] 14:42, 19 November 2009 (EST)<br /> :::: BLASPHEMY!!! :-) [[User:J'ordos|J&amp;#39;ordos]] 07:02, 20 November 2009 (EST)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=22201 2009-08-09T15:38:48Z

<p>J&#039;ordos: /* D3D */</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> :::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)<br /> ::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J&amp;#39;ordos]] 05:01, 9 September 2008 (PDT)<br /> : Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)<br /> ::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)<br /> :::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)<br /> :::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)<br /> ::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)<br /> ::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)<br /> :Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J&amp;#39;ordos]] 12:58, 26 April 2009 (EDT)<br /> ::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)<br /> <br /> OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your &quot;Full Auto&quot; mode would be 100% TUs for 10 rounds and your &quot;Burst Mode&quot; could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)<br /> <br /> : On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)<br /> <br /> Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ. <br /> <br /> Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz: <br /> <br /> See if you can get the &quot;hidden item&quot;, Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)<br /> <br /> :Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:<br /> :*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front<br /> :*reduce accuracy even further when shooting out of sight (this was mentionned in another post)<br /> :*change the damage model and reduce the probability that terrain is destroyed when shot<br /> :*have a cooldown period where the weapon is not useable (not sure if it's feasible though)<br /> <br /> ::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J&amp;#39;ordos]] 16:27, 7 September 2008 (PDT)<br /> :::Hm, I already cannibalized the unused &quot;open&quot; and &quot;close&quot; actions for the heavy laser mod, there is no more room for a new &quot;hit&quot; command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)<br /> <br /> :OK, here is the last draft before I finalize:<br /> :*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)<br /> :*Each shot of a burst will reduce the accuracy (amount not determined yet)<br /> :*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL<br /> :If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)<br /> <br /> Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)<br /> :OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)<br /> <br /> It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J&amp;#39;ordos]] 12:41, 28 February 2009 (CST)<br /> :It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)<br /> <br /> Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.<br /> --[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)<br /> <br /> :The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the &quot;shortcuts&quot; patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)<br /> <br /> I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)<br /> <br /> == Wish List please please please ==<br /> <br /> <br /> <br /> === New and Outstanding Requests ===<br /> <br /> * Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.<br /> [Utilities]<br /> Run Utilities=0|1<br /> Run before battle=&quot;xcomutil ...&quot;<br /> Run after battle =&quot;xcomutil ...&quot;<br /> Run before base screen=&quot;xcomutil ...&quot; <br /> <br /> * Allow scrolling the map with the keyboard. &quot;WASD&quot; as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.<br /> <br /> * Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.<br /> <br /> * Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.<br /> <br /> * Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode. <br /> <br /> : Has this been completed via the &quot;Save Reserve Mode&quot; feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair. <br /> <br /> * Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:<br /> ** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has &gt;0 units before allowing it to start. <br /> ** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.<br /> ** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix. <br /> * Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns &quot;no line of fire&quot;. This would avoid a lot of the &quot;hit the ceiling&quot; issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''<br /> * Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.<br /> * Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]]. <br /> <br /> <br /> * [[Wish List#Prior Recon of Battlefield|&quot;Eye in the Sky&quot;]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings. <br /> <br /> * Grenades that [[Wish List#Warm Grenades|function normally]].<br /> <br /> * Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].<br /> <br /> ==== Incendiary Bug ====<br /> <br /> * Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].<br /> <br /> :: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the &quot;end of turn&quot; criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)<br /> <br /> OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:<br /> <br /> # In area of effect<br /> ##add fire to tiles<br /> ##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)<br /> # IF a unit was hit directly<br /> ## check to see if it catches fire<br /> ## ''possibly'' do &quot;impact&quot; damage. <br /> # Return, '''without''' calling the end-of-turn smoke/fire routine<br /> <br /> And it's entirely possible there was never supposed to be any &quot;impact&quot; damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the &quot;impact&quot; damage could just be a side effect of the funky fire bug - applying the 5-10 &quot;on fire&quot; damage right away, when it was meant to be applied at end-of-turn. <br /> <br /> [[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)<br /> :Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)<br /> <br /> ::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences. <br /> <br /> ::It will be interesting to see if patching out all 4 calls eliminates &quot;impact&quot; IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but &quot;impact&quot; damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff! <br /> <br /> ::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)<br /> <br /> ==== See Also ====<br /> <br /> *[[Wish List]]<br /> *[[Known Bugs]]<br /> *[[Exploits]]<br /> <br /> === Completed Items - Thanks Seb! ===<br /> <br /> See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]<br /> <br /> * Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault. <br /> :The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :: Completed with the &quot;Keep Base Navigation Tables&quot; option. <br /> <br /> * Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the &quot;Roswell Incident&quot;. Crash site would be automatically detected &amp; UFO would have random damage. <br /> :Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :Update: feature almost complete, time to bake a new version ;-)<br /> <br /> :[[Image:Roswell.png]]<br /> <br /> :There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)<br /> <br /> <br /> * Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)<br /> <br /> : Fixed with &quot;Faster base defence sequence&quot; option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)<br /> <br /> <br /> * Multiple Radar - Fixed. <br /> <br /> Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]<br /> :As I said, I used about the same as in you BaseFixer script:<br /> float shortDetection=pow(0.9f,smallRadars);<br /> float largeDetection=pow(0.8f,largeRadars);<br /> <br /> *(short *)(&amp;base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);<br /> *(short *)(&amp;base[0x12])=(short)((1.0-largeDetection)*100.0);<br /> :However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> * Accuracy reductions for long range snap and auto fire - Fixed. <br /> * Aircraft always ready for mission despite re-fuel/re-arm status - Fixed<br /> * Stack up base build orders in advance - Implemented<br /> * More smoke and fire - Fixed<br /> * Blaster drift and waypoint bug - Fixed<br /> * Stats visible during Equip phase - Implemented<br /> * Melee combat (bludgeoning) with any weapon - Fixed<br /> * With &quot;Council Funding Only&quot;, allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any &quot;income&quot; (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with &quot;Council Funding Only&quot;. Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)<br /> * Close Down Exploits<br /> ** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed<br /> <br /> == Warm Grenades ==<br /> <br /> It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them. <br /> <br /> This could be implemented by an extra bit of logic that increments the &quot;Turn When I Will Explode&quot; field by +2 if the grenade is being held/worn when the Explode check happens. <br /> <br /> For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE. <br /> <br /> Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)<br /> <br /> == Facility maintenance cost bug ==<br /> <br /> Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)<br /> :I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)<br /> ::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)<br /> :Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)<br /> :Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)<br /> ::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], &quot;Blind spots around the corner&quot;.<br /> Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground? <br /> :Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.<br /> :*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...<br /> mov esi, 11h<br /> ...<br /> loc_44004C:<br /> dec esi<br /> mov word ptr [esp+3Ch+elementsArray], 0<br /> jnz short loc_44004C<br /> :*ecx is initialized to point to the maintenance cost data (nothing wrong here)<br /> mov ecx, offset baseElements.maintenance<br /> :*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):<br /> movsx eax, ax<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000<br /> :we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].<br /> :*then after each row, we have this:<br /> add ecx, 10h<br /> :which explains why the cost changes for each row.<br /> :I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).<br /> :The fix required two patches:<br /> :*remove the incrementing of ecx for each row<br /> char nop[]={0x90,0x90,0x90};<br /> PatchInPlace(0x44066E,nop,3);<br /> :*make a working inner loop:<br /> char patch[]={<br /> 0x03, 0xc0, // add eax,eax<br /> 0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element<br /> 0x0f, 0xb6, 0xc0, // movzx eax, al<br /> 0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining<br /> };<br /> PatchInPlace(0x440651,patch,13);<br /> :this takes care of the nonsense code<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> <br /> Very interesting stuff! By the way I'm playing a &quot;Roswell&quot; game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)<br /> <br /> ==Grenade Status Indicator==<br /> <br /> Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go? <br /> :Hmm, I'll see if I can find something<br /> <br /> == Keyboard Support ==<br /> <br /> Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)<br /> :sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)<br /> <br /> :: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT) <br /> <br /> Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....<br /> Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)<br /> :I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)<br /> <br /> ----<br /> <br /> First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already. <br /> :Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)<br /> BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).<br /> :There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental. <br /> A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again. <br /> :I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.<br /> Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength? <br /> :At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.<br /> If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control? <br /> <br /> Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).<br /> :These two are on my secret todo list ;-)<br /> ::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)<br /> 80 item bug on base defense mission<br /> :May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...<br /> I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof! <br /> :I think this is a known issue with LOS, not sure though<br /> I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round). <br /> :I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look<br /> This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc. <br /> :Hmm, you do know I don't have the original source code available, don't you? :p<br /> Any plans to work on Terror from the deep? <br /> :I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)<br /> <br /> Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)<br /> <br /> == Inventory screen ammo weight bug ==<br /> <br /> I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)<br /> :Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)<br /> <br /> :: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)<br /> :Does not ring any bell. Any link?<br /> <br /> == Equipment issue ==<br /> Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)<br /> :There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)<br /> <br /> == Request For UFO PS Explosion Offset ==<br /> <br /> Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:<br /> <br /> &lt;i&gt;Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)&lt;/i&gt;<br /> <br /> I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)<br /> <br /> == Great new features ==<br /> <br /> Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)<br /> <br /> :OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap&gt;auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades. <br /> <br /> :I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:<br /> :* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units<br /> :* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien<br /> :* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it? <br /> :* In night missions, even with Big Brother &lt;strike&gt;and View All Locations&lt;/strike&gt; set, I could only see what my guys had illuminated &amp; seen. <br /> :* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)<br /> ::The &quot;Hack&quot; section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]<br /> :* With Alien Bases and View All Locations, the X-COM bases show up as pink.<br /> :* It wasn't obvious to me that I needed to set e.g. &quot;Initial Alien Bases=20&quot; rather than just &quot;Initial Alien Bases=1&quot;. I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> <br /> :Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission. <br /> :I have not developed Heavy Laser yet, &lt;strike&gt;nor beaten up any aliens in melee,&lt;/strike&gt; but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)<br /> <br /> :: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it. <br /> :::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]<br /> ::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)<br /> : I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:<br /> ::Glad you're having fun :-) [[User:Seb76|Seb76]]<br /> <br /> ::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader. <br /> : Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)<br /> ::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]<br /> <br /> <br /> == Base Disjoint Bug Fix ==<br /> A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. &lt;strike&gt;It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)&lt;/strike&gt;. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).<br /> : Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]<br /> <br /> I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)<br /> :Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)<br /> :Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]<br /> Yes I doubled checked a couple of times. I set the flag as<br /> <br /> Base Disjoint=1<br /> <br /> Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> : Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!<br /> <br /> == A couple of bugs to report ==<br /> <br /> Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message &quot;The Alien Food UFO was on an Damage Capacity mission in Power Sources.&quot; All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.<br /> <br /> The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> :Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)<br /> <br /> Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> <br /> :I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)<br /> <br /> ::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the &quot;crafts always ready&quot; option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)<br /> <br /> Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)<br /> <br /> :&quot;Raiding&quot; ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: &lt;pre&gt;Zone Discovered=Intel found out that the %s UFO was raiding %s&lt;/pre&gt;If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)<br /> <br /> :Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)<br /> <br /> ::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)<br /> :Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)<br /> <br /> Some more comments:<br /> # Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add &quot;usage&quot; comments to the .INI file?<br /> # Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!<br /> [[User:Spike|Spike]] 13:20, 2 January 2009 (CST)<br /> :What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)<br /> *Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game<br /> <br /> :: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)<br /> <br /> Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)<br /> Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)<br /> <br /> == Glitches with Alien Pets ==<br /> <br /> OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!<br /> <br /> * If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?<br /> * It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:<br /> ** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!<br /> ** Terror units can also equip weapons in their &quot;hands&quot;. Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)<br /> * I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly. <br /> <br /> This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):<br /> <br /> * When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error? <br /> <br /> Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!<br /> <br /> [[User:Spike|Spike]] 19:04, 5 March 2009 (CST)<br /> :My pleasure. It was the very reason I allowed it in the loader in the first place!<br /> :FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)<br /> <br /> I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy -&gt;&gt; no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!<br /> So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this &quot;retreating&quot; a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)<br /> :Thanks for the support, I'm bored of the &quot;the stuff does not work with ET&quot; thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)<br /> ::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)<br /> :Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)<br /> ::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)<br /> <br /> == TFTD Door problem ==<br /> <br /> Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> :Hi Talon81, what do you mean by &quot;other patches&quot;. Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)<br /> :Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)<br /> <br /> Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).<br /> <br /> If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)<br /> --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> <br /> : I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)<br /> <br /> :Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)<br /> <br /> == Initial Alien Bases ==<br /> <br /> OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)<br /> <br /> By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)<br /> :Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)<br /> <br /> Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)<br /> <br /> :OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)<br /> <br /> Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)<br /> <br /> == Won't work on my rig Vista+CE version ==<br /> <br /> Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.<br /> <br /> My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.<br /> <br /> * http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG<br /> * http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG<br /> --[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)<br /> :Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):<br /> <br /> [[Image:Dxwnd.png]]<br /> <br /> [[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)<br /> <br /> Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?<br /> <br /> http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)<br /> <br /> [edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.<br /> <br /> :I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:<br /> :[[Image:Scale2x.png]]<br /> <br /> :When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)<br /> <br /> <br /> ::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?<br /> :I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)<br /> :Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)<br /> <br /> The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. &lt;3<br /> :Uploaded a new version, you need to add a &quot;HQ4x=1&quot; line under the &quot;Mod&quot; section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)<br /> <br /> Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)<br /> <br /> ==Heavy laser mod==<br /> My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]<br /> <br /> :Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)<br /> :Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)<br /> <br /> ::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)<br /> <br /> ::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)<br /> <br /> I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)<br /> :Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)<br /> <br /> Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)<br /> <br /> OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)<br /> :I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)<br /> <br /> I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)<br /> :Hum, are youe using the &quot;dev&quot; version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)<br /> <br /> Not sure what you mean by &quot;dev&quot; version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)<br /> <br /> Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)<br /> :That's great ;-) By dev I was refering to the &quot;dev&quot; version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)<br /> <br /> == REng UFO with IDA ==<br /> <br /> Hi Seb =)<br /> <br /> I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.<br /> <br /> So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).<br /> <br /> Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.<br /> <br /> I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.<br /> <br /> My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).<br /> <br /> Any advice is deeply appreciated mate =)<br /> <br /> XCom forever!<br /> --[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)<br /> :Hi k9,<br /> :Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.<br /> :For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...<br /> :Good luck with your project,<br /> :[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)<br /> <br /> :::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...<br /> <br /> void InsertCall(int dst, void *func)<br /> {<br /> DWORD oldProtect;<br /> DWORD *pOffset=(DWORD *)(((char *)dst)+1);<br /> <br /> VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&amp;oldProtect);<br /> *(char *)dst=(char)0xE8;<br /> *pOffset=(int)func-(int)dst-5;<br /> VirtualProtect((void *)dst,5,oldProtect,&amp;oldProtect);<br /> }<br /> <br /> ::: This calculation here is interesting:<br /> <br /> *pOffset=(int)func-(int)dst-5;<br /> <br /> :::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).<br /> :The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).<br /> :The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)<br /> <br /> :::Can you suggest some good reading material to better understand this? Cheers!<br /> :::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)<br /> :You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the &quot;UFO Defense&quot; process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)<br /> <br /> == D3D ==<br /> <br /> If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has. <br /> <br /> I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)<br /> :You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)<br /> <br /> Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)<br /> <br /> OK I ran the &lt;b&gt;dxdiag&lt;/b&gt; utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)<br /> :Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.<br /> :Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)<br /> Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)<br /> <br /> D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J&amp;#39;ordos]] 19:09, 8 August 2009 (EDT)<br /> :edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*<br /> :Do you know if this card supports non power of two textures? [[User:Seb76|Seb76]] 05:10, 9 August 2009 (EDT)<br /> ::no idea, but since your new version works fine with the D3D option on I assume it doesn't :) [[User:J'ordos|J&amp;#39;ordos]] 11:38, 9 August 2009 (EDT)<br /> <br /> == Save equipment ==<br /> <br /> Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:<br /> <br /> *1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of &quot;invisible&quot; equipment!<br /> *Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips. <br /> *The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.<br /> *Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment. <br /> <br /> Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked? <br /> <br /> Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)<br /> :Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.<br /> :The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?<br /> :As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.<br /> :I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)<br /> ::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a &quot;before&quot; and &quot;after&quot;. [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)<br /> :In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)<br /> ::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns &amp; ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)<br /> :OK, I'll have a look at this, thanks for the effort.<br /> :Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the &quot;i/b&quot; one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)<br /> ::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)<br /> ::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)<br /> ::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)<br /> :I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)<br /> :: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)<br /> :Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)<br /> ::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=22184 2009-08-08T23:12:00Z

<p>J&#039;ordos: /* D3D */</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> :::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)<br /> ::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J&amp;#39;ordos]] 05:01, 9 September 2008 (PDT)<br /> : Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)<br /> ::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)<br /> :::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)<br /> :::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)<br /> ::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)<br /> ::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)<br /> :Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J&amp;#39;ordos]] 12:58, 26 April 2009 (EDT)<br /> ::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)<br /> <br /> OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your &quot;Full Auto&quot; mode would be 100% TUs for 10 rounds and your &quot;Burst Mode&quot; could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)<br /> <br /> : On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)<br /> <br /> Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ. <br /> <br /> Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz: <br /> <br /> See if you can get the &quot;hidden item&quot;, Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)<br /> <br /> :Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:<br /> :*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front<br /> :*reduce accuracy even further when shooting out of sight (this was mentionned in another post)<br /> :*change the damage model and reduce the probability that terrain is destroyed when shot<br /> :*have a cooldown period where the weapon is not useable (not sure if it's feasible though)<br /> <br /> ::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J&amp;#39;ordos]] 16:27, 7 September 2008 (PDT)<br /> :::Hm, I already cannibalized the unused &quot;open&quot; and &quot;close&quot; actions for the heavy laser mod, there is no more room for a new &quot;hit&quot; command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)<br /> <br /> :OK, here is the last draft before I finalize:<br /> :*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)<br /> :*Each shot of a burst will reduce the accuracy (amount not determined yet)<br /> :*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL<br /> :If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)<br /> <br /> Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)<br /> :OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)<br /> <br /> It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J&amp;#39;ordos]] 12:41, 28 February 2009 (CST)<br /> :It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)<br /> <br /> Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.<br /> --[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)<br /> <br /> :The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the &quot;shortcuts&quot; patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)<br /> <br /> I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)<br /> <br /> == Wish List please please please ==<br /> <br /> <br /> <br /> === New and Outstanding Requests ===<br /> <br /> * Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.<br /> [Utilities]<br /> Run Utilities=0|1<br /> Run before battle=&quot;xcomutil ...&quot;<br /> Run after battle =&quot;xcomutil ...&quot;<br /> Run before base screen=&quot;xcomutil ...&quot; <br /> <br /> * Allow scrolling the map with the keyboard. &quot;WASD&quot; as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.<br /> <br /> * Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.<br /> <br /> * Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.<br /> <br /> * Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode. <br /> <br /> : Has this been completed via the &quot;Save Reserve Mode&quot; feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair. <br /> <br /> * Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:<br /> ** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has &gt;0 units before allowing it to start. <br /> ** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.<br /> ** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix. <br /> * Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns &quot;no line of fire&quot;. This would avoid a lot of the &quot;hit the ceiling&quot; issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''<br /> * Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.<br /> * Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]]. <br /> <br /> <br /> * [[Wish List#Prior Recon of Battlefield|&quot;Eye in the Sky&quot;]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings. <br /> <br /> * Grenades that [[Wish List#Warm Grenades|function normally]].<br /> <br /> * Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].<br /> <br /> ==== Incendiary Bug ====<br /> <br /> * Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].<br /> <br /> :: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the &quot;end of turn&quot; criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)<br /> <br /> OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:<br /> <br /> # In area of effect<br /> ##add fire to tiles<br /> ##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)<br /> # IF a unit was hit directly<br /> ## check to see if it catches fire<br /> ## ''possibly'' do &quot;impact&quot; damage. <br /> # Return, '''without''' calling the end-of-turn smoke/fire routine<br /> <br /> And it's entirely possible there was never supposed to be any &quot;impact&quot; damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the &quot;impact&quot; damage could just be a side effect of the funky fire bug - applying the 5-10 &quot;on fire&quot; damage right away, when it was meant to be applied at end-of-turn. <br /> <br /> [[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)<br /> :Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)<br /> <br /> ::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences. <br /> <br /> ::It will be interesting to see if patching out all 4 calls eliminates &quot;impact&quot; IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but &quot;impact&quot; damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff! <br /> <br /> ::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)<br /> <br /> ==== See Also ====<br /> <br /> *[[Wish List]]<br /> *[[Known Bugs]]<br /> *[[Exploits]]<br /> <br /> === Completed Items - Thanks Seb! ===<br /> <br /> See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]<br /> <br /> * Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault. <br /> :The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :: Completed with the &quot;Keep Base Navigation Tables&quot; option. <br /> <br /> * Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the &quot;Roswell Incident&quot;. Crash site would be automatically detected &amp; UFO would have random damage. <br /> :Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :Update: feature almost complete, time to bake a new version ;-)<br /> <br /> :[[Image:Roswell.png]]<br /> <br /> :There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)<br /> <br /> <br /> * Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)<br /> <br /> : Fixed with &quot;Faster base defence sequence&quot; option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)<br /> <br /> <br /> * Multiple Radar - Fixed. <br /> <br /> Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]<br /> :As I said, I used about the same as in you BaseFixer script:<br /> float shortDetection=pow(0.9f,smallRadars);<br /> float largeDetection=pow(0.8f,largeRadars);<br /> <br /> *(short *)(&amp;base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);<br /> *(short *)(&amp;base[0x12])=(short)((1.0-largeDetection)*100.0);<br /> :However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> * Accuracy reductions for long range snap and auto fire - Fixed. <br /> * Aircraft always ready for mission despite re-fuel/re-arm status - Fixed<br /> * Stack up base build orders in advance - Implemented<br /> * More smoke and fire - Fixed<br /> * Blaster drift and waypoint bug - Fixed<br /> * Stats visible during Equip phase - Implemented<br /> * Melee combat (bludgeoning) with any weapon - Fixed<br /> * With &quot;Council Funding Only&quot;, allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any &quot;income&quot; (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with &quot;Council Funding Only&quot;. Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)<br /> * Close Down Exploits<br /> ** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed<br /> <br /> == Warm Grenades ==<br /> <br /> It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them. <br /> <br /> This could be implemented by an extra bit of logic that increments the &quot;Turn When I Will Explode&quot; field by +2 if the grenade is being held/worn when the Explode check happens. <br /> <br /> For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE. <br /> <br /> Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)<br /> <br /> == Facility maintenance cost bug ==<br /> <br /> Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)<br /> :I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)<br /> ::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)<br /> :Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)<br /> :Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)<br /> ::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], &quot;Blind spots around the corner&quot;.<br /> Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground? <br /> :Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.<br /> :*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...<br /> mov esi, 11h<br /> ...<br /> loc_44004C:<br /> dec esi<br /> mov word ptr [esp+3Ch+elementsArray], 0<br /> jnz short loc_44004C<br /> :*ecx is initialized to point to the maintenance cost data (nothing wrong here)<br /> mov ecx, offset baseElements.maintenance<br /> :*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):<br /> movsx eax, ax<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000<br /> :we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].<br /> :*then after each row, we have this:<br /> add ecx, 10h<br /> :which explains why the cost changes for each row.<br /> :I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).<br /> :The fix required two patches:<br /> :*remove the incrementing of ecx for each row<br /> char nop[]={0x90,0x90,0x90};<br /> PatchInPlace(0x44066E,nop,3);<br /> :*make a working inner loop:<br /> char patch[]={<br /> 0x03, 0xc0, // add eax,eax<br /> 0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element<br /> 0x0f, 0xb6, 0xc0, // movzx eax, al<br /> 0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining<br /> };<br /> PatchInPlace(0x440651,patch,13);<br /> :this takes care of the nonsense code<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> <br /> Very interesting stuff! By the way I'm playing a &quot;Roswell&quot; game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)<br /> <br /> ==Grenade Status Indicator==<br /> <br /> Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go? <br /> :Hmm, I'll see if I can find something<br /> <br /> == Keyboard Support ==<br /> <br /> Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)<br /> :sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)<br /> <br /> :: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT) <br /> <br /> Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....<br /> Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)<br /> :I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)<br /> <br /> ----<br /> <br /> First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already. <br /> :Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)<br /> BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).<br /> :There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental. <br /> A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again. <br /> :I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.<br /> Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength? <br /> :At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.<br /> If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control? <br /> <br /> Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).<br /> :These two are on my secret todo list ;-)<br /> ::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)<br /> 80 item bug on base defense mission<br /> :May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...<br /> I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof! <br /> :I think this is a known issue with LOS, not sure though<br /> I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round). <br /> :I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look<br /> This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc. <br /> :Hmm, you do know I don't have the original source code available, don't you? :p<br /> Any plans to work on Terror from the deep? <br /> :I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)<br /> <br /> Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)<br /> <br /> == Inventory screen ammo weight bug ==<br /> <br /> I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)<br /> :Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)<br /> <br /> :: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)<br /> :Does not ring any bell. Any link?<br /> <br /> == Equipment issue ==<br /> Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)<br /> :There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)<br /> <br /> == Request For UFO PS Explosion Offset ==<br /> <br /> Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:<br /> <br /> &lt;i&gt;Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)&lt;/i&gt;<br /> <br /> I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)<br /> <br /> == Great new features ==<br /> <br /> Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)<br /> <br /> :OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap&gt;auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades. <br /> <br /> :I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:<br /> :* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units<br /> :* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien<br /> :* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it? <br /> :* In night missions, even with Big Brother &lt;strike&gt;and View All Locations&lt;/strike&gt; set, I could only see what my guys had illuminated &amp; seen. <br /> :* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)<br /> ::The &quot;Hack&quot; section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]<br /> :* With Alien Bases and View All Locations, the X-COM bases show up as pink.<br /> :* It wasn't obvious to me that I needed to set e.g. &quot;Initial Alien Bases=20&quot; rather than just &quot;Initial Alien Bases=1&quot;. I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> <br /> :Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission. <br /> :I have not developed Heavy Laser yet, &lt;strike&gt;nor beaten up any aliens in melee,&lt;/strike&gt; but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)<br /> <br /> :: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it. <br /> :::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]<br /> ::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)<br /> : I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:<br /> ::Glad you're having fun :-) [[User:Seb76|Seb76]]<br /> <br /> ::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader. <br /> : Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)<br /> ::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]<br /> <br /> <br /> == Base Disjoint Bug Fix ==<br /> A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. &lt;strike&gt;It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)&lt;/strike&gt;. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).<br /> : Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]<br /> <br /> I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)<br /> :Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)<br /> :Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]<br /> Yes I doubled checked a couple of times. I set the flag as<br /> <br /> Base Disjoint=1<br /> <br /> Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> : Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!<br /> <br /> == A couple of bugs to report ==<br /> <br /> Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message &quot;The Alien Food UFO was on an Damage Capacity mission in Power Sources.&quot; All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.<br /> <br /> The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> :Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)<br /> <br /> Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> <br /> :I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)<br /> <br /> ::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the &quot;crafts always ready&quot; option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)<br /> <br /> Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)<br /> <br /> :&quot;Raiding&quot; ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: &lt;pre&gt;Zone Discovered=Intel found out that the %s UFO was raiding %s&lt;/pre&gt;If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)<br /> <br /> :Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)<br /> <br /> ::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)<br /> :Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)<br /> <br /> Some more comments:<br /> # Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add &quot;usage&quot; comments to the .INI file?<br /> # Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!<br /> [[User:Spike|Spike]] 13:20, 2 January 2009 (CST)<br /> :What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)<br /> *Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game<br /> <br /> :: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)<br /> <br /> Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)<br /> Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)<br /> <br /> == Glitches with Alien Pets ==<br /> <br /> OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!<br /> <br /> * If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?<br /> * It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:<br /> ** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!<br /> ** Terror units can also equip weapons in their &quot;hands&quot;. Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)<br /> * I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly. <br /> <br /> This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):<br /> <br /> * When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error? <br /> <br /> Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!<br /> <br /> [[User:Spike|Spike]] 19:04, 5 March 2009 (CST)<br /> :My pleasure. It was the very reason I allowed it in the loader in the first place!<br /> :FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)<br /> <br /> I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy -&gt;&gt; no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!<br /> So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this &quot;retreating&quot; a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)<br /> :Thanks for the support, I'm bored of the &quot;the stuff does not work with ET&quot; thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)<br /> ::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)<br /> :Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)<br /> ::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)<br /> <br /> == TFTD Door problem ==<br /> <br /> Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> :Hi Talon81, what do you mean by &quot;other patches&quot;. Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)<br /> :Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)<br /> <br /> Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).<br /> <br /> If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)<br /> --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> <br /> : I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)<br /> <br /> :Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)<br /> <br /> == Initial Alien Bases ==<br /> <br /> OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)<br /> <br /> By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)<br /> :Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)<br /> <br /> Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)<br /> <br /> :OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)<br /> <br /> Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)<br /> <br /> == Won't work on my rig Vista+CE version ==<br /> <br /> Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.<br /> <br /> My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.<br /> <br /> * http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG<br /> * http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG<br /> --[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)<br /> :Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):<br /> <br /> [[Image:Dxwnd.png]]<br /> <br /> [[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)<br /> <br /> Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?<br /> <br /> http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)<br /> <br /> [edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.<br /> <br /> :I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:<br /> :[[Image:Scale2x.png]]<br /> <br /> :When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)<br /> <br /> <br /> ::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?<br /> :I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)<br /> :Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)<br /> <br /> The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. &lt;3<br /> :Uploaded a new version, you need to add a &quot;HQ4x=1&quot; line under the &quot;Mod&quot; section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)<br /> <br /> Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)<br /> <br /> ==Heavy laser mod==<br /> My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]<br /> <br /> :Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)<br /> :Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)<br /> <br /> ::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)<br /> <br /> ::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)<br /> <br /> I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)<br /> :Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)<br /> <br /> Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)<br /> <br /> OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)<br /> :I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)<br /> <br /> I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)<br /> :Hum, are youe using the &quot;dev&quot; version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)<br /> <br /> Not sure what you mean by &quot;dev&quot; version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)<br /> <br /> Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)<br /> :That's great ;-) By dev I was refering to the &quot;dev&quot; version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)<br /> <br /> == REng UFO with IDA ==<br /> <br /> Hi Seb =)<br /> <br /> I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.<br /> <br /> So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).<br /> <br /> Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.<br /> <br /> I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.<br /> <br /> My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).<br /> <br /> Any advice is deeply appreciated mate =)<br /> <br /> XCom forever!<br /> --[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)<br /> :Hi k9,<br /> :Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.<br /> :For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...<br /> :Good luck with your project,<br /> :[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)<br /> <br /> :::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...<br /> <br /> void InsertCall(int dst, void *func)<br /> {<br /> DWORD oldProtect;<br /> DWORD *pOffset=(DWORD *)(((char *)dst)+1);<br /> <br /> VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&amp;oldProtect);<br /> *(char *)dst=(char)0xE8;<br /> *pOffset=(int)func-(int)dst-5;<br /> VirtualProtect((void *)dst,5,oldProtect,&amp;oldProtect);<br /> }<br /> <br /> ::: This calculation here is interesting:<br /> <br /> *pOffset=(int)func-(int)dst-5;<br /> <br /> :::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).<br /> :The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).<br /> :The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)<br /> <br /> :::Can you suggest some good reading material to better understand this? Cheers!<br /> :::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)<br /> :You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the &quot;UFO Defense&quot; process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)<br /> <br /> == D3D ==<br /> <br /> If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has. <br /> <br /> I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)<br /> :You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)<br /> <br /> Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)<br /> <br /> OK I ran the &lt;b&gt;dxdiag&lt;/b&gt; utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)<br /> :Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.<br /> :Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)<br /> Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)<br /> <br /> D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J&amp;#39;ordos]] 19:09, 8 August 2009 (EDT)<br /> :edit: forgot to mention, I have directx 9.0c installed and dxdiag reports no problems. I have a Geforce2 MX *blushes*<br /> <br /> == Save equipment ==<br /> <br /> Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:<br /> <br /> *1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of &quot;invisible&quot; equipment!<br /> *Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips. <br /> *The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.<br /> *Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment. <br /> <br /> Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked? <br /> <br /> Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)<br /> :Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.<br /> :The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?<br /> :As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.<br /> :I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)<br /> ::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a &quot;before&quot; and &quot;after&quot;. [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)<br /> :In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)<br /> ::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns &amp; ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)<br /> :OK, I'll have a look at this, thanks for the effort.<br /> :Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the &quot;i/b&quot; one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)<br /> ::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)<br /> ::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)<br /> ::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)<br /> :I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)<br /> :: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)<br /> :Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)<br /> ::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=22183 2009-08-08T23:09:15Z

<p>J&#039;ordos: forgot signature</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> :::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)<br /> ::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J&amp;#39;ordos]] 05:01, 9 September 2008 (PDT)<br /> : Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)<br /> ::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)<br /> :::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)<br /> :::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)<br /> ::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)<br /> ::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)<br /> :Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J&amp;#39;ordos]] 12:58, 26 April 2009 (EDT)<br /> ::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)<br /> <br /> OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your &quot;Full Auto&quot; mode would be 100% TUs for 10 rounds and your &quot;Burst Mode&quot; could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)<br /> <br /> : On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)<br /> <br /> Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ. <br /> <br /> Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz: <br /> <br /> See if you can get the &quot;hidden item&quot;, Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)<br /> <br /> :Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:<br /> :*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front<br /> :*reduce accuracy even further when shooting out of sight (this was mentionned in another post)<br /> :*change the damage model and reduce the probability that terrain is destroyed when shot<br /> :*have a cooldown period where the weapon is not useable (not sure if it's feasible though)<br /> <br /> ::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J&amp;#39;ordos]] 16:27, 7 September 2008 (PDT)<br /> :::Hm, I already cannibalized the unused &quot;open&quot; and &quot;close&quot; actions for the heavy laser mod, there is no more room for a new &quot;hit&quot; command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)<br /> <br /> :OK, here is the last draft before I finalize:<br /> :*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)<br /> :*Each shot of a burst will reduce the accuracy (amount not determined yet)<br /> :*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL<br /> :If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)<br /> <br /> Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)<br /> :OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)<br /> <br /> It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J&amp;#39;ordos]] 12:41, 28 February 2009 (CST)<br /> :It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)<br /> <br /> Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.<br /> --[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)<br /> <br /> :The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the &quot;shortcuts&quot; patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)<br /> <br /> I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)<br /> <br /> == Wish List please please please ==<br /> <br /> <br /> <br /> === New and Outstanding Requests ===<br /> <br /> * Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.<br /> [Utilities]<br /> Run Utilities=0|1<br /> Run before battle=&quot;xcomutil ...&quot;<br /> Run after battle =&quot;xcomutil ...&quot;<br /> Run before base screen=&quot;xcomutil ...&quot; <br /> <br /> * Allow scrolling the map with the keyboard. &quot;WASD&quot; as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.<br /> <br /> * Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.<br /> <br /> * Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.<br /> <br /> * Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode. <br /> <br /> : Has this been completed via the &quot;Save Reserve Mode&quot; feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair. <br /> <br /> * Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:<br /> ** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has &gt;0 units before allowing it to start. <br /> ** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.<br /> ** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix. <br /> * Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns &quot;no line of fire&quot;. This would avoid a lot of the &quot;hit the ceiling&quot; issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''<br /> * Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.<br /> * Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]]. <br /> <br /> <br /> * [[Wish List#Prior Recon of Battlefield|&quot;Eye in the Sky&quot;]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings. <br /> <br /> * Grenades that [[Wish List#Warm Grenades|function normally]].<br /> <br /> * Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].<br /> <br /> ==== Incendiary Bug ====<br /> <br /> * Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].<br /> <br /> :: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the &quot;end of turn&quot; criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)<br /> <br /> OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:<br /> <br /> # In area of effect<br /> ##add fire to tiles<br /> ##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)<br /> # IF a unit was hit directly<br /> ## check to see if it catches fire<br /> ## ''possibly'' do &quot;impact&quot; damage. <br /> # Return, '''without''' calling the end-of-turn smoke/fire routine<br /> <br /> And it's entirely possible there was never supposed to be any &quot;impact&quot; damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the &quot;impact&quot; damage could just be a side effect of the funky fire bug - applying the 5-10 &quot;on fire&quot; damage right away, when it was meant to be applied at end-of-turn. <br /> <br /> [[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)<br /> :Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)<br /> <br /> ::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences. <br /> <br /> ::It will be interesting to see if patching out all 4 calls eliminates &quot;impact&quot; IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but &quot;impact&quot; damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff! <br /> <br /> ::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)<br /> <br /> ==== See Also ====<br /> <br /> *[[Wish List]]<br /> *[[Known Bugs]]<br /> *[[Exploits]]<br /> <br /> === Completed Items - Thanks Seb! ===<br /> <br /> See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]<br /> <br /> * Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault. <br /> :The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :: Completed with the &quot;Keep Base Navigation Tables&quot; option. <br /> <br /> * Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the &quot;Roswell Incident&quot;. Crash site would be automatically detected &amp; UFO would have random damage. <br /> :Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :Update: feature almost complete, time to bake a new version ;-)<br /> <br /> :[[Image:Roswell.png]]<br /> <br /> :There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)<br /> <br /> <br /> * Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)<br /> <br /> : Fixed with &quot;Faster base defence sequence&quot; option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)<br /> <br /> <br /> * Multiple Radar - Fixed. <br /> <br /> Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]<br /> :As I said, I used about the same as in you BaseFixer script:<br /> float shortDetection=pow(0.9f,smallRadars);<br /> float largeDetection=pow(0.8f,largeRadars);<br /> <br /> *(short *)(&amp;base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);<br /> *(short *)(&amp;base[0x12])=(short)((1.0-largeDetection)*100.0);<br /> :However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> * Accuracy reductions for long range snap and auto fire - Fixed. <br /> * Aircraft always ready for mission despite re-fuel/re-arm status - Fixed<br /> * Stack up base build orders in advance - Implemented<br /> * More smoke and fire - Fixed<br /> * Blaster drift and waypoint bug - Fixed<br /> * Stats visible during Equip phase - Implemented<br /> * Melee combat (bludgeoning) with any weapon - Fixed<br /> * With &quot;Council Funding Only&quot;, allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any &quot;income&quot; (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with &quot;Council Funding Only&quot;. Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)<br /> * Close Down Exploits<br /> ** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed<br /> <br /> == Warm Grenades ==<br /> <br /> It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them. <br /> <br /> This could be implemented by an extra bit of logic that increments the &quot;Turn When I Will Explode&quot; field by +2 if the grenade is being held/worn when the Explode check happens. <br /> <br /> For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE. <br /> <br /> Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)<br /> <br /> == Facility maintenance cost bug ==<br /> <br /> Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)<br /> :I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)<br /> ::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)<br /> :Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)<br /> :Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)<br /> ::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], &quot;Blind spots around the corner&quot;.<br /> Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground? <br /> :Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.<br /> :*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...<br /> mov esi, 11h<br /> ...<br /> loc_44004C:<br /> dec esi<br /> mov word ptr [esp+3Ch+elementsArray], 0<br /> jnz short loc_44004C<br /> :*ecx is initialized to point to the maintenance cost data (nothing wrong here)<br /> mov ecx, offset baseElements.maintenance<br /> :*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):<br /> movsx eax, ax<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000<br /> :we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].<br /> :*then after each row, we have this:<br /> add ecx, 10h<br /> :which explains why the cost changes for each row.<br /> :I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).<br /> :The fix required two patches:<br /> :*remove the incrementing of ecx for each row<br /> char nop[]={0x90,0x90,0x90};<br /> PatchInPlace(0x44066E,nop,3);<br /> :*make a working inner loop:<br /> char patch[]={<br /> 0x03, 0xc0, // add eax,eax<br /> 0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element<br /> 0x0f, 0xb6, 0xc0, // movzx eax, al<br /> 0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining<br /> };<br /> PatchInPlace(0x440651,patch,13);<br /> :this takes care of the nonsense code<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> <br /> Very interesting stuff! By the way I'm playing a &quot;Roswell&quot; game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)<br /> <br /> ==Grenade Status Indicator==<br /> <br /> Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go? <br /> :Hmm, I'll see if I can find something<br /> <br /> == Keyboard Support ==<br /> <br /> Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)<br /> :sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)<br /> <br /> :: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT) <br /> <br /> Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....<br /> Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)<br /> :I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)<br /> <br /> ----<br /> <br /> First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already. <br /> :Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)<br /> BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).<br /> :There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental. <br /> A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again. <br /> :I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.<br /> Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength? <br /> :At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.<br /> If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control? <br /> <br /> Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).<br /> :These two are on my secret todo list ;-)<br /> ::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)<br /> 80 item bug on base defense mission<br /> :May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...<br /> I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof! <br /> :I think this is a known issue with LOS, not sure though<br /> I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round). <br /> :I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look<br /> This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc. <br /> :Hmm, you do know I don't have the original source code available, don't you? :p<br /> Any plans to work on Terror from the deep? <br /> :I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)<br /> <br /> Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)<br /> <br /> == Inventory screen ammo weight bug ==<br /> <br /> I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)<br /> :Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)<br /> <br /> :: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)<br /> :Does not ring any bell. Any link?<br /> <br /> == Equipment issue ==<br /> Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)<br /> :There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)<br /> <br /> == Request For UFO PS Explosion Offset ==<br /> <br /> Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:<br /> <br /> &lt;i&gt;Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)&lt;/i&gt;<br /> <br /> I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)<br /> <br /> == Great new features ==<br /> <br /> Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)<br /> <br /> :OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap&gt;auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades. <br /> <br /> :I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:<br /> :* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units<br /> :* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien<br /> :* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it? <br /> :* In night missions, even with Big Brother &lt;strike&gt;and View All Locations&lt;/strike&gt; set, I could only see what my guys had illuminated &amp; seen. <br /> :* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)<br /> ::The &quot;Hack&quot; section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]<br /> :* With Alien Bases and View All Locations, the X-COM bases show up as pink.<br /> :* It wasn't obvious to me that I needed to set e.g. &quot;Initial Alien Bases=20&quot; rather than just &quot;Initial Alien Bases=1&quot;. I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> <br /> :Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission. <br /> :I have not developed Heavy Laser yet, &lt;strike&gt;nor beaten up any aliens in melee,&lt;/strike&gt; but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)<br /> <br /> :: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it. <br /> :::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]<br /> ::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)<br /> : I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:<br /> ::Glad you're having fun :-) [[User:Seb76|Seb76]]<br /> <br /> ::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader. <br /> : Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)<br /> ::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]<br /> <br /> <br /> == Base Disjoint Bug Fix ==<br /> A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. &lt;strike&gt;It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)&lt;/strike&gt;. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).<br /> : Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]<br /> <br /> I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)<br /> :Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)<br /> :Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]<br /> Yes I doubled checked a couple of times. I set the flag as<br /> <br /> Base Disjoint=1<br /> <br /> Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> : Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!<br /> <br /> == A couple of bugs to report ==<br /> <br /> Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message &quot;The Alien Food UFO was on an Damage Capacity mission in Power Sources.&quot; All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.<br /> <br /> The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> :Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)<br /> <br /> Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> <br /> :I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)<br /> <br /> ::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the &quot;crafts always ready&quot; option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)<br /> <br /> Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)<br /> <br /> :&quot;Raiding&quot; ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: &lt;pre&gt;Zone Discovered=Intel found out that the %s UFO was raiding %s&lt;/pre&gt;If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)<br /> <br /> :Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)<br /> <br /> ::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)<br /> :Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)<br /> <br /> Some more comments:<br /> # Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add &quot;usage&quot; comments to the .INI file?<br /> # Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!<br /> [[User:Spike|Spike]] 13:20, 2 January 2009 (CST)<br /> :What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)<br /> *Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game<br /> <br /> :: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)<br /> <br /> Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)<br /> Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)<br /> <br /> == Glitches with Alien Pets ==<br /> <br /> OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!<br /> <br /> * If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?<br /> * It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:<br /> ** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!<br /> ** Terror units can also equip weapons in their &quot;hands&quot;. Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)<br /> * I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly. <br /> <br /> This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):<br /> <br /> * When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error? <br /> <br /> Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!<br /> <br /> [[User:Spike|Spike]] 19:04, 5 March 2009 (CST)<br /> :My pleasure. It was the very reason I allowed it in the loader in the first place!<br /> :FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)<br /> <br /> I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy -&gt;&gt; no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!<br /> So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this &quot;retreating&quot; a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)<br /> :Thanks for the support, I'm bored of the &quot;the stuff does not work with ET&quot; thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)<br /> ::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)<br /> :Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)<br /> ::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)<br /> <br /> == TFTD Door problem ==<br /> <br /> Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> :Hi Talon81, what do you mean by &quot;other patches&quot;. Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)<br /> :Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)<br /> <br /> Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).<br /> <br /> If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)<br /> --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> <br /> : I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)<br /> <br /> :Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)<br /> <br /> == Initial Alien Bases ==<br /> <br /> OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)<br /> <br /> By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)<br /> :Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)<br /> <br /> Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)<br /> <br /> :OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)<br /> <br /> Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)<br /> <br /> == Won't work on my rig Vista+CE version ==<br /> <br /> Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.<br /> <br /> My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.<br /> <br /> * http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG<br /> * http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG<br /> --[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)<br /> :Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):<br /> <br /> [[Image:Dxwnd.png]]<br /> <br /> [[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)<br /> <br /> Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?<br /> <br /> http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)<br /> <br /> [edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.<br /> <br /> :I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:<br /> :[[Image:Scale2x.png]]<br /> <br /> :When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)<br /> <br /> <br /> ::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?<br /> :I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)<br /> :Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)<br /> <br /> The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. &lt;3<br /> :Uploaded a new version, you need to add a &quot;HQ4x=1&quot; line under the &quot;Mod&quot; section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)<br /> <br /> Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)<br /> <br /> ==Heavy laser mod==<br /> My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]<br /> <br /> :Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)<br /> :Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)<br /> <br /> ::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)<br /> <br /> ::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)<br /> <br /> I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)<br /> :Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)<br /> <br /> Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)<br /> <br /> OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)<br /> :I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)<br /> <br /> I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)<br /> :Hum, are youe using the &quot;dev&quot; version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)<br /> <br /> Not sure what you mean by &quot;dev&quot; version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)<br /> <br /> Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)<br /> :That's great ;-) By dev I was refering to the &quot;dev&quot; version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)<br /> <br /> == REng UFO with IDA ==<br /> <br /> Hi Seb =)<br /> <br /> I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.<br /> <br /> So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).<br /> <br /> Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.<br /> <br /> I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.<br /> <br /> My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).<br /> <br /> Any advice is deeply appreciated mate =)<br /> <br /> XCom forever!<br /> --[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)<br /> :Hi k9,<br /> :Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.<br /> :For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...<br /> :Good luck with your project,<br /> :[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)<br /> <br /> :::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...<br /> <br /> void InsertCall(int dst, void *func)<br /> {<br /> DWORD oldProtect;<br /> DWORD *pOffset=(DWORD *)(((char *)dst)+1);<br /> <br /> VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&amp;oldProtect);<br /> *(char *)dst=(char)0xE8;<br /> *pOffset=(int)func-(int)dst-5;<br /> VirtualProtect((void *)dst,5,oldProtect,&amp;oldProtect);<br /> }<br /> <br /> ::: This calculation here is interesting:<br /> <br /> *pOffset=(int)func-(int)dst-5;<br /> <br /> :::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).<br /> :The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).<br /> :The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)<br /> <br /> :::Can you suggest some good reading material to better understand this? Cheers!<br /> :::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)<br /> :You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the &quot;UFO Defense&quot; process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)<br /> <br /> == D3D ==<br /> <br /> If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has. <br /> <br /> I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)<br /> :You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)<br /> <br /> Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)<br /> <br /> OK I ran the &lt;b&gt;dxdiag&lt;/b&gt; utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)<br /> :Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.<br /> :Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)<br /> Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)<br /> <br /> D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'. [[User:J'ordos|J&amp;#39;ordos]] 19:09, 8 August 2009 (EDT)<br /> <br /> == Save equipment ==<br /> <br /> Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:<br /> <br /> *1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of &quot;invisible&quot; equipment!<br /> *Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips. <br /> *The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.<br /> *Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment. <br /> <br /> Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked? <br /> <br /> Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)<br /> :Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.<br /> :The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?<br /> :As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.<br /> :I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)<br /> ::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a &quot;before&quot; and &quot;after&quot;. [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)<br /> :In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)<br /> ::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns &amp; ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)<br /> :OK, I'll have a look at this, thanks for the effort.<br /> :Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the &quot;i/b&quot; one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)<br /> ::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)<br /> ::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)<br /> ::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)<br /> :I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)<br /> :: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)<br /> :Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)<br /> ::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=22182 2009-08-08T23:08:03Z

<p>J&#039;ordos: /* D3D */</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> :::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)<br /> ::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J&amp;#39;ordos]] 05:01, 9 September 2008 (PDT)<br /> : Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)<br /> ::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)<br /> :::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)<br /> :::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)<br /> ::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)<br /> ::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)<br /> :Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J&amp;#39;ordos]] 12:58, 26 April 2009 (EDT)<br /> ::Yeah, it is possible ^_^ But you now, it was never officially supported, it worked more or less by chance ;-) As I said on the forum, it might be possible the older version of the loader still works (you can use the old loader with a recent patcher DLL, it should be OK), but I got little feedback so I don't know if I'm correct... [[User:Seb76|Seb76]] 16:13, 27 April 2009 (EDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)<br /> <br /> OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your &quot;Full Auto&quot; mode would be 100% TUs for 10 rounds and your &quot;Burst Mode&quot; could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)<br /> <br /> : On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)<br /> <br /> Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ. <br /> <br /> Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz: <br /> <br /> See if you can get the &quot;hidden item&quot;, Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)<br /> <br /> :Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:<br /> :*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front<br /> :*reduce accuracy even further when shooting out of sight (this was mentionned in another post)<br /> :*change the damage model and reduce the probability that terrain is destroyed when shot<br /> :*have a cooldown period where the weapon is not useable (not sure if it's feasible though)<br /> <br /> ::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J&amp;#39;ordos]] 16:27, 7 September 2008 (PDT)<br /> :::Hm, I already cannibalized the unused &quot;open&quot; and &quot;close&quot; actions for the heavy laser mod, there is no more room for a new &quot;hit&quot; command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)<br /> <br /> :OK, here is the last draft before I finalize:<br /> :*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)<br /> :*Each shot of a burst will reduce the accuracy (amount not determined yet)<br /> :*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL<br /> :If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)<br /> <br /> Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)<br /> :OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)<br /> <br /> It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J&amp;#39;ordos]] 12:41, 28 February 2009 (CST)<br /> :It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)<br /> <br /> Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.<br /> --[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)<br /> <br /> :The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the &quot;shortcuts&quot; patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)<br /> <br /> I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)<br /> <br /> == Wish List please please please ==<br /> <br /> <br /> <br /> === New and Outstanding Requests ===<br /> <br /> * Replace the batch file that runs xcomutil. Make it so the loader will call an outside program at certian points. Add a section to the config file that will allow the user to pick a program to be run.<br /> [Utilities]<br /> Run Utilities=0|1<br /> Run before battle=&quot;xcomutil ...&quot;<br /> Run after battle =&quot;xcomutil ...&quot;<br /> Run before base screen=&quot;xcomutil ...&quot; <br /> <br /> * Allow scrolling the map with the keyboard. &quot;WASD&quot; as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.<br /> <br /> * Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.<br /> <br /> * Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.<br /> <br /> * Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode. <br /> <br /> : Has this been completed via the &quot;Save Reserve Mode&quot; feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair. <br /> <br /> * Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:<br /> ** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has &gt;0 units before allowing it to start. <br /> ** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.<br /> ** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix. <br /> * Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns &quot;no line of fire&quot;. This would avoid a lot of the &quot;hit the ceiling&quot; issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''<br /> * Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.<br /> * Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]]. <br /> <br /> <br /> * [[Wish List#Prior Recon of Battlefield|&quot;Eye in the Sky&quot;]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings. <br /> <br /> * Grenades that [[Wish List#Warm Grenades|function normally]].<br /> <br /> * Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].<br /> <br /> ==== Incendiary Bug ====<br /> <br /> * Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].<br /> <br /> :: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the &quot;end of turn&quot; criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)<br /> <br /> OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:<br /> <br /> # In area of effect<br /> ##add fire to tiles<br /> ##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)<br /> # IF a unit was hit directly<br /> ## check to see if it catches fire<br /> ## ''possibly'' do &quot;impact&quot; damage. <br /> # Return, '''without''' calling the end-of-turn smoke/fire routine<br /> <br /> And it's entirely possible there was never supposed to be any &quot;impact&quot; damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the &quot;impact&quot; damage could just be a side effect of the funky fire bug - applying the 5-10 &quot;on fire&quot; damage right away, when it was meant to be applied at end-of-turn. <br /> <br /> [[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)<br /> :Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)<br /> <br /> ::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences. <br /> <br /> ::It will be interesting to see if patching out all 4 calls eliminates &quot;impact&quot; IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but &quot;impact&quot; damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff! <br /> <br /> ::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)<br /> <br /> ==== See Also ====<br /> <br /> *[[Wish List]]<br /> *[[Known Bugs]]<br /> *[[Exploits]]<br /> <br /> === Completed Items - Thanks Seb! ===<br /> <br /> See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]<br /> <br /> * Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault. <br /> :The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :: Completed with the &quot;Keep Base Navigation Tables&quot; option. <br /> <br /> * Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the &quot;Roswell Incident&quot;. Crash site would be automatically detected &amp; UFO would have random damage. <br /> :Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :Update: feature almost complete, time to bake a new version ;-)<br /> <br /> :[[Image:Roswell.png]]<br /> <br /> :There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)<br /> <br /> <br /> * Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)<br /> <br /> : Fixed with &quot;Faster base defence sequence&quot; option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)<br /> <br /> <br /> * Multiple Radar - Fixed. <br /> <br /> Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]<br /> :As I said, I used about the same as in you BaseFixer script:<br /> float shortDetection=pow(0.9f,smallRadars);<br /> float largeDetection=pow(0.8f,largeRadars);<br /> <br /> *(short *)(&amp;base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);<br /> *(short *)(&amp;base[0x12])=(short)((1.0-largeDetection)*100.0);<br /> :However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> * Accuracy reductions for long range snap and auto fire - Fixed. <br /> * Aircraft always ready for mission despite re-fuel/re-arm status - Fixed<br /> * Stack up base build orders in advance - Implemented<br /> * More smoke and fire - Fixed<br /> * Blaster drift and waypoint bug - Fixed<br /> * Stats visible during Equip phase - Implemented<br /> * Melee combat (bludgeoning) with any weapon - Fixed<br /> * With &quot;Council Funding Only&quot;, allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any &quot;income&quot; (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with &quot;Council Funding Only&quot;. Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)<br /> * Close Down Exploits<br /> ** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed<br /> <br /> == Warm Grenades ==<br /> <br /> It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them. <br /> <br /> This could be implemented by an extra bit of logic that increments the &quot;Turn When I Will Explode&quot; field by +2 if the grenade is being held/worn when the Explode check happens. <br /> <br /> For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE. <br /> <br /> Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)<br /> <br /> == Facility maintenance cost bug ==<br /> <br /> Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)<br /> :I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)<br /> ::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)<br /> :Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)<br /> :Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)<br /> ::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], &quot;Blind spots around the corner&quot;.<br /> Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground? <br /> :Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.<br /> :*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...<br /> mov esi, 11h<br /> ...<br /> loc_44004C:<br /> dec esi<br /> mov word ptr [esp+3Ch+elementsArray], 0<br /> jnz short loc_44004C<br /> :*ecx is initialized to point to the maintenance cost data (nothing wrong here)<br /> mov ecx, offset baseElements.maintenance<br /> :*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):<br /> movsx eax, ax<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000<br /> :we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].<br /> :*then after each row, we have this:<br /> add ecx, 10h<br /> :which explains why the cost changes for each row.<br /> :I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).<br /> :The fix required two patches:<br /> :*remove the incrementing of ecx for each row<br /> char nop[]={0x90,0x90,0x90};<br /> PatchInPlace(0x44066E,nop,3);<br /> :*make a working inner loop:<br /> char patch[]={<br /> 0x03, 0xc0, // add eax,eax<br /> 0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element<br /> 0x0f, 0xb6, 0xc0, // movzx eax, al<br /> 0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining<br /> };<br /> PatchInPlace(0x440651,patch,13);<br /> :this takes care of the nonsense code<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> <br /> Very interesting stuff! By the way I'm playing a &quot;Roswell&quot; game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)<br /> <br /> ==Grenade Status Indicator==<br /> <br /> Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go? <br /> :Hmm, I'll see if I can find something<br /> <br /> == Keyboard Support ==<br /> <br /> Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)<br /> :sSuch as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)<br /> <br /> :: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT) <br /> <br /> Well, since it has been a little while now, and nobody has said anything, let me be the first. Thank you for the shortcuts on the geoscape. As I mentioned before, I had the shortcuts on battlescape on, but personally I never used them because it is not timed. But the geoscape, being that there is no pause, I have found a lot of use in shortcuts. Works perfectly for me, too. Secondly, the obdata editing feature is fantastic. If only it worked on accuracy, too....<br /> Thanks again, my friend. --[[User:Talon81|Talon81]] 17:19, 22 May 2009 (EDT)<br /> :I've put a new version with support for more settings, give it a shot ;-) [[User:Seb76|Seb76]] 06:25, 23 May 2009 (EDT)<br /> <br /> ----<br /> <br /> First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already. <br /> :Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)<br /> BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).<br /> :There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental. <br /> A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again. <br /> :I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.<br /> Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength? <br /> :At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.<br /> If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control? <br /> <br /> Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).<br /> :These two are on my secret todo list ;-)<br /> ::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)<br /> 80 item bug on base defense mission<br /> :May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...<br /> I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof! <br /> :I think this is a known issue with LOS, not sure though<br /> I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round). <br /> :I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look<br /> This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc. <br /> :Hmm, you do know I don't have the original source code available, don't you? :p<br /> Any plans to work on Terror from the deep? <br /> :I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)<br /> <br /> Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)<br /> <br /> == Inventory screen ammo weight bug ==<br /> <br /> I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)<br /> :Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)<br /> <br /> :: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)<br /> :Does not ring any bell. Any link?<br /> <br /> == Equipment issue ==<br /> Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)<br /> :There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)<br /> <br /> == Request For UFO PS Explosion Offset ==<br /> <br /> Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:<br /> <br /> &lt;i&gt;Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)&lt;/i&gt;<br /> <br /> I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)<br /> <br /> == Great new features ==<br /> <br /> Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)<br /> <br /> :OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap&gt;auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades. <br /> <br /> :I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:<br /> :* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units<br /> :* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien<br /> :* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it? <br /> :* In night missions, even with Big Brother &lt;strike&gt;and View All Locations&lt;/strike&gt; set, I could only see what my guys had illuminated &amp; seen. <br /> :* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)<br /> ::The &quot;Hack&quot; section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]<br /> :* With Alien Bases and View All Locations, the X-COM bases show up as pink.<br /> :* It wasn't obvious to me that I needed to set e.g. &quot;Initial Alien Bases=20&quot; rather than just &quot;Initial Alien Bases=1&quot;. I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> <br /> :Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission. <br /> :I have not developed Heavy Laser yet, &lt;strike&gt;nor beaten up any aliens in melee,&lt;/strike&gt; but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)<br /> <br /> :: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it. <br /> :::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]<br /> ::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)<br /> : I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:<br /> ::Glad you're having fun :-) [[User:Seb76|Seb76]]<br /> <br /> ::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader. <br /> : Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)<br /> ::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]<br /> <br /> <br /> == Base Disjoint Bug Fix ==<br /> A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. &lt;strike&gt;It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)&lt;/strike&gt;. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).<br /> : Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]<br /> <br /> I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)<br /> :Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)<br /> :Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]<br /> Yes I doubled checked a couple of times. I set the flag as<br /> <br /> Base Disjoint=1<br /> <br /> Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> : Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!<br /> <br /> == A couple of bugs to report ==<br /> <br /> Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message &quot;The Alien Food UFO was on an Damage Capacity mission in Power Sources.&quot; All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.<br /> <br /> The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> :Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)<br /> <br /> Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> <br /> :I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)<br /> <br /> ::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the &quot;crafts always ready&quot; option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)<br /> <br /> Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)<br /> <br /> :&quot;Raiding&quot; ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: &lt;pre&gt;Zone Discovered=Intel found out that the %s UFO was raiding %s&lt;/pre&gt;If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)<br /> <br /> :Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)<br /> <br /> ::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)<br /> :Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)<br /> <br /> Some more comments:<br /> # Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add &quot;usage&quot; comments to the .INI file?<br /> # Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!<br /> [[User:Spike|Spike]] 13:20, 2 January 2009 (CST)<br /> :What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)<br /> *Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game<br /> <br /> :: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)<br /> <br /> Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)<br /> Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)<br /> <br /> == Glitches with Alien Pets ==<br /> <br /> OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!<br /> <br /> * If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?<br /> * It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:<br /> ** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!<br /> ** Terror units can also equip weapons in their &quot;hands&quot;. Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)<br /> * I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly. <br /> <br /> This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):<br /> <br /> * When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error? <br /> <br /> Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!<br /> <br /> [[User:Spike|Spike]] 19:04, 5 March 2009 (CST)<br /> :My pleasure. It was the very reason I allowed it in the loader in the first place!<br /> :FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)<br /> <br /> I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy -&gt;&gt; no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!<br /> So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this &quot;retreating&quot; a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)<br /> :Thanks for the support, I'm bored of the &quot;the stuff does not work with ET&quot; thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)<br /> ::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)<br /> :Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)<br /> ::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)<br /> <br /> == TFTD Door problem ==<br /> <br /> Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> :Hi Talon81, what do you mean by &quot;other patches&quot;. Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)<br /> :Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)<br /> <br /> Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).<br /> <br /> If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)<br /> --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> <br /> : I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)<br /> <br /> :Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)<br /> <br /> == Initial Alien Bases ==<br /> <br /> OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)<br /> <br /> By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)<br /> :Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)<br /> <br /> Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)<br /> <br /> :OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)<br /> <br /> Seems to have solved the problem to me. The alien bases now appear after placement of mine instead of before like they previously did. X-Com bases are correctly shown, as well. --[[User:Talon81|Talon81]] 13:34, 28 April 2009 (EDT)<br /> <br /> == Won't work on my rig Vista+CE version ==<br /> <br /> Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.<br /> <br /> My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.<br /> <br /> * http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG<br /> * http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG<br /> --[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)<br /> :Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):<br /> <br /> [[Image:Dxwnd.png]]<br /> <br /> [[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)<br /> <br /> Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?<br /> <br /> http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)<br /> <br /> [edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.<br /> <br /> :I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:<br /> :[[Image:Scale2x.png]]<br /> <br /> :When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)<br /> <br /> <br /> ::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?<br /> :I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)<br /> :Edit: version updated with support for HQ4x (in 1280x800). Feedback appreciated... [[User:Seb76|Seb76]] 09:55, 3 May 2009 (EDT)<br /> <br /> The above version works perfectly on my PC but only through DXWmd. I'd also like to note that using DXWnd eliminates fast speed issues in Battlescape for some reason. I'm really excited Seb is pulling this off. &lt;3<br /> :Uploaded a new version, you need to add a &quot;HQ4x=1&quot; line under the &quot;Mod&quot; section to enable it. [[User:Seb76|Seb76]] 15:36, 6 May 2009 (EDT)<br /> <br /> Works perfect without the use of DXWnd, but there's some sort of frameskip feeling. Great work, this is getting better and better. :-)<br /> <br /> ==Heavy laser mod==<br /> My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction. [[User:SaintD:SaintD]]<br /> <br /> :Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)<br /> :Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)<br /> <br /> ::I tried it. The new modes now work, but Snap Mode is still missing from my HL. Also it's not clear the difference between burst and full auto since they both have the same accuracy and TU cost.--[[User:SaintD|SaintD]] 19:25, 29 April 2009 (EDT)<br /> <br /> ::: Hmmm, on mine the burst and full auto have different accuracies (80% and 60%, respectively); and they fire 5 and 8 rounds, also respectively. I believe the snap shot was taken out on purpose to coincide with the idea of the heavy laser as being more suited to being a support weapon. Of course the last part is conjecture on my part, but I am pretty certain it is not supposed to be there. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)<br /> <br /> I am not the original poster in this heading, and I have not had the same problems with the heavy laser that others had (only one I had was about the Range Based Acc not affecting full auto), so I cannot confirm whether this patch has solved that. But I will tell you what you probably already know: everything is fuzzy, kinda like [ Mok's 2xSaI]. It is also a little bit jumpy. Due to that, I can't take advantage of the Funky Fire fix, or any other future fix, unless I am willing to deal with the fuzziness, or unless you create 2 runs; 1 with the Heavy Laser fix, and one without. --[[User:Talon81|Talon81]] 13:42, 28 April 2009 (EDT)<br /> :Hum, I'm not sure I understand. What has the fuzziness to do with the HL fix? [[User:Seb76|Seb76]] 14:15, 28 April 2009 (EDT)<br /> <br /> Wow, to think I almost didnt bother to post because I was sure you would already be aware of it. As soon as I updated your loader from 6 April (TFTD door fix) to 26 April (funky fire fix), everything got fuzzy. After that, I tried the update without funky fire (HL fix). Still fuzzy. Then I rolled back to the previous one (Initial Alien Base fix). No more fuzzy. I even went back to HL fix, then back again to Alien Base fix. Same deal. I will try using it on a fresh X-Com install without my other patches. But yeah, you should seriously install the patch I linked to in my above post. Will only take a minute to try. Looks VERY much like it (I know that many people have the fuzzy problem with that patch). --[[User:Talon81|Talon81]] 02:17, 29 April 2009 (EDT)<br /> <br /> OK, it is indeed still fuzzy on a fresher copy of X-Com. It is not a genuine fresh install as I no longer have the disk, it is just the original files copied on my computer in another location. Furthermore, I forgot to mention there is also slight video garble (yes, even with the garble fix on) at the bottom of the menu screens. That in itself is not a problem as it is not throughout the game, and is only a few pixels in height. I can't wait to see if anyone else has these problems or if its just me. --[[User:Talon81|Talon81]] 02:27, 29 April 2009 (EDT)<br /> :I have a crash with Mok's patch so I cannot check the problem. By fuzzy you mean something like the image is bilinearly filtered and all smoothed? [[User:Seb76|Seb76]] 17:20, 29 April 2009 (EDT)<br /> <br /> I am a total programming/graphics newb, so I don't know if that is a good description or not. The UFO's for example, instead of being crosses, are blurbs that slightly change shape as they fly, and everything has softer transitions that make it look like it is done with pastels or something. I can tell you I tried to take a screen capture but it did not reflect the screen as it appears in game. In any case, unless other people have this same problem, I would not worry about it for my sake. If it is something you want to tackle anyway, just tell me what I can do to help you. --[[User:Talon81|Talon81]] 23:51, 29 April 2009 (EDT)<br /> :Hum, are youe using the &quot;dev&quot; version instead of the official one? It features a scale2x filter that craps the image up.[[User:Seb76|Seb76]] 14:40, 30 April 2009 (EDT)<br /> <br /> Not sure what you mean by &quot;dev&quot; version, but I am guessing you are referring to my version of CE. I do not know for sure, because it has been years since I got it, but I am guessing the answer is yes because mine runs in full screen without any mods. --[[User:Talon81|Talon81]] 12:22, 1 May 2009 (EDT)<br /> <br /> Your newest version seems to have gotten rid of my problem. --[[User:Talon81|Talon81]] 12:32, 1 May 2009 (EDT)<br /> :That's great ;-) By dev I was refering to the &quot;dev&quot; version of the loader linked on this page. It is an experimental version that uses scale2x with 640x400 resolution. [[User:Seb76|Seb76]] 12:53, 1 May 2009 (EDT)<br /> <br /> == REng UFO with IDA ==<br /> <br /> Hi Seb =)<br /> <br /> I've just started working with IDA in an attempt to understand the inner workings of TACTICAL.EXE. I have never used IDA or related tools before, nor do I really know what I'm doing ;) I have removed the DOS/4GW loader and am examining the LE code currently.<br /> <br /> So far my only progress (using DOSBox debugger) has been to isolate the calls in main() which display the equip screen and handle the interative section of the mission. You could say progress has been slow, as this has taken a couple days (including time spent figuring out the basics of IDA/DOSbox debug).<br /> <br /> Would it be possible to see your notes? You will no doubt have discovered most (all?) functions and exactly what they do. If I could see this data (such as comments, renamed funtions, cleaned up code) it would take months off of the time I would need to understand the underlying assembler code.<br /> <br /> I also recently discovered a plugin called HexRays for IDA. Do you use this? I'm really a newb so would love to get some input on which tools are best for this job.<br /> <br /> My long, long-term goal will be to implement TACTICAL as a native windows program, as it would be a great project to have whilst learning to program (I should say I have some basic programming already, but nothing beyond a simple Windows game in Delphi).<br /> <br /> Any advice is deeply appreciated mate =)<br /> <br /> XCom forever!<br /> --[[User:K9wazere|K9wazere]] 09:51, 17 June 2009 (EDT)<br /> :Hi k9,<br /> :Slow progress at the start is a normal thing. In the windows version I got help from the developers because they left a few error messages around to guide me during my initial analysis ^_^ I don't know about the DOS version, maybe they are also present.<br /> :For the DB, just PM me an email address where I can send you the file (~1.7MB)... I gave a shot at HexRays (early versions), but I didn't find it that much useful in helping to understand what's going on. Well, if you're not used to asm, it may be interesting for you ;-) Still, for re-engineering a function it may prove useful. All in all, I'm just using a standard 5.2.0.908 version, it got everything I need. Also for debugging, I use DXWnd because breakpoints and fullscreen DX apps don't live well together...<br /> :Good luck with your project,<br /> :[[User:Seb76|Seb76]] 14:15, 17 June 2009 (EDT)<br /> <br /> :::Thanks for that, Seb! I'm trying to understand how your loader and patcher works...<br /> <br /> void InsertCall(int dst, void *func)<br /> {<br /> DWORD oldProtect;<br /> DWORD *pOffset=(DWORD *)(((char *)dst)+1);<br /> <br /> VirtualProtect((void *)dst,5,PAGE_EXECUTE_READWRITE,&amp;oldProtect);<br /> *(char *)dst=(char)0xE8;<br /> *pOffset=(int)func-(int)dst-5;<br /> VirtualProtect((void *)dst,5,oldProtect,&amp;oldProtect);<br /> }<br /> <br /> ::: This calculation here is interesting:<br /> <br /> *pOffset=(int)func-(int)dst-5;<br /> <br /> :::I assume 0xEA is assembler for CALL ... but then the reason for subtracting 'dst' from 'func' is not apparent. All in all I'm a bit confused as to how code in one area of memory (UFO Defense) can call code in another area of memory, belong to a different process (UFO Loader).<br /> :The 0xEA is indeed the CALL opcode, but it is a relative jump so you must feed it the delta between source and destination (the 5 is the size of the CALL instruction itself that must be removed).<br /> :The beauty of the thing is that the loader injects the code in the address space of the main executable image so you can call functions from/to it with no trouble :)<br /> <br /> :::Can you suggest some good reading material to better understand this? Cheers!<br /> :::--[[User:K9wazere|K9wazere]] 14:36, 20 June 2009 (EDT)<br /> :You can search for DLL injection methods on the web, that's the name of the trick. In a nutshell I spawn the &quot;UFO Defense&quot; process in a suspended state, then use the CreateRemoteThread/LoadLibrary trick. HTH, [[User:Seb76|Seb76]] 14:48, 21 June 2009 (EDT)<br /> <br /> == D3D ==<br /> <br /> If I select the D3D option, UFO Defense and patcher.dll crash and generate a Windows Error Report. It won't let me copy and paste the contents unfortunately. My XCom machine is an old laptop, Win XP Pro 2003, Pentium III 851MHz, 376Mb RAM. I'm not sure what version (if any) of DirectX it has. <br /> <br /> I'm still checking out the Save Equipment / Auto Flares mods. Very welcome! Once these are working there will be no reason for most people to use XComUtil. I will get back to you when I have specific feedback - but thanks again, Seb. [[User:Spike|Spike]] 12:59, 18 July 2009 (EDT)<br /> :You need DirectX 9 installed (couldn't easily locate any older SDK, I'm sure I could've gotten away with DX7...), maybe I should make the code more robust and exit gracefully instead of crashing... [[User:Seb76|Seb76]] 13:04, 18 July 2009 (EDT)<br /> <br /> Hmm. I've installed DirectX version 9 (March 2009 version) and with D3D enabled the Loader just fails silently; no error message, nothing in the event log. Maybe the install didn't work properly. I'll see if I can find some kind of DirectX test/verification utility somewhere. [[User:Spike|Spike]] 21:23, 19 July 2009 (EDT)<br /> <br /> OK I ran the &lt;b&gt;dxdiag&lt;/b&gt; utility which comes with DirectX 9.0c. This tests DirectDraw and Direct3D levels 7/8/9. There were no problems and no issues detected, apart from my laptop does not support hardware sound buffering (software only). I can send you the full dxdiag.txt report if it will help. When the Loader fails, all I see is a little black square in the top left, which I think is a normal part of the loading sequence (some kind of command window), and then nothing. [[User:Spike|Spike]] 21:39, 19 July 2009 (EDT)<br /> :Might be related to using none power of two textures. Maybe your hardware does not support it? I'll add some more checks to make sure that's the problem.<br /> :Edit: Can you try the latest version? I added some more error handling, can you tell me if you have an error message at some point? [[User:Seb76|Seb76]] 19:18, 20 July 2009 (EDT)<br /> Unforunately I don't have access to the original laptop now, I won't do for a few months. I have tried on another PC (XP 2002 Professional SP3, DirectX9.0c, dxdiag tests all ok) and I also get a crash. Instead of dropping out right away, I see the smallish black square in the top left for a while, then I go to a full screen black or grey-black screen. This lasts for minutes. It doesn't eat up CPU and I can task switch out of it. I don't see any popup error messages and nothing in the event logs. When I kill UFO Defense the black full screen goes away. Sorry I know that's not much help. [[User:Spike|Spike]] 17:59, 22 July 2009 (EDT)<br /> D3D mode isn't working for me either, I simply get a black screen. When I alt+tab out of it though I can see an error box titled 'D3D error' which tells me it 'Cannot create texture'.<br /> <br /> == Save equipment ==<br /> <br /> Hi Seb. I've tried out the Save Equipment and Auto Flares (good idea by the way). I've seen some quirks. I had a few weapons (a Rifle and maybe a Pistol) that weren't loaded. Normally the game loads all weapons unless there isn't sufficient ammo. I moved some stuff around so this might have been due to me. So I restarted. Then I got a situation where:<br /> <br /> *1 soldier had no weapons, just a grenade in a belt, even though there were Rifles and Auto Cannon (both with ammo) not allocated. Actually this soldier was showing 54/40 encumbrance from one grenade. Carrying a lot of &quot;invisible&quot; equipment!<br /> *Heavy weapons (Auto Cannon, Heavy Cannon, Rocket Launcher) were allocated only once each. Spare heavy weapons were not allocated. The soldiers allocated the heavy weapons carried 3 spare ammo clips and were overloaded. Also, a weak soldier (strength 21 or so) was selected to carry the Auto Cannon and 3 spare clips. <br /> *The mission appeared to be a night mission but no flares were allocated. (the previous mission, the Auto Flares worked fine). Maybe it was a Dusk mission? It looked dark out there.<br /> *Also the game crashed when I moved the first guy out of the transport. Of course this is not necessarily related to using Save Equipment. <br /> <br /> Actually, making sensible automatic rules for weapon and ammo allocation is hard to do, and a matter of personal taste, and this is really a different goal than just saving equipment allocations that have been picked manually by the player. So I'm probably being really unfair. Maybe it would be easier not to allocate any weapons other than what the player has picked? <br /> <br /> Anyway I have a save game file for the 2nd game if that is any use to you for debugging. Cheers, [[User:Spike|Spike]] 18:53, 18 July 2009 (EDT)<br /> :Thanks for the feedback, it got in the dev version for 2 months and nobody sent any comment so I figured I might as well put it in the official version ;-) I'm not surprised with the kind of problems you encountered, I got lots of 'em while making this... The crash at the start is most likely due to reaction fire.<br /> :The autoflare feature should trigger at the same time as the visibility reduction caused by the night. Were you able to see up to 20 tiles away?<br /> :As for the auto-allocation, I'm afraid there is no other easy option that I can see: when the mission starts, everybody is already equiped with the default stuff. I have to remove everything to be able to reassign items properly :( The default reequiping rules are quite simple: strength is not taken into account, and you require a set amount of free clips to be able to equip a weapon.<br /> :I had a look at your savegame, but one just before the mission would be better. Also can you attach your ini file? Maybe some problems are caused by incompatibilities between mods. [[User:Seb76|Seb76]] 04:08, 19 July 2009 (EDT)<br /> ::OK uploaded what I hope is the right .ini file. Unfortunately that was my first savefile of the game, I don't have any earlier one. All I did was bought some guns 'n ammo and landed on the first (Roswell) crash site. The weirdest thing was the female soldier (Martha Stewart? or am I hallucinating?) with 54/40 encumbrance but only carrying one grenade. Could this be connected to [[Known_Bugs#Weightless_Loaded_Ammo|the problem you discovered in the game's weight routine]]? Anyway I will try and recreate the problem with more savefiles so you have a &quot;before&quot; and &quot;after&quot;. [[User:Spike|Spike]] 07:15, 19 July 2009 (EDT)<br /> :In your savegame I indeed see that the Maria chick is overweight, but if I bail out of the mission and go on a new one, she only have a grenade and a weight of 3... Another strange thing is that in the equip.ini file of the savegame, she's marked as having a large rocket loaded in the weapon that she's holding, but she has no weapon... Did you equip her with the rocket launcher and changed your mind afterward? [[User:Seb76|Seb76]] 11:27, 19 July 2009 (EDT)<br /> ::OK I restarted from a new game. I took lots of savegames after each step. Everyone has your default basic loadouts - loaded pistol or rifle, one reload, one grenade. I see a couple of anomalies. Look for Jacques. He is overweight despite only carrying a Rifle. Also, he is carrying a grenade that shows as Primed - it isn't. I even threw it to make sure - no explosion. Like Maria before him, Jacques is the last soldier in the equip.ini list. Also like Maria, Jacques is carrying more guns &amp; ammo in equip.ini than are shown in the inventory screen. He has 5 items but they don't add up to the 54 or so Encumbrance he is showing. Like Maria, he is carrying ammo (type 13) in a slot1 (left hand) weapon that doesn't exist, and it seems to weigh about 20! The crazy encumbrance persists into the next turn and it is still there after I restore a savegame. I will upload a full set of play-by-play savegame files. I did move some equipment around for some guys in the later saves. But never for Jacques. [[User:Spike|Spike]] 21:10, 19 July 2009 (EDT)<br /> :OK, I'll have a look at this, thanks for the effort.<br /> :Edit: I could not reproduce the problem staight away: I see the crapped up weight if I load your tactical games, but when using the &quot;i/b&quot; one, Jacques is alright... Does this problem happens 100% of the time on your PC? Maybe it's a problem with the ini file handling (W2K3?), who knows... I'll keep trying. Feedback from XP/Vista users could be useful on this one. BTW are you using split binaries? [[User:Seb76|Seb76]] 15:44, 20 July 2009 (EDT)<br /> ::I've uploaded another save game, this time on a different PC (better XP version, CPU, RAM). Same symptoms - the last man has phantom equipment. Actually I notice the last TWO men have 2 items of equipment on them, but only visible one item shown in equip.ini. Also I keep forgetting to send the UFO Extender.ini file. My games don't use split binaries. I don't think it's a problem parsing the equip.ini file because the problem appears right away, if I save as my first action when the battlescape appears - the equip.ini already has the weirdness, and on the battlescape the soldier already has the weirdness. Although - let me check this - but I don't think the phantom equipment weirdness is there during the Equip Screen, it only appears when the actual Battlescape starts. So, if you pass the equipment information from the Equip screen to the Battlescape via the equip.ini file, that's a possibility. [[User:Spike|Spike]] 17:21, 20 July 2009 (EDT)<br /> ::Uploaded another New game, same/similar symptoms. This time the last guy is carrying weapons. But still, he is too heavy. The effect is NOT present in Equip Screen; his weight only increases once on the Battlescape. He is carrying a Rocket (object type 13) inside an invisible second weapon. So this could be a problem parsing the equip.ini file. [[User:Spike|Spike]] 17:38, 20 July 2009 (EDT)<br /> ::Last note tonight. The guy is overweight by 13 x 2 = 26 units. His equip.ini shows him carrying a phantom type 13 object (in a nonexistent 2nd weapon). Is this a coincidence? Maybe check the other savefiles and see if the last man was also overweight by 26 units, or by 2 x the index of the phantom item. [[User:Spike|Spike]] 18:00, 20 July 2009 (EDT)<br /> :I uploaded a new version, can you check it out? [[User:Seb76|Seb76]] 19:16, 20 July 2009 (EDT)<br /> :: Re tried with New game after your fix. Still seeing last 2 characters with incorrect weights. The weights were the same on the Equip screen as on the Battlescape. Excess weights are 6 and 3 units. Uploaded the save game. [[User:Spike|Spike]] 14:14, 21 July 2009 (EDT)<br /> :Actually you're now hitting another bug: when putting a loaded gun to the floor, the ammo stays assigned to the soldier so its weight is still taken into account... [[User:Seb76|Seb76]] 15:21, 21 July 2009 (EDT)<br /> ::Yes you are right. In fact the weight errors were not 6 and 3 but 6 and 5 - the weight of heavy cannon ammo and auto cannon ammo, respectively. When I dropped the loaded heavy cannon and the loaded auto cannon, the encumbrance weights drop by 18 and 19 respectively. This is the weight of the unloaded weapon, not the correct weight of the loaded weapon. (Though normally, due to the buggy weight routine in the game, that *is* the actual (but incorrect) weight of the loaded weapon if you haven't yet unloaded it). So this is just a matter of ignoring the ammo weight from the soldier's encumbrance when dropping a loaded weapon. And it does look like the original problem has been fixed. [[User:Spike|Spike]] 18:18, 22 July 2009 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=21248 2009-04-26T16:58:23Z

<p>J&#039;ordos: /* UFOloader and Xcomutil */</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> :::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)<br /> ::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J&amp;#39;ordos]] 05:01, 9 September 2008 (PDT)<br /> : Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)<br /> ::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)<br /> :::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)<br /> :::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)<br /> ::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)<br /> ::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)<br /> :Hey Seb is it possible the latest versions of your extender don't work with xcomutil anymore? Did you drop support? Love the new features but I rather miss xcomutil's automatic re-equipping :) [[User:J'ordos|J&amp;#39;ordos]] 12:58, 26 April 2009 (EDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)<br /> <br /> OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your &quot;Full Auto&quot; mode would be 100% TUs for 10 rounds and your &quot;Burst Mode&quot; could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)<br /> <br /> : On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)<br /> <br /> Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ. <br /> <br /> Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz: <br /> <br /> See if you can get the &quot;hidden item&quot;, Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)<br /> <br /> :Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:<br /> :*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front<br /> :*reduce accuracy even further when shooting out of sight (this was mentionned in another post)<br /> :*change the damage model and reduce the probability that terrain is destroyed when shot<br /> :*have a cooldown period where the weapon is not useable (not sure if it's feasible though)<br /> <br /> ::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J&amp;#39;ordos]] 16:27, 7 September 2008 (PDT)<br /> :::Hm, I already cannibalized the unused &quot;open&quot; and &quot;close&quot; actions for the heavy laser mod, there is no more room for a new &quot;hit&quot; command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)<br /> <br /> :OK, here is the last draft before I finalize:<br /> :*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)<br /> :*Each shot of a burst will reduce the accuracy (amount not determined yet)<br /> :*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL<br /> :If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)<br /> <br /> Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)<br /> :OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)<br /> <br /> It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J&amp;#39;ordos]] 12:41, 28 February 2009 (CST)<br /> :It may have been broken by other stuff indeed. I'll have a look [[User:Seb76|Seb76]] 17:29, 28 February 2009 (CST)<br /> <br /> Hey, is it just me or is full auto not affected by range based accuracy, while burst is? I am using the RB accuracy mod on all weapons, and maybe that is affecting it. All I know is, even at long distance, full auto shows full accuracy. Not sure if the burst mode is showing the RB decrease I programmed or not though.<br /> --[[User:Talon81|Talon81]] 06:01, 14 April 2009 (EDT)<br /> <br /> :The heavy laser and range based accuracy stuff were developped in parallel and merged later. It is almost sure that things will go wrong if you activate both ;-) I could reproduce some issues and will try to fix them. BTW, I got no feedback for the &quot;shortcuts&quot; patch. Is it broken that badly that nobody wants to have it fixed? [[User:Seb76|Seb76]] 17:00, 18 April 2009 (EDT)<br /> <br /> I just used an unpatched version (CE, as I always use), and used your patch on it. The only things I even activated in the patch are the video fix so it was playable, the heavy laser mod, and the accuracy mod. Still have the same problem, so yeah... they don't work well together at the moment. But... I am hooked on the accuracy mod, so I guess Ill just deal with it and not use full auto. As far as shortcuts go... I had enabled it at one time, but I found that I just never used them. Maybe I will try to use it a bit to give you some feedback. I added a comment for alien bases, too, btw. --[[User:Talon81|Talon81]] 15:18, 19 April 2009 (EDT)<br /> <br /> == Wish List please please please ==<br /> <br /> <br /> <br /> === New and Outstanding Requests ===<br /> <br /> * Allow scrolling the map with the keyboard. &quot;WASD&quot; as default maybe, since you used the arrow keys and most people have thier left hand free anyway. Allow moving units one square at a time with the numpad. First tap changes facing if not looking that way, second one moves you in that direction.<br /> <br /> * Remember soldier load outs from last mission and re-equip accordingly. Or maybe just prevent units from taking more than they can carry. Removing grenades first, then magazines and ammo and lastly guns.<br /> <br /> * Make it so you can drop more than one screen worth of stuff in the pre-mission equipping phase.<br /> <br /> * Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode. <br /> <br /> : Has this been completed via the &quot;Save Reserve Mode&quot; feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair. <br /> <br /> * Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:<br /> ** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has &gt;0 units before allowing it to start. <br /> ** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.<br /> ** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix. <br /> * Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns &quot;no line of fire&quot;. This would avoid a lot of the &quot;hit the ceiling&quot; issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''<br /> * Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.<br /> * Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]]. <br /> <br /> <br /> * [[Wish List#Prior Recon of Battlefield|&quot;Eye in the Sky&quot;]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings. <br /> <br /> * Grenades that [[Wish List#Warm Grenades|function normally]].<br /> <br /> * Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].<br /> <br /> ==== Incendiary Bug ====<br /> <br /> * Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].<br /> <br /> :: Boy oh boy this is a tough one. First we need to figure out how Incendiary actually works. Zombie is getting in to some heavy testing over on [[Talk:Incendiary]]. Right now, the more we learn, the more we know we ''don't'' know. With this 'Funky Fire' bug, presumably what is going on is that during an Incendiary explosion, the game engine loops through all units that are in fire(and on fire?). This is wrong. What it should be doing is testing to see if they are within the Area of Effect of this particular IN round. The game definitely has working code to correctly select units within an area of effect, since that's what happens for HE and Stun explosions. But in this case it does not apply the correct selection criteria. What is looks like it does is scans the Unitref table (copy in memory) for every unit standing on a tile with fire in it, and maybe also with the 'on fire' flag set. Both of these lookups are actually irrelevant to an exploding IN round. These looks would make exact sense for the end-of-turn processing of fire damage, but not for the instantaneous effect of an IN round. They should use the HE/Stun routine instead, to select the units for processing. Then when the units are selected, it should apply the IN effects - still to be determined. So yes, I think what's happened is the coders mistakenly used the &quot;end of turn&quot; criteria to select units for instantaneous damage/effect when an IN round explodes. Anyway, once Zombie has sorted out the facts, maybe you could take a look at these IN explosion routines? I guess one difficulty is that the HE routine is performing 2 functions - it's doing damage to terrain, and also flagging units to apply damage to. It may also be setting smoke. Similarly, the IN routine ought to have 2 functions - to apply fire/burning time to the tile, but also to apply IN damage effects to the occupants of the tiles. This really could be coded badly and just hard to fix. [[User:Spike|Spike]] 19:17, 11 March 2009 (CDT)<br /> <br /> OK I'm pretty sure this is the whole problem with the Funky Smoke/Fire bug. What's going on is the Incendiary Explosion routine is calling the whole end-of-turn smoke/fire processing routine, every time an IN round explodes anywhere on the map. That's why you get smoke induced stun as well as fire-induced damage. All you need to do is find this IN Explosion routine and make it return unconditionally before it calls the end-of-turn routine. That will substantially solve the bug. What the IN Explosion routine ought to do is:<br /> <br /> # In area of effect<br /> ##add fire to tiles<br /> ##'''possibly''' do 33% check for units to catch fire - '''unless''' this is performed by the end of turn routine (probably)<br /> # IF a unit was hit directly<br /> ## check to see if it catches fire<br /> ## ''possibly'' do &quot;impact&quot; damage. <br /> # Return, '''without''' calling the end-of-turn smoke/fire routine<br /> <br /> And it's entirely possible there was never supposed to be any &quot;impact&quot; damage, all that was intended was to set tiles and units on fire, with any damage only coming at the end of turn. You can easily imagine a last minute and ill-considered coding decision to run the end of turn routine upon every IN explosion, as an attempt to increase IN lethality, without thinking through the implications properly. So the &quot;impact&quot; damage could just be a side effect of the funky fire bug - applying the 5-10 &quot;on fire&quot; damage right away, when it was meant to be applied at end-of-turn. <br /> <br /> [[User:Spike|Spike]] 22:11, 11 March 2009 (CDT)<br /> :Hey, that's a nice piece of supposition:) There is actually what I called an ApplyFireAndStunDamage function which is indeed called after IN explosions and at the end of the turn... It basically damages/stuns every unit on fire/in smoke and makes units standing in firing tiles possibly take fire. The function is called 5 times, one of which is at the end of the turn so patching the 4 other locations should remove the bug; but also weaken the IN rounds...[[User:Seb76|Seb76]] 16:22, 12 March 2009 (CDT)<br /> <br /> ::Thanks! :) But now you're scaring me - why would there be '''4''' calls to this function, apart from end-of-turn? Why wouldn't there just be one piece of common code, one call, for IN explosions? I'm racking my brains. I guess there could just be 4 different situations when an IN round could explode. Maybe - direct impact, impact with terrain, reaction fire, large units, auto fire... guesswork! Reaction fire is a good guess - we already know lots of things that are bugged with reaction fire, which suggests the code for reaction fire may be a separate loop. There are hints that auto fire may be handled differently for IN - only hints. I'd be worried patching out all 4 calls. But, if you can do it, I'm very happy to test for unintended consequences. <br /> <br /> ::It will be interesting to see if patching out all 4 calls eliminates &quot;impact&quot; IN damage from direct hits - suggesting it was only ever an unintended effect of the bug. It may not be possible, but &quot;impact&quot; damage might be the one thing to retain, to avoid making IN weapons too weak. Still it might not be an option. Interesting stuff! <br /> <br /> ::Any chance you could do 5 separate config file flags to mask out the 5 calls? Then I could determine by experiment what each one does. [[User:Spike|Spike]] 18:27, 12 March 2009 (CDT)<br /> <br /> ==== See Also ====<br /> <br /> *[[Wish List]]<br /> *[[Known Bugs]]<br /> *[[Exploits]]<br /> <br /> === Completed Items - Thanks Seb! ===<br /> <br /> See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]<br /> <br /> * Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault. <br /> :The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :: Completed with the &quot;Keep Base Navigation Tables&quot; option. <br /> <br /> * Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the &quot;Roswell Incident&quot;. Crash site would be automatically detected &amp; UFO would have random damage. <br /> :Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :Update: feature almost complete, time to bake a new version ;-)<br /> <br /> :[[Image:Roswell.png]]<br /> <br /> :There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)<br /> <br /> <br /> * Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)<br /> <br /> : Fixed with &quot;Faster base defence sequence&quot; option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)<br /> <br /> <br /> * Multiple Radar - Fixed. <br /> <br /> Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]<br /> :As I said, I used about the same as in you BaseFixer script:<br /> float shortDetection=pow(0.9f,smallRadars);<br /> float largeDetection=pow(0.8f,largeRadars);<br /> <br /> *(short *)(&amp;base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);<br /> *(short *)(&amp;base[0x12])=(short)((1.0-largeDetection)*100.0);<br /> :However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> * Accuracy reductions for long range snap and auto fire - Fixed. <br /> * Aircraft always ready for mission despite re-fuel/re-arm status - Fixed<br /> * Stack up base build orders in advance - Implemented<br /> * More smoke and fire - Fixed<br /> * Blaster drift and waypoint bug - Fixed<br /> * Stats visible during Equip phase - Implemented<br /> * Melee combat (bludgeoning) with any weapon - Fixed<br /> * With &quot;Council Funding Only&quot;, allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any &quot;income&quot; (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with &quot;Council Funding Only&quot;. Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)<br /> * Close Down Exploits<br /> ** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed<br /> <br /> == Warm Grenades ==<br /> <br /> It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them. <br /> <br /> This could be implemented by an extra bit of logic that increments the &quot;Turn When I Will Explode&quot; field by +2 if the grenade is being held/worn when the Explode check happens. <br /> <br /> For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE. <br /> <br /> Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)<br /> <br /> == Facility maintenance cost bug ==<br /> <br /> Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)<br /> :I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)<br /> ::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)<br /> :Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)<br /> :Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)<br /> ::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], &quot;Blind spots around the corner&quot;.<br /> Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground? <br /> :Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.<br /> :*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...<br /> mov esi, 11h<br /> ...<br /> loc_44004C:<br /> dec esi<br /> mov word ptr [esp+3Ch+elementsArray], 0<br /> jnz short loc_44004C<br /> :*ecx is initialized to point to the maintenance cost data (nothing wrong here)<br /> mov ecx, offset baseElements.maintenance<br /> :*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):<br /> movsx eax, ax<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000<br /> :we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].<br /> :*then after each row, we have this:<br /> add ecx, 10h<br /> :which explains why the cost changes for each row.<br /> :I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).<br /> :The fix required two patches:<br /> :*remove the incrementing of ecx for each row<br /> char nop[]={0x90,0x90,0x90};<br /> PatchInPlace(0x44066E,nop,3);<br /> :*make a working inner loop:<br /> char patch[]={<br /> 0x03, 0xc0, // add eax,eax<br /> 0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element<br /> 0x0f, 0xb6, 0xc0, // movzx eax, al<br /> 0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining<br /> };<br /> PatchInPlace(0x440651,patch,13);<br /> :this takes care of the nonsense code<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> <br /> Very interesting stuff! By the way I'm playing a &quot;Roswell&quot; game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)<br /> <br /> ==Grenade Status Indicator==<br /> <br /> Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go? <br /> :Hmm, I'll see if I can find something<br /> <br /> == Keyboard Support ==<br /> <br /> Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)<br /> :such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)<br /> <br /> :: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT) <br /> <br /> <br /> ----<br /> <br /> First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already. <br /> :Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)<br /> BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).<br /> :There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental. <br /> A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again. <br /> :I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.<br /> Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength? <br /> :At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.<br /> If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control? <br /> <br /> Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).<br /> :These two are on my secret todo list ;-)<br /> ::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)<br /> 80 item bug on base defense mission<br /> :May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...<br /> I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof! <br /> :I think this is a known issue with LOS, not sure though<br /> I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round). <br /> :I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look<br /> This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc. <br /> :Hmm, you do know I don't have the original source code available, don't you? :p<br /> Any plans to work on Terror from the deep? <br /> :I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)<br /> <br /> Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)<br /> <br /> == Inventory screen ammo weight bug ==<br /> <br /> I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)<br /> :Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)<br /> <br /> :: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)<br /> :Does not ring any bell. Any link?<br /> <br /> == Equipment issue ==<br /> Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)<br /> :There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)<br /> <br /> == Request For UFO PS Explosion Offset ==<br /> <br /> Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:<br /> <br /> &lt;i&gt;Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)&lt;/i&gt;<br /> <br /> I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)<br /> <br /> == Great new features ==<br /> <br /> Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)<br /> <br /> :OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap&gt;auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades. <br /> <br /> :I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:<br /> :* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units<br /> :* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien<br /> :* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it? <br /> :* In night missions, even with Big Brother &lt;strike&gt;and View All Locations&lt;/strike&gt; set, I could only see what my guys had illuminated &amp; seen. <br /> :* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)<br /> ::The &quot;Hack&quot; section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]<br /> :* With Alien Bases and View All Locations, the X-COM bases show up as pink.<br /> :* It wasn't obvious to me that I needed to set e.g. &quot;Initial Alien Bases=20&quot; rather than just &quot;Initial Alien Bases=1&quot;. I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> <br /> :Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission. <br /> :I have not developed Heavy Laser yet, &lt;strike&gt;nor beaten up any aliens in melee,&lt;/strike&gt; but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)<br /> <br /> :: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it. <br /> :::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]<br /> ::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)<br /> : I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:<br /> ::Glad you're having fun :-) [[User:Seb76|Seb76]]<br /> <br /> ::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader. <br /> : Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)<br /> ::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]<br /> <br /> <br /> == Base Disjoint Bug Fix ==<br /> A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. &lt;strike&gt;It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)&lt;/strike&gt;. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).<br /> : Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]<br /> <br /> I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)<br /> :Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)<br /> :Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]<br /> Yes I doubled checked a couple of times. I set the flag as<br /> <br /> Base Disjoint=1<br /> <br /> Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> : Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!<br /> <br /> == A couple of bugs to report ==<br /> <br /> Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message &quot;The Alien Food UFO was on an Damage Capacity mission in Power Sources.&quot; All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.<br /> <br /> The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> :Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)<br /> <br /> Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> <br /> :I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)<br /> <br /> ::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the &quot;crafts always ready&quot; option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)<br /> <br /> Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)<br /> <br /> :&quot;Raiding&quot; ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: &lt;pre&gt;Zone Discovered=Intel found out that the %s UFO was raiding %s&lt;/pre&gt;If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)<br /> <br /> :Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)<br /> <br /> ::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)<br /> :Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)<br /> <br /> Some more comments:<br /> # Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add &quot;usage&quot; comments to the .INI file?<br /> # Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!<br /> [[User:Spike|Spike]] 13:20, 2 January 2009 (CST)<br /> :What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)<br /> *Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game<br /> <br /> :: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)<br /> <br /> Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)<br /> Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)<br /> <br /> == Glitches with Alien Pets ==<br /> <br /> OK I know that Alien Pets is a Hack and we should expect side effects. I just want to list them here for information purposes - please do not feel under any obligation to fix them!<br /> <br /> * If Alien Pets is set to 1 at the start of a Battlescape mission, Aliens generate with all their equipment in slot 2, i.e. no clips in weapon, no weapon in hand. They remain in this state until they spot a human in their own turn, at which point they lose 19 TUs drawing and loading the weapon. Furthermore, they are incapable of reaction fire until they have seen a human, drawn and loaded their weapon as a result, and survived the experience. From [[Talk:Alien Inventory Use|discussions]] it seems likely that there is a pre-battle routine which moves a weapon from slot 2 on each alien, and arms it, prior to the start of Battlescape turn 1. This routine bypassed - possibly because Alien Pets flags the alien units as human-controlled, and so this 'arming' routine ignores those units?<br /> * It is possible to get to an Inventory screen for large terror units. Normally this is blocked (even when using the Alien Inventory 'trick'). This has these effects:<br /> ** Large terror units can pick up and drop items. To pick up, position the topmost/northwest corner of the unit over the item. The Cyberdisc makes a great cargo vehicle!<br /> ** Terror units can also equip weapons in their &quot;hands&quot;. Move the weapon to the left hand slot and it will appear in the Battlescape display. However the weapon can't actually be used. Using the left weapon will cause the unit's built-in ranged weapon to be used instead. (But test with Reapers or when the built-in is out of ammo?)<br /> * I also saw some very weird TU and Weight/Encumbrance behaviour. Aliens at 200% encumbrance, unable to do anything and losing TUs each round. I need to characterise this more clearly. <br /> <br /> This might or might not be unrelated (might be due to me using Bomb Bloke's object editor wrongly):<br /> <br /> * When an Alien loads a clip into a weapon and fired it, the ammo count goes negative. This clip (or even single rocket/bomb) then becomes an infinite ammo supply. Probably a signed vs unsigned integer error? <br /> <br /> Now regardless of all these minor points, Alien Pets has been very helpful for me doing research on the Alien AI and Inventory handling, so thanks very much for this useful hack!<br /> <br /> [[User:Spike|Spike]] 19:04, 5 March 2009 (CST)<br /> :My pleasure. It was the very reason I allowed it in the loader in the first place!<br /> :FYI: the weapons are not handed in a hidden turn but while the aliens are spawned. Also I think reaction fire is completely disabled for the aliens when the hack is activated [[User:Seb76|Seb76]] 13:37, 6 March 2009 (CST)<br /> <br /> I dropped by after three months or so (you've inspired me to start an disassembly work on another oldie strategy -&gt;&gt; no time), and I am really astonished, Seb. Behold, incredible work with one of my old wishes, the decreasing accuracy. Fantastic for the gameplay!<br /> So - ehm - I'll try to wish for one more, hope you do not mind. There is the last, very (game-wise) frustrating issue: the AI fires a weapon and then sidesteps the alien just out of your view. I am bored to death to make that one step forward and always find the bad guy and shoot him in the back. If you could make this &quot;retreating&quot; a somewhat random thing (random APs, random where to), it would thicken the atmosphere (where he is??) and make the game 10x better. I guess you can't make them 'search cover', but make them running away RANDOMLY will do the job for me. I'll be very thankful to you. --[[User:Kyrub|Kyrub]] 20:26, 1 April 2009 (EDT)<br /> :Thanks for the support, I'm bored of the &quot;the stuff does not work with ET&quot; thing ;-) I can have a look but the alien AI is one of the points I'm clueless about, I don't really know what to look for. When I study the parts that interact with ROUTE.DAT data, I cannot figure what the hell is going on... Do you know if the backing alien has ran out of TUs? Maybe the game tries to keep some for reaction fire but no-one realized that turning your back on danger is not the best tactic for reaction shots ^_^ [[User:Seb76|Seb76]] 15:46, 2 April 2009 (EDT)<br /> ::The situation happens always a) in the open b) during the alien turn c) when the enemy spots you, fires and then retreats out of view. I think he even turns back to face you sometimes, but not sure. But the main (gameplay) problem is that you are totally safe to advance 1 step and shoot because you have full TUs, no reaction fire, no support from other aliens. Perhaps the program determines the quadrant with human, via substracting the positions and finding the angle with a pre-made table in the exe (I have the same thing in my disassembling game)? Or it just loops next fields until it finds the one without eye-contact? -- I am almost sure that this was repaired in the Ufo Tftd. The aliens are very nasty and retreat totally out of view... -- BTW, the aliens do well in the vessels in UFO-eu, they search cover in the next room!--[[User:Kyrub|Kyrub]] 16:22, 2 April 2009 (EDT)<br /> :Hum, too bad I never got to disassemble TFTD then ;-) BTW, which game do you work on? [[User:Seb76|Seb76]] 17:22, 2 April 2009 (EDT)<br /> ::Master of Orion I, correcting the bugs and improving AI. (Hey, noticed the doors' thing. Another great one.) --[[User:Kyrub|Kyrub]] 20:09, 2 April 2009 (EDT)<br /> <br /> == TFTD Door problem ==<br /> <br /> Seb, there seems to be a problem using the TFTD Doors with the Proximity Mine bug fix. I do have several other patches to my game, and it is possible that they are complicating the matter, but simply by turning off the PM fix I can suddenly open doors again. --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> :Hi Talon81, what do you mean by &quot;other patches&quot;. Are you using ET or xcomutils? Or are you just enabling other patches from the loader? Also what are the symptoms exactly. Can't you open any door? [[User:Seb76|Seb76]] 14:24, 6 April 2009 (EDT)<br /> :Edit: Nevermind, I could reproduce the problem. Can you try the new version I just uploaded? [[User:Seb76|Seb76]] 15:08, 6 April 2009 (EDT)<br /> <br /> Yeah, I tried it, and it works fine. As you no doubt have already figured out, it wasnt working on any kind of door, as far as I could determine. The other things I am using should not interfere. They are minor patches such as Zombie's combo patch for terrain, etc, CE to DOS sound editor, and the aimed accuracy adjustment patch. I am not using Xcomutil or ET (would like to use ET, but I know that it doesnt work well with your patch).<br /> <br /> If it means anything to you, I would like to say that your work has meant a LOT towards making this game what it should have been. I fell in love with this game in 94, and never have more than a couple years gone by without me playing it. Your patch is the best thing to come along since it was made. ;-)<br /> --[[User:Talon81|Talon81]] 06:02, 14 April 2009 (EDT)<br /> <br /> : I second that, wholeheartedly. [[User:Spike|Spike]] 16:44, 14 April 2009 (EDT)<br /> <br /> :Thanks guys! This game is the best and I try not to divert it from its spirit with my patches... Actually the fix for the doors *might* increase compatibility with ET, but it's a wild guess. [[User:Seb76|Seb76]] 16:56, 18 April 2009 (EDT)<br /> <br /> == Initial Alien Bases ==<br /> <br /> OK, so I was having some problems getting alien bases to work, so I created a new folder of X-Com with nothing but your video patch on, and alien bases. I am still having the same problems I was having on my more heavily patched version. For example, I created one with 3 alien bases. Looks fine. I run it with the show all locations patch and sure enough, no alien bases. I make a new game with the show all patch on and there are the alien bases, shown until the point that I place my own base. Then they disappear and my base now looks like an alien base. There are some other minor bugs associated, too; however, that seems to be the main problem. In short, I have yet to get an alien base to survive past the placement of my base. I thought it could be a glitch in the show all patch, but scouting the areas where the alien bases were shown prior to base placement has returned nothing. --[[User:Talon81|Talon81]] 15:23, 19 April 2009 (EDT)<br /> <br /> By the way, Seb, are you the same as Strife67? --[[User:Talon81|Talon81]] 13:13, 24 April 2009 (EDT)<br /> :Nope, never heard of that guy. What's he doing? [[User:Seb76|Seb76]] 15:13, 24 April 2009 (EDT)<br /> <br /> Nothing anymore. He created a sound patch a year ago or so, and there were some things he said that reminded me of you, not to mention in my head I was thinking you were Seb67 instead of Seb76. I just now noticed my mistake. --[[User:Talon81|Talon81]] 20:16, 24 April 2009 (EDT)<br /> <br /> :OK, I uploaded a new version. Can you confirm it fixes the problem on your rig? [[User:Seb76|Seb76]] 07:57, 26 April 2009 (EDT)<br /> <br /> == Won't work on my rig Vista+CE version ==<br /> <br /> Nice work! I really want to play this, it's not working on my PC though. I may be stuck with the Dos version in Dosbox forever.<br /> <br /> My screen flashes between the squashed look of the unpatched EXE and the OK version. On screens without animation it changes back and forth as I move the mouse. On the Geoscape it just flashes and gives me a headache. Sorry about the big images, to lazy to cut them down.<br /> <br /> * http://darksun.lunarpages.com/XCOM/Scrambled%20P1010264.JPG<br /> * http://darksun.lunarpages.com/XCOM/Fine%20P1010265.JPG<br /> --[[User:SaintD|SaintD]] 19:09, 19 April 2009 (EDT)<br /> :Hum, looks like another Vista problem... Do you have the problem when using [http://appaholic.co.uk/2007/10/16/dxwnd-force-almost-anything-into-a-windowed-mode/ DXWnd]? I use the following settings (but I'm under XP...):<br /> <br /> [[Image:Dxwnd.png]]<br /> <br /> [[User:Seb76|Seb76]] 14:57, 20 April 2009 (EDT)<br /> <br /> Awesome. That worked. My 1440x900 regular resolution means that the window is really tiny though. You should really get the upscaler working now. Heheh. Dxwnd makes Internet Explorer crash on vista. Does that happen to you?<br /> <br /> http://darksun.lunarpages.com/XCOM/xcomWindowed.png --[[User:SaintD|SaintD]] 00:34, 21 April 2009 (EDT)<br /> <br /> [edit] I didn't realize you can just drag the Dxwnd window bigger. I still miss the advinterp3x from dosbox.<br /> <br /> :I dunno exactly how DXWnd works but I think it may screw up aero stuff... I played with scale2x a bit and got that but it only works with DXWnd:<br /> :[[Image:Scale2x.png]]<br /> <br /> :When I try fullscreen, it looks like DirectX won't allow me to go to 640x400 resolution :( Any DX guru out there? [[User:Seb76|Seb76]] 14:36, 21 April 2009 (EDT)<br /> <br /> <br /> ::Can I get a copy of the new version? :) I can only use Dxwnd anyway. If you can boil the problem down I might be able to get some Direct X help. I know a couple guys who have been playing with XNA a lot. Can you create a stand alone sample program to illustrate your issue maybe?<br /> :I uploaded this: [[Image:UFOExtender-dev.zip]]. It works only in window mode on my laptop, maybe you can give it a try? You'll most likely have to alt-tab out of the black screen though... [[User:Seb76|Seb76]] 11:08, 26 April 2009 (EDT)<br /> <br /> ==Heavy laser mod==<br /> My heavy laser only has the two new firing modes. Also, when I fire, the beams don't go where I point. They seem to be grouped correctly, just off in the wrong direction.<br /> :Yeah, it is a problem when you enable range based accuracy at the same time. I'll try to fix that when I get some time... [[User:Seb76|Seb76]] 14:25, 23 April 2009 (EDT)<br /> :Made a new version. Can you try it and let me know if the problem is gone? [[User:Seb76|Seb76]] 09:19, 26 April 2009 (EDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=19837 2009-02-28T18:41:18Z

<p>J&#039;ordos: /* Heavy Laser Mod */</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> :::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)<br /> ::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J&amp;#39;ordos]] 05:01, 9 September 2008 (PDT)<br /> : Hey there, I've read about this project and I'm wondering if I can ran it with XComUtil but I play with the DOS versions (through DosBox) and thus use RunXCom. [[User:Hobbes|Hobbes]] 16:27, 13 September 2008 (PDT)<br /> ::Sorry there, this project uses modifications of the binary so it'll work only on the windows version. Why do you have to stick to the DOS version BTW? [[User:Seb76|Seb76]] 04:29, 14 September 2008 (PDT)<br /> :::DOS version was the first I played and I prefer its sounds (specially the alien death cries). I also prefer the DOS bugs (some on CE are too annoying). Thanks anyway :) [[User:Hobbes|Hobbes]] 11:26, 14 September 2008 (PDT)<br /> :::Hmm, something I remembered: IIRC, XComUtil splits the binary of CE into Tactical and Geoscape, in order for it to run with CE. I think I'll download your program and give it a try [[User:Hobbes|Hobbes]] 11:34, 14 September 2008 (PDT)<br /> ::::No success, doesn't surprise since I have the barest clue of what I should be doing. [[User:Hobbes|Hobbes]] 11:44, 14 September 2008 (PDT)<br /> ::There's no way it could work like that, windows binaries cannot run in DOS environment; split binaries or not. If you're pissed about a particular bug, just tell. I may be able to fix it ;-) Concerning the sounds, I don't know exactly what is the problem about CE version. If someone can give some details, I may have a look at that too. [[User:Seb76|Seb76]] 12:09, 14 September 2008 (PDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)<br /> <br /> OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your &quot;Full Auto&quot; mode would be 100% TUs for 10 rounds and your &quot;Burst Mode&quot; could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)<br /> <br /> : On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)<br /> <br /> Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ. <br /> <br /> Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz: <br /> <br /> See if you can get the &quot;hidden item&quot;, Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)<br /> <br /> :Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:<br /> :*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front<br /> :*reduce accuracy even further when shooting out of sight (this was mentionned in another post)<br /> :*change the damage model and reduce the probability that terrain is destroyed when shot<br /> :*have a cooldown period where the weapon is not useable (not sure if it's feasible though)<br /> <br /> ::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J&amp;#39;ordos]] 16:27, 7 September 2008 (PDT)<br /> :::Hm, I already cannibalized the unused &quot;open&quot; and &quot;close&quot; actions for the heavy laser mod, there is no more room for a new &quot;hit&quot; command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)<br /> <br /> :OK, here is the last draft before I finalize:<br /> :*Shooting the HL will cost ~50 energy so you won't be able to abuse it (the shooter will be a sitting duck)<br /> :*Each shot of a burst will reduce the accuracy (amount not determined yet)<br /> :*The [[User:Seb76#Range_Based_Accuracy|Range Based Accuracy]] will always apply to the HL<br /> :If everybody likes it, I'll got with that. Any comment? [[User:Seb76|Seb76]] 09:16, 22 November 2008 (CST)<br /> <br /> Sounds good to me. [[User:Spike|Spike]] 17:25, 22 November 2008 (CST)<br /> :OK, here we go. I won't tell you exactly what I did, just give me your feedback ;-) [[User:Seb76|Seb76]] 05:24, 23 November 2008 (CST)<br /> <br /> It's been a while, but recently tried your newest version and it seems the heavy laser is bugged? No matter which firing mode I choose it is extremely inaccurate and a lot of shots after travelling in one direction suddenly 'deflect' into another direction for some reason. It's a miracle none of my own guys were hit :) [[User:J'ordos|J&amp;#39;ordos]] 12:41, 28 February 2009 (CST)<br /> <br /> == Wish List please please please ==<br /> <br /> <br /> <br /> === New and Outstanding Requests ===<br /> <br /> * Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode. <br /> <br /> : Has this been completed via the &quot;Save Reserve Mode&quot; feature? Not entirely I guess as Reaction fire is still always in Snap. To be honest that's not a bad thing. [[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair. <br /> <br /> * Close down Exploits. (I've just been reorganising the Exploits pages so it's on my mind.) Maybe this is pointless for those who have the willpower just to abstain from using Exploits. But as these are actually bugs I think it would be good to fix them. The worst exploits in my opinion are:<br /> ** [[ExploitsA#Free Manufacturing|Free Manufacturing]]. Probably needs to add a check that the manufacturing project has &gt;0 units before allowing it to start. <br /> ** [[ExploitsA#Free Wages|Free Wages]]. Pay wages regardless of whether staff are in transit. They are on the payroll after all. This has a drawback that you pay twice (1.5x) for staff you hired very near the end of the month, which would affect some styles of gameplay.<br /> ** [[Tactical Exploits]]: The worst ones are the Collision Detection bugs, those I imagine are '''hard''' to fix. <br /> * Side-arm throws for grenades: It would be nice if the game could first check for a direct fire solution (side-arm throw or straight throw) for a grenade attack, if the target is in range for a straight throw, Range for straight throws would be reduced (to 1/4 or so of the parabolic range). It would only go on to attempt the indirect fire solution (parabolic vertical throw) if the direct fire attack returns &quot;no line of fire&quot;. This would avoid a lot of the &quot;hit the ceiling&quot; issues with grenade indirect fire.[[User:Spike|Spike]] 08:54, 23 November 2008 (CST)<br /> <br /> * With View All Locations, put some kind of indicator or (better yet) counter on the Geoscape screen when there are UFOs in flight. In case the UFO is on the other side of the world from where you are currently looking. '''-OR-'''<br /> * Make the world rotate at normal speed (i.e. once per 24 hrs. Rotation starts after say 12 or 24 hrs of looking at the Geoscape and not touching anything. Stops again if you touch the globe controls.<br /> * Make Aliens able to pick up a weapon if they are empty handed! Or just make them pick up anything Alien in their square, if that's easier. Maybe move them towards a weapon if they have no weapon - much harder to do I suppose. But at least, if they are empty handed and happen to walk over an Alien weapon, pick it up! See discussion [[Wish List#Alien AI|here]]. <br /> <br /> * Fix the [[Tactical Exploits#Fire|bug]] where all units in smoke/fire take stun/fire damage, whenever any smoke/fire hex is hit with an [[Incendiary]].<br /> <br /> * [[Wish List#Prior Recon of Battlefield|&quot;Eye in the Sky&quot;]]. Map (set to visible) all terrain features on Turn 1 (but do not sight any hostile units). Ideally this should be only the exterior of buildings but that's probably too tricky. Assume we have something like a FLIR on the Skyranger that can do basic imaging of the inside of buildings. <br /> <br /> * Grenades that [[Wish List#Warm Grenades|function normally]].<br /> <br /> * Fix Base Storage display problems that lead to storage weirdness. Discussion and recommendations [[Talk:Base Stores#Base Stores Anomalies|here]].<br /> <br /> ==== See Also ====<br /> <br /> *[[Wish List]]<br /> *[[Known Bugs]]<br /> *[[Exploits]]<br /> <br /> === Completed Items - Thanks Seb! ===<br /> <br /> See also the lists at: [[User:Seb76#Mods]] and [[User:Seb76#Bug_Fixes]]<br /> <br /> * Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault. <br /> :The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :: Completed with the &quot;Keep Base Navigation Tables&quot; option. <br /> <br /> * Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the &quot;Roswell Incident&quot;. Crash site would be automatically detected &amp; UFO would have random damage. <br /> :Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> :Update: feature almost complete, time to bake a new version ;-)<br /> <br /> :[[Image:Roswell.png]]<br /> <br /> :There are probably some bugs lurking (the most likely problem would be unfreed CRAFT.DAT entries), but I don't think I'll change the code much now. [[User:Seb76|Seb76]] 07:47, 13 September 2008 (PDT)<br /> <br /> <br /> * Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)<br /> <br /> : Fixed with &quot;Faster base defence sequence&quot; option. [[User:Spike|Spike]] 06:40, 14 December 2008 (CST)<br /> <br /> <br /> * Multiple Radar - Fixed. <br /> <br /> Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page. [[User:Spike|Spike]]<br /> :As I said, I used about the same as in you BaseFixer script:<br /> float shortDetection=pow(0.9f,smallRadars);<br /> float largeDetection=pow(0.8f,largeRadars);<br /> <br /> *(short *)(&amp;base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);<br /> *(short *)(&amp;base[0x12])=(short)((1.0-largeDetection)*100.0);<br /> :However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> * Accuracy reductions for long range snap and auto fire - Fixed. <br /> * Aircraft always ready for mission despite re-fuel/re-arm status - Fixed<br /> * Stack up base build orders in advance - Implemented<br /> * More smoke and fire - Fixed<br /> * Blaster drift and waypoint bug - Fixed<br /> * Stats visible during Equip phase - Implemented<br /> * Melee combat (bludgeoning) with any weapon - Fixed<br /> * With &quot;Council Funding Only&quot;, allow items to be sold for money if they are ''purchasable'' (i.e. conventional weapons). Buying and selling these is loss making, and there is no source of them on the Battlescape, so it does not create any &quot;income&quot; (except at the start of the game perhaps). But it does help to manage a tight budget. And you need all the help you can get with &quot;Council Funding Only&quot;. Check offset 18 of [[PURCHASE.DAT#Structure|PURCHASE.DAT]] If byte 18 is true then it's ordinarily Purchasable, so it's ok to sell that item. - OK, here is your christmas gift ;-) You can sell what you can purchase now. [[User:Seb76|Seb76]] 08:28, 28 December 2008 (CST)<br /> * Close Down Exploits<br /> ** [[ExploitsA#Robotic Manufacturing|Robotic Manufacturing]] / [[ExploitsA#Cybernetic Laboratories|Cybernetic Laboratories]] - Fixed<br /> <br /> == Warm Grenades ==<br /> <br /> It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them. <br /> <br /> This could be implemented by an extra bit of logic that increments the &quot;Turn When I Will Explode&quot; field by +2 if the grenade is being held/worn when the Explode check happens. <br /> <br /> For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE. <br /> <br /> Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)<br /> <br /> == Facility maintenance cost bug ==<br /> <br /> Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)<br /> :I'm a bit confused about this one. Some says that the fund graph is OK but not the amount of money taken. I had a look at the code and found that what is shown on the graphs is exactly the same amount as removed (the graph data is updated at the same place and the computation is done once for both). I think I remember also someone saying that the bug does not exist at all... Can someone clarify? [[User:Seb76|Seb76]] 02:31, 15 September 2008 (PDT)<br /> ::The graph is ok and the amount of money taken is ok (tested). What is wrong is the maintenance displayed in the 'Base overview' screen (in every respective base you go to 'overview' and something like 'maintenance'). The wrong way is very well described here [[Base_Facilities#Displayed_Base_Maintenance_Cost_Bug]], I think you will guess what exactly is wrong in the code. --[[User:Kyrub|Kyrub]] 15:34, 17 September 2008 (PDT)<br /> :Thanks, I found the code and it is indeed completely f*cked up. I'll try a fix tomorrow. [[User:Seb76|Seb76]] 16:53, 17 September 2008 (PDT)<br /> :Edit: Done. What's next? ;-) [[User:Seb76|Seb76]] 01:15, 18 September 2008 (PDT)<br /> ::Blimey. Seeing the work you have put in (below), it is impressive beyond measure. And... what next? Well... Could you possibly fix a game harming BUG of the blind spots? How come he sees you, and you do not see him, and vice-versa? There must be some strange way the line of sight is implemented in the code... See here: [[http://www.ufopaedia.org/index.php?title=Line_of_sight]], &quot;Blind spots around the corner&quot;.<br /> Just how bad was the mess up? Curios minds demand to know! By the way, my mind was wandering while at the office and one thing came to mind to add to your already useful inventory display: Armed grenade status. Ever drop one you've just armed and lose it in a pile of other unarmed grenades on the ground? <br /> :Well, from the look of it, I think they were trying to compute the maintenance cost using an array. Obviously something was wrong.<br /> :*they first try to clear an array of 0x11 entries at the begining of the function (there are 0x11 base elements types, hangar count as 1). Note that there is already a bug here and the array is not cleared as expected, only the first entry is cleared 0x11 times...<br /> mov esi, 11h<br /> ...<br /> loc_44004C:<br /> dec esi<br /> mov word ptr [esp+3Ch+elementsArray], 0<br /> jnz short loc_44004C<br /> :*ecx is initialized to point to the maintenance cost data (nothing wrong here)<br /> mov ecx, offset baseElements.maintenance<br /> :*then they loop on each base element, but the inner loop is nonsense (at this point ax contains the base element type. edi is the total maintenance cost):<br /> movsx eax, ax<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea eax, [eax+eax*4]<br /> lea edi, [edi+eax*8] ;totalMaintenaceCost+=elementMaintenanceCost*1000<br /> :we see that they increment the array element, but the content of the array is discarded and the maintenance cost (edi) is computed simply from [ecx].<br /> :*then after each row, we have this:<br /> add ecx, 10h<br /> :which explains why the cost changes for each row.<br /> :I don't see what kind of C code could produce such disassembly; maybe there is a bug in the compiler,at least the address calculation should have been removed (optimized out).<br /> :The fix required two patches:<br /> :*remove the incrementing of ecx for each row<br /> char nop[]={0x90,0x90,0x90};<br /> PatchInPlace(0x44066E,nop,3);<br /> :*make a working inner loop:<br /> char patch[]={<br /> 0x03, 0xc0, // add eax,eax<br /> 0x8a, 0x04, 0xc1, // mov al, BYTE PTR [ecx+eax*8] ;get the maintenance cost for the *specific* base element<br /> 0x0f, 0xb6, 0xc0, // movzx eax, al<br /> 0x90, 0x90, 0x90, 0x90, 0x90 // nop the remaining<br /> };<br /> PatchInPlace(0x440651,patch,13);<br /> :this takes care of the nonsense code<br /> inc word ptr [esp+eax*2+44h+elementsArray] ;increment the array entry corresponding to the base element type<br /> lea eax, [esp+eax*2+44h+elementsArray] ;get the address of the array entry we just incremented<br /> xor eax, eax ;discard the address we just computed (!)<br /> mov al, [ecx] ;get the maintenance cost from ecx; the element type is not used here (!)<br /> <br /> Very interesting stuff! By the way I'm playing a &quot;Roswell&quot; game at the moment and loving it - thanks Seb! [[User:Spike|Spike]] 10:31, 20 September 2008 (PDT)<br /> <br /> ==Grenade Status Indicator==<br /> <br /> Is it possible to include an indicator on the end of the grenade's name string to show whether the grenade has been armed? Or perhaps even show how many grenade ticks are left to go? <br /> :Hmm, I'll see if I can find something<br /> <br /> == Keyboard Support ==<br /> <br /> Would it be possible to introduce some keyboard shortcuts for simple tasks? -[[User:NKF|NKF]] 00:48, 19 September 2008 (PDT)<br /> :such as? [[User:Seb76|Seb76]] 02:52, 19 September 2008 (PDT)<br /> <br /> :: Hmm, perhaps a few keys like they had in Apocalypse for ending the turn and raising/lowering the elevation with the page up and down keys would be a good start, or jumping to the inventory screen. Perhaps keys in the Geoscape for setting the time compression settings. I can already see a bit of an obstacle with adding a key capture function in the Geoscape, you'd have to know when you're entering strings or every other time when you're just toggling the Geoscape overlay. I've always admired this game for relying on a two button mouse for pretty much everything except when entering strings, but if it's within the realm of possibility I think it would be great to have some keyboard shortcuts. -[[User:NKF|NKF]] 12:39, 19 September 2008 (PDT) <br /> <br /> <br /> ----<br /> <br /> First off have to say that this is outstanding work Seb, sincere thanks for what you have done here. I have started playing this again after years thanks to your hard work. I was going to suggest the old smoke limit problem but before I could you fixed it!! I have some other ideas, I know there are a lot but I thought I would throw them in anyway. Don’t mind if you think there all rubbish, you’ve done loads already. <br /> :Thanks. Don't hesitate to suggest stuff, if it is not too difficult I'll try to make something :)<br /> BTW is there a separate loader with your new Laser weapon? Can’t see it listed in the extender file (not researched it in my current game yet).<br /> :There is a special [[Image:UFOExtender-dev.zip|dev version]] for the HL mod. It is not in the normal package since it is still too experimental. <br /> A suggestion for a mod would be the following; I understand that if you defeat an alien assault on your base with base defense measures, then the aliens will continue to attack that base with more battleships until defeated inside the base (they then have to ‘find’ your base again before launching another attack). Can this be altered so that if their battleship is destroyed then they have to find your base again before dispatching anther battleship? Or a chance that they have to find it again. <br /> :I'd gladly work on that, but I need a savegame to reproduce the problem. I have one but when the battleship is destroyed, no other comes back later so there must be something wrong with it.<br /> Another suggestion is that I also understand that when the aliens use psi attacks they always go for your guys with the most chance of failing the attack and going nuts. Is it possible to make those pesky aliens attack random soldiers, regardless of their psi skill/strength? <br /> :At one time I had the idea of having aliens target only visible units, but then I thought that the scout units would be doomed. Maybe targeting any unit randomly would be better. I'll give it a try.<br /> If you psi control a human in a terror mission, they become enemies when you lose control (meaning you have to kill the poor idiots to finish the mission). Any chance that they could revert to friendlies/non enemies again when you lose control? <br /> <br /> Men who are under alien control when you win become MIA, any chance they could be saved (you will have killed all the aliens after all).<br /> :These two are on my secret todo list ;-)<br /> ::I was doing a Terror mission and getting creamed by Sectoids and Cyberdisks. Had a couple of guys left and got them back into the Skyranger only to find a civilian cowering at the back (must of walked in at some point). When I took off the civilian was counted as being killed by the aliens. Would it be possible to count any civilians in x-com craft at end of Terror as recued if you have to blast off? I think this would work interestingly with the civilians psi control issue above if they no longer became enemies after you control them. :-)--[[User:Mal310|Mal310]] 09:23, 22 September 2008 (PDT)<br /> 80 item bug on base defense mission<br /> :May be hard to pull off. IIRC there is a 170 objects limit in the battlescape, and we must leave some room for the aliens...<br /> I have noticed that sometimes you can shoot through hard objects, for example, recently I had a soldier up on the roof of a house overlooking a large scout craft. When a Sectiod moved through one of the inner doors of the UFO, my man shot him straight through the intact ufo roof! <br /> :I think this is a known issue with LOS, not sure though<br /> I don’t know if this is already implemented in the game? When the aliens attack your base and you defend it with base defense measures does the following occur and if not a mod maybe? When you hit the battleship with your weapons but it still gets through (e.g. you hit the battleship with some missiles before it lands) can the number of attackers be reduced accordingly. For example if you hit it with some missiles then maybe they could have a couple less soldiers attacking (could be random small amount) or when you hit with loads of stuff like plenty of fusion balls and the battleship just makes it then their attack could be reduced to a few aliens (all others got killed in the defense). As I say not sure if this is already there to some degree (not played in a long time and I’m not at that stage yet this time round). <br /> :I don't think this is done already. It may be possible to modify the number of units according to the damage done to the attacking ship, I'll have to take a look<br /> This one is way out there. Alien v Alien battles outwith main game, just ramdom battlescape maps. Sectoid and their terrorists against Floters and theirs etc. One side human controlled the other computer . Choice of ships involved etc. <br /> :Hmm, you do know I don't have the original source code available, don't you? :p<br /> Any plans to work on Terror from the deep? <br /> :I had a look and reidentifying the specific patch locations is quite tedious, and I'm quite lazy... The loader source is available however, if anyone feels like giving it a shot ;-) [[User:Seb76|Seb76]] 16:38, 19 September 2008 (PDT)<br /> <br /> Thanks for the reply. If I get a suitable saved game re the base attack I’ll let you know. Great to hear that a couple of the ideas are on your list already. I have been playing around with the smoke bombs since your fix. I have not noticed any problems, seems to be working fine. --[[User:Mal310|Mal310]] 12:10, 21 September 2008 (PDT)<br /> <br /> == Inventory screen ammo weight bug ==<br /> <br /> I think there is a small bug. The weight of loaded weapons is not initially calculated. The base weight of the weapon is used but the weight of the ammunition is ignored. However if you reload the weapon in the inventory screen, the correct weight is then calculated. I have seen this repeatedly with AutoCannons. I am using XcomUtil to 'remember' the equipment loads - maybe this might be part of the problem? [[User:Spike|Spike]] 09:24, 21 September 2008 (PDT)<br /> :Yeah, I noticed this one already but flagged it as minor :) I'm using a function that I found in the executable to calculate the weight (the one that's actually used by the game to see if a soldier is overburdened) so it is an original bug. Anyway, this calls for a fix ;-) [[User:Seb76|Seb76]] 09:47, 21 September 2008 (PDT)<br /> <br /> :: Is this the same bug that is present when calculating the throwing range of a loaded weapon? (NKF)<br /> :Does not ring any bell. Any link?<br /> <br /> == Equipment issue ==<br /> Also, something that I was reminded of while in the rifle vs. laser pistol discussion. It's not related to the weight bug but it is inventory related: The weird pistol arming bug where sometimes no one arms any pistols, or only one guy will arm one pistol and then fill every available inventory slot with the respective pistol clip. I'm sure it was thrown in so that pistols were always the last to be armed, but is it possible to make the game ignore this and arm the pistol like every other weapon? -[[User:NKF|NKF]] 15:20, 26 September 2008 (PDT)<br /> :There is a lot of possible work to do with how the soldiers are equiped (equip stuff on shoulders first instead of belt, keep equipment from last battle à la xcomutil, stop having one guy get stuffed up with every ammo available, etc). Since obviously all that is tightly intertwined, it requires some thought before getting into it... Plus this is a part of code that I did not analyse yet ;-) [[User:Seb76|Seb76]] 03:40, 27 September 2008 (PDT)<br /> <br /> == Request For UFO PS Explosion Offset ==<br /> <br /> Hi Seb, in the [[Talk:Explosions#UFO_Power_Source_Explosions|Explosions Talk page]] you mention the following:<br /> <br /> &lt;i&gt;Looks like before the first turn, the engine will look for every tile in the map (it scans the MAP.DAT data linearly) ; when it finds a power source (it checks if the MCD special property is set to 2), there is a 25% chance that it will leave it alone. Otherwise, it'll generate an explosion at the UPS location with a strength of 180+RND*70. Whether the UPS blows up on top of that or is just destroyed, I do not know. Can someone hack the MCD data and see if it's possible to generate an explosion on a tile that is not a UPS just by messing with the special property? PS: I am almost certain of the 75% probability of explosion vs 70% that is often stated here. [[User:Seb76|Seb76]] 09:31, 12 February 2008 (PST)&lt;/i&gt;<br /> <br /> I'm just wondering where the power source explosion is coded in the executable. If you could tell me that, I'd be able to edit it down so that units don't take quite so much damage. This is a whole heck of a lot better than editing unit stats to near maxed-out levels as the number of trials needed to find the average would be cut by a few orders of magnitude. Also, if you have an email address where I could contact you directly, it would be appreciated (email me with it). Thanks! --[[User:Zombie|Zombie]] 23:58, 2 November 2008 (CST)<br /> <br /> == Great new features ==<br /> <br /> Hi Seb! I just saw you uploaded a version with lots of new features. It was a great idea to add some of the [[Making the Game Harder]] scenarios. I look forward to trying all the new features out (some previous ones I've missed as well). Cheers! [[User:Spike|Spike]] 16:37, 19 November 2008 (CST)<br /> <br /> :OK I dusted off my Windows version of XCOM and installed your latest loader. I have to say I love it! The range-based accuracy is great. I use about half the default values, I might try returning them to the default levels as it makes snap&gt;auto for everything above point blank. But it's definitely working as designed. And I love the %Acc indicators over the target square. Not to mention the (primed) indicator on grenades. <br /> <br /> :I played with Alien Pets and Big Brother and View All Locations and found a few strange bugs:<br /> :* If you use the left and right arrows in the Inventory screen to try to move to a different Alien unit, you only see human units<br /> :* The character graphic displayed on the Inventory screen is a human, not the appropriate type of Alien<br /> :* For some reason if you check on turn one the aliens weapons are not loaded and not in their hands. This was in a Roswell scenario, so might be more to do with Roswell. - No, I also got it on my base defence mission. Hang on, silly me, this is just normal for Aliens under mind control isn't it? <br /> :* In night missions, even with Big Brother &lt;strike&gt;and View All Locations&lt;/strike&gt; set, I could only see what my guys had illuminated &amp; seen. <br /> :* View All Locations showed the incoming Battleship before my radars detected it on the half-hour, which gave me a brief chance to prepare my base for attack. Not exactly a bug, more a feature - different. Sadly I wasn't quick enough so ended up defending with loads of ammo clips and not enough weapons. :)<br /> ::The &quot;Hack&quot; section is really not to be used for gameplay; there I put patches that are useful to test my stuff, nothing more. I only make them available in case it can help someone with her analyse of the game. All the strange things you mention are expected behaviors ;-) [[User:Seb76|Seb76]]<br /> :* With Alien Bases and View All Locations, the X-COM bases show up as pink.<br /> :* It wasn't obvious to me that I needed to set e.g. &quot;Initial Alien Bases=20&quot; rather than just &quot;Initial Alien Bases=1&quot;. I is dumb! [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> <br /> :Now I need to check the notes on this page to get it working with XComUtil. The one thing that really p____s me off about playing without XComUtil is having to allocate equipment to my guys before every mission. It's really tedious! Especially as I tend to take 14 guys on each mission. <br /> :I have not developed Heavy Laser yet, &lt;strike&gt;nor beaten up any aliens in melee,&lt;/strike&gt; but I will let you know how that goes. Thanks for all your amazing work! [[User:Spike|Spike]] 19:00, 23 November 2008 (CST)<br /> <br /> :: Awesome. I just completed a mission by my Captain pistol-whipping a Floater Navigator into unconsciousness. How cool is that? But - possible bug - it cost my guy only 8 TUs per attack when he has about 58 total TUs. Is that intended, or is that an error? [[User:Spike|Spike]] 19:38, 23 November 2008 (CST) ''(Later)'' I'm regularly beating up aliens, it's a giggle. The close quarters combat feels much more authentic now, I love it. <br /> :::The small TU usage for the pistol is normal (it goes with small stun damage). I liked the idea of having to bash an alien for a while before he falls. Did you not experience reaction fire from the alien? [[User:Seb76|Seb76]]<br /> ::::The TU costs are percentage based instead of fixed(this has been clarified on the main page). 15% of 58 is 8.7 TUs, which truncates to 8. [[User:Arrow Quivershaft|Arrow Quivershaft]] 14:15, 24 November 2008 (CST)<br /> : I'm having so much fun and doing so well I got a Base Defence on Superhuman on Jan 12th. And with the old, sucky starting base layout (hangars take 25 days to move!). I've never seen so many Floaters and Reapers at one time. I knew there was a reason to hang on to those Incendiary rounds - bad doggie, down! Loads of fun, however one or two bugs have cropped up:<br /> ::Glad you're having fun :-) [[User:Seb76|Seb76]]<br /> <br /> ::* The game crashed as a soldier walked down the stairs from Living Quarters. This is probably a bug in the game and not a bug in your loader. <br /> : Let me know what details I can give you. [[User:Spike|Spike]] 20:43, 23 November 2008 (CST)<br /> ::Can you provide me with a savegame that reproduces the crash? I think it is the bug that makes defence missions crash around turn 5-6 sometimes (it crashes during the alien turn). I could not reproduce it. [[User:Seb76|Seb76]]<br /> <br /> <br /> == Base Disjoint Bug Fix ==<br /> A Base Disjoint has occurred, despite enabling your Based Disjoint bug fix. &lt;strike&gt;It may be an usual one because it's not on the bottom nor the right edge of the map (isn't that where Disjoints are supposed to happen?)&lt;/strike&gt;. It's the normal, bottom of the map edge kind. Here is a [[Media:BaseDisjointGenStores.ZIP|screenshot]] (anyone got a freeware TGA converter?).<br /> : Hum, the code was badly f***ed up. Can you retry with the last version? [[User:Seb76|Seb76]]<br /> <br /> I downloaded the latest version but unfortunately no effect. It didn't fix the saved Base Defence scenario. I also restarted from 3 hours before the attack and so created a new Base Defence mission, twice, but no change - still bugged. I'll post the [[Media:IncomingRetaliation.zip|savegame from 3 hrs before]] in case that helps. [[User:Spike|Spike]] 14:24, 25 November 2008 (CST)<br /> :Kinda weird, it works here. Maybe I made a faulty delivery... [[User:Seb76|Seb76]] 15:34, 25 November 2008 (CST)<br /> :Edit: nope, took the patcher from the delivery and it worked. Are you sure you enabled the fix? [[User:Seb76|Seb76]]<br /> Yes I doubled checked a couple of times. I set the flag as<br /> <br /> Base Disjoint=1<br /> <br /> Is that correct? I'll try again anyway. [[User:Spike|Spike]] 17:20, 25 November 2008 (CST)<br /> : Oops my fault. I updated the .exe but not the patcher.dll. (I didn't want to overwrite my UFOExtender.ini - very lazy of me.) Doh!<br /> <br /> == A couple of bugs to report ==<br /> <br /> Two things so far. With wreck analysis enabled I am getting analysis reports even after raiding alien bases. On one occasion this seemed to have fairly random strings inserted into the variables, resulting in the message &quot;The Alien Food UFO was on an Damage Capacity mission in Power Sources.&quot; All things considered, this is just a cosmetic problem as the actual UFOs are being properly analysed. However, this has got me curious as to what enables you to perform these analyses? It doesn't happen right from the beginning of the game, at least for me. From the description of the feature I thought maybe it was after researching UFO navigation, but then the messages started popping up before that.<br /> <br /> The other bug I have encountered is more severe. After building my first Firestorm I was completely unable to send it out for interception. Clicking on the craft in the list simply returned me to the Geoscape screen without allowing to pick a target, and the game continued to play normally. Disabling the feature for crafts to always be ready despite rearming, repairs and refueling fixed this. [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> :Been out for a while... I'll have a look at these two. [[User:Seb76|Seb76]] 11:04, 2 January 2009 (CST)<br /> <br /> Another case of erroneous wreck analysis, this time from an actual UFO: I followed a battleship on an alien base mission and assaulted it when it landed on its own. After the battle the analysis claimed it was on a raiding mission. Perhaps this has something to do with how alien bases are created the moment the battleship appears? [[User:Crowley|Crowley]] 15:52, 3 January 2009 (CST)<br /> <br /> :I use the data from [[MISDATA.DAT]] to get the mission details. Perhaps it is not correctly set at the time I retrieve the information. I'll investigate further. As for the firestorm problem, do you have a savegame just before the craft is finished so I can reproduce the bug easily? [[User:Seb76|Seb76]] 18:23, 3 January 2009 (CST)<br /> <br /> ::Unfortunately not, but I did make a separate save shortly after the craft was finished. I tested it, and turning on the &quot;crafts always ready&quot; option still disables Firestorms with all my saves. With more testing I found out this also affects Lightnings, but not Avengers. [[User:Crowley|Crowley]] 08:36, 4 January 2009 (CST)<br /> <br /> Instead of MISDATA.DAT, maybe grabbing the first byte out of [[LOC.DAT]] might be more accurate? I'm not entirely positive if offset 76 of MISDATA is for just crash sites or all sites in general. BB would know for sure. --[[User:Zombie|Zombie]] 20:25, 3 January 2009 (CST)<br /> <br /> :&quot;Raiding&quot; ''is'' what you're supposed to get if you're not lucky enough to get both the mission type ''and'' the zone, as in the .ini file: &lt;pre&gt;Zone Discovered=Intel found out that the %s UFO was raiding %s&lt;/pre&gt;If I remember correctly, difficulty level and the number of recovered navigation modules determine the chance of finding out both pieces of information, so it can't be Christmas every day ;)<br /> <br /> :Regarding the 'Craft always ready' option, I had some Interceptors not launching as described by Crowley above but turned out they had 0% fuel, thanks to the [[Known_Bugs#Fuel_dump_on_transfer|transfer bug]] (shuffled them around ages ago to make room for Avengers and forgot about them ;) ). Maybe Crowley's Firestorms were also transferred around? In any case enabling this option is a bit tricky, if you happen to have craft with the fuel bug sitting around without realising it (or knowing about the bug to begin with); all I can think of right now is to have this option enforce the transfer bug fix ''and'' somehow have buggy craft (0% fuel but ready) update their status to 'refuelling'... Wouldn't be surprised if there's a global 'update interval' in Geoscape when all craft marked as 'refuelling' get their fuel level increased; if so, it might be possible to change that status check to use fuel level instead (much like what this option already does, for the selected craft only) [[User:Goran|Goran]] 00:09, 4 January 2009 (CST)<br /> <br /> ::Repairing interception craft repair one point of damage capacity per hour (XX:00), refuelling interception craft are granted an amount of fuel each half hour(XX:00 and XX:30) dependent on craft, and rearming interception craft are given an amount of ammo each hour(XX:00) dependent on the weapon being loaded. [[User:Arrow Quivershaft|Arrow Quivershaft]] 05:12, 11 January 2009 (CST)<br /> :Being busy with work ccurrently so I've not much time for the loader. I already use the fuel level instead of the status. I used a value of 30 as a threshold for readyness which is OK for standard fuel ships, but for elerium ships it's too high: even when fully refuelled, they don't exceed it. Reducing the value should be enough to fix the problem. [[User:Seb76|Seb76]] 05:22, 11 January 2009 (CST)<br /> <br /> Some more comments:<br /> # Limited Military = 1 gives you only 1 soldier. OK, I guess it's meant to do that, but it was not obvious. User error! But maybe it's time to add &quot;usage&quot; comments to the .INI file?<br /> # Personnel Overflow works ok, even when the extra personnel are transferred in from another base (instead of being Recruited) - good job!<br /> [[User:Spike|Spike]] 13:20, 2 January 2009 (CST)<br /> :What's wrong with the info from readme.txt? [[User:Seb76|Seb76]] 05:13, 3 January 2009 (CST)<br /> *Limited Military: you start with this specified amount of soldiers and cannot recruit any more during the game<br /> <br /> :: User Error ^2 - I didn't read the readme.txt either :) [[User:Spike|Spike]] 12:17, 3 January 2009 (CST)<br /> <br /> Errr.... why do Launchers do more stun damage than the Stun Rod? ... Electrocuting someone should do more than just hitting them with a large object? ... for that matter, stun damage of 80 is a LOT... remember that being shot with a rifle does 30, and a grenade does 50. (IMHO, the stun rod is likely to use VERY high voltage... it is much larger than a normal stun gun, and X-com doesn't mind doing permanent damage to the aliens)<br /> Here's a challenge for your coding skills, and a logical one too: make melee do more damage based on Strength stat. My 80 strength goliath should do more damage than my 10 strength rookie wimp... [[User:Jasonred|Jasonred]] [[User:Jasonred|Jasonred]] 18:40, 26 February 2009 (CST)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=16877 2008-09-09T12:01:43Z

<p>J&#039;ordos: /* UFOloader and Xcomutil */</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> :::After spending an hour with reading through this double discussion and trying to find the right batch file in the old archives and make the game work, I decided to put your '''Xcomutil + UFOloader solution''' here: [[Image:RunXcomW.zip]] with a simple explanation. Hope you don't mind.--[[User:Kyrub|Kyrub]] 15:43, 8 September 2008 (PDT)<br /> ::::Actually you don't need the modified runxcomw.bat file, the way I do it is I tell xcomutil to use f0dder's loaders and then I simply replace xcloader.exe (xcomutil's included f0dder patch) with UFOLoader.exe! [[User:J'ordos|J&amp;#39;ordos]] 05:01, 9 September 2008 (PDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)<br /> <br /> OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your &quot;Full Auto&quot; mode would be 100% TUs for 10 rounds and your &quot;Burst Mode&quot; could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)<br /> <br /> : On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)<br /> <br /> Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ. <br /> <br /> Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz: <br /> <br /> See if you can get the &quot;hidden item&quot;, Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)<br /> <br /> :Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:<br /> :*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front<br /> :*reduce accuracy even further when shooting out of sight (this was mentionned in another post)<br /> :*change the damage model and reduce the probability that terrain is destroyed when shot<br /> :*have a cooldown period where the weapon is not useable (not sure if it's feasible though)<br /> <br /> ::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J&amp;#39;ordos]] 16:27, 7 September 2008 (PDT)<br /> :::Hm, I already cannibalized the unused &quot;open&quot; and &quot;close&quot; actions for the heavy laser mod, there is no more room for a new &quot;hit&quot; command. Unless... ;-) [[User:Seb76|Seb76]] 11:28, 8 September 2008 (PDT)<br /> <br /> == Wish List please please please ==<br /> <br /> Seb: Wow! I can't believe what you've done with UFO Extender! I wish I could try it but I can't get XCom working on my current PC. <br /> <br /> Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page.<br /> :As I said, I used about the same as in you BaseFixer script:<br /> float shortDetection=pow(0.9f,smallRadars);<br /> float largeDetection=pow(0.8f,largeRadars);<br /> <br /> *(short *)(&amp;base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);<br /> *(short *)(&amp;base[0x12])=(short)((1.0-largeDetection)*100.0);<br /> :However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> Now then, requests - could we please have:<br /> <br /> * Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault. <br /> :The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> * Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the &quot;Roswell Incident&quot;. Crash site would be automatically detected &amp; UFO would have random damage. <br /> :Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> Both of the above are totally pointless, apart from helping with my silly &quot;No Detection&quot; variant game, and actually making it possible to win. <br /> <br /> * Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode. <br /> <br /> * Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair. <br /> <br /> I can't think of much else, as you've already fixed everything!<br /> <br /> On the Heavy Laser Mod, my initial thoughts are that it is fun and cool but too powerful. The overall shots per turn should not be more than normal auto mode. The accuracy should be lower than normal auto. Having the 'sweep' effect is advantage enough. I'll have a think and suggest some numbers. [[User:Spike|Spike]] 11:41, 1 September 2008 (PDT)<br /> <br /> : Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)<br /> <br /> == Warm Grenades ==<br /> <br /> It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them. <br /> <br /> This could be implemented by an extra bit of logic that increments the &quot;Turn When I Will Explode&quot; field by +2 if the grenade is being held/worn when the Explode check happens. <br /> <br /> For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE. <br /> <br /> Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)<br /> <br /> == Facility maintenance cost bug ==<br /> <br /> Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=16850 2008-09-07T23:27:53Z

<p>J&#039;ordos: /* Heavy Laser Mod */</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)<br /> <br /> OK, it's cool but it really is overpowered. Accuracy must be lower in Auto modes than in Snap, that's basic in the game. If you assume the Heavy Laser is somehow better optimised for autofire than the Laser Rifle, and set the TUs for normal Auto at say 30% (vs 34% with Laser Rifle) that would let you get off 3 bursts, which would be better. (I could live with the idea that you can also only fire 3 snap shots). Then your &quot;Full Auto&quot; mode would be 100% TUs for 10 rounds and your &quot;Burst Mode&quot; could be 50% TUs for 5 rounds, and that would be consistent with the 'standard' Auto mode. But the accuracy per shot needs to be much lower. I would suggest the base Accuracy per shot is reduced to 33% (one third less than Snap, similar to a Laser Rifle). You are still making the weapon MUCH more effective this way. [[User:Spike|Spike]] 12:47, 1 September 2008 (PDT)<br /> <br /> : On further analysis, even this is too powerful. The stats I just cited would give firepower only a fraction less than a Heavy Plasma - with much lower cost, unlimited ammo and easier-to-reach technology. That's not balanced. Unfortunately, you can't really go above 6 shots per turn without unbalancing the game, as none of the 2 handed weapons fire more than 6 shots/turn. So the TUs for Auto need to be 34%-40%, and you can't really have it fire more than 6 shots per turn even in the Full Auto mode. I would suggest Auto = 35%, Burst = 75%, Full Auto = 80%. Burst and Full Auto only fire 6 shots. Burst Mode fires 2 shots each at 2 waypoints, and a further 2 rounds spread in between the 2 waypoints. Full Auto fires one each at 2 waypoints and 4 shots spread between the waypoints. And maybe the Burst Mode should be the more expensive one as it is more 'concentrated' fire. The reason you can't really exceed 6 shots per turn, even if you reduce the accuracy drastically, is because otherwise you create a super-effective shock weapon at point blank range (and a super effective terrain-clearing weapon). Somehow the 'shock power' in particular seems inappropriate for something as clumsy as a Heavy Laser. To rationalise it, think of it this way - it's not a machinegun, it's an energy weapon. The 'cyclic rate of fire' is limited by the energy circuitry as much as anything else. So squeezing six shots per turn out rather than 3 (the limit with Snap fire) is a pretty good improvement. With the Auto Mode I've suggested here, you have still double the 'shock' firepower of the Heavy Laser at short range, and increased its firepower by two thirds at longer ranges. Not a bad way to put some life back into a weapon that otherwise has very limited uses. Probably in the 'Area' modes (Burst / Full Auto) the Accuracy should drop, say to 25% (vs 33% in standard Auto). [[User:Spike|Spike]] 13:48, 1 September 2008 (PDT)<br /> <br /> Ok I finally shut down my NeXCom Workstation and turned out the lights in the Bean Counter's Department at X-Com HQ - and headed down to the Armoury. I checked out one of the new, experimental Super Heavy Auto Lasers and ducked onto an Avenger heading into a hot LZ. <br /> <br /> Seb, let me tell, you, it was SPECTACULAR! You are the Ayatollah of Rock-and-Rolla! I was like Jesse Ventura in Predator, carving up the jungle with his minigun. I love your gun. It is too cool. It must not be nerfed. So I have another suggestion for your coding skillz: <br /> <br /> See if you can get the &quot;hidden item&quot;, Gatling Laser, working. Add your Super Heavy Auto Laser as a new item, using the Gatling Laser image and OBDATA entry. I don't know if you can add a new Research option or a new Manufacturing option. If you can't, maybe you can offer it to Purchase (once Heavy Laser is researched, or perhaps Laser Cannon). Given the power of the weapon (as spec'd above), the cost to buy or manufacture should be similar to a Heavy Plasma: around a total cost of $164K to manufacture (including ''all'' costs) or around $225K to buy. As a quick hack, for the time being, if you are still using the Heavy Laser object for the Super Heavy Auto Laser (with 10 shot Full Auto), increase the manufacturing costs and buy/sell prices to roughly the same as the Heavy Plasma. [[User:Spike|Spike]] 13:29, 3 September 2008 (PDT)<br /> <br /> :Thanks for the nice feedback! The initial idea for this mod came when watching a Laser Squad speedrun (never played the game myself) and seeing the guy waste several baddies with one auto-shot sweep (in this game you can also select the number of shots when auto-firing). I chose to try a modification of the heavy laser for 2 reasons: everybody agrees to say that the default one sucks and second, since it uses no ammunition there is no need to handle out-of-ammo conditions. I personally see this weapon more as a recipe for new doors than a direct way to kill aliens. Several things could nerf it a bit but I didn't try them yet:<br /> :*make accuracy lower and lower during a burst (to account for the laser lens deformation caused by overheating). This would restore the advantage of cover and make people thing twice before firing when a friendly unit stands in front<br /> :*reduce accuracy even further when shooting out of sight (this was mentionned in another post)<br /> :*change the damage model and reduce the probability that terrain is destroyed when shot<br /> :*have a cooldown period where the weapon is not useable (not sure if it's feasible though)<br /> <br /> ::Yeah cooldown periods! Then restore functionality of the melee HIT command. Hey it worked for incubation: time is running out. ^^ [[User:J'ordos|J&amp;#39;ordos]] 16:27, 7 September 2008 (PDT)<br /> <br /> == Wish List please please please ==<br /> <br /> Seb: Wow! I can't believe what you've done with UFO Extender! I wish I could try it but I can't get XCom working on my current PC. <br /> <br /> Can I ask what algorithm you used for Multiple Radar? The algorithm in my BaseFixer.py Python script is actually much better than the fairly lame one described on my User page.<br /> :As I said, I used about the same as in you BaseFixer script:<br /> float shortDetection=pow(0.9f,smallRadars);<br /> float largeDetection=pow(0.8f,largeRadars);<br /> <br /> *(short *)(&amp;base[0x10])=(short)((1.0-shortDetection*largeDetection)*100.0);<br /> *(short *)(&amp;base[0x12])=(short)((1.0-largeDetection)*100.0);<br /> :However I keep the computed value even for the one small/one big radar combo ;-) [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> Now then, requests - could we please have:<br /> <br /> * Add 1-2 UFO Navigation to the haul after a successful Alien Base Assault. <br /> :The game actually has specific code to remove these from the recovered items, it's just a matter of bypassing it. Next version will have an option to do so. [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> * Random chance (1-2%, and only for Scouts) per mission that a UFO accidentally crashes - like the &quot;Roswell Incident&quot;. Crash site would be automatically detected &amp; UFO would have random damage. <br /> :Sounds like a nice idea. I'm working on it but I still have some crashes, and the routine to check if a ship is over water does not seem to work properly :( [[User:Seb76|Seb76]] 07:19, 7 September 2008 (PDT)<br /> <br /> Both of the above are totally pointless, apart from helping with my silly &quot;No Detection&quot; variant game, and actually making it possible to win. <br /> <br /> * Allow human side soldiers to reaction fire in their currently saved Reserved Fire mode - eg to take Autofire or Aimed reaction shots. That would be very, very cool. It would also be a balanced trade-off, if these Reacting soldiers were not allowed to 'switch' to Snap fire after they no longer have the TUs left to use their Reserved mode. <br /> <br /> * Implement your 'Area Fire' (as per Heavy Laser) for '''all''' large automatic weapons (AutoCannon, Heavy Plasma) or maybe just for all automatic weapons, period. It would be very handy for Autocannon bursts to cover a wider area, firing a narrow burst is often not what you want at all in many tactical situations. There might be a problem implementing this for Plasma weapons, if you couldn't persuade the Aliens' AI to use the Area modes - it wouldn't be fair. <br /> <br /> I can't think of much else, as you've already fixed everything!<br /> <br /> On the Heavy Laser Mod, my initial thoughts are that it is fun and cool but too powerful. The overall shots per turn should not be more than normal auto mode. The accuracy should be lower than normal auto. Having the 'sweep' effect is advantage enough. I'll have a think and suggest some numbers. [[User:Spike|Spike]] 11:41, 1 September 2008 (PDT)<br /> <br /> : Got an idea while I was at work today that I thought I'd throw onto the wish list. Some means to completely fast-forward the base defense screen. Either by making all the firing sequences happen in an instant, or completely skip the screen altogether. I always advise against making impenetrable bases if only to preserve your sanity. I mean you eventually get sick of being interrupted to watch the defense module firing screen for the umpteenth time. If you never got the interruptions then an impenetrable base would be quite satisfactory. You shouldn't be getting any points for a failed base attack so you won't be gaining from it. About the only problem would be when an undefended base gets destroyed, unless you can make a dialog box pop up to announce it. -[[User:NKF|NKF]] 03:10, 2 September 2008 (PDT)<br /> <br /> == Warm Grenades ==<br /> <br /> It would be nice to have a Mod where grenades / HE explode a set number of half-turns after you drop/place them. <br /> <br /> This could be implemented by an extra bit of logic that increments the &quot;Turn When I Will Explode&quot; field by +2 if the grenade is being held/worn when the Explode check happens. <br /> <br /> For me this is a more natural way for grenades to work: set the fuse, then the fuse only starts when you release the spring or set the HE pack in position. Certainly hand grenades should behave this way. I guess people could argue that HE packs should behave in the standard way. In which case, you could check the weapon type and use different logic for HE. <br /> <br /> Hopefully the Alien AI would not be confused by any of these changes. I suspect the AI cheats anyway? Or always sets to 0 and throws right away? [[User:Spike|Spike]] 02:00, 2 September 2008 (PDT)<br /> <br /> == Facility maintenance cost bug ==<br /> <br /> Could you fix that? [[User:Spike|Spike]] 16:15, 3 September 2008 (PDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=Talk:Hoverbike_(Apocalypse)&diff=16724 2008-09-01T16:41:10Z

<p>J&#039;ordos: </p> <hr /> <div>The official entry says &quot;The Hoverbike can be a valuable means of transport for the Agent on investigative missions where speed of response is essential.&quot; Is there ever such a situation though? It seems waiting another minute for the Valkyrie to arrive with 8-12 agents is usually more practical, unless you are roleplaying.<br /> <br /> The hoverbike can be useful if you want to send an agent or two to stun raid the slums for psiclone though.<br /> --[[User:Captain Foo|Captain Foo]] 09:13, 1 September 2008 (PDT)<br /> <br /> Well it's just fluff text, but I always kinda assumed it referred to the stripped out VIP part of the game, where speed&amp;stealth (tracker gun) might have been more important than squad size? [[User:J'ordos|J&amp;#39;ordos]] 09:41, 1 September 2008 (PDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=16677 2008-08-31T12:44:49Z

<p>J&#039;ordos: New section: Heavy Laser Mod</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> :Edit2: playing with the heavy laser mod, I found the data for bullet image/sound. It is located at offset 0x6D1F8. Each entry is organized like that:<br /> struct {<br /> short bulletVisual;<br /> short shootSound;<br /> short impactSound; <br /> short impactAnimation;<br /> }<br /> Entries are sorted per [[OBDATA.DAT]] ID (i.e. the first entry is for pistol, the 0x12th for heavy laser, etc.) [[User:Seb76|Seb76]] 15:31, 2 August 2008 (PDT)<br /> <br /> : Ah, that'll help with some modding. Although I just remembered something that I was going to ask at the time - but completely forgot about. What controls how the weapon is displayed while in the soldier's hands? I mean, the pistols are displayed with the weapon extended in the firing position while most other weapons are held across in both hands (mimicking one/two handed items). Would this be hard coded as well in addition to the unique item actions? -[[User:NKF|NKF]] 17:43, 2 August 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^<br /> :Thanks for the feedback, it is good to know that it is possible to have this work with xcomutil. BTW, the fix I did in the test version is also in the latest package with the ammo clip hack ;-) [[User:Seb76|Seb76]] 16:16, 27 July 2008 (PDT)<br /> <br /> == Heavy Laser Mod ==<br /> <br /> Hey Seb, I've been trying the new heavy laser. It's a cool idea, adds some new options during battle :) But I think currently the full auto option is overpowered. I hardly use the burst mode at all. I'd suggest lowering the accuracy and/or (if possible) reducing the amount of shots fired? Currently when I see a single alien I use full auto (can't miss with 10 shots), when I see a terror unit I use full auto (2x2 + 10 shots = dead terror unit :) ), and when I see a group of aliens I also use full auto (10 shots &gt; 5 shots). A few units still standing? Bring on the next heavy laser.<br /> Also because these new fire modes don't mind line of fire restrictions cover won't help aliens at all (unless the cover is strong enough to withstand HL power). Just use full auto to blast through any house that's in the way and in most cases it'll still kill the alien as well. (do need to make sure no agents/civilians are standing in the line of fire though) <br /> Should note that ATM I'm still only dealing with sectoids and the occasional floater. Will let you know how it fares against the later races.<br /> [[User:J'ordos|J&amp;#39;ordos]] 05:44, 31 August 2008 (PDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15895 2008-07-27T22:43:09Z

<p>J&#039;ordos: </p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?<br /> :I was talking about the &quot;a program has cause xxx to close unexpectedly&quot; (or whatever it is in the US version) dialog box. This looks more like a silent crash (the worth case). I modified the loader and it looks better. I still have the &quot;ctrl-C&quot; issue however. [[User:Seb76|Seb76]] 12:38, 27 July 2008 (PDT)<br /> <br /> :: &lt;3 don't know what you did but the latest version works perfect! Just did 3 missions in a row, restarted xcom and did another 2 (only actually completed one of 'em tho :) ) without any crashes at all! *crosses fingers* I enabled all the settings I wanted in both xcomutil and the UFOLoader without problems. Thanks Seb, excellent work! ;-)<br /> :: oh and the ctrl+C thing is a problem in the xcomutil batch file, it's not your program's fault. The Xcopy commands in the runxcomW.bat file are missing a /Y parameter. Here's a link to the xcomufo.com forum thread discussing it for anyone interested: [http://www.xcomufo.com/forums/index.php?showtopic=242025489]<br /> :: Whew, was quite a ride... Now, where's my ammo clip fix? ^^</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15889 2008-07-27T19:11:18Z

<p>J&#039;ordos: </p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)<br /> :Can you give me the address of the error when it crashes? (accessible in the crash window dialog)[[User:Seb76|Seb76]] 11:29, 27 July 2008 (PDT)<br /> <br /> :: There is nothing when it crashes, not even the console remains. Unless you're talking about a log file?</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15887 2008-07-27T17:50:42Z

<p>J&#039;ordos: </p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)<br /> :: edit2: OK here's what I have so far: It crashes if the previous mission worked. It works if it crashed on the previous mission. If I delete the contents of the MISSDAT folder it always crashes until I do a mission without xcomutil and/or without the loader. After that the normal rules apply. (i.e. next mission I play with both xcomutil&amp;the loader it'll crash, as the previous mission worked, but the next one will work again) very strange :s Note that I did not yet try to play out a full mission, I always aborted on the first turn. Hope you can narrow the problem down a bit this way :-) [[User:J'ordos|J&amp;#39;ordos]] 10:50, 27 July 2008 (PDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15886 2008-07-27T17:37:06Z

<p>J&#039;ordos: </p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)<br /> <br /> :: edit: quick testing reveals that it actually crashes exactly 1 times in 2, apparently regardless of what fixes are on. (though I did not yet test any xcomutil features) I guess it's probably related to one of the MISSDAT files? [[User:J'ordos|J&amp;#39;ordos]] 10:37, 27 July 2008 (PDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15885 2008-07-27T17:31:19Z

<p>J&#039;ordos: </p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(<br /> :About the 3sec pause, it may be related to the musicfix that f0dder's patch does: it runs the MCI commands in a separate thread to remove the pause due to synchronous calls (with the unpatched version, there is a &quot;slight&quot; pause (~0.5sec on my computer) each time the music changes). Do you have the same pause in the main menu? Also if you activate the PSX music patch (even with no CD in the tray), it should remove the pause (if it is indeed the same problem). For your crash, I haven't got a clue. Maybe it's time I release the source code so people with different configurations can try more stuff. I know there are imaginative people out there ;-) [[User:Seb76|Seb76]] 07:02, 27 July 2008 (PDT)<br /> <br /> :: Ah that fixed the delays, thanks! Strangely the battlescape now works fine (using ctrl+C) as long as I don't enable the equipment patch with xcomutil... Don't know about the other fixes&amp;flags. I'll do some more testing. [[User:J'ordos|J&amp;#39;ordos]] 10:31, 27 July 2008 (PDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15883 2008-07-26T23:36:41Z

<p>J&#039;ordos: </p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :The only modification I did to this version is forward the parameters passed to the loader to the XCOM executable (geoscape is passed an argument which tells it if it needs to start from scratch, or use the data from the missdat folder). Also it cannot work with f0dder's patch the way you tried: doing so, you are patching the xcloader binary itself, which obviously is not what you want.<br /> :Edit: I added a &quot;Video Pitch&quot; bug fix to compensate for the incompatibility of the 2 loaders ;)<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> :Hm, I guess that's what you get when experimenting stuff at 1:00 am ;-) (GMT+2 here)<br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :I start the runxcomw.bat batch from a shell and I have to do a &quot;ctrl-C&quot; between phases . Maybe it is because I replied yes to &quot;Do you want to see XcomUtil messages after combat?&quot; <br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.<br /> :Did you try disabling every XComUtil features? I don't know how extensively it modifies the main executable. Here it works with the following config: replied &quot;no&quot; to everything while installing XComUtil (so that only executable splitting is done), enabling only equipment screen patches with my loader, and starting via the attached batch file. I can start a new game, down a UFO, go into tactical mode and go back to the geoscape view after taking down all the aliens. Did you try renaming UFOLoader.exe into xcloader.exe? It might work [[User:Seb76|Seb76]] 12:21, 25 July 2008 (PDT)<br /> <br /> :: Thanks for your efforts, but still no luck. I downloaded the new version and did a fresh install of xcom. Running the UFOloader without xcomutil works fine (with your directdraw patch I get a ~3sec pause everytime the game zooms in/out on an interception though, which does not occur with f0dder's patch). Running xcomutil without the UFOLoader also works fine (using ctrl+C). I then did another fresh install and put the both of 'em together. I enabled the equipment screen patch and the directdraw fix on UFOLoader and told xcomutil to use f0dder's loader, answering no to all other questions. Renamed UFOLoader.exe to xcloader.exe and started runxcomW.bat. The game crashed when it should go to the equipment screen. (no ctrl+C possible) Disabling the equipment screen patch and/or enabling xcomutil's messages after combat yielded the same result. :(</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15879 2008-07-25T02:12:57Z

<p>J&#039;ordos: </p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)<br /> <br /> :: edit: I decided to do some testing first by manually disabling directdraw to circumvent the bugfix loader problem. Unfortunately the game crashes as soon as I enter tactical combat (when it should go to the equipment screen) even when all features are disabled. But unless I delete the MISSDAT folder's contents the next time I run runxcomW.bat I can hear the battlescape music playing. Unfortunately the batch file seems to get stuck in an infinite loop or something as it just keeps starting xcom over and over until it finally kills my system! :-) (all my base really belong to you ;-) )<br /> :: using the previous version I can enter battles just fine, but none of the UFOloader features work.</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15878 2008-07-25T01:25:16Z

<p>J&#039;ordos: </p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)<br /> :You can try this version: [[Image:UFOExtender-dev.zip ]]. I did not really have time to test it. Use the modified batch and keep me posted ;-) You'll get a crash if you activate the patch to disable the introduction movie. I checked the equipment screen patches, they were OK. TFTD will wait till I'm satisfied with the XCOM version. Anyway, I'm not in a disassembling frenzy right now :p [[User:Seb76|Seb76]] 15:29, 24 July 2008 (PDT)<br /> <br /> :: Hey fast response, thanks! I tried the new version but unless I'm missing something I've been unable to get it to include f0dder's bugfix loaders. I edited the ini file's Executable= to 'xcloader.exe', xcomutil's included bugfix loader, and when I run UFOloader.exe directly it works fine, but when using your modified runxcomW.bat it seems to be disregarded. This was not the case with your previous version. (I actually thought of modifying runxcomW.bat like that :-) ) Can't seem to find any reason for it in runxcomW.bat.<br /> :: also a minor note, but on a fresh xcom install the console echoes a read error on MISSDAT\saveinfo.dat (I assume this is the work of xcomutil) and minimizes Xcom to the tray. It still works fine though.<br /> :: while on the subject of minor notes the 'Rank In Inventory=' in your ini file actually has the letter O instead of the number 0 by default ;-)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User_talk:Seb76&diff=15875 2008-07-24T21:09:56Z

<p>J&#039;ordos: New section: UFOloader and Xcomutil</p> <hr /> <div>Hey, sorry to pester you again. :) I've gotten access to IDA, as you suggested, and with it I'm making some slow progress toward my mod. I wanted to ask, though, do you know of any sort of tutorial or useful intro for it? The user interface is pretty obtuse, the built-in help has nothing useful, and I've been struggling just to make comments go where I want them to.<br /> <br /> (I mean, I understand that it's meant for very advanced users, but Jesus, who writes an enterprise-grade utility and doesn't bother to implement an Undo function?!?)<br /> <br /> Thanks again for your help! [[User:Phasma Felis|Phasma Felis]] 23:15, 16 June 2008 (PDT)<br /> <br /> <br /> Okay, a little more progress since I discovered anterior comments. Couple of more specific questions: what's the difference between a &quot;comment&quot; and a &quot;repeatable comment&quot;? Or any of the several other types of comments, for that matter.<br /> <br /> What exactly does &quot;mov cs:word_102F9, ax&quot; do? At first I thought it was just copying the accumulator into the data word at 02F9, but the &quot;cs:&quot; part is confusing. word_102F9 is 0, I think (&quot;seg000:02F9 word_102F9 dw 0&quot;). Does that mean it's copying AX into the current code segment, offset 0, modifying the code in progress? That seems odd.<br /> <br /> Okay, one more and then I'll go to bed: what does &quot;jmp short $+2&quot; do? It looks like it just means &quot;jump to next instruction&quot;, which is kinda redundant, but it could be &quot;jump ''over'' next instruction&quot;, which...still seems unnecessarily verbose. I dunno. [[User:Phasma Felis|Phasma Felis]] 00:51, 17 June 2008 (PDT)<br /> <br /> : The last two questions are actually general Intel 16-bit assembly ;)<br /> <br /> : The cs in &quot;mov cs:word_102F9, ax&quot; is the 16-bit code segment base, yes. It *might* be self-modifying code, but more likely there is a C global or static variable that was implemented there and being updated. The &quot;seg000:02F9 word_102F9 dw 0&quot; is probably from C default initialization, but could be from an explicit initialization to 0.<br /> ::Back in the 16bit days, there were several memory models. My knowledge on this is quite rusty, but IIRC COM executables were using the &quot;tiny&quot; one which means that the code and data use the same segment (I assume you're working on the music TSR?). Modification of data via the CS segment is not necessarily self-modifying code. Also TSRs were usually signaled using software interruptions so the code most likely sets up an interrupt vector and bails out. e.g.:<br /> seg000:0140 mov dx, 157h<br /> seg000:0143 push ds<br /> seg000:0144 push cs<br /> seg000:0145 pop ds<br /> seg000:0146 mov ax, 2566h<br /> seg000:0149 int 21h ; DOS - SET INTERRUPT VECTOR<br /> seg000:0149 ; AL = interrupt number<br /> seg000:0149 ; DS:DX = new vector to be used for specified interrupt<br /> seg000:014B pop ds<br /> seg000:014C call sub_1067A<br /> seg000:014F mov dx, ax<br /> seg000:0151 mov ax, 3100h<br /> seg000:0154 int 21h ; DOS - DOS 2+ - TERMINATE BUT STAY RESIDENT<br /> seg000:0154 start endp ; AL = exit code, DX = program size, in paragraphs<br /> <br /> ::In this example (from music.com), there is code at 157h but IDA does not detect it. You can get there, type 'C' and create a new function. The code there is the most important. HTH [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> ::: There were at least six common memory models. *.COM not only assumed a single code and single data segment, it assumed their base addresses were the same. You get four more (with one segment of static data) by 1 or more than 1 of each of code and data segments [near and far pointer distinctions]. The last allowed more than 64K of static data.<br /> <br /> ::: XCOM most likely used one of the double-far memory models. -- [[User:Zaimoni|Zaimoni]], 9:31 Jun 19 2008 CDT<br /> <br /> : &quot;jmp short $+2&quot; is jump over the next instruction, if the next instruction is 2 bytes. This probably came from an if-then-else in C (it's a common idiom in translating C to assembly). -- [[User:Zaimoni|Zaimoni]], 12:36 Jun 17 2008 CDT<br /> <br /> :: I can see several instances of this in music.com for simple &quot;return value&quot; functions. Most likely a &quot;feature&quot; of the compiler. If used for padding, it is equivalent to 2 nop instructions, but takes only one cycle to execute. This was before deeply pipelined processors though ;-) [[User:Seb76|Seb76]] 12:10, 17 June 2008 (PDT)<br /> <br /> Yeah, I sidelined off IDA onto general assembly there :) Probably a good thing, means I'm getting used to it. Sort of.<br /> <br /> (Holy crap. I just discovered that hitting &quot;P&quot; (Create Function) in the right place is all it takes to enable graph display mode and give me a vast, improbably pretty flowchart of, well, a lot of stuff. I'd been wondering how to make that work.)<br /> <br /> Anyway! Seb, you're correct, I'm working on the music TSR. I've pretty much figured out how the entry code works, setting up an interrupt vector and terminating, which I think is decent progress for three days' experience with x86 assembler. I did find a web reference to &quot;jmp short $+2&quot; [http://www.programmersheaven.com/mb/x86_asm/484/484/ReadMessage.aspx here], which suggests that it's &quot;used to clear the cache, before going in or out of protected mode&quot;. Not entirely sure what clearing the cache does, but it's good to know.<br /> <br /> Thanks to the both of you for your help. Seb, do you mind if I continue to ask questions here? I don't know where else it should go. Maybe we need a &quot;ridiculous hacking ideas&quot; section of the wiki... ;) [[User:Phasma Felis|Phasma Felis]] 01:10, 18 June 2008 (PDT)<br /> <br /> :Hehe, sounds like fun. When I can find time to write a dll injector, I may add some stuff to it ;-) I'd start with increasing the max number of smoke entries. (Not possible right off the bat because it's using a static array instead of malloc-ed data :( ). Other ideas: fix the proxmine bugs, or maybe the disjoint base bug. I found the piece of code and it is not a simple &quot;off by one&quot; issue so it cannot just be patched in place... [[User:Seb76|Seb76]] 12:22, 18 June 2008 (PDT)<br /> <br /> ::Yeah, there's a lot of bugs and odd behaviors that could be fixed by just using larger arrays somehow. The 80-item limit causes all sorts of problems, the smoke limit, the 20-armed-proxmine limit...I wouldn't mind having more than 8 bases in the late game...stuff like that. [[User:Phasma Felis|Phasma Felis]] 12:42, 18 June 2008 (PDT)<br /> <br /> <br /> Hmm. The loader thing looks wonderful, but as I'm using a dos version in dosbox I'm guessing I'm out of luck for now? Or are you a dos wizard as well? :)<br /> [[User:Knan|Knan]] 12:35, 9 July 2008 (PDT)<br /> :Using a loader coupled with dll injection, there is no limit to the size of what you want to patch. You can also use higher level languages instead of plain assembler. However it is windows specific (won't work on anything pre-XP because of CreateRemoteThread usage BTW). For CD music in DOS, [[User:Phasma Felis|Phasma Felis]] may be your ticket. I'm willing to help but as I said before, my knowledge of DOS is quite rusty. [[User:Seb76|Seb76]] 12:49, 9 July 2008 (PDT)<br /> ::It's really the equipment screen hack that looks compelling. Figure it might be unreasonably hard to do that in dos. But I can't seem to get the windows version to run at a reasonable speed these days, always far too fast. That's why I'm using dosbox. Ah well, have fun modding :) [[User:Knan|Knan]] 14:14, 9 July 2008 (PDT)<br /> :Well, actually I have the speed issue too. It's just that setting the laptop to max battery and scroll speed to one is enough to work around the problem ^^. The geoscape has a sleep routine to prevent too fast updates. The mecanism is not present in the tactical part. [[User:Seb76|Seb76]] 14:45, 9 July 2008 (PDT)<br /> :Edit: might be your lucky day. I made a modification, it should slow down the scroll now. Can you check? [[User:Seb76|Seb76]] 15:42, 9 July 2008 (PDT)<br /> <br /> <br /> Seb76, since you appear to be on a roll with the findings lately, I thought I'd mention this as something to look out for if you haven't already found it. Can you track down the tables that determine a few other object properties that aren't stored in obdata.dat? I mean for properties like if it can cast light, what bullet image to use if the object is fired, whether its melee attack/mind probe/psi attacks are available for that item, etc. This would certainly allow for much more robust equipment modding. I'm guessing it'll be a part of the tactical.exe portion of the game. - [[User:NKF|NKF]] 19:56, 11 July 2008 (PDT)<br /> :Only flares can cast light currently. It is not a property in obdata, but a hardcoded &quot;objectType=0x1B&quot; check. I can hack in a piece of code to enable light for some other object types, but we'll need a way to say which ones do (can be done in the ini file but it would not be clean. Maybe we can find an unused bit in obdata.dat and arrange that...). [[User:Seb76|Seb76]] 14:12, 12 July 2008 (PDT)<br /> :Edit: the routine that populates the item menu has everything almost hardcoded too: stun, mind probe, psi-amp actions, scanner and medkit are all hardcoded by object type. The rest uses known flags from obdata. [[User:Seb76|Seb76]] 15:18, 12 July 2008 (PDT)<br /> <br /> == Error running UFOExtender ==<br /> <br /> Hi Seb76. I've tried running your UFOExtender as I want to slow down the scrolling in the tactical view. However I get the following error message:<br /> <br /> C:\Games\X-com\UFO Defense\UFOLoader.exe<br /> This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem.<br /> <br /> Any ideas what's going wrong? I'm on Win XP running Collector's Edition of UFO. --[[User:Col w|col_w]] 05:34, 12 July 2008 (PDT)<br /> :Hum, looks like the error you get when there is a missing DLL. I compiled using Visual Studio 9.0 Express Edition, maybe you don't have the runtime installed? You can get it [http://www.microsoft.com/downloads/details.aspx?FamilyID=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&amp;displaylang=en here]. Tools like [http://www.dependencywalker.com/ dependency walker] can help identify missing DLLs. Also what OS are you using (service pack number)? I don't have Vista here to test so it may only be running in XP SP2. Anybody can report it running on Vista? For sure it won't work on Win9x. [[User:Seb76|Seb76]] 09:02, 12 July 2008 (PDT)<br /> ::Yeah, visual xyz runtime dlls need to be included with things you compile with visual xyz. A common complaint when running small hacks under Wine on Linux as well, since you usually install just a very few programs on each virtual windows install, so it's unlikely some other program installs the dlls for you. [[User:Knan|Knan]] 17:08, 12 July 2008 (PDT)<br /> :Especially since they made up that manifest stuff. Supposed to solved DLL hell... Well, so far it caused me more trouble than it solved issues. The funny part is when you install a new VS service pack on your build servers and have half the development team freak out because their target system won't boot the latest piece of code... [[User:Seb76|Seb76]] 18:04, 12 July 2008 (PDT)<br /> Awesome, that fixed it! Now I can enjoy this classic game once again. Love the language screen joke too :) Many thanks --[[User:Col w|col_w]] 11:08, 12 July 2008 (PDT)<br /> :My pleasure man. Glad you enjoyed it ;-) [[User:Seb76|Seb76]] 12:07, 12 July 2008 (PDT)<br /> <br /> == UFOloader and Xcomutil ==<br /> <br /> Hey Seb76 awesome work with this patch! Just wondering though if it would be possible to run this together with XcomUtil somehow. Thanks!<br /> Oh and btw when's the TFTD version coming out? ;-)<br /> [[User:J'ordos|J&amp;#39;ordos]] 14:09, 24 July 2008 (PDT)</div>

J'ordos https://temp.ufopaedia.org/index.php?title=User:J%27ordos&diff=14385 2008-01-29T18:51:54Z

<p>J&#039;ordos: just doodling</p> <hr /> <div>== X-Com Apocalypse Known Data ==<br /> === UFO2P.EXE ===<br /> 1300148 - 1300691 ;facility data<br /> <br /> 1302012 - 1303900 ;UFO mission data<br /> 1303902 ;bogus entry?<br /> 1303904 - 1304460 ;UFO crew data<br /> 1304464 - 1305020 ;UFO drop troops data<br /> <br /> 1305450 - 1305478 ;craft ammo manufacturers data<br /> <br /> 1306240 - 1309010 ;research data<br /> 1309012 - 1310002 ;not used?<br /> 1310004 - 1312152 ;manufacturing data<br /> <br /> 1315952 - 1315956 ;funding data<br /> <br /> 1319592 - 1319678 ;aequip alien artifact data<br /> 1319679 - 1320330 ;unknown<br /> 1320332 - 1321355 ;base layout data<br /> <br /> 1349026 - 1349486 ;vehicle names<br /> 1349488 - 1351087 ;aequip names<br /> 1351089 - 1351120 ;unit measurements<br /> 1351122 - 1353322 ;building names<br /> 1353324 - 1353639 ;facility names<br /> 1353641 - 1354564 ;cequip names<br /> 1354566 - 1355304 ;building functions<br /> <br /> 1355537 - 1355822 ;org names <br /> <br /> 1356174 - 1356442 ;craft ammo names<br /> <br /> 1369018 - 1370656 ;research topics<br /> 1370658 - 1376753 ;research short descriptions<br /> 1376755 - 1377625 ;manufacturing items<br /> 1377627 - 1377939 ;senate relationships<br /> 1377941 - 1378103 ;alien unit names<br /> 1378105 - 1378168 ;agent ranks<br /> <br /> 1387229 - 1387318 ;ufopaedia categories<br /> <br /> 1391631 - 1392287 ;unit names<br /> <br /> 1393142 - 1393176 ;difficulty levels<br /> <br /> 1394838 - 1395054 ;damage types<br /> <br /> 1396772 - 1397090 ;UFO growth rates<br /> <br /> 1398132 - 1403096 ;unit stats data<br /> <br /> 1612940 - 1617223 ;vehicle data<br /> 1617224 - 1618398 ;cequip1 data<br /> 1618400 - 1619248 ;cequip3 data (weapons)<br /> 1619250 ;bogus entry?<br /> 1619252 - 1619316 ;cequip3 data (engines)<br /> 1619318 - 1619550 ;cequip3 data (cargo)<br /> <br /> 1620416 - 1629103 ;vehicle slot data<br /> 1629104 - 1634142 ;market data<br /> <br /> 1644906 - 1645187 ;starting UFOPaedia entries<br /> <br /> 1645484 - 1646020 ;alien building defenses data<br /> <br /> 1681936 - 1682762 ;damage mod data<br /> 1682764 - 1684434 ;aequip3 data<br /> 1684436 - 1684584 ;aequip2 data (protection)<br /> 1684586 - 1685160 ;aequip2 data (weapons)<br /> 1685162 - 1686726 ;aequip1 data<br /> 1686728 - 1687219 ;aequip2 data (other)<br /> 1687220 - 1687356 ;aequip sets score req data<br /> 1687360 - 1689998 ;aequip sets data</div>

J'ordos https://temp.ufopaedia.org/index.php?title=Talk:Vehicle_Engines_(Apocalypse)&diff=14371 2008-01-23T02:33:23Z

<p>J&#039;ordos: </p> <hr /> <div>'''Brain Dump'''<br /> <br /> EDIT: this page becomes a mess when not formatted properly<br /> <br /> Engine Stats:<br /> Standard (E1)- $1000, X2Y2, Spd:10, Wt:75 <br /> Deluxe (E2)- $1500, X2Y2, Spd:11, Wt:100<br /> Sports (E3)- $2000, X2Y2, Spd:12, Wt:140<br /> Turbo (E4)- $3500, X2Y4, Spd:13, Wt:190<br /> Elite (E5)- $5000, X4Y4, Spd:14, Wt:240<br /> Special (E6)- $7000, X4Y4, Spd:15, Wt:180<br /> <br /> <br /> Hoverbike: Wt=100kg<br /> Empty(Load) + E1 = Spd:14(14),Accel:5(4)<br /> Empty(Load) + E2 = Spd:15(15),Accel:10(7)<br /> Empty(Load) + E3 = Spd:16(16),Accel:10(10)<br /> <br /> Hovercar: Wt=700kg<br /> Empty(Load) + E3 = Spd:12(12),Accel:4(3)<br /> Empty(Load) + E4 = Spd:13(13),Accel:8(7)<br /> <br /> **more than 110kg from clean, acceleration will drop by 1 point (using SD Turbo)<br /> <br /> Valkyrie: Wt=3000kg<br /> Empty(Load) + E4 = Spd:13(13),Accel:2(2)<br /> Empty(Load) + E5 = Spd:14(14),Accel:4(4)<br /> Empty(Load) + E6 = Spd:15(15),Accel:10(9)<br /> **more than 20kg from clean, acceleration will drop by 1 point (using SD Special)<br /> **accel will decrease again if vehicle weighs over 3550kg (using SD Special)<br /> <br /> Hawk: Wt=5000kg<br /> Empty(Load) + E5 = Spd:14(14),Accel:3(2)<br /> Empty(Load) + E6 = Spd:15(15),Accel:6(5)<br /> *more than 150kg from clean, acceleration will drop by 1 point (using SD Special).<br /> <br /> <br /> Trends:<br /> *TOP SPEED does not drop!<br /> *having the best engine with the best weapon loadout almost always will drop the acceleration down by one point.<br /> *using multiple small shields on large terran craft can sometimes drop acceleration values again by 1 point.<br /> <br /> Weights:<br /> *Bolter Laser - 50<br /> *Lancer Laser - 80<br /> *Rendor Plasma - 70<br /> *Lineage Plasma - 95<br /> *Janitor Missile - 70<br /> *Prophet Missile - 70<br /> *Disruptor Missile - 120<br /> *Cargo/Pass. Module - 50<br /> *Small Shield - 80<br /> *Fusion Powerfuel - ?? (irrelevant?)<br /> <br /> <br /> : Are these the speeds for ships while under computer control? Or just the numbers listed in the information screens? As far as I can remember, when vehicles are under manual control, you can reach top speeds regardless of the total weight of the aircraft. Also, just to help the formatting a little, I changed the list to unformatted plain text. - [[User:NKF|NKF]]<br /> : yeah, it has to be because you cannot control more than one at a time. yes, numbers are from the info screen. i did a test of speeds using Apoc'D editor. WHoa! I love the 45 speed for the hoverbike. Anyways, I do think the we all got shafted with the craft not reaching absultue capaable speeds, but oh well!<br /> GOOD JOIB on the formatting. My brain diarehha and spelling can be shocking when I can't write fast enuf to keep up with my head. LOL! No, I m not crazy (I hope).<br /> <br /> A small fact about top speeds I noticed: each vehicle that has a total weight (=including equipment) of less than 350 receives a +4 bonus to it's top speed.</div>

J'ordos