[Forge]

Gambini, on 14 October 2011 - 06:46 PM, said:

...

Here are some images attached, gay circles ...

This being a description of the people you associate with?

I knew it. Poofter!

[blizzart]

blizzart, on 10 October 2011 - 12:57 PM, said:

I have a Mapster 32 scrpting problem here.

I included the a.m32 with the console and wanted to use the EVENT_PREKEYS3D (description here: http://wiki.eduke32....script_examples), but it didn´t work. Did I miss something?

Forget about I opened the a.m32 in notepad and saw how it works.

Sorry for asking this stupid question in first place.

[Danukem]

blizzart, on 15 October 2011 - 03:44 PM, said:

Forget about I opened the a.m32 in notepad and saw how it works.

Sorry for asking this stupid question in first place.

I wish there were more people like you.

[Helixhorned]

Gambini, on 14 October 2011 - 06:46 PM, said:

Today Steam broke the Source tools so I felt like replaying my last map for Duke. It would have been funny to take a picture of my expression when I saw my beloved map and its best friend -the software renderer- broken. There are several clipping issues with sprites, more specifically: it occurs when sprites are very close to walls, they tend to overpass the wall and clip out in very strange shapes, even through the floor. I wonder whether this has something to do with Polymer or TROR but whatever reason it calls for a fix.

This is ugly, and it doesn't have anything to do with TROR. It turns out that the clipping of drawn sprites against the rest of the geometry depends on the viewingrange since DOS Duke, but r1957 (which made r_usenewaspect turned on by default) made that issue noticeable. So, if you can live with a slightly distorted image, setting r_usenewaspect to 0 should rid you of the sprite drawing glitches, but the long-term solution will involve me reading a good chunk of unfamiliar engine code and looking for an elegant way to fix this.

[Gambini]

Hey. You make it sound like if I were the only person left using software . using that "r_usenewaspect" would fix it only for me and my report is rather aimed to show that that map (and most likely a lot more) looks broken for anybody using 8bits. What has been improved when the problem were introduced that is worth not fixing it by just removing the change? At least, until you can sort out the difficulties of finding that elegant way to make everybody happy.

[Kyanos]

Gambini, on 17 October 2011 - 03:09 PM, said:

What has been improved when the problem were introduced that is worth not fixing it by just removing the change?

Every single model in Eduke had an improper shape whenever using a new aspect ratio (eg. a cube comes out as a rectangle)
But, IMHO (as a modeler I might add) software mode should always work correct. If it means advanced things have to wait so be it.
It must be extremely difficult working on an engine with 3 different rendermodes. I can't even imagine the headaches this has caused our beloved development team

[Hendricks266]

Drek, on 17 October 2011 - 03:40 PM, said:

Every single model in Eduke had an improper shape whenever using a new aspect ratio (eg. a cube comes out as a rectangle)

Ideally, what we need is for a cube in Blender to appear a cube in EDuke32. No screwing around with stretching. I believe Helix's new code fixed that. If that means old models are messed up, that's a small price to pay for them being actually correct.

[Kyanos]

I agree. When I first started modeling I got baffled because my cubes weren't quite so cubicle. Helix's code did fix that. The issue here is that it "broke/damaged/quick kicked" a part of the software render.
I always wondered if mixing classic and polymer is worth it. I mean couldn't you have two separate engines, EDuke32-bit & EDuke8-bit? It's just a thought but most people use 32 bit or they don't, and those that use both can just get both.

[Danukem]

Gambini, on 17 October 2011 - 03:09 PM, said:

Hey. You make it sound like if I were the only person left using software . using that "r_usenewaspect" would fix it only for me and my report is rather aimed to show that that map (and most likely a lot more) looks broken for anybody using 8bits. What has been improved when the problem were introduced that is worth not fixing it by just removing the change? At least, until you can sort out the difficulties of finding that elegant way to make everybody happy.

Gambini, it is actually worse than you think. The change effects all modes, not just software. I was playing Smithsonian Terror (a Duke it Out in DC map) the other day in Polymost, and I could see some sprites through a wall. It was in the parallaxed room in the space museum part. I have seen glitches in other maps as well. So yes, the problem is widespread.

Perhaps it would be better if r_usenewaspect were 0 by default until this is sorted out.

[Gambini]

Or the command/fix/whatever should be tied to using an engine that requires it. Like, everytime you switch renderers something automatically takes care of writting r_usenewaspect 1 or 0.

Quote

If that means old models are messed up, that's a small price to pay for them being actually correct.

I would not call it a "small price". At least 80% of the worth content done for Duke doesn´t use or does not recommend using models. Breaking the original game´s compatibility in sake of making it easier for today modellers sounds more like a terrible mistake.

[Plagman]

The aspect ratio should always be correct in Polymer, and it shouldn't be affected by any such sprite clipping bug. Unless you specifically set a custom aspect ratio, a cube should always appear square no matter what resolution you pick. Please let me know if that's not the case.

[Paul B]

Okay something I have noticed while editing in Mapster. I'm not sure if this is by design or if it is a bug. Anyway, if you raise the floor to the ceiling and attempt to lower the floor once it is squished it doesn't lower. You can only raise the ceiling before lowering the floor. Also the same works for the ceiling. If the ceiling is lowered to the floor and you attempt to raise the ceiling you first have to lower the floor before you can raise the ceiling again. I find this to be an annoyance since the original build editor didn't have this problem. It also causes problems with special sector effectors getting pushed through the floor and this can result in glitches with the way the sectors behave. Is this something that can be fixed?

A bit off topic but if the development team would like a multi-player beta tester i'd be more than happy to assist in anyway.
Thanks,
Paul

[Stabs]

helix bro, whats the chances of you making a script that can subdivide via a power to a selected sectored and turn them into a generic terrain type surface with some triangles and sloping, just to take the flatness out of things a bit more easily?

[rasmus thorup]

There's state mkterrain.

[Stabs]

yeh but thats more for elevations, i just want something to fill a flat plane

i actually prefer to use ctrl + m1 to control and hand draw all elevated/organic terrains

[Helixhorned]

Paul B, on 22 October 2011 - 10:51 PM, said:

Okay something I have noticed while editing in Mapster. I'm not sure if this is by design or if it is a bug. Anyway, if you raise the floor to the ceiling and attempt to lower the floor once it is squished it doesn't lower. You can only raise the ceiling before lowering the floor. Also the same works for the ceiling. If the ceiling is lowered to the floor and you attempt to raise the ceiling you first have to lower the floor before you can raise the ceiling again. I find this to be an annoyance since the original build editor didn't have this problem. It also causes problems with special sector effectors getting pushed through the floor and this can result in glitches with the way the sectors behave. Is this something that can be fixed?

What is really aimed at when the cursor is at a given x,y-coordinate is renderer-specific. Besides, I can't reproduce your findings 100% (but I haven't tried very hard). Anyway, those seem like relatively benign issues and there's also Alt+SPACE when aiming at walls to compensate for the trouble of working inside squished sectors.

