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.


Messages - Omega

Pages: 1 ... 5 6 7 8 [9] 10 11 12 13 ... 246
201
Bug reports / Re: Misspellings in Megapack
« on: 21 October 2013, 16:07:55 »
On a side note, note that changing file names may damage scenarios, etc, that depend on unit names. And some of these scenarios are not part of the MegaPack. The use of translations would probably be best, unless we want to create a version that is not backwards compatible.

202
Bug reports / Re: Misspellings in Megapack
« on: 20 October 2013, 02:40:24 »
Also:

Factions:


Indian:


horsefarm -> horse_farm
roundtent -> round_tent
bullfood -> bull_food
iron_advanced -> advanced_iron (strangely Norsemen get this right)

Norseman:


mistletree -> mistle_tree
Regarding units ending in "_berzerk", I feel it should either be "berserk_*" or "_berserker"

But while we're discussing name changes, I feel that the "Indian" faction is horribly named. I mean, they look nothing like Indians! Could you see Gandhi leading those bunch? They resemble natives. I feel they should be renamed to "natives". Or something else that fits them. I'd rather not name them after a specific type or tribe of native people, however. They're fantasy and do not resemble any one type well.

Tilesets:


Similarly, the desert2 tileset should be renamed to desert. From a player's perspective, the versioning is noise.

The mediterran tileset should be renamed to mediterranean. Because the creator was too lazy to Google how to spell the name right.

Somewhat relatedly, winter and winter_forest are very similar. Do we need to include both with the game?

Maps:


2rivers -> two_rivers
6isle -> six_isles
lakesway -> lakes_way (or lake_sway?)
land_of_plenty2 -> land_of_plenty
megakill3vs1 -> mega_kill_3v1
riverway2 -> riverway
showdown_3way -> showdown_threeway
team_island4 -> team_island_4v4
tropical4v4 -> tropical_4v4
tt_goldrush_v2 -> goldrush
wadi_nefud2 -> wadi_nefud

ally_resist and ally_resist_clone are odd. Similar names, similar maps. Slight differences, however. I don't see why we need both. Clone seems to be better designed. Likewise for conflict and conflict6xtreed. I feel that a compromise between those two would be best, though. The former has too few trees and the latter has too many.

The usage of numbering to indicate how players are setup is often inconsistent and can be confusing. I would personally prefer to change the metadata stored with maps so that we can include "player layout" as a field. Possibilities include "free for all", "x on x", "x on y" (where x and y are any positive integer that sum up the total number of players, eg, "4 on 4"). This information can be displayed where the map size and player count is already displayed.

Scenarios:


amazones - > amazons
amazones_light -> amazons_light

Other:


Magic's faction image is so radically different than the others. I feel consistency would look better.

203
Mods / Re: Has there been any completed for profit glest projects?
« on: 20 October 2013, 02:05:26 »
The problem is not that steam allows or doesn't allow open source games, it's that their DRM (which is required to work with steam) is not open source and thus incompatible with gpl code.
Not true. The Steamworks DRM is not Steam! The DRM is optional. Steam is the distribution network. For example, Gish is GPL licensed and available on Steam. Steam is hardly anti-open source. The upcoming Steam OS, for example, is open source, Linux based OS.

However, Steam Greenlight costs money. A one time $100 cost, to be exact. The submission fee is supposed to keep non-serious entries out. Once in Greenlight, gamers essentially vote whether or not the game belongs in Steam. If approved, the game is moved into the standard Steam library.

Presence in Steam does not stop the game from being distributed elsewhere. Nor does it change the license requirements. Steam can simply provide an alternative method of distribution, including easy setup. The downside is extra work in distribution (for new releases, anyway) and the $100 submission fee.

It is also unclear how pricing would work. While free products exist on Steam, Valve only says:

3. Who sets the price for my game on Steam?
Pricing is very title specific, and we've got a lot of data and experience to help you decide on what the best price is for your title. We'll work with you to figure out pricing.

It is unclear if it is possible to explicitly choose making the game free. Not that the game has to be free, given that there's a submission fee for Greenlight. A fee would help recuperate costs, and could even be used towards MG development. Since submission to steam does not require a change in licensing, the game remains GPL. It can and should be distributed freely from other sites. A separate Steam version would make the game visible to a very large audience of gamers (Steam has more than half of the digital gaming market). It's also an easy way to donate to MG, since it allows players to pay with their Steam wallet and any payment method that Steam accepts.

So the only real downside in my opinion is that submission fee. And that's actually kind of a big one. $100 is a lot for a small, free game. It's up to debate if Steam would even have a noticeable impact on MG.

