|
|
Post by riedquat on May 26, 2011 15:46:11 GMT -5
oi... voted before reading explanations... the more I read the less i understand...  Mods: yes!! |
|
|
|
Post by Pilot on May 26, 2011 18:23:00 GMT -5
Since I'm currently busy with the main-frame, I hit the following questions, and I was wondering what you guys thought about it. Ofcourse we want this version to be moddable, however, there comes a moment when you saved a game, and want a MOD, but not loose your saved progress.. What does this have to do with the buildup? I can let the program use worlds, which each have their own maps/moths/scripts/data. These worlds can be duplicated and modded, etc etc. This way you will be able to use several modded versions or extensions (extra map) beside the original one, which can be selected from ingame. Advantage: Better support for multiple maps or mods. Disadvantage: Modding with several versions could get complicated if not managed well. I can also only use one version, which can still be modded ofcourse, but you're directly modding the original version. New worlds or maps will have to replace the other one, so unless more versions of HardWar are installed, only one will be available at a time. Advantage: Simple to apply MOD's Disadvantage: not possible to keep different save-games of different worlds in the same installation. Not possible to access different maps or MOD's from within the program. Note: with the first option I can include a program to manage the different MOD's for different worlds. Let me hear what you guys think of it. I included a Poll to make it easier to reply. It's a big enough question to have warranted a new topic. ^^ I'm for multiple mods being possible at once myself. While this does make it more complex, to keep each MOD individual and unlikely to interfere with each other maybe anyone that decided to make a MOD would have to chose a string for that mod to take, (I'm sure my post is making little sense by now.) Perhaps limiting creativity would be the most effective route... Example: If two modders wanted to take make a crater south of Mines they would at least need to know the general area off each others new crater as well as tunnels and property of that crater, another words each adding a moth factory to their craters would be to convenient... I think I've gotten too far a head of myself... Again. |
|
|
|
Post by rotary on May 27, 2011 16:44:31 GMT -5
riedquathappens  PilotThe problem with a map is that is it made out of one (1) piece. This means you cannot add craters, without overwriting the rest of the world. Buildings have their own model also, but are placed within the world by code, meaning you can add buildings by simply adding it in a list of a world. However, you cannot have 2 MODs active which both change the same model. At the moment, the map (terrain that is) only has 1 file with the complete map. I can try to split it up in craters, but to add a crater, you need to edit a map and save it as a complete map, overwriting a previous version, or saving it as part of a new world. Ofcourse we could make underground tunnels available, (for example via tunneling drills, entered via their tunnel entrance) which connect different craters, which would solve this issue, giving way support infinite ammounts of craters, even addable during the game.
|
|
|
|
Post by Pilot on Jun 1, 2011 18:11:08 GMT -5
PilotThe problem with a map is that is it made out of one (1) piece. This means you cannot add craters, without overwriting the rest of the world. Buildings have their own model also, but are placed within the world by code, meaning you can add buildings by simply adding it in a list of a world. However, you cannot have 2 MODs active which both change the same model. At the moment, the map (terrain that is) only has 1 file with the complete map. I can try to split it up in craters, but to add a crater, you need to edit a map and save it as a complete map, overwriting a previous version, or saving it as part of a new world. Ofcourse we could make underground tunnels available, (for example via tunneling drills, entered via their tunnel entrance) which connect different craters, which would solve this issue, giving way support infinite amounts of craters, even addable during the game. What if... ............................................ .....___................................. ....|==|............___............... ....|__/............|==|.............. .........\.\..........|__/.............. ...........---------././................. ...........|=====|................... ...........|=====|................... ...........|_____/................... ............................................ ............................................ ............................................ ............................................ ............................................ ............................................ ............................................ ............................................ ............................................ ............................................ ............................................ Well it would take too a... long to do all the craters in ascii art, but you can see a general area that is crater like, considering you idea of drills lets say all the periods are solid rock (or "empty" space holders.) That could be influenced in game via those drills, maybe {X} square meters per every 50,000 to 100,000 credits. Or left for crater mods. |
|
|
|
Post by rotary on Jun 2, 2011 8:59:25 GMT -5
Now that's art! ;D
But that would be possible indeed. What the biggest problem actually is, is not the added crater (it can be imported relatively easy), but its connection to the 'old' world. Because the entrance needs to connect its tunnel somewhere into the old model, which needs a change of the old model, which limits the use of independent map/crater-mods to 1. That's why I suggested the drills, which will be a built-in feature that build tunnels dynamically; in-game. Tunnels go from Entrance-building to Entrance-building, maybe connecting multiple buildings with one building. This way craters can also be connected via this underground network, making it useful for long-range traders.
Although this feature is not really needed for the Remake, its very nice to have some space for modding afterwards. Drilling new craters square by square could be possible, but this should probably be added via MOD's, actually just like the tunnel-drills.
|
|
|
|
Post by duncan on Jun 3, 2011 2:22:35 GMT -5
Short update, i can now import the entire hardwar world from native files into blender by python script. i hope to restructure the script a bit and then release in time. plus still some fixes to make, like materials image - ok, looks just like the old ones, but really is the product of the python script:  |
|
|
|
Post by ouch on Jun 4, 2011 11:29:38 GMT -5
wow, i'll look forward to that release...
|
|
alucard
New Member
"you foul monster!" "I get that a lot."
Posts: 20
|
Post by alucard on Jun 5, 2011 9:06:03 GMT -5
What he said. I can only make a few simple programs in python, most of them with no gui XD. thats amazing. (Side note, is the game logic in blender easy to use?) |
|
|
|
Post by rotary on Jun 5, 2011 17:58:30 GMT -5
Good to see so much progress on the graphics! I've got to work my ass off if I want the engine finished at that time ;D While programming in the past month, I developed a file-structure, which seems quite convenient for me. I added some pictures to show it. Furthermore, I added a screen of how the menu looks like now. I'm still fuzzling with the camera-size, and the fact that mipmapping is blurring also perpendicular pictures and causing artifacts on transparent edges. Following posts will contain the pictures. Short description on how it works until now (and partly is going to work). I will explain according the file-structure. HardWar.exe is the main engine (obvious!) config.cfg contains settings like video, sound, MOD selection, etc. 'Vanilla'-directory stands in this case for a pack, which will be explained later. In the Model-directory go all the models. Models (the .blend-files contain the model) like buildings and moths have a .cfg file, to store details like health, mounting-points, capacity, hangar-position, etc etc. Menu-items like buttons are imported via the engine on request of the menu-script. This way new Menu's can be created easily without having to edit the main-engine. Maps store the map-models. For now this will only contain 1, but it can also contain different craters or planets. Remember that buildings are not included in these maps. 'World'-files (.wld) contain a collection representing a world. It contains information of which maps it uses, which buildings to include, which persons with which skill (trader, pirate, etc), which moths, which plot, properties like money, cargo, factories, owners, etc etc. and an empty (property-less) player person. Profiles contain information of which world to start and eventual changes to this world (like your account, type of moth, etc) SaveGames probably work like Profiles or World-files, depending if buildings will be destructable or not. (I wish I could start a new Poll in this topic...) So how does a game start? Via the engine, you will end up in the menu. Via starting a new game, and selecting a profile. This profile will load its world via a pre-defined world-file and the player's property. In this world a basic script will always be running, managing which script to run when for who. It will also be responsible for lowering script-rate when objects are out of sight. All changable objects will have a property which points out their Character, it either being a Trader, Pirate, Building, Hangar, Person, Plot, etc. The basic script will check an object, run its script, and ask when its script has to be reactivated. Now that's actually how I'm working on it now.. Many things have to be worked out still ofcourse. I'm working on completing the menu (currently making it easier to mod, also easier for myself to add features later). It is however already working as a menu. Buttons are addable via a simple line, and new menus via an extra menu-script. Layout and explanation of the scripts will follow later when they are more finalized. Oh yes, why the Vanilla-directory. As you can see, all buildings, maps, moths and profiles can be edited, added, etc etc. However it can happen that MOD's will conflict, especially when you are talking about larger MOD's. Although you can create different names for each MOD, and keep them in 1 directory, I thought it better and safer to be able to separate MOD's, which contain a complete new world. Also because save-game compatibility can become an issue when MODding. Good night all! Attachments:
|
|
|
|
Post by rotary on Jun 5, 2011 17:59:23 GMT -5
Menu: MipMapping off No artifacts  Attachments:
|
|
|
|
Post by rotary on Jun 5, 2011 17:59:55 GMT -5
Current File-structure used Attachments:
|
|
|
|
Post by Pilot on Jun 6, 2011 17:07:09 GMT -5
Nice work! While I do love the Hardwar font, I personally believe that if it is a burden to you, it could be dropped.
|
|
|
|
Post by rotary on Jun 7, 2011 7:26:38 GMT -5
I got the font from one of the HardWar-fan websites. It works reasonable, but maybe I'll make my own text-builder inside the game, to prevent mip-mapping problems and blurring. It's not more burden to use this font or any other, its only the quality that makes a different.
|
|
|
|
Post by rotary on Jun 7, 2011 12:16:41 GMT -5
Good news: Dynamic importing of external models (dynamically via script, so not pre-programmed) works!
>>small jump of excitement<<
It took me quite a while, since it is a relative unknown and new feature of blender, and still comes with all kind of hooks and bugs, but I managed to import objects smoothly from a completely non-related .blend-file. This means modding will become much MUCH easier, without having to update the main-engine every time.
|
|
|
|
Post by Pilot on Jun 7, 2011 17:49:55 GMT -5
Nice!
|
|