DanM, on 30 October 2011 - 10:21 AM, said:

helix bro, whats the chances of you making a script that can subdivide via a power to a selected sectored and turn them into a generic terrain type surface with some triangles and sloping, just to take the flatness out of things a bit more easily?

Sorry, I can't make much sense even after reading it for the 5th time. Do you really need the Foster's to make such awesome maps?

DanM, on 30 October 2011 - 10:23 AM, said:

yeh but thats more for elevations, i just want something to fill a flat plane

i actually prefer to use ctrl + m1 to control and hand draw all elevated/organic terrains

If you mean some auto-generated walls so that a sector is subdivided into e.g. triangles, Mapster32 or the scripting isn't really there yet. Also, Ctrl+what?

[Stabs]

bah fosters, cats piss, its illegal for Australians to be sober after 9pm

Well what i was trying to explain is a "fill" for a selected sector that basically subdivided it into triangles

[Forge]

DanM, on 30 October 2011 - 05:17 PM, said:

bah fosters, cats piss, its illegal for Australians to be sober after 9pm

Well what i was trying to explain is a "fill" for a selected sector that basically subdivided it into triangles

sounds like a terrain generator

[Stabs]

load map01
start new map
save as map02
press ctrl + s and it saves over map01 derp

ffs lucky i had a backup

[Helixhorned]

Ouch, this sucks! Even if that particular problem is sorted out now, it always pays off to regularly back stuff up.

[TerminX]

 Helixhorned, on 31 October 2011 - 12:08 PM, said:

Ouch, this sucks! Even if that particular problem is sorted out now, it always pays off to regularly back stuff up.

I'm thinking that instead of requiring a "y" keypress to confirm the save, we should just require a second press of ctrl+s to confirm (and anything else to cancel). Thoughts?

[Helixhorned]

Sounds good to me.

EDIT: On the other hand, the idea is to make the user take a glance at the file name under which the map will be saved. If two consecutive Ctrl-S's will be necessary to really save a map, there's the chance that users might simply get into the habit of pressing them quickly in succession. With Ctrl-S, Y, there's at least some "panic moment".

[Kyanos]

Ever think of doing a more eleborate autobackup like maybe mymap.map gets saved and the original is changed to mymap.map1
Then once again mymap.map is saved the overwrite becomes mymap.map1 then the mymap.map1 overwrite becomes mymap.map2
This is how blender works when overwriting and I like the system. The backups have a different extension so you never see it in the program and it's there if you need it.

[TerminX]

That actually crossed my mind when I read this thread earlier. I think it's a great idea, as long as the files are kept in a subdirectory so as to not clutter up the main one.

[Stabs]

cheers for the fix helix and thats a brilliant idea Drek

[Paul B]

Okay... This post is for Helixhorned.

When you have time, I was wondering if you could assist me. The reason why I didn't build my RCPD.map using mapster was because of some small set backs (bugs) with Mapster editing. I can demonstrate the bugs very easliy by using my RCPD.map as an example.

