Topics

1

Programming / [Critical bug] The game crashes at the end of Mars Phase 1 (2014_11_16_1124)

« on: November 17, 2014, 12:44:27 pm »

The game (the latest nightly build) quits immediately (without any message) after killing the last Sectoid in the phase 1 of the final assault. See the attachment for a save. However, it works OK in the version 1.0

Btw., is it a right effect that the final sequence (of pictures) starts immediately after destroying the first part of the Brain? As I can remember, you should shoot and destroy all 4 parts of the brain. A save for tests is in the attachment as well.

And the second "by-the-way". Is it right that unloading weapon is mute, with no accompanying sound? It is a little unnatural effect when you unload your weapon with no sound and next load a clip with a click. I would suggest to add a sound to weapon unloading as well.

2

Programming / [Bug] Crash when a soldier throws a thing

« on: October 05, 2014, 03:12:24 am »

openxcom_git_master_2014_10_04_1449 crashes when a soldier throws an object in tactics. This does not occur in openxcom_git_master_2014_10_02_0537

3

Programming / [(Non critical) bug] Soldiers can walk through walls!

« on: October 02, 2014, 02:08:03 am »

Inspired by the latest nightly (openxcom_git_master_2014_09_30_0211.zip) with a patch to the Firestorm route file, I have looked through all three 2nd-generation Xcom ships.

[For confused ones: Firestorm is available in the game when you swich an option to use it for transporting soldiers too. This idea comes from the old good times of XcomUtil.]


1. There is no reason for the terrain files of Firestorm to differ from the terrain for Lightning. Both vessels use exactly the same tiles. However, there is a new, corrected version of LIGHNIN MCD/PCK/TAB files in the Universal Patch. But the same errors have not been corrected in FIRES MCD/PCK/TAB! The game adds these files during installation - but these should be just copies of LIGHTNIN files from the patch. Please correct it!

Btw., there is a simpler solution. I suggest to change Firestorm tilesets from FIRES into LIGHTNIN in the Ruleset. As far as I know, nobody has ever changed FIRES to make it different from LIGHTNIN, and there is not a single mod which uses FIRES, so this is completely safe.


2. Both LIGHTNIN and AVENGER terrain files contain errors, not patched yet. Southern and eastern walls of all three ships look and feel like sothern and eastern walls of UFOs, so they should be assigned as northern and western wall tiles in the data files, respectively. Some other tricks, like adding a patch for BigWall attribute in the Ruleset is used instead. It is not a real solution. Other errors have been corrected in the Universal Patch - why not to correct this as well?

If a tile is marked as object, the BigWall attribute is very important - if set (to 1, even if there are also other possibilities), the tile is impassable and does not generate mistakes in path finding.

But if the same tile is marked as northern wall or western wall, the BigWall becomes of no importance and is set to 0 (in all genuine tiles marked as walls). Soldiers (and aliens) should not pass through walls in any case.

I have made all needed corrections (I mean errors I have found... perhaps there are other errors too), and the result is in the attachment. Check it, test it, and if you feel they are OK, add them to the Universal Patch. To emphasize: they are not mods, they are patches.

There was an unused frame for the human ship Power Source (in LIGHTNIN terrain files); I have also added it to the animation (and it is no longer unused in the file). Now the power source pulses slower and switches off for a second. Just install the corrected version and observe it yourself. I feel using/activation an unused PCK is a patch, not a mod as well.

To forewarn: these changes have nothing to do with the problem described below. I have tested the game's behaviour with old and new tilesets, and it is exactly the same.

I have used the AVENGER tileset version with a patched door. It is not applied in the normal game (so both patched (in this point) and unpatched versions of the tileset will work exactly the same) but modders have created a special Avenger type with door. The mod uses the corrected door, and my version of the tileset will work with the updated Avenger without problems.


3. Then was the turn for checking maps. Avenger appeared not to have one needed "wedge" (a bit of wall to plug the hole in the corner) in its north-western corner. Btw., in human ship maps, such wedges should always be added externally: at the convex side of the angle and also by skew walls. In UFOs, pillars should be inserted to corners and to the places where two skew wall tiles touch one another (or there will be holes in walls).


