tjhancocks / kdl Goto Github PK

An example of what is meant is below.

declare PlayerCharacterTemplate {
  duplicate (#128 as #150) {
    Cash = 50000;
  };
};

An example of what is meant is listed below:

declare PlayerCharacterTemplate {
  override (#128) {
    Cash = 50000;
  };
};

Get KDL working on Windows.

This will require the following actions to completed:

• Ensure Graphite is working for Windows.
• Ensure KDL builds for Windows and all existing tests pass.

The built in KDL types all have errors in their conversion definitions. They use $InputFile rather than $InputFormat

• MacintoshPicture (Support/KDLTypes/Toolbox/Picture.kdl)
• MacintoshColorIcon (Support/KDLTypes/Toolbox/ColorIcon.kdl)
• MacintoshSound (Support/KDLTypes/Toolbox/Sound.kdl)
• RLESprite (Support/KDLTypes/SpriteWorld/Sprite.kdl)

Further more the import paths are not complete in the Manifest files:

• Toolbox (Support/KDLTypes/Toolbox/Manifest.kdl)
• SpriteWorld (Support/KDLTypes/Toolbox/Manifest.kdl )

They should look like:
@rpath/.kdl/toolbox/Types/FileName.kdl

This issue is hidden by the issue raised in #29.

Overview

When started in a specific mode, KDL should act as a pseudo "server", providing information about available types, resource viewing, creation editing over an interface (REST/JSON most likely).

Reasoning

Plugin and mod creation for Kestrel based games should not be gated behind KDL itself.

How

KDL follows a reasonably rigid flow:

1. Parse arguments, and import any required resources (Scenario Manifest, external Data Files, record which KDL files to import, etc). Start constructing the "target", which is an object that represents the resulting resource file.
2. Read each of the discovered KDL files into the "target".
3. Export target to disk.

It could be possible to inject this functionality just before step 3. Start a server and allow external callers to influence, mutate and inspect the target, before instructing KDL to resume and save the target to disk.

An example of how KDL might be invoked with this is as follows:

$ kdl --scenario game --include /path/to/game/data -o output --start-server

Example API

This is an example of how the API might look, with respect to getting the known resource types from KDL.

Request:

GET /defined_types HTTP/1.1
Host: localhost:8080

Response:

[
    {"name": "Alpha", code: "älph"},
    {"name": "Beta", code: "bëta"},
    {"name": "Gamma", code: "gmma"}
]

The issue is in conversion.cpp, and it appears to be that no matter what input format is used for the conversion, it will just use PNG.

https://github.com/tjhancocks/kdl/blob/master/src/media/conversion.cpp#L103-L130

An example of what is meant is listed below

@type StellarObject : "spöb" {
  
  relationship("LandingText") Description& {
    $id - 128 + 1000; ` or whatever the exact formula is. can't recall of top of my head.
  };

};

declare StellarObject {
  new (#128, "Earth") {
    LandingText = new {
      ` stuff here...
    };
  };
};

This is a complex issue and will involve a couple of things:

• Keep track of all resource declarations in a table internally.
• Multipass approach to assembly.
  1. Parse all resources as normal, but keep track of any resource dependancies, as well as build a table of all resources (type, id, name, etc)
  2. Validate that all resources that are required exist,
  3. This may involve loading in existing data files and using them to assist this process.

This will be required to enable certain other features to work.

There needs to be a way to encode rleD resources for use in EV Nova. Due to how rleD resources work, this will need some adjustment to the KDL language and syntax.

rleD resources consist of a series of "frames" which can be thought of as separate images. Each frame should be defined as a separate image on the users system, and specified using the following
syntax:

Sprites = import "frame1.tga" "frame2.tga" "frame3.tga" ...

This list should be variable in length with the user being able to specify as many as they want. Alternatively the following syntax should also be available:

Sprites = import directory "path/to/directory" "tga"

This would allow the user to specify the directory containing the sprite images and specify the file extension of those images. KDL can then use this information to determine what images to load.

Once images have been loaded the following checks must be completed:

1: All images must be the same size.
2: Images must support alpha transparency i.e. TGA or PNG (assuming it has been implemented)

Once everything is loaded and confirmed to be valid for an rleD frame, then the images need to be handed to the rleD encoder and processed. See how the graphite::qd::pict and graphite::qd::cicn resources work for this.

Note: Some of this work actually needs to happen in Graphite rather than KDL itself.

This is due to the configuration file path not being expanded when performing a file exists check.

It should be possible for GUI based editors and programs to be able to include the lexer and parser via a library in order to work with KDL files directly.

This will also help with modularity in the project.

Some types such as MacintoshPicture need this feature. They need to have multiple fields that reference the same template field, but only one needs to be specified.

@type MacintoshPicture : "PICT" {
	template {
		HEXD Data;
	};

	optional field("PNG") {
		Data as File<PNG> __conversion($InputFile, PICT);
	};

	optional field("TGA") {
		Data as File<TGA> __conversion($InputFile, PICT);
	};
};

declare MacintoshPicture {
	new (#128) {
		PNG = import "image.png";
	};
	new (#129) {
		TGA = import "image.tga";
	};
};

This issue is to track the progress for introducing unit tests into KDL.

The ability to disassemble resource files.

KDL currently has no means of representing the STR# resource type. The template for this resource is as follows:

@type StringList : "STR#" {
    template {
        OCNT NumStrings;
        LSTC _;
        PSTR TheString;
        LSTE _;
    };
};

KDL has no way of handling this type of a resource template currently and as such, support for this type should be baked into the assembler directly, requiring no type definition. The end user would not see any difference directly. They would use the StringList type like so:

declare StringList {
    new (#128) {
        String = "Item 1";
        String = "Item 2;
        String = "Item 3";
        String = "Item 4";
    };
};

The String should be a repeatable field, each repetition being an element in the list.

An example of what is meant is below:

declare PlayerCharacterTemplate {
  new (#auto) {
    Cash = 50000;
  };
};

Example:

$ cat Example.kdl
@type Example : "exmp" {
}

Output:

$ bin/kdl -o ../kdl-out/ Example.kdl
libc++abi.dylib: terminating with uncaught exception of type std::logic_error: [kdl::sema::parser] Attempted to access lexeme beyond end of stream.
Abort trap: 6

It'd be nice if the message was something like Example.kdl:L2:1 - Expected ';' at end of file.

We should get LSP support into KDL so that external editors can communicate with KDL to understand the syntactic structure of the code. This can help code editors and IDEs correctly render, colour and provide completions and hints for KDL.

This issue is intended for keeping documentation images.

An example of what is meant below.

declare StellarObject {
  new (#128, "Earth") {
    Government = new(#auto, "Planet Specific Government") {
      `... definition for government
    };
  };
};