[CultureShock]

One problem I have is Mapster32 remembering its window position. Does Mapster32 store settings in a .INI file or is this not coded in?

I have supplementary questions:

I haven't examined the codebase yet but is Mapster32 abstracted with a portability layer? I did read BUILD was a porting nightmare. Has Mapster32 inherited this too? I'm wondering because this might make native ports to OS X and Linux possible.

I have experienced no problems running EDUke and Mapster within Wine 1.6.2 on Linux Mint 17.3. It's actually been fantastic. Will the new graphics engine be tested against this or the new Wine 1.8?

I don't know how much the interfaces and core code are abstracted. How easy would it be to fit a new more up to date GUI?

I've discovered some useful tools which may help with mapping. If the source is available and licenses permit might some of these tools be incorporated as plugins?

[The Mechanic]

CultureShock, on 27 December 2015 - 11:07 AM, said:

I don't know how much the interfaces and core code are abstracted. How easy would it be to fit a new more up to date GUI?

Depends what you mean by "core". The build engine itself could be considered seperated but modifying the data used by the engine within mapster is totally merged. One UI function is some 7000 lines of code, that is, one routine, scanning keys and fiddling with mainly global data. It is also very much a single-threaded environment and there are quite a few magic variables that connect different pieces of code together. Over the years pieces have been modified in a considerable better manner but at the heart it is still the original Mid-90's hack code/structure.

You can build on what is there, for example I have implemented a prototype pop-up menu system but for it to be incorporated into Mapster I would need to seperate the graphics drawing side of things from the functional side of things so that the "functional" side of things could be implemented via external scripts. Unfortunately external scripts can't do some of the necessary functions, or at least would require duplicating existing code in a script so I'm not sure how to proceed further. Something needs doing though, as we've just about run out of available keyboard keys for adding any new functionality.

TTFN,
Jon

[CultureShock]

The Mechanic, on 27 December 2015 - 12:56 PM, said:

Depends what you mean by "core". The build engine itself could be considered seperated but modifying the data used by the engine within mapster is totally merged. One UI function is some 7000 lines of code, that is, one routine, scanning keys and fiddling with mainly global data. It is also very much a single-threaded environment and there are quite a few magic variables that connect different pieces of code together. Over the years pieces have been modified in a considerable better manner but at the heart it is still the original Mid-90's hack code/structure.

You can build on what is there, for example I have implemented a prototype pop-up menu system but for it to be incorporated into Mapster I would need to seperate the graphics drawing side of things from the functional side of things so that the "functional" side of things could be implemented via external scripts. Unfortunately external scripts can't do some of the necessary functions, or at least would require duplicating existing code in a script so I'm not sure how to proceed further. Something needs doing though, as we've just about run out of available keyboard keys for adding any new functionality.

I suppose what I'm asking is whether the user interface and business logic (the magic which makes things happen) and OS level layers are separated. I also would like to know how well organised the business logic is. From what you say you understand this.

Ummm... Where to begin? Okay, I think I understand your challenge.

I haven't coded for ages and not sure I'm capable now. Coding just mangles my brain.I was curious though if Mapster had the capacity to be refactored. I'm tempted to dig deeper. I'd like to. I just have other personal priorities plus I'm still learning to create maps and don't want to over burden myself. (I managed to make progress today and examined other tools so pleased enough with this.)

I was wondering about improvements then slapped myself. I can't manage anything too big at the mo and I'm sure you guys have enough of your own ideas!

[Hendricks266]

CultureShock, on 27 December 2015 - 11:07 AM, said:

One problem I have is Mapster32 remembering its window position.

r_windowpositioning

CultureShock, on 27 December 2015 - 11:07 AM, said:

Does Mapster32 store settings in a .INI file or is this not coded in?

mapster32.cfg, m32_settings.cfg

CultureShock, on 27 December 2015 - 11:07 AM, said:

I'm wondering because this might make native ports to OS X and Linux possible.

We've supported OS X and Linux for years, probably for as long as the project has existed.

CultureShock, on 27 December 2015 - 11:07 AM, said:

Will the new graphics engine be tested against this or the new Wine 1.8?

It will use Vulkan, which should be cross-platform.

CultureShock, on 27 December 2015 - 11:07 AM, said:

How easy would it be to fit a new more up to date GUI?

Suck it up and read the Infosuite. Implying a more "up to date" GUI would better than what we have now, with no other reasoning given, is an instance of the appeal to novelty fallacy.

CultureShock, on 27 December 2015 - 11:07 AM, said:

I've discovered some useful tools which may help with mapping. If the source is available and licenses permit might some of these tools be incorporated as plugins?

"Useful tools" is quite vague, and we would have to look at each one on a case-by-case basis.

