Mi-28 Working Instrument Needles

This is a minor release to add working needles to the Havoc cockpit

====================================================================

Version 1.16.1 minor bug fix

Changes:

- Havoc cockpit now has working needles for instruments
- Left/Right Engine RPM shown in Rotor RPM gauge
- Status Panel Lamps working
- Threat Warning Display working (needs reworked as using Hind threat warning) - many thanks to thealx for the help
- Warning Panel Lamps working
- Master Alarm lamp working
- Chaff/Flare lamps now working (including damaged state)
- Weapon panel lamps now working (including damaged state)
- Wut text on startup screen moved
- Menu screen title font changed to help it scale better

To install:

Delete the following folders;

cohokum\graphics\textures\cockpit\mi-28-cockpit

cohokum\3ddata\objects\Mi-28_Havoc_Instruments

Reason for deleting these is to ensure the textures and object files are refreshed, as some of them have been reworked.


Extract the archive and copy it into the root folder of your EECH game e.g. where the cohokum folder is. Replace any files if it asks for overwrites.

MAKE A BACKUP IF YOU WANT TO REVERT CHANGES

https://drive.google.com/open?id=0B_9WsInmSbhuMDMtbVdBVkhaWmc

Hi. I have fly around for a while, everything works properly - great job.
One thing I noticed - rotor RPM dial also should have engines torque needles. As torque grades to the right are not available, it's only way to know engines state so I think it's important, but it's your choice anyway.

As for code changes, I have some notes:

1. You should never use something like "01" in version number. Thing you may want to use is build number (under minor version), but we have no such so only possible solution is make it as "1.16.1". It doesn't mean this version should be released immediately - you can wait for a while until other modders (including me) will finish their tasks, so this one can be named as 1.16.1a or whatever (APP_NAME is a string so type there anything you want), but MINOR_VERSION is integer - please revert related changes in the code.

2. you have commit changes in CMAKE.BAT, DMAKE.BAT files. it's not a big deal but next time please exclude them. no need to fix anything, just leave it like that.

I was hoping to get the bars for the engine gauges working, so I didn't add them. Also, the only texture with the Ng on that dial, is the night cockpit. The day texture only shows Rotor RPM. I also couldn't find any decent reference for the real thing.

As for the version number, I was trying to make it different from the current release, which I thought was 1.16.0. but now I realise it's 1.16.1, so I'll change it. It formatted as a decimal, so needs to contain a number. Maybe 1.16.2.

I added *.bat to the gitignore file, so I'm not sure why they were added. It doesn't seem to ignore them.

You are planning to use texture animation, but not sure it's good idea - we can't expand it's functionality since original release, and I am not sure it will work with OGRE implementation in future. Texture animation is applying to the surface of the model, other words you are applying some pre-defined texture to the polygons, set animation name for the surface, and then game manipulate with this texture.
Instead you could use the way which modern cockpits using - subobjects manipulation. Arneh usually placed lamp polygons as subobjects into the scene, and make code to hide (lamp inactive) or show (lamp active) them. I have tried another thing - lamps are always presented in the scene, but they are closed by shatter - simple non-transparent polygon, when it's hided - lamp is active. Both are complicated, but with texture animation you have really small chances to succeed, especially without background knowledge.

I have pushed working threat warning lamps for Havoc - code and subobjects was taken from Hind (copy all mi24v_rwr***.eeo into Mi-28_Havoc_Instruments folder). You can see on example how lamps presented in the scene, what labels has and how placed. You should notice that parent NullObject has rotated and positioned to fit original Hind's lamps into Havoc cockpit object.

Last release is 1.16.0, you can see it in the GIT log (yellow tag), so this one should be 1.16.1

Ok, thanks for that. I was taking advice from Firebird about the texture animation, as that's how it works in the Hokum.

What triggers the animation? For example, how does it know which rwr light to light up?

I'm also thinking more about the Rotor Brake for example, what ties pressing R to trigger the animation?

Default Havoc functions calculates which lamps should be active, their states saved in the "havoc_lamps" so you don't need to change anything here. Previously this data was used for drawing, but it will work fine for texture animation, sub-objects manipulation and any other goals.
So flags still updating at the background even if lamps not appear in the cockpit, only thing required is use this data - you can see new function was added "update_threat_warning_lights", here these flags checking and related lamps appear or disappear in the scene:

rwr_above_light->visible_object = havoc_lamps.threat_warning_missile_above;

Rotor brake, and other avionics states, stored in another place - current_flight_dynamics. but in the Havoc's "update_status_panel_lamps" function you can see existing string:

havoc_lamps.status_16 = get_current_flight_dynamics_rotor_brake ();

So to get rotor brake state, you can use "havoc_lamps.status_16", or "get_current_flight_dynamics_rotor_brake ()", or "current_flight_dynamics->rotor_brake". First one is preferable as you can control it if necessary - disable all lamps if electricity power is turned off, for example.

Ok, thanks. I'm understanding it now. I'm still working out how the LW scene is linked to the code for various things.

There's a lot of code commented out with #if 0 blocks that seemed to be added with the Direct3D9 conversion, so I wasn't sure how much of it was still usable.

I'll try and get one of the lamps working using these methods, and if it's successful I'll do the others.

Do you think I should create new RWR objects for the Havoc, or just reuse the Hind ones you've added? I'm sometimes not sure about reusing code and objects from other cockpits, in case someone makes a change in one place that breaks other cockpits. For example, when I was doing the Havoc instruments, there's code in ha_instr.c that is used by the hind, but not used anymore by the Havoc. But when I removed it, the Hind cockpit broke.

