plugging up free cheating.

Development directions, tasks, and features being actively implemented or pursued by the development team.
Locked
parkel
Hunter
Hunter
Posts: 73
Joined: Fri Jun 12, 2009 2:22 pm

Re: plugging up free cheating.

Post by parkel »

compressing the file might be a good idea.
BUT.
what about gamers who are desperate and who don't know how to code?
i still stand my ground on not to prevent hacking in an open source game.

now: look at this situation -

you are stuck in an asteroid fighter base - there's a bug where u cant undock and get stuck inside the asteroid base.
you need (want) to play the game... and you are extremely desperate.
one thing to do: hack the game file(s)

so.. if you make it hard to open.. it would be quite difficult for people to actually hack themselves out from this mess.
i'm sure no one here wants to restart a new game once you have gotten a lot and advanced a lot as well?
  • Derivative + pArKeL + a bunch of luddites = ?

    :D
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: plugging up free cheating.

Post by safemode »

Opening some program you have to search for and download vs opening anything that can edit a text file is harder. So it accomplishes the task of removing a huge amount of casual cheating simply by forcing a cheater to have to take the step to download the editor.

Likewise, I'm not concerned that cheating will occur, nor am i concerned with the method that the cheating is done. It's an open source game where most of the logic in the game is in python files. Plain text that is easily editable to do whatever you want in the game. That's not the issue here.

The issue is exactly what the last person brought up. You're encountering a bug, and instead of filing a report, tossing up a forum thread with the offending savegame file etc, and having the bug fixed, the casual player with access to an unbelievably easy method of "correcting" their problem goes the path of least resistance. In this case however, that path is destructive to the project, because now that bug doesn't get filed, tested, corrected and a fix made available to all. Now we have to wait for another person and the scale of the problem is hidden by the fact that maybe 20% of the people playing encounter the bug, but 17% of them simply hack the savegame and move on, making it seem like only 3% of people are having the problem. 3% would tell us that it may be something specific to the hardware/software of those players rather than a game logic problem that would effect many more people regardless of hardware/software.

In the end, the savegame is not an appropriate or official api for modifying the game by the player so it can be changed at will whenever and however it's deemed most helpful to those developing the game. It should be of no consequence to the player what the savegame file is, it's format, or what's in it.

Part of the reason for the lack of content is the lack of people who enjoy the potential of the game having to face the reality of the state of the game. Without demand, there isn't going to be any supply. Such immediate and defacto access to cheating away most of the short comings of the game reduces demand. The other part of the reason for the lack of content is obviously being creative is a rare commodity these days.

Eventually i will have more time to get back into heavy development. While this particular topic isn't a high interest of mine, it's obvious that it's doing more harm that good by hiding the magnitude of logic issues during gameplay. I'm very much more interested in finishing the physics updates, overhauling the ai and finally implementing dynamic events (which would ride parellel to normal scripting, yet can be used to totally replace it for everything). I really really wish i had the time now to do it, life has other plans right now though.
Ed Sweetman endorses this message.
JsnMtth
Bounty Hunter
Bounty Hunter
Posts: 174
Joined: Wed May 27, 2009 6:38 am
Location: Fresno, California - United States of America
Contact:

Re: plugging up free cheating.

Post by JsnMtth »

I lzma'd my savegame file. It went from 8M to 1M.
TBeholder
Elite Venturer
Elite Venturer
Posts: 753
Joined: Sat Apr 15, 2006 2:40 am
Location: chthonic safety

Re: plugging up free cheating.

Post by TBeholder »

safemode wrote: You're encountering a bug, and instead of filing a report, tossing up a forum thread with the offending savegame file etc, and having the bug fixed, the casual player with access to an unbelievably easy method of "correcting" their problem goes the path of least resistance. In this case however, that path is destructive to the project, because now that bug doesn't get filed, tested, corrected and a fix made available to all. Now we have to wait for another person and the scale of the problem is hidden by the fact that maybe 20% of the people playing encounter the bug, but 17% of them simply hack the savegame and move on, making it seem like only 3% of people are having the problem. 3% would tell us that it may be something specific to the hardware/software of those players rather than a game logic problem that would effect many more people regardless of hardware/software.
Good point again. So, if you'll just add "file a bug report" button or something like on a very visible place, plus dialog or notification when editor is used on savegame instead of mission, probability of a report would raise, no?.. Of course if they'll use your editor. Which IMO should be part of the game (i.e. up-to-date, built upon the same version of API) and not third-side just because of issues related to data integrity.
Hmmm, it looks like problems not in cheating, but in random cheating. :)
safemode wrote: Part of the reason for the lack of content is the lack of people who enjoy the potential of the game having to face the reality of the state of the game. Without demand, there isn't going to be any supply. Such immediate and defacto access to cheating away most of the short comings of the game reduces demand. The other part of the reason for the lack of content is obviously being creative is a rare commodity these days.
Well, tastes differ. Also, you can't seriously expect tinkering with it from people other than those who going to tinker with it anyway.
"Two Eyes Good, Eleven Eyes Better." -Michele Carter
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: plugging up free cheating.