[CultureShock]

How did I miss config files? Call me dizzy headed. I tried this but Mapster32 ignores r_windowpositioning and overwrites mapster32.cfg like the addition was never made.

I can't clearly remember if I read the infosuite discussing a new editor. I think I did but I've read lots of stuff this week. I understand the reasoning if I'm recalling things properly. It doesn't explicitly exclude an editor refresh or a new editor entirely and this was the question I was exploring. I examined the initial feasibility today. I need to examine a few technical issues further but it seems likely a new editor is straightforward-ish. I need to pick through various documentation and things and code to be sure. If I'm happy with progress I need to examine file formats and supported entities much closer so I have a clearer idea about editor constraints. There's things I'd like to do with maps which take a lot of work. A new editor can support this and I discovered an abandoned project which took one major editing facility almost to completion so I know it's possible.

I've installed some Linux development tools and compiled a Linux source port of SLADE and it works. I next need to play with this for a while.

If in my wildest dreams if I manage to produce a test build which allows me to roundtrip maps 99% of the code will be robbed. This is a least effort exercise. Believe me!

P.S.Vulkan is cool.

[The Mechanic]

CultureShock, on 27 December 2015 - 08:15 PM, said:

... but it seems likely a new editor is straightforward-ish.

(darnit, where's the streaming tears of laughter emoticon?). Are you _sure_ you are aware of everything in the current mapster?

I would be the first to acknowledge that writing a brand new editor from scratch would provide a much better/modern editing experience and no doubt easier code base to maintain and expand, what with the current Mapster forever constrained by it's roots.

But for starters,
1) Re-writes mean a lot of coding effort - person-years - just to create something that does the same as what we have now, which itself is evolving. There are plenty of examples out there of project re-writes that just never get done, probably for this very reason.
2) Starting point has to be "what's wrong with the current system" ? Well, other than the recent colour changes (and,ok, the awkwardness of switching between running apps), mapster is very usable as-is. The UI could be made easier (e.g. convert door to a sector with sound/autoclose/activator etc in one menu) or make existing functions that require the manual dexterity of an octopus (such as selecting multiple sectors) to simply become a right-click. All acheivable in the current mapster.
3) You'd need to provide a 3D view exactly as it'd appear in Duke/Eduke which pretty much means interfacing to the existing most-definately-not-OOP build engine. Straightforward !?
4) Support the current scripting (and future one)? Sure, it has it's limitations, but enabling additional functionality via external scripting greatly increases the number of people that can add functionality.

So list what additional functionality you are thinking of, or what UI improvements you can think of, you may well find that could be incorporated into the current mapster.

CultureShock, on 27 December 2015 - 08:15 PM, said:

P.S.Vulkan is cool.

I certainly have high hopes. And doesn't need a rewrite of Eduke

TTFN,
Jon

[CultureShock]

I've been examining code to discover the feasibility of a new editor and to estimate how much and what kind of work will be needed to make this a practical reality. The competing codebases are very different I grant you. I haven't discovered anything yet which indicates this is an intractable problem. If you have good code separation the core task appears achievable. I would not say trivial but not hard either.

I gave up programming ages ago. I've experienced the evolution of graphics APIs from the classic pipeline through its modern evolutions and my interest has waned. I'm much more emotionally involved with pragmatics and user experiences. How does this deliver products and customer service which people find meaningful? My experience is game code is only 5% of a game and you could say similar about anything. As important as getting essential technology right is this can become too ivory tower. It has its place but not at the expense of cutting in to overall quality. The essential issue is the balance of the design or framework and how it facilitates communities. Without this growth or interest you never develop the base which supports the top of the pyramid.

To some degree companies like Adobe and Epic have done well because they understand this. 3DR and Core Design failed because they were hobby companies who never crossed over into being professional and were buried by the demands created by their own hype. The market is moving on and gamergate and more recently accusations made against Linux Torvalds are part of this. OMG. Feminists are trying to collect scalps! Oh, the horror.

Too political, I know. You don't have to tell me! I really am just interested in a professional appraisal of the code. This is why I've been examining codebases, and working out how the code is organised and data structure compatibilities, and exactly what may be needed to refresh the user experience.

I haven't got very far but have the sense file input-output and reading into data structures is fine. I'm not yet sure whether new internal data structures are needed or what may need to be gutted. There's also the issue of rendering into the main window in 2D and 3D views. User interaction should, I hope, not present any problems. I can't imagine there will be any but I would prefer not to assume. I can barely make sense of Slade and keep losing myself with Mapster. One thing which would be helpful is Slade being better documented with better naming schemes for the source files (which is unlikely to happen soon). Mapster code could be better separated and have better named source files too. None of this is new work just documentation and light re-organising.

