aliens

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - karvanit

Pages: 1 ... 3 4 [5] 6
61
Programming / Re: Line endings
« on: November 09, 2012, 09:44:44 pm »
We should add the core.autocrlf to the coding guidelines, because we have lots of people on different platforms that get bitten by this.

62
Programming / Line endings
« on: November 09, 2012, 06:48:09 pm »
I have created a branch that set the line endings of files to be managed through Git. (line-endings)
To make sure your line endings are ok, after pulling from it, merging and commiting, delete ALL the files in the working directory (except files under the git directory .git) and do
Code: [Select]
git reset --hardFrom then on, you never have to worry about line endings and huge whitespace changes any more.

This is based on the current SupSupr's master, so you may have many merge conflicts if you have moved a long way from it. But just taking the .gitattributes file from it should help normalize your line endings.

63
Programming / Re: Questions about code / design decisions
« on: November 09, 2012, 05:12:35 pm »
Original XCom was programmed in procedural style with giant array of different global variables and arrays of structures.
So what's wrong with singleton? Is it out of oop paradigm? Or it's make mess in code?

A singleton is (not just IMO) a glorified global pointer. Which IS what I am proposing, and I could live with
Code: [Select]
Game::instance()->foo() instead of
Code: [Select]
theGame->foo().

64
Programming / Re: Reducing numbers of memory allocations in game execution
« on: November 09, 2012, 05:06:21 pm »
Ok, my bad. It is used in the BattlescapeState code, but only at the end.
The visibility calculations are O(N) though, in the number of Battleunits, and they are run every step of every moving unit.

65
Programming / Re: Questions about code / design decisions
« on: November 09, 2012, 10:22:54 am »
Classes having their data blindly manipulated from others directly is not OOP.
OOP means having objects represent ideas and keeping interactions to a minimum, each object containing all the data it needs and preneting the actions that make sense. So, for example, the Ufo should present methods for moving, damaging it or checking for interesting conditions (destroyed, landed, moving). Not give free access to everyone to directly set member variables. Moving all moving things on the map should be the responsibility of the class holding the list of all movables on the map, etc for many things.

Our Game object now has 3 distinct roles. It's the main loop, the game state database and the rules database.
The main loop is a service and should be a global object.
Many things require the ruleset, and we only ever care for one, so a global ruleset is not unreasonable.
Since our objects don't have  a clean state separation (data and behaviour are split across many objects), we need to pass the savegame around. But that is because it too has two roles. It's the 'persistent data' and also the 'current game state of all objects'. The 'current game state' is also a candidate for a global object, to be used everywhere except load/save routines (which actually care for the persistent data).

The above are my personal opinion and are not gospel. But I am obviously biased to think they are good ideas, unless proven otherwise.

66
Programming / Re: Reducing numbers of memory allocations in game execution
« on: November 09, 2012, 10:14:55 am »
The point is - what creates this drop - I doubt it's pathfinding, because there's no need in pathfinding for xcom AI at all.

Of cource it is used. Every time anything wants to from point A to point B pathfinding is used, that's what creates the path (intermediate positions) that any moving unit uses.

67
Programming / Questions about code / design decisions
« on: November 09, 2012, 01:24:35 am »
I have the following questions about some of the decisions in OpenXcom code:
  • Why are we not using YAML anchors and aliases instead of thesaveId() functions? The file structure will be cleaner, and so will the code.
  • Instead of creating the objects and then loading them, why don't we have a "loading" constructor? Again, the code will be cleaner, since we can remove some functions that only get used once.
  • Why don't we have the Game object as a global object (or Singleton)? It is required in LOTS of places and we just store and pass it around (or it's Ruleset and SavedGame members, which amounts to the same thing). Making it visible everywhere would simplify LOTS of code and remove redundant arguments from lots of functions. It's not like we will ever have more than one.
  • Since we gave get/set for every member in some classes, why not make them plain structs?
  • Why do we return pointers to collections (eg Game::getUfos()) instead of references? The code has a lot of places where references are more suited to what we mean instead of pointers (eg Everywhere we store Game, Rule* and SavedGame pointers in classes as fields).
  • Why do we return non-const rules? They should not have writable fields after they are initialized.

If the answer is "too much work to change", I am more than willing to make a patch for either of the above.

68
Programming / Re: Another look at Geoscape AI.
« on: November 08, 2012, 06:57:48 pm »
First of all, thanks for the clean pull request!

so i finally get github "figured out", sit down to take a look at your code, and you've used completely different methods in ruleAlienMission than in... every other ruleset in openxcom.
i'm at a loss here. i just don't know what to do.
should i rewrite it? should i try to figure out wtf you're doing and try to do it that way?

