151
MegaGlest / Re: Oi quero criar um servidor
« on: 24 October 2012, 16:03:11 »
Yes, that looks correct
News:
Check out the latest MegaGlest news on our e-mail newsletter (subscribe), Twitter, Facebook and Google+.
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
152
MegaGlest / Re: Oi quero criar um servidor
« on: 24 October 2012, 15:54:22 »
there should be something called: NAT in the advanced Setup
Then Add
Mark Custom Server
give it any name e.g. "MegaGlest"
Server IP Address = the local IP of your computer
And External+ Internalports: 61357
Then Add
Mark Custom Server
give it any name e.g. "MegaGlest"
Server IP Address = the local IP of your computer
And External+ Internalports: 61357
153
MegaGlest / Re: More lua by request of MuWuum
« on: 17 October 2012, 22:37:16 »
Thank you very much, will test it later. 
Update:
Tested, is working great
Update:
Tested, is working great
154
Maps, tilesets and scenarios / Re: BattleGlest Alpha v. 0003-008 ( 31 May 2012)
« on: 16 October 2012, 23:36:12 »
After a longer break BattleGlest is back in active development.
Today I implemented the teleporters which speedup the game a lot.
It still suffers in any kind of balancing. Will have a try to improve that in the next days.
A development-Alpha could be out at the end of the week.
Today I implemented the teleporters which speedup the game a lot.
It still suffers in any kind of balancing. Will have a try to improve that in the next days.
A development-Alpha could be out at the end of the week.
155
Off topic / Re: My first program (Released !)
« on: 26 September 2012, 06:24:28 »
Maybe it would help, to tell what your program does? I have no idea what it's for and won't run software where I have no Idea what it will do.
156
Mods / Re: Glest Community Development Monthly - Issue 55
« on: 15 September 2012, 12:24:09 »
Oh, sorry, I missed that ... somehow.
Should we rename it to Quarder-Yearly (or something like this)
Should we rename it to Quarder-Yearly (or something like this)
157
Mods / Re: Glest Community Development Monthly - Issue 55
« on: 14 September 2012, 06:19:25 »The next issue is scheduled for 11 December 2012 (GMT+10)....Well that does not look like monthly ...
158
MegaGlest / Re: user accounts / ranking system
« on: 11 September 2012, 12:32:34 »I mean if you are at a very high skill and kill a cpu(easy). Do you get less points for that? or do you get as much as you would get if you are a low skill player.
Here are some examlpes for my calculation (team 1 always won).
| Team 1 | ELO | New ELO | Team 2 | ELO | New ELO |
| Player 1 | 1000 | 1016 | Player 1 | 1000 | 984 |
| Team 1 | ELO | New ELO | Team 2 | ELO | New ELO |
| Player 1 | 1000 | 1003 | CPU EASY | 400 | 397 |
| Team 1 | ELO | New ELO | Team 2 | ELO | New ELO |
| Player 1 | 2500 | 2508 | Player 1 | 2000 | 1991 |
| Player 2 | Player 2 | 1500 | 1493 |
| Team 1 | ELO | New ELO | Team 2 | ELO | New ELO |
| Player 1 | 2900 | 2901 | Player 1 | 400 | 397 |
| Team 1 | ELO | New ELO | Team 2 | ELO | New ELO |
| Player 1 | 400 | 429 | Player 1 | 2900 | 2885 |
159
MegaGlest / Re: user accounts / ranking system
« on: 10 September 2012, 17:59:09 »does MuwuM thought about games you easily win? like playing against a cpu(easy)? Do you get ELO for these too? is that right?
for beating a cpu on easy you get 1 ELO point ... for a match again a player of your skill 16.
160
MegaGlest / Re: user accounts / ranking system
« on: 9 September 2012, 18:33:38 »
I like the idea of a ranking where players can select to join or not.
About ranking cheaters: I would recommend not to allow ranked games between the same amount of time, without having played with a number of other player.
About ranking cheaters: I would recommend not to allow ranked games between the same amount of time, without having played with a number of other player.
161
MegaGlest / Re: user accounts / ranking system
« on: 4 September 2012, 18:27:52 »
Here the concept of my modified version of ELO for MG:
https://docs.megaglest.org/MG/ELO (Wiki because TeX does not work in the forum)
https://docs.megaglest.org/MG/ELO (Wiki because TeX does not work in the forum)
162
Feature requests / Re: Suggestion: Voices change in the language that is selected
« on: 9 August 2012, 16:52:18 »
Hello,
your idea is not really new, but a technically challenge. Due to the way sound files are stored and loaded it would be hard to seperate translated language, not translatable soundeffects and fallback sounds. For technical background see: https://docs.megaglest.org/XML/Skills (the sound-tags)
your idea is not really new, but a technically challenge. Due to the way sound files are stored and loaded it would be hard to seperate translated language, not translatable soundeffects and fallback sounds. For technical background see: https://docs.megaglest.org/XML/Skills (the sound-tags)
(click to show/hide)
163
Maps, tilesets and scenarios / Re: BattleGlest Alpha v. 0003-008 ( 31 May 2012)
« on: 16 July 2012, 16:46:24 »
Battleglest is now aviable on GitHub: https://github.com/MuwuM/Battleglest.git
164
Feature requests / Re: Animations of Upgraded/Advanced Units
« on: 10 July 2012, 17:11:09 »How about allowing for different unit particles for each 'level' ?
yes, like it
165
MegaGlest / Re: I want a new release!!!
« on: 2 July 2012, 00:20:52 »
Maybe we should do some kind of nightly builds, for the one's that don't want to complie anything, but would like to test. (I know that it would mean even more work)
166
MegaGlest / Re: I want a new release!!!
« on: 29 June 2012, 10:48:46 »Why don't you just ask your dad?
Because he want a release for everyone. And not a custom build for himself.
I do not think so because as more delay we a better version and more features packedbut I admit It is difficult to wait.
Guidelines for creating good open source software (source wikipedia)
7. Release early. Release often. And listen to your customers.
Quote from: Eric S. Raymond
show original
Early and frequent releases are a critical part of the Linux development model. Most developers (including me) used to believe this was bad policy for larger than trivial projects, because early versions are almost by definition buggy versions and you don't want to wear out the patience of your users.
This belief reinforced the general commitment to a cathedral-building style of development. If the overriding objective was for users to see as few bugs as possible, why then you'd only release a version every six months (or less often), and work like a dog on debugging between releases. The Emacs C core was developed this way. The Lisp library, in effect, was not—because there were active Lisp archives outside the FSF's control, where you could go to find new and development code versions independently of Emacs's release cycle [QR].
The most important of these, the Ohio State Emacs Lisp archive, anticipated the spirit and many of the features of today's big Linux archives. But few of us really thought very hard about what we were doing, or about what the very existence of that archive suggested about problems in the FSF's cathedral-building development model. I made one serious attempt around 1992 to get a lot of the Ohio code formally merged into the official Emacs Lisp library. I ran into political trouble and was largely unsuccessful.
But by a year later, as Linux became widely visible, it was clear that something different and much healthier was going on there. Linus's open development policy was the very opposite of cathedral-building. Linux's Internet archives were burgeoning, multiple distributions were being floated. And all of this was driven by an unheard-of frequency of core system releases.
Linus was treating his users as co-developers in the most effective possible way:
7. Release early. Release often. And listen to your customers.
Linus's innovation wasn't so much in doing quick-turnaround releases incorporating lots of user feedback (something like this had been Unix-world tradition for a long time), but in scaling it up to a level of intensity that matched the complexity of what he was developing. In those early times (around 1991) it wasn't unknown for him to release a new kernel more than once a day! Because he cultivated his base of co-developers and leveraged the Internet for collaboration harder than anyone else, this worked.
But how did it work? And was it something I could duplicate, or did it rely on some unique genius of Linus Torvalds?
I didn't think so. Granted, Linus is a damn fine hacker. How many of us could engineer an entire production-quality operating system kernel from scratch? But Linux didn't represent any awesome conceptual leap forward. Linus is not (or at least, not yet) an innovative genius of design in the way that, say, Richard Stallman or James Gosling (of NeWS and Java) are. Rather, Linus seems to me to be a genius of engineering and implementation, with a sixth sense for avoiding bugs and development dead-ends and a true knack for finding the minimum-effort path from point A to point B. Indeed, the whole design of Linux breathes this quality and mirrors Linus's essentially conservative and simplifying design approach.
So, if rapid releases and leveraging the Internet medium to the hilt were not accidents but integral parts of Linus's engineering-genius insight into the minimum-effort path, what was he maximizing? What was he cranking out of the machinery?
Put that way, the question answers itself. Linus was keeping his hacker/users constantly stimulated and rewarded—stimulated by the prospect of having an ego-satisfying piece of the action, rewarded by the sight of constant (even daily) improvement in their work.
Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in the code and user-base burnout if any serious bug proved intractable. Linus was behaving as though he believed something like this:
8. Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone.
Or, less formally, ``Given enough eyeballs, all bugs are shallow.'' I dub this: ``Linus's Law''.
My original formulation was that every problem ``will be transparent to somebody''. Linus demurred that the person who understands and fixes the problem is not necessarily or even usually the person who first characterizes it. ``Somebody finds the problem,'' he says, ``and somebody else understands it. And I'll go on record as saying that finding it is the bigger challenge.'' That correction is important; we'll see how in the next section, when we examine the practice of debugging in more detail. But the key point is that both parts of the process (finding and fixing) tend to happen rapidly.
In Linus's Law, I think, lies the core difference underlying the cathedral-builder and bazaar styles. In the cathedral-builder view of programming, bugs and development problems are tricky, insidious, deep phenomena. It takes months of scrutiny by a dedicated few to develop confidence that you've winkled them all out. Thus the long release intervals, and the inevitable disappointment when long-awaited releases are not perfect.
In the bazaar view, on the other hand, you assume that bugs are generally shallow phenomena—or, at least, that they turn shallow pretty quickly when exposed to a thousand eager co-developers pounding on every single new release. Accordingly you release often in order to get more corrections, and as a beneficial side effect you have less to lose if an occasional botch gets out the door.
And that's it. That's enough. If ``Linus's Law'' is false, then any system as complex as the Linux kernel, being hacked over by as many hands as the that kernel was, should at some point have collapsed under the weight of unforseen bad interactions and undiscovered ``deep'' bugs. If it's true, on the other hand, it is sufficient to explain Linux's relative lack of bugginess and its continuous uptimes spanning months or even years.
Maybe it shouldn't have been such a surprise, at that. Sociologists years ago discovered that the averaged opinion of a mass of equally expert (or equally ignorant) observers is quite a bit more reliable a predictor than the opinion of a single randomly-chosen one of the observers. They called this the Delphi effect. It appears that what Linus has shown is that this applies even to debugging an operating system—that the Delphi effect can tame development complexity even at the complexity level of an OS kernel. [CV]
One special feature of the Linux situation that clearly helps along the Delphi effect is the fact that the contributors for any given project are self-selected. An early respondent pointed out that contributions are received not from a random sample, but from people who are interested enough to use the software, learn about how it works, attempt to find solutions to problems they encounter, and actually produce an apparently reasonable fix. Anyone who passes all these filters is highly likely to have something useful to contribute.
Linus's Law can be rephrased as ``Debugging is parallelizable''. Although debugging requires debuggers to communicate with some coordinating developer, it doesn't require significant coordination between debuggers. Thus it doesn't fall prey to the same quadratic complexity and management costs that make adding developers problematic.
In practice, the theoretical loss of efficiency due to duplication of work by debuggers almost never seems to be an issue in the Linux world. One effect of a ``release early and often'' policy is to minimize such duplication by propagating fed-back fixes quickly [JH].
Brooks (the author of The Mythical Man-Month) even made an off-hand observation related to this: ``The total cost of maintaining a widely used program is typically 40 percent or more of the cost of developing it. Surprisingly this cost is strongly affected by the number of users. More users find more bugs.'' [emphasis added].
More users find more bugs because adding more users adds more different ways of stressing the program. This effect is amplified when the users are co-developers. Each one approaches the task of bug characterization with a slightly different perceptual set and analytical toolkit, a different angle on the problem. The ``Delphi effect'' seems to work precisely because of this variation. In the specific context of debugging, the variation also tends to reduce duplication of effort.
So adding more beta-testers may not reduce the complexity of the current ``deepest'' bug from the developer's point of view, but it increases the probability that someone's toolkit will be matched to the problem in such a way that the bug is shallow to that person.
Linus coppers his bets, too. In case there are serious bugs, Linux kernel version are numbered in such a way that potential users can make a choice either to run the last version designated ``stable'' or to ride the cutting edge and risk bugs in order to get new features. This tactic is not yet systematically imitated by most Linux hackers, but perhaps it should be; the fact that either choice is available makes both more attractive. [HBS]
167
Maps, tilesets and scenarios / Re: BattleGlest Alpha v. 0003-008 ( 31 May 2012)
« on: 31 May 2012, 17:55:37 »
The Alpha is out for testing. it could be that some heroes aren't finished and most of them aren't balanced.
Download v.0003-008 Alpha (windows-binaries included)
7-zip Package crossplattform (require SVN HEAD of megaglest / windows build included)
Download v.0003-008 Alpha (windows-binaries included)
7-zip Package crossplattform (require SVN HEAD of megaglest / windows build included)
168
Closed bug reports / Re: Pink circles when selecting units (dev version)
« on: 25 May 2012, 20:44:20 »
You know that the mg - dev version shows the pink circles for the range (big circles) and being affected by attack-boosts (small circles), when debug mode is enabled ? (What I mean is the info: MouseXY / MouseXY cell cord / ...)
I personally think it's a great feature for developing and testing attack-boosts, but why are you playing with debug-mode enabled ?
renderer.cpp
4837 glColor4f(MAGENTA.x,MAGENTA.y,MAGENTA.z,MAGENTA.w); //here you got your pink
4848 renderSelectionCircle(currVecBoost, affectedUnit->getType()->getSize(), 1.f); //and here your cicles
I personally think it's a great feature for developing and testing attack-boosts, but why are you playing with debug-mode enabled ?
renderer.cpp
Code: [Select]
// Render Attack-boost circles
4832 if(showDebugUI == true) {
4833 //const std::pair<const SkillType *,std::vector<Unit *> > ¤tAttackBoostUnits = unit->getCurrentAttackBoostUnits();
4834 const UnitAttackBoostEffectOriginator &effect = unit->getAttackBoostOriginatorEffect();
4835
4836 if(effect.skillType->isAttackBoostEnabled() == true) {
4837 glColor4f(MAGENTA.x,MAGENTA.y,MAGENTA.z,MAGENTA.w);
4838 renderSelectionCircle(currVec, unit->getType()->getSize(), effect.skillType->getAttackBoost()->radius);
4839
4840 for(unsigned int i = 0; i < effect.currentAttackBoostUnits.size(); ++i) {
4841 // Remove attack boost upgrades from unit
4842 int findUnitId = effect.currentAttackBoostUnits[i];
4843 Unit *affectedUnit = game->getWorld()->findUnitById(findUnitId);
4844 if(affectedUnit != NULL) {
4845 Vec3f currVecBoost = affectedUnit->getCurrVectorFlat();
4846 currVecBoost.y += 0.3f;
4847
4848 renderSelectionCircle(currVecBoost, affectedUnit->getType()->getSize(), 1.f);
4849 }
4850 }
4851 }
4852 }4837 glColor4f(MAGENTA.x,MAGENTA.y,MAGENTA.z,MAGENTA.w); //here you got your pink
4848 renderSelectionCircle(currVecBoost, affectedUnit->getType()->getSize(), 1.f); //and here your cicles
169
Tools / Re: exporter/Blender 2.5 series
« on: 24 May 2012, 22:15:23 »
I got an error using 2.63 with the Blender 2.6x script (http://glestae.git.sourceforge.net/git/gitweb.cgi?p=glestae/glestae;a=blob_plain;f=source/glexemel/g3d_support.py;hb=HEAD)
Code: [Select]
G3DSaver(self.filepath, context, self)
File "C:\Users\User\AppData\Roaming\Blender Foundation\Blender\2.63\scripts\ad
dons\source_glexemel_g3d_support.py", line 534, in G3DSaver
for face in mesh.faces:
AttributeError: 'Mesh' object has no attribute 'faces'
Now Exporting File: C:\Glest-mods\untitled.g3d
Traceback (most recent call last):
File "C:\Users\User\AppData\Roaming\Blender Foundation\Blender\2.63\scripts\ad
dons\source_glexemel_g3d_support.py", line 683, in execute
G3DSaver(self.filepath, context, self)
File "C:\Users\User\AppData\Roaming\Blender Foundation\Blender\2.63\scripts\ad
dons\source_glexemel_g3d_support.py", line 534, in G3DSaver
for face in mesh.faces:
AttributeError: 'Mesh' object has no attribute 'faces'
170
Maps, tilesets and scenarios / Re: BattleGlest Alpha v. 0003-003 ( 07 May 2012)
« on: 24 May 2012, 18:46:16 »
The Alpha is out for testing. it could be that some heroes aren't finished and most of them aren't balanced. Last Version with the testing unit 'Arbol_Alma'.
Download v.0003-003 Alpha (windows-binaries included)
7-zip Package crossplattform (require SVN HEAD of megaglest / windows build included)
Download v.0003-003 Alpha (windows-binaries included)
7-zip Package crossplattform (require SVN HEAD of megaglest / windows build included)
171
Tools / Re: Heightmap Exporter/Import (for gbm / mgm)
« on: 23 May 2012, 22:39:47 »Can you make the source code available just in case you or your webserver vanish at some point?
of course:
index.php
Code: [Select]
<?php
if(!is_uploaded_file($_FILES['map']['tmp_name'])){
echo('<h1>Heightmap Exporter/Importer</h1><form action="?" method="post" enctype="multipart/form-data">
Map: <input type="file" name="map" /> This is the map to Export or Import the Heightmap.<br/>
Heightmap: <input type="file" name="highmap" /> If given: Import this Heightmap, if not: Export the Heightmap.<br/>
<input type="submit" value="Export/Import" />
</form> ');
}else{
include('readFunc.php');
$handle = fopen($_FILES['map']['tmp_name'], "rb");
$contents = '';
$version = getInt32($handle);
#echo('Version: '.$version.' <br/>');
$maxPlayers = getInt32($handle);
#echo('maxPlayers: '.$maxPlayers.' <br/>');
$width = getInt32($handle);
#echo('width: '.$width.' <br/>');
$height = getInt32($handle);
#echo('height: '.$height.' <br/>');
$altFactor = getInt32($handle);
#echo('altFactor: '.$altFactor.' <br/>');
$waterLevel = getInt32($handle);
#echo('waterLevel: '.$waterLevel.' <br/>');
$titel = getString($handle,128);
#echo('title: '.$titel.' <br/>');
$autor = getString($handle,128);
#echo('author: '.$autor.' <br/>');
if($version <= 1){
$description = getString($handle,256);
}else{
$description = getString($handle,128);
$magic = getInt32($handle);
$meta = getString($handle,124);
}
#echo('description: '.$description .' <br/>');
$i = 0;
while ($i < $maxPlayers) {
$startLocation[$i] = array(getInt32($handle),getInt32($handle));
#echo('<b>StartLocation Player '.$i .':</b> ('.$startLocation[$i][0].','.$startLocation[$i][1].')<br/>');
$i++;
}
$i = 0;
while ($i < $width * $height) {
$map[($i % $width)][(floor($i / $width))]['h'] = getFloat($handle);
$i++;
}
$i = 0;
while ($i < $width * $height) {
$map[($i % $width)][(floor($i / $width))]['s'] = getInt8($handle);
$i++;
}
$i = 0;
while ($i < $width * $height) {
$map[($i % $width)][(floor($i / $width))]['o'] = getInt8($handle);
$i++;
}
fclose($handle);
$faktor = 1;
$im = imagecreatetruecolor(($width)*$faktor, ($height)*$faktor);
$color = imagecolorallocatealpha($im, 255 ,255, 255,0);
imagefilledrectangle($im, 0, 0, $width*$faktor ,$height*$faktor, $color);
$i = 0;
while ($i < ($width) * ($height)) {
$co = $map[($i % $width)][(floor($i / $width))]['h'] / 20 * 255;
$color = imagecolorallocatealpha($im, $co ,$co, $co, 0);
imagefilledrectangle($im, ($i % $width)*$faktor, (floor($i / $width))*$faktor, ($i % $width+1)*$faktor-1,(floor($i / $width)+1)*$faktor-1, $color);
#echo('<b>Cell ('.($i % $width).','.(floor($i / $width)).')</b><br/><pre>');
#echo(' Height: '.$map[($i % $width)][(floor($i / $width))]['h'].' <br/>');
#echo(' Surface type: '.$map[($i % $width)][(floor($i / $width))]['s'].' <br/>');
#echo(' Object: '.$map[($i % $width)][(floor($i / $width))]['o'].' <br/>');
##echo(' Resource: '.getInt8($handle).' <br/>');
#echo('</pre>');
$i++;
}
if(is_uploaded_file($_FILES['highmap']['tmp_name']) ){
imagedestroy($im);
$im = imagecreatefrompng($_FILES['highmap']['tmp_name']);
$i = 0;
while ($i < ($width) * ($height)) {
$col = imagecolorsforindex ($im,imagecolorat($im, ($i % $width)*$faktor,(floor($i / $width))*$faktor));
$map[($i % $width)][(floor($i / $width))]['h'] = $col['red'] / 255 * 20;
#$color = imagecolorallocatealpha($im, 0 ,0, 0, / 20 * 127);
#imagefilledrectangle($im, ($i % $width)*$faktor, (floor($i / $width))*$faktor, ($i % $width+1)*$faktor-1,(floor($i / $width)+1)*$faktor-1, $color);
$i++;
}
$tmpfname = tempnam("/tmp", "map_");
$handle = fopen($tmpfname, "wb");
writeInt32($handle,$version);
writeInt32($handle,$maxPlayers);
writeInt32($handle,$width);
writeInt32($handle,$height);
writeInt32($handle,$altFactor);
writeInt32($handle,$waterLevel);
writeString($handle,$titel,128);
writeString($handle,$autor,128);
if($version <= 1){
writeString($handle,$description,256);
}else{
writeString($handle,$description,128);
writeInt32($handle,$magic);
writeString($handle,$meta,124);
}
$i = 0;
while ($i < $maxPlayers) {
writeInt32($handle,$startLocation[$i][0]);
writeInt32($handle,$startLocation[$i][1]);
$i++;
}
$i = 0;
while ($i < $width * $height) {
writeFloat($handle,$map[($i % $width)][(floor($i / $width))]['h']);
$i++;
}
$i = 0;
while ($i < $width * $height) {
writeInt8($handle,$map[($i % $width)][(floor($i / $width))]['s']);
$i++;
}
$i = 0;
while ($i < $width * $height) {
writeInt8($handle,$map[($i % $width)][(floor($i / $width))]['o']);
$i++;
}
fclose($handle);
header('Content-Description: File Transfer');
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename='.$_FILES['map']['name']);
header('Content-Transfer-Encoding: binary');
header('Expires: 0');
header('Cache-Control: must-revalidate');
header('Pragma: public');
header('Content-Length: ' . filesize($tmpfname));
ob_clean();
flush();
readfile($tmpfname);
}else{
header('Content-type: image/png');
imagepng($im);
}
imagedestroy($im);
}
?>readFunc.phpCode: [Select]
<?php
function getInt32($handle){
$str = fread($handle, 4);
$buf = pack('a4',$str);
$res = unpack('l',$buf);
return $res[1];
}
function getInt8($handle){
$str = fread($handle,1);
$buf = pack('a',$str);
$res = unpack('c',$buf);
return $res[1];
}
function getString($handle,$length){
$str = fread($handle, $length);
$buf = pack('a'.$length,$str);
$res = unpack('a'.$length,$buf);
return $res[1];
}
function getFloat($handle){
$str = fread($handle, 4);
$buf = pack('a4',$str);
$res = unpack('f',$buf);
return $res[1];
}
function writeInt32($handle,$val){
$buf = pack('l',$val);
return fwrite($handle, $buf,4);
}
function writeInt8($handle,$val){
$buf = pack('c',$val);
return fwrite($handle, $buf,1);
}
function writeFloat($handle,$val){
$buf = pack('f',$val);
return fwrite($handle, $buf,4);
}
function writeString($handle,$val,$length){
$buf = pack('a'.$length,$val);
return fwrite($handle, $buf,$length);
}
?>
172
Tools / Heightmap Exporter/Import (for gbm / mgm)
« on: 22 May 2012, 17:41:59 »
I developed a simple Heightmap Exporter/Importer. Supports gbm and mgm maps and png heightmaps.
Old Version:
http://www.muwum-lexicons.de/mgm/
with this tool you can get maps like this very easy:
... the Heightmap for this was:
http://muwns.eu/mgm/
Old Version:
http://www.muwum-lexicons.de/mgm/
with this tool you can get maps like this very easy:
... the Heightmap for this was:
174
Feature requests / [done] unitName(unitId)
« on: 17 May 2012, 12:27:14 »
... another try to submit useful Lua methods:
Code: [Select]
Index: source/glest_game/game/script_manager.cpp
===================================================================
--- source/glest_game/game/script_manager.cpp (revision 3330)
+++ source/glest_game/game/script_manager.cpp (working copy)
@@ -309,6 +309,7 @@
luaScript.registerFunction(setUnitPosition, "setUnitPosition");
luaScript.registerFunction(getUnitFaction, "unitFaction");
+ luaScript.registerFunction(getUnitName, "unitName");
luaScript.registerFunction(getResourceAmount, "resourceAmount");
luaScript.registerFunction(getLastCreatedUnitName, "lastCreatedUnitName");
@@ -1258,6 +1259,11 @@
ScriptManager_STREFLOP_Wrapper streflopWrapper;
return world->getUnitFactionIndex(unitId);
}
+const string ScriptManager::getUnitName(int unitId) {
+ if(SystemFlags::getSystemSettingType(SystemFlags::debugLUA).enabled) SystemFlags::OutputDebug(SystemFlags::debugLUA,"In [%s::%s Line: %d]\n",__FILE__,__FUNCTION__,__LINE__);
+ ScriptManager_STREFLOP_Wrapper streflopWrapper;
+ return world->getUnitName(unitId);
+}
int ScriptManager::getResourceAmount(const string &resourceName, int factionIndex) {
if(SystemFlags::getSystemSettingType(SystemFlags::debugLUA).enabled) SystemFlags::OutputDebug(SystemFlags::debugLUA,"In [%s::%s Line: %d]\n",__FILE__,__FUNCTION__,__LINE__);
@@ -1781,6 +1787,12 @@
luaArguments.returnInt(factionIndex);
return luaArguments.getReturnCount();
}
+int ScriptManager::getUnitName(LuaHandle* luaHandle){
+ LuaArguments luaArguments(luaHandle);
+ const string unitname = thisScriptManager->getUnitName(luaArguments.getInt(-1));
+ luaArguments.returnString(unitname);
+ return luaArguments.getReturnCount();
+}
int ScriptManager::getResourceAmount(LuaHandle* luaHandle){
LuaArguments luaArguments(luaHandle);
Index: source/glest_game/game/script_manager.h
===================================================================
--- source/glest_game/game/script_manager.h (revision 3330)
+++ source/glest_game/game/script_manager.h (working copy)
@@ -304,6 +304,7 @@
Vec2i getStartLocation(int factionIndex);
Vec2i getUnitPosition(int unitId);
int getUnitFaction(int unitId);
+ const string getUnitName(int unitId);
int getResourceAmount(const string &resourceName, int factionIndex);
const string &getLastCreatedUnitName();
int getLastCreatedUnitId();
@@ -410,6 +411,7 @@
static int getStartLocation(LuaHandle* luaHandle);
static int getUnitPosition(LuaHandle* luaHandle);
static int getUnitFaction(LuaHandle* luaHandle);
+ static int getUnitName(LuaHandle* luaHandle);
static int getResourceAmount(LuaHandle* luaHandle);
static int getLastCreatedUnitName(LuaHandle* luaHandle);
static int getLastCreatedUnitId(LuaHandle* luaHandle);
Index: source/glest_game/world/world.cpp
===================================================================
--- source/glest_game/world/world.cpp (revision 3330)
+++ source/glest_game/world/world.cpp (working copy)
@@ -1285,6 +1285,13 @@
}
return unit->getFactionIndex();
}
+const string World::getUnitName(int unitId) {
+ Unit* unit= findUnitById(unitId);
+ if(unit == NULL) {
+ throw megaglest_runtime_error("Can not find Faction unit to get position unitId = " + intToStr(unitId));
+ }
+ return unit->getFullName();
+}
int World::getUnitCount(int factionIndex) {
if(factionIndex < factions.size()) {
Index: source/glest_game/world/world.h
===================================================================
--- source/glest_game/world/world.h (revision 3330)
+++ source/glest_game/world/world.h (working copy)
@@ -248,6 +248,7 @@
void setUnitPosition(int unitId, Vec2i pos);
int getUnitFactionIndex(int unitId);
+ const string getUnitName(int unitId);
int getUnitCount(int factionIndex);
int getUnitCountOfType(int factionIndex, const string &typeName);
175
Maps, tilesets and scenarios / MG Sim (a city-building scenario)
« on: 16 May 2012, 16:47:46 »
I just stared a small project in addition to Battleglest because I'd like to play arround with some Lua features / show what is possible with mg. It will be a singleplayer scenario. You start with a family (man and his wife) and their house. Your target is to build a huge city with a great economy. BUT there are many threats like monsters, droughts and thiefs.
Features:
self-growing fields
'intelligent' units (when they have nothing to do, they do something by themself)
many beautiful models from the vBros-Pack (used under CC-BY-SA)
maybe: different difficulties
Code: [Select]
[URL=http://imageshack.us/photo/my-images/717/screen0p.jpg/][IMG]http://desmond.imageshack.us/Himg717/scaled.php?server=717&filename=screen0p.jpg&res=landing[/img][/URL]Features:
self-growing fields
'intelligent' units (when they have nothing to do, they do something by themself)
many beautiful models from the vBros-Pack (used under CC-BY-SA)
maybe: different difficulties