Messages

26

Feature requests / Re: Randomly generated maps

« on: 2 October 2016, 22:13:17 »

Procedural generation of maps is certainly possible. Mostly nobody has simply bothered to implement it, yet. But it's more complicated than you suggest. Generating a randomized heightmap is easy. The harder part is placing objects in a way that is playable, looks good, and doesn't follow simple patterns (because simple patterns are boring). Like, you could easily just make every map follow either an "X" or square shaped path between player bases or something. But that's predictable and boring. Some other games have it a lot easier because it's perfectly acceptable to not be 100% balanced. Eg, Civ V is well known for mostly using procedurally generated maps. But Civ V doesn't mind if one player is isolated on an island surrounded by water (since they have navies). Civ V doesn't care if you have a mountain range making it crazy hard for you to be attacked. Frankly, maps don't care too much about balance since the style of the game gives lots of ways to recover from that. And of course, if you want to see how much work can be involved in procedural generation, perhaps take a look at the various map scripts for Civ V.  It's not that easy to do well. I've seen some scripts that are like 5000 lines of Lua code (and that's with the infrastructure to place stuff already being in place!).

MegaGlest? Not so much. Map balance is much more important. That limits what procedural generation can do in an interesting way. The main "easy" ways to come up with procedurally generated maps in my mind would kinda be boring. It also doesn't help that the pathfinding can get confused if you do anything too weird (and hence why human made maps need to be tested when you try anything weird).

My personal recommendation is just to have lots of maps and tilesets installed. Using a random map with a random tileset and randomized starting points and you've got some serious degree of variance going on.

27

Feature requests / Re: GUI based unit editor

« on: 2 October 2016, 22:02:31 »

Gosh, something like this totally came up before. Heck, I think even tried my hand at some rudimentary variant? And others did similar? But it's been a while and I don't remember much. I don't have any of my early work, anyway. Nothing more than about 3 years old, when I started throwing everything in my GitHub.

Anyway, I don't actually support the idea anymore. I feel like it's very unnecessary. The main issue is that making a mod is a somewhat technical thing. Yet, it's really not that complex. Put bluntly, I feel like if you can't figure out how to work with the very straightforward and reasonably well documented XML files (documented on the wiki, that is), then you're not really ready or good enough to make a mod. And I really don't care about users who just wanna edit small things. It's really not that hard to figure out how to give something more health or similar. Plus, they need a certain level of technical skill or they'll break stuff (eg, multiplayer CRC checks).

And if you want anything novel on the graphical front, that's the real technical bottleneck.

At any rate, I don't see this as adding value for anyone with good tech skills. And anyone who really needs it probably would be limited in what value they could add, anyway...

28

Feature requests / Re: Human-only simulation

« on: 18 July 2016, 07:08:45 »

I mean, the normal way to do this is just to use two computers and create a multiplayer game between them. Controls are a bit different, but arguably smoother since the screen isn't constantly jerking back and forth between teams.

However, I don't see this as a particularly useful feature or one that's gonna be in high demand. This just isn't the kind of game you play against yourself.

29

Feature requests / Re: [8]Case sensitivity for windows too

« on: 3 June 2016, 05:56:25 »

Definitely possible, since Windows preserves case. Could check that the path you retrieved matches the expected case.