I think it will be properly to rename objects mi24v_rwr and do the same in the scene (you can use text editor to replace MI24V_RWR_ with mi28_rwr_ or something similar in the LWS file). However, it's not necessary as lamps objects should be copied to the Mi28 scene without any changes anyway. Code I added was just example but not finished mod, so feel free to apply any changes.

It's not usual that some code from single cockpit used by other one, normally such functions should be moved to the COMMON section. but it happen, yes.

Do you know why when I open the rwr objects, they look for .tga files, but all the texture files are .bmp? It's really annoying to have to select every texture file when loading a scene

When converting eeo to lwo, you can specify textures search directory as an additional parameter. Result lwo files will refer existing texture files and not potential ones.

There is no limit in animation texture usage anywhere.

Ah, I didn't know it took parameters. I'll convert them again, as I just had it in a batch file anyway.

wow is a useful information.
Firebird or thealx You have a script that automatically converts all files in folder to lwo or eeo?Is there any way to convert multiple files at once?

I just list the files in the cmd line, then copy them into a text editor. Delete everything except the file names. And then on each line, just add the command that you would run manually.

Then save it as a .bat, and run it from the cmd line.

I was thinking of writing a shell sript that could find every .eeo in a directory, and convert it to a .lwo, but I've not got round to it.

You can do things using a tool called sed in a shell script, that can find an manipulate strings, and you can add some parameters.

For example, this is a snippet of the one I used to convert all the hind rwr files...

nice idea, But it still takes a lot of time.Thanks, see how it works.

Yeah, but it's still quicker than doing each one. You can just copy/paste the file name twice, then use find/replace to change one of the eeo to lwo.

I do the same. Drag'n'drop feature can be useful when you need to convert several objects quickly, but it's not available.

hmmm in totalcommander is great multi rename tool.Check that it will not be useful in this case.
dont know if this only for files, or also inside txt working

Notepad++ has such features. A really good editor, even useable for coding and completely free.

I wish I'd looked in ha_avlmp to start with. It makes much more sense. I was looking in ha_lamps, which I suppose must be old and unused now?

I've now got the status lamps working. The link in the first post has been updated.

Let me know if there's nay problems.

woow you are getting faster.downloading and testing

I've not checked it in the Dawn/Dusk/Midnight textures. I used the daylight ones to make the lamps, so they might not line up or look right.

And the hits keep coming...

The warning panel lamps are now working. Link updated in first post.

That'll do for today, time for sleep.

Hi messyhead. Great work!!!

Had not much time for EECH the last few days, but I look forward to do a ride in the new cockpit the next days.

The few time I have at the moment I try to finish the KA-50 model. I also started a bit with the KA-52 and the MI-28, but it's a lot of work because I have to change many things in the models themselves too, for fitting with the new textures.

There's new exe files in the link on the first post.

I had built it on the branch of code that thealx was working on for cockpit improvements.

I've not changed it to use the last 1.16.0 release, and updated that instead.

I didn't want to include things that are work in progress.

I've now added Engine RPM (left and right) needles to the Rotor RPM gauge.

You'll only really notice them if you use manual engine startup.

Link in the first post has been updated.

Yeah! Soon we will have a great fully working MI-28A pilot cockpit again. I missed it so much.

The day you are finished with it, I will spent a few hours with the MI-28 in flight

Hope I get the external skins for it also finished the next time.

I've almost got the master caution working, but it's flashing black instead of red.

Chaff and Flare should be quick as well.

The weapon status lights will be trickier. Mainly just due to the awkward angle that they're at.

Don't expect the engine gauges soon though.

Master alarm, chaff, and flare lamps now also working.

I hope I can also present some new results here, but at the moment I'm fighting a bit with the 3D model which does not want to do what I want

The weapon panel lamps are now working. Link in the first post has been updated.

I think that's now all the needles and lamps working apart from the engine bars, so unless I've missed anything, this will be the last main release for this.

I'm going to experiment with getting the engine bars working, but not sure if they will work, or how long it might take.

No problem . I need more time too for making the new skins.

I was nearly finished with the KA-50, but then I messed some things up. And the fool what I am, I have also made a backup from this new BS, which had also overwritten the last good version I had

I always made another name for example ka50.lwo ka501.lwo ka5011.lwo ka50111 safest method.

Yes I did this too and had about 20 backups for every step I made. Then I tested the last version and deleted the rest for saving space. This last version I accidentally have overwritten with a version which was messed up. I also cleaned the recycler before, so no way to get the last good version.

Now I make backups to a USB-thumb also. Don't want to start nearly from scratch once again

So glad that I had the model with all the seperatet surfaces at least, but all the texture work adjusting the maps to the model is lost.

messyhead, have you tried to compile latest master branch? I am experiencing stability issues, particularly - with debug build game crashes before campaign loaded, or right after. Afognak, Yemen and many others.
But I am not experience problems with your build (I suppose it was made from test branch), neither with build, made from my latest commit (1cddd520346134b925ebefbb5e1d252aadcd1204). Can you please ensure that game runs smooth with latest changes, so I will know where to start looking.

I'll have a look later. I'm not sure how the changes I made would affect the campaign loading though. I did see some ctd on maps with the last 1.16 release as well though, before my changes. I always use Lebanon for testing, and I tried afognak as well, but in free flight rather than campaign mode.

Do you need to use different linklib files now that it uses D3D9? I'm still compiling using the DX7 ones.

I've just compiled the master branch, and I'm not getting any crashes when I start the campaign on Afognak and Yemen. The only map I seem to always get a crash on, regardless of the game version, is Cuba.

Are you getting any error in the logs?

no, I am still using same lib files as before, they DX9 actually with backward compatibly.

