Matrix Games Forums

From el cid
 
Talking about self important blather

lack of humility about code is not a substitute for understanding it.
 
Sid, this is the point.
 
Instead of making a factual dissertation on the subject, you started off by throwing mud.
 
Your usual posts are usually so full of RHS this and RHS that & I know the code 'cos matrix told me!!
 
And often you are proven wrong, or have been given bad advice.

ORIGINAL: JWE

ORIGINAL: Shark7

ORIGINAL: R8J
el cid,
I'm not sure how much testing you have done.

What would happen if a naval gun, aircraft cannon, torpedo or bomb had an upgrade to another slot?

For example, device number 27 "14in/45 Mk VII Gun" had an upgrade to 25 "16in/45 Mk I Gun" (with an available date changed to 4401). Will the naval gun automatically upgrade?

Honestly I have added guns into slots other than #1-82 and it SEEMS (stressing seems) to work. I had no idea there were slot restrictions on them. Granted this was for a specific unit and I have not yet gotten into an actual surface combat with that unit guess I need to go head to head and make it happen. I could be completely wrong and could have wasted all my time and effort on it...I need to do some more testing with it.

Yes, Shark, and so have I, over the course of 2 - 3 years, and it DOES (stressing does) work.

Perhaps there is a unique advantage to being part of the AE development team, so we got a good appreciation of the original code, by helping develop the new. There is no substitute for understanding what Source does, or how it works. You can test and blather until the cows come home, but if you don't know what the code says, it's all just self-important, self-abuse. Things have several implications, so if you "fix" one, you screw up 3 others.

AE is going to be way worse. If anyone messes with one data point, it will screw up maybe 6 or 7 different routines that depend on that value. There is no substitute for understanding what Source does, or how it works.

Now if we can get a real manual for modders that get specific on what the code does and does not do, instead of the, 'ahem', next to useless one we have to work with in the present, I will be quite excited..

Oh, my....Looks like I have created a maelstrom..

Ok, so I will have to tried in diferent slots and check if it works.

Thank you.

@Fremen: Soy un tozudo de padre y muy señor mío [:D]

ORIGINAL: Shark7

ORIGINAL: R8J

el cid,

I'm not sure how much testing you have done.

What would happen if a naval gun, aircraft cannon, torpedo or bomb had an upgrade to another slot?

For example, device number 27 "14in/45 Mk VII Gun" had an upgrade to 25 "16in/45 Mk I Gun" (with an available date changed to 4401). Will the naval gun automatically upgrade?

Honestly I have added guns into slots other than #1-82 and it SEEMS (stressing seems) to work. I had no idea there were slot restrictions on them. Granted this was for a specific unit and I have not yet gotten into an actual surface combat with that unit guess I need to go head to head and make it happen. I could be completely wrong and could have wasted all my time and effort on it...I need to do some more testing with it.

