feat(cpn): add surface vehicles to wizard

[ikkemaniac]

This is a draft to ask some questions on how to proceed to implement surface vehicles to the model wizard.

I chose a crawler to start with, i see this as kind of a template for future surface models.
attached is a squashed commit of my current progress. I have a few specfic questions that will ask using the inline comments.

a general question is: How do you guys prefer to include a different type of vehicle into the wizard process?
Currently, all code assumes air-type vehicles. Although a mix is mix, regardless of the type of vehicle applied to, some things under the hood are different. For example, there's currently an enum Input defined that holds a list of standard aircraft inputs. This list only has 1 item (THROTTLE_INPUT) that overlaps with surface models.
What approach would be best to incorporate surface? Expand the enum with surface controls (ex. STEERING_INPUT, GEAR_INPUT, DIFFLOCK_INPUT) or define a new enum dedicate for surface models?
I would think a new enum makes more sense as the listed inputs now represent default channels as int's.

thanks for the feedback.

[elecpower]

Great to see someone putting forward surface models as wizard options! Also not bad graphics too. Far better than I could ever hope to knock up.

Suggest changing Model Type page to list Air and Surface option types and add a new two new pages moving sub-types to separate Air and Surface pages to avoid future reorganisation to declutter.

I'd suggest behind the scenes a generic surface framework rather than mangling air and making it hard to add/maintain in the future. As you say there is vague overlap. Maybe at some point we have frameworks for watercraft, robotics, etc.

[elecpower]

Currently the air wizard doesn't cater well for models with flight controllers too.

[elecpower]

This task is on my TODO list, so as part of this PR can you please move all the wizard files to a new sub-directory 'companion/src/wizard'. Create a new cmake project for the directory.

If you require any assistance with the cmake bits I can help.

This is part of decluttering the src directory housekeeping.

[ikkemaniac]

Great to see someone putting forward surface models as wizard options! Also not bad graphics too. Far better than I could ever hope to knock up.

Thanks! much appreciated

Suggest changing Model Type page to list Air and Surface option types and add a new two new pages moving sub-types to separate Air and Surface pages to avoid future reorganisation to declutter.

10-4 will do.

I'd suggest behind the scenes a generic surface framework rather than mangling air and making it hard to add/maintain in the future. As you say there is vague overlap. Maybe at some point we have frameworks for watercraft, robotics, etc.

agreed, that makes sense. I do need some pointers though as i'm new to cpp. I do have quite some PY experience but anything c is new to me.

What would be the best approach?
it looks like wizarddialog is the entry point for the wizard. StandardPage already has an Input defined making it "air specific"
i was thinking about moving wizarddata.[h,cpp] to wizarddataair.[h,cpp] and creating a wizarddatasurface.[h,cpp] and moving further through the code to split it up.
your thoughts?

[ikkemaniac]

This task is on my TODO list,
I don't see anything that looks like a task?

so as part of this PR can you please move all the wizard files to a new sub-directory 'companion/src/wizard'. Create a new cmake project for the directory.

If you require any assistance with the cmake bits I can help.

This is part of decluttering the src directory housekeeping.

Yessir, i'll have look and report back if I need any support.

CPP is new to me, i'm a PY guy. I probably need some pointers some time somewhere. I work best with an example that shows "old" vs "new", would be great if you can give this type of feedback. as i said, i'm good for now and will report here.

[Jonimoose]

Suggest changing Model Type page to list Air and Surface option types and add a new two new pages moving sub-types to separate Air and Surface pages to avoid future reorganisation to declutter.

I hope this isn't bike shedding too much but are there going to be enough different surface and air model types to warrant making separate pages? I feel like just listing the current 5 or 6 types on one page, maybe in two columns if you really want them split, would be better than adding a whole separate page with additional clicks in the process.

[ikkemaniac]

Suggest changing Model Type page to list Air and Surface option types and add a new two new pages moving sub-types to separate Air and Surface pages to avoid future reorganisation to declutter.

I hope this isn't bike shedding too much but are there going to be enough different surface and air model types to warrant making separate pages? I feel like just listing the current 5 or 6 types on one page, maybe in two columns if you really want them split, would be better than adding a whole separate page with additional clicks in the process.

i forsee the following:

1. plane
2. heli
3. quad
4. crawler
5. track-based (tanks etc, no 'steering axle')
6. truck
7. robot?

anything missing?