There is the possibly ugly issue of having multiple files with only case differences that could not be opened on Windows at all since they'd conflict on the file system, but there's no clean way of handling that, anyway (and I'd consider it a terrible idea to have multiple files with only case differences).

30

MegaGlest / Re: Megaglest current situation

« on: 8 May 2016, 05:21:19 »

I'm afraid I haven't played MG for a very long time. Largely lost the desire to. I don't think RTSes are quite my ideal genre. To a large degree, my interest in the community has always been a developing/modding one. These days I get more than my coding fill from work and can't even bring myself to do personal projects as much as I'd like. While I tried my hand at developing for MG in the past, it's just too messy of a codebase for me to work up the bother. I'm a neatfreak where code quality is concerned. As for modding, it's just too time consuming and my interests are largely in programming and not in creation of models or anything.

31

Maps, tilesets and scenarios / Re: Scenario - Grandezza Peril

« on: 8 May 2016, 05:17:07 »

@MuwuM, the Lua code sections should indeed be using Lua comments. There's actually kinda some weirdness about having a scripting language inside XML. JS has similar issues when embedded in HTML. But at any rate, the correct thing to do is use the commenting format of the scripting language. It'll typically never have any issues. At any rate, all the other scenarios do it this way.

While avoiding magic numbers is a good idea, it's not really a problem for the team numbers in most cases. Anyone with experience in Lua scripting for MG (or who has the documentation on hand) will obviously know what these numbers mean. Nothing new there. Certainly MG scenarios aren't the pinnacle of software engineering, though. Plenty of times when it's unavoidable, anyway (eg, to give some units to every player).

32

Forum discussion / Re: Forum avatars reset

« on: 9 April 2016, 03:43:25 »

I highly recommend you use Imgur to host your images. It's been consistently the most dependable, in my experience.

33

Feature requests / Re: What if MG added a "live programming" feature?

« on: 14 February 2016, 07:27:46 »

This is best done with a Lua console. GAE had such a feature implemented, which goes to show the effectiveness of such approach. It would let you do all the things you listed and more. Although it's a bit more verbose and there never was a good way to select units programmatically (which probably wouldn't be hard to extend -- IIRC, all that would be needed would be a way to figure out the IDs of units).

34

Tools / Re: Heightmap Exporter/Import (for gbm / mgm)

« on: 11 January 2016, 19:23:33 »

e.g. you could use your WebRTC knowledge to add an feature to collaborativly edit maps 