sometimes it just crashes, sometimes assert is triggered. nothing really helpful. I will try to compile different commits just in case it will appear on some of it.

If you don't use DX9, will the D3D9 not work? Should I be using DX9 libs from now on?

I had always use DX9, at least DX7 libraries caused errors since I came here (Jan '14). That shouldn't be a reason of compilation errors, as you didn't applied changes to the rendering code. But it can be Watcom compatibly issue, or even hardware compatibly. Still trying to find some time for experiments.

I have checked torque indicators code - I am not sure how exactly you expected it can work, draw_havoc_engine_bar uses 2D draw functions that no longer longer work with the 3D cockpit. You can't just copy old code, it should be modified for sub objects manipulation, or texture animation.
I have changed trq_gauge object and added function to control it's scale->y value, that's the way how usual instruments works. You just need to set in the scene parent's position, and object rotation (to fit cockpit surface), other indicators can be added same way.
And, are you sure you have used exactly the same function as in the 1.15.0? as this particular bar behave differently.

Thanks for having a look at that, and the advice.

I'm confused though. Why does the Comanche and Apache MFD gauges work, as they use the 2D draw functions to draw the bars on the engine pages.

I was trying to basically use the same functions as they use to draw the bar on a texture. Almost like the engine gauges were unique MFDs. That's why I reused some code from those.

I had discussed a while ago with Firebird about doing it using a 3D subobject, but wasn't sure how to approach it.

Also, this experiment was also to learn how to do it so I can later use it in my Blackhawk. In the Blackhawk bars, the colour changes as the bar increases, so I'd have to work out how to do that. With the way the comanche torque bar works, it changes colour if it's over torque.


Just to add, I don't have a problem with doing them as 3D objects, as I'm pretty familiar with that. But I'd like to know why the 2D draw functions work in some places, i.e. MFDs, but can't be used in others.

Rendering on texture applied to the texture name, not sub object. I think surface field "Comment" also used, but not really remember details. So to make it work, "eng_trq_texture_screen" has to be linked with this texture both in the Modeler and code (not scene editor), so function "draw_havoc_engine_bar" will render data somewhere.

Ok thanks. I did mean to check the texture comment, but not had time to work on it recently. Home improvements and DIY have taken all my time recently.

Your new lamp textures have an incorrect size.and this version NOT have the new lighting other cockpits.

This is still based on the old EEAH cockpit models, so it won't have the lighting applied.

Can you explain what you mean about the textures having an incorrect size?

I wrote once in your blackhawk
texture should be divided by two for ex 128x64 128x32 1024x512 type textures 162x48 can cause ctd.

Ok, well I'll rework them when I have time. I usually end up cropping the image to only what's needed, so end up with those sizes. I suppose I'll just need to make the canvas size correct, and have blank space around the image.

maybe just try to resize, they are not big differences.

Resizing wouldn't work for all of them, unless I make them quite a bit bigger than they are. So 164 x 48 would need to be 256 x 128 to avoid it being cropped, but would leave some blank space around the image.


Is the rule just that the proportions can be divided by each other equally? I see some textures are 256 x 256 and 512 x 512, but also 256 x64.

Which one were you seeing that was 164 x 48?

from what I know can be (examples, not all)
128x16 128x32 128x64 128x256 128x512 and so on . 164x48 it's not good.
yes, resize to a larger size is the simplest.
or to a smaller, rather, there should not be any change on the model
making white space is a lot of work.

The engine status gauges are not in the description up front, so I don't think they have been hooked up. Maybe messyhead will add that in later. I seem to remember a discussion on how to do the engine gauges in another thread for the Blackhawk, so maybe they haven't figured that out yet.

Sorry, I meant to reply to this. It was tricky for me to get the engine bars working. I tried out a few ideas, but couldn't quite get them to work. I think someone was also talking about building a new modernised cockpit for it, as the one in game is from the MI28A, but the model is designated MI28N, which had more digital displays in the cockpit.

Yes, it was upgraded and has 2 MFD's. It looks like this:
Mi-28N Cockpit

The Mi-24 was also upgraded with 2 modern MFD's and renamed the Mi-35, it looks like this:
Mi-35 Cockpit

Hi Messyhead, I took a look in LightWave at your Mi-28 needles file. I see a slightly different model for every needle. Can't we do it with one needle model copied and renamed 20 times, then inserted into the scene file? I can handle the start position and movement with one equation, resulting in one simple rotation command. A little easier than altering the model for every gauge. And how do you place the needles into the scene file in the correct spot? It seems to me that would take either a lot of trial and error, or some way to insert the textured cockpit in as a reference.

I moved your post into this thread.



I had to use separate needle objects. If you used one object, copied it, then renamed and moved it to the right position, then when it loads, it would have given the single object the new position. I think I might have tried that and found problems. If you can work out how to do it with a single object, then that would be better.



To get the needles in the right place, I opened the cockpit model, then added each needle to the cockpit in a new layer, and positioned it in the right place. I then saved each needle as a separate object in the rigt position. Then when I loaded them into the scene, they were in the right place. I also loaded the cockpit model into the scene to check, and then removed the cockpit model before saving the scene. I find the scene editor quite tricky to use, in terms of being able to move things around. I keep meanig to try and find a good tutorial on using the scene editor.

Thanks, I doubt I'll find a better way than you have, just asking the question.

That makes sense, use the cockpit model. Of course.

I need to find some basic LightWave tutorials myself. I know Inventor, Autocad 3D, and Solid Works from work, but LightWave is very different.

Some useful keys I tend to always use;

Space bar - switches between selection modes: point, line, polygon. I tend to stay on polygon
/ - deselect current selection
- (as in minus key) - hide selection: this is useful to remove surfaces that you don't need to see, or if a surface is behind another.
\ - unhide all
Shift \ ( | pipe) - hide inverted: this shows what's been hidden, and hides what's visible. So switches hidden.
] - select all connected polygons
Shift a - fit selected polygon
Ctrl a - fit all
" (quote mark: Shift 2 on UK keyboards) - invert selected. So selects everything not selected, and deselects what you selected. This can be useful to quickly hide everything. Select a surface you want to work on, invert everything, and hit the hide key.