204
Mods / Re: Has there been any completed for profit glest projects?
« on: 10 October 2013, 03:21:25 »
If you browse older posts, you see that there has been quite a few  glest based games with the plan to sell them, does anyone know if any for profit glest projects were completed? I'm just curious to see what has been done.
As far as I know, nobody has ever had any success with that business model. It's very difficult to sell a product when a completely free alternative of comparable (or better) quality is available. Glest wasn't big enough when you could get so much more if you wanted to pay.

205
(and possibly megapack might rely on this???).
Are there really any legacy uses of this? I did a quick search for all morph skills in the megapack, and the only buildings that have morph skills do not store resources. I don't believe any non-buildings store resources.

Unless there's any mods that purposely depend on this behavior, I see no reason to add a quirks mode.

206
Should I apply the changes to the wiki?
Go ahead.

207
Forum discussion / Re: New Icons.
« on: 6 October 2013, 17:47:07 »
How do we tell if there are unread posts under a section?
I merged your separate post into this. I don't understand your question, though.

208
Forum discussion / New posts icons
« on: 6 October 2013, 01:44:36 »
We recently changed the icons that show whether or not a board has new, unread posts. Previously, the icons were the "G" of the Glest logo for new posts and a greyed out version of the same for no new posts.

As you can probably see from the main page, the icons have been changed to a swordman's attack icon (the sword) for new posts and the hold position icon (the shield) for no new posts. Is it better? Or is it too unclear of the icons meanings? Should we use a different set of icons (such as the hold position icon; a flag)?

Let us know what you think!

209
Forum discussion / Re: Profile Picture?
« on: 5 October 2013, 07:20:53 »
It takes about one second to load a 1000x1000 avatar, I think it should al least tell you the max size on the profile page if it gong to have such a small limit.
Please note that this applies to your internet, but not everyone elses. However, as a PNG, a 1000 x 1000 image would likely be over 1 MB. On an 8 Mbps connection (pretty common in my area), it would take at least a second to download. In reality, internet speeds rarely hit their limit, so we can expect at *least* one second to download this image. Then there's up to 19 other user avatars on the same page. Even more, most of the time for a fairly fast connection will be in the request, not the download. For example, for my fairly fast connection, there's approximately a 150 ms delay on pretty much every request because the server "handshake" with my web browser.

While this isn't a big deal compared to the incredibly slow page loading (about two seconds for the server to create the main forum page), I don't see any real need to extend it for something as trivial as avatars.

Also the error should say:

The avatar you have selected is either larger than 100x100 or not an avatar.
It's an SMF error.

210
Forum discussion / Re: Profile Picture?
« on: 4 October 2013, 22:13:22 »
What! That should be changed!
Why? It's an avatar. It adds almost nothing but a tiny bit of personality. Don't need hundreds of massive avatars to slow down load times. Avatars are already one of the weakest links.

The maximum avatar size is currently 100 x 100.

211
I feel that interface improvements are by and far the best approach to this issue. In particular, we should adopt the drop down menus that GAE uses. The drop down menus have a scrollbar, which make selection from a large set of choices easy, and choices are atomic (you instantly pick something from a list instead of iterating through every element alphabetically).

212
Feature requests / Re: In-game Lua Console
« on: 2 October 2013, 00:59:46 »
Did you ever wrote a chat message in-game? 2nd lettrr wrong = delete almost everything :(
Oh, I didn't realize that. Presumably the left and right arrow keys should move the cursor, and the up and down arrow keys should move through the command history, like a shell terminal.

And Bethesda games usually are single player games so there is no need to enable/ disable console, but when playing against human player I don't want to loose because my opponent is typing the console faster.
In my opinion, multiplayer games should always disable the console, by default. However, because of the very valid testing purposes, it should be possible to use the console if all human players can somehow agree to it. I don't feel a command line flag is a good approach, as it would require the program to be relaunched by everyone to allow console commands. Instead, an option in the advanced settings of the host should allow the console to be enabled for multiplayer. For good measure, this option should issue an additional prompt to prevent cheating (only real use of the console for multiplayer is testing).

Honestly, though, I only ever had single player in mind. If the console is troublesome for multiplayer (eg, OOS issues), it can be completely disabled. A single player only console is still vastly more useful than no console, and I imagine most of the uses of a console will be for single player (cheats, testing, debug, etc).

213
You would need a 1024x1024 map AT LEAST for this to be at all viable. Also since late game would last so long the unit counts would be huge.

Not sure most computers could really handle something like that.
Not necessarily, especially if limits are imposed on the maximum number of units at any given time.

214
Feature requests / Re: In-game Lua Console
« on: 1 October 2013, 16:25:42 »
it sounds like a good idea, but I think it should be disabled by default and enabled via the advanced options in the create game menu and/or via start-up arguments like --lua_console=true
I don't really think it's necessary, since the console is opened with "~". A number of games (like many Bethesda games) do it this way. Opening the console should pause the game. The game is not meant to be navigated while the console is open.

215
I think this could be very possible via a scenario, and I do agree a map should be bigger at least 256. to solve the power difference each empire should spawn larger than previous empires.

I think it's an interesting idea.

Ah, yes. Lua might be able to do this already... it should have the scripting functions needed. And sure, the map needs to be big enough for this to work out well.
Well, technically, Lua can do this, but there's complications. For example, we'd have to create a new base for the enemy (or enemies) after the previous ones were defeated. The problem is that the player may already have units located where we'd spawn the new base, which looks unusual.

There's also the problem of resources, since Lua does not allow resources to be changed (well, you can give actual resources, but you can't place them on the map).