Post by safemode »

Turbo Beholder wrote:
safemode wrote: You're encountering a bug, and instead of filing a report, tossing up a forum thread with the offending savegame file etc, and having the bug fixed, the casual player with access to an unbelievably easy method of "correcting" their problem goes the path of least resistance. In this case however, that path is destructive to the project, because now that bug doesn't get filed, tested, corrected and a fix made available to all. Now we have to wait for another person and the scale of the problem is hidden by the fact that maybe 20% of the people playing encounter the bug, but 17% of them simply hack the savegame and move on, making it seem like only 3% of people are having the problem. 3% would tell us that it may be something specific to the hardware/software of those players rather than a game logic problem that would effect many more people regardless of hardware/software.
Good point again. So, if you'll just add "file a bug report" button or something like on a very visible place, plus dialog or notification when editor is used on savegame instead of mission, probability of a report would raise, no?.. Of course if they'll use your editor. Which IMO should be part of the game (i.e. up-to-date, built upon the same version of API) and not third-side just because of issues related to data integrity.
Hmmm, it looks like problems not in cheating, but in random cheating. :)
I guess that's supposed to be sarcastic. In any case, i'm bored right now so i'll bite. The idea is to make it much more enticing to use mission files to edit the game, legitimate or cheating, by reducing the ease of editing the savegame file. That's it on that level. If a glitch occurs then we want to entice them to file a report or goto the forums, rather than kludge it themselves in the savegame.

We dont care about cheating, we care about the effects that such effortless cheating has on gameplay, longterm usage, and bug fixing. And we have the ability to do something about it without modifying any type of user interface.

Well, tastes differ. Also, you can't seriously expect tinkering with it from people other than those who going to tinker with it anyway.
I would expect a fraction of the people who goto the mission files to cheat to get the urge to tinker further than simply modifying a value in the same way that many coders begin hacking on something in a particular language and it sparks an interest in it over time. In the end, whether or not it gets more people involved in the authoring of mission files is secondary. It's the intended api for that stuff, so it should be the only one used. The more it's used the better.
Ed Sweetman endorses this message.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: plugging up free cheating.

Post by Deus Siddis »

safemode wrote:Opening some program you have to search for and download vs opening anything that can edit a text file is harder. So it accomplishes the task of removing a huge amount of casual cheating simply by forcing a cheater to have to take the step to download the editor.
Alot of people have excel or calc and the later is free.
The issue is exactly what the last person brought up. You're encountering a bug, and instead of filing a report, tossing up a forum thread with the offending savegame file etc, and having the bug fixed, the casual player with access to an unbelievably easy method of "correcting" their problem goes the path of least resistance. In this case however, that path is destructive to the project, because now that bug doesn't get filed, tested, corrected and a fix made available to all. Now we have to wait for another person and the scale of the problem is hidden by the fact that maybe 20% of the people playing encounter the bug, but 17% of them simply hack the savegame and move on, making it seem like only 3% of people are having the problem. 3% would tell us that it may be something specific to the hardware/software of those players rather than a game logic problem that would effect many more people regardless of hardware/software.
That isn't really true because people don't want to have to hack around bugs over and over. Hacking around them is just a way to keep the game from getting so punishing that you quit until the next release, and thereby file no more bug reports. Like the surprise in the face ship spawning of 0.4 or the chain-reaction faction hatred of 0.5. And both of these bugs have been well reported, but their roots were/are so extensive that entire sections of code had/have to be overhauled to fix them. So torturing folks with having to deal with these while waiting for the next release will not deliver more bug reports, it will deliver less. Especially with how much time there is between releases.
Part of the reason for the lack of content is the lack of people who enjoy the potential of the game having to face the reality of the state of the game. Without demand, there isn't going to be any supply. Such immediate and defacto access to cheating away most of the short comings of the game reduces demand. The other part of the reason for the lack of content is obviously being creative is a rare commodity these days.
Again, that assumption could backfire. I for one fully enjoy the game's potential, alot more than its current state. I point out some bugs and contribute 3d content. But the current state would weigh me down alot if I did not have a weapon against it in the short term.