[Jonimoose]

i forsee the following:

1. plane

2. heli

3. quad

4. crawler

5. track-based (tanks etc, no 'steering axle')

6. truck

7. robot?

anything missing?

I'm not sure if speedboat would be sufficiently different from truck/basher/racer other than most boats not having reverse but neither do many Nitro vehicles, though they do tend to have brakes.

Maybe sailboats though I'm not sure what the standard mix setup on those is I'd have to look at what the pack-in radios do for a few models to get the idea of what you'd want.

The only other thought I would have would be RC Construction equipment like an excavator which would likely be different enough from the base Track mix or at least likely have dig mode and a drive mode or so that you can control which you are in. I know twin stick radios are popular for this application but I do not know what the common mix setups are for that or if you could reasonably make a wizard for how varied those models can be.

If things end up with many more surface types I would agree with @elecpowers request of having separate pages, I was initially thinking only of only track based and car/truck and hadn't though about dial motor crawlers or other more obscure configurations.

[elecpower]

What would be the best approach?
it looks like wizarddialog is the entry point for the wizard. StandardPage already has an Input defined making it "air specific"
i was thinking about moving wizarddata.[h,cpp] to wizarddataair.[h,cpp] and creating a wizarddatasurface.[h,cpp] and moving further through the code to split it up.
your thoughts?

I haven't dug into this yet but likely there will be base wizard classes (data & methods) and inheritance for each group/type. In the first pass I'd go the way you are suggesting just for the crawler and then see where is the commonality and move that to base classes. Keeping separate for now will help with the workflow to a working prototype.

When you get it a bit further along I can provide the amended and new cmake files if you need.

[pfeerick]

Just a thought... since the list of model types is now up past 5, a drop-down list / combo-box might make life easier for layout... And yeah, "boat" of some description is definitely another possibility. Even if they do nothing more than just configure the primary channels (i.e. "movement" and "steering") and set the default name, it would be to have a scaffold that takes them all into account if not a basic implementation for them all (so this doesn't blow out to be a bigger than Ben-Hur PR).

Screenshots looks great. SA will be assigned... for what? (me dumb human... 🤭) ;)

[ikkemaniac]

I'm not sure if speedboat would be sufficiently different from truck/basher/racer other than most boats not having reverse but neither do many Nitro vehicles, though they do tend to have brakes.

speedboat and basher/racer would be the same. I do think there's a bit of a barrier for people to choose basher/racer when they're planning to setup a boat. We could still split them up as individual choices but run the same template in the backend. Very little effort imho.

Truck to me was different as the scale trucks have 3+ geared tranmissions, shit ton of light and sound options and auxiliaries like the the trailer hitch and lifting up the 3rd axle. I would keep those seperate.

Maybe sailboats though I'm not sure what the standard mix setup on those is I'd have to look at what the pack-in radios do for a few models to get the idea of what you'd want.

I have no clue either but would assume the have some mixing on the sail winches. But if we setup reasonably modular/templating we could add those later on as well.

The only other thought I would have would be RC Construction equipment like an excavator which would likely be different enough from the base Track mix or at least likely have dig mode and a drive mode or so that you can control which you are in. I know twin stick radios are popular for this application but I do not know what the common mix setups are for that or if you could reasonably make a wizard for how varied those models can be.

good point. Trucks, sailboats and construction equipment are typically run with stick transmitters anyway so there's some overlap there.

If things end up with many more surface types I would agree with @elecpowers request of having separate pages, I was initially thinking only of only track based and car/truck and hadn't though about dial motor crawlers or other more obscure configurations.

tbh, i'm not a fan of the radio button selections and clicking next. I don't want to change too much at the same time but was playing around with the idea of making the selection with directly clickable buttons. First page has 2 buttons, air - surface, onClick you move to page 2. Page 2 lists individual vehicle types as buttons, onClick you get into the vehicle specific wizard. That "saves" 1 click per page. But is see that more as UI finishing up thing for now. Let me know if i'm wrong.

[ikkemaniac]

Just a thought... since the list of model types is now up past 5, a drop-down list / combo-box might make life easier for layout... And yeah, "boat" of some description is definitely another possibility. Even if they do nothing more than just configure the primary channels (i.e. "movement" and "steering") and set the default name, it would be to have a scaffold that takes them all into account if not a basic implementation for them all (so this doesn't blow out to be a bigger than Ben-Hur PR).

i initially wanted to avoid adding models that just require a basic steering/throttle setup as that is ... well... basic.
If we all agree to go the split-per-realm-on-1st-page route the total quantity of vehicles is less of burden imho. So it would be fine to even add the most basic configs.

Screenshots looks great.

ty sir.

SA will be assigned... for what? (me dumb human... 🤭) ;)