In order to ensure that the enemy scales well, you'd need to have handlers on every unit creation and death, so that you can count the number of units the player has, and size the enemy bases appropriately.

216
Feature requests / Re: archers shooting own units
« on: 27 September 2013, 23:35:12 »
1. Redirecting Attacks is a big no no.
Imagine a arrow flying around like a heat seeking missile?. no.
Redirection would obviously have to be an option in the projectile XML. It wouldn't make sense for an arrow, but might for magic. GAE had a tracking option that allowed projectiles to change course for moving targets. Tracking projectiles could still be avoided by very fast units (limited amount of tracking).

217
Mods / Re: Questions about modelling?
« on: 27 September 2013, 15:16:30 »
Weird. Sourceforge has really started sucking lately. This link should work: http://sourceforge.net/p/glestae/glestae/ci/master/tree/source/glexemel/g3d_support.py

And yes, tutorials are MANDATORY. Blender is complex, yo.

218
Anyway tutorials are on the wiki? And I noticed Mg models have some special extension?
Not yet. Pretty much just straightforward documentation. I'd like to expand it with tutorials, but there's a lot going on. We're also planning on moving the Wiki to a new domain, but I haven't had time to finish that, yet. Soon!

219
So here is the question , why it can only be built by one worker{one worker may build it at the time?}
You need to add it to the list of repairable buildings in the worker XML.

When multiple units build a building, what's actually happening is one unit is using the build skill and the rest are repairing it. Since buildings are considered constructed once they reach full health, that works. Also interesting is how repair skills tend to be slower than build skills, so the first worker is the most important.

220
GAE does this no? Are you sure MG doesn't already have this?
I don't have my computer setup to compile the tools, but as of the latest stable release, it doesn't appear to exist.

221
When closing the map editor, it prompts to save the file, which is great. However, it also prompts if you have no changed the default map in any way. This is akin to a text editor prompting you to save when you haven't typed any text (and most modern text editors will not prompt for an empty file).

The method of detecting if the file has been changed varies. One method would be to compare the file to an empty map. If it's a match, the map cannot have been edited. Another method would be to set a flag the moment the user makes a change to the map. The latter would be faster, but if the user undos their change, the map is still recognized as changed, so the former method would be more accurate (if you type in a text editor, then remove the text, it won't prompt you to save, since saving an empty file is rarely desirable).

222
I believe it would be beneficial for map editing and scenario creation if the map editor displayed the coordinates for the tile the mouse is currently hovering over in the status bar in the window. This feature is seen in most modern image editors.

223
One problem I have with maps is that everything is a large square tile. It makes curved roads and cliffs look terrible. It's difficult to make a change without impacting a huge amount of the engine, though. Thus, I propose that we allow the square tiles to be subdivided into triangles as per the picture below (which illustrates the issue with the square tiles and how triangles help):



To prevent this change from messing with too much of the engine (path finder, object placement, etc), it should apply only to surfaces and heights. The surfaces is obvious enough: we can create paths that are not straight and don't look like crap (as the above image illustrates). In the map editor, when you zoom in enough, the editor should subdivide the tiles into triangles, which can be "painted" in the same manner as we currently select the square tiles. It may also be ideal to implement a "show grid" option, which would show a grid overlay with the triangles when zoomed in sufficiently.

This, of course, requires a change to the map format.

The effects are similar for changing the heights. We raise or lower the height of a triangle instead of a whole tile. Objects placed on the tile will be placed at the height of the lowest triangle (to prevent floating objects). This allows us to create rivers, islands, etc that don't have horridly jagged edges.

I believe this change will make the maps look more realistic for dedicated map makers. If the map editor is further tweaked to automatically paint with triangles based on the brush size, it may be easy to make maps with smooth edges without a large amount of editing. This change is purely for aesthetic reasons and does not impact gameplay.

