[Helixhorned]

RichardStorm, on 19 November 2013 - 08:23 AM, said:

Anything odd to know about sprite.extra ? sometimes i get 0 using getactor[whatever].extra... i set it via mapster... nothing overrides extra value ...

For actors, .extra actually holds their strength. For sectors, it's the lotag of a containing GPSPEED sprite, or 256 by default. In any case, I wouldn't use .extra for my own scripting purposes, better simply create a new per-actor gamevar.

Edit: oh, I noticed that getting values via the map is what you want. In that case, you could try putting them into {x,y,z}vel and extracting them at premap (EVENT_LOADACTOR). I think that's the standard procedure other mods handle it as well.

[Fox]

Yeah. With eventloadactor you actually can extract the values before any script from the game takes place.

[RichardStorm]

How the hell i copypasta sectors with "new" mapster ?

I select both sprites and sectors with Rshift, but C or Ins just double sprites, and not sectors. What i'm missing ???

[Micky C]

It's right alt, not right shift, it's always been like that.

[MetHy]

Selecting sectors with Alt Gr (right alt) doesn't work in the newest mapster. Try an earlier version.

[Jblade]

Shit, so it's not just me then? I noticed it but thought it was due to my keyboard or something.

[Daedolon]

It's a problem with SDL versions 1.2 and later, EDuke32 switched to 2.0 recently. A fix is coming though.

[Helixhorned]

As suggested in another place, you may want to switch the OS keyboard layout to US before starting Mapster32. This may or may not solve the problem. I don't know why it's happening to you guys; for me it's fine in either Windows or Linux, so I can't debug this.

[neoacix]

Helixhorned, on 21 January 2014 - 08:19 AM, said:

As suggested in another place, you may want to switch the OS keyboard layout to US before starting Mapster32. This may or may not solve the problem. I don't know why it's happening to you guys; for me it's fine in either Windows or Linux, so I can't debug this.

Uhm.... maybe you should stick another keyboard with some foreign layout on your PC to debug this?!
Keycodes on foreign keyboards are not the same as on US-layout, as far as I know.
If I change the layout in my OS, the OS is emulating those codes for me, but mapster with SDL2 is ignoring this emulation, I guess.

So this maybe the reason why everything is fine for you, but not on foreign (non-US) keyboards.

[RichardStorm]

@helix
Ok helix, go buy an italian qwerty keyboard, and start debugging just kidding..

[Helixhorned]

neoacix, on 22 January 2014 - 06:50 PM, said:

Uhm.... maybe you should stick another keyboard with some foreign layout on your PC to debug this?!
Keycodes on foreign keyboards are not the same as on US-layout, as far as I know.
If I change the layout in my OS, the OS is emulating those codes for me, but mapster with SDL2 is ignoring this emulation, I guess.

I have a German keyboard, by the way. Anyhow, I don't think it makes sense to reason at such a low level. What matters is what value SDL2 gives on pressing RAlt: in sdlayer.c, at line 2125 as of r4266:

        case SDL_KEYDOWN:
        case SDL_KEYUP:
            code = keytranslation[ev.key.keysym.scancode];

What's the value of ev.key.keysym.scancode? It should be SDL_SCANCODE_RALT (#defined to 230 in SDL2/SDL_scancode.h). Our translation then yields 0xb8, the value that's used for RAlt in mapster32.cfg, among others. If someone can do a quick debugging session by setting a breakpoint at that location and pressing RAlt, that may bring the bug closer to resolution.

[RichardStorm]

"MD3 wtf" serie...

I exported a monster into md3 from blender, for a project i'm working on with other guys. It works, but the light wtf :



-Darkus flashlight code ( as planned in the mod )
-original .obj from the net
-blender 2.68, export script v.2.6 (win7)
-no normal or specular map, just texture.
-light works bad only in front of it

WHAT I'M SUPPOSED TO DO ???

P.S.
I hate how this thing is going on; i'm not supposed to do it cause i'm not a 3d/blender expert, too, but I'm the only who can do it right now unless i (we) find other skilled people.

[RichardStorm]

Sorry, but... Bump

[Mark]

I had a skeleton model that didn't light properly with the flashlight. I ran the model through the program called " Npherno". I chose the option to rebuild normals and export it back out. It fixed my problem. If you don't want to go through the trouble of installing and using the program I'll do it for you right away if you attach the model to your post.

EDIT: I waited about 20 minutes and didn't hear back from you. I'm going now to get some dinner. Sorry.

[RichardStorm]

Oh sry i was logged on this without reading ... i'll try right now with Npherno