The main reason for the lack of content is how the project currently handles the content. Say with my asteroid models now released I want to make your super-freighter idea a content reality. First it has to be approved and given a make (say Merchants faction). Then I need enough guildlines for that make (Merchants) to create something that looks close to whatever is canon. But those guidelines don't really exist anywhere I can read them. Then I have to propose a concept or nearing completion model for final approval. Only there is no one around with the authority within the project to approve it as I understand it. Finally, I have to get it working in-game (mesher, units, unexplained missing texture bugs) and commit all the changed files so that it works in SVN.

So while people are still creating things for the game, not many are venturing far enough down that workflow to get the content in that you are noticing a lack of. But a recent lack of jackS and pyramid should not be confused with the presence of a text file save game format.


Anyway, the following is my warning or dark prophecy regarding action against save game hacking. I think it will:
  • 1) Make really bad and hard to fix bugs become so obvious that people quit the game, for that release at least.

    2) People will get way more emotional about bugs in general, since they feel they have no weapon against them and releases are far in between.

    3) There will be a values backlash by FOSS focused people who will feel a freedom is being taken away from them for the purpose of taking it away from them. (This has actually already started, in this thread.)
Eventually i will have more time to get back into heavy development. While this particular topic isn't a high interest of mine, it's obvious that it's doing more harm that good by hiding the magnitude of logic issues during gameplay. I'm very much more interested in finishing the physics updates, overhauling the ai and finally implementing dynamic events (which would ride parellel to normal scripting, yet can be used to totally replace it for everything). I really really wish i had the time now to do it, life has other plans right now though.
Totally understandable, I think all of us would rather spend alot more time working on VS than RL allows us to. But what really matters as far as project progress is that we keep coming back to help things along, when we have time to again.

Anyway, those features you have proposed and will be taking on I am really looking forward to. Physics and AI are the most important and most neglected elements of games, I feel.
safemode
Developer
Developer
Posts: 2150
Joined: Mon Apr 23, 2007 1:17 am
Location: Pennsylvania
Contact:

Re: plugging up free cheating.

Post by safemode »

Deus Siddis wrote:
  • 1) Make really bad and hard to fix bugs become so obvious that people quit the game, for that release at least.
I think the more people use the mission files, the less of a black box they will become. Even things like bugs in how the factions behave toward eachother have their root in the python files. The more people forced to dive into the mission files means more people who eventually want to understand them.

I think it's better to have the people quit than to make it so easy that nobody has any need to fix the problem. Without stress there is no evolution. You're effectively removing the trigger that causes some future programmer the desire to get in and produce a patch for a bug he's coming up against while playing.

If there was a bug so destructive to gameplay that the number of users who would rather quit than figure out how to reproduce what they do in the savegame in a mission file then i'm sure we'd see a lot more interest and work being done to correct that and get something out. Currently i dont see something like that. And, once people would be forced to go that route, i'm sure a step by step howto would be posted to tell others how to do it. I dont care if people cheat and create guides to cheat. I just want them to cheat via the mission system and to leave the damn savegame file to saving games.
2) People will get way more emotional about bugs in general, since they feel they have no weapon against them and releases are far in between.
They have a weapon, the entire game is completely configurable in plain text. They just dont know how to do it yet. No big deal. It's ok to get emotional about bugs too, though dont try getting too emotional, the people working on the game both in the code and in the content dont get paid, not by some company and certainly not by the emotional bug reporter.
Though if they want to send us money they can be as emotional as their heart desires and we'll definitely spend some extra attention to calm them down and rectify things.
3) There will be a values backlash by FOSS focused people who will feel a freedom is being taken away from them for the purpose of taking it away from them. (This has actually already started, in this thread.)[/list]
The savegame wouldn't be encrypted in some proprietary format. So the FOSS people have nothing to complain about license wise or whatever. Users are still free to use things in ways in which they're not intended. So nothing has changed here. Complaining that you can't misuse things in the same manner would obviously be met with blank stairs and perhaps laughter in any other product. While it's our responsibility to make proper use of the program reliable, it's not our responsibility to make improper use of the program dependable. That's like getting mad at gcc people because undefined behavior of a certain instruction has changed between versions and your app was depending on a particular undefined behavior in the old version in order to work. The in-use format of the savegame file is a convenience to developers but that convenience has not and should be weighed against the impact it has on the userbase as a whole and even though i didn't start this thread (split it from another topic though), I do believe it's been more detrimental than helpful. Especially in consideration that there are other more appropriate means to do what people are misusing the savegame file for.
Ed Sweetman endorses this message.
denyasis
Hunter
Hunter
Posts: 75
Joined: Thu Mar 19, 2009 10:31 am