Besides the I/O (which I have now brought more in line with the rest of OpenXcom) the RuleAlienMission only has two functions, one to get the mission type and one to select a race. These are the only mission parts I have in the ruleset so far. I have hidden the 'chose a race from among the possibilities' behind a separate class that can be used to select based on weights, because this is common functionality (choose mission type based on region, choose region for mission, all these are the same).

69
Programming / Re: Reducing numbers of memory allocations in game execution
« on: November 08, 2012, 06:47:14 pm »
A* is like Dijkstra, but smarter about which node to examine first. This is what I have implemented in my patch.
Using a TU limit in the pathfinding needs to take care, so we find the part of the path we can walk within the limit (we still want that).

Simply finding all tiles reachable within X TUs is done as pure Dijkstra in my code, but it has no callers for now.

70
Programming / Re: Another look at Geoscape AI.
« on: November 08, 2012, 06:39:22 pm »
karvanit, what do you mean by "region and zone for each area"?
I mean, of the 720 areas, which belong to each region (eg North Americe) and which belong to each zone (eg North America zone 0)? Is it just by position (offset) in the table?

I have already set the race/month/mission distribution data according to the data in Ufopaedia.org as data in the mission rules.

For the rest (trajectories, UFO types etc) we need a way to represent it in the ruleset. I think trajectories (zones and areas) should be a different ruleset, as well, but the rest (UFOs and spawning them) should be part of a mission's rules. That's what we should be trying to figure out.

We need  a way that can:
  • Handle all the vanilla data. It needs to give as close toi same behaviour as we can get.
  • Allow easy modification.
  • Allow extension (eg new mission types) with minimal of extra coding, only ruleset changes.

71
Programming / Re: Reducing numbers of memory allocations in game execution
« on: November 08, 2012, 12:11:45 am »
Could you try my A* pathfinding code from GitHub? It takes away some allocations and speeds up the pathfinding, which should be a lot with that many actors.
(same username, branch should be obvious)

72
Programming / Re: Another look at Geoscape AI.
« on: November 08, 2012, 12:08:53 am »
I now have code to read / write (incomplete) alien mission rules in 'devel'.
Only the racial distribution is stored for now, and I'm not actually using the rules yet.

73
Programming / Re: Another look at Geoscape AI.
« on: November 07, 2012, 05:04:32 pm »
The steps to do to prepare a clean pull request are:
  • Add my repository as a remote (let's say karvanit).
  • Create a local branch from the branch you want to get merged in eventually. (my devel)
  • Work locally until you are satisfied (making logical and nicely commented commits!).
  • Push your changes to a new branch on GitHub.
  • Make the pull request.

In command line git the commands are (assuming your GitHub remote is origin:
  • git remote add -t devel karvanit git:https://github.com/karvanit/OpenXcom.git
  • git checkout --no-track -b for-karvanit karvanit/devel
  • ... (many git commits later)
  • git push origin for-karvanit


If you are using a GUI tool, I'm sorry, but you'll have to figure the proper way to do steps 1,2 and 4, I have ABSOLUTELY no experience with them.

74
Programming / Re: Another look at Geoscape AI.
« on: November 07, 2012, 04:20:03 pm »
@volutar: Great information, thank you. Could you also add the region and zone for each area?
@Warboy1982:
Races should be a sequence of maps, like so:
Code: [Select]
races:
  - afterMonth: 0
    distribution:
      STR_SECTOID: 10
      STR_MUTON: 5
  - afterMonth: 3
    distribution:
      STR_SECTOID: 10
      STR_FLOATER: 20
      STR_MUTON: 50

Taking the info Volutar has uncovered, I think we should either have a table of trajectories common to all missions (and use trajectory number / id) or replicate the trajectory information per type (scout / mission). I'm leaning towards common list and using ids myself, less typing / cut-and-paste. This means the flightPattern is not needed as we discussed.

75
Programming / Re: Another look at Geoscape AI.
« on: November 07, 2012, 12:21:51 pm »
translation: shoot down scouts, aliens get mad and send bigger scouts and eventually battleships as scouts, or even as the mission ships themselves. (in certain cases, hence why we define it in the rulesets)

see also:
https://www.ufopaedia.org/index.php?title=Terror_Mission#UFOs_with_Terror_Missions

Yes, but on eg Terror info from MISSIONS.DAT it appears only 4 ships will take part in the terror mission. Two scout and two terror ships.

So, how does it work? How do we want to encode it so that at least the vanilla behaviour happens for 1.0? How to encode it so that additional things can be done just by tweaking the ruleset?

Pages: 1 ... 3 4 [5] 6