I'm not convinced Slade is the best base to work from. The code is okay but is too obscure plus there will be too many data structures and hooks needing rewriting. This is not impossible but too big a task to be realistic. I tend to believe Mapster could better accommodate a new interface and the work would be relatively minimal in comparison. A possible plus is Doom codebase data structures can be better accommodated within Mapster if this becomes a desired feature in the future.

This is the point I've been able to work to. I'm not especially concerned with what happens next. (So there really was no need to leap down my throat or mansplain me tah very much.) I really just wanted to open this question and know with more certainty.

[Mark]

I would be interested in having certain functions automated. Like mentioned before, you want to make a door. With some keyboard or keyboard/mouse press on a sector and a window pops up where you enter in the type of door, activator included?, lotag, enter sound effect number...etc All in one place instead of having to put in place each seperate effector. Or a function to create stairs automatically. Again with a window that pops up asking for parameters such as how many stairs and how many page up or page down units per stair. There are probably other things but those two come to mind first. IIRC the Build that comes with Shadow Warrior had auto stair creation. Maybe grab it from there if we're lucky enough with compatibility.

[CultureShock]

After a lot of headbanging I managed to get the EDuke and Mapster to compile on Linux. (Thank you for your earlier none answer!) I also discovered they use GTK and SDL. GTK is used at application launch to set parameters and they then dive in to SDL. Okay, I understand this. A first step will be to create a one window GTK application and test everything is working perfectly with SDL. If this works I need to ask more questions. I'm not quite sure what but will need to begin separating out interface elements.

The code is undocumented and a real mess. It's mostly an obscure blob of stuff. Directory organisation and file naming schemes? Oh, please.

Generally it's been fairly easy so far. It's just because it's a blob of stuff this task has been harder and taken longer, and this is a million times harder when you are coming to the source from cold. If and it's a big i I manage to get the basics working there's things which are good candidates for being polished up.There's also extra functionality which can be folded in normally supplied by a scattering of utilities.

I don't know how far I will get with this. Maybe nowhere but if it's all on my own I'm keeping it. I'm not releasing anything without quid-pro-quo cuz I know what men are like. All blah-blah this and blah-blah that and promptly sit on their backside while you do everything for them. I hope you're having good fun with your new renderer boys! The rest of us like easy, okay!

Mark., on 28 December 2015 - 12:23 PM, said:

I would be interested in having certain functions automated. Like mentioned before, you want to make a door. With some keyboard or keyboard/mouse press on a sector and a window pops up where you enter in the type of door, activator included?, lotag, enter sound effect number...etc All in one place instead of having to put in place each seperate effector. Or a function to create stairs automatically. Again with a window that pops up asking for parameters such as how many stairs and how many page up or page down units per stair. There are probably other things but those two come to mind first. IIRC the Build that comes with Shadow Warrior had auto stair creation. Maybe grab it from there if we're lucky enough with compatibility.

I haven't thought through things too deeply. I do wonder though if these kinds of helper functions (and a lot more besides) would be more easily accommodated if the code was tweaked to be more modern and better organised. I don't know of any reason why what you need cannot be accommodated via a plugin. This could be extended much further to include pre-built components or styles, or even nested components.

I think we can do better than Slade...

[Hendricks266]

CS, since you've returned to the forums you've been all talk. Let us know when you can put your money where your mouth is.

[LeoD]

... smells like LakiSoft spirit ...

[Danukem]

The Mechanic, on 28 December 2015 - 01:43 AM, said:

(darnit, where's the streaming tears of laughter emoticon?). Are you _sure_ you are aware of everything in the current mapster?

I would be the first to acknowledge that writing a brand new editor from scratch would provide a much better/modern editing experience and no doubt easier code base to maintain and expand, what with the current Mapster forever constrained by it's roots.

But for starters,
1) Re-writes mean a lot of coding effort - person-years - just to create something that does the same as what we have now, which itself is evolving. There are plenty of examples out there of project re-writes that just never get done, probably for this very reason.
2) Starting point has to be "what's wrong with the current system" ? Well, other than the recent colour changes (and,ok, the awkwardness of switching between running apps), mapster is very usable as-is. The UI could be made easier (e.g. convert door to a sector with sound/autoclose/activator etc in one menu) or make existing functions that require the manual dexterity of an octopus (such as selecting multiple sectors) to simply become a right-click. All acheivable in the current mapster.
3) You'd need to provide a 3D view exactly as it'd appear in Duke/Eduke which pretty much means interfacing to the existing most-definately-not-OOP build engine. Straightforward !?
4) Support the current scripting (and future one)? Sure, it has it's limitations, but enabling additional functionality via external scripting greatly increases the number of people that can add functionality.

