555 replies to this topic

[Nyerguds]

Seems I somehow broke the ini dump function. I'll look into that later :|

[edit]

Turned out to be more serious than I thought. The whole "movement types" system had been broken for a while. I wonder why it didn't crash on this before.


Anyway, fixed in v1.19.1:
http://nyerguds.arsa...tor_v1.19.1.zip

[edit]

Updated the rules.ini dumps on my website with dumps from the newest version.

[Nyerguds]

I post an update after a year, and no one even notices?

[MrFlibble]

Sorry, I've been pretty busy lately, and only check stuff on the Internet sporadically. As always, you did an awesome job implementing new;y discovered things into the editor

Nyerguds, on 04 September 2011 - 10:50 AM, said:

• The thing I identified as "units can enter" on buildings, almost completely at the beginning of the development, amazingly turned out to be (byte #2 of) a prerequisites-like list for allowing specific units to enter a building. The reason this was "0/1" for one of the bytes was simply because the only activated data in that byte, for both the repair facility and the refinery, was the harvester, which is the first bit in it. This means you can now let ANY unit be repaired. Odd detail: apparently the MCV is NOT set as Allowed to Enter by the repair facility.

This is probably the most interesting bit of what you've listed (I guess there's more?), I remember it seemed weird that the option to enter structures was some odd value in that old DUNE2.EXE editor where it was first defined (it was shown as something like -128 or whatever; but that editor had plenty of such values, due to some options not having been correctly identified and/or broken down into separate sections)

[Nyerguds]

That was probably the second lowest byte then. For the repair bay, the bytes are 00 01 FF 80. for the refinery it's 00 01 00 00.

That FF byte of the repair bay is indeed -128 in decimal, but in reality, the value is the full 4 bytes.

I'd never have realized this without the OpenDune code though.. just as I would never have realized that tons of the previously-unknown values at the start could never be identified because they were shared by units and buildings, but completely unused by one of them.

[Nyerguds]

Now I think about it, that kinda strokes with these old inis we found in some other Dune II version. Units and structures were one single list there, IIRC.

[MrFlibble]

There are, in fact, two lists, one called [CONSTRUCT] that includes both structures and units and another titled [COMBAT] which is only about units.

For some stupid reason I can't attach the zip file with the old INIs though.

[Pokota]

I was wondering why, when I tried messing with it, a harvester with movement type "foot" kept exploding when it started harvesting.

[MrFlibble]

Pokota, on 11 November 2011 - 03:50 AM, said:

I was wondering why, when I tried messing with it, a harvester with movement type "foot" kept exploding when it started harvesting.

This is the result of animation differences between foot units and vehicles. Namely, foot units cycle through several neighbouring frames for movement animation, while vehicles have only one movement/standing animation. When a unit with vehicle graphics tries to cycle through frames like an infantry unit would, it gets into an explosion animation, playing which destroys that unit (meaning that unit destruction is linked to the animation, and playing it means destroying that unit; the UNIT.EMC file must be responsible for this kind of cause-effect stuff).

[Nyerguds]

Huh, seeing as the harvester has its own custom movement type, I wouldn't even think of changing that. I'd immediately conclude that it would somehow remove its harvesting ability

[dementine]

hey everyone,

Do you have a version of Dune II editor that works with super dune classic ?

nice to see this community is alive and well, cheers

[MrFlibble]

Hi! The curent version supports Super Dune II Classic, you just need to drag-and-drop the SD2 executable over the editor's executable to open it.

[dementine]

ah excellent, much appreciated!

cheers

[MrFlibble]

Hmm, just checked the Files section, and the sizes for PAK files seem to be all wrong in v1.07 (haven't checked v1.0 yet). I wonder if those are really used by the game, 'cause if they are, this certainly leads to some spectacular file size miscalculations...

[Nyerguds]

A lot of data like that is in fact filled in on startup. I'd assume it's the same with those. The ones visible in the editor could just be some original data from some old internal beta.

[MrFlibble]

Which basically means that fixing the file sizes isn't going to positively affect the game (e.g. the sound issues with Windows*)?

* I've had reports that even with the speech files fixed and XMS properly configured, there's still unstable behaviour when playing under XP, especially noticeable if played for a long time. Didn't have any time to test that myself though.

[Nyerguds]

It's just an assumption. The unit data have a "choam status" field like that. You can always try it out, see if it helps.