4. The existing trial to eliminate gaps in walls of Firestorm and Lightning is to add wedges that block lines of view (and firing) but are invisible. They form last 4 tiles (43-46) in the LIGHTNIN tileset. Such a solution looks very temporary...

I have reverted the wedges into a visible form like in the AVENGER tileset (however, one of them is NOT the same like in AVENGER, it fits to the Lightning graphics instead) - btw., thanks to Volutar's MCD Edit! A great program indeed! (Even if the built-in PCK Editor not very comfortable - but still great).

It appeared that the Lightning and Firestorm maps look ugly with the corrected graphic. It is quite probable that the previous patchers did not know were to put the gap-filling edges, and they used them on the inner side of walls. I have corrected it as well, removed unnecessary wedges from the inner sides, and add necessary wedges in the outer sides.

Now at last the door of Firestorm looks normal (it is so because the edges are no longer invisible). You can have a look at the attached screenshots (or add my patches into the game, and test them in-game).


5. The Firestorm map that the game installs looks strange as it has two Power Sources stacked on two navigations (all other existing squares inside the ship are to be used for soldiers, so no moving of navigations / Power sources is possible). It looks very ugly! I have removed one navigation and one power source. Now the vessel is no more ideally symmetrical but looks normal, without engines growing from control tables. See the attached screenshots. I hope my idea will appear fine, and the corrected map will replace the existing one in the game (unless somebody finds a yet smarter solution). Once again, it is not a mod. It is a patch.


6. Soldiers in Firestorm look north even if the door is on the eastern side. It is a game error and it needs a correction in the Ruleset. Look at screen000 in the attached archive with screenshots.


7. And, finally, the most interesting! I have found a bug in the game. Namely, the wall tiles on the maps are all placed as objects and not walls. It contrasts with UFO walls: the ones which form southern and eastern external UFO walls, are placed on the map as northern and western walls (on adjacent squares), and it all works.

But if we correct the placement of walls in maps to make them be placed in the same way as on UFO maps, it will not work!

SOLDIERS WILL WALK THROUGH WALLS. See the attached screenshots with arrows showing planned movement of a soldier. The soldiers will actually cross the walls if we made them move. It looks very strange.

They do not cross edges or tile borders. They cross wall tiles. It should never happened...

Nothing helps: marking the tiles as objects again in the MCD, setting the BigWall attribute, etc. The game stops allowing crossing the walls only when the walls are placed as objects again on the map. Their assignation in MCD has nothing to do.

It is sounds strange - soldiers can walk through walls and cannot walk through some objects...


I do not understand how this bug could emerge. But UFO maps are constructed in EXACTLY the same way as the human ships maps corrected by me. There are tiles assigned to be northern and western walls, they form UFO southern and eastern walls, they have (nearly) the same attributes as Firestorm / Lightning / Avenger tiles - but soldiers cannot enter the UFO through them. So, why they can go through walls of corrected human ships which are marked EXACTLY the same?

Is it true that the game, instead of reading properties of tiles, has them hard coded inside? It seems to me to be the only explanation...

If yes, the situation is very uncomfortable for modders. Even now there are mods which use LIGHTNIN or AVENGER tilesets, and not the walls are not always used as objects (which is generally incorrect even if exists on unpatched maps because of an error) - sometimes they are correctly placed on maps as walls (of course, I mean only walls on southern and eastern borders of ships, so northern and western walls - all the others should be objects indeed).


I strongly suggest that the game should check tile attributes, and should not let soldiers pass through any walls, instead of using some inner database. It would drastically help modders.


One of OXC features is that a unit can stand on a square where a wall or an object is placed. The original game does not allow walking just by northern and western sides of UFOs - OXC does allow it. Perhaps it is a patch, perhaps it is a mod... it does not matter. I like this feature.

However, the possibility to stand just by the wall / object should not allow the unit to cross it. For example, if a unit stands on a square, and there is a tile placed as northern wall on the square adjacent south of the unit, the possibility to go south should be always blocked. It should not depend on what kind of map it is.