224
It's a bit disappointing that this thread has not attracted any dev comments of any kind.

Anyway, a side note that this does not change the map format. It only affects the game engine. The maps folder will be structured like how scenarios are, with each map in a folder. The mgm/gbm file must have the same name as this folder, as should the XML file that defines the "extension" of the map (the "scenario" portion, if you will). Thus, the map editor requires zero changes.

As an example of what the XML file might look like:

Code: [Select]
<map>
<players>
<!-- One neutral faction of animals inhabits the map -->
<player faction="glestimals" aggressiveness="3" team="9"/>
</players>
<particle-files>
<!-- Load a particle system file -->
<particle-file name="towerParticles" file="tower_particles.xml" />
</particle-files>
<models>
<!-- A tower model is placed in the center of the 128 x 128 map (at coordinates {64, 64}) -->
<model name="darkTower" file="dark_tower.g3d" x="64" y="64" size="10" active="true">
<!-- The model uses the previously loaded particle system -->
<particle value="towerParticles" />
</model>
</models>
<regions>
<region name="nearTower">
<!-- The center of the tower is located at {64, 64}, so this region is a 20 x 20
     rectangle that surrounds this tower -->
<rectangle-selection x1="54" y1="54" x2="74" y2="74" />
</region>
</regions>
<!-- Lua code starts here -->
<startup>
insideTowerRegionTimer = startTimerEvent() -- Start a timer to check if units are inside the tower region
createUnit('bear', 9, {50, 70}) -- Places a bear from the glestimals faction near the tower (coordinates {50, 70})
</startup>
<timerTriggerEvent>
-- Check if the event that triggered the timer is the same as the timer we created
if triggeredTimerEventId() == insideTowerRegionTimer  then
-- Check if at least 2 seconds have elapsed
if timerEventSecondsElapsed(triggeredTimerEventId()) >= 2 then
unitsNearTower = getUnitsInRegion('nearTower') -- Get units in region
-- Use a for loop to iterate through all units in that array
for i, v in ipairs(unitsNearTower) do
-- Change the stats for the unit selected by the iterator (stored in "v") by
-- increasing its attack by 20 points for 5 seconds
changeUnitStats(v, 'attack', 20, 5)
end
resetTimerEvent(triggeredTimerEventId()) -- Reset the timer
end
end
</timerTriggerEvent>
</map>

To summarize what happens above, we tell the engine that we have one neutral faction (glestimals) and we load in a particle file for use later. We do this because the engine must know what it needs to load when starting a game.

We then load in a model and place it in the center of this map (assuming the map is 128 x 128). The tower is active, so it is displayed by default. Since no cell map is specified, it defaults to non-walkable for all cells, which is fine for a square tower (although a round tower would want to use a cell map). We then apply the previously loaded particles to this tower. Maybe the particles are some beam shooting up from the tower, making it look all dramatic looking (kinda like this).

Finally, we draw a region around the tower. The tower is a 10 x 10 square, and the region is the 20 x 20 square around that, meaning it's the walkable area up to (approximately) 5 cells from the tower. We'll use this area so we can boost the stats of units inside it. The picture to the left shows the placement in detail. Note the placement isn't exact, since models are placed based on the center of the model, and there's no tile that's *exactly* in the center of a 10 x 10 model, so we use one shifted up and left.

Now the startup element should look familiar, since it functions the same way as in scenarios. It creates a timer, which we'll use to check for units inside the region. We also create a single bear from the glestimal faction and place it near the tower.

The timer trigger element is also the same as in scenarios, and should look familiar to those who've used timers in scenarios. It first checks if the triggered timer is the correct one (not actually needed since we only have one timer), then checks if enough time has passed (in this case, it triggers in intervals of two seconds). When the timer triggers, it gets the array of units in the region and iterates through this array, boosting the stats of all those units. Thus, all units near the tower get a small boost to their attack. Finally, we reset the timer, since this is a reoccuring event.

Hopefully this example sheds more light on the potential of this proposal.

225
Mods / Re: Modelling infantry
« on: 1 September 2013, 04:06:13 »
We all animate with Blender here, I have no idea how you can animate in max and get that to Glest...
At one point of time, we had an export script for 3DS Max, but it has since fallen in disuse and no longer functions with the more recent versions of the program. The G3D model format, however, is well defined. The community would certainly welcome the creation of an up-to-date export script if anyone has the relevant experience to create one.

The crucial flaw is that 3DS Max is not free software, and nobody wants to pay to develop for software they don't even use.

Pages: 1 ... 5 6 7 8 [9] 10 11 12 13 ... 246