Re: [glob2-devel] New Features Galore (ps: I merged them)

[Leo Wandersleb]

Hi Bradley

Great you did so much while i was afraid glob2 was kind of dieing from a lack 
of programmers.

my feedback:
when pressing cancel on the introduction-screen for the next mission after a 
campaign i get:
...
SGSL : Use of setArea is deprecated. Use newer script areas in the map editor 
instead.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47243185862976 (LWP 13800)]
0x00000000006099b2 in EndGameScreen::EndGameScreen ()

I could reproduce it after the second mission.

when choosing "Start" instead, the next mission launches normally, but when now 
i say "Quit the game" i get:
...
SGSL : Use of setArea is deprecated. Use newer script areas in the map editor 
instead.

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 47569457813824 (LWP 14011)]
0x000000000062b665 in GAGCore::DrawableSurface::_drawHorzLine ()





>>  - New unit and building editor -
>>
>> The map editor has new unit and building editing functionality! The
>> many in-game properties of units and buildings are editable. This is
>> achieved simply by clicking on the unit. The proccess of adding a new
>> editable property is simple enough, if someone wants a new editable
>> property for units or buildings added, I can do it. (This does *not*
>> allow the editing of ingrained building-type properties, only
>> properties mutable at game-time).

great! works fine and intuitive.

i wondered how turrets have bullets and stone without a hard-coded relation. 
maybe it should have only one of those adjustable.

>>
>>  - New translation text shot code -
>>
>> Personally, this is my favorite new feature. The translation text
>> shots are bassically screenshots that are taken of the screen when a
>> particular translation key is drawn to the screen. But not only that,
>> the translated text is highlited as well! This means translators will
>> be able to trivially get context to their translaions. It is enabled
>> by running glob2 with "glob2 -textshot <directory>". You can use "."
>> for the current directory. All of the screenshots are bmp's, so watch
>> out for hardrive consumption.

technically a nice feature. if i ever touch this language system again (i 
started on an ajax-site to help translate glob2) i will add some image-magick 
to get small pngs or jpgs.

>>  - New Script Areas -
>>
>> Thats right, the old way of doing areas in scripts has been replaced.
>> The map editor now features new script areas. These "areas" can be in
>> any shape, they have a name and are place dmuch like forbidden zone.
>> Their can be between 0-9 of them on any one map. (The limit 9 is made
>> because each square is labeled with the areas it contains, in a 3x3
>> square, there are 9 places to draw a number. As well, script areas are
>> a light aqua in coloring). This is replacing the conventional position
>> and radius way of doing areas directly from the script. The old way is
>> still there, however a message signifying that its deprecated is sent
>> everytime the game is run. I did not make the changes on the tutorial,
>> since the script I had was not the one that has been merged with all
>> the translations.
>>
>> - Improved Echo API -
>>
>> The Echo API has been made much more generic since its last revision.
>> Conditions has been generalized, it is now much mroe powerfull. The
>> proccess of automatically constructing and upgrading 10 inns, to be
>> cosntructed and upgraded in sequence (1 after another), and having
>> upgrades start after the fifth is complete, *and* allowing the chain
>> of construction to continue even if one of the buildings is destroyed
>> takes a mere 100 lines of code, including all of the code to choose a
>> location. Its not bad for a low barrior approach to an API. This is
>> done via enhanced conditions, the merging of all the types of
>> management orders, and the allowance of building orders to accept
>> conditions. However, this shift in the API did not come with one
>> sacrifice: old save-games using ReachToInfinity can not be loaded with
>> the new API. Please don't scream, this was a nesseccarry sacrifice. I
>> thought long and hard to avoid it, I couldn't work arround this
>> difficulty, and still have the new API that I wanted.
>>
>>  - New No-Ressource-Growth Areas -
>>
>> Thats right, this is the solution to those horrific "I can't upgrade
>> my racetrack bugs". These new areas, again placable like a traditional
>> zone from the map editor, restrict ressource growth . Nothing can grow
>> from, or into these areas. I haven't changes the tutorial yet, again
>> because I don't have a version with the merged translations. I will do
>> it as soon as I get internet at my house.

As there was the mentioned problem of cheating by covering the opponents wheat 
with this i guess i don't have to search any closer for this missing feature.

>>
>>  - Updated End-Game screen -
>>
>> The end game screen graph has been signifigantly improved. Among the
>> new features includes time scaling, and amount marks. As well, you can
>> disable and enable particular teams to be drawn. And, if you move your
>> mouse pointer close to the lines on the graph, it will give you the
>> value of that position. These improvements make a siginifigant
>> contribution to the usability of the end-game screen graphs.

great work here, although i had cases when there was a line shown even as now 
checkbox was checked. see
http://home.in.tum.de/~wandersl/Bug0001.jpg