Re: plugging up free cheating.

Post by denyasis »

I'm no fan of cheating - but I would express concern about making the save game file overly difficult to access:
Save games serve 1 purpose and 1 purpose only, to save the current state of the game to be re-loaded at a later date by the game. At no point is it intended for the user to be involved in editing the save game, or even being able to read it and make sense of it. At no point is the save game a means of debugging. While it may be easy to use it for such things, shortcuts cannot and should not be depended on existing - they're not an intended api in this case.
In many games, with and w/o modable content, the Savegame file is a means of degugging. Take for example, in the future, we have a campaign. Wouldn't we need access to the file to make sure the campaign's state is being properly saved? Also when it comes to playtesting said campaign, wouldn't the Save file be of use to report bugs from the play testors? Ie, the author/dev could see what condition/phase of the campaign the player is actually in. Is there another way to get this information from the game? Especially from a playtestor who may have limited programming experience?

I agree that cheating is most uncool and would rather people not do it, but i would worry about making it too dificult for devs/authors. Our content/editing tools aren't super user friendly and sometimes figuring out how the game works gives me a headache (The mission files still hurt my head, sorry). I just worry about over-complication :shock: although I do understand your concerns about the expectations from those used to "mis-using".
charlieg
Elite Mercenary
Elite Mercenary
Posts: 1329
Joined: Thu Mar 27, 2003 11:51 pm
Location: Manchester, UK
Contact:

Re: plugging up free cheating.

Post by charlieg »

I think this is a bad idea at the moment. The game is incomplete. Surely developer effort is better spent elsewhere than on obfuscating the save game format and preventing cheating. If you so want to, come back to that later on when the game is more complete.
Free Gamer - free software games compendium and commentary!
FreeGameDev forum - open source game development community
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: plugging up free cheating.

Post by chuck_starchaser »

I agree.
If this was a commercial game, and cheating was hitting you in the wallet, that'd
be something else. Right now, tho, clamp down on cheating and you risk losing
half your players.
Aren't there any more important things to do? Look at the Modding Engine forum
the number of feature requests I've filed there over the past year and a half. NOT
ONE of them has been done yet.
Zebedee
Trader
Trader
Posts: 17
Joined: Thu Jul 30, 2009 8:58 pm

Re: plugging up free cheating.

Post by Zebedee »

I'm not sure I'm following the logic of this argument. By removing the user's ability to make actual changes to a save game file in order to resolve bugs and glitches in the game to his/her personal satisfaction, this is meant to generate increased bug reporting where people bug report the issues which they can no longer fix for themselves and wait for those capable of bug fixing to release the next stable version? Really can't see how you get to B from A there.

Really love this game. Really appreciate the work the devs put in. But every time I go to report a bug (I actually registered to report a bug but then discovered it had been extensively commented upon but I'd used the wrong search terms when looking for a solution), I find it already listed and usually it's been flagged for some time. I've no doubt the bugs have been squashed in SVN but I look at the installation instructions for SVN and I just don't get them. So what's a boy to do? I know there's a lot of hard work and effort going on behind the scenes and that it's accessible if you understand the instructions but the expectation is that the user learns to reinvent the wheel (even should it be possible - I'd imagine fixing the factions must have been a nightmare)? Surely if the user was that way inclined then they would be better directed into using that energy and time in fixing things within SVN? Can you imagine the chaos which could be caused by users throwing out 'hotfixes' outside of the SVN project?

Peace and respect to all those who put time and energy into this project, but please leave me the ability to quickly and easily make changes to fix and improve my Vega Strike experience. I guess I need to figure out how to play SVN so that I can be more useful bug reporting as this is obviously something which more people need to do judging from the comments on the thread.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: plugging up free cheating.

Post by chuck_starchaser »

The logic is that preventing savefile edits you'd inflict heavy pain on players, on the
assumptions that,