I know the only problem I have had with modding the high slots are that they do not show up on the production screen, but they do seem to get produced, and they do work. The only restrictions I have found for the 1-82 slot range is that they are to be used for naval guns (as mounted on ships, not CD's) only as per the manual.

ORIGINAL: AlaskanWarrior
Now if we can get a real manual for modders that get specific on what the code does and does not do, instead of the, 'ahem', next to useless one we have to work with in the present, I will be quite excited..

I hope you’ll like the AE manual, then. It should have enough charts, tables and graphs to confuse Pierre de Fermat.

But it’s still very hard to get specific about what’s going on. It’s like the synch bug; somebody (Joe, Don, don’t recall which) said it wasn’t really a single bug, but a collection of many, many, many little things, scattered here & there and used at different times and under different circumstances. It’s the same with hard slotting; many little things.

Some are used by the AI, and are a don’t care for H2H or PBEM. Some are used by AI on harder settings, initial setup, stuff like that, but are able to bite, from time-to-time, in PBEM when something is set to computer control. So a PBEM player may only occasionally see something that might drive an AI player into thoughts of murder and mayhem.

It would definitely be nice to see a list or something in the editor manual, of what you can or can’t move, to maintain stability of the engine. Seen most of it here & there on the forum over time. Nik put a really good list together sometime back.

Ok, so I will have to tried in diferent slots and check if it works.

Thank you.

When you find out the results of your experiments please tell us here.

How the hell do you test when any changes puts you back to square one at the beginning of the war. This is a big frustration for me in trying any test of anything. The only way I can think of accomplishing this is to forgo anything but the most basic items at 12/08, let the scenario run on continuous turns until you get to a point you are able to try out things on the enemy.

How do you all test or set up for a test?

BuckBeach
 
I have "test" units.
 
100 Sqn RAF gets its Vildebeesties manipulated (I also move them to Alor Star to ensure they are in range)
 
IJNS Haruna is my "testbed" for ship changes, Its in place to fight surface battles & ground bombardments.
 
THis way I can see what happens in a day or 3
 
PS  I have tried to set Naval Guns outside the range metioned above, they seem to take on ghost values  ie. Make device 240 a naval gun, it shows on screen as device 40, 5" Gun?

ORIGINAL: JeffK

From el cid

Talking about self important blather

lack of humility about code is not a substitute for understanding it.

Sid, this is the point.

Instead of making a factual dissertation on the subject, you started off by throwing mud.

Your usual posts are usually so full of RHS this and RHS that & I know the code 'cos matrix told me!!

And often you are proven wrong, or have been given bad advice.

It takes great moral courage to work with a program of this sort - with or without code to read.
No programmer or modder is stupid - and even the very best and brightest are bound to be "wrong" -
because of the inherant complexity of the project - because it was not written in a modern system
- because it was never documented in a comprehensive, technical sense - and because many have
worked on it besides GG - none of whom really knew what he intended in full detail. Modders like me
have one other handicap: we are licencees who agree not to reverse compile - or to reverse engineer -
so even if we know how to read machine code or have commenting reverse compilers - we don't use them.
[Not that it would help much - it would take longer than I will live to understand one sub section]
Anyone not talking like this does not undestand the nature of the code - and is more likely to be wrong
than those who do - which includes all the programmers I know who have commented. Some of this is
posted in threads by programmers. If you believe you never make a mistake, do not write code. If you
want to look perfect - never say anything specific which you can be pinned down on in a project of this sort.
Well written code by a single person with a plan and careful documentation does not work the way that person
intended it to - exactly. The more complex the program the more so. The more coders, the more so. The
less budget there is to document - the more so. This project suffers from the triple whammy of being badly
restricted in budget - so no effort was made to document - and almost no effort to test (so we end up with
major options like Russian active not working - and no one suspected it - from the get go) - and then too many cooks
who are blind cooks because of no documentation. Try to be respectful of anyone who makes an effort to make
more things work. The list of things we have got working is long - and anyone who says it is not impressive
is being less than honest. And almost all the credit goes to information provided by forum members, by Matrix,
or from testing. For better or worse - the project is virtually ended - it took far more than the two months I estimated it would -
and attracted a lot more ideas than I expected. We have been able to do many things I never would have believed possible.
If you are not impressed - I don't think you understand what we are working with - or how poorly it once was behaving.
It isn't as good as I would like - but it is nearly as good as it is going to get in this form. It is a fine foundation for the next
stage - and I am glad the decision to suspend development was reversed.

And for the record - I don't sling mud except when it is already in the air and needs to be redirected. I don't approve of being hostile or negative - and I don't see any point in being anything but cooperative or helpful. Those who are upset with me have a philosophy of life I am unable to comprehend and I always stand ready to see them change it. For the record - in spite of some remarks about PAST issues with Terminus - while he never apologized - and while I once wrote he must do that - he became civil and helpful and I have backed off my demand.
I don't understand the persistence of JWE - who also took the position he would never read what I post - a position he has apparently now reversed - in his hostility - but I am not willing to give up hope he too will become honorable (in the sense of not violating the use agreement of the board) and civil - and further I will say he has been constructive and a contributor at times anyway. I used his information - got in trouble due to an omission - but eventually was able to figure out the missing part - and we are better off for it. It would be more fun to ignore negative writing - but it would not produce better product. If you ever believe I am "slinging mud" you have misunderstood my intent - which is always to say "we can do better than that" - if not to say something directly positive. I don't have to proove anything to anyone - my skin is thick - I don't get angry - and I won't become hostile - even when threatened (which has happened). Not my philosophy of doing business.

ORIGINAL: JeffK

BuckBeach

PS  I have tried to set Naval Guns outside the range metioned above, they seem to take on ghost values  ie. Make device 240 a naval gun, it shows on screen as device 40, 5" Gun?

That's the point that baffled me about this discussion from the start. This came up early in the history of the game - apparently devices on aircraft and ships are stored in just one byte in the database, which means it's impossible to use devices with an ID of more than 255. If you put a larger number into the device fields in the Ship Class or Aircraft datasets, the number gets truncated, that is, 256 is subtracted from the device number until the result is smaller than 256. In the WIP Database Editor 6.0, you can see that happening: type a number into the "Device #" field and watch what is displayed in the "Device" field right alongside. Type in, say, "257", what you see after each keystroke in the "Device" field will be, in sequence, "2", then "25", then "1". The WitPEditorX pretends to let you put in a greater number, but if you select a different class, then the original class, you see that just the truncated value has been stored.

So you don't have a lot of scope introducing new, additional devices either for ships or aircraft, just the empty slots (19 if I've counted correctly), and there seems to be no guarantee that you can put just any type of device into any slot and have it work properly. For anything else, you'd have to sacrifice an existing device, and odds are it will work if you replace like with like type. The situation for aircraft armament is favorable, there are lots of German and Italian aircraft guns in the database that have little relevance for the PTO. Ships' guns are more difficult.

ORIGINAL: JeffK
PS  I have tried to set Naval Guns outside the range metioned above, they seem to take on ghost values  ie. Make device 240 a naval gun, it shows on screen as device 40, 5" Gun?

Went back and looked at some of the CHS-based scenario mods, from way back when. Blast from the past, LOL. There’s naval guns shoehorned everywhere, even some extra Brit radars sandwiched in with aircraft ordnance.