In the perspective viewport
Alt and L mouse - rotate around view: this rotates around a centre point of your current view, not the current selection
Ctrl Alt and L mouse - zoom in / out
Shift Alt and L mouse - Move view about

Modify tab
t - move the selection
y - rotate the selection
h - stretch selection
Shift h - size selection

You can also hold Ctrl before using a modifier, and constrain the movement to one direction.

You can select a modify mode, then hit n to bring up the numeric panel, and change something using values instead of moving the mouse.

If you're in a modify mode, hitting Space bar will get you out of it.

Texture related
q - Change surface: used to assign or create a surface
F5 - surface editor (this is probably where you'll need to look up some tutorials)

In the bottom right, you'll see 5 letters W, T, M, C, S. T is textures. If you select that, then the dropdown shows all the existing UV maps.

Each viewport has some dropdowns at the top that can be used to change a view. If you set one of the viewports to UV, then select a UV map from the dropdown in the bottom right of the screen, then the UV map will be shown in the viewport. You can also show the image for the UW map, so you can see how the textures are mapped.

Other stuff
i - information on the current selection: can be useful to find the surface that is assigned to the selection
w - statistics: you can use this to select different surfaces by their characteristics. For example, all polygons with a certain surface

At the top right, next to the name of the model there is a number, then some boxes, split diagonally. These are the layers. Everything is usually loaded into layer 1, unless the model is saved in layers. You can split an object to layers, by selecting some polygons, cutting them (Ctrl x), then selecting an empty layer, and pasting. You can then select individual layers, or Shift L mouse click to select multiple layers. If you click in the bottom half of the split layer box, it will show the layer as an outline.

Layers can sometimes be useful if you're working on smaller details.

end - collapse all layers to one layer. You'll need to do this before trying to convert to an EEO or it won't load in game properly, if at all.
home - delete a layer
insert - inserts a layer
F7 - shows the layers panel. Useful if you end up with a lot of layers, and you can name them as well. For my Blackhawk cockpit, I had 15 layers.


I hope that's some help.

messyhead THANKS!

This makes things so much easier to remember after two years of abstinence

The last evenings looked more like this

Thanks for that, printing it out now!

Thanks messyhead,maybe worth add your post to eechcentral. Very useful.

My few tips.
In scene when you click on any part cockpit,in left down corner show you what name this is in modeler (4251.lwo )
Monitor texture in modeler MUST BE bmp,not tga. Any other textures you can use tga or bmp. But monitor bmp.
You need set surface monitor luminosity to 100% .

Ah! I didn't know that. I was trying to get a monitor working in my blackhawk and nothing would show up. I'll need to check the texture.

Yeah, I should probably do that. I keep meaning to write up some guides to what I work on

Yes,someone can waste few hours to find reason why mfd not working.

I was trying to create a small mfd for engine gauges in the Havoc, and also the display for the digital readouts in my blackhawk cockpit. I'm sure I had all the code and model correct, but I think now the texture was wrong.

I might try it again tonight.

I dont know how add NEW Mfd in modeler. For me works only copy old and paste in another place. If i made new mfd surface,all the same as original it not working.

Interesting. It's probably because an MFD texture gets written to in the code every frame, and maybe the code can only write to a BMP texture. I'd have to really dig to find it, but I'll bet that's the reason. I'm going through the MFD code right now.

I added the object to the scene using a bmp, but it just shows as a black surface in the game. The mfd still isn't being drawn onto it.

Are you looking at the branch I made for the engine bars?

I remember working out how to use existing code with an existing mfd in another cockpit, but not how to add a new one.

If you talking about mi 28 mfd this is not editable. Thealx made editable mfd in apache gunner,and in ka50 is copied from ka52. im not programmer but only one way is delete old mi28 mfd and paste new one from ka52.

It's not the main mfd that I'm working on. I was experimenting with how to get the engine gauges working. I thought I could make small mfds, and have the bars show on that. Similar to the engine bars that the Apache uses, for example, but then make them look like the mi28 ones.

I'll post some screens later to show what I mean.

I'm looking into adding a new MFD in the code for the Havoc engine gauges. The part I haven't see yet is I haven't gone into lightwave to find the cockpit object that matches the code. I'll look into that this weekend. I also want to add a FLIGHT MFD to the export screen for the exported MFD's for the secondary displays. My simple home cockpit is the target. Some of the helos don't export anything, I want to fix that. I think I have a rough understanding of the code now, I'll test that on Saturday.

Yes, Javelin this would be a great thing

I think AndyB will also be pleased to hear this. Didn't know how he managed it now to get his MFD's working in his simpit. Years ago he used a program called MaxiVista but since Windows 7, I think this does not work anymore. Never had the time to test it, cause I sadly had to do much other things before I was able to come back to my hobby.

I'll email you my files later. I'd started on this too a while ago

Thanks Messyhead, I got the email. The trq_gauge.eeo file is the one I really need the most.

I've been digging through the code, so far I've found a number of locations where the code needs to be altered.
In _vckpt.c there is a define section, initialize, deinitialize, and draw sections that reference the MFD. All need changes to add a new MFD.
in _mfd.c the are the same sections, plus draw_to_texture for exported mfd's, and a draw_to_screen section.

There is also an overlay MFD section in _mfd.c, not quite sure what that's for yet.
This one is interesting because it renders directly to a transparent quad on the screen, not through a separate 3D MFD object.
If I can figure out how to convert the coordinates to a location on the cockpit model, this might be a direct way to add the engine gauges.

I'll know more after I try a few experiments this weekend.

Exporting the MFD's to a second monitor is not really very hard. You turn it on in the ini file, and in Windows you have to place the second screen at the upper-right corner of monitor #1.
I have a mini widescreen monitor that fits the Cougar F-16 MFD button frames on it on a piece of plexiglass I can take on and off. Positioned right below my main monitor, it works great as a set of MFD's. Was about $60 for the Cougars, $50 for the monitor.

http://simhq.com/forum/ubbthreads.php/topics/4430043/exporting-mfds

As far as I remember, in textname.h, you have to list the names of the textures in the scene. So in there, you put the name of the texture that the MFD should be drawn, preceded by TEXTURE_INDEX_ (just for info, 3dmodels.h is a store of all the objects, you probably already know)

Then in ha_ebars.c I had these sections, which references the texture.



So I thought that was what was needed to get an MFD to draw to a texture, but it doesn't work in the code I added. I could create new MFDs in the blackhawk on a new texture by re-using code, and setting a new texture name. But for the havoc, it wouldn't work.

I hope you manage to work it out further than I could. It would be really useful, as then it would open possibilities for other displays. Especially in my blackhawk cockpit, as I wanted to add displays for the digit readouts on some of the gauges.

Maybe you can see in apache cockpit how this is done?gunner mfd was uneditable, thealx made it possible to edit.should be a solution there.

It's the same as I described above. I went through the existing code to try and understand it.

maybe stupid question, but not better just pm thealx than waste x days to find solution?After all, answer is a few sentences.

Personally I'd rather be able to figure it all out, then I would have a better understanding of it. Perhaps Javelin would be the same. And anyway, thealx hasn't been around for a while, so could wait x days for a reply.

Ok understand .it was just a layman question

Yah, give me a week or two and we'll see far I get.

I made this in a very similar way in my pit and also used an old flat screen behind my panel, leaving a hole behind the MFD displays.

Sadly I never had the time to test the screen exporting with EECH, cause I also wanted to make the pit compatible with BMS, DCS and the FSX. For those sim many solutions exist and I wanted to get this running first, cause I thought this would be much more simple than EECH. After finishing the work at those simulations, I wanted to do the harder work and get EECH also running. Sadly I never got that far.

Hi Viper1970, exporting MFD's in EECH is a piece of cake. Hook up a second monitor, use the ini file settings in the following thread, and you'll be up and running in minutes. Read down through the thread until you find my MFD picture post with all of my settings.

http://SimHQ.com/forum/ubbthreads.php/topics/4430043/exporting-mfds

Not all of the helos export an MFD, the Blackshark, Hind, and maybe one or two others don't. I'm fixing it.

Javelin, thank's for this!

I will take a look and hopefully could use this information as soon as possible. At the moment the whole pit project looks more like an Apache hit by a SAM

As soon as the rest of the new flat is ready, the work at my homepit will start again

OK, I'm back working on the Mi-28 Havoc Engine Gauges. I have a couple of questions:

The trq_gauge.eeo object is included in the current set of objects in cohokum\3ddata\objects\Mi-28_Havoc_Instruments\ directory, but is it being rendered? Do I need to switch to a new HAVOC_VIRTUAL_COCKPIT_INSTRUMENT_NEEDLES.ees to get it to render? (The one you emailed me perhaps?)

I see TEXTURE_INDEX_HAVOC_TRQ_GAUGE in the textname.h file in your branch, but is it attached to the trq_gauge.eeo object I have in my running version of the game where the trq_gauge.eeo is located? Can I just insert the index name into my textname.h file and run with it or do I need a new trq_gauge.eeo file with the texture attached?

I'm going to try it with the ones you sent me in the email and see what happens.

I don't see any code in the Branch to alter the texture for the engine gauges, did I miss it?

I see the Black Strip rendering now. The texture (HAVOC_TRQ_GAUGE.bmp which I edited) does not show up. Does that mean the Object trq_gauge.eeo does not have the texture attached to it? I also need the object large enough to cover all of the vertical engine gauges, not just the left two. I intend on making the texture transparent and drawing all of the engine gauge bars to the same texture. Is the object something one of you guys could fix for me? Viper maybe? I don't know Lightwave at all.

Ah, the trq gauge isn't being rendered. This was my attempt to create an "MFD" style display that the engine trq bars could be drawn on. It was all experimental. The furthest I got with it, was to have a black texture displayed, but nothing would draw on it.

My changes to try and get it working were in this branch...

https://github.com/enemy-engaged-developers/eech_source_code/tree/develop_1_16_1_havoc_engine_bars

No, it is being rendered, there just isn't a texture attached to it. I edited the black texture and the changes didn't show up.

Ok, let me check the code to refresh my memory. I remember it just showed as a black rectangle in the cockpit.

It won't be in the code, it would be in the definition of the 3D Object when it was saved, in trq_gauge.eeo. Doesn't the texture get assigned and given u-v coordinates in Lightwave?

trq_gauge.eeo does have a texture called HAVOC_TRQ_GAUGE.bmp in lightwave.



I think the way it works, is that you tell the code which texture to render the MFD onto. So the texture itself won't show as anything, and instead just be the surface that the MFD is drawn onto. At least from memory, that's what I figured out. So I thought the fact that it was black, meant that the code was seeing the texture to draw onto, but not drawing the MFD.

If you had the object there without the code, it would show as the textured surface.



I can resize the object to cover the both gauges and send it to you.

I'll send you the LW files as well

Roger. I just have the object there rendering with no support code yet. I know what pieces to add in so I'll start on that. I was testing it to see if the texture was connected.

Put in a texture that's a different color from black, like red or green so you can see it.

The texture is 2 different brown strips.

Ok, everything for the instruments is in this folder.

https://drive.google.com/open?id=1UYw9IFvBonVSUra1lOg8aSYcgtKuFhoH


I updated the trq_gauge.lwo and the HAVOC_VIRTUAL_COCKPIT_INSTRUMENT_NEEDLES_engine_mfd.lws files. You'll just need to convert them into eeo/ees files.

Roger. I've got the code in to write to the texture and turn it gray so I can see it write.

Dang, still not working. I have a larger black square now, no texture. I'm going to have to research the regular MFD textures to see if I can figure out what's different.

Yeah, there's something hidden. I spent a while searching, but couldn't figure it out.

Round two didn't work either. I guess it will have to wait until tomorrow before I try round three.

Messyhead, I have a question... Which way is the quad facing for the engine gauges eeo? If it's backwards (facing away from the pilot) that might be why it always renders black.

messy
for a try you can copy this mfd paste, turn it over and leave both in another place .if it is, it should work. also remember about 100% brightness

Tried a few other things, like rotating the HAVOC_TRQ_GAUGE object in the cockpit, which worked after I added it to the SUB-OBJECT listing. I know I've got the correct object.

Until we can get the object to render in the cockpit with a texture, there just isn't anything I can do to get it to work.
All I can think of is delete the current Object, then copy a working Object with a texture (please bigger than two dots) to it's location, name it HAVOC_TRQ_GAUGE and we can try it again.

thealx wrote once that only this cockpit does not meet any modern standards.
it has bugged not working lighting, the textures are darkened in different parts(this is my experience).and you need all the surroundings copy everything from ka52.I do not know what that mean , and I suspect that's what it's about.
that it is still this bugged old cockpit, not modern with proper lighting as in all others.probably that's why it does not work.
maybe try do this in another cockpit? ka50 for example.
and if it works, it will simply remove the old ka50 cockpit and paste the new (old) mi28.

Banita, What does 100% brightness mean? It looks like I'm going to have to learn some Lightwave in order to fix this.

I don't think 100% brightness makes a difference. Other models have MFDs, and the surface they use isn't set to 100% brightness.



The cockpit already has one MFD for the TV screen, so I copied how that worked. I don't think it matters that it's an old cockpit.


I'll spend some time on it again, and see if I can get a surface to render. I seem to remember trying this anyway, and without having the code in place, the surface showed as a texture. It was only once the code was there, that it showed up as black.

Also, I seem to remember having the same issue in my Blackhawk cockpit when I tried to add a new MFD

Ok, so it seems the luminosity of the surface needs to be set to 100%. I did this, and now the surface shows as textured and not black.

In the textname.h class, it lists all of the textures in the game. In ha_mfd.c it shows there that the texture to be used for the CRT is called TEXTURE_INDEX_HVCKPT_DISPLAY_CRT. I tried changing the texture to TEXTURE_INDEX_HAVOC_TRQ_GAUGE, the texture file is called HAVOC_TRQ_GAUGE.bmp. But when I try to go into the cockpit in the game, it just crashes out to desktop. My idea was to try and get the main CRT to display on this other texture.

Here's the updated files with the luminosity at 100%

https://drive.google.com/open?id=1I_vThSVjLyuaqQwbtE5XPsJdOFzpD_eO

"Banita, What does 100% brightness mean"
If you not set surface mfd luminosity to 100% picture on mfd is very dark,like old lltv in ka50.
maybe it does not work on all monitors, but on those that have been modified by thealx works.and this is the old advice from thealx

Are you sure you use bmp texture for mfd,not tga?

I don't think it matters

and I'm 100% sure. once again you undermine my opinion, so goodbye, good luck guys.

Seriously? There's no need for your reaction.

There's such a mix of TGA and BMP files in the textures, I didn't think it was important which file type was used. If it needs to be a TGA, then I'll convert it and try again.

Just to clarify why I said this. When I look in the code, it only refers to the texture name to be used, and nothing to do with the file type. So I couldn't see anything saying it has to be a tga file.

Export new cockpit file,put tga instead bmp to mfd texture,and run game. Will be not working mfd. Dont know why ,im normal user,not programmer but work only with bmp. I say this many times. Maybe Javelin waste one week work,because you dont think. It is for real? Come on....

Hi guys, Thumbs up on the luminosity! And it probably does matter for an MFD since you are trying to write to the texture, not just display it. BMP format is simple, TGA is not. I'm not sure what the code does with a texture once it's loaded, but it's easy to test so I'll check it just to be sure. I did try both TGA and BMP before just in case it mattered, but since the texture wan't displaying I didn't see a difference, just a black square.
And i figured out how to size, rotate and move an Object in the code so getting the rectangle in exactly the right spot in Lightwave doesn't matter.

I checked the MFD textures in my Blackhawk, and they actually use the Comanche textures as it was copied from that cockpit. The texture name is COMANCHE_MFDx.tga, where x is a number depending on which MFD it's used on. So I think the Comanche also uses tga files. The texture itself is actually 1x1 pixel dark grey square when you open it in photoshop, and it's then just tiled across the surface.

@Banita, do the BMP textures need to be used in the older style cockpits for them to work?

I also checked the extracted textures from the textures in the game, and they're all TGA files. I'm not sure if the converter did that though.

It's pretty confusing now, which textures work and which don't.

I just read this again. My comment about it not mattering, was to do with the MFD texture file. Not the luminosity. I already 2 posts before that changing the luminosity worked.

Game converter extract tga,i know this. But in my cockpits tga not work. I use always from 2013 128x128 white bmp texture for all mfds and this always work.i think all new and modified old mfd must be 100% luminosity . And surface for mfd also white.

Ok, I've got the new MFD to display the same as the existing CRT display. I did this by changing the texture of the new MFD surface to be the same one used by the main CRT. The file I selected in LW is a TGA file, and I converted the objects with the TGA file, and it works. However, I know that the textures.bin contains the BMP version of the file with the same name, so it might be ignoring the TGA file from LW, and using the BMP file. I also think this, as the texture folder does not contain the required TGA file. I think there might be some caching in memory as well, as earlier I got an error when I deleted the texture file, and now I'm not.

But I'm not going to worry about that for now.

I'm going to experiment some more, by changing the main CRT to use the new texture file, and see if I can get it to work the other way round.

if you copy mfd texture and paste in another place , this also works.

Now I changed the main CRT and the small MFD to use a new texture file, copied from the same file that the main CRT uses. In textname.h it is a new entry for this, so I changed the mfd code to use this new entry, but it doesn't render either MFD now. It's using a BMP file, with all the same LW surface settings as in my previous post, with just the texture file changed.

This is the problem we're having trying to add a new MFD.

We can't use the existing MFD filename, as this is what is referred to in the code. It basically says, find a texture called X and render the MFD on it. But copying that code, but for a new MFD doesn't want to work. Each MFD has to have a unique texture name.

In apache cpg both mfd were hardcoced, uneditable.
just like here. thealx made them editable.
if you understand what the thealx did in apache cpg, you will find the golden grail

The apache A or D? I'll have a look again at those, but I think I went through a lot of the code already.

D of course. arneh made this mfd hardcoded.
thealx made editable.

I wonder if it's not rebuilding the index for the textures somehow.

This is the line of code from ha_mfd.c that assigns the texture.



The TEXTURE_INDEX_HAVOC_TRQ_GAUGE refers to the index in textname.h. In the IDE, it resolves as 2318, which relates to the index. But maybe it's not rebuilding the index. I'll try adding some logging and see what happens. If I change textname.h and run a dmake build, it doesn't show anything changing. If I run remake, then dmake, it rebuilds everything again, but hasn't fixed the MFD display.

I had a look. He reused existing textures from the Hokum, so maybe he couldn't get a new one either??



However, there is a new texture for the Hind Map.

"He reused existing textures from the Hokum, so maybe he couldn't get a new one either??"

Yes! Is impossible edit hardcoded mfd. you can only reuse another,I thought it was known.

What do you mean by hardcoded?

I can't understand why we can't add new MFD's. That's what Javelin and I have been trying to work out.

Do you mean you have to use an existing MFD texture name, instead of being able to add new ones? How did the Hind get added then, as it has a new texture for the moving map.

This is the end of textname.h showing the new Hind ones added, then a comment saying to add new ones at the end

Now we are MUCH closer to find solutnion

Im not programmer. Hardcoded i think i mean that havoc cockpit, and apache arneh cpg no have any AVCKPT_DISPLAY_CPG_LHS_MFD (or similar)texture. And cannot be editable.

As we see also arneh and thealx made the same, copied ka52 mfd texture, and this is only way to make editable mfds.

Even if we have to reuse an existing texture, there are plenty to choose from. Comanche has eight.

I changed the small MFD to use a comanche one, and now it's not showing at all in the cockpit. However, I think that's progress as I wouldn't expect it to render if the code had found it as an MFD surface. It's not drawing the engine bars on it though, so I'll investigate why.

I think you need to find out how it is done, that it recognizes the Hind cockpit instead of ka52 etc



And probably i found reason first released ee apache havoc and this game has no editable hardcoded mfds.
netx released much modern ee comanche hokum and this helos has editable mfds.

I'm going to leave this for now and concentrate on finishing off the instruments for the KA50. I'm not far from having them all working. Maybe Javelin can progress some more with what I've found so far.

I just need the HAVOC_TRQ_GAUGE.lwo or eeo with the copied Comanche texture attached to it. I can take it from there. It will have to wait until Friday though, I'm on 12 hr shift work until Thursday. Don't worry about the code, I can make it work with new.

Well, I tried a few more things, but no luck. I need someone who does modeling to paste a working MFD screen object from a different helicopter into the Havoc HAVOC_VIRTUAL_COCKPIT_INSTRUMENT_NEEDLES.ees file right over the engine gauges, then save it. Send me the ees or lws file and the name of the MFD object you pasted in (and the texture name if you know what it is) then I can fix the Havoc engine gauges. I don't think it will work any other way.

I can send you the NEEDLES.lws file if you tell me where to send it via a PM.

I think I'll go work on something else for a while.

You can download the trq gauge object and scene here

https://drive.google.com/open?id=1XzgMjktq9GVxVyKIsfqo-KenX-k86LaV

The texture for the MFD is called COMANCHE_MFD1

Excellent! Thanks, I'll get back to work on it.

Yes! We have ignition! It's drawing right over the engine gauges, transparent. Now I just need to draw the bars in the right places.

Awesome

OK, it's ready for testing. The Havoc Engine Gauges are working. Go to the MFD Export Upgrades thread to get it.

MFD Export Upgrade Thread

Finally. Great news. Im only on phone one week,cant test now.

Just had a quick try of this, and it looks great. Finally a fully working Havoc cockpit, like we had in EEAH. Thanks for your work Javelin.

I think this cockpit does need some love though, so probably one for a future project. I always preferred flying this helo in the game. It's like a flying tank.

There's a couple of things I noticed. The right hand gauges seem to increase quicker than the left hand ones. And only when the left hand engine NG reached max, did I get an engine over torque warning, as if that was the "real" value.

I also got a crash to desktop, but there doesn't seem to be a DEBUG.LOG generated to see what it was. So I'm not sure if it's related.

I'll do some more testing.

Edit: Actually, there was a log being generated, as a debug.txt, but it's not in the usual format as the other DEBUG.LOG files. I've attached it.

This time I got another CTD, when I pressed CTRL Q to quit free flight, I get a CTD when it quits.

Done some more testing. When you do manual engine start, and throttle up, the NG bar picks up, then drops to around 60 (on the gauge) and picks up again. The same happens when throttling down.

I took a video of it.

I found an old image of the original cockpit. To the right of the engine gauges, there's a couple of other smaller gauges. Does anyone know wht these are for, and would it be possible to get them working?

I wonder if it's the engine NP, as at some point, someone added 2 small needles to the rotor rpm gauge for this, perhaps as it was missing from these gauges.

I don't know what the log file means. It hasn't crashed on my machine at all. I can make you a debug version, or you could compile one on your end since you have the code now.

On the engines, I haven't touched any of the engine operational code at all, all I did was show the numbers on the gauges. I did also noticed that the right side is more reactive than the left. I don't know why. Temperature responds to engine rpm correctly though.

Engine rpm is on the 0 to 200 inner gauges (the top number should be 110, not 200). Someone should fix that, the values are bounded in the code to 120. I don't know what the four small gauges to the right are for. And Rotor rpm is missing. Is that the gauge just to the left of the engine gauges?

I see the glitch in the numbers when it hits 70, then drops down to 60. I'll fix it, that looks like something I did wrong.

OK, I fixed the 0-60 glitch and Pushed the change up to Master. The download looks the same, I reused cohokum_test16.exe as the name for the cmake executable.

I also made a slight addition to the Hover code. The Heading while in Hover mode was drifting too much after taking out the joystick deadzone, so I added in a dampener to fix it. We don't have a Heading-Lock control like the real helicopters do, but this works just as well. When flying, the tail does it for you, it's only needed when you Hover.

Rotor RPM is on the gauge on the left of the cockpit.

I added a Debug version of the exe into the download just for you. Boy, it takes a long time to compile the code when you do it that way. I have an abbreviated method, I only delete the obj files in the section I'm working on so it only has to recompile a few files, then link the exe together.

Yeah, it takes a while. Noone, as far as I know, has looked at the compile scripts to improve them. The dbug exe enables all the debug messages, and debug windows if you need to see more of what's going on.

Also i have many ctd, only with the last build. especially if i want to exit ctrl x.
maybe because there is not one full version, and you need to install the messyhead version, then Javelin.there is a big mess with it.

I don't think you should have to install both versions one after the other. All of the changes Javelin made, are also in my build. We use the Master branch to build from. Maybe installing both is causing your problems?

NVM.

Even though you removed your post, I got it in the email notification. So to answer the points you made.

I've not been on this forum for a while, or done any coding as I started a new job, and that is taking all my time now, and my free time is family time. So I forgot what I previously have posted.

It's a debug build as it's for testing, and the debug log is more detailed when things go wrong. I've never said it's a stable release. It's still in testing. Only releases made with an installer should be considered stable and complete.

A completely green person should use the last "released" version that was provided with an installer.
If they choose to use other updates for work in progress, they should accept things might not work.

My comment regarding my build being the same as javelin, was to do with the content of the exe as it's built from the same branch. Any additional files that Javelin changed will only be in the download he provided. This is part of the problem with there being no unified approach to making mods.

I can't make promises when I'll be back on this, as life is busy, and takes priority.

Ok now is more clear.Sorry for the aggressive post, just too much confusion:
your version no have dyn files Javelin.
javelin version no have ka50 cockpit files.
Your version is debug mode.
To be sure - the Javelin version has all your latest ka50 fixes or not?
If yes, properly installation is unpack your version
and next unpack Javelin version, which is commercial without debug mode?

I don't think Javelins exe has my code changes.

I'll try and find time this week to make a commercial build, so you should have to use my exe and cockpit files with javelins dyn files

Hello guys,

what's going on here? Banita be a little more patient, all of us have to do others things in life, too.

I've seen Javelin has done a lot of good work for the Havoc's pit and also made some more MFD screens exportable.
Messyhead has finished the KA-50 pit and also worked at the Havoc. Thank's to you both for this great work!!!

I will continue my work at the MI28N now, but I also have a lot of other building sites too, so it could take a while.
I had to manage a lot of things and also started again with my homepit.

Since the last time I was working on it, so many things changed again, that I have nearly to start from scratch.

Since ED has released a lot of new very interesting modules I always wanted and my pit never was primarily designed to run with DCS
(cause I never thought that those modules will see the light of day during my lifetime), I have to change many things now to make it also mostly compatible with it.

DCS uses completely other methods for instrument and MFD extraction as BMS does with it's shared memory.
So I have to learn a lot new things like dealing with lua-scripts. This will take also a lot of my free time.

why not to add new cockpit special for Mi-28N? like it was made for AH-64 - we will have modern and classic cockpits same time.

Good idea.

not sure anyone still working on it but will leave examples of wrong gauges values here

I'll have a look at my code when I get a chance. I think I might have corrected those.