>>  - New statistics -
>>
>> You know how in the game, the statistics screen tells you that you
>> have tons of free workers, but the upper left hand statistic on the
>> top-bar of the screen tells you your desperately needing jobs? I've
>> now added for more small statistics that should help this
>> signifigantly. Each tells how many jobs are needed *per level*. This
>> can tell you if all of those unfilled jobs are level 2 jobs, which may
>> signify that you need to build more schools to train faster. This
>> should help us advanced players considerably.

Thanks! that's a good thing.

>>  - New overlay areas -

try to better represent levels. now all points of damage/hunger/turrets 
generate a field of the same size indicating that there is d/h/t.
i would like it to more represent the level of d/h/t.
for example, the now used damage gradient could be the 100% damage gradient 
with an according scale. so 1% damage results in only the field of the glob to 
turn red while shortly before death it turns to the size it is now.

turrets on the other hand should be no gradient, as their damage is constant 
within a rectangle. i would generate a 12x12 square of constant blue 
representing the damage done per second for a L1 turret. for a L2-turret it 
would be darker and 14x14 while overlay of several turrets areas would 
represent the somehow more dangerous situation for opponents.

hunger could be represented by a far less dense "gradient"

>> Now for a completely unique feature. I got this idea from Sim City
>> 4000. Sim City would tell you what areas had, for example, the largest
>> polution, crime, or desirability. It did this by overlaying color onto
>> the main screen to signifiy the level of that particular overlay. I,
>> my friends, have done the same. You will now see, on the statistics
>> graph menu, three new check boxes with captions "Starving Map",
>> "Damaged Map", and "Defense Map". By clicking one of these checkboxes,
>> colors will be overlayed on the main screen. You can see areas of
>> concentration for starving and damaged units, and your areas of high
>> defenese. Remember all of these values are relative to the maximum
>> number of starving or wounded units, or your maximally defended areas.
>> (Having a finite graph was an option, but I decided I alone couldn't
>> achieve a good maximum and minimum value, since I wasn't the general
>> playing population). Gradient here is used in the graphical sense, not
>> the pathfinding sense.
>>
>> Now, with low quality mode enabled, the score of a box is simply
>> converted to an alpha for a color and drawn to the screen. Bassically
>> it colors in 32x 32 boxes. With high quality enabled, I tried
>> something trickier. I attempted to gradient between the boxes in 8 x 8
>> sections (8x8 is sufficiently small you can barely tell). The
>> gradients are indeed extremely complex to do without writing a value
>> for every 8x8 box ( which would take up 16 times the memory of using
>> the standard squares anbd giving values to them ). The gradient
>> formula was very difficult to create, and it still has allot of error.

are you talking about
http://home.in.tum.de/~wandersl/Bug0002.jpg
?

>> Its reasnobly enough to create a decently smooth gradient in areas of
>> high concentration. When there is only 1 starving unit on the entire
>> map, on teh other hand, and you enable this overlay, the flaw in my
>> gradient formula becomes clear. Te formula bassically takes the
>> average of the north-south gradients and the east-west gradients. The
>> value of the box in question is entirely ignored, its the surrounding
>> boxes that are considered, and the gradient is calculated between
>> them.
>>
>> I went through *allot* of expirementation to come to this result. I
>> can honestly tell you that it is the best I could come up with. I
>> spent hours with a notepad working our formulas to make the gradient
>> the way I pictured it appearing in my head. I just couldn't do it. I
>> tried averaging between all 8 surrounding squares, not just four of
>> them. That turned out very mismatched. I tried calculating the
>> gradient of a square between what would logically be the score between
>> the lines that seperate the 32x32 pixel squares. That turned out too
>> blocky and obvious. I tried developing the gradient based on the
>> maximum instead of the average, that turned out just odd, I can't
>> remember how, but it just did. Anywho, I encourage anyone who has
>> experience with graphical algorithms for a gradient like what I'm
>> doing to improve my scode, its about 50 lines before the end of
>> Game::drawMap in Game.cpp. It sticks out because of all the

maybe (10%) i will have a look.

>> const-float definitions used in the formula. It should be easy enough
>> to figure out.
>>
>> One question to nct/nuage, is it semantically correct to send the size
>> of the map to TeamStats in Game::load? Is there another setMapSize
>> function that I should locate the code into? The overlay maps are
>> calculated everytime the teams stats are updated (about once every 4
>> seconds).
>>
>>
>>  - Thats it -
>>
>> I didn't get anything else done. Un-impressed? I worked my ass off!
>> Ahh just kidding. These changes where fun to do. I hope you enjoy
>> them. Most of you wont enjoy them quite yet, because someone has to
>> merge them into the current cvs. I'm in the proccess of uploading the
>> glob2.tar.gz to my website, and I'll post some merging information on
>> another thread once I get that done.
>>

greetings, leo wandersleb