|
Post by Major Pain on Aug 31, 2014 23:15:17 GMT 1
|
|
|
Post by Major Pain on Aug 31, 2014 23:33:38 GMT 1
Standby... working on it.
Sorry about the screen images... the size is restricted at that the displayed size.
I'll be showing many closeups as we proceed.
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Aug 31, 2014 23:59:45 GMT 1
For my part you are forgiven teacher
|
|
|
Post by Major Pain on Sept 1, 2014 0:05:37 GMT 1
Thanks... The screen images sizes are 1600x1200. Image Shack is restricting it to 800x600, I resized and got a bit more.
|
|
|
Post by ogmodon on Sept 1, 2014 0:36:44 GMT 1
Now I expect those Humbers to dance...
|
|
|
Post by Major Pain on Sept 1, 2014 0:45:56 GMT 1
dance... bloody 'ell... they will waltz on cue...
|
|
|
Post by Scyooff on Sept 1, 2014 1:19:14 GMT 1
Thanks... The screen images sizes are 1600x1200. Image Shack is restricting it to 800x600, I resized and got a bit more. With mediafire the images sizes are surely larger than 800x600. Click
|
|
|
Post by Major Pain on Sept 3, 2014 5:01:45 GMT 1
Slight delay on the Humber while I work on these babes... Pz IV Ausf J
|
|
|
Post by kellyshero on Sept 3, 2014 9:53:02 GMT 1
Awesome work Major. 1 minor thing......and I am happy to be corrected, but all the blueprints and pictures I have seen of the Ausf J & H's (on the Western Front at least,) had a one-piece circular commander's turret hatch. I wouldn't normally say as this is such a minor point but I know you are a stickler for detail Keep up the excellent work!!!
|
|
|
Post by Major Pain on Sept 3, 2014 13:30:21 GMT 1
Good eye there Kelly... The models shown is the first mockup... You are quite correct. That should have been the Ausf "G", which was the final Split hatch.
The track conversion was involved... and doubled the models weight... 600KB to 1200kb (1.2mb).
I must reduce this by about 20% or so to guarantee model integrity. This model as it stands, will not load into the tanks viewer, mostly because of the number of polys. So the project is still young... I'm looking at part structures that can be eliminated or modified to save weight. The thing that adds to the weight the most of course are the wheels of which there are 20 on each side, 10 Doubles. This may have to be reduced to where the bogie wheels are combined and use a 2D effect for the split effect. Removing a few faces will not get me where I need to be... I already used 10 sided wheels instead of 12 sided knocking off 320 polys.
Another major change on these models are on the hulls. I have opened up the area just below the turrets which allows viewing down into the tank when the turret blows off. That requires interior faces to prevent looking through the inside surfaces. That just looks better than a large black circle drawn on the hull top. That adds about 36 polys for the circle opening.
Sometimes the details can cause frustration... aaarrgggggghhhh
|
|
|
Post by Major Pain on Sept 3, 2014 23:58:18 GMT 1
Ok... after some minor changes on the Road Wheels, Sprocket and Trailing Wheel... I have the first of the fully functional PzIV Series II Tanks to show... Call this the F2 or G Model...
|
|
Deleted
Deleted Member
Posts: 0
|
Post by Deleted on Sept 4, 2014 0:17:30 GMT 1
What a marvel, I would say, A BEAUTY.
Just to think of it, make me want to play alone with the alone.
Good job "Major Pain" much realism in track and wheel
Greetings.
|
|
|
Post by Mascarenhas2 on Sept 4, 2014 1:48:29 GMT 1
Great, as usual, Major, applause. A question: the Pz IV series comprises a xml file - which I suppose should be added to objects xml, and folders for each model, right? My doubt is about other mods ( GZM, Kursk, HRA) that have different specifications, ranges, firepower and so on. May I just add them to the proper folders and modobjects or some will be compatible and others not?
|
|
|
Post by Major Pain on Sept 4, 2014 3:15:10 GMT 1
Thank you... If my work inspires anyone to play right now, then I have done my job.
@ Mascarenhas2: Let me make sure I answer you correctly...
First of all, each model you want to add to the game should be added to your objects.xml, not the modobjects.xml.
I try to name my models in such a way they do not conflict with other models that I am aware of. Sometimes, I have to rename models if I happen to use a same name, but this is rare.
The reason I suggest you place these in the objects. xml for for the simple reason I do not pack these as a .pak file. Because of the number of models that I produce, you would need a modobjects.xml in each .pak, which could present a problem with conflicts.
There have been a couple of MODS or ADD-ONS with my work, which do have modobjects.xml file. But generally, these modes may have the same models that I have released, but they rename them slightly to avoid conflicts with models that may be in your files.
I have considered several times of doing Mega-Packs, but so far have not done this because the number of downloads on my work. I assume that everyone that downloads it has a pretty good idea what it is and they are downloading on purpose. So a Mega-pack would be redundant for them since they likely already have most if not all of the models.
Over the years, i tend to revisit earlier work and update it or make some changes or additions. I try to make the distinction on those so there is no mistake. The most recent was the updates on open bed trucks. I released a rebuild on many models to incorporate the riders. These models did not require another mention in the Objects.xml since they were likely already included. I assume most players have the knowledge to address situations to add models to the objects.xml.
As for Add-ons or MODS that have changes to the sight and ranges... the sight is controlled by the 1.xml file... the weapon range is controlled by the weapon file. To use my models for GZM for instance, you might wish to look at comparable models and make the changes where needed. I expand the 1.xml file for this purpose... to make it easier to find what you need, and to make changes as needed. great care must be taken to makes sure you only change a value or weapon name, and not remove < > / "" and other key characters in the code. Those Characters all have a purpose as to how the 1.xml is structured. The 1.xml file is more than just a simple file... it is actual xml code and processed by the game engine as such.
About modobjects for a second. Modobjects are a great way to add models in a MOD form. It is not so great for models you may need to work on from time to time. If you read my How To Tutorial, then you have the knowledge to unpack and pack your .pak files. Unless models and missions are designed to be in a MOD form, there is simply no reason to not expand your game files. I point to the computers of the day having small hard drives as one of the benefits in 2001-02. But today's computers usually have a tremendous amount of hard drive space.
Having your game files open, makes it much easier for you to modify the skins, 1.xml, and other files. If you had to unpack and repack just to work on a one model, it gets very time consuming when you are talking about thousands of objects and models.
Now there are some ZIP utility programs that will read and write to .pak files as if they are open files, but my experience has been if you do this a lot, there is a high chance of errors occurring in the individual folders. What in effect happens is if the folder worked on is not the exact same size when you write it back, the Utility appends the folder to the back of the file and removes the original location.
You have to think of how ZIP and RAR work... they write sequentially in order they grab each file... but they do not read back sequentially if you have inserted something... There is a directory added to the ZIP file that maintains the placement where each file starts and stops.
In the old days, we called this Relative File Storage, or Relative Data Storage. We did not have hard drives at the time and depended on Reel to Reel Taped Drives. Each file was stored by the Tape Counter as to its location. To retrieve a File, the Counter was used to Start reading the file. We had to enter what we call a CR at the end of the file which told the work station the file had been retrieved. The CR stands for Carriage Return... in effect the exact same thing that happens when you are typing on a conventional typewriter and reach the end of a line.
Anyone remember the old typewriters??? I have a couple I'd like to sell to you if you have never seen one. They are mostly museum pieces today.
I hope I covered everything and answered your questions.
MP
|
|
|
Post by Mascarenhas2 on Sept 4, 2014 10:48:38 GMT 1
Many thanks, sir, for your kind and precise response. You gave us exactly directions on what to do to enjoy your little jewels right on. Regards.
|
|