To summarize, you are saying that making a new editor from scratch would require a huge effort, and in order for the new editor to be embraced by the community, it would need to have 3) and 4). That's too bad, but it seems to be true. I would take issue with the statement that "mapster is very usable as-is", however. Yes, people can and do use it to make levels, but it's pretty damned hard to use. The people whose opinions matter most, though -- experienced BUILD mappers -- are accustomed to it and have memorized most the key combinations, so they will continue to build awesome levels without much complaint. The people we don't hear from are those who might want to try mapping, but don't get far because of the editor.

@CultureShock: It seems to me you would have to be a masochist to take this on. There's little demand for it within the community, and (largely for that reason) you will almost certainly have to do all of the heavy lifting yourself.

[Mblackwell]

It took me about the same amount of time to learn Mapster/BUILD and UnrealEd. But building levels in Mapster is faster unless you have a lot of predone brushes and models to paste in, and even then...

[CultureShock]

Hendricks266, on 29 December 2015 - 07:04 PM, said:

CS, since you've returned to the forums you've been all talk. Let us know when you can put your money where your mouth is.

I've been using an OS platform which is mostly alien to me. I've had to discover (without pointers help or anything) a download wasn't available and I needed to install development tools from scratch, compile and test, and put up with both OS and application quirks. The source is almost completely undocumented. I've spent hours examining other editors including sourcecode and tutorials on top of hours with EDuke and Mapster. So far nobody is taking a hint. It's like you either A.) Can't take the competition or B.) Want efforts to fail or C.) Both A and B.

This is only a passing interest. I have no investment in its success or failure. I'm not going to beat myself up when people who can answer key questions sit on their knowledge. For what, ego? Mocking? Watch the bitch fail?

Trooper Dan, on 29 December 2015 - 07:43 PM, said:

To summarize, you are saying that making a new editor from scratch would require a huge effort, and in order for the new editor to be embraced by the community, it would need to have 3) and 4). That's too bad, but it seems to be true. I would take issue with the statement that "mapster is very usable as-is", however. Yes, people can and do use it to make levels, but it's pretty damned hard to use. The people whose opinions matter most, though -- experienced BUILD mappers -- are accustomed to it and have memorized most the key combinations, so they will continue to build awesome levels without much complaint. The people we don't hear from are those who might want to try mapping, but don't get far because of the editor.

@CultureShock: It seems to me you would have to be a masochist to take this on. There's little demand for it within the community, and (largely for that reason) you will almost certainly have to do all of the heavy lifting yourself.

I was only asking the feasibility and was slammed. Then slammed again for raising issues with project organisation and for examining the code. Then hung out to dry. This and the I'm Alright Jack Attitude is basic corporate politics.

I only have plans to produce one to three maximum maps. They will be very focused and some may not be playable as games. I'm doing them for my fun and my amusement. It's been tricky learning editing. I can do almost all what I want to with very little advanced features. One thing I would like to do involves me doing a lot of work inside mapster then roundtriping through at least two external tools to make up for mapster's shortcomings for something which should be either accessible or built in.

I'm not going to diss people's work. Getting the source as far as it has reached is awesome and some of the maps produced by some of the mappers are amazing. I'm just finding the stand offish sink or swim attitude like it's some kind of exclusive boys club is a bit much.

[Micky C]

By external tools are you referring to LEBuild?

[Danukem]

CultureShock, on 29 December 2015 - 09:34 PM, said:

I'm just finding the stand offish sink or swim attitude like it's some kind of exclusive boys club is a bit much.

I have been around this community for ten years now and I can confirm that there are plenty of assholes and nutcases here. I have seen lots of immaturity, douchebaggery, churlishness, and even some paranoia. But I can assure you that guys who make similar threads are treated in exactly the same way that you are, maybe even less nicely. So please, stop bringing gender into this. It just shows how ignorant you are of how people are treated around here.

[CultureShock]

Trooper Dan, on 29 December 2015 - 09:58 PM, said:

I have been around this community for ten years now and I can confirm that there are plenty of assholes and nutcases here. I have seen lots of immaturity, douchebaggery, churlishness, and even some paranoia. But I can assure you that guys who make similar threads are treated in exactly the same way that you are, maybe even less nicely. So please, stop bringing gender into this. It just shows how ignorant you are of how people are treated around here.

I'm not throwing a fit... I have read past comments both about people requesting a modern editor and other comments. (A lot of chat was not very nice!)

I was just curious about feasibility and needed to know the code structure and function points to determine what was possible. I'm not hiding the fact I haven't coded for years (Eek!) and found navigating the source very difficult. I don't think though that this task is difficult for anyone who is coding and familiar with the organisation of the source. If I could get the help I needed to get at least this far I thought maybe a mock up or at least enough to prove basic functionality would be enough.