Got very curious about your default to 40. Couldn’t find a reason for it, so went in and looked at the scenario files themselves and, yep, the ship weapon id field array tops out at FF hex (0-255 numeric, 256 max). Woohoo! Mystery solved!

Probably why lots of us didn’t pay much attention to big numbered devices; CHS has lots of functional things in 100 and 200 series slots, so … what the heck.

Looks like everything up to 255 is “valid” for the .dat file, but there’s some “special” devices in there, like eng and sup squads and airplane engines that you won’t want to step on.

Hope this helps.

ORIGINAL: mikemike
That's the point that baffled me about this discussion from the start. This came up early in the history of the game - apparently devices on aircraft and ships are stored in just one byte in the database, which means it's impossible to use devices with an ID of more than 255. If you put a larger number into the device fields in the Ship Class or Aircraft datasets, the number gets truncated, that is, 256 is subtracted from the device number until the result is smaller than 256. In the WIP Database Editor 6.0, you can see that happening: type a number into the "Device #" field and watch what is displayed in the "Device" field right alongside. Type in, say, "257", what you see after each keystroke in the "Device" field will be, in sequence, "2", then "25", then "1". The WitPEditorX pretends to let you put in a greater number, but if you select a different class, then the original class, you see that just the truncated value has been stored.

So you don't have a lot of scope introducing new, additional devices either for ships or aircraft, just the empty slots (19 if I've counted correctly), and there seems to be no guarantee that you can put just any type of device into any slot and have it work properly. For anything else, you'd have to sacrifice an existing device, and odds are it will work if you replace like with like type. The situation for aircraft armament is favorable, there are lots of German and Italian aircraft guns in the database that have little relevance for the PTO. Ships' guns are more difficult.

That's it; right on the nose. Single byte field in the wpc and wps .dat files. CHS has functioning naval devices (on ships) down to, I think, 231, so .. so long as you don't step on the restricted devices, everything down to 255 should work - at least there is no engine limitaton to their doing so.

So moving land devices to higher slots will free up Naval and Aircraft ones? And will those land ones work?

Thanks JWE,

I'll work on lower numbered devices then.

ORIGINAL: Dili

So moving land devices to higher slots will free up Naval and Aircraft ones? And will those land ones work?

No ... because the land slots appear at 258, which is bigger than 255. Moving land stuff to bigger values will work, but it doesn't free anything else up.

An important differentiation: since the class and ship .dat files won't recognize a number bigger than 255 in the weap num field, ship-borne naval weapons should reside in the byte wide 256 slots from 000 to 255.

Ground stuff, like in the wpl .dat files, have way bigger array values, so you can put a naval weapon (as in all the CD guns), anywhere, up to 999.

It's all in the value size for the different fields in the different .dat files.

I'm lost [X(][X(].



Ok. I'll try to add Axis Infantry Squad wherever I can [:D] and test what happened.

Squads should reside in the range Matrix used in stock - or in the blank slots between them. In general most devices should also use this pattern. At one time CHS and RHS experimented with lots of out of range devices - and enough problems were detected that Andrew and I independently concluded it was better to stay in the stock range (at almost exactly the same time - so when I reported to him he said he had just figured it out). Then Joe said we were right - that a surprising number of slots have hard code related to them - and good performance required being in sync with that.

Above a certain slot - it is in the Manual - land production does not work properly - and while devices "work" - their pools don't work well. [Sometimes a thing gets dropped into a pool when some unit upgrades or something - but most of the time the pools don't get any replacements - even if you set it.] I use the higher slots for devices which are obsolete - which will never produce anyway - and which are also land devices. This works well because you don't care about replacements or production for such devices. Slot limits are a severe issue for modders.

The compromise solution is to find and combine duplicated devices, to find and use empty slots, and to combine similar devices into generic devices. All these things give you more slots for devices you want to add. You can get very creative with combined devices. And there are a few devices identical in performance you can also combine unless you want the chrome of a "proper" sounding name.

No ... because the land slots appear at 258, which is bigger than 255. Moving land stuff to bigger values will work, but it doesn't free anything else up.

An important differentiation: since the class and ship .dat files won't recognize a number bigger than 255 in the weap num field, ship-borne naval weapons should reside in the byte wide 256 slots from 000 to 255.

Yes. My mistake, going only with memory and tought land devices started earlier.

ORIGINAL: Dili
Yes. My mistake, going only with memory and tought land devices started earlier.

No worries.

Special land devices (engineers, support, etc.) do start earlier, as do certain production items and aircraft weapons and ordnance. The Devil is always in the details.

There is no fundamental limitation in the engine, however, there is a limitation to the recognizable slot numbers for “class/ship” weapons based on the single byte limit (0-255) for numeric entries to the weapon field in the scenario files (all fixed in AE, but of no use, here).

Class/Ship weapons – device slots 0-255, wherever they can be sandwiched in, taking very good care to avoid stepping on restricted slots.

Land Weapons – any device slots 256 and up, again taking very good care to avoid stepping on restricted slots.

Restricted slots have been described elsewhere, and are scattered throughout the system.

Do you know if this limitation will happen in AE too?