EDIT: Used Npherno. Damn, it works. THANKS, i'll build a statue for you Mark.

[Mark]

Always happy to help.

[pmw]

Couple versions ago, I had this same problem..now it's back.

I have my eduke in directory D:\Eduke\.
My mapster's location is D:\Eduke\Mapster.exe.

Now, my episode's maps are located in D:\Eduke\episode\1.map, 2.map, 3.map etc.
When I start my Mapster, load example episode\5.map, it works fine.

BUT, when I hit SAVE, mapster saves my map to D:\Eduke\5.map. Not under episode\ (!).

What I'm doing wrong? Or are the old bugs back?


vers:

Mapster32 2.0.0devel r4309 (64-bit)
Compiled Feb 8 2014 06:47:19

[Helixhorned]

It's a known bug, and I agree that it's annoying. Currently, Mapster32 always saves in the directory that is the current working directory (usually, the one containing the exe on Windows, ~/.eduke32 on Linux). It's partially because a map could have been loaded from other sources than the OS's file system, namely GRP and ZIP files. So, in case it was really loaded from the local FS, we'd need to track that somehow.

[RichardStorm]

I bought DN3D megaton Edition a while ago on steam...

Now any eduke32 always recognize that steam folder's Duke3d.grp file, instead of the one inside eduke folder, how to avoid this ?

[RichardStorm]

Lil' bump

[LeoD]

RichardStorm, on 21 February 2014 - 04:40 AM, said:

I bought DN3D megaton Edition a while ago on steam...

Now any eduke32 always recognize that steam folder's Duke3d.grp file, instead of the one inside eduke folder, how to avoid this ?

eduke32.exe -usecwd

[pmw]

Why new mapsters are changing top/bottom orientation of textures when I use . <- button for auto-aligning?
In earlier versions, it was fine, now it messes up everything.

Is this a bug, or just someone's "great" idea to change something which worked fine?

[pmw]

I don't know does anyone read this topic...but my question belongs here:

Is there any way to avoid this problem:




I've made a table of sprites. I can see concrete sprite block from under the table -- not always, but from sometimes.
Same thing if I made a real red line block there, I can see it trough sprites.

Is there any way to avoid this?

[Daedolon]

Stop using the shitty 8bit renderer.

Or make the base out of sectors.

[pmw]

I'm never gonna stop using 8bit renderer.
What you mean by "base out of sectors"?

Daedolon, on 15 June 2014 - 03:43 PM, said:

Stop using the shitty 8bit renderer.

Or make the base out of sectors.

[Gambini]

Daedolon, on 15 June 2014 - 03:43 PM, said:

Stop using the shitty 8bit renderer.

Or make the base out of sectors.

Making the base out of a sector would expose similar glitches.

Quote

Is there any way to avoid this problem:

The order in which the sprites are drawn is directed from their "origin" distance to the player. Think of that when building your spritework. For that table I´d use more and shorter sprites for the edges and the upper part.

[Forge]

pmw, on 15 June 2014 - 03:32 PM, said:

I've made a table of sprites. I can see concrete sprite block from under the table -- not always, but from sometimes.
Same thing if I made a real red line block there, I can see it trough sprites.

Is there any way to avoid this?

make the base out of sector work (red line walls for the box). & raise it until it is the height of the table top. texture the same as the table top.
put sprites around the box, but don't allow any part of the sprites to cross the box's sector lines that you don't want to disappear.

if the player can view a sector that has a sprite partially entered into it while at the same time they can no longer see the center of said sprite, you'll get those clipping out issues.

Gambini, on 15 June 2014 - 04:30 PM, said:

Making the base out of a sector would expose similar glitches.

The order in which the sprites are drawn is directed from their "origin" distance to the player. Think of that when building your spritework. For that table I´d use more and shorter sprites for the edges and the upper part.

^-this
____________
|...................|
|........|..........|<-sprite always stays in view on this side of the sector line because
|........O.........| the center of the sprite is on this side
|---------------|----------<-red sector line
|...................|
|___________|<-the part of the sprite on this side will clip out of sight if player stands close to or on the sector line - the sector that's clipping though from underneath is getting drawn at a different time than the sprite that makes up the table top because of distances between the player, the center of the sprite, and the sector that makes up the table base.

[pmw]

Thanks for advice.

Now these really kicks ass:

[The Commander]

Those walls really need attending to...

[Mike Norvak]

The Commander, on 18 June 2014 - 06:07 PM, said:

Those walls really need attending to...

You can tell by the look of the entire shot, that those walls are unfinished...