I believe people should get the tools they deserve. I think I'll just say that.

Paaaaaaaaaaaaaaaaaaaaaaawuff. I have a thick head from all this.

[The Mechanic]

Mark., on 28 December 2015 - 12:23 PM, said:

I would be interested in having certain functions automated. Like mentioned before, you want to make a door. With some keyboard or keyboard/mouse press on a sector and a window pops up where you enter in the type of door, activator included?, lotag, enter sound effect number...etc All in one place instead of having to put in place each seperate effector.

Indeedie (Excuse primitive graphics, it was a prototype).

Only needed to hook two places to run the menu's

Thing is, it wont be accepted into the main branch as I would have to find some way of making the thing scriptable which is beyond me right now. I can see the logic for trying to make the menu system scriptable, although it would require duplicating some code into a script, plus I'm not sure if the script system is flexible enough as it stands.

Quote

If I could get the help I needed to get at least this far I thought maybe a mock up or at least enough to prove basic functionality would be enough.

Thing is, not sure who will offer to help until you say what it is you are trying to achieve (more detail than "a better UI"), what additional functionality you envisage and the language(s) you intend to use. At the moment I can't see why a new ground-up editor is needed as the existing Mapster code can be built on (and yes, it is like a lump of spaghetti tangled up with another lump of spaghetti). I've a lot of ideas of what I'd like to see in an editor but so far the only one that I think would demand a re-write would be the ability to have multiple maps open at the same time and cut/paste between them.

TTFN,
Jon

Attached thumbnail(s)

• 
• 
• 
• 
• 

[CultureShock]

I was going to write a comment about people being attracted to bling and cutting new turf instead of architecture and maintenance issues. This is true (or can be true). I do think this new essay The Sad Graph of Software Death poses an intriguing question!

I haven't spent any time with the code since I posted, previously. I did wonder about tracing the code through to discover its structure and function points and which libraries were being used so I could better understand this opaque mess. It is the minimum I would need to understand the feasibility of a new editor. Additional data includes menu and hooking to onscreen hooks.

I've noticed a few issues with your scripting engine implementation too. This could be tweaked to be more architecturally coherent.

Once it's established that a reworking is possible I'm confident various possibilities to move the engine forward fall easily in to place. Some of the functionality can very definitely be be added to or improved more easily with a new GUI interface. The other major item is this would likely improve both usability and access to additional functionality. The user and new user experience would be much more familiar and compelling.

I noticed there may be changes of internal data structures which might help facilitate expanding the editor to include other BUILD engines and of course the other engine which shall not be named!

I don't think this is an especially big task nor would it interfere with other development. Both could continue in parallel. If nobody is interested with helping and I'm in the mood again I'm tempted to follow this through myself. I'm not sure though. It's a nice idea but gives me a headache just considering it!

[The Mechanic]

CultureShock, on 02 January 2016 - 06:05 PM, said:

I was going to write a comment about people being attracted to bling and cutting new turf instead of architecture and maintenance issues.

How many end users - customers - give a monkeys about architecture and maintanence ? How many about new features (bling/new turf)?

Quote

I did wonder about tracing the code through to discover its structure ...

Mapster and structure ? LMAO ! Over the years as features have been added the associated code has been much improved, evolution rather than revolution, but at the end of the day is built on a piece of software that was almost certainly only ever intended to be used in-house by a handful of people, done in a hurry by someone with little coding experience at the time.

Quote

I've noticed a few issues with your scripting engine implementation too. This could be tweaked to be more architecturally coherent.

I won't argue with that.
Read me.

Also looking at release notes other useful improvements are in hand, such as "set" instead of "setvar/setvarvar" (1/3rd of my errors are generally related to this !).

Quote

I don't think this is an especially big task nor would it interfere with other development. Both could continue in parallel. If nobody is interested with helping and I'm in the mood again I'm tempted to follow this through myself. I'm not sure though. It's a nice idea but gives me a headache just considering it!

The only reason I won't offer to help in a new editor is I think so much can be done in the current Mapster which, to use modern language, will improve the user experience in a much shorter time-frame. I certainly am not sitting back gleefully rubbing my hands going "ooh, lets watch him fail", far from it, I wish you the best of luck.

When you have ideas of way you'd want an new editor to work, post them here, I can gaurentee people will be only too wiling to help refine the ideas or suggest additions.

Trooper Dan, on 29 December 2015 - 07:43 PM, said:

I would take issue with the statement that "mapster is very usable as-is", however. Yes, people can and do use it to make levels, but it's pretty damned hard to use