A) Players WON'T report a bug unless forced to (a **ridiculous** assumption
in the age of open source, when users are eager to help the few ways they can).
B) That bugs reported will result in timely fixes (a hilariously naive assumption, as
there are bugs that have been reported 100's of times over the years and still lurk).

And then, what about mods of Vegastrike? At the PU forum we get TONS of bug
reports that there's nothing we can do about because, let's face it, VS developers
don't give much of a damn about mods, and the few of us that have some C++
experience can't make heads or tails of the code base. So, we're between a rock
and a hard place, already as it is. All we can tell players, sometimes, is to fix their
gameplay problems due to bugs by editing the savefile, and now you want to take
that away from us?

If you're desperate for bug reports, check the wcjunction forum.. we got hundreds
for 'ya... --certainly more than we know what to do with. We in fact **discourage**
people reporting too many bugs, because it increases our workload of filing them
away, which is work done for nothing, since we know they will probably never be
fixed.

Damn!

I've been asking now for over a year for cube-maps in the engine. It would make a
HUGE difference in the graphics quality. Presently we have these horrendous
sphere-maps that are totally deformed; preventing gloss control from working right.
The code for using cube-maps is already in the engine. And I've already produced
produced DDS cube-maps for ALL of VS's backgrounds using CubeMapGen, from
ATI. That's like 2 days of hard work. The ONLY thing needed is code to read DDS
cubemap format. And it just never happens...

Meantime, precious developers' time is being wasted on this stupid... And I mean
STUPID discussion. 5 goddam pages of it, already...

"Cheaters" this, "cheaters" that... Like who cares? There's hundreds of known
bugs already. What we need is some action; not so much talk.

Are you a developer, Zebedee? Because if you're not, you're in no position to judge
the need for bug reports. And if you ARE, then I got fucking TONS of work for you.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: plugging up free cheating.

Post by chuck_starchaser »

You know? Vegastrike is dying. If you look at the long-term pattern,
VS is almost dead alredy.
4 or 5 years ago, there were all kinds of mods...
  • PR
  • WCU
  • PU
  • Vegatrek
  • Some Star Wars mod, forgot the name
  • Rylix
  • Some Elite mod, forgot the name
  • A Babylon 5 mod
  • A Pi Armada mod
And one or two more I forget now.

There's only two of us left, today: Us (PU), and Vegatrek.
Vegatrek are in discussions, looking into other engines; eager to make a move on.

So that means that this crazy guy you're talking to, chuck_starchaser, happens to be
the maintainer of the only remaining mod of VS, really. And I'm TOTALLY fed up
with the lack of support. There's features I've asked for that should take a smart
programmer 5 minutes flat to implement. You guys just don't give a damn; do you?
He're you are spending dozens of hours a week discussing CRAP, like whether to
encrypt save-games to "stop cheating"...
Yeah, go on pretending to yourselves about how important Vegastrike the game and
its engine are to the world...
Once your game is the ONLY game using the VS engine, will you be able to still
call it an "engine"?

If an engine allows cheating, but nobody uses it, does it allow cheating?
Zebedee
Trader
Trader
Posts: 17
Joined: Thu Jul 30, 2009 8:58 pm

Re: plugging up free cheating.

Post by Zebedee »

chuck_starchaser wrote:
Are you a developer, Zebedee? Because if you're not, you're in no position to judge
the need for bug reports. And if you ARE, then I got fucking TONS of work for you.
Oobviously there must be a need for bug reports... that's the logical underpinning to the whole argument of encrypting save games. ;)
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: plugging up free cheating.

Post by chuck_starchaser »

Well, it's a dynamic of supply and demand.
Right now there may be few bug reports coming in, but there's huge
amounts of unprocessed bug repots in storage; and there's no demand
whatsoever for them, since nobody is working on the engine much,
lately. If you think that by pushing in more bug reports, somehow that's
going to cause development to accelerate, think again. Just about
every bug there is has already been reported 7 times. What we need
is more people to WORK on the engine.
I got tons of bug reports at wcjunction, like I said. Nobody is asking
for them.
If you want to help this project to move forward, first make sure you
know what its needs are, rather than assume. Its main need is for
programmers, right now.
denyasis
Hunter
Hunter
Posts: 75
Joined: Thu Mar 19, 2009 10:31 am

Re: plugging up free cheating.

Post by denyasis »

agreed;
safemode wrote:I think the more people use the mission files, the less of a black box they will become. Even things like bugs in how the factions behave toward eachother have their root in the python files. The more people forced to dive into the mission files means more people who eventually want to understand them.
I would go one step further and add a need for good documentation. Yeah the Wiki is nice, but the project is 10 years old and has gone through a lot of hands. As a result, there are a lot of nuiances (is that the correct word?) to the code base and many are not inutitive to figure out.

I think there are people in both vs and pu more than willing to help out with the code in any way possible (even little bug hunting and typo fixing), but learning how the basics of the engine works, is well, daunting; Its programed in 2 different languages, multiple file formats, unique extensions, overlapping dependencies, etc

Mission files for example- ok, configurable in plain text, anyone can change them - got it. But some Mission files conditions are limited by python scripts (faction identity), both of which are called by the cpp (AI selection) files and the mission files even call other python scripts (AI specificaion)or default to cpp(fallback mechanism -YaY), to select appropriate xml files (AI routines) via 3-5 csv files (1 of which may not even be used by the engine) that make calls to other xml files or call straight back into the cpp files (in flight manuevers).

Without good documentation, ppl will get stuck on step one up there, get frustrated, and then wander off to Oolite or someplace else. Heck, I'm 99% sure what I put up there is incorrect, I just lack the coding ability or documentation to figure out exactly what happens, so I have to extrapolate and guess. - YaY :D

--

I understand from what has been said in the forums, that a move to Ogre will squash bugs as the code is refactored, but I just read a post where Ogre was just "around the corner" in 2007.

It makes perfect sense to not to use resources bug fixing the old engine when a new one is comming, but we seem to be stuck in a limbo bewteen the two.

I guess my question is, devs, which way are we going (100% to ogre or 100% to the vs engine) and what can we the community do to make the game engine (which ever it will be) more accessible so we can attract and get more coders involved (and reduce your burden)?



---
side note: chuck, You've always seemed super knowledgable, especially when it came to the game engine graphics and well everything graphic, I always kinda figured you were a dev who wrote for graphic engine, lol.
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: plugging up free cheating.

Post by chuck_starchaser »

Well put, denyasis. You've summarized the situation EXACTLY.

As for me, I don't consider myself a developer. There's only two pieces of C++ code I wrote,
in the engine. One was a template messaging system, like an observer pattern; the other
is the code that computes tangents. In both cases, though, I just wrote the code and gave
it to Klauss to integrate into the engine, because I'd have no idea where to put it.
And shaders are something else altogether; not really a part of the engine.
But like you said so clearly, I'd love to become a developer, but I find the code inscrutable;
can't make heads or tails of it ever; even when Hellcat has tried to help me, the amount
of un-figurable stuff is staggering. Among the things you forgot to mention, using special
values in floats, like 0 or -1 to mean special things. This is a NO-NO-NO-NO-NO-NO-NO
in programming. In my coding I rigorously observe command/query separation: A function
is either a query (returns a value but changes no state, and is declared ...() const;) or it is
a command, and MUST return void. To me this is a sacred rule; but VS code doesn't even
seem to be aware of the existence of command/query separation discipline. There's hardly
ever a function returning void, in fact. So one looks at a function and can't even tell if it's a
function to get information or to effect a change, except by looking at the code. Because
even the names tell you nothing about it.
I'd name a query function

Code: Select all

    bool light_is_on() const;
and a command function

Code: Select all

   void turn_light_on();
Makes the meanings and intents clear.
But in the VS engine you might likely find a function

Code: Select all

    float light_off( double );
Same thing with naming of variables... A variable named "fuel_is_empty" HAS to be a
boolean; can't be anything else; can it? That's how one names variables. Boolean
variables should read like statements that are either true or false. But in the VS engine they
NEVER are so named. Same as "amount_of_fuel_left" is obviously a float, without looking
up the definition. But trying to read VS code you have no way to tell anything from the way
variables or functions are named. You ALWAYS have to look things up, look things up,
look things up... Study functions in detail to even get a glimpse of what they are for.
It just drives me bananas.
We need to get 600 programmers on promises of free sex, and put them to work on a
mother of all rename-athons.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: plugging up free cheating.

Post by Deus Siddis »

Imho, going for OGRE full steam should be a priority, and then Bullet and anything else that covers a large portion of the game with a strong feature set and clean code.

But I wonder how much that would fix, since the remaining code would still be such a mess (something that's been reported over and over on the forums, iirc).
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: plugging up free cheating.

Post by chuck_starchaser »

Deus Siddis wrote:Imho, going for OGRE full steam should be a priority, and then Bullet and anything else that covers a large portion of the game with a strong feature set and clean code.
Frankly, you might be right; you might not; I just don't know. I was the first guy who argued for Ogre in this forum. That was when this guy... many years ago... I forget his name now; registered and from his first post started trying to sell us into Ogre. Everybody in the forum jumped on him like he was a troll or something. I was the first to say "Hold it guys; maybe there's something to this idea." Then Klauss joined the yey side; and finally Hellcat showed in and approved the project. Thing is, though, whatever his name was is not around anymore; and Klauss has very little time.
I get your drift that perhaps by embracing a clearer code base, the clarity might percolate to the dark side; but then again it might not.
And the fact is that it isn't necessary to acquire clarity by conquest. There just needs to be desire for it. That's what I liked about safemode; not sure whether he's gone permanently or temporarily, so I'm not sure whether to speak in past tense; but he had a habit of cleaning up code as he implemented new stuff; and posted requests for opinions when he wasn't sure how to best organize things.
Another thing I liked about safemode is that he was convinceable. He listened to a good argument. He was looking for ways to speed up the engine once, and I suggested to him implementing support for DDS textures. It was a long argument; but once he was convinced, he implemented them in no time, and now VS boots in like 1/10th of the time it used to take.
Having a few programmers like him helping out, and with few months' work the engine might get cleaned up into ship shape.

But there needs to be a bit of civil disobedience, also; because I know that if any programmers show up they'll probably be subsumed into the man-eating multiplayer project, unless they adamantly refuse, and insist on working in code clean-up.
Code clean-up, plus bug-fixing, plus implementing features that are needed, as opposed to pie in the sky. Talking about
things like my proposal to unify the code for bases and ship interiors, which are not categorical distinctions in the real world.... --the difference between a ship and a space station is the size of the engines---... so we could go places inside the ship just like we do at bases; or look at the stars through a window on a space station. Ace123 liked the idea a lot; yet it didn't get implemented. I've filed many such feature requests that are small, concise, clear about the problem and the solution, if not necessarily "simple", as opposed to many feature requests we get, like atmospheric flight, that are huge endeavors. But no matter; nothing I suggest ever seems to get implemented. Ironically, multiplayer is, IMO, one perfect example of pie in the sky project. Huge amount of work without, AFAIK, a clear goal. I don't think there's a gameplay plan for multiplayer; I could be wrong; but I think the assumption is that once head-to-head works, "the rest" will follow automagically. And the biggest problem of multi-player is cheating. Now THAT is the kind of cheating they should worry about; because it kills most multiplayer games in the bud. Either you own secure servers, or you invite people to contribute servers; and if you do the latter, many server donors are hackers posing as philantropists.
OTOH, they might have a harder time understanding the server sources than than they would at cracking a hex file :D

Well, that might be it: Just dump the sources and work with disassemblers... Call it an "Open Hex" project :D :D :D

EDIT: If I sound animated it's just the kind of guy I am; I mean no animosity, really. Well a few broken noses maybe; but noses were made to be broken, anyways. Just saying this because Zebedee sent me a PM yesterday, worried that I had been offended by something he said. No such thing. Just that I've got a bottomless pit of frustrations to vent, and when 50 people decide to discuss a stupid subject on and on and on... they are just asking to slapped back to their senses :)
denyasis
Hunter
Hunter
Posts: 75
Joined: Thu Mar 19, 2009 10:31 am

Re: plugging up free cheating.

Post by denyasis »

I can't seem to get in to the wiki at the moment, and I have not looked at it in a very long time, but, going on a limb here, It seems to me that a detailed "master plan" of sorts might be useful. Having a representation of how we want the engine to work (graphical, list, what ever), along with proper documention of what the objects in the engine are supposed to do, how they interact, definitions, and a link to the corresponding SVN section would be a great guide as it would allow many different people to "jump into the code" in collaboration while maintaining a clear focus on an end goal, namely a clean Ogre game Engine.

Referencing this thread:
http://vegastrike.sourceforge.net/forum ... 27&t=11040

As the code is ported over, the refactoring and clean up would be near automatic as it written as it would conform to the rules set in the wiki's game engine "master plan", right?

So setting up the "rules" for how every object in the Engine should work would be the big first priority, right? Then porting code over, refactoring it to conform to the rules and adding proper documention? Am I understanding this correctly?

If that's the case, what can we do to help get this ball rolling?
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: plugging up free cheating.

Post by chuck_starchaser »

I'm going to email Klauss and ask him what's the status with his branches.
I think he recently rewrote the sound system from the ground up, but hasn't merged
his code into trunk yet. Regarding the graphics side of things, his work on the Ogre
port is completely frozen, sitting in a branch.
Currently, he's starting to work on graphics, but without Ogre. He just finished some
work on "techniques" to distinguish DDS cubemaps from 2D textures, but hasn't
written a DDS cubemap file-reading routine; but is planning to do so. I think there's
a few more changes needed beyond that for CineMut shader integration; not sure
what or how many, myself.
But other than for the above, I think a documentation/clean-up/refactoring-athon
could be started any time. Safemode rewrote the collision code from the ground up,
and was working on refactoring the object hierarchy; not sure how far he got.
Deus Siddis
Elite
Elite
Posts: 1363
Joined: Sat Aug 04, 2007 3:42 pm

Re: plugging up free cheating.

Post by Deus Siddis »

chuck_starchaser wrote:That's what I liked about safemode; not sure whether he's gone permanently or temporarily, so I'm not sure whether to speak in past tense; but he had a habit of cleaning up code as he implemented new stuff; and posted requests for opinions when he wasn't sure how to best organize things.
Another thing I liked about safemode is that he was convinceable. He listened to a good argument. He was looking for ways to speed up the engine once, and I suggested to him implementing support for DDS textures. It was a long argument; but once he was convinced, he implemented them in no time, and now VS boots in like 1/10th of the time it used to take.
Having a few programmers like him helping out, and with few months' work the engine might get cleaned up into ship shape.
Safemode's still around, he just hasn't been able to touch the codebase do to RL business. In his own words from his first post on the previous page of this thread:
safemode wrote:I'm very much more interested in finishing the physics updates, overhauling the ai and finally implementing dynamic events (which would ride parellel to normal scripting, yet can be used to totally replace it for everything). I really really wish i had the time now to do it, life has other plans right now though.
He's also been pushing for greater realism in VS recently, in his "A new take on wormholes" thread, which ended up covering alot more realism issues besides wormholes.
klauss
Elite
Elite
Posts: 7243
Joined: Mon Apr 18, 2005 2:40 pm
Location: LS87, Buenos Aires, República Argentina

Re: plugging up free cheating.

Post by klauss »

chuck_starchaser wrote:I think he recently rewrote the sound system from the ground up, but hasn't merged
his code into trunk yet.
Nope, not merged yet. There's a lot to do before that happens, but the code is functional and very very very cool :D
chuck_starchaser wrote:Regarding the graphics side of things, his work on the Ogre
port is completely frozen, sitting in a branch.
Yeppers... exactly that. I haven't had time to work on it for ages, and I believe restarting my work on it would involve several weekends of wondering where was I ;)
That doesn't mean I abandoned it... I very much wish to finish it (it feels sooo sour to leave something that unfinished), but it may be very long before that happens.

I did however decide to take shortcuts. I was aiming too high - which was good since it pointed me in the right direction - but now I have to scale down the requirements a bit to make the port a reality.
chuck_starchaser wrote:Currently, he's starting to work on graphics, but without Ogre. He just finished some
work on "techniques" to distinguish DDS cubemaps from 2D textures, but hasn't
written a DDS cubemap file-reading routine; but is planning to do so.
Ya, I've been dividing my time between that, the sound system, and RL. Frankly, the sound system is taking higher priority (though it's not exclusive), since it's close to completion, and I very much want to see it integrated.
Oíd mortales, el grito sagrado...
Call me "Menes, lord of Cats"
Wing Commander Universe
chuck_starchaser
Elite
Elite
Posts: 8014
Joined: Fri Sep 05, 2003 4:03 am
Location: Montreal
Contact:

Re: plugging up free cheating.

Post by chuck_starchaser »

Klauss, my offer still stands that, after CineMut, I'll give you a hand with Ogre, sound, or
whatever else you need help with. And you know me; --you know I can code.
But one unresolved issue between us is the opening braces/parenthesis, and it's a killer.
Fortunately, about a year ago I read an article in some mag --maybe C/C++ Journal-- on
this very subject. The author began by recognizing the fact that this may be more than
just a matter of taste, and that in fact it's a serious issue affecting the whole software
industry.
I can barely read code like

Code: Select all

void function() {
    if (whatever) {
        for (the hell of it) {
            code...
        }
    }
}
And I can't work with it.
I just can't.
I NEED to see,

Code: Select all

void function()
{
    if( whatever )
    {
        for( the hell of it )
        {
            code...
        }
    }
}
Otherwise I have to manually reformat the code first; then work with it.

And the article mentioned a solution for this problem... some server-side plug-in that can
reformat code on the fly to any developer's taste; then put it back to its original format
upon commit.

I don't remember what it was called. Maybe we could use something like that? I'm sure
I'm not the only one with this problem. It would increase our chances of getting more
developers involved like several-fold, I bet.
Locked