Current and Future Developments

[Nightinggale]

So one problem I have when editing my xml (this one makes me so tired sometimes!)
Is adding in a tag to an existing entry. Trying to make sure I put it in the right place so that the order does not break. (Especially when using entries that do not need to have every tag.) So maybe something that lets you choose an entry like UNIT_INFANTRY, then a list of all unitinfo tags, then you select the one(s) you want and it builds or adds it in the right place(s). Something like that.

That is precisely my plan. You select a file, then a type in that class and it will display everything based on the schema file. That's the essence of my primary goal with all the GUI stuff.

However reading you write this now makes me realise a blunder in my planning. I planned on adding a "new" button, which would then add a new instance to the end. However I just realised that order matters. Well I knew that, but my wishful thinking had forgotten about it. I need some sort of Type reorder feature as well and perhaps something like click on a type and then the new button to make a new type right after the selected one

Perhaps another one for tech tree type situations is something that 'auto fills' the placement order. I don't know exactly what I am thinking, but for example I am thinking of building a tech tree from scratch, and having some way to put them in order, or just an easier way to organise them in the right order, click a button and it then builds that order.. Don't know my brain has gone a bit squishy right now..

I have been thinking of some default values, possibly stored as comments in the schema files. However I will start by making the xml file editable first with a GUI, then worry about default values.

For now I will just carry on and try to make the window itself with the 4? areas it needs to contain and then fill it with xml data. Right now I will be happy if I can just draw the damn thing like I want to. Ok drawing them doesn't seem to be the biggest problem anymore, but 4 empty blocks aren't that interesting.

 

[Lib.Spi't]

Ok drawing them doesn't seem to be the biggest problem anymore, but 4 empty blocks aren't that interesting.

you say not interesting, I say realms of endless possibility

 

[Nightinggale]

I moved my perl GUI stuff into a new thread: http://forums.civfanatics.com/showthread.php?p=14129985

 

[Lib.Spi't]

following! (I have nothing further of value to add..)

 

[Kailric]

Looks like fun stuff your doing with the wxPerl. Ok, I've lost track of where we was in the Civeffect. Did we get things merged so I can start testing and doing the xml work?

Today is my first day of school and I am really excited! After all these years I am finally officially learning to be a programmer I am taking my time too, reading each page carefully even if its just telling me things I have already picked up along my way. I just learned that "the term BUG is often said to have originated from an actual moth that was discovered trapped in the circuitry of a computer at Harvard University in 1945", but actually it has been around since Thomas Edison's time. Da*m bugs, I bet they've been around since the Dinosaurs and that is what probably killed them all off!

 

[Nightinggale]

Looks like fun stuff your doing with the wxPerl. Ok, I've lost track of where we was in the Civeffect. Did we get things merged so I can start testing and doing the xml work?

The merge is complete. I forgot to convert traits to CivEffects and to do so, I better convert FFs too. I don't want to do this amount of xml work, which is why I started the wxPerl stuff. I wonder how many xml files I would have been done with by now if I had just started instead of messing with perl

Today is my first day of school and I am really excited! After all these years I am finally officially learning to be a programmer

We will be able to see a noteworthy improvement

I am taking my time too, reading each page carefully even if its just telling me things I have already picked up along my way. I just learned that "the term BUG is often said to have originated from an actual moth that was discovered trapped in the circuitry of a computer at Harvard University in 1945", but actually it has been around since Thomas Edison's time.

The choice of words is a strong hit that they called it bugs prior to this incident.

Da*m bugs, I bet they've been around since the Dinosaurs and that is what probably killed them all off!

dinosaur->setBreathingRate(15);
printf("%d", dinosaur->getBreathingRate();

I bet it went wrong when this one started printing 134217743. I will be impressed if you figure out what went wrong (no, it's not a random number).

 

[Kailric]

The merge is complete. I forgot to convert traits to CivEffects and to do so, I better convert FFs too. I don't want to do this amount of xml work, which is why I started the wxPerl stuff. I wonder how many xml files I would have been done with by now if I had just started instead of messing with perl

Ahh yeah, and that's what you meant when you said there was tons of xml work.

We will be able to see a noteworthy improvement

That is the plan

The choice of words is a strong hit that they called it bugs prior to this incident.

Ahh, cool, yet it is. Programmers are not known for the excellent use of grammar. I don't consider a moth a bug though, I'd call it an FlyingInsect, inheriting from the Insect class

dinosaur->setBreathingRate(15);
printf("%d", dinosaur->getBreathingRate();

I bet it went wrong when this one started printing 134217743. I will be impressed if you figure out what went wrong (no, it's not a random number).

Well, one issue I see is there is a missing parenthesis?

 

[Nightinggale]

Well, one issue I see is there is a missing parenthesis?

dinosaur->setBreathingRate(15);
printf("%d", dinosaur->getBreathingRate());

How can this one print 134217743? The parenthesis would cause a fail to compile, not a runtime error

 

[Kailric]

So was that a trick question with the correct answer being that it can not print 134... because it would never compile?

 

[Nightinggale]

134217743 = 15+2^27. This mean it writes 15 and read 15, but it adds that one bit is 1 even though it was 0 during writing. This sort of thing actually happens and is called flipped bits. The most annoying cause is cosmic radiation. It can cause a bit to flip in memory and can easily be the cause of a once in a lifetime crash of an otherwise stable application. When you buy computer memory, you can get ECC memory and most people skip it because it is more expensive and requires CPU support. ECC stands for Error Correcting Code, which mean it detects and corrects flipped bits, which in turn makes the hardware more reliable. Servers tend to use those.

I was half joking, but it is true that medical software and other similar critical software has to be aware of this problem and has to constant check if everything still makes sense. For instance if the device provides a constant flow of medication, it should stop and trigger an alarm rather than provide enough to kill a number of people.

For now I think we should just stick to a game where bugs are something you cause at and in worst case restart the game.

 

[Nightinggale]

I'm having stability problems in my data compression approach in savegames. The savegames work, but replay doesn't

I think the best approach would be to disable the variable size and always save 2 bytes (or 4 like vanilla?) to ensure consistency even without a conversion table (replays haven't got conversion tables).

This reintroduces the issue of adding plenty of bytes to savegames, which will always be 0. Thinking about what to do about that, I started wondering about compression libraries and came across 7z. It's fairly fast, has great compression (better than rar and zip) and the only meta data it requires is an int (4 bytes). It also seems fairly easy to use, at least if we leave it at default settings.

My idea now is to write a class with a byte vector. On write, an instance is made and the existing save code is used where pStream points to the new class (minimal code change). Once write is complete, a member function is called to compress the vector and then save the compressed array.

On load, all the data is read into an array and then decompressed into a vector. After that the existing readWrite code is used to read from the vector.

That will for sure ensure small savegames and it doesn't seem unrealistic to implement. However I will not do it now. Instead I will add a byte to the start of the savegame telling if it is compressed or not and always set that to 0. This allows turning compression on/off later if needed and it also allows reading uncompressed savegames after compression is added (read: backward compatible). The goal now is to make all the savegame changes, which prevents backward compatibility, not to make the perfect code not to be touched again.