Messages

1

Programming / Re: ruleset dumping for testing (modding & coding)

« on: December 29, 2013, 02:14:36 am »

How acceptable are macros?

This code can be cleaner, more readable by using macros.
bool Example::map(Node& node, const typename MemberMappingNodeKey<Node, Example>::type *key, const Example *oldValue) using macros:

Code: [Select]

bool result = true;
MAP_MEMBER(op, required, result, Example, x, node, "x", oldValue)
MAP_MEMBER(op, required, result, Example, y, node, "y", oldValue)
return result;
where MAP_MEMBER is defined by:

Code: [Select]

#define MAP_MEMBER(op, required, result, Type, member, ...) \
if (!MemberMapping<op, required>::map(*this, &Type::member, __VA_ARGS__)) \
{ \
if(op == MemberMappingOps::equals) return false; \
result = !required; \
}


2

Programming / Re: ruleset dumping for testing (modding & coding)

« on: December 28, 2013, 09:18:01 pm »

Here is my current model:
in header:

Code: [Select]

struct Example
{
int x, y;
template<MemberMappingOp op, bool required, typename Node>
bool map(Node& node, const typename MemberMappingNodeKey<Node, Example>::type *key = 0, const Example *oldValue = 0);

https:/// Loads the example from YAML.
void load(const YAML::Node& node, std::string *key = 0);
https:/// Saves the example to YAML.
YAML::Node save(const std::string *key = 0, const Example *oldValue = 0) const;
};

cpp file:

Code: [Select]

template<MemberMappingOp op, bool required, typename Node>
bool Example::map(Node& node, const typename MemberMappingNodeKey<Node, Example>::type *key, const Example *oldValue)
{
bool result = true;
if (!MemberMapping<op, required>::map(*this, &Example::x, node, "x", original)) result = !required;
if (!MemberMapping<op, required>::map(*this, &Example::y, node, "y", original)) result = !required;
return result;
}

void Example::load(const YAML::Node& node, std::string *key)
{
map<MemberMappingOps::load, true, YAML::Node>(node, key);
}

YAML::Node Example::save(const std::string *key = 0, const Example *oldValue)
{
YAML::Node node;
map<MemberMappingOps::save, true, YAML::Node>(node, key, oldValue);
return node;
}



3

Programming / Re: ruleset dumping for testing (modding & coding)

« on: December 28, 2013, 08:56:42 pm »

It could also mix binary cache and some other format , such as YAML.
Then a timestamp check could be used to see if the binary cache needs to be updated.
The list of used rulesets would also be in the binary cache.
This would allow faster loading when using the same rulesets in the same order.
However, checking time stamps usually requires platform dependent code.

Lastly, I do plan on having load and save stubs in the cpp files that would call the template functions which will also be defined the the cpp files.
As long as the template functions are not defined in the header and not used anywhere else, that should have no more than a negligible effect on compilation.

Otherwise, SomethingFor<type> structs can be specialized for the job where Something is something else.

4

Programming / Re: ruleset dumping for testing (modding & coding)

« on: December 28, 2013, 05:54:01 am »

What if I design some template functions that allow one template function to be written for both loading and saving?
This would remove the extra maintenance by allowing one template function specialize for a load stub and a save stub.
Templates are already used for shading in OpenXcom.

5

Programming / Re: ruleset dumping for testing (modding & coding)

« on: December 28, 2013, 04:27:48 am »

I agree that it adds another function to each rule class to maintain; however, a save function can be next to the load function, updated in unison, and followed by using a differential dump to check for typos in the load & save code as well as the ruleset.

Actually, I copied the code from the load functions and used regular expression replacement to transform most of the code from the load functions.

6

Programming / Re: ruleset dumping for testing (modding & coding)

« on: December 28, 2013, 01:29:28 am »

Defaults change the YAML tree making comparisons of YAML trees inaccurate.
The Ruleset and Rule* objects will have to be copy-able and have their own difference dump functions, but this would provide a better match with the ruleset model used by the OpenXcom including any new defaults.
This would allow Xcom1Ruleset.rul to be used as a base for differential dumping removing extraneous rules from the dump(s), but would be more work.

7

Programming / Re: ruleset dumping for testing (modding & coding)

« on: December 27, 2013, 11:55:36 am »

void dumpYamlToFile(const std::string &filename) const could be changed to void dumpYamlToFile(const std::string &filename, const std::string &baseFilename) const where baseFilename is a base YAML file loaded into a base tree for comparison.
The DUMP_BASE top level node would be used for chaining differential ruleset dumps.
The DUMP_DELETED top level node could be used for identifying anything removed without a special delete tag, which could help check for lost nodes when dumping due to incorrect/outdated code by checking it against the original ruleset.

The -dumprulesetbase command line option would specify the baseFilename.

Another option that can also be combined with the previous is recursive differential dumping in void Game::loadRuleset().
The -dumprulesets command line option would specify the use of recursive differential dumping of the ruleset using its PATH parameter as a prefix with incremental numbers followed by ".rul" appended for each dump.
The -dumprulesetbase command line option could be extended to support +<number>, where <number> is the ofset into the list of rulesets from where to start.

Code: [Select]

openxcom -dumprulesets diff_ -dumprulesetbase +1would skip the first entry in rulesets and output diff_0.rul, diff_1.rul, ...


The code would probably be O(n^2) for dumping, but would have almost no effect on normal operation of OpenXcom.

8

Programming / ruleset dumping for testing (modding & coding)

« on: December 27, 2013, 07:06:44 am »

I created a pull request (PR758) for debugging mods and changes to the ruleset.
When using the added command line option, it dumps the composite ruleset loaded by OpenXcom to the specified file.
This can be used to check that changes the the ruleset structure are loaded correctly.
It can also be used when making or mixing mods, since it shows the resulting ruleset.
If having it wrapped in ifdef blocks for conditional compilation is preferred, I can do that.
If this feature is unwanted, I will close the pull request.
Comments and change requests are welcome.

9

Work In Progress / reaction fire priority in ruleset

« on: December 23, 2013, 10:16:45 am »

Perhaps you would like something like this:

Code: [Select]

  - type: STR_SNIPER_RIFLE
    size: ?
    costBuy: ?
    costSell:
    weight: ?
    bigSprite: ?
    floorSprite: ?
    handSprite: ?
    bulletSprite: ?
    fireSound: 4
    compatibleAmmo:
      - STR_SNIPER_RIFLE_CLIP
    accuracyAuto: ?
    accuracySnap:
    accuracyAimed: ?
    tuAuto: ?
    tuSnap: ?
    tuAimed: ?
    battleType: 1
    twoHanded: true
    invWidth: 1
    invHeight: 3
    reactionFiring: [STR_AIMED_SHOT, STR_AUTO_SHOT, STR_SNAP_SHOT]
where

Code: [Select]

reactionFiring: [STR_AIMED_SHOT, STR_AUTO_SHOT, STR_SNAP_SHOT] is used to order the reaction fire options.

The code should check each action in order seeing if there are enough TUs and ammo, then check actions short on ammo but not TUs in the same order.
This would cause the effective order to be aimed, snap, then auto if auto is short on ammo, which makes auto less likely to hit.

This could also be hard-coded, but would have to be replaced if custom actions for individual items can be added in the future.
For example:
   A future machine gun mod may have snap, aimed, semi-auto, and full-auto actions.
 

Code: [Select]

reactionFiring: [STR_FULL_AUTO_SHOT, STR_SEMI_AUTO_SHOT, STR_AIMED_SHOT, STR_SNAP_SHOT]