You probably shouldn't. WebRTC uses UDP. Perfectly suitable to lose some audio or video data (since being real time is what's important), but for collaborative editing, we really wouldn't want a user's change to go ignored (and order is likely important). Also, WebRTC only has native support on Firefox and Chrome for now. My work has to use ActiveX and Java plugins to get IE and Safari working (and that's a non-free third party solution).

A simple web sockets solution to communication is likely more ideal (I've been using SignalR for the signalling channel of said WebRTC application -- it's a nice RPC library for persistent connections, either via long polling or websockets).

35

Bug reports / Re: ini-path argument using relative path, non-critical

« on: 11 January 2016, 19:12:22 »

Oh because just because? "Good" beginning, no comment.

Because pretty much every place that accepts relative paths will also accept an absolute path. There's no reason to avoid the norms of most software. In fact, I've never used a program that accepts relative paths and does not accept absolute paths.

- it work for you also when you will move whole main game directory to the other place,

Obviously you wouldn't use an absolute path then! I'm not here to debate the merits of relative paths. I'm a programmer; I know full well their uses. But I also know that absolute paths do occassionally have valid purposes.

- it may work for other players in the same way when you need this (when you need, so absolute paths in other cases are allowed),

But again, that doesn't matter because typically one wouldn't share just any command line argument. Command line arguments are largely to allow you to tweak how the program runs and may not be relevant to others. In this particular case, you simply wouldn't share the command line argument. But all that said, absolute paths can absolutely work for other people. Surely you've executed things like vim ~/.vimrc? I can share that around and anyone who has vim on a *nix system can use it.

- it is easy to use, proposition of "%%APPDATA%%" is pitiful, how to document usage of this and where? if in the --help then most likely it will be too long, if not in the --help then it is not enough easy accessible,

I used %%APPDATA%% as an example of MG replacing variables with absolute paths to show that this is clearly unexpected behavior (since you can't use said variables if only relative paths are allowed). The poor documentation of said variables is off topic. Code tells a lot about the intentions. However, a better example of something that users would actually do is ~/megaglest_shit or %appdata%/customMG. Both of those include variables that are swapped by the OS before the data is even sent to the application (by the shell).

- it will work on every OS and every command line env cause MG is cross platform, using characters like "%" in the command line is just asking for trouble.

Again, there's no need for command line arguments to be cross platform. I mean, heck, Windows and OS X are case insensitive, so you can already create command line arguments that are Windows only. To lazy to check, but pretty sure you'd be able to use backslashes in the path, too. Windows allows that for relative paths, but for Linux, it's just a regular character in a filename.

What magic?  On which OS? (cross-platform!) This one which your variable seems to suggests, where even simple usage of %programfiles% may return unexpected results? or this magic related with sending personal data to mICROSOFT? 
When you wanna cross-platform support then you need to avoid as much "unexpected magic" as it is possible.

By "magic", I was referring to the fact that all modern OSes retain a working directory for which relative paths are based against. Usually this is the working directory of the terminal which you use to launch MG, but shortcuts can usually specify their own working directory. And I dunno why you're bringing up sending personal data to Microsoft. That seems very off topic here and makes me question if you're just trolling me here.

Some months back there was a bug related with paths and every "git user" had to use for ~ 1-2 days --ini-path=./ --data-path=./ to even launch game (relative? relative, simple? simple) and even now our headless servers 3.11.1 have relative path to ini in the configuration.

I'm not sure why you think the fact that a bunch of people use relative paths is a good reason not to support absolute paths.

Did you ever tried to help someone or write a documentation related with absolute paths?
Try to write something like this: "if ... then Please use --ini-path=<path_to_the_file>" and you have a guarantee to get some % responses like this does not work, I see an error: '<path_to_the_file> not found' and those will be from just normal avg users.

Yes I have. I help with the annual Unix Bootcamp at my university, which caters to people who have never used a terminal in their life. But the reality is that anyone who's dumb enough to make the mistake you showed is not someone who should be using command line arguments. They're not exactly hard to use, but require the ability to read and understand what the arguments are. When creating documentation for intelligent people, I've never had issues with simply using the placeholder <path> and stating whether or not it must be absolute (there's a small number of cases where relative paths would be too confusing due to the lack of an obvious path which they'd be relative from).

At any rate, here's a recent example of why you'd use absolute paths. It's a per user thing and Tomreyn is clearly banking on the reader having the intelligence to change the paths to whatever value they are using. You could use relative paths here, but it's more confusing because you'd have to figure out the point that we're relative to. Absolute paths are often superior for personal usage because they remove that source of confusion -- you always know where the path is pointing.

In the *nix community, absolute paths are used all the flipping time, usually relative to the home directory (using the nifty ~ variable -- the Windows equivalent is a bit more verbose: %userprofile%, but PowerShell allows the use of ~).

36

MegaGlest / Re: MegaGlest nominated for Open Source Game of the Year at LQ

« on: 11 January 2016, 19:02:10 »

Please don't use link shorteners. They remove the ability for the user to easily check where the link is going and naturally make the link suspicious. Instead, use the full link: http://www.linuxquestions.org/questions/2015-linuxquestions-org-members-choice-awards-117/welcome-to-the-2015-linuxquestions-org-members-choice-awards-4175562701/page2.html#post5475019

Or if length is a concern, use the syntax

Code: [Select]

[url=http://example.com]My text[/url] which would allow us to create something like Source.

37

MegaGlest / Re: Debian 8 snapshot 32-bit

« on: 8 January 2016, 07:19:53 »

I think the original quote may be mine (I can't seem to find it using the forum and wiki search, though). I think this statement made sense when we had no automatically built snapshots, yet, or when those do not work on some system.

It is indeed your comment, from 2012 (PS: I found the quote using Google search -- most websites have shoddy weak search systems; when I searched the quote, I got "Search string must be less than %1$d characters long." ).

EDIT: I just noticed that this post also contains that quote. Since it's a sticky, you probably want to update that one.

38

Off topic / Re: Anyone know were i can rent cheap VPS server?

« on: 8 January 2016, 07:02:42 »

Oh, there's plenty. I use DigitalOcean for my cheapo VPS. $5 a month for a not-great-but-not-horrible machine. Never tried it with MG, though, and the memory and CPU of the lowest tier are probably too low for MG. The $10/mo tier might be enough, but it's hard to say if the processing power is sufficient. The MG documentation strongly recommends multi-core and I can't say just how important that is (CPUs are really hard to put to a number, and VPSes especially so -- I mean, "1 core" doesn't exactly mean much).

You can get cheaper, though. I mostly went with DigitalOcean due to free credit from the GitHub student package, and I really liked their documentation for setting up a variety of common software (eg, to setup Postgres).

I've heard a lot about Amazon EC2, but never used it and can't say for sure if MG would work there. Don't see why it wouldn't. I have more experience with Microsoft Azure (can't say if I'd recommend that; had plenty of frustration in working with the poorly documented management API -- but you wouldn't need to use that, nor would most people, I would think). Anyway, I can't tell exactly what the EC2 instance is compared to Azure. MG provided wouldn't run in an Azure App (they're too limited with the control provided), and thus would need an Azure VM (which is a VPS).

39

Tools / Re: Heightmap Exporter/Import (for gbm / mgm)

« on: 8 January 2016, 06:50:03 »

And it could lay the foundation to a HTML/Javascript map editor. If anyone is willing to implement this I'll sure be happy to add an upload backend.

Might be interesting for a personal project. I'm not sure if it's be worthwhile, though. What could it do that a desktop version couldn't? Mostly I'd think it'd be more limited, since we wouldn't be able to easily run MG to preview the map and there's performance concerns for any kind of larger operations (eg, one feature that comes to mind is treating the height levels of the map as an image and gaussian bluring this to get softer slopes). Probably not an issue at map making sizes, though, and I've done some pretty intensive stuff with JS (my current work involves WebRTC -- sharing video, audio, and screen capture).

I'm not sure what could be done better in a JS version that a desktop version.

40

MegaGlest / Re: MegaGlest nominated for Open Source Game of the Year at LQ

« on: 8 January 2016, 06:39:04 »

What a weird list...  It seems like a GotY poll would include recent/current games.  FOSS projects never really die exactly, but I think most of these games are in a pretty deep coma.

Probably not enough Linux-compatible, open source games to have a list, otherwise . It's not a very competitive market.

41

Bug reports / Re: ini-path argument using relative path, non-critical

« on: 8 January 2016, 06:36:36 »

Eh, there's no reason to be constrained to relative paths. That makes no sense. It's a command line flag, so it doesn't matter if it works for other people.

This is probably due to concatenating a path somewhere instead of letting the OS work its magic. While I couldn't find the code where this occurs in a timely fashion (and can't be bothered booting up a debugger this late at night), I did note that the INI path applies what MG refers to as "tags" but would more properly be pictured as the environmental variables of a shell. Eg, you can do %%APPDATA%%/foo and MG will replace that with the appropriate path. Those only make sense for absolute paths.

Therefore, the current functionality seems to be unintended.

42

MegaGlest / Re: cmd arg to change default config directory

« on: 8 January 2016, 05:48:25 »

Hmm, I wonder why these paths can't be the same. Nothing obvious comes to mind. Given that softcoder implemented this change, he can probably explain that. These paths probably need to be better explained. The wiki is very tautological.  "--data-path=x sets the game data path to x." Very helpful. I've managed to forget the difference, myself, and can't be bothered doing anything more than a git blame  .

43

Feature requests / Re: harvest buildings for resources

« on: 2 January 2016, 01:34:55 »

Any particular reason to harvest the building instead of just instantly deleting it, as most games would implement such?

44

Closed bug reports / Re: "Load Game" and "Game Mods" buttons overlap on Main Menu

« on: 2 January 2016, 01:31:00 »

....man, how do you attach a pic in this thing?

Use an image host like Imgur.

45

Maps, tilesets and scenarios / Re: Licnese discussion (NC and not NC )

« on: 7 December 2015, 01:03:13 »

You misunderstand the granularity of which I use "work". You seem to be thinking of saying "this mod is CC-BY-SA". But I'm thinking at a lower level, such as "this mod contains models that are CC-BY-SA and other models that are CC-BY-NC-SA".

46

Off topic / Re: MMorpg project

« on: 4 December 2015, 23:59:55 »

To be entirely blunt, I'd be cautious about pursuing this idea. People wanting to develop MMOs are usually treated as a joke among programmers because of the severe amount of work that an MMO requires. Games alone are a lot of work, but MMOs are far, far worse due to the multiplayer aspect, dealing with scaling, and preventing cheating.

Your code does not work, so I cannot say if you're at the stage where you can realistically do an MMO. Have you created a single player game first? That's a good way to test skill. Art is the easy part; code is where all the work is (well, it's not truly easy, but you can get away with crappy art, but crappy code won't work at all).

Your platform raises some questions. The client side is entirely doable in JS, but the server side is far iffier. And you need a server side. I mean, in theory, you could use WebRTC to create an entirely P2P MMO. You'd still need a signalling channel, but in theory, you could get rid of that by swapping all the necessary signalling information (offer, answer, ICE candidates) over a medium like email, IRC, etc. I guess you can tell that I've been using WebRTC a lot lately. But that's not scaleable, anyway, so a central server is a necessity for any serious game. And this central server has to do a LOT of work. The only effective way to stop cheating is to have the server (under your control) do most of the work, with clients mostly being treated as mostly just GUIs. So the server needs optimal performance, for which JS is a poor choice.

Not trying to discourage you from doing fun programming side projects, but if you don't know what you're doing (and honestly, this is one of those "if you have to ask such vague questions, you're not ready" cases), things will rarely work out. So you may end up wasting your time that could be better put towards, say, making a single player game or some other form of stepping stone. As a skill testing trial, I would expect that you'd be able to make at least a single player game and something like a multi-player chess game (etc) where the server does all the work before you try an MMO.

For a more comical approach to my point see this thread about someone trying to make a 100% dragon MMO.

47

Maps, tilesets and scenarios / License discussion (NC and not NC )

« on: 4 December 2015, 23:45:38 »

If someone builds a new mod using one of your models he cannot use a model from MG iitself or another mod because this results in a license conflict.
So making a new tileset using tree models from your mod and tree models from original MG will not be allowed.

This is not true. You can license specific things under different licenses. So you can have some models under CC-BY-SA and others under CC-BY-NC-SA. You simply have to specify this somewhere (eg, in a "LICENSE" file). What you can't do is just claim the whole mod is one license when there's actually mixed assets. Although you can do that if the licenses are compatible, but judging compatibility is difficult. For example, the GPL is a CC-BY-SA compatible license. But to make things even more confusing, CC-BY-SA is NOT a GPL compatible license (ie, it's one way). So best to never try and relicense. Just keep track of the individual licenses and ensure that modifications to the media follow the license.

48

MegaGlest / Re: Hello Topic

« on: 4 December 2015, 23:38:38 »

That was spam, Alket. You'd notice that it was their only post, they didn't mention anything at all related to this site, and they immediately pushed links to soundcloud and youtube.

49

MegaGlest / Re: docs.megaglest.org's Special Pages have 502 error

« on: 1 September 2015, 23:55:51 »

The top square links issue is very strange. I think it's a Firefox bug? It works in Chrome and examining the style in Firefox tells me that it should be working fine (yet obviously doesn't). But I can't reproduce elsewhere...

The logo image somehow disappeared. I don't have the file, so I just resized the logo from elsewhere and reuploaded.

50

MegaGlest / Re: docs.megaglest.org's Special Pages have 502 error

« on: 19 July 2015, 05:32:32 »

Thanks for pointing this out. What an unusual error.

Tom, any ideas on this? I didn't see anything in the logs I checked that seemed to be related to this (as an aside, there seems to be some chron job that is seg faulting every minute or so). It doesn't seem to be an issue with MediaWiki. Has anything changed related to server configuration semi-recently (I guess it could have happened a while ago, since I haven't uploaded an image for a long time).

It's not every special page, but it's not just Special:Upload, either. I also noticed that Special:SpecialPages gets the same error, which is rather unusual, since there isn't really anything that interesting going on on those pages (compared to the regular pages).