If I can trouble you for about 5 minutes to show you what I am talking about. Maybe you can help me address these minor quirks because I would really like to convert my RCPD.map over to Mapster and stop using build. This will allow me to enhance my maps with your new TROR feature as my RCPD map could definitely benefit from using ROR as well as providing me with more sectors to enhance some of the shading and detail.

Anyway, my first and major draw back is if you take my RCPD.map open it up in Mapster then save it as a different map name you will notice that when you play the game on the "Come Get Some Difficulty" the Pig Cops in the Alley go way off course and no longer follow their intended Locator paths. Is this something you can fix? This problem occurs in Build as well but opening the map in build a second time, resetting the player start location and saving and exiting fixes it in build. But in Mapster this is not the case.

My second and last glitch i found with mapster I had brought to your attention previously about lowering sectors to the floor like a sector lowtag 0,20 door and attemping to raise them in mapster which doesn't work as intended. This is critical for me to build anything properly. It would be nice to run under a squished sector and hit the page up key and actually have it do something. Likewise with a floor sector that is squished against the ceiling I should be able to page down that sector and have it actually go down again.

Thanks,
Paul

[Micky C]

About the going under the squished door and hitting page up, have you tried it in all renderers? I'm not sure about classic or polymost but I can guarantee you that you will be able to do this in polymer.

You can set herbs rendering modes in the start-up window in the drop down box that has screen resolutions. Some of them say 8-bit and some say 32-bit. Once you start up mapster in 32-bit mode, go into 3D mode, bring down the console with the tilde key (~) and type 'setrendermode 4' without quotation marks. It will then switch over to polymer. Polymer is rendermode 4, polymost is 3, and classic is 0 (1 and 2 were buggy test modes and removed).

I also think there may be a key combination which allows you to adjust the height of a sector on the opposite side of the wall you're pointing at. For example, if you point at the door, and hold down a key, you can move the height up and down. I don't know what the key is, but hopefully it's in the wiki.

The other problem sounds more serious and I'll let Helixhorned tackle that. In the meantime, nothing's stopping you from making new maps in mapster

[Helixhorned]

 Paul B, on 09 November 2011 - 10:39 PM, said:

Anyway, my first and major draw back is if you take my RCPD.map open it up in Mapster then save it as a different map name you will notice that when you play the game on the "Come Get Some Difficulty" the Pig Cops in the Alley go way off course and no longer follow their intended Locator paths. Is this something you can fix? This problem occurs in Build as well but opening the map in build a second time, resetting the player start location and saving and exiting fixes it in build. But in Mapster this is not the case.

This can only happen due to Mapster32 resetting some sectnums of sprites that are out of the bounds of their containing sectors. I checked your map and there weren't any LOCATORS among them, though. Anyway, r2110 addresses this, looks like this 'auto-fixing' sometimes does damage.

Quote

My second and last glitch i found with mapster I had brought to your attention previously about lowering sectors to the floor like a sector lowtag 0,20 door and attemping to raise them in mapster which doesn't work as intended. This is critical for me to build anything properly. It would be nice to run under a squished sector and hit the page up key and actually have it do something. Likewise with a floor sector that is squished against the ceiling I should be able to page down that sector and have it actually go down again.

I finally understood what you meant by that, see r2111.

I hope that's enough to convert you to using the One True Editor . The key list on the wiki should be a good place to start about learning Mapster's features.

[Paul B]

Hi Helixhorned,

You never cease to amazing me, thank you! Your r2110 fix has resolved my problems with the flying pig cops. I have now started implementing TROR on my RCPD map. =)

Last but not least, I did try squishing sectors either floor or ceiling. It worked for me once as it was suppose to with the ceiling, but then stopped working consistently every time after that. A notification appears on the bottom left of my screen which states: "Didn't move Sector Floors"

Also I noticed that when lowering the floor from the ceiling you cannot perform this action because the floor disappears all together showing the sector beside it. So you can't put your mouse on the floor of the squished sector because its invisible and doesn't lower.

But I'm happy to hear you were able to reproduce the bug. So it is not just me. It doesn't sound like this bug is consistent for you?

Micky C - I tried your suggestions with using setrendermode 4 & setting resolution to 1024x768 32bpp but that doesn't appear to correct the squished sector problem for me. (Using Mapster).

[Helixhorned]

Ah yes, that "didn't move sector floors" is due to a thinko of mine, it's fixed in r2112 (man, I sure feel like I'm repeating myself always referring to revisions). About being in squished places, the thing is that the editor always places you a little below the floor then. It probably could be a bit smarter and figure out when to place you a little above the ceiling, depending on the surrounding sectors, but as I mentioned earlier, you don't need to be inside squished sectors at all. Just aim at a ceiling/floor door's wall, and holding LAlt (to affect the sector on the other side of the wall) and SPACE (to lock the aim), move the ceiling or floor as usual with (Ctrl+)PGUP/PGDN.