loading set from file

[laggyluk]

I didn't explained it well enough, sorry. It turns out it's not possible so I used a map
http://stackoverflow.com/questions/1...ng-to-set-type

[SilverWarior]

I know that using strings for naming block types might look easier but in the end it only complicates things not to mention that operating with strings is ususally slower.
So I advice you to use numbers for defining your block type. Why? Becouse with numbers you can quickly kinda divide all of your block types into sets.
Take a look at next example of block definition:

//Pseudocode

//Passable blocks: 0-100
begin
  0 = air
  1 = water
  2 = background wall
  3 = doors
  ....
end

//Unpassable blocks 100-900
begin
  //Destructable blocks
  begin
    //Ground 100-199
    begin
      100 = dirt
      101 = grass
      102 = stone
      ...
    end
    //Minerals 200-300
    begin
      200 = iron
      201 = coal
      202 = coper
      ...
    end
  //Undestructable blocks 900-1000
  begin
    901 = bedrock
  end
end

In the end you can also define numeric sets in form of btMinerals: 201..300. This alows you to change the block definition types at any time without the need to recompile your program and still use sets to quickly determine block type.

[laggyluk]

it's a byte not a string. I just let the compiler number them

type 
   {$PACKENUM 1} 
   eBlockTypes = (btNone,btUndefined,btStone, btYellowFlower, btWoodBrown);

...

mineralsNonBlocking:=[btNone]+mineralsOxygen;

[Super Vegeta]

Hm, can't you just typecast the set to an integer when saving, and then do it the other way when loading?

Btw, doing a writeln(enum_type) will print the name of the identifier, as it appears in code. Have you checked if readln(enum_type) works?

[laggyluk]

I can't apparently. isn't writeln/readln console program thing? anyways it says 'Error: Can't read or write variables of this type'

[SilverWarior]

it's a byte not a string. I just let the compiler number them

Automatic numbering for such things isn't verry suitable as you can quickly change the numbering order by changing the set itself. This means that after you change the set your program will no longer be able to load older savegame.
Using my aproach also has advantage of you being albe to leave some identifier numbers unused so you can use them in the future and therefore avoid changing existing ones when adding new ones.

EDIT: As for sets their primarry use is to add predefined identifiers for some properties. And yes in memory set elements are saved just as Indexes of set elements. You can consider sets as bunch od Constants of same type grouped together.

[laggyluk]

Automatic numbering for such things isn't verry suitable as you can quickly change the numbering order by changing the set itself. This means that after you change the set your program will no longer be able to load older savegame.
Using my aproach also has advantage of you being albe to leave some identifier numbers unused so you can use them in the future and therefore avoid changing existing ones when adding new ones.

I know what you mean but so far so good, I just add new elements to end of set

[Delphius]

Although there are other possible ways to address the problem If the intention is to add more elements to the enumerated type seems just a design flaw and is making use of the wrong type.
If you have not yet defined the number of items and you'll be adding more and more, it is clear that go on your design is counterproductive.
It is better to redirect this design to one based on classes as I mentioned in a previous post.
You design The class TMineralList with methods to add and remove items in an internal list. And until it can be designed to do set operations such as union and intersection if you want.
TMineralList assumes responsibility for store / read the file and materialization. If you insist to make the correspondence by string, you be can avail the name of the class. Something like this:

type
TBlockTypeClass = class of TBlockType; //TBlockType is the abstract base class

var
BlockType: TBlockType;
BlockTypeClass: TBlockTypeClass;
...

Index := BlockLists.IndexOf(TheTextReadFromFile);
BlockTypeClass := TBlockType(BlockLists.Object[Index]);
BlockType := BlockTypeClass.Create;

BlockLists is a TStringList.
To "register" each subclass of TBlockType:

BlockLists.AddObject(ConcreteBlockType.ClassName, TObject(ConcreteBlockType));

Naturally this design not is "the solution", because it involves add new classes, but when trying to be adding elements to an enumerated type in the first thing you should think about is a lack of design and/or are not using the right path.
I say this with all respect.

Regards,
P.S: Soory for my bad English.

[User137]

I don't think it's as much a type problem, but more of a file-format problem. If you have old version file where is

[someobject1]
type=10

(where type 10 meant grass)
And new file

[someobject1]
type=11

(where type 11 means grass)
Loading old file with new loader, would consider that type 10 object something else than it was meant to be.

You need a way to distinct the 2 files. I'm not one to give you right answer to that. Clumsiest of all ways is to have version number on top, and different loading routine for each version. You can forget to change the file version from the source code, and override your work file with garbage data.

One other way is to explain all the types at beginning of file. For example:

[type10]
texture=grass.png
burnable=true

That might also mean new list structure for program to store this information.
(In essence, new types will be added to the end of the list.)