Current and Future Developments

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

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.

 

you say not interesting, I say realms of endless possibility

 

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

 

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

 

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!

 

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

We will be able to see a noteworthy improvement

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

PHP:

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).

 

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

That is the plan

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

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

 

PHP:

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

 

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

 

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.

 

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.