Editing a published game?!!

#1 Mission files are ment to be editable by users/players. If you want those mission files to be compiled like Torque script files then you might just need a few changes to the engine to make it happen and when it's time to publish the game just make sure source scripts and mission files are removed and the compiled ones are left alone.

By the way when players/users edit mission files it isn't editing the game, it's just editing the map, and they could do it without opening the file in notepad, they simply could host the game and press F11 to edit the mission/map file which is a whole lot easier. Tribes and Tribes 2 which used an earlier version of Torque were designed so the player could easily create and modify their maps and use the ones that come with the game to be used as examples on how missions are done.

Again whenever you become a Torque SDK owner(which I noticed you are not, yet?) you'll have complete source code to Torque Game Engine and make it possible to keep your users/players from being able to edit your official maps and still allow them(or not allow?) to create their own.

#2

Quote:
I don't think it would be permitted in any commercial game, whould it?."

To name a few Comerical Games that did permit "mods:
Neverwinter Nights by BioWare
Quake
Doom
Tribes (where Torque engine come from)
Etc...

Most games allow mods of some sort or have crafty people who figured it out.

Quote:
I don't know why the Torque developers left this nice project with these painful lacks,

Well some would say its a "power" get users to create their own mods and hopefully generate a sale or two. (I got 3 of my friends to purchase NWN because we could create our own D&D Adventures with it)

#3 The whole point of allowing users to make mods for your games is to sell more copies :)

#4 Yes, they should be able to create mods but not be allowed to edit my game, so if you mean that all mission and script file will be compiled and uneditable it's a solved problem i thought. you want to say i can compile all of my source and make them uneditable, so whats the compiled mission file name and extention also the gui and script ones?.

#5 Yeah they cannot edit nor view your compiled files since they're in some sort of machine byte code. Compiled script files are .dso (usually it's .cs.dso) same goes for .gui files (as .gui.dso).

#6 Mgm, you are just wrong. Editing levels is absolutely standard nowadays and I just don't understand what's wrong with it. And if someone's editing your levels they've bought your game.

Ian

#7 Its usually a gamers way of extending the game. I know lots of people who only brought Half-Life because of Mods.

Also I noticed you haven't brought the TGE, and guessing you want to chnage your icon etc with out the source? well I've always thought icons had to be changed in the source code anyway.

Also wouldn't it be right to say your modding the TGE?

#8 I said i just dont want my commercial published game be edited, so they should be given an ability to create their new missions and mods based on game and creating costum missions isn't the matter but not editing a certain game.and then i want to know if the mission file is compiled during the first run but why when i delete it(a ".mis" file) its level doesn't be loaded?.
thanks to all.

#9 If it wasn't for publically available ways to edit games, I probably would have shy'd away from a life of game development. Back in the days of Doom, I spent most of my waking minutes hacking the levels to bits, walking around them with 'idclip' and 'idspispopd' (.. er... that was god mode, right? It's been FOREVER!), learning about how they did what. I downloaded almost every editor out there for it, and absolutely shredded that game to bits.. all in the effort of learning, and in doing so, wanting to edit it, and wanting to make my own.

It's inevitable. If you do not allow for your game to be edited, and it is a very good game, people will find a way to edit it anyway. It's best to simply give in, and give the people, your customers, what they want. Or at least, that's my suggestion. (Even the games out there which have editors built into them, people still make OTHER editors and hacks which allow them even FURTHER editability!)

#10 As for mission files loading, each .mis file loads when that individual mission is parsed. Deleting the actual .mis file without having it compiled in a way that the game can recognise it as, "Oh, it's over there! Okay, I'll use this already-parsed version, then." then it's going to give a nasty problem when trying to load. (Or did I completly understand your question incorrectly..?)

-Dave C.

#11 Maybe yes...i mean when i load a mission named "features.mis" then the engine builds a file named "features_7678a003.ml" for example, is this that compiled bytecoded format?. if yes so why engine doesnt use this compiled at the next game loading without its source("features.mis"), and if not so whats the compiled mission file name?

#12 The engine uses the .mis file every time it runs. There is no "compiled" version it will use instead like the .cs files.

To prove this just remove your .mis file from the folder. You will see the engine no longer sees this mission.

If you want this functionality, buy the engine and update the code to provide it.

#13 The .ML files are lighting files. They are produced when you run a map, usually when there is some form of an issue with the lighting.

As I'm not a programmer rather a simple designer who is just beginning to learn TorqueScript, I don't know the details on exactly what causes the .ML files the be created. I however know that they are always created when there is a problem lighting the map, however are not always created, which I believe is whenever there is no problem lighting the map.

Could one of the programmers perhaps confer this, or correct it?

#14 I haven't taken a look at the actual ML (mission lighting?) file generation process but here's an educated guess at what it does:

It probably stores the lightmaps for each individual interior instance and probably for the terrain too. Since lightmaps are different for each mission (and object instance, which is why the .ml files get big), they need to be stored somewhere "mission relative" (that's why they've got the same names as the mission files). This lets you use the same geometry (even terrain) in different missions and just store the mission specific lightmaps in the LM files.

I don't think there should be any problems in compiling the .mis file to bytecode. They aren't by default (probably due to the different naming scheme?) but I'm sure you could compile them to bytecode and ship your game without the ascii file.

#15 You could change the .mis file to a .cs file and have it compile into a .dso file; would require a few changes to the way missions are loaded and saved.. not that hard to-do if you trace through how missions are loaded/saved

-Ron

#16 Luigi is correct, as is Ron. Of course, compiling to bytecode still allows modification, it's just a bit hairier..

#17 Exactly what i want to know is how it's possible to compile a .mis file to a binary version,

Ron wrote:

Quote:
You could change the .mis file to a .cs file and have it compile into a .dso file; would require a few changes to the way missions are loaded and saved.

but i thought the .cs file are just the script files, so when it changed to this format and compiled how the engine applies this .dso when it seeking for .mis files as its default mission file, also for a .cs file when executed by exec("'sciptname'.cs") how it could be deleted and used a .dso instead, doesn't it cause an error?.

#18 When loading a mission, the .mis file is executed using the script function exec(), just like any other script file.

You wouldn't really need to change the actual engine source code at all.

#19 You do have a point about the listing of mission files - I'd suggest hardcoding a list of missions into your game. Or you could modify the engine to allow compiling of .mis files, which would still break the listing stuff.

This is hardly rocket science, though. You could always have an external description file, although then *gasp* people could modify _that_.

#20 Thanks for any answers.