It does not so for now. This is why soldiers can go through Firestorm / Lightning / Avenger walls (if the maps are corrected, and the walls are placed as such, and not as objects).

See the attached screenshots. I have also added fpslooks - their numbers correspond to screenshots numbers. Perhaps it'll help with further analysing the problem.


8. Avenger / Lightning / Firestorm walls are not the only passable walls. It appears that wall navigations (the pink objects in UFOs) not always block passing through. They are assigned to be walls (northern or western ones). If they are placed as walls (on a used-made maps), they sometimes do not block passing.

The problem is of the same kind as the problem with Avenger / Lightning / Firestorm walls.

Once again, the game should not rely on its own inner database, and should not allow passing through some walls but block passing through other walls with the same attributes. If it was so, it could stop modding... A new tile made by a modder could always be passable even if marked as wall! It would not be fair, the most simply speaking.

Hence an appeal to the coders: correct the procedure checking the possibility of passing to the adjacent square. And make it always impossible if there is a wall blocking the passage. Any wall. Any tile marked as a wall and put on a map as wall.

4

Work In Progress / [MAPS] YetMoreUFOs!

« on: September 24, 2014, 02:13:54 pm »

I would like to announce a new mod... even if partially with already known contents.

As long ago as in 1997, some people created new UFO maps as replacements or variants (chosen by the game randomly) of the well-known types which we all know well from our beloved game. Which is more, the original game creators must also have planned different UFOs set(s), and left their unfinished work in game files (see https://openxcom.org/forum/index.php?topic=2911.0). My ultimate aim is to revive results of all that job - make it available for OXC (and for the original game, if somebody would like it too), and thus show respect to them and to their work.

I have also found a number of less or more important flaws in more modern maps, made by Luke83 and published in his ExtraUFOs pack. For example: if you install that mod, you cannot have the original Harvester any longer in your campaign (or it would look very strange). It needn't be so, this is a problem that one can solve (even if with some own efforts, sometimes enough painful).

Having considered all of these, I have decided to make my own mod with a large collection of UFO maps. The most basic premise of mine is NOT TO RESIGN of the original maps (so, Harvester variants will still be usable along with the original, unmodified map). I am planning to include as much of maps known to me as possible, to make the campaign more attractive. The sources of the maps will then be:
- original UFOs that are present in data files but not occurring in the game,
- UFOs from MapPack1 by Robert Di Fiore, of 1997 (https://www.strategycore.co.uk/files/ufo-map-pack-1/),
- UFOs from MapPack2 by Luchian Deurell and Sam Jeffreys, of 2001 (https://www.strategycore.co.uk/files/ufo-map-pack-2/),
- (another) Bird of Prey (provided) by PolynomialRing (https://www.openxcom.com/mod/birdofprey),
- Small Scout by Zombie, of 2008 (https://www.strategycore.co.uk/files/small-scout-mod/),
- Extra UFOs by Luke83 (https://www.openxcom.com/mod/lukes-extra-ufos),
- New UFOs by SolariusScorch (https://www.openxcom.com/mod/solar-039-s-new-ufos).

Now the time for my own contribution. The mod will not be only a compilation of existing maps, created by other people. Less or more important changes are needed in maps and especially in route files. Luke's tilesets (UFOL83 and U_DISEC3) used with his maps will also need some changes (esp. U_DISEC3, to make the original Harvester and his Harvesters usable side by side). Reviving the forgotten UFOs from the game files would need creating special tilesets (even if Luke83 has already made some good job in this point).

Moreover, I am planning to add reflected, turned, etc. extra variants as my contribution, and perhaps several personal creations made from scratch.

All details will be described in the included readme file.

As for now, maps of two UFO types (Small Scout and Medium Scout) are ready to tests: https://www.openxcom.com/mod/yet-more-ufos. Large Scouts are just in preparation and will be available in a few days with a new version of the mod (20-30 variants may be expected).

All so far published maps are UFO variants, not new UFO types, i.e. you will still have the basic 8 types, and no new Ufopedia entries, no new topics for scientists, etc. So, the only change in the game is that you have more various alien vessels in your combat missions. Thanks to this, the game is less schematic. You will never know where is the entrance to the UFO, and what is its floor plan. You must be more flexible in your tactics then.

I am planning to leave this option for as much new maps as possible. As for now, it will be impossible for all maps, though.

MapPack1 is fully applicable here (even if UFOs from the pack do not look like their well-known basic variants). The only problem are false walls, holed floors, etc. - I do not like them, and I will remove them all (in my humble opinion, the game reality is not Hogwart, and the aliens should not be warlocks who walk through solid walls - if you disagree, try the original maps from that mappack). Problems start with MapPack2 whose authors changed tilesets for their UFOs. One of possiblilities is to take:
• their Battle Cruiser and Evader as Abductor variants (and not Harvesters like they planned),
• their Freighter as a Terror Ship variant (and not an Abductor variant),
• their Marauder as a Harvester variant (and not a Terror Ship variant),
• their Warbird as a Supply Ship variant (and not a Battleship variant),
• their Attack Cruiser as an Abductor variant (and not a Supply Ship variant),
and I am doing so.

It is so because the current rules used in rulesets do not allow UFOs with the same name and different tilesets. So, there is an appeal to the game creators then: please change it if possible! Especially that no tricks will help (for now) to survive the forgotten pyramidal UFOs from the game files to be just randomly selected variants of the plain UFOs known to all.

I mean that the game allows this:

Code: [Select]

  - type: STR_LARGE_SCOUT
    size: STR_SMALL
(...)
    battlescapeTerrainData:
      name: UFO_120
      mapDataSets:
        - BLANKS
        - U_EXT02
        - U_WALL02
        - U_BITS
        - UFOL83
      mapBlocks:
        - name: UFO_120
          width: 20
          length: 20
       - name: UFO_121
(...)

and it would be nice if it allowed this (or something similar):

Code: [Select]

  - type: STR_LARGE_SCOUT
    size: STR_SMALL
(...)
    battlescapeTerrainData:
      name: UFO_120
       - mapDataSets:
          - BLANKS
          - U_EXT02
          - U_WALL02
          - U_BITS
          - UFOL83
        mapBlocks:
          - name: UFO_120
            width: 20
            length: 20
          - name: UFO_121
(...)
       - mapDataSets:
          - BLANKS
          - U_EXT02
          - U_WALL02
          - U_BITS
          - UFOL83
          - U_DISEC3
        mapBlocks:
          - name: UFO_122
(...)
(as for now, it does not work).

So, I am also planning another option (and a special, second ruleset for this mod) in the future: adding more UFO types (so you will have more than 8 UFO types in the game, and each of these still in many variants). It would need changes in Alien missions, the research tree, additional interception graphic, so this is a more distant future...

Finally, inform me please if you know other UFO maps aleady made, and want to have them in this mod as well.

5

Open Feedback / Alien Missions vs. Alien Attacks

« on: September 14, 2014, 04:14:07 pm »

Perhaps I have found a solution to a problem once been discussed on Ufopaedia. The problem is of a big importance for the game.

UFO / TFTD game researchers found alien appearence ratios in the game exe file. It appeared that also the Alien Retaliation mission has such ratios set. On the other side, it was said that alien attacks on XCom bases are always responses to XCom activity, occurring with some chance, and it is always the XCom-suffering alien race which responds - so the appearence ratios in the game seemed to be of no use. They were said to be superfluous (https://www.ufopaedia.org/index.php?title=Alien_Appearance_Ratios: "All Retaliation rows are unused. Retaliation missions are generated in response to shooting down enemy craft, with a set probability that is scaled by the difficulty level multiplier.").

It was also observed that (during TFTD playing) Tasoths were able to attack a ship route as early as in April 2040 even if the first appearance of that race should be in June 2040 (see Ufopaedia: https://www.ufopaedia.org/index.php?title=Alien_Appearance_Ratios_(TFTD)). Contrary to the popular opinion, no flying/floating USO recording used to be done just before the attack. It seemed that the aliens emerged from the deep, not from a USO.

Similarly, it was observed in UFO:EU that some terror attacks may happen very early in the campaign, even in the first week, and no preceding Terror Ship flights were observed even if they should be (e.g. when the terrorized city was not too far from the XCom base).

I think I have solved all the above problems. Namely, according to my observations, there are TWO DIFFERENT general Alien activity types. The first type are the well-known alien missions, each containing several phases of scheduled UFO/USO appearances, and chosen by the game engine in accordance with the alien appearance ratios. The other type are aliens single attacks that are not scheduled, not in accordance with the ratios, and not consisting of any phases (hence "single").

So, it seems that the aliens take a part in both (a) missions and (b) single attacks which are not part of any mission (and thus are not scheduled). Single attacks mean, among others, city terror attacks (in TFTD: shipping route, port and island terror attacks), not recorded before, not preceded by an appearance of any UFO/USO (the aliens attack immediately) and not in agreement with the appearance tables. Hence Ethereals (UFO:EU) or Tasoths (TFTD) may appear as early as in April, hence aliens may terrorize land as early as in the first days of the campaign, without smaller UFOs preceding the attack.

Single terror attacks are frequent in first months, then (exactly when?) they seem to cease. Aliens can still terrorize cities (UFO) or ships, ports and islands (TFTD) but only (mainly?) during their Alien Terror / Alien Surface Attacks missions rather than single attacks. Of course - if such a type of mission has been chosen for a current month. It is also quite probable that shooting down UFOs/USOs during first phases of the mission can stop it, and finally no terror will occur. Or (which one is true?): it will prevent aliens from knowing the localization of the city (port, island, ship route). As the result, the final UFO/USO (Terror Ship in UFO:EU and Battleship in TFTD) will appear but not find its target.

As it seems to me, a similar dual mechanism lies behind alien attacks on XCom bases. Some of the attacks are a result of an alien response to shooting down a UFO / downing a USO (with a chance of occurrence which depends on the game difficulty level). Contrary to single terror attacks, a Battleship (UFO) / Dreadnought (TFTD) always appears then before the attack. The aliens know exactly where the XCom base is located, so nothing can help XCom to avoid the battle, and the UFO/USO moves straight to the base. Appearance ratios are of no use then - it is the same race which responds, as the race whose UFO/USO has been downed by XCom.

These single attacks in response to UFO/USO downing seem to have nothing to do with Alien Retaliation / Floating Base Attack missions. Like other of the 7 mission types altogether, Alien Retaliations / Floating Base Attacks are scheduled and consist of several phases. Such a mission must be chosen for the current month (together with another mission - two missions start a month). It is quite probable (but not confirmed!) that the mission region (chosen at the beginning of a new month) must contain an existing XCom base. Smaller UFOs/USOs happening on the first phases of the mission are scouts which help aliens to locate the base (otherwise unknown, unlike during a single attack). Shooting them down can also stop the occurring of the further phases of the mission, and as a result, no Battleships / Dreadnoughts will appear finally. Alien Appearence Ratios are applied, contrary to what is said in Ufopaedia (so the data are not superfluous). It is also only a chance that the aliens will find the XCom base location (unlike single attacks when the Aliens always know where the base is located, without a preceding reconnaissance).

In UFO and TFTD the aliens start two missions each month. It is known nothing about single attacks: what is the exact number of them, or even if they depends on time at all (perhaps there are moths with no single attacks, and months with several single attacks). However, observations suggest that they stop at a certain moment of the campaign (or become very rare). Anyway, multi-phase missions dominate over single attacks (if any still possible) in later months of the game.

I would like to know if my observations (as it's been seen, partially not in accordance with Ufopaedia) are correct, and if not, how to explain the observed game behaviour.

My second question is how it all works in OXC. Are multi-phase missions and single attacks distinguished? Are the aliens able to terrorize a city as early as, say, on 1st January 1999? Does the number of single attacks (those terror ones and on XCom bases) depend on the current month, and how (e.g. two attack a month, together with two missions starting)? Is there a possibility e.g. for Ethereals to appear as early as in the first month of the campaign (during a single, non-scheduled, city terror attack)? And if appearance ratios / rules exist in the game, what are they like? The above mentioned April Tasoths (and also probably April Ethereals) suggest that they should not be the same appearance ratios as in alien missions.

In the original game, two new Alien missions start each month. Is it hardcoded in OXC, or can be modded? And: is it possible to change the rule of starting alien missions (in a game mod, to make the campaign different that in the original game) that they would start in a day chosen by chance and not the first day of each month?

6

Programming / [Deadly bug] The game cracks during tactical fight

« on: September 09, 2014, 11:21:31 pm »

Load the game from the attachment, and give move to the aliens. The game will crack.

In  openxcom_git_master_2014_09_09_0725, the message says:

vector::_M_range_check

In the version 1.0 the message is:

invalid vector<T> subscript

7

Work In Progress / How does OpenXcom know where to place Elerium-115 on the battlefield?

« on: September 07, 2014, 01:15:05 am »

Long ago someone did new UFO variants for the vanilla game + XComUtil. I would like to bring them back to OpenXcom as well. There are two problems about it, however.

1. Various extra UFO maps can use different tilesets, see my other post.
2. UFO Power Source in those new UFOs is, as a rule, in a different place than it is in the basic, well-known UFO variants.

Elerium-115 is an object which should be generated on the battlefield somehow... It's location is not written in any map file, either the terrain or the alien ship, so the game must place it correctly with the help of a built-in procedure. All is right as long as we deal with either original UFOs or their slight modifications (e.g. with moved inner walls). And what if the new UFO has its power source in a different place than the basic variant? Will the game recognize it and place Elerium in the right place?

UFO:EU + XComUtils does not do it correctly, and as a result, Elerium lies on the ground in a different place than the power source is. Or, exactly speaking, it is generated in the place where the power source should be (if the UFO map was default).

I am asking about it because there is an Alien Base map with two power sources, and it is necessary to point the right place for Elerium openly, in the Ruleset. So, what is the algorithm in case of other terrains, those with an alien ship generated on the battlefield?

And another, related question. Let's say I want to make a new UFO variant with 8 power sources but with only 4 Eleriums generated on the battlefield. Is it possible?

The question seems to be important for the future of OpenXcom because in TFTD the number of Zrbite does not always correspond to the number of Ion-Beam Accelerators in the alien ship...

8

Work In Progress / Unused UFO maps in the vanilla game

« on: September 07, 2014, 12:54:22 am »

The original game contains some unused files, including several unused UFO maps: UFO1B, PSCOUT, UFO000, UFO010, PHARVEST, PABDUCT. I would like to restore them back to life as new variants of the existing UFOs. However, there is a problem with it.

Mods like Luke's Extra UFOs, are based on a premise that all variants of a given UFO type (e.g. UFO_110, ox_ufo1, ox_ufo1b, etc. - variants of Medium Scout) use the same tilesets (mapDataSets) in the same order (in the given example:  BLANKS, U_EXT02, U_WALL02, U_BITS, UFOL83). But in order to use the extra UFO maps that are present (and unused) in the game, we do need another tilesets than the basic, well-know, vanilla variants of UFOs.

For example, to bring UFO1B to life as another variant of Small Scout it is enough to make a new MCD/PCK/TAB set (let's say, UFO0) of the existing UFO1 set, by removing the first tile (which is duplicated besides).

But the existing syntax seems to exclude such an option, cf.:

  - type: STR_SMALL_SCOUT
    size: STR_VERY_SMALL
    sprite: 0
    damageMax: 50
    speedMax: 2200
    accel: 12
    power: 0
    range: 0
    score: 50
    reload: 56
    breakOffTime: 200
    battlescapeTerrainData:
      name: UFO1A
      mapDataSets:
        - BLANKS
        - UFO1
      mapBlocks:
        - name: UFO1A
          width: 10
          length: 10
        - name: UFO1B
          width: 2
          length: 2


It will not work: the variable mapDataSets is defined BEFORE the list of variants (here: UFO1A and UFO1B) and not within each single UFO type description, so it is common for both variants.

The first question is: is it possible to define a specific mapDataSets variable for each single UFO variant within the same UFO type -  for instance different tilesets for UFO1A and UFO1B, both being variants of Small Scout?

The second question is: will the game function well with such a strange map, of width = 2 and length = 2?

I know that there is another, very simple solution: to add one to each single non-zero byte inside UFO1B.MAP, and then it will work with UFO1 tileset. And, in case of problems, to enlarge the map to the size of 10 x 10. But I am asking for curiosity...


In order to revive other unused UFO variants, present in the game but unused, we need special tileset(s). So, to have both the well-known vanilla, basic UFO variants along with the revived ones (if the tilesets making will succeed...), we will need different tilesets for various UFO variants within one UFO type, and we will not avoid this (unlike in the case of UFO1B).

And the third question is: has anybody tried to bring PSCOUT, UFO000, UFO010, PHARVEST and PABDUCT back to life yet? Or I am the first one who has ever thought about it?

9

Programming / Something wrong with messages during tactical battle

« on: September 05, 2014, 01:50:36 am »

Sometimes when your unit has 0 TUs left, and you try to move it, you receive a message that there is no time left for aimed shot - even if aimed shot has not been reserved...

Load the attached savegame, take a look at the sectoid under Xcom control, try to turn it with right click, and see the message...

I have already added this issue to the bugtracker.

10

Open Feedback / Savegame converter?

« on: September 04, 2014, 02:34:48 pm »

Will it be possible to try to add a savegame converter UFO: EU <---> OpenXCom? I realize that because of many (stupid...) limitations of the original game, and many unique (and nice!) features of OXC it is not possible to make an accurate "translation" between savegames. But perhaps it would be possible to get something as similar as possible.

I feel it would help with testing some (yet) not implemented features of the original game like the correct length of alien ship landing on the ground, or of the range of randomless of alien behaviour during tactical and air combat (see my other posts).

It would also be nice to compare if you can catch a Supply Ship with an Interceptor or not - in exactly the same situation, in UFO: EU and in OXC.

As meaning of (lots of / most / nearly all?) bytes in the original savegame is known today, such a converter should not be a serious challenge for a smart programmer... I hope... I wish I was much skillful and wrote such a program but myself... but with my present very limited (rookie  ) skills it would really take too much time for me

11

Open Feedback / OXC is too much repeatable

« on: September 04, 2014, 02:21:51 pm »

The original game behaves VERY differently each time when loaded from a savegame. It concerns both tactical and strategic savegames. Just load a savegame several times into UFO: EU, and you will see what I mean. Unlike the original game, OXC seems to be repeatable, schematic.

When you save the game during chasing a UFO, and then load it several times, it will appear that the alien ship may land down in 30 seconds, 3 hours or at all. You may try the UFO: EU savegame attached to my other post, or start a new (vanilla) game, wait till the first UFO appears, then save the game immediately, and next load it several times, again and again. You will see that the scenario will be different each time.

The same about tactical game. Sometimes you finishes your move, and during the alien move one of your soldiers is being killed. In OXC he is always killed (or at least the situation can change only rarely). When you are using an autoshot, each of three shots goes to the same place! In UFO: EU each time you load the same savegame, the situation develops differently, and results of an autoshot are never the same.

Please give much more randomless to the game to make it really similar to the original one. No predictable trajectories of alien ships on the globe screen, no fully predictable alien behaviour during mission, please.

12

Open Feedback / How long should Supply Ship stay at the alien base?

« on: September 03, 2014, 06:11:46 pm »

As I have noticed, Supply Ship flees very quickly in OX, much quicker than in the original game (UFO:EU). As a result, "alien base milking" is very hard.

It is so because the initial value of ufos: secondsRemaining: is set to 2000 seconds. Perhaps two thousand seems to be an impressive number - but one hour = 3600 seconds! In other words, UFO waits for only a little more than half an hour... With Skyranger, it is impossible to be there on time. Unlike in the original game...

Is it on purpose, or is it a bug of OXC?

13

Translations / The new system can be destructive for the translation!

« on: September 01, 2014, 03:59:44 pm »

The new system causes that each particular string can be changed with voting. This is the worst solution of all possible. It is so because a given term can occur in a number of strings at the same time. Voting can cause a change in one string while another version stays in all other strings.

To clear the thing, I will give an example from the Polish translation:

For STR_MUTON_CORPSE, "Zwłoki mutona" has won the voting. But:

STR_SECTOID_CORPSE is "Ciało Sektoida",
STR_SNAKEMAN_CORPSE is "Ciało Wężownika",
STR_ETHEREAL_CORPSE is "Ciało Etereala", etc.

Note CORPSE as "zwłoki" in the first example while CORPSE as "ciało" in the others. Note also the spelling "mutona" (lower case) and "Sektoida" etc. (upper case).

It can be even worse! COMMANDER means "komandor" in Polish but some people may translate it as "przywódca". But the normal translation of "przywódca" is "leader"! So, the present system of democracy towards each single string which is trating apart, can cause a total mess: in some strings "przywódca" may be COMMANDER while in others "przywódca" may be LEADER.

So, this democratic system of clicks may be destructive! And the final translation may lead to serious missunderstandings.

Please consider my argumentation, and add a rule that a given term MUST be translated in the same way in all strings where it is present. This cannot be done automatically, however.

For example, COMMANDER should be either "komandor" or "przywódca" everywhere, in all strings in which it occurs. But NAME should be sometimes translated as "imię" and sometimes as "nazwa" because of features of the language.

In other words, only clicks on such or another version of a given string is the worst solution. There should be some coordination between all changes.

As for now, the Polish translation has been destructed by people who wanted to force their own translations only in some strings. I really expect that someone WILL revert the translation to the prevoious state, before the introduction of the new system, or the game will be less and less comprehensible. If this mess will continue, the only solution will be to play in English.

As for now, to play OpenXCom in Polish, in a comfortable way, you must first edit the localization file for yourself, and remove all the mess caused by the new system of clicks. Previously there was not such a need.

I do not think it is one the creators of the new system expected. Perhaps it is time for go back to the previous system, or to serious changes in the click system.

14

Programming / [Missing feature?] Alien Habitat is not recognized by OpenXCom

« on: August 30, 2014, 02:43:11 pm »

Due to bugs in original game files, Alien Habitat is absent in the game. The tiles that represent that item (chairs and flashing balls) are marked as Destructed instead (MCD files, special properties, offset 59 in the structure, the value 12 instead of 11).

If to repair this bug by patching MCD files, Alien Habitat is collected after a tactical game in the original game. There is not a special topic to research, so Alien Habitat is absent in the ingame Ufopedia. However, it appears in base stores, and it can be sold.

OpenXCom, unlike the original game, cannot see Alien Habitat even if marked as such in MCD files, so it is not collected after a tactical game. Placing a patch in the ruleset does not help, either.

Cf. https://openxcom.org/forum/index.php?topic=2872.0 for a patch ready to test.

Please add a service of Alien Habitat to the game.

15

Work In Progress / Alien Habitat and Alien Reproduction

« on: August 30, 2014, 02:49:45 am »

I have created a little mod for the research tree, together with some MCD patches / modifications (see inside the archive, TinyResearchMod.txt, for the argumentation that they are patches rather than mods). Some tiles have been marked as Alien Habitat (specialType: 11) both in the ruleset and in .mcd files (made of yet patched versions, from the Universal Patch).

When I am playing the original game with the patched .mcd files, the game sees those alien chairs as Alien Habitat really, in mission summary. Even if there is no such a topic in the research list, I receive this item in my base, and I can sell it.

However, when I play OpenXCom, no Alien Habitat appears in mission summary or in the base after the mission. I use both patched .mcd and the .rul files (in proper folders, with the mod switched on, etc.).

My question is: can the present version of OpenXCom serve Alien Habitat in the same way like the original game can?

Even if such an item is absent in normal game (in my humble opinion: due to a bug in data files), Alien Habitat appears in the original game when proper changes have been made in mcd's. It would be nice if OpenXCom can imitate this behaviour (for the use of modders).

Or perhaps there is something wrong with my ruleset? Please take a look...

By the way, look at the map UFO_150.MAP (inside the archive); I have found a rather obvious error in the original file, and removed it. This error has been missed in the Universal Patch.

BTW, you can test other features of my mod as well, there is a detailed list of changes inside.