There are no dumb questions.
I had already updated the text to be more verbose but didnt push it to GH.
SA will allow the user to switch between

1. both motors active
2. front motor only
3. rear motor only

These rigs are typcially comp rigs and the guys sometimes use this as an alternative to dig. And it just fun to have ofc 😀

[ikkemaniac]

page 1:

• air
• surface

page air

1. plane
2. heli
3. quad

page surface

1. crawler
2. racer/basher/speedboat
3. truck
4. tanks/excavators/cranes (track based)
5. sailboat

[ikkemaniac]

so i've been playing around trying to get a basic idea working.

My thought process, hoping i interpreted @elecpower 's comments correctly:

• setup a framework of vehicles where we could build out each type of vehicle, in my mind that meant CLASSES
• moved all the existing wiziard stuff over to ....air... files as it's all air-type related. Generic classes will end up in a generic wizarddata file but i left it in the ...air... file for now as this is just a proof of concept.
• the enums were hurting as they wouldn't be easily adapted to other vehicle types. Googling a bit i found out that it's relatively common to use static const instead of enum to achieve the same. So i went ahead converted them to static const.
• created a basic Vehicle class as the mother of all classes. This has some very rudimentary stuff defined and should never be used by itself
• also created an AirVehicle class which is more specific and contains general air stuff (only the constants for now). We could have an SurfaceVehicle, MarineVehicle etc. This is not a requirement and should only be done if multiple vehicle types overlap.
• drilling deeper i've also created Plane class inheriting from AirVehicle. This has all the plane stuff. Again for now only the constants but i forsee all plane specific stuff ending up in here. We would have Helicopter, Multirotor, Glider etc.
• Next steps i want to take is to build out Vehicle class to have all functions defined that are a minimum requirement for the class to be functional. An example is a the addMix function. I think it would be best to not have any code in it but just have it return False by default. Each specific vehicle type classes, like Plane should overwrite/overload this function with the relevant class function.
• there are some reminiscences of Heli and Multi in the example code right now as i didn't want to break to much. Please ignore, those would be split out of this code into their own files or subfolders.
• with this approach i'm running intot he issue that current QOBJECT can't be nested. When nesting WizMix into AirVehicle it throws error error: Meta object features not supported for nested classes.
  A solution would be to "forward declare the nested class ...". This part I understand and I can get it working. It continues with "... and put it's declartion into it's own header". Here I'm lost. I guess i have to create a seperate_wizmix_header.h which holds the class WizMix .... Is that correct? I did so to try anyway, see the last commit. I can't get it together though.

I hope the above explains my thought process clearly and makes sense, as i'm not a programmer by trade.

I've updated this branch/PR to show my current progress with the above. the 1st commit is up-to the last bullet in the list with the issues that QOBJECT can't subclass. The last commit is my attempt but fails to build.

Please let me know if i'm on the right track and this is acceptable. Thanks.

[elecpower]

Classic inheritance structure so no problem there.

I've struck the nested QOBJECT situation before. Not every class needs to be a Qt object especially if there is no Qt features required such as translation and signals/slots i.e. no need to run MOC parser over header.

Try using fundamental c++ data types and functions in the base classes and leave inheriting Qt widgets or using QOBJECT macro until the final class.

You can also use multi class inheritance eg from /shared/autocheckbox.h. AutoWidget is not a Qt object.

class AutoCheckBox : public QCheckBox, public AutoWidget

Unfortunately with Qt case by case solutions to get around its MOC restrictions.

[Guilhem23]

@ikkemaniac great work! I was wondering surface / marine vehicles was a big miss in this great companion. Are you still working on this development?

[ikkemaniac]

@ikkemaniac great work! I was wondering surface / marine vehicles was a big miss in this great companion. Are you still working on this development?

Yessir! Just a bit busy with private stuff so didn't make much progress. I expect to have a bit more time when the weather gets worse and when the holidays start :) Great excuse to avoid those 'must do' festivities.

[Guilhem23]

Great no worries. I'd be happy to test them if you need feel free to ping ;-)