Without the use of menus and dialogs, I can't see any other way mapster could be made easier. There are so many keypress combinations they can be difficult to find/remember and it also limits how any more functionality could be added. If you started with a clean sheet of A4, how would you envisage it should work ? Stuff I think would be useful and lower the barrier for new users would be:

Right-click, create a room, dialog pops up so you can select textures. New user creates first room using a reasonable scale.(Could even do something really bizarre and set the player start in the right place )
Select two sectors, right click, "connect with a door", pops up dialog with door types, what sounds do you want, autoclose? etc.
Select two sectors, right click, "connect with a window"
Right-click on a wall -> menu to tag / split / delete /mask/...
Right-click on sector, "add effect" -> "Flashing Lights", and if the sector is anything other than a really small sector then it prompts "are you sure? Big areas of flashing lights usually suck".
Right-click copy/paste would be nice.
Right-click, insert sector - way easier than drawing a sector inside a sector, then alt-S'ing on it whilst praying it'll work this time (works 99% of time on my Win8 machine, 10% of time on ye olde Win7 machine).
Support for themes (could be done in a limited way via tiles.cfg).
Support project based map development (specify a folder and always load/save maps to that folder, use that folder's names.h + tiles.h + a.32 and .....)
Support defining a location for duke3d.grp and duke3d.rts so mapster doesn't have to be in same folder -> I don't have 20+ copies of these files and is less work when trying different mapster versions for testing.
In 3D mode:-
hold down mouse button on floor/ceiling and drag 'em up and down, adjusting any neighbouring sloping sectors with it.
Launch Eduke whilst in 3D mode (even if this causes a switch to 2D mode).

This is all easily achievable in the current Mapster. It took me two evenings to unravel the spaghetti and find two points in the code to hook to implement menu's (in 2D mode) but once that was done, and having a basic understanding of a few key data structures, implementing a menu system was straightforward.

From my point of view, what is blocking this happening is the requirement to implement a lot of this via scripts instead of straight 'C' code. I totally get why scripting would be a good, but the fact is I can't make it all happen if I also have to sort out scripting too - it's too much for me alone.

TTFN,
Jon

[CultureShock]

I know my red top looks boyish with a blue denim skirt but, c'mon!

I've been asking questions and dropping hints which don't take much effort to answer and so far have been given nothing. One comment mentioned two menu hooks but this was one man replying to another man who never asked the question. Sexism in the boardroom? Hello?

I'm not even discussing the merits or demerits of modifying Mapster's code or even whether it will be done or who by. I was examining feasibility. Without any input given I would need to come up to speed from scratch while using a completely alien development environment to even consider a working prototype if I picked this up as a casual fun project to fill in during a few spare months. I couldn't ask for less exploratory discussion and all I'm hearing is doubling down on the existing vision and other people's complaints like I'm their mother. I only began asking about feasibility not wanting the whole being dominated and having the kitchen sink thrown in my face. You're racing ahead like you want everything and won't budge until you have a fully finished product done for you then you might decide to take an interest. I'm not a tart or work bunny so this is not going to happen!

I'm sure you have skills and you mentioned some very good ideas and specific issues which I sympathise with. I'm just not sure we're starting from the same place with this.

I'm not enthused for taking this further without quid pro quo. Step one first, please? If there is no step one there will not be a step two. Not from me!

[Danukem]

CultureShock, on 03 January 2016 - 06:57 PM, said:

I've been asking questions and dropping hints which don't take much effort to answer and so far have been given nothing. One comment mentioned two menu hooks but this was one man replying to another man who never asked the question. Sexism in the boardroom? Hello?

Are you referring to Jon "The Mechanic" mentioning that he found two places in the code where menus could be hooked? I'm not aware that anyone asked him where to find said hooks. I'm pretty sure that he would be happy to point anyone in the right direction if asked. Did you ask him? Are you suggesting that he is being sexist because he didn't write detailed instructions explaining what he did to get to get some menus working in mapster?

[TerminX]

Trooper Dan, on 03 January 2016 - 07:18 PM, said:

Are you referring to Jon "The Mechanic" mentioning that he found two places in the code where menus could be hooked? I'm not aware that anyone asked him where to find said hooks. I'm pretty sure that he would be happy to point anyone in the right direction if asked. Did you ask him? Are you suggesting that he is being sexist because he didn't write detailed instructions explaining what he did to get to get some menus working in mapster?

If there were detailed instructions, it would be "mansplaining."

Just another troll.

[CultureShock]

Trooper Dan, on 03 January 2016 - 07:18 PM, said:

Are you referring to Jon "The Mechanic" mentioning that he found two places in the code where menus could be hooked? I'm not aware that anyone asked him where to find said hooks. I'm pretty sure that he would be happy to point anyone in the right direction if asked. Did you ask him? Are you suggesting that he is being sexist because he didn't write detailed instructions explaining what he did to get to get some menus working in mapster?

Pardon me for being dim but I understand feasibility of a new interface requires at least a little code analysis and comment on the libraries being used? I've dropped heavy hints about needing the entry points and code structure and program flow. What part of this is hard to understand? (The codebase is such a disorganised mess it likely would benefit from at least a little light refactoring but this is beyond the scope of this narrow task.)

I get this crap from men all the time. It's incredibly frustrating. I don't think it's sexism per se just men being set in their routine.

Jon has been really nice and helpful actually (even if he has the wrong end of the stick). A lot of men are really nice which I know is a surprising thing to say in this day and age! I just think this is an issue of competing views and priorities which reading back over the past five or so years the BUILD community haven't yet been able to resolve. Yes, I could say this is a men problem because, well, men. But I can understand how different people have different views and endpoints.

What I'm asking for I think and maybe the best way is help just picking through Mapster code for the critical bits. I'm starting from cold with this codebase. You guys (the men) know this and I don't. I can then work through this on my own to produce a working shell. Deeper interfacing hooks and scripting and possibly plugins are worth discussing. I think this makes more sense later though. We can pick through them one buy one which helps breaks the task down into small manageable chunks. What I'm saying is this is a process not a destination and like relationships needs work as we go along. If we can evolve discussion of the benefits of a modern GUI and how things fit together and how this may help facilitate development and include a larger mapping community this may be a larger benefit in itself too. While this is where I would like to arrive it's best I don't race ahead either because this is too demanding for you guys.

I'm just not moving forward with this if I'm not enjoying myself too. I'm just feeling like a work bunny who is expected to disappear and pop out with everything done when this is too much for me to carry. I can't carry this without a little help along the way. Like, I have my needs too!

[CultureShock]

TerminX, on 03 January 2016 - 07:51 PM, said:

If there were detailed instructions, it would be "mansplaining."

Just another troll.

I've been very specific and stuck as close as I can to the task. Yes, I was mansplained but I didn't just make an accusation. I explained why. I also believe it's fair to say I understood why they jumped to conclusions so there is at least a little give and take on my part! Different people who don't know each other don't necessarily know each others talents or plans and this may take time to discover.

I will confess I do love men's attention and if I can con men into doing what I want them to do while leaving men thinking they were the ones who thought of it and they are saving the day I wouldn't complain either.

You can't win boys. Give up!

[Danukem]

I am not a programmer and I know nothing useful in this area. I learned how to write CON script for Eduke32 so that I could make and share fun mods. That is all. I can read C well enough to (sometimes) figure out what the game is doing when I look at the source code, but not well enough to make any useful contribution. I am now done with this thread.

[CultureShock]

Trooper Dan, on 03 January 2016 - 10:04 PM, said:

I am not a programmer and I know nothing useful in this area. I learned how to write CON script for Eduke32 so that I could make and share fun mods. That is all. I can read C well enough to (sometimes) figure out what the game is doing when I look at the source code, but not well enough to make any useful contribution. I am now done with this thread.

I'm really sorry you're saying this but are you sure your C skills aren't good enough? I just need to trace through where the codebase entry points and flow is. Where does the main loop begin and where the windowing code is called? Plus anything else if which calls GTK or SDL or OS equivalent like Win32... I've found some but not all of this. This is completely optional but I'd like to slightly refactor the code and just need to know where the main blocks of stuff are located. (Ideally the code would be refactored and files renamed and code better documented but this is too much for this task and likely better as an ongoing task as the code evolves.)

I'm using Linux which is still a learning curve for me and Eclipse which I have never used before and is very different from Visual Studio or Borland etcetera.

Um, well. I'm sorry I didn't better appreciate your coding skills and needs. If this is a stretch for you I understand. Thank you for helping how you could. This is appreciated even if we weren't able to go very far with this together.

[The Mechanic]

CultureShock, on 03 January 2016 - 08:22 PM, said:

I've dropped heavy hints about needing the entry points and code structure and program flow. What part of this is hard to understand?

Understanding the question is not hard. Answering those questions is however completely different. A whole book could be written. You need to ask more targeted questions.

"Entry points" I have no idea. One minute I'm in the "build" library, next I'm in the "eduke32" library and they are somewhat intertwined. I've not gone anywhere near the other four libraries.

"code structure" I'm sure you have sussed that there is precious little. If by structure you mean some of the main map related data structures then structs for sprites, walls etc very much echo those used CON files so you can use this page as a substitute for Mapster's lack of doc.

"program flow" - The way I tend to find bits of code I need to use is to start with monster funcs keys2d() and keys3d() (you can ignore the minor keys2d3d() for now) which interpret primary key presses (that is keys that initiate doing something); if I need to work out how to manipulate sectors for example then I find an editor keypress that fiddles with sectors in some way, try and find them in the keysxx functions and look at what it does. However some keyboard interception can't be found so easy so I ended up sprinkling a few breakpoints in the code on functions that I suspected *could* get called and then if lucky was able to do a callstack dump to find how the hell it got there.You can then look at who calls keys2d(), you'll arrive (eventually) at app_main in build.c, look at what it calls. overheadeditor() is a good one.

Oh, and watch out for some macros such YAX_SKIPWALL. This is actually a good case where although the macro is an abomination - it hides a "continue" which really threw me for a while - I can totally get why it is done that way due to the way the code works and I can't suggest anything better (other than a major restructuring).

CultureShock, on 03 January 2016 - 08:22 PM, said:

(The codebase is such a disorganised mess it likely would benefit from at least a little light refactoring but this is beyond the scope of this narrow task.)

I think getting Doxygen into the project would be a better first step as it could be used to help understand what the hell is going on before thinking about how to refactor. I mentioned this to Helixhorned some time ago.

CultureShock, on 03 January 2016 - 08:22 PM, said:

I get this crap from men all the time. It's incredibly frustrating. I don't think it's sexism per se just men being set in their routine.

Loose the chip on your shoulder. Seriously. I noticed something about gender in earlier posts but didn't pay any attention until the above statement. When I answer posts here I've never met any of the posters in person and have no idea of their gender and some previous statements have negative results - I mean, now I may miss out details for fear of being accused of "m a n s p l a i n i n g" (spaces added to try and foil whatever is auto-changing what I type). Don't point me at your avatar as a clue, I read nothing into other people's avatars - I very nearly set my avatar to Mrs Doyle when I joined.


TTFN,
Jon

[CultureShock]

I prefer working from expanding a structural view and working down. I've discovered that time and time again people become lost in specifics. This is especially true of technical people who may both lose track of the overall details or lack context of other domains. This is why for example marketing and engineering throw rocks at each other.

But ugh. Yes, this code is a difficult read... I hate macros and makefiles. I wasn't sure what the relationship between EDuke and Build code was nor where one began and the other ended. I also had a problem identifying the input-output code (like keyboard) and was confused with Win32 and GTK code (but no SDL code I can find). I'm not sure where or how platform specific code is called or compiled. I couldn't make sense of a wall of code which ran on and on with cryptic function and variable names. I found some rendering code but couldn't understand how the different renderers were called. I wasn't looking for this specifically but have no clue where mouse or networking code is.

I hate DOxygen. I was screaming for this which show show big a hairball the code is!

In an ideal world I would separate out Eduke and Build main loops. The interface code should be separated out too and abstracted properly so we would have keyboard, mouse, and graphics in their own directories. Other code like data structures could later be separated out too. Beyond this demangling and renaming to self-explanatory naming schemes is horrendous!

Maybe the best for now is to document things as they are discovered...

Okay, your identifying a mainloop and keyboard functions helps a little. I'm still a little hazy with this as I discovered both GTK start-up screen and Win32 code. I have no clue which begins where. I hope this doesn't involve makefiles. I cannot for the life of me discover SDL code being used but it's in the codebase. I need to make sense of the main loops, the keyboard handling code, and properly confirm how the display surface is dealt with. Specifically, I need to know exactly what creates the window and what creates the display surface and what hooks both together. Is this native, or a toolkit like GTK or SDL and which one. If native or GTK is being used things should hopefully be straightforward.If SDL is being used you have the problem of an SDL mainloop too. If SDL is relied on for input and output too this too needs to be identified.

What I planned is if I could identify this I should be able to create GUI shell using GTK. I should be able to create the window environment, hook in to mouse and keyboard, and destroy everything later. If abstracted properly it should be possible to maintain a GUI abstraction plus the existing scheme. I'm unsure at the moment but wonder if properly done this abstracting would help tidy up one small corner of the codebase. This may be useful for future porting or engine enhancements.

It would be nice to get in to data structures more to modernise the internal code. Your tip helps a lot. I don't think I will be doing this though. My brain aches enough!

[LeoD]

The Mechanic, on 04 January 2016 - 03:35 AM, said:

I think getting Doxygen into the project would be a better first step as it could be used to help understand what the hell is going on before thinking about how to refactor.

This.

Spoiler

I plan to design a nuclear power plant better then everything we have now.

Spoiler

But I can't start until someone explains that stuff